Ochrona serwera MTA:SA przed atakami DDoS

Serwer Multi Theft Auto: San Andreas zachowuje się pod atakiem DDoS inaczej niż każdy inny projekt multiplayer w GTA, bo oferuje jednocześnie trzy oddzielne usługi sieciowe: ruch gry na 22003 UDP, pełnoprawny serwer HTTP na 22005 TCP oraz zapytanie ASE na 22126 UDP. Każdą z tych trzech usług da się zaatakować osobno i każda pada inaczej. Ten artykuł pokazuje najpierw, co możesz zabezpieczyć sam i bez dodatkowych kosztów, potem, gdzie te działania kończą się na fizyce łącza, a na koniec, co skuteczna ochrona DDoS dla MTA:SA musi zrobić w sieci przed serwerem.

Jeśli atak trwa właśnie teraz, najważniejsze pytanie brzmi, która z tych trzech usług została trafiona. Jeśli gracze zostają połączeni, ale przy dołączaniu przestają ładować zasoby, obrywa serwer HTTP na 22005. Jeśli serwer znika z przeglądarki, podczas gdy połączeni gracze grają dalej normalnie, obrywa zapytanie ASE na 22126. Jeśli wszystkie połączenia zrywają się jednocześnie, celem jest albo 22003, albo łącze jest pełne. Wszystkie informacje dotyczą serwera MTA 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.

Dlaczego serwery MTA:SA tak często stają się celem ataków DDoS

Projekty MTA:SA są wygodnymi celami, bo muszą same publikować swój adres. Serwer pojawia się w przeglądarce gry tylko wtedy, gdy zgłosi się do listy masterserwerów i następnie odpowiada na zapytania z zewnątrz. Lista zawiera adres IP i port otwartym tekstem, wcześniejszy rekonesans jest więc dla atakującego zbędny.

Do tego dochodzi sama scena. Niemieckojęzyczne i brazylijskie serwery roleplay, serwery driftu oraz konwersje DayZ konkurują o tę samą publiczność, a awaria w głównych godzinach gry jest widoczna maksymalnie. Zbanowany gracz, skłócony zespół albo konkurencyjny projekt nie potrzebuje ani umiejętności, ani liczących się pieniędzy, żeby zepsuć cały wieczór. Usługi ataku na zamówienie, w tej scenie nazywane booterami albo stresserami, sprzedają za kilka euro miesięcznie dokładnie dwa wyniki: zdjęcie serwera MTA z sieci na kilka minut albo doprowadzenie go szczytami opóźnień do stanu niegrywalnego. Czym atak DDoS jest technicznie i jakie są jego rodzaje, wyjaśnia wpis Czym jest atak DDoS?.

Technicznie MTA:SA ułatwia atakującym zadanie w dwóch miejscach bardziej niż inne modyfikacje multiplayer. Po pierwsze zapytanie leży na własnym porcie UDP, który na jeden jedyny bajt odsyła odpowiedź o wielkości kilku kilobajtów. Po drugie do każdego serwera MTA należy serwer HTTP, który wydaje pliki klienckie wszystkich zasobów, i to bez logowania każdemu, kto o nie poprosi.

Porty, o które naprawdę chodzi

Serwer MTA:SA potrzebuje dokładnie trzech portów: 22003 UDP dla gry, 22005 TCP dla wewnętrznego serwera HTTP oraz 22126 UDP dla zapytania ASE. Trzeci port nie jest dowolnie wybieranym ustawieniem, tylko wynika na sztywno z portu gry plus 123. Kto ustawi serverport na 22010, dostanie zapytanie na 22133.

Dwie subtelności stoją tak w dostarczonym pliku mtaserver.conf i są regularnie przeoczane. httpport może mieć tę samą wartość liczbową co serverport, bo jeden port jest po TCP, a drugi po UDP. Natomiast serverip stoi na auto i tam powinien zostać: na sztywno wpisana wartość wiąże socket ASE dokładnie z tym adresem i łamie wpis na liście, gdy tylko adres się zmieni.

Protokół zapytań ASE i dlaczego jest wzmacniaczem

ASE (All-Seeing Eye) to czyste protokół zapytań po UDP: pierwszy bajt pakietu decyduje o odpowiedzi, nawiązywania połączenia nie ma w ogóle. Serwer MTA zna pięć zapytań i odpowiada na nie na 22126:

• s to pełne zapytanie ASE. Odpowiedź zaczyna się od EYE1 i zawiera nazwę serwera, typ gry, nazwę mapy, wersję, status hasła, liczbę graczy, pełną listę wszystkich reguł ustawionych przez setRuleValue, a potem każdego połączonego gracza z nazwą, punktacją i pingiem. Ta odpowiedź nie ma żadnego ograniczenia wielkości.
• b i r to szczuplejsze zapytania dla przeglądarki gry. Odpowiedź zaczyna się od EYE2 i jest w kodzie źródłowym ucinana na 1340 bajtach, żeby uniknąć fragmentacji.
• x dostarcza skrócony komunikat o stanie, v tylko identyfikator wersji ASE.

Wynika z tego problem. Zapytanie składa się z jednego jedynego bajtu danych, czyli na łączu z 29 bajtów (20 bajtów nagłówka IP, 8 bajtów nagłówka UDP, 1 bajt danych). Odpowiedź o wielkości 1400 bajtów danych to na łączu 1428 bajtów. Stosunek wynosi około 49 razy więcej, a ponieważ UDP nie zna nawiązywania połączenia, adres nadawcy da się podrobić. Atakujący może więc wykorzystać twój serwer jako wzmacniacz przeciw trzeciemu celowi, nigdy nie wchodząc do twojej gry. Przy pełnym zapytaniu współczynnik rośnie wraz z liczbą graczy i z każdą regułą, którą ustawia twój tryb gry.

MTA ma przeciwko temu dwa wbudowane hamulce, które warto znać, bo tłumaczą, dlaczego niektóre floody działają, a inne nie. Serwer odpowiada na najwyżej pięć zapytań z jednego adresu źródłowego w ciągu sześciu sekund, a potem ignoruje ten adres przez siedem sekund. Poza tym trzyma odpowiedzi w pamięci podręcznej przez dziesięć sekund, zamiast składać je na nowo przy każdym zapytaniu. Zliczanie na adres źródłowy jest jednak całkowicie pomijane, gdy tylko na liście stoi jednocześnie więcej niż 100 różnych adresów nadawcy. Dokładnie tak jest w normalnym przypadku przy floodzie rozproszonym z botnetu albo z podrobionymi nadawcami, i dlatego wbudowany hamulec nie pomaga przeciw poważnemu atakowi.

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

Ten rozdział jest najdłuższy i to celowo. Czysto skonfigurowany serwer MTA wytrzyma małe i średnie ataki o własnych siłach, niezależnie od tego, u kogo stoi.

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

Sprawdź najpierw, co twój serwer wystawia na zewnątrz. Nie zgaduj, sprawdź:

ss -lntup

Spodziewane są trzy wiersze procesu MTA: 0.0.0.0:22003 po UDP, 0.0.0.0:22005 po TCP oraz 0.0.0.0:22126 po UDP. Jeśli pojawia się tam dodatkowo baza danych na 0.0.0.0:3306, serwer WWW albo zapomniana usługa głosowa, to należy to wyłączyć. Spojrzenie oczami atakującego daje skan portów z zewnątrz:

nmap -Pn -sU -p 22003,22126 TWOJ.ADRES.IP.SERWERA
nmap -Pn -p 22005 TWOJ.ADRES.IP.SERWERA

Serwer ma do tego także własne polecenie konsolowe. W konsoli serwera openports sprawdza, czy wszystkie trzy porty są osiągalne z zewnątrz.

2. Zostaw otwarte tylko te trzy porty, których MTA naprawdę potrzebuje

W UFW nośna konfiguracja wyjściowa wygląda tak, dokładnie w tej kolejności, żebyś nie zamknął dostępu samemu sobie:

ufw allow 22/tcp comment 'SSH'
ufw allow 22003/udp comment 'MTA gra'
ufw allow 22005/tcp comment 'MTA HTTP'
ufw allow 22126/udp comment 'MTA ASE'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Pełna instrukcja razem z drogą ratunkową stoi we wpisie Konfiguracja firewalla UFW. Przy serwerach root KVM i serwerach dedykowanych od KernelHost w razie potrzeby dostaniesz się do systemu przez konsolę VNC w panelu klienta, nawet gdy łącze jest wysycone.

Baza danych nie należy do otwartej sieci. Jeśli ss -lntp | grep 3306 pokazuje 0.0.0.0:3306, ustaw w /etc/mysql/mariadb.conf.d/50-server.cnf wiersz bind-address = 127.0.0.1 i zrestartuj usługę.

3. Ogranicz port ASE, nie wypadając z listy serwerów

W odróżnieniu od SA-MP zapytanie leży w MTA:SA na własnym porcie, możesz je więc ograniczyć niezależnie od rozgrywki. To największa praktyczna zaleta tej architektury: reguła na 22126 nie wyrzuca ani jednego gracza.

Z nftables we własnej tabeli, żeby zestaw reguł nie wszedł w drogę UFW:

nft add table inet mtaguard
nft add chain inet mtaguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet mtaguard input udp dport 22126 meter aseperip '{ ip saddr limit rate over 3/second burst 6 packets }' drop
nft add rule inet mtaguard input udp dport 22126 limit rate over 2000/second burst 500 packets drop
nft list table inet mtaguard

Pierwsza reguła ogranicza każdy pojedynczy adres źródłowy, druga cały port. Obie razem są ważne: flood rozproszony przeciska się przez lukę między wieloma pojedynczymi źródłami, jeśli ograniczasz tylko na adres. Wartości są dobrane ciasno i tutaj jest to do obrony, bo prawdziwa przeglądarka serwerów odpytuje twój serwer tylko co kilka sekund. W iptables to samo osiąga moduł hashlimit:

iptables -A INPUT -p udp --dport 22126 -m hashlimit --hashlimit-name mta_ase \
  --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 6 \
  --hashlimit-htable-expire 30000 -j DROP

Próba zamknięcia portu w całości to kompromis, a nie tajna sztuczka: bez ASE twój serwer znika z przeglądarki gry, a tym samym z organicznego napływu graczy. Jeśli mimo to chcesz to zrobić, <ase>0</ase> nie wystarczy. W kodzie źródłowym otwarcie portu wisi na alternatywie trybu internetowego i trybu LAN, socket pozostaje więc przy <ase>0</ase> nadal otwarty, dopóki stoi <donotbroadcastlan>0</donotbroadcastlan>. Kto naprawdę chce zamknąć ten port, ustawia oba:

<ase>0</ase>
<donotbroadcastlan>1</donotbroadcastlan>

Uczciwsza droga dla rosnącego projektu brzmi: zostaw port otwarty, ogranicz liczbę pakietów i trzymaj efekt wzmocnienia mały przez to, że twój tryb gry nie publikuje zbędnych reguł przez setRuleValue. Każda reguła stoi w pełnym zapytaniu i powiększa odpowiedź.

4. Odciąż wewnętrzny serwer HTTP

Serwer HTTP na 22005 jest w MTA:SA osobną powierzchnią ataku, bo każdy dołączający gracz pobiera tam wszystkie pliki klienckie wszystkich działających zasobów. Przy projekcie roleplay z własnymi modelami to szybko kilkaset megabajtów rozłożonych na setki pojedynczych plików. Wbudowany serwer jest celowo prosty: żadnej kompresji, stały przydział wątków roboczych. Kilkadziesiąt jednoczesnych pobrań wystarczy, żeby prawdziwi gracze wisieli w ekranie ładowania całymi minutami.

Najskuteczniejszym środkiem jest wyjęcie pobierania z serwera gry w całości. MTA samo przygotowuje do tego pliki do wydania, w katalogu mods/deathmatch/resource-cache/http-client-files. Ten katalog wydajesz przez nginx albo lighttpd i wpisujesz adres do pliku mtaserver.conf:

<httpdownloadurl>http://cdn.twoja-domena.tld/mta</httpdownloadurl>

To daje dwie rzeczy naraz. Pobieranie idzie przez serwer WWW, który jest do tego zbudowany, i nie idzie już przez adres twojego serwera gry. Jeśli serwer WWW leży na innej maszynie albo za siecią dostarczania treści, flood przeciw pobieraniu nie trafia już w rozgrywkę. Ważne: jeśli zewnętrzny adres jest błędny albo nieosiągalny, MTA po cichu przełącza się z powrotem na serwer wewnętrzny.

Jeśli serwer wewnętrzny zostaje w użyciu, wykorzystaj jego własne limity. W pliku mtaserver.conf:

<httpmaxconnectionsperclient>5</httpmaxconnectionsperclient>
<httpdosthreshold>20</httpdosthreshold>
<http_dos_exclude></http_dos_exclude>
<httpthreadcount>8</httpthreadcount>

httpmaxconnectionsperclient ogranicza jednoczesne połączenia na klienta do 5 w dozwolonym zakresie od 1 do 8. httpdosthreshold ogranicza, ile połączeń może zbudować pojedynczy adres IP w krótkim czasie, wartość domyślna 20. http_dos_exclude wyłącza z tego pojedyncze adresy, na przykład twoją własną stronę statusu. httpthreadcount określa liczbę wątków roboczych, wartość domyślna 8 w zakresie od 1 do 20. Wyższa wartość pomaga przy wielu małych plikach, ale kosztuje czas procesora, którego brakuje rozgrywce.

Pomyśl poza tym o tym, co jeszcze jest wydawane na tym samym porcie. Zasoby webadmin i resourcebrowser są w dostarczonej konfiguracji uruchomione i osiągalne w przeglądarce przez 22005. Interfejs administracyjny nie należy niezabezpieczony do otwartej sieci: nadaj w acl.xml czyste uprawnienia, załóż osobne konto z długim losowym hasłem i zatrzymaj ten zasób, jeśli go nie potrzebujesz.

5. Wykorzystaj wbudowane limity w mtaserver.conf

MTA ma więcej limitów ochronnych, niż wykorzystuje większość projektów. Część z nich stoi na sztywno w kodzie źródłowym, część w pliku mtaserver.conf. Ta tabela zbiera te, które odgrywają rolę przy ataku:

Trzy ustawienia zasługują na świadomą decyzję. maxplayers stoi na 32 i powinno odpowiadać rzeczywistości: każdy dodatkowy slot powiększa pełne zapytanie i podnosi liczbę połączeń, które atakujący może zająć. bandwidth_reduction stoi na medium, a wartość maximum obniża obciążenie wychodzące odczuwalnie, kosztuje jednak dokładność synchronizacji. Natomiast <password></password> zmienia twój serwer bez wysiłku w zamknięte grono, podczas gdy wpis na liście pozostaje: to najszybszy hamulec bezpieczeństwa przy trwającym floodzie połączeń.

6. Odróżniaj floody połączeń od floodów zdarzeń

Dwa wzorce ataku celują nie w łącze, tylko w logikę gry, i regularnie się je myli.

Flood połączeń buduje w szybkim tempie prawdziwe połączenia, aż wszystkie sloty są zajęte albo serwer nie nadąża z ich zestawianiem. MTA ogranicza to samo z siebie do czterech połączeń na adres źródłowy w ciągu 30 sekund i ignoruje potem ten adres przez 30 sekund. Co ten hamulec właśnie robi, pokazuje polecenie konsolowe debugjoinflood. Limit działa na adres, więc botnet z tysiącem adresów przechodzi obok niego. Pomagają na to hasło serwera, whitelista w trybie gry oraz ograniczenie liczby pakietów na 22003.

Flood zdarzeń przychodzi natomiast od już połączonych graczy: zmanipulowany klient wysyła triggerServerEvent w pętli, aż serwerowi brakuje czasu procesora. MTA pozwala na to fabrycznie na 100 zdarzeń na gracza i sekundę, a powyżej tego rzuca komunikatem o floodach zdarzeń. Jeśli twój tryb gry korzysta z wielu małych zdarzeń, sprawdź tę wartość, zanim ją obniżysz: ustawiona zbyt ciasno wyrzuca własnych graczy.

Niezależnie od tego po stronie serwera obowiązuje ta sama zasada co wszędzie: nigdy nie polegaj na wartościach, które przysyła klient, ustalaj gracza z nadawcy zdarzenia i ograniczaj wszystko, co wywołuje zapytanie do bazy danych. Jedno niesprawdzone zdarzenie, które uruchamia zapytanie, wystarczy, żeby zatrzymać serwer bez żadnego ataku sieciowego.

7. Lista serwerów, adres IP i co jeszcze go zdradza

Twojego adresu IP nie da się utrzymać w tajemnicy. Zna go każdy gracz, który choć raz był połączony, a wpis na liście masterserwerów i tak go publikuje. Domena przed nim nie pomaga: klient rozwiązuje nazwę raz i potem rozmawia bezpośrednio z adresem.

Sprawdź zamiast tego, co jeszcze zdradza twój adres. Typowe wycieki przy projektach MTA to stare wpisy A i AAAA w DNS, strona projektu na tej samej maszynie, bot Discorda ze statusem, który publicznie odczytuje zapytanie ASE, certyfikaty TLS ze starymi nazwami hostów oraz wpisy na forum z początków projektu. Wynika z tego zasada, której wiele projektów uczy się za późno: jeśli przenosisz się na chroniony adres, zmień jednocześnie stary adres. Jeśli zostanie, stoi w każdej bazie skanera, a atak przechodzi obok ochrony.

Dwa wpisy w pliku mtaserver.conf dotyczą widoczności bezpośrednio. <serverip>auto</serverip> zostaje na auto, chyba że dokładnie wiesz, dlaczego nie. A <owner_email_address> należy wypełnić: brak wpisu albo błędny wpis może pogorszyć widoczność na liście masterserwerów.

8. Zapisuj logi, żeby w razie ataku mieć dane

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 piątkowy wieczór. Po apt-get install -y vnstat sysstat pomiar chodzi na stałe w tle.

W trakcie incydentu oddziel najpierw te trzy porty od siebie. Wystarczą cztery polecenia:

sar -n DEV 1 10
nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
tcpdump -ni eth0 -c 200 -q 'udp port 22126'
ss -tn state established '( dport = :22005 or sport = :22005 )' | wc -l

Odczyt jest prostszy, niż wygląda. Jeśli błędy buforów rosną przy niskim obciążeniu procesora, dociera do ciebie więcej ruchu, niż proces jest w stanie obrobić. Jeśli jeden rdzeń pracuje na maksa, podczas gdy ruch wygląda normalnie, problem leży w trybie gry, a nie w sieci. Jeśli zrzut na 22126 pokazuje wiele pakietów z jednym jedynym bajtem danych, to jest flood ASE. Jeśli liczba otwartych połączeń na 22005 stoi trwale w zakresie czterocyfrowym, obrywa serwer HTTP. Przy tcpdump obowiązuje zawsze: ograniczaj przez -c, bo zrzut przy pełnym obciążeniu dodatkowo obciąża i tak przeciążony serwer. Jak odczytać te wartości w szczegółach, opisuje wpis Jak rozpoznać atak DDoS na serwerze.

Sam log serwera leży w logs/server.log, log skryptów w logs/scripts.log. Obie ścieżki stoją w pliku mtaserver.conf i da się je przenieść.

Gdzie te działania się kończą

Teraz część, której nie rozwiąże żaden plik konfiguracyjny. 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, co odpowiada 125 megabajtom na sekundę, a przy pakietach po 64 bajty około 1,49 miliona pakietów na sekundę. Ataki przeciw projektom serwerowym tej wielkości leżą zwykle między 5 a 50 Gbit/s, czyli od pięciu do pięćdziesięciu razy powyżej twojego łącza. To, czy twoja reguła nftables za tym łączem jest dobra, nie ma już wtedy znaczenia, bo pakiety twoich graczy nie przechodzą już wcześniej.

Liczba pakietów uderza przy tym często wcześniej niż przepustowość. Zwykły kernel serwera przetworzy, zależnie od procesora i karty sieciowej, kilkaset tysięcy pakietów na sekundę, zanim zacznie odrzucać. Atak, który nie zapełnia twojego łącza nawet w jednej trzeciej, może więc położyć twój serwer, 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”.

W MTA:SA dochodzi trzecia granica i działa ona najwcześniej. Serwer czyta porty sieciowe w jednym jedynym przebiegu roboczym. Flood zapytań na 22126 zajmuje ten przebieg tak mocno, że pakiety synchronizacji prawdziwych graczy przepadają w buforze odbiorczym na długo przed wysyceniem łącza. Proces przy tym się nie wywraca, robi się tylko wolny, a gracze widzą efekty gumki. To samo dotyczy serwera HTTP: dzieli on czas procesora z rozgrywką.

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 przy ponad 8,7 miliona pakietów na sekundę w serwer gier. Pierwszy przypadek to około 473 razy więcej niż przepustowość i mniej więcej 28 razy więcej niż liczba pakietów, którą łącze 1 Gbit/s jest w ogóle w stanie przyjąć. Na to nie ma żadnego ustawienia lokalnego. Ataki wolumetryczne muszą kończyć się w sieci przed serwerem.

Co przeciwstawia temu KernelHost

Stała ochrona wliczona w każdy serwer

Każdy serwer w KernelHoście stoi za stale aktywnym, dwuwarstwowym filtrowaniem:

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

Decydujące są trzy cechy. Ochrona jest stale aktywna, nie ma więc fazy wykrywania, w której twój serwer przechodzi w offline. Nie stosuje się żadnego null-routingu: atakowany adres zostaje w sieci, odrzucane są wyłącznie szkodliwe pakiety, podczas gdy połączenia prawdziwych graczy działają dalej. I nie kosztuje nic dodatkowo, tylko jest od momentu udostępnienia zawarta w każdym pakiecie serwerowym, od serwera root KVM przez serwer gier aż po serwer dedykowany. Filtrowanie odbywa się na warstwach 3, 4 i 7 na każdym porcie TCP albo UDP, czyli na 22003 UDP, 22005 TCP i 22126 UDP jednocześnie. Prowadzone jest to w centrum danych maincubes we Frankfurcie nad Menem w Niemczech. Które gry i protokoły mają własne profile, pokazuje wpis Ochrona DDoS serwerów gier w czasie rzeczywistym.

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

Niektóre projekty są trafiane nie okazjonalnie, tylko celowo przez wiele tygodni. Na ten przypadek 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. Twój serwer zostaje na niego przełączony wewnątrz sieci KernelHost, po twojej stronie nic nie przebudowujesz.
• Samodzielnie zarządzane reguły ochrony na port i protokół w panelu klienta. Dokładnie o to chodzi przy MTA:SA: ustawiasz osobne reguły dla 22003 UDP, 22005 TCP i 22126 UDP, zamiast mierzyć trzy bardzo różne usługi tą samą miarą.
• Zmiany działają w czasie rzeczywistym, bez zgłoszenia i bez czekania. Możesz więc korygować ustawienia w środku trwającego ataku.
• Profil ochrony dopasowany do gry. Multi Theft Auto jest dostępne jako własny profil, tak samo serwery WWW, serwery głosowe oraz własne aplikacje TCP albo UDP, które mieszczą się za tym samym chronionym adresem.

Porównanie obu wariantów

Dla większości projektów MTA:SA 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

„Zablokowałem 22126, serwera i tak nie ma na żadnej liście, ale zapytania nadal przychodzą”: wtedy socket jest nadal otwarty. Samo <ase>0</ase> nie zamyka portu, dopóki ustawione jest <donotbroadcastlan>0</donotbroadcastlan>. Sprawdź przez ss -lnup | grep 22126, czy naprawdę nic już nie nasłuchuje.

„Gracze wiszą w ekranie ładowania, sama gra działa normalnie”: to nie jest atak na 22003, tylko serwer HTTP na 22005 na granicy możliwości. Wynieś pobieranie przez httpdownloadurl i sprawdź httpmaxconnectionsperclient oraz httpthreadcount.

„Serwer zniknął z przeglądarki, a gracze na nim nic nie zauważają”: wtedy obrywa wyłącznie 22126. Dla połączonych graczy jest to bez skutków, dla napływu nowych graczy już nie. Właściwą odpowiedzią jest ograniczenie liczby pakietów na tym jednym porcie, a nie na porcie gry.

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

„Ustawiliśmy limit 20 pakietów na sekundę na adres na 22003”: to zbyt ciasno. Już pojedynczy gracz leży przy aktywnej synchronizacji powyżej tego, a kilku graczy za tym samym adresem NAT dzieli ten sam przydział. Wyrzucasz w ten sposób własnych graczy. Na 22126 ciasne wartości są natomiast bezproblemowe.

„Zamknęliśmy sobie dostęp firewallem”: restart nie pomoże, bo UFW przy starcie odtwarza swoje reguły. W KernelHoście otwierasz konsolę VNC w panelu klienta i wykonujesz tam ufw disable. Konsola VNC pracuje niezależnie od sieci systemu gościa.

„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.

„Po prostu przeczekamy atak”: ataki, które działają, są powtarzane. Dokumentuj moment razem ze strefą czasową, czas trwania, wartości szczytowe oraz port, którego to dotyczyło. Dokładnie tych danych potrzebuje także zgłoszenie wsparcia, żeby filtrowanie zostało celowo dociągnięte.

Krótkie podsumowanie

• Serwer MTA:SA potrzebuje dokładnie trzech portów: 22003 UDP dla gry, 22005 TCP dla wewnętrznego serwera HTTP oraz 22126 UDP dla zapytania ASE. Trzeci wynika na sztywno z portu gry plus 123.
• Zapytanie ASE leży na własnym porcie i dlatego da się je ograniczyć, nie odcinając ani jednego gracza. To najważniejsza różnica wobec SA-MP, gdzie gra i zapytanie dzielą ten sam port.
• Jeden jedyny bajt zapytania na 22126 wytwarza odpowiedź o wielkości do kilku kilobajtów, a adres nadawcy da się podrobić. Nieograniczony port ASE jest tym samym celem i wzmacniaczem naraz.
• Wbudowane hamulce MTA działają na adres źródłowy: pięć zapytań w sześć sekund, cztery połączenia w 30 sekund. Przy więcej niż 100 jednoczesnych adresach źródłowych zliczanie zapytań jest pomijane, flood rozproszony przechodzi więc na wylot.
• Wewnętrzny serwer HTTP na 22005 to osobna powierzchnia ataku. Kto wyniesie pobieranie przez httpdownloadurl na zewnętrzny serwer WWW, wyjmuje je z rozgrywki.
• Wszystko, co działa na serwerze, decyduje tylko o małych atakach. Przy 1 Gbit/s koniec następuje przy około 1,49 miliona pakietów na sekundę, niezależnie od jakości twoich reguł.
• Dwuwarstwowa stała ochrona w KernelHoście jest zawarta w każdym pakiecie serwerowym bez dopłat i pracuje bez null-routingu. Kto chce sterować regułami na każdym porcie samodzielnie, dobiera Advanced DDoS Protection od 50,00 € miesięcznie.

Jeśli twój projekt działa już w KernelHoście, filtrowanie jest stale aktywne i nie musisz niczego włączać. Gdybyś mimo to zauważył coś nietypowego, załóż zgłoszenie wsparcia z zakresem czasu, portem i zaobserwowanym zachowaniem, żeby reguły dla twojego adresu zostały skorygowane. Przy trwającym ataku dotrzesz do nas dodatkowo przez awaryjny czat WhatsApp pod numerem +43 650 8209883. Jeśli hostujesz jeszcze gdzie indziej i jesteś regularnie trafiany, krótszym rozwiązaniem jest przeprowadzka do Frankfurtu nad Menem: dalsze kroki na ostry przypadek stoją we wpisie Silny atak DDoS: co robić teraz.