Ochrona serwera RedM przed atakami DDoS

Serwer RedM, który wieczorem znika w środku sesji i dziesięć minut później pojawia się z powrotem, rzadko ma problem ze sprzętem. Zwykle trwa atak na port 30120, i trwa dokładnie wtedy, gdy online jest najwięcej graczy. Ten artykuł pokazuje, jak chronić serwer RedM przed atakami DDoS: najpierw to, co możesz zabezpieczyć sam i bez dodatkowych kosztów, potem fizyczną granicę tych działań, a na koniec to, co musi wydarzyć się w sieci przed serwerem, gdy atak jest większy niż twoje łącze.

Wszystkie informacje dotyczą FXServera z ustawieniem gamename rdr3 na Debianie 12, Debianie 13, Ubuntu 22.04 LTS albo Ubuntu 24.04 LTS. Polecenia są napisane dla użytkownika root, jako zwykły użytkownik poprzedź je poleceniem sudo. RedM to modyfikacja Red Dead Redemption 2 od Cfx.re i siostrzany projekt FiveM. Oba działają na tym samym programie serwerowym, więc część techniki sieciowej jest naprawdę identyczna. Tam, gdzie tak jest, znajdziesz tu jedno zdanie, a część szczegółową we wpisie Ochrona serwera FiveM przed atakami DDoS. Cała reszta tego tekstu dotyczy wyłącznie RedM.

Jeśli atak trwa właśnie teraz: nie zmieniaj teraz niczego w server.cfg i nie restartuj serwera. Zabezpiecz najpierw pomiary (patrz rozdział „Zbieraj pomiary”), po ataku już ich nie będzie.

Dlaczego serwery RedM tak często stają się celem ataków DDoS

Serwer RedM jest bardziej opłacalnym celem, niż sugeruje liczba jego graczy. Powodem jest właśnie niewielki rozmiar sceny. We wrześniu 2026 publiczne trackery list serwerów naliczyły około 2000 aktywnych serwerów RedM z mniej więcej 12 400 jednoczesnymi graczami, wobec około 39 000 serwerów FiveM z mniej więcej 325 000 graczy. Kto unieruchomi jeden z 2000 serwerów RedM, zdejmuje z sieci wyraźnie większą część całej sceny niż ktoś, kto trafia w jeden z 39 000 serwerów FiveM. Dla atakującego, który chce zaszkodzić konkurencyjnemu projektowi, dźwignia jest więc nieporównanie większa.

Do tego dochodzi struktura społeczności. Roleplay w RedM żyje ze stałych sesji o stałych porach, często z zapisami i akceptacją postaci. Awaria o 20:00 nie trafia w przypadkowych graczy, tylko dokładnie w tych, którzy zapisali się na ten wieczór. Wiele projektów działa poza tym hobbystycznie, z małym budżetem, wisi na jednym tanim serwerze i nie ma drugiej instancji, na którą można by przełączyć. Publicznie udokumentowane przypadki ze sceny RedM opisują serie ataków ciągnące się miesiącami w niemal codziennym rytmie, które jednocześnie uderzały w serwer gry i w osobny serwer głosowy.

Technicznie dochodzi do tego fakt, że ruch gry idzie przez UDP. UDP to bezpołączeniowy protokół transportowy: nie ma nawiązywania połączenia, którego serwer mógłby wymagać, a adresy nadawcy da się podrobić. Atakujący nie musi więc ani wchodzić na twój serwer RedM, ani poprawnie się z nim komunikować, żeby wygenerować obciążenie. Czym dokładnie jest atak DDoS i jak się go buduje, wyjaśnia wpis Czym jest atak DDoS?.

Porty, o które naprawdę chodzi

Serwer RedM domyślnie wiąże się z jednym portem, i to na obu protokołach. W pliku server.cfg stoi w tym celu:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
set gamename rdr3
sv_enforceGameBuild 1491
sv_licenseKey "cfxk_..."

Wiersz set gamename rdr3 jest jedynym, który odróżnia serwer RedM od serwera FiveM. Gdy go brakuje, ten sam FXServer zgłasza się jako serwer GTA V, a klient RedM w ogóle się nie połączy. RedM nie ma własnego portu zapytań ani własnego portu RCON: zapytanie o serwer, nawiązanie połączenia, ruch gry i RCON idą przez te same dwa wpisy na 30120. Tak wygląda twarda sytuacja liczbowa:

Z czterech wymienionych portów do otwartej sieci należą dokładnie dwa: 30120 TCP i 30120 UDP. Port 40120 i port 3306 nie mają tam czego szukać, a SSH na porcie 22 powinno być ograniczone do twoich własnych adresów. To najczęstszy możliwy do uniknięcia błąd na serwerach RedM, bo wiele projektów startuje z gotowego przepisu na txAdmin i potem nigdy nie sprawdza, co serwer wystawia na zewnątrz.

Co możesz zrobić sam, zanim wydasz pieniądze

Ten rozdział jest najdłuższy i to celowo. Czysto skonfigurowany serwer RedM wytrzyma małe i średnie ataki o własnych siłach, niezależnie od tego, u kogo stoi. Kolejność jest wybrana świadomie: najpierw mierzysz, potem zamykasz i dopiero na końcu ograniczasz.

1. Inwentaryzacja: co w ogóle nasłuchuje?

Zanim napiszesz choć jedną regułę, sprawdź, co twój serwer wystawia na zewnątrz. Nie zgaduj, sprawdź:

ss -lntup

Interesuje cię kolumna z adresem lokalnym. 0.0.0.0:30120 oraz [::]:30120 oznaczają „osiągalny z całego internetu”, 127.0.0.1:3306 oznacza „tylko lokalnie” i nie potrzebuje żadnej reguły firewalla. Obok FXServera na serwerze RedM regularnie pojawiają się jeszcze txAdmin na 40120, MariaDB na 3306, serwer WWW dla strony projektu i czasem usługa głosowa. Spojrzenie oczami atakującego daje skan portów z zewnątrz:

nmap -Pn -p- --min-rate 1000 TWOJ.ADRES.IP.SERWERA

2. Zostaw otwarte tylko 30120 TCP i UDP

Dla RedM wystarczą dwa otwarte porty na zewnątrz, cała reszta zostaje ograniczona albo w ogóle nie trafia do sieci. W UFW wygląda to tak, dokładnie w tej kolejności, żebyś nie zamknął dostępu samemu sobie:

ufw allow 22/tcp comment 'SSH'
ufw allow 30120/tcp comment 'RedM'
ufw allow 30120/udp comment 'RedM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Zamień 203.0.113.10 na swój własny adres. Przy łączu ze zmiennym adresem to niepraktyczne, lepszy sposób opisuje następny rozdział o txAdmin. Pełną instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu.

Baza danych w żadnym wypadku nie należy do otwartej sieci. VORP, RSGCore i RedEM:RP potrzebują wszystkie MariaDB albo MySQL, zwykle przez oxmysql z ciągiem połączenia w server.cfg. To połączenie działa lokalnie, port nie musi więc być osiągalny z zewnątrz. Sprawdź w pliku /etc/mysql/mariadb.conf.d/50-server.cnf, czy stoi tam:

bind-address = 127.0.0.1

3. Zabezpiecz punkty końcowe HTTP FXServera

FXServer odpowiada na zapytania HTTP na części TCP portu 30120 i nikt nie musi w tym celu uruchamiać Red Dead Redemption 2. Zobacz, co twój serwer RedM tam wydaje:

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600
curl -s http://127.0.0.1:30120/dynamic.json

/players.json wypisuje podłączonych graczy razem z ich identyfikatorami, /info.json konfigurację serwera i załadowane zasoby, /dynamic.json bieżące obłożenie. Dokładnie te trzy punkty końcowe są udokumentowaną drogą ataku w warstwie 7 przeciwko serwerom FiveM i RedM: są osiągalne bez logowania, można je odpytywać dowolnie często, każde zapytanie kosztuje twój serwer pracę, a treść zdradza atakującemu, kiedy atak się opłaca. Dwa środki zaradcze nic nie kosztują. Po pierwsze adresy graczy nie mają czego szukać w odpowiedzi, wystarczy do tego jeden wiersz w server.cfg:

sv_endpointPrivacy true

To ustawienie ukrywa adresy IP twoich graczy w publicznych wynikach serwera. Po drugie: jeśli twój bot na Discordzie albo strona projektu pokazuje liczbę graczy, nie odpytuj punktu końcowego z przeglądarki odwiedzającego, tylko buforuj wynik w stałych odstępach. Dzięki temu popularna strona ze statusem generuje jedno zapytanie na interwał zamiast jednego na odwiedzającego. Przy tak małej scenie jak RedM waży to podwójnie, bo pojedynczy bot ze statusem serwera może być wpięty jednocześnie w kilku serwerach Discord.

4. Wyjmij txAdmin na porcie 40120 z otwartej sieci

txAdmin to interfejs zarządzania zawarty w buildzie FXServera dla FiveM i RedM, a nasłuchuje domyślnie na 40120 TCP. Za nim leży pełny dostęp do twojego serwera: restarty, lista banów, baza graczy, zarządzanie zasobami. Bez stałego adresu IP do reguły zostaw ten port zamknięty z zewnątrz i dostawaj się do niego przez lokalne przekierowanie portu z SSH, a potem otwórz w przeglądarce http://127.0.0.1:40120:

ssh -N -L 40120:127.0.0.1:40120 root@TWOJ.ADRES.IP.SERWERA

Kto zostawia txAdmin publicznie, dostaje dwa problemy naraz: maskę logowania, przeciw której da się prowadzić floody logowania, oraz usługę, która przy każdym zapytaniu wykonuje pracę, choć z samą grą nie ma nic wspólnego. W razie wątpliwości zwiąż txAdmin od razu lokalnie, każąc usłudze nasłuchiwać tylko na 127.0.0.1.

5. Ogranicz liczbę połączeń i pakietów na adres źródłowy

Przeciw małym atakom i niechlujnym botom pomaga górny limit na adres źródłowy. Obie reguły dotyczą portu 30120, czyli obu protokołów gry:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name redm_udp --hashlimit-mode srcip --hashlimit-above 500/sec --hashlimit-burst 750 -j DROP

Pierwsza reguła odrzuca nowe połączenia TCP, gdy jeden adres ma ich otwartych jednocześnie więcej niż osiem, druga odrzuca pakiety UDP powyżej trwałych 500 pakietów na sekundę z tego samego źródła. Wartości startowe leżą tu nieco niżej niż na serwerze FiveM, bo serwer RedM z 32 slotami generuje po prostu mniej legalnych połączeń na adres. Wartości startowe nie są jednak prawdami objawionymi: pełny wieczór RP generuje wyraźnie więcej pakietów niż pusty serwer, a kto ustawi limit zbyt ciasno, wyrzuci własnych graczy. Najpierw mierz przez tydzień w normalnej pracy.

Dwie uwagi. Same reguły iptables znikają po restarcie, na Debianie i Ubuntu zapisuje się je tak:

apt-get install -y iptables-persistent
netfilter-persistent save

A przy UFW takie reguły należą do /etc/ufw/before.rules, bo inaczej znikną przy następnym ufw reload. Często przeoczonym wąskim gardłem jest ponadto śledzenie połączeń w kernelu: gdy się zapełni, serwer odrzuca także legalne pakiety, a w logu stoi „nf_conntrack: table full”. Stan i górny limit pokazuje:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

6. Zabezpiecz 32 sloty przed floodami dołączania

Serwer RedM ma bez OneSync dokładnie 32 sloty. Z OneSync jest ich 48, powyżej tego potrzebna jest subskrypcja Element Club na maksymalnie 1024 miejsca. Ta liczba ma znaczenie dla bezpieczeństwa, bo jest górną granicą, którą atakujący musi zapełnić: kto utrzymuje jednocześnie 32 otwarte próby dołączenia, zajmuje standardowy serwer w całości, i to bez tego, żeby choć jeden gracz naprawdę wszedł do gry. Przy projekcie FiveM ze 128 miejscami ten sam próg jest cztery razy wyższy.

Częściowo wyrównuje to przewaga specyficzna dla RedM: RedM wymaga prawdziwej kopii Red Dead Redemption 2, wszystko jedno czy kupionej przez Steam, Epic Games czy Rockstara, do tego launchera Rockstar. Flood dołączania z tysiącami kont jednorazowych, typowy przy grach darmowych, kosztuje tu więc realne pieniądze. Ataki przesuwają się przez to na warstwę sieciową i na punkty końcowe HTTP, gdzie kopia gry nie jest potrzebna.

Przeciw wszystkiemu, co korzysta ze zwykłej drogi dołączania, i tak działa whitelista. Wdraża się ją po stronie serwera w zdarzeniu playerConnecting, gdzie zatrzymujesz połączenie funkcjami deferrals, sprawdzasz identyfikator i dopiero potem przepuszczasz gracza. Do tego dochodzi ostra weryfikacja konta oraz realistyczny limit graczy:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

sv_authMaxVariance to wartość od 1 do 5 i określa, jak mocno identyfikator gracza może się zmieniać u danego dostawcy; 1 jest ustawieniem najostrzejszym. sv_authMinTrust również biegnie od 1 do 5 i opisuje, jak nieprawdopodobna musi być podrobiona tożsamość; tutaj najostrzejszą wartością jest 5. Hasło RCON ustawiaj tylko wtedy, gdy RCON jest ci naprawdę potrzebny, bo ten dostęp leży na tym samym otwartym porcie 30120. I jedno musi być jasne: whitelista chroni twoją logikę gry, a nie twoje łącze. Atakujący, który zalewa twój serwer, wcale nie chce dołączyć. Jego pakiety zostaną odrzucone, ale i tak już dotarły, i o to właśnie chodzi.

7. Właściwie oceń wpis na liście serwerów RedM

Tutaj opłaca się szczerość zamiast myślenia życzeniowego: twojego adresu IP nie da się utrzymać w tajemnicy. RedM korzysta z tej samej infrastruktury masterserwerów Cfx.re co FiveM, a wpis na liście zawiera w polu connectEndPoints punkt końcowy połączenia otwartym tekstem. Przez publiczny interfejs pod adresem servers-frontend.fivem.net da się do każdego kodu cfx.re odpytać przypisany adres, dla RedM tak samo jak dla FiveM. Kto publicznego wpisu w ogóle nie potrzebuje, bo projekt działa wyłącznie przez Discorda i połączenie bezpośrednie, może prowadzić serwer jako prywatny przez sv_master1 "": z listy serwerów nie da się wtedy do niego dołączyć. Kosztuje to jednak całą widoczność dla nowych graczy, a w scenie liczącej 2000 serwerów widoczność jest właściwym motorem wzrostu.

Skuteczniejsze są dwa nawyki. Nigdzie nie publikuj surowego adresu IP samodzielnie, czyli ani na kanale Discord, ani na stronie projektu. I podłączaj graczy przez nazwę hosta, żeby w razie potrzeby móc zmienić adres bez łamania wszystkich odnośników. Klasykiem są przy tym stare wpisy DNS: zapomniany rekord A wskazujący na poprzedni adres unieważnia każdą zmianę.

8. Sprawdzaj zdarzenia VORP, RSGCore i RedEM po stronie serwera

Wiele awarii zgłaszanych jako atak DDoS bierze się z jednego skryptu. Zasoby RedM komunikują się przez zdarzenia sieciowe, a zdarzenie, które serwer wykonuje bez sprawdzenia, jest otwartymi drzwiami: kto wyśle z klienta TriggerServerEvent z dowolnymi wartościami, może wygenerować dolary, spawnować konie albo w pętli wywoływać zapytania do bazy, aż serwer stanie. Dotyczy to w równym stopniu wszystkich trzech rozpowszechnionych frameworków: VORP Core, który od 2020 roku ma największą bazę skryptów, RSGCore oraz starszego RedEM:RP.

Szczególnie podatne są zasoby inwentarza i postaci, bo przy każdym wywołaniu zapisują do bazy danych. Pętla zdarzeń, która dziesięć razy na sekundę zapisuje stan inwentarza, obciąża serwer RedM mocniej niż niejedna powódź pakietów, a przychodzi od środka, gdzie żaden firewall nie działa.

Trzy zasady wyłapują większość takich przypadków. Rejestruj przez RegisterNetEvent wyłącznie te zdarzenia, które naprawdę mają przychodzić od klienta. Nigdy nie polegaj na wartościach przysyłanych przez klienta, tylko ustalaj gracza po stronie serwera z source. I ogranicz, jak często gracz może wywołać to samo zdarzenie, zwłaszcza przy wszystkim, co odpytuje bazę. Jeśli serwer się tnie, a łącze jest spokojne, resmon 1 w konsoli klienta pokaże czas procesora na każdy zasób, a winowajca stoi zwykle na samej górze.

9. Zbieraj pomiary, zanim będą ci potrzebne

Najważniejszy krok to ten, którego prawie nikt nie robi wcześniej: przygotuj bazę porównawczą, dopóki wszystko działa normalnie. Bez wartości normalnej po incydencie nie powiesz, czy 40 000 pakietów na sekundę to dużo, czy po prostu dobrze obsadzony wtorkowy wieczór. Po apt-get install -y vnstat sysstat pomiar chodzi na stałe w tle. W trakcie incydentu wystarczą cztery polecenia: liczba pakietów na sekundę, liczba odrzuconych pakietów na interfejsie, komunikaty kernela oraz krótka próbka ruchu.

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 port 30120 -c 200 -q

Przy tcpdump obowiązuje zasada: zawsze ograniczaj przez -c, bo zrzut przy pełnym obciążeniu dodatkowo obciąża i tak przeciążony serwer. Zwróć poza tym uwagę, czy obciążenie leży na części UDP, czy na części TCP portu 30120. Obciążenie UDP wskazuje na powódź pakietów wymierzoną w ruch gry, obciążenie TCP na flood przeciw punktom końcowym HTTP, a jedno i drugie wymaga innych środków zaradczych. Jak odczytać te wartości, opisuje wpis Jak rozpoznać atak DDoS.

Gdzie te działania się kończą

Teraz część, której nie rozwiąże żaden plik server.cfg. Wszystkie dotychczasowe działania dzieją się na twoim serwerze, czyli na końcu łącza. Reguła firewalla decyduje o pakiecie, który już przeszedł przez kabel. Możesz go odrzucić, ale nie możesz sprawić, żeby nie został wysłany.

Policz to razem ze mną. Typowy serwer gier wisi na 1 Gbit/s, czyli 125 megabajtach na sekundę, a łącze jest pełne, gdy tylko ktoś wyśle więcej. Ataki na projekty roleplay mieszczą się zwykle między 5 a 50 Gbit/s, czyli od pięciu do pięćdziesięciu razy powyżej pojemności twojego łącza. To, czy twoja reguła iptables za tym łączem jest dobra, nie ma już wtedy znaczenia, bo pakiety twoich graczy nie przechodzą już wcześniej.

Druga wielkość to liczba pakietów na sekundę i uderza ona często wcześniej niż przepustowość. Przy małych pakietach po 64 bajty w łącze 1 Gbit/s mieści się około 1,49 miliona pakietów na sekundę. Zwykły kernel serwera przetworzy z tego, zależnie od CPU i karty sieciowej, kilkaset tysięcy, zanim zacznie odrzucać. Atak, który nie zapełnia twojego łącza nawet w jednej trzeciej, może więc mimo wszystko położyć twój serwer RedM, bo cały czas procesora idzie na odrzucanie. Operatorzy przeżywają to jako „przecież obciążenie wcale nie było wysokie, a i tak wszystko padło”. Dokładnie te skoki lagów bez widocznego obciążenia serwera są typowym obrazem ataku na liczbę pakietów.

Dla porządku wielkości, które zdarzają się naprawdę: na serwerach KernelHost odfiltrowano między innymi atak o wolumenie ponad 473,4 Gbit/s przy ponad 41,5 miliona pakietów na sekundę wymierzony w serwer głosowy oraz flood UDP o wolumenie ponad 112,2 Gbit/s w serwer gier. Na to nie ma żadnego ustawienia lokalnego. Ataki wolumetryczne muszą kończyć się w sieci przed serwerem.

Co w RedM jest inne niż w FiveM

Krótka odpowiedź: technika sieciowa jest identyczna, otoczenie nie. Oba działają na tym samym FXServerze, oba korzystają z 30120 TCP i UDP, oba zarządzane są przez txAdmin na 40120. Wszystko, co czytasz wyżej o portach, limitach i punktach końcowych, dotyczy obu. Różne są warunki brzegowe i to właśnie one decydują, jak szybko atak zadziała:

Trzy punkty z tej tabeli są decydujące dla obrony. Po pierwsze mniejsza scena czyni każdy pojedynczy serwer RedM cenniejszym celem, bo awaria dotyka większej części graczy. Po drugie standardowa granica 32 slotów obniża próg, od którego flood dołączania zamyka serwer. I po trzecie dla RedM znajdziesz w sieci mniej gotowych przepisów na ochronę niż dla FiveM, przez co wiele projektów działa na niezmienionej konfiguracji standardowej. Obrona jest ta sama, stan wyjściowy gorszy.

Co przeciwstawia temu KernelHost

Stała ochrona wliczona w każdy serwer

Ochrona DDoS w KernelHoście jest zbudowana dwuwarstwowo i stale aktywna, bez konieczności włączania, zamawiania czy konfigurowania czegokolwiek:

• Warstwa 1: 17 Tbps pojemności mitygacji w globalnej sieci scrubbing. Ataki wolumetryczne są oczyszczane blisko źródła, zanim dotrą do centrum danych.
• Warstwa 2: filtrowanie Arbor w czasie rzeczywistym o wydajności 3,2 Tbps we Frankfurcie nad Menem. Bezpośrednio przed serwerem rozpoznawane i odrzucane są wzorce specyficzne dla protokołów, pakiet po pakiecie.

Decydujące są dwie cechy. Ochrona działa nieprzerwanie i nie musi dopiero reagować na atak, nie ma więc kilku minut na starcie, w których serwer RedM znika. I nie stosuje się null-routingu: twój adres IP zostaje w sieci, odrzucane są wyłącznie szkodliwe pakiety. Kto zdejmuje adres IP z sieci, osiąga dla ciebie ten sam efekt co atakujący. Lokalizacją filtrowania jest Frankfurt nad Menem. Które gry i protokoły są objęte ochroną, wylicza wpis Ochrona DDoS serwerów gier w czasie rzeczywistym.

Advanced DDoS Protection dla projektów pod stałym ostrzałem

Niektóre projekty są atakowane nie okazjonalnie, tylko celowo i przez wiele tygodni. Dla nich jest Advanced DDoS Protection od 50,00 € miesięcznie, w modelu PrePaid i bez minimalnego okresu umowy. Różnica nie polega na większej pojemności, tylko na kontroli:

• Dedykowany chroniony adres IP z frankfurckiego rdzenia sieci, na który twój serwer zostaje przełączony w naszej sieci. Po twojej stronie nie trzeba niczego przebudowywać.
• Samodzielnie zarządzane reguły ochrony na port i protokół w panelu klienta: osobno ustawiasz, co jest dozwolone na 30120 UDP, a co na 30120 TCP, bez pisania zgłoszenia. Właśnie przy RedM ten podział jest użyteczny, bo ruch gry i punkty końcowe HTTP leżą na tym samym numerze portu i mają zupełnie inne wzorce.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku.
• Profil ochrony dopasowany do aplikacji. Dla serwerów Cfx.re na 30120 istnieje odpowiedni profil, tak samo dla zmodyfikowanych i własnych aplikacji na dowolnych portach TCP albo UDP.

Jedno i drugie dotyczy serwerów stojących w KernelHoście. Jeśli twój projekt RedM działa obecnie gdzie indziej i regularnie jest zestrzeliwany z sieci, zaleceniem jest przeprowadzka, a nie dodatkowy produkt.

Porównanie obu stopni

Dla większości projektów RedM wystarczy wliczona stała ochrona razem z czystą konfiguracją serwera. Advanced DDoS Protection jest odpowiedzią na sytuację, w której ktoś bierze to do siebie osobiście.

Typowe błędy i ich rozwiązania

„Mój serwer nie pojawia się na liście serwerów RedM, podejrzewam atak”: sprawdź najpierw konfigurację. Gdy brakuje set gamename rdr3, FXServer zgłasza się jako serwer GTA V i nie pojawia się na liście RedM. Gdy brakuje klucza licencyjnego z portal.cfx.re albo jest on nieprawidłowy, wpis również nie powstaje. Atak wygląda inaczej: wpis pozostaje, a połączenie się nie udaje.

„Setki graczy dostają błąd przy dołączaniu, to wygląda jak flood”: zwykle jest to problem z wersją gry. Gdy sv_enforceGameBuild nie pasuje do tego, czego oczekują twoje zasoby, klient zgłasza „server specified an invalid game enforcement”. Ustaw wartość, której wymaga twój framework, zwykle 1436 albo 1491, i zrestartuj serwer w całości.

„Zmieniłem adres IP i dwie godziny później znowu byłem offline”: atakujący zdobył nowy adres z tego samego źródła co stary, zwykle z wpisu na liście, z bota Discord albo ze starego wpisu DNS. Zmiana adresu to zysk na czasie, a nie rozwiązanie.

„Moje reguły iptables nie działają”: częste są trzy przyczyny. Reguły stoją za łańcuchami UFW i nigdy nie zostają osiągnięte, zniknęły po ostatnim restarcie (wtedy pomogą netfilter-persistent save albo wpis w /etc/ufw/before.rules) albo atak jest wolumetryczny, a reguła pracuje poprawnie na łączu, które jest już pełne. Sprawdź przez iptables -L INPUT -n -v, czy liczniki trafień rosną. Jeśli stoją na zerze, reguła nie jest osiągana.

„Serwer działa, ale wszyscy gracze mają efekt gumki”: to częściej skrypt niż atak. Sprawdź najpierw przez resmon 1, czy jakiś zasób nie zjada czasu procesora, i przyjrzyj się zasobom inwentarza oraz postaci w swoim frameworku. Jeśli sar -n DEV 1 10 nie pokazuje nic nietypowego, to nie był atak DDoS.

„txAdmin pokazuje setki nieudanych prób połączenia”: to flood dołączania i uderza w logikę gry, a nie w łącze. Pomagają na to whitelista, weryfikacja konta przez sv_authMinTrust oraz limit połączeń na adres źródłowy.

„Mój dotychczasowy dostawca zablokował mój adres IP”: to null-routing. Dostawca chroni w ten sposób własną sieć, a dla ciebie wynik jest identyczny z udanym atakiem, zwykle jeszcze przez wiele godzin po nim. W razie wątpliwości zapytaj, czy ruch jest filtrowany, czy null-routowany. Ta odpowiedź decyduje o twojej dostępności bardziej niż jakakolwiek specyfikacja sprzętu.

„W tcpdump nie widzę nic nietypowego”: jeśli ruch jest filtrowany już w sieci przed serwerem, to zgodnie z oczekiwaniem nic na serwer nie dociera. To normalny stan przy działającym filtrowaniu. Odwrotnie też jest prawdą: gdy łącze jest wysycone, może cię nie dosięgnąć nawet sesja SSH, którą chciałeś użyć do pomiaru. Skorzystaj wtedy z konsoli VNC w panelu klienta, która działa niezależnie od sieci systemu gościa.

Krótkie podsumowanie

• Serwer RedM potrzebuje dokładnie dwóch otwartych portów: 30120 TCP i 30120 UDP, ustawionych przez endpoint_add_tcp oraz endpoint_add_udp. Własnego portu zapytań ani portu RCON nie ma.
• txAdmin na 40120 TCP oraz baza danych na 3306 TCP nie należą do otwartej sieci, tylko odpowiednio do twojego własnego adresu i do 127.0.0.1.
• sv_endpointPrivacy true usuwa adresy IP graczy z publicznych wyników, a buforowany status serwera zdejmuje obciążenie z /players.json, czyli z udokumentowanej drogi ataku w warstwie 7 przeciwko serwerom Cfx.re.
• Serwer RedM ma bez OneSync 32 sloty, z OneSync 48, a z Element Club do 1024. Im mniejsza liczba slotów, tym tańszy jest flood dołączania i tym ważniejsze są whitelista oraz weryfikacja konta.
• RedM i FiveM działają na tym samym FXServerze, odróżnione wyłącznie przez set gamename rdr3. Obrona sieciowa jest przez to identyczna, otoczenie nie: około 2000 serwerów RedM wobec około 39 000 serwerów FiveM czyni każdy pojedynczy projekt RedM cenniejszym celem.
• Lokalne reguły firewalla kończą się tam, gdzie łącze jest pełne: 1 Gbit/s to 125 megabajtów na sekundę, a przy pakietach po 64 bajty mieści się w nim około 1,49 miliona pakietów na sekundę. Wszystko powyżej musi kończyć się w sieci przed serwerem.
• W KernelHoście dwuwarstwowa stała ochrona jest zawarta w każdym pakiecie serwerowym, działa od momentu udostępnienia i obywa się bez null-routingu. Kto chce sam sterować filtrowaniem, dostaje z Advanced DDoS Protection od 50,00 € miesięcznie dedykowany chroniony adres IP oraz własne reguły na port i protokół.

Jeśli twój projekt RedM działa już w KernelHoście, filtrowanie jest aktywne i nie musisz nic robić. Gdybyś mimo to zauważył coś nietypowego, załóż zgłoszenie wsparcia, żeby reguły filtrowania dla twojego adresu IP zostały skorygowane. Przy trwającym ataku dotrzesz do nas dodatkowo przez awaryjny czat WhatsApp pod numerem +43 650 8209883.