Ochrona serwera Call of Duty przed atakami DDoS

Ochrona serwera Call of Duty przed atakami DDoS jest w klasycznych tytułach zadaniem przyjemnie konkretnym: chodzi o dokładnie jeden port UDP, o garść dvarów w server.cfg i o wektor amplifikacji, który silnik nosi w sobie od 2003 roku. Serwer, który wieczorem w środku rundy traci naraz wszystkich graczy, rzadko ma za to problem ze sprzętem. Zwykle trwa atak, a trwa dokładnie wtedy, gdy serwer jest pełny.

Ten artykuł pokazuje najpierw, których tytułów w ogóle dotyczy, potem, co możesz zabezpieczyć sam i bez dodatkowych kosztów, następnie, gdzie te działania kończą się technicznie, a na koniec, co musi wtedy wydarzyć się w sieci przed serwerem. Polecenia są napisane dla Debiana 12, Debiana 13, Ubuntu 22.04 LTS i Ubuntu 24.04 LTS oraz zakładają użytkownika root, jako zwykły użytkownik poprzedź je poleceniem sudo.

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

Przy których tytułach Call of Duty możesz chronić serwer przed DDoS

Serwer Call of Duty przed DDoS możesz chronić tylko przy tych tytułach, które pozwalają na własne serwery dedykowane. To oryginalne wersje Call of Duty (2003), Call of Duty United Offensive, Call of Duty 2, Call of Duty 4 Modern Warfare i Call of Duty World at War, do tego platformy społecznościowe Plutonium (World at War, Black Ops, Black Ops II, Modern Warfare 3), IW4x (Modern Warfare 2) oraz CoD4X (Call of Duty 4). Wszystkie te tytuły przynoszą ten sam schemat: plik server.cfg, jeden otwarty port UDP i wpis na publicznej liście serwerów.

Dla nowszych części ten artykuł wyraźnie nie obowiązuje. Warzone, Modern Warfare (2019), Black Ops Cold War, Vanguard, Modern Warfare II, Modern Warfare III i Black Ops 6 nie znają serwerów dedykowanych do wynajęcia: rozgrywki działają na infrastrukturze matchmakingu Activision, nie ma pliku server.cfg, nie ma przeglądarki serwerów ani portu, który mógłbyś udostępnić albo zabezpieczyć. Listy portów, które Activision publikuje dla tych tytułów (między innymi TCP 3074 oraz od 27014 do 27050, a także UDP 3074, 3478 oraz od 27000 do 27031), opisują porty klienta i platformy, a nie porty serwera. Kto ma zrywające się połączenia w Warzone, ma problem na własnym łączu albo problem po stronie Activision, ale nie taki, który rozwiązałby wynajęty serwer.

Dlaczego akurat serwery Call of Duty są atakowane

Serwery Call of Duty łączą cztery cechy, które czynią z nich wygodny cel. Po pierwsze każdy wylistowany serwer sam publikuje swój adres: wpis na liście serwerów zawiera adres IP i port otwartym tekstem, bo inaczej nikt nie mógłby na niego wejść. Po drugie cały ruch idzie przez UDP, a UDP nie zna nawiązywania połączenia, którego można by wymagać, adresy nadawcy da się zaś podrobić. Po trzecie silnik odpowiada na zapytania o status każdemu, bez konieczności uruchamiania gry. Po czwarte zdalne sterowanie RCON leży na tym samym porcie co sama gra.

Do tego dochodzi część społeczna: zbanowani gracze, konkurencja między klanami, spory w społeczności, która zna się od lat. Atak nie kosztuje zlecającego ani umiejętności, ani liczących się pieniędzy, tak zwane bootery i stressery sprzedaje się w abonamencie za kilka euro miesięcznie, a ataki z amplifikacją przez serwery gier należą tam do standardowej oferty. Czym dokładnie jest atak DDoS, wyjaśnia wpis Czym jest atak DDoS?.

Porty, o które naprawdę chodzi

Klasyczny serwer Call of Duty zajmuje dokładnie jeden port UDP, a mianowicie 28960. Na tym jednym porcie działają jednocześnie trzy rzeczy: ruch gry, zapytania o status z listy serwerów oraz zdalne sterowanie RCON. Osobnego portu query ani osobnego portu RCON nie ma. Wiersz startowy serwera dedykowanego wygląda tak samo przy wszystkich tytułach, różni się tylko nazwa pliku wykonywalnego:

+set dedicated 2 +set net_ip 0.0.0.0 +set net_port 28960 +set sv_maxclients 32 +exec server.cfg +map_rotate

Porty serwerów master nie należą do twoich reguł zezwalających w firewallu. 20810 i 20800 to porty docelowe po drugiej stronie, a nie porty nasłuchu na twojej maszynie: twój serwer sam odzywa się do listy. Wiele poradników o przekierowaniu portów zaleca mimo to otwarcie ich przychodząco. To powiększa powierzchnię ataku bez żadnej korzyści.

Typowe rzędy wielkości przy Call of Duty

Druga tabela jest ważniejsza, jeśli chcesz ocenić, czy jeszcze poradzisz sobie sam. Zestawia normalne obciążenie pełnego serwera z liczbami, o które chodzi przy ataku.

Dlaczego gra, query i RCON leżą na tym samym porcie

To jest decydująca osobliwość Call of Duty. Silnik id Tech 3, na którym zbudowane są wszystkie klasyczne tytuły Call of Duty, nie zna osobnych portów dla gry, zapytania i zdalnego sterowania. Wszystko idzie przez tak zwane pakiety bezpołączeniowe na tym jednym porcie UDP. Pakiet bezpołączeniowy to pakiet UDP, który zaczyna się czterema bajtami 0xFF, a dalej niesie nazwę polecenia otwartym tekstem: getstatus, getinfo, getchallenge, connect albo rcon.

Praktyczny skutek jest niewygodny: nie oddzielisz RCON od gry firewallem, nie blokując przy tym samej gry. Reguła na porcie 28960 trafia zawsze we wszystko. Kto chce celowo odsiewać floody zapytań i ataki na RCON, musi zajrzeć w zawartość pakietu, a nie tylko w numer portu. Właśnie dlatego reguły firewalla oparte na portach dochodzą przy Call of Duty do swojej granicy wcześniej niż przy grach z osobnym portem query.

Czym jest refleksja getstatus przy Call of Duty?

Refleksja getstatus to atak z amplifikacją, w którym atakujący wysyła małe zapytania o status z podrobionym adresem nadawcy do wielu serwerów gier, żeby ich wyraźnie większe odpowiedzi wylądowały u właściwej ofiary. Serwery gier nie są przy tym celem, tylko wzmacniaczem. Ten wektor jest udokumentowany dla silnika id Tech 3 od ponad dekady i dotyczy Call of Duty tak samo jak Quake 3 oraz pozostałych jego pochodnych.

Trafia cię to podwójnie, z dwóch stron. Jako atakowany dostajesz zalew zapytań getstatus, które zużywają czas procesora i wychodzącą przepustowość, a twoi gracze odczuwają to jako skoki lagów. Jako mimowolny wzmacniacz rozsyłasz odpowiedzi do obcej ofiary, a zgłoszenie abuse ląduje u ciebie. Jedno i drugie dzieje się na tym samym porcie, tymi samymi pakietami, i jedno i drugie wygląda na wykresie obciążenia początkowo niegroźnie.

Jak wygląda pakiet getstatus

Zapytanie składa się z czterech bajtów 0xFF i słowa getstatus, razem 13 bajtów ładunku. Z nagłówkiem IP i UDP daje to 41 bajtów na łączu. Dokładnie na to celuje sprawdzenie długości w regułach firewalla, które od lat krążą po forach Call of Duty:

iptables -A INPUT -p udp -m length --length 41:45 -m recent --set --name getstatus_cod
iptables -A INPUT -p udp -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP

Odpowiedź jest nieporównanie większa. statusResponse zawiera całą konfigurację serwera jako ciąg znaków plus jeden wiersz na każdego połączonego gracza, przy pełnym serwerze więc kilka kilobajtów. CISA prowadzi protokół sieciowy Quake w swoim przeglądzie ataków z amplifikacją przez UDP (TA14-017A) ze współczynnikiem amplifikacji 63,9 i wskazuje jako nadużywane polecenie wprost wymianę informacji o serwerze. Z 1 Mbit/s podrobionych zapytań robi się w ten sposób około 64 Mbit/s u ofiary. Dla porównania: DNS leży w tym samym przeglądzie na poziomie od 28 do 54, NTP na 556,9.

Wbudowany hamulec: sv_queryIgnoreTime i sv_queryIgnoreMegs

Call of Duty 4 ma od wersji serwera 1.7 wbudowany hamulec zapytań. Zapamiętuje on każdy adres, który wysłał zapytanie o status, i ignoruje kolejne zapytania z tego samego adresu przez ustawialny czas. Sterują tym cztery dvary, z takimi wartościami domyślnymi:

sv_queryIgnoreMegs        1
sv_queryIgnoreTime        2000
sv_queryBounceIgnoreTime  12000
sv_queryIgnoreDebug       0

sv_queryIgnoreMegs określa, ile pamięci operacyjnej może zająć lista ignorowanych adresów. 1 megabajt mieści około 65 000 adresów, każdy kolejny megabajt mniej więcej 87 000 następnych. Wartość 0 wyłącza hamulec całkowicie i dokładnie tak jest na wielu serwerach, bo konfiguracja pochodzi ze starego wzorca. sv_queryIgnoreTime to czas blokady w milisekundach. sv_queryBounceIgnoreTime działa wtedy, gdy wraca odpowiedź „ICMP Port Unreachable”, czyli dokładnie wtedy, gdy twój serwer jest właśnie nadużywany jako wzmacniacz przeciwko obcej ofierze. sv_queryIgnoreDebug 1 zapisuje trafienia do logu, żebyś w ogóle widział, czy coś się dzieje.

Kto używa CoD4X, ma dodatkowo sztywne górne limity w kodzie serwera: najwyżej 20 odpowiedzi getstatus na 20 sekund, najwyżej 100 odpowiedzi getinfo na 100 sekund i najwyżej jeden komunikat błędu RCON na 100 milisekund. Komentarz w kodzie źródłowym nazywa zamiar wprost: serwer może się spokojnie dać zalewać, ale nie powinien przy tym marnować wychodzącej przepustowości. To właściwe ustawienie priorytetów, ale nie zastępuje filtrowania przed serwerem.

Dlaczego RCON przy Call of Duty jest historycznie problemem

RCON to zdalne sterowanie serwerem, a przy Call of Duty jest ono nieszyfrowanym pakietem UDP na porcie gry. Polecenie RCON wygląda na łączu tak: cztery bajty 0xFF, potem słowo rcon, potem hasło otwartym tekstem, potem właściwe polecenie. Nie ma szyfrowania, nie ma sesji, nie ma konta użytkownika ani drugiego składnika. Wynikają z tego trzy problemy i wszystkie są realne:

• Podsłuch. Kto widzi ruch w dowolnym miejscu drogi, czyta twoje hasło RCON otwartym tekstem. Dotyczy to każdej sieci między tobą a serwerem i każdego narzędzia, któremu to hasło dasz.
• Zgadywanie. Nie ma logowania, które dałoby się zablokować, ani blokady konta po dziesięciu nieudanych próbach. Atakujący przerabia hasła w dowolnym tempie. Oryginalny serwer w ogóle tego nie hamuje, CoD4X hamuje jedynie odpowiedź do jednego komunikatu błędu na 100 milisekund i zapisuje próbę jako „Bad rcon”.
• Refleksja. Także komunikat błędu RCON jest odpowiedzią na podrobiony pakiet. Kto ostrzeliwuje twój serwer podrobionymi pakietami RCON, używa go jako małego wzmacniacza, a twój serwer przy okazji zapisuje sobie log do pełna.

Praktyczna konsekwencja: ustawiaj rcon_password tylko wtedy, gdy RCON jest ci naprawdę potrzebny. A jeśli tak, to hasło długie i losowe. CoD4X wymaga co najmniej ośmiu znaków, to dolna granica, a nie zalecenie. Na co dzień administruj przez SSH i konsolę serwera zamiast przez RCON z otwartej sieci. A jeśli prowadzisz narzędzie administracyjne w rodzaju IW4MAdmin, które samo rozmawia przez RCON, to jego interfejs webowy na porcie 1624 nie należy do otwartej sieci.

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

Ten rozdział jest najdłuższy i to celowo. Czysto skonfigurowany serwer Call of Duty 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?

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:28960 oraz [::]:28960 oznaczają „osiągalny z całego internetu”, 127.0.0.1:3306 oznacza „tylko lokalnie” i nie potrzebuje żadnej reguły firewalla. Obok gry pojawiają się tam często IW4MAdmin, serwer WWW do Fast Download, baza danych do statystyk oraz zapomniana druga instancja gry. Spojrzenie oczami atakującego daje skan portów z zewnątrz:

nmap -Pn -sU -p 28960-28970,4976,27016 TWOJ.ADRES.IP.SERWERA
nmap -Pn -p- --min-rate 1000 TWOJ.ADRES.IP.SERWERA

2. Zostaw otwarte tylko to, czego gra naprawdę potrzebuje

Dla pojedynczego serwera Call of Duty wystarczy jedno udostępnienie 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 28960/udp comment 'Call of Duty'
ufw allow from 203.0.113.10 to any port 1624 proto tcp comment 'IW4MAdmin'
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 Plutonium T6 na miejsce 28960/udp wchodzi 4976/udp, przy Plutonium IW5 jest to 27016/udp. Jeśli prowadzisz kilka instancji, udostępniaj wyłącznie faktycznie używany zakres, czyli na przykład 28960:28962/udp, a nie ryczałtem od 28960 do 28970. Każdy port, na którym nic nie nasłuchuje, nie jest wprawdzie furtką, ale w razie ataku i tak kosztuje kernel pracę. Pełną instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu.

3. Włącz hamulec zapytań w server.cfg

Te cztery wiersze należą do każdej server.cfg serwera Call of Duty 4 i nie kosztują nic poza kilkoma megabajtami pamięci operacyjnej:

set sv_queryIgnoreMegs "4"
set sv_queryIgnoreTime "2000"
set sv_queryBounceIgnoreTime "12000"
set sv_queryIgnoreDebug "0"

4 megabajty mieszczą około 326 000 adresów, to wystarczy także na poważny flood. sv_queryIgnoreTime podnoś ponad domyślne 2000 milisekund tylko ostrożnie: lista serwerów i każda przeglądarka serwerów odpytują twój serwer tym samym mechanizmem, a kto ustawi czas blokady za wysoko, znika z listy. Ustaw sv_queryIgnoreDebug przejściowo na 1, jeśli chcesz wiedzieć, czy hamulec w ogóle działa, a potem z powrotem na 0, żeby log nie zapełnił ci dysku.

4. Odsiewaj floody zapytań w firewallu

Hamulec w silniku działa dopiero wtedy, gdy pakiet dotarł już do procesu gry. Reguła firewalla decyduje wcześniej i kosztuje mniej. Te dwa wiersze ograniczają getstatus na adres źródłowy:

iptables -A INPUT -p udp --dport 28960 -m length --length 41:45 -m recent --set --name cod_query --rsource
iptables -A INPUT -p udp --dport 28960 -m string --algo bm --string "getstatus" -m recent --update --seconds 2 --hitcount 4 --name cod_query --rsource -j DROP

Pierwszy wiersz zapamiętuje każdy adres źródłowy, który wysyła pakiet o typowej długości zapytania o status. Drugi odrzuca każde kolejne zapytanie getstatus, gdy tylko ten sam adres wyśle ich w ciągu dwóch sekund więcej niż cztery. Cztery zapytania na dwie sekundy wystarczą każdej przeglądarce serwerów. Po forach krążą też warianty z 20 zapytaniami na sekundę, które są wyraźnie hojniejsze i działają raczej przeciw grubym botom niż przeciw czystej fali refleksji.

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. Sprawdź potem przez iptables -L INPUT -n -v, czy liczniki trafień rosną. Jeśli stoją na zerze, reguła nie jest osiągana.

5. Wyłącz RCON albo prowadź go ciasno

Najbezpieczniejszy dostęp RCON to taki, którego nie ma. Puste rcon_password odrzuca każdy pakiet RCON:

set rcon_password ""

Zwróć przy tym uwagę na subtelność: serwer i tak jeszcze odpowiada, mianowicie komunikatem błędu, i pozostaje przez to małym wzmacniaczem. Kto chce to wykluczyć, a RCON i tak potrzebuje tylko z jednego stałego adresu, odrzuca te pakiety wcześniej:

iptables -A INPUT -p udp --dport 28960 ! -s 203.0.113.10 -m string --algo bm --string "rcon " -j DROP

Ta reguła ma efekt uboczny, o którym powinieneś wiedzieć: ciąg znaków rcon może teoretycznie pojawić się także w pakiecie czatu połączonego gracza, taki pakiet również zostałby wtedy odrzucony. W praktyce da się to przeboleć. Kto nie chce tego efektu ubocznego, pomija regułę i pracuje wyłącznie z pustym albo bardzo długim hasłem.

6. Odeprzyj flood prób dołączenia i wyczerpanie slotów

Flood prób dołączenia celuje nie w łącze, tylko w logikę gry: atakujący wysyła w szybkim tempie pakiety getchallenge i connect, aż wszystkie sloty zajmą półgotowe połączenia. Prawdziwi gracze dostają wtedy „Server is full”, choć w grze nie stoi nikt. Przeciw temu działają te ustawienia:

set sv_maxclients "32"
set sv_reconnectLimit "3"
set sv_floodProtect "1"
set sv_connectTimeout "30"
set sv_timeout "120"

sv_reconnectLimit ogranicza, jak często ten sam gracz może łączyć się na nowo raz za razem. sv_floodProtect ogranicza, ile poleceń klienta serwer przetwarza na gracza, i zapobiega tym samym temu, że pojedynczy klient wyhamuje serwer komendami. sv_connectTimeout i sv_timeout określają, jak długo półgotowe względnie milczące połączenie blokuje slot: kto zostawi tu hojne wartości ze starego wzorca, ułatwia atakującemu wyczerpanie slotów.

Na CoD4X dochodzi do tego sv_authorizemode. Wartość 1 wpuszcza tylko graczy z ważną kopią, 0 tylko graczy bez niej, a -1 jednych i drugich. Kto ustawi 1, odcina dużą część klientów jednorazowych, ale traci też prawdziwych graczy bez oryginalnej kopii. Najostrzejszym środkiem jest hasło serwera przez g_password, które działa przeciw wszystkiemu, co korzysta ze zwykłej drogi dołączania. I jedno musi być jasne: hasło chroni logikę twojej 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. Wpis na liście serwerów i twój własny adres

Tutaj opłaca się szczerość zamiast myślenia życzeniowego: twojego adresu IP nie da się utrzymać w tajemnicy. Zna go każdy gracz, który choć raz się połączył, a wpis na liście i tak go publikuje, razem z portem. Możesz ten wpis wyłączyć, nie ustawiając w server.cfg żadnego serwera master (dvary nazywają się sv_master1, sv_master2 i tak dalej). Kosztuje to jednak całą widoczność dla nowych graczy i pomaga tylko na najwygodniejszego z atakujących.

Uwaga co do stanu samych list: pierwotne serwery master Activision (codmaster.activision.com na 20510, cod2master.activision.com na 20710, cod4master.activision.com na 20810) nie odpowiadają już dla starych tytułów niczym. Kto chce być dziś wylistowany, korzysta z list społecznościowych: CoD4X prowadzi własną i wymaga do tego tokenu w sv_authtoken, Plutonium przynosi własną listę serwerów. Na samej sprawie to nic nie zmienia, adres stoi tam tak samo otwartym tekstem.

Dwa nawyki działają mimo to. Nigdzie nie publikuj surowego adresu IP samodzielnie, czyli ani na kanale Discord, ani na stronie klanu. I podłączaj graczy przez nazwę hosta, żeby w razie potrzeby móc zmienić adres bez łamania wszystkich odnośników. Klasykiem jest przy tym zapomniany rekord A wskazujący na stary adres: unieważnia on każdą zmianę.

8. Zabierz interfejsy webowe, bazę danych i Fast Download z otwartej sieci

Obok gry na większości serwerów Call of Duty działa jeszcze więcej: IW4MAdmin ze swoim interfejsem webowym na porcie 1624, serwer WWW do Fast Download map, czasem baza danych do statystyk. Każda z tych usług to osobna powierzchnia ataku i żadna z nich nie należy bez ograniczeń do otwartej sieci.

Ogranicz 1624 do własnego adresu albo dostawaj się do tego interfejsu przez przekierowanie SSH, a potem otwórz lokalnie http://127.0.0.1:1624:

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

Bazę danych zwiąż z 127.0.0.1, w otwartej sieci nie ma ona w żadnym wypadku czego szukać. A Fast Download połóż na osobnym serwerze WWW zamiast w procesie gry: serwer WWW pod obciążeniem zabiera inaczej grze dokładnie ten czas procesora, którego potrzebuje ona na symulację.

9. 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 wystarczą cztery polecenia:

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

Dla Call of Duty jest jeszcze piąte, które odpowiada na decydujące pytanie. Ten zrzut pokazuje wyłącznie pakiety bezpołączeniowe, czyli dokładnie getstatus, getinfo, getchallenge, connect i rcon:

tcpdump -ni eth0 'udp port 28960 and udp[8:4] = 0xffffffff' -c 200 -A

Jeśli stoi tam stokrotnie getstatus z coraz to nowych adresów, masz flood zapytań. Jeśli stoi tam rcon, ktoś próbuje zgadnąć twoje hasło. Jeśli stoi tam tylko getchallenge i connect, to flood prób dołączenia. Przy tcpdump obowiązuje zawsze zasada: ograniczaj przez -c, bo zrzut przy pełnym obciążeniu dodatkowo obciąża i tak przeciążony serwer. 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 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ą. Pełny serwer na 32 sloty generuje wychodząco około 6,4 Mbit/s, czyli mniej niż jeden procent łącza gigabitowego. To samo łącze jest pełne, gdy tylko ktoś wyśle 125 megabajtów na sekundę, a dokładnie na to nastawione są ataki, które można zamówić za dziesięć euro miesięcznie. 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 przy Call of Duty uderza ona regularnie 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ć. Zapytanie getstatus jest z 41 bajtami jeszcze mniejsze: atak, który nie zapełnia twojego łącza nawet w jednej trzeciej, i tak kładzie 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”.

Przy Call of Duty dochodzi osobliwość, która zaostrza ten rachunek. Ponieważ gra, query i RCON leżą na tym samym porcie, nie możesz awaryjnie zamknąć 28960: to byłoby to samo, co wyłączenie serwera. A ponieważ silnik odpowiada na każde zapytanie o status wielokrotnością rozmiaru zapytania, atakujący zużywa na ten sam efekt mniej własnej przepustowości niż przy innych grach.

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 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 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. 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 klany i społeczności 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 rdzenia sieci we Frankfurcie, 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: ustawiasz, co jest dozwolone na 28960 UDP, bez pisania zgłoszenia, a przy kilku instancjach osobno dla każdego portu.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku.
• Profil ochrony dopasowany do konkretnej gry, także dla zmodyfikowanych i własnych aplikacji na dowolnych portach TCP albo UDP. To jest istotny punkt dla Plutonium i CoD4X, bo ich porty mogą odbiegać od wartości domyślnych.

Advanced DDoS Protection jest przeznaczona dla serwerów, które stoją w KernelHoście. Jeśli twój serwer Call of Duty działa obecnie gdzie indziej i jest tam regularnie zdejmowany z sieci, to przeprowadzka do KernelHosta jest drogą, która coś zmienia.

Porównanie obu wariantów

Dla większości serwerów Call of Duty wystarczy wliczona stała ochrona razem z czystym plikiem server.cfg. Advanced DDoS Protection jest odpowiedzią na sytuację, w której ktoś bierze to do siebie osobiście.

Typowe błędy i ich rozwiązania

„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 ze statusem albo ze starego wpisu DNS. Zmiana adresu to zysk na czasie, a nie rozwiązanie.

„Mój dostawca przysyła mi zgłoszenie abuse, chociaż to ja jestem ofiarą”: wtedy twój serwer nie jest celem, tylko wzmacniaczem. Ktoś wysyła podrobione zapytania getstatus, a twój serwer grzecznie odpowiada obcej ofierze. Sprawdź najpierw, czy sv_queryIgnoreMegs stoi na 0, i ustaw cztery dvary zapytań oraz regułę firewalla z rozdziału 4.

„Serwer stoi na liście jako pełny, a jest pusty”: to flood prób dołączenia i uderza on w logikę gry, a nie w łącze. Przeciw temu działają sv_reconnectLimit, krótsze wartości dla sv_connectTimeout i sv_timeout, a w razie wątpliwości hasło serwera.

„Serwer znika podczas ataku z listy serwerów”: to skutek, a nie przyczyna. Lista serwerów sprawdza tymi samymi zapytaniami o status, czy twój serwer żyje. Jeśli odpowiedzi nie przechodzą albo zostały odrzucone przez twój własny hamulec, serwer uchodzi za offline. Sprawdź, czy sv_queryIgnoreTime nie stoi za wysoko, zanim zaczniesz podejrzewać firewall.

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

„Serwer działa, ale wszyscy gracze mają skoki lagów”: spójrz najpierw na liczbę pakietów na interfejsie, a nie na obciążenie CPU. Jeśli sar -n DEV 1 10 nie pokazuje nic nietypowego, a mimo to się tnie, to zwykle wina moda, przesadzonej wartości sv_maxRate albo po prostu zbyt wielu botów w rundzie.

„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

• Klasyczny serwer Call of Duty potrzebuje dokładnie jednego otwartego portu: 28960 UDP. Przy Plutonium T6 jest to 4976 UDP, przy Plutonium IW5 27016 UDP.
• Gra, zapytanie o status i RCON leżą przy Call of Duty na tym samym porcie. Nie oddzielisz RCON od gry regułą portową, potrzebujesz do tego reguły, która zagląda w zawartość pakietu.
• Refleksja getstatus to typowy dla tej gry wektor amplifikacji: 41 bajtów zapytania, według ostrzeżenia CISA TA14-017A współczynnik 63,9 przy protokole sieciowym Quake, czyli około 2600 bajtów odpowiedzi.
• Włącz hamulec zapytań: sv_queryIgnoreMegs 4, sv_queryIgnoreTime 2000, sv_queryBounceIgnoreTime 12000. Na wielu serwerach stoi on na 0 i jest przez to wyłączony.
• Ustawiaj rcon_password tylko wtedy, gdy RCON jest ci naprawdę potrzebny: hasło idzie nieszyfrowane przez UDP i da się je zgadywać dowolnie długo, bo nie ma blokady konta.
• Porty serwerów master 20810 i 20800 to wychodzące porty docelowe i nie należą do twoich reguł dla ruchu przychodzącego.
• Od mniej więcej 1 Gbit/s albo kilkuset tysięcy pakietów na sekundę decyduje wyłącznie sieć przed serwerem, a nie już twoja konfiguracja.

Jeśli twój serwer 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.