Team Fortress 2: ochrona serwera TF2 przed atakami DDoS

Serwer społecznościowy Team Fortress 2, który wieczorem w środku rundy traci naraz wszystkich graczy, a potem na kilka minut znika z przeglądarki serwerów, rzadko ma problem ze sprzętem. W większości przypadków trwa atak na 27015/UDP. Ten artykuł pokazuje, jak chronić serwer TF2 przed atakami DDoS: najpierw to, co możesz zrobić sam w ciągu najbliższych dziesięciu minut i bez dodatkowych kosztów, potem miejsce, w którym te działania kończą się fizycznie, a na koniec to, co musi wydarzyć się wcześniej w sieci.

Wszystkie informacje dotyczą serwera dedykowanego Source zainstalowanego przez SteamCMD (srcds_run -game tf) 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. Jeśli atak trwa właśnie teraz: nie zmieniaj najpierw niczego i nie restartuj serwera, tylko zabezpiecz pomiary z rozdziału 9. Po ataku już ich nie będzie.

Dlaczego serwery Team Fortress 2 potrzebują ochrony przed DDoS

Team Fortress 2 jest od 2011 roku darmowe i dokładnie to przesuwa ekonomię ataku. Atakujący ma nieograniczoną liczbę kont jednorazowych, za żadne z nich nie płaci i przy blokadzie nie ryzykuje niczego. To, co w grze płatnej kosztuje pieniądze, tutaj kosztuje minutę.

Dochodzi do tego cecha, która odróżnia TF2 od większości innych gier: od aktualizacji „Meet Your Match” z lipca 2016 nie ma już Quickplay, który automatycznie rozdzielał nowych graczy na serwery społecznościowe. Nowi gracze trafiają w trybie Casual na serwery Valve. Serwery społecznościowe da się znaleźć wyłącznie przez przeglądarkę serwerów. Kto wypadnie z tej listy, dla nowych graczy praktycznie nie istnieje, nawet jeśli proces serwera działa bez zarzutu. Atak, który tylko wypycha twój serwer z listy, osiągnął więc już swój cel.

Typowe cele wyglądają odpowiednio: stale działające serwery społecznościowe ze stałymi graczami (2Fort przez całą dobę, Trade, Jailbreak, Surf, Dodgeball, Mann vs. Machine), serwery ligowe z ustalonym terminem meczu w rozgrywkach ETF2L, RGL i ozfortress, a także serwery, których operator właśnie kogoś zablokował. Powód prawie nigdy nie jest techniczny. Czym w ogóle jest atak DDoS, wyjaśnia wpis Czym jest atak DDoS?.

Porty, o które przy serwerze TF2 naprawdę chodzi

Serwer TF2 potrzebuje na zewnątrz dokładnie jednego portu: 27015/UDP. Cała reszta daje się wyłączyć, należy ją ograniczyć albo i tak działa wyłącznie wychodząco. Ta tabela jest podstawą każdej reguły firewalla opisanej niżej:

Przy kilku instancjach na jednej maszynie numery rosną: 27016, 27017 i tak dalej dla gry, 27021 i 27022 dla SourceTV. Plik konfiguracyjny leży pod tf/cfg/server.cfg i jest wczytywany od nowa przy każdej zmianie mapy.

Dlaczego wspólny port 27015 jest najczulszym punktem

Ruch gry i zapytanie do serwera dzielą w TF2 ten sam port UDP, osobnego portu query nie ma. Zapytanie A2S_INFO ma przy tym dokładnie 25 bajtów: cztery bajty FF FF FF FF, jeden bajt 0x54 oraz dwudziestobajtowy ciąg „Source Engine Query” z kończącym zerem. Odpowiedź z nazwą serwera, mapą, liczbą graczy i tagami jest wielokrotnie większa. Amerykańska agencja CISA podaje w alercie TA14-017A współczynnik wzmocnienia protokołu Steam na poziomie 5,5.

Ponieważ UDP nie zna nawiązywania połączenia, a adresy nadawcy da się podrobić, przez lata była to otwarta luka wzmacniająca: atakujący odpytywał cudze serwery Source, podając jako nadawcę adres swojej ofiary, a serwery wysyłały swoje odpowiedzi do ofiary. A2S_PLAYER i A2S_RULES od zawsze wymagały wcześniej pobranego wyzwania, A2S_INFO nie. Dopiero w grudniu 2020 Valve dołożyło wyzwanie także dla A2S_INFO: serwer może zamiast odpowiedzi odesłać S2C_CHALLENGE, które pytający musi powtórzyć, czym dowodzi, że nie sfałszował adresu nadawcy.

To rozbraja odbicie, ale nie kończy kłopotu. Każdy pakiet z zapytaniem nadal do ciebie dociera i kosztuje czas procesora, zanim zostanie obsłużony albo odrzucony. A atakujący, który zalewa twój serwer bezpośrednio, i tak nie potrzebuje żadnego wzmocnienia.

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

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

1. Inwentaryzacja: co nasłuchuje i z jaką linią startową

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

ss -lntup

Wszystko, co jest związane z 127.0.0.1 albo ::1, nie potrzebuje żadnej reguły. Wszystko na 0.0.0.0 albo [::] jest osiągalne z internetu, także baza MySQL, którą przyniósł ze sobą plugin statystyk, oraz serwer WWW, na którym leżą twoje pliki FastDL. Porównaj wynik ze swoją linią startową:

./srcds_run -game tf -console \
  -port 27015 -steamport 26901 -nohltv \
  +maxplayers 24 +map ctf_2fort +sv_pure 1 \
  +sv_setsteamaccount TWOJ_TOKEN_GSLT

Każdy port w tej linii to świadoma decyzja. Jak instaluje się podstawę, opisuje wpis Instalacja serwera gry przez SteamCMD.

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

Publiczny serwer TF2 potrzebuje na zewnątrz dokładnie jednego otwarcia, plus RCON dla twojego własnego adresu. 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 27015/udp comment 'TF2 gra i A2S'
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment 'RCON'
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. SourceTV celowo się tu nie pojawia: kto nie transmituje, startuje z -nohltv i w ogóle nie zajmuje 27020/UDP. To zmniejsza o połowę powierzchnię UDP serwera TF2 osiągalną z zewnątrz. Jeśli transmitujesz mecze ligowe, dochodzi ufw allow 27020/udp, a wtedy trzeba ustawić tv_password.

Pełną instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu. Gdyby jednak do tego doszło: serwery root KVM oraz serwery dedykowane KernelHost osiągniesz przez konsolę VNC w panelu klienta, która działa niezależnie od sieci systemu gościa.

3. Ogranicz zapytania A2S, nie wypadając z przeglądarki serwerów

Tutaj leży najdroższy błąd w tym temacie: ryczałtowa blokada albo zgrubne ograniczenie tempa na 27015/UDP wyrzuca własnych graczy i kończy atak po myśli atakującego. Ponieważ ruch gry i zapytania zajmują ten sam port, granica musi przebiegać między rodzajami pakietów, a nie na porcie.

Silnik ma do tego trzy zmienne konsolowe, które należą do pliku tf/cfg/server.cfg:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

Pierwsza ogranicza liczbę obsłużonych zapytań na adres nadawcy, druga sumę ze wszystkich adresów, trzecia ustala okno uśredniania w sekundach. Chronią procesor przed bezsensownym generowaniem odpowiedzi. Wartości domyślne różnią się zależnie od gry i kompilacji, find sv_max_queries w konsoli serwera pokazuje, które wartości zna twój serwer.

Druga wartość jest w TF2 tą delikatną: ogranicza odpowiedzi ponad wszystkimi adresami. Ustaw ją za nisko, a twój serwer przestanie w trakcie zalewu zapytaniami odpowiadać także usługom listującym i zniknie z przeglądarki serwerów, czyli z jedynej drogi, na której znajdują cię nowi gracze. Zacznij hojnie i dociskaj dopiero wtedy, gdy możesz zmierzyć, że legalne zapytania przechodzą.

Warstwę niżej ten sam ruch da się czysto rozdzielić. Wszystkie bezpołączeniowe pakiety silnika Source zaczynają się czterema ustawionymi bajtami (0xffffffff), ruch graczy już połączonych tego nagłówka nie ma. Na tym można oprzeć ograniczenie tempa, nie dotykając ruchu gry:

table inet tf2 {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

Plik ładujesz poleceniem nft -f. Priorytet -10 sprawia, że reguła działa przed łańcuchem filtrującym UFW, a @th,64,32 czyta pierwsze cztery bajty za nagłówkiem UDP.

4. Przechwyć zalewy pakietami dzielonymi, które w logu pojawiają się jako NET_GetLong

Ten atak to cecha silnika Source i trafia szczególnie w TF2, bo TF2 do dziś działa na starej gałęzi silnika. Obok normalnych pakietów bezpołączeniowych silnik zna pakiety dzielone: zaczynają się od FE FF FF FF zamiast FF FF FF FF i zapowiadają, że większa wiadomość nadejdzie w kilku częściach. Serwer musi te części buforować i czekać na resztę.

I dokładnie to da się wykorzystać. Atakujący wysyła masowo zapowiedziane, ale nigdy niekompletne części z podrobionymi adresami nadawcy. Obciążenie procesora rośnie, gra się tnie, a w logu serwera mnożą się wiersze z NET_GetLong. Wystarczy do tego jeden komputer, przepustowości prawie nie potrzeba. Operatorzy regularnie zgłaszają to jako atak DDoS, choć łącze jest prawie puste.

Ponieważ zwykły klient TF2 nie ma właściwie powodu, żeby wysyłać serwerowi pakiety dzielone, wąskie ograniczenie jest tutaj do obrony:

udp dport 27015 @th,64,32 0xfffffffe \
    meter tf2split { ip saddr limit rate over 5/second burst 10 packets } drop

Ten wiersz należy do tego samego łańcucha co reguła z rozdziału 3. Jeden z nielicznych legalnych powodów wysyłania plików przez klienta usuwasz dodatkowo przez sv_allowupload 0 (patrz rozdział 7).

5. Wyjmij RCON z otwartej sieci

Protokół RCON silnika Source przesyła hasło otwartym tekstem przez TCP. Kto może podsłuchać drogę między tobą a serwerem, ma potem twoje hasło RCON, a kto ma RCON, może zmienić mapę, zablokować wszystkich graczy i zatrzymać serwer. To nie jest problem DDoS, tylko przejęcie, ale bywa regularnie zgłaszane jako atak.

Nigdy nie zostawiaj rcon_password pustego ani łatwego do odgadnięcia, wartość z openssl rand -base64 32 wystarczy. Do tego należy hamulec na próby logowania:

rcon_password "TUTAJ_WARTOSC_LOSOWA"
sv_rcon_maxfailures 3
sv_rcon_minfailures 3
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Dzięki temu serwer blokuje adres po trzech nieudanych próbach w ciągu 30 sekund na 24 godziny; find sv_rcon pokazuje, które zmienne zna twoja kompilacja. Skuteczniejsza pozostaje mimo to reguła firewalla z rozdziału 2, bo nie przepuszcza próby nawet do aplikacji. Do dostępu ze zmieniających się łączy ustaw lokalne przekierowanie przez SSH i odzywaj się do RCON na 127.0.0.1:

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

6. Ogranicz tempo przesyłu i zostaw hibernację włączoną

Team Fortress 2 pracuje ze stałą częstotliwością 66,67 ticka na sekundę. O tym, ile powstanie z tego ruchu, decyduje jednak nie tick, tylko to, ile wolno zażądać pojedynczemu klientowi. Bez górnej granicy każdy gracz bierze tyle, ile żąda jego klient, a płacisz za to swoją przepustowością wychodzącą:

sv_minrate 50000
sv_maxrate 100000
sv_mincmdrate 40
sv_maxcmdrate 66
sv_minupdaterate 40
sv_maxupdaterate 66

Przelicz to raz dokładnie: przy sv_maxrate 100000 każdy gracz może pobierać 100 kilobajtów na sekundę, na 24 miejscach to 2,4 megabajta na sekundę, czyli około 19 Mbit/s wychodząco. Gdy ustawisz sv_maxrate 0, górnej granicy nie ma. Serwery ligowe robią to świadomie, publiczny serwer z wieloma miejscami nie powinien. Pluginy, które odblokowują tickrate, zwielokrotniają liczbę pakietów na gracza, a wraz z nią ten sam rachunek.

Drugi punkt bywa robiony źle. TF2 zasypia, gdy nikt nie jest połączony, i w tym stanie prawie nie zużywa procesora. Wielu operatorów to wyłącza, żeby serwer „czuł się obudzony”. Na maszynie z kilkoma instancjami oznacza to, że procesor jest obciążony już na biegu jałowym, a atak trafia w system, który jest już pełny. Zostaw ustawienie domyślne:

sv_hibernate_when_empty 1
sv_hibernate_postgame_delay 5
tf_allow_server_hibernation 1

7. Oddziel FastDL i wyłącz wysyłanie plików przez klientów

Serwery społecznościowe żyją własnymi mapami i dokładnie stąd bierze się druga powierzchnia ataku. Bez sv_downloadurl każdy gracz pobiera zawartość kanałem sieciowym gry, czyli przez ten sam port i ten sam proces, który jednocześnie liczy mecz. To kilka kilobajtów na sekundę i plik po pliku, a przy kolekcji map wielkości 200 megabajtów blokuje ci to serwer na całe minuty na każdego gracza:

sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64
sv_downloadurl "https://fastdl.example.org/tf/"

net_maxfilesize stoi domyślnie na 15 i da się podnieść najwyżej do 64 megabajtów. sv_allowupload 0 uniemożliwia klientom wysyłanie własnych plików (na przykład sprayów) na serwer i tym samym usuwa jeden z nielicznych legalnych powodów istnienia pakietów dzielonych z rozdziału 4.

Decydujące jest to, gdzie stoi host FastDL. Jeśli leży pod tym samym adresem IP co serwer gry, wystarczy zalew HTTP na 443/TCP, żeby zapełnić łącze i tym samym udusić także 27015/UDP. Przenieś szybkie pobieranie na inny host albo za sieć dostarczania treści, wtedy atak na pliki nie trafi w grę.

8. Ogranicz system głosowań, zalewy dołączeń i pluginy

Nie każda awaria to przepustowość. Ponieważ TF2 jest darmowe, atak na logikę gry nie kosztuje nic poza kontami: zalewy dołączeń zajmujące każde miejsce, spam głosowy i czatowy oraz nadużywane głosowania, które wyrzucają zwykłych graczy. Ustawienia domyślne TF2 są tutaj już rozsądne, ale bywają rozluźniane:

sv_allow_votes 1
sv_vote_issue_kick_allowed 0
sv_vote_allow_spectators 0
sv_vote_creation_timer 150
sv_vote_failure_timer 300
sv_vote_quorum_ratio 0.6

To są wartości standardowe: głosowania są dozwolone, głosowania o wyrzucenie nie, widzowie nie głosują, między dwoma głosowaniami mija 150 sekund, po nieudanym 300, a głosowanie potrzebuje 60 procent poparcia. Kto ustawia sv_vote_issue_kick_allowed 1, powinien wiedzieć, że otwiera narzędzie, które na publicznym serwerze bywa nadużywane niezawodnie.

Wszystko, co wykracza poza to, pochodzi w TF2 z SourceMod i Metamod:Source. Oba leżą w tf/addons/ i zgłaszają się w konsoli przez meta version oraz sm version. Inaczej niż przy Counter-Strike 2 podstawa jest tu dojrzała, a pluginy do list blokad, weryfikacji dołączeń i ograniczania czatu są zwyczajną drogą. Dwie zasady do tego: każdy plugin to kod w tym samym procesie, a plugin, który się wywali, zabiera serwer ze sobą. I pluginy, które przynoszą własne usługi webowe, otwierają kolejne porty i czasem publikują dokładnie ten adres, który chcesz chronić. sm plugins list pokazuje, co faktycznie działa.

Jak poważnie trzeba traktować stronę silnika, pokazuje kwiecień 2020: po wycieku starszych wersji kodu źródłowego TF2 i CS:GO duzi operatorzy społecznościowi, jak Creators.TF czy Red Sun, tymczasowo wyłączyli swoje serwery z obawy przed wykorzystaniem luk. Trzymaj binarium serwera aktualne, a rozszerzenia dopasowane do wersji silnika.

9. Mierz i zapisuj logi, zanim się zapali

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. W trakcie incydentu wystarczą cztery polecenia:

ip -s link show eth0
nstat -az | grep -i udp
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xfffffffe"

Pierwsze polecenie pokazuje pakiety, błędy i odrzucenia na każdym interfejsie; wykonaj je dwa razy w odstępie dziesięciu sekund, a dostaniesz tempo zamiast wartości bezwzględnej. Oba zrzuty oddzielają zalew zapytaniami od zalewu pakietami dzielonymi i odpowiadają tym samym na pytanie, która z dwóch reguł z rozdziałów 3 i 4 w ogóle musi zadziałać. Zawsze ograniczaj je przez -c, zrzut przy pełnym obciążeniu sam kosztuje czas procesora.

Wewnątrz serwera polecenie konsolowe stats podaje w jednym wierszu obciążenie procesora, wchodzące i wychodzące obciążenie sieci w kilobajtach na sekundę, liczbę klatek serwera oraz liczbę graczy. Jeśli liczba klatek serwera spada wyraźnie poniżej wartości ticka, a liczba graczy jest normalna, serwer pracuje nad czymś innym niż gra. Jak odczytać te wartości, opisuje wpis Jak rozpoznać atak DDoS na serwerze.

Gdzie te działania się kończą: przepustowość i liczba pakietów

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.

Postaw normalną pracę pełnego serwera TF2 obok prawdziwego ataku, a proporcja stanie się oczywista:

Typowy serwer gier wisi na 1 Gbit/s, czyli 125 megabajtów na sekundę, a łącze jest pełne, gdy tylko ktoś wyśle więcej. Druga wielkość to liczba pakietów i uderza ona zwykle wcześniej niż przepustowość: każdy pakiet kosztuje przebieg przez stos sieciowy, nawet jeśli potem zostanie odrzucony. Atak, który nie zapełnia twojego łącza nawet w jednej trzeciej, mimo to kładzie twój serwer. Operatorzy przeżywają to jako „przecież obciążenie wcale nie było wysokie, a i tak wszystko padło”.

Dla porządku wielkości, które zdarzają się naprawdę: na serwerach KernelHost odfiltrowano w czasie rzeczywistym między innymi flood UDP przeciw serwerowi gier o wolumenie ponad 112,2 Gbit/s przy ponad 8,7 miliona pakietów na sekundę oraz atak wielowektorowy na serwer głosowy o wolumenie ponad 473,4 Gbit/s przy ponad 41,5 miliona pakietów na sekundę. 473,4 Gbit/s to około 470-krotność łącza 1 Gbit/s. Na to nie ma żadnego ustawienia lokalnego.

Dwa rozpowszechnione hamulce awaryjne nic tu nie dają. Null-routing zdejmuje atakowany adres IP z sieci i kończy atak, ale kończy też twój serwer. Reaktywne przekierowanie kosztuje w czasie przełączania dokładnie te minuty, w których rozstrzyga się mecz. Skuteczne jest wyłącznie filtrowanie, które działa nieprzerwanie w sieci przed serwerem.

Co KernelHost przeciwstawia atakom na serwery TF2

Stała ochrona zawarta w każdym pakiecie serwerowym

Ochrona DDoS w KernelHoście jest zbudowana dwuwarstwowo i od momentu udostępnienia stale aktywna, bez konieczności zamawiania, włączania 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.

Dla serwera TF2 decydujące są dwie cechy. Filtrowanie działa nieprzerwanie i nie musi dopiero reagować na atak, nie ma więc czasu przełączania, w którym twoi gracze wylatują, a serwer wypada z przeglądarki serwerów. I nie stosuje się null-routingu: twój adres IP zostaje w sieci, odrzucane są wyłącznie szkodliwe pakiety. Które gry i protokoły są objęte ochroną, wylicza wpis Ochrona DDoS serwerów gier w czasie rzeczywistym.

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

Niektóre projekty są atakowane nie okazjonalnie, tylko celowo i przez wiele tygodni, ze zmieniającymi się wzorcami i zawsze dokładnie na termin meczu. 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: osobno ustawiasz, co jest dozwolone na 27015/UDP, co na 27020/UDP i co na 27015/TCP, bez pisania zgłoszenia.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku, zamiast czekać do końca meczu.
• Profil ochrony dopasowany do gry, dla Team Fortress 2 i pozostałych tytułów na silniku Source, a także wolne profile TCP i UDP dla własnych aplikacji.

Oferta jest skierowana do serwerów, które działają w KernelHoście. Jeśli twój serwer TF2 stoi obecnie gdzie indziej i jest regularnie ostrzeliwany, drogą do tej ochrony jest przeprowadzka.

Porównanie obu wariantów

Dla większości społecznościowych serwerów TF2 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

„Serwer działa, ale nie ma go już w przeglądarce serwerów”: sprawdź najpierw Game Server Login Token. Serwery TF2 potrzebują do publicznego wpisu tokena, ustawianego przez sv_setsteamaccount i wygenerowanego dla App-ID 440. Steam wycofuje tokeny, które nie były używane przez 30 dni. Serwer, który znika po dłuższej przerwie, potrzebuje więc często tylko nowego tokena i wcale nie jest atakowany. Dopiero potem w grę wchodzi za niskie sv_max_queries_sec_global albo zbyt zgrubna reguła firewalla na 27015/UDP.

„Procesor stoi na 100 procentach, a łącze jest prawie puste”: to typowy obraz zalewu zapytaniami albo zalewu pakietami dzielonymi. Poszukaj w logu serwera wierszy z NET_GetLong i zmierz dwoma poleceniami tcpdump z rozdziału 9, który rodzaj pakietów przychodzi.

„Moje reguły nftables albo iptables nie działają”: częste są trzy przyczyny. Reguła stoi za łańcuchami UFW i nigdy nie zostaje osiągnięta (dlatego priorytet -10), zniknęła po ostatnim restarcie albo atak jest wolumetryczny, a reguła pracuje poprawnie na łączu, które jest już pełne. Sprawdź przez nft list ruleset, czy liczniki rosną. Jeśli stoją na zerze, reguła nie jest osiągana.

„Zmieniłem adres IP i następnego dnia znowu byłem offline”: atakujący znajduje nowy adres z tego samego źródła co stary. Twój serwer publikuje go sam, gdy tylko wraca do przeglądarki serwerów, a resztę robią stare wpisy DNS oraz boty Discord ze statusem. Zmiana adresu daje godziny, a nie rozwiązanie.

„Serwer wywala się powtarzalnie, choć przepustowość nie zwraca uwagi”: zwykle nie jest to atak DDoS, tylko plugin, który nie pasuje do wersji silnika, albo przestarzałe binarium serwera. sm plugins list i porównanie wersji są tu szybsze niż jakakolwiek reguła filtrowania.

„Serwer reaguje po biegu jałowym z opóźnieniem”: to hibernacja, a nie błąd. Obniża obciążenie procesora prawie do zera, dopóki nikt nie jest połączony, a to dokładnie ten stan, w którym chcesz mieć rezerwy.

„Na serwerze wykonują się obce polecenia administracyjne”: to nie atak DDoS, tylko przejęty dostęp RCON. Natychmiast ustaw nowe hasło, ogranicz port do własnego adresu i pamiętaj, że hasło idzie przez łącze otwartym tekstem.

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

Krótkie podsumowanie

• Serwer TF2 potrzebuje na zewnątrz dokładnie 27015/UDP. RCON na 27015/TCP należy ograniczyć do własnego adresu, a SourceTV na 27020/UDP wyłącza się przez -nohltv, jeśli nie transmitujesz.
• Ruch gry i zapytanie A2S dzielą ten sam port. Kto blokuje albo ryczałtowo ogranicza tempo na 27015/UDP, wyrzuca własnych graczy. Granica musi przebiegać między rodzajami pakietów, rozpoznawalnymi po pierwszych czterech bajtach za nagłówkiem UDP.
• Zalewy pakietami dzielonymi z nagłówkiem FE FF FF FF generują obciążenie procesora zamiast przepustowości i widać je w logu jako NET_GetLong. Wąskie ograniczenie tego rodzaju pakietów jest przy TF2 do obrony.
• Od aktualizacji „Meet Your Match” nowi gracze znajdują serwery społecznościowe już tylko przez przeglądarkę serwerów. Każde działanie, które wypycha cię z listy, działa jak sam atak.
• Pełny serwer na 24 miejsca przetwarza około 1600 pakietów przychodzących na sekundę. Ataki na społecznościowe serwery gier mieszczą się zwykle między 5 a 50 Gbit/s przy kilku milionach pakietów na sekundę.
• 1 Gbit/s niesie przy najmniejszych pakietach około 1,49 miliona pakietów na sekundę. Powyżej tej granicy decyduje wyłącznie sieć przed serwerem, a nie reguła na samym serwerze.
• W KernelHoście dwuwarstwowa stała ochrona jest zawarta w każdym pakiecie serwerowym bez dopłat i działa od momentu udostępnienia, bez null-routingu. Advanced DDoS Protection dochodzi od 50,00 € miesięcznie, jeśli chcesz sam sterować regułami na każdym porcie.

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. Podaj od razu cztery informacje: adres IP, port, przedział czasu w twojej strefie czasowej oraz to, co widzisz. To oszczędza jedną rundę dopytywania, a ta liczy się, gdy trwa mecz.