Ochrona serwera Left 4 Dead 2 przed atakami DDoS

Serwer Left 4 Dead 2 rzadko pada w wygodnym momencie. Pada w ostatnim rozdziale kampanii, w drugim przebiegu meczu Versus albo dokładnie wtedy, gdy zbanowany gracz został odrzucony po raz trzeci. Kto jest właśnie pod ostrzałem, nie potrzebuje dyskusji o zasadach techniki sieciowej, tylko kolejności działań. Ten artykuł pokazuje najpierw, jak chronić serwer Left 4 Dead 2 przed atakami DDoS, dopóki da się to zrobić środkami z pokładu, potem, gdzie te możliwości kończą się fizycznie, a na koniec, co musi wydarzyć się przed nim w sieci.

Wszystkie informacje dotyczą serwera dedykowanego (srcds), zainstalowanego przez SteamCMD pod App-ID 222860, 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. Jedna rzecz na wstępie, bo wyznacza kolejność: w trakcie trwającego ataku nie zmieniaj niczego na ślepo i nie restartuj serwera, zanim nie zabezpieczysz pomiarów. Po ataku już ich nie będzie.

Dlaczego serwery Left 4 Dead 2 są opłacalnym celem ataku DDoS

Różnica wobec strzelanki z 64 miejscami leży w rozmiarze rozgrywki. Kampania kooperacyjna ma cztery miejsca dla ocalałych, mecz Versus osiem miejsc na obie strony razem. Awaria nigdy nie trafia więc w pojedynczych graczy, tylko zawsze w całą partię: kto przerwie kampanię w trzecim z pięciu rozdziałów, zakończył wieczór wszystkim uczestnikom. Właśnie to czyni atak atrakcyjnym dla zlecającego, bo nie kosztuje go ani umiejętności, ani liczących się pieniędzy, a po drugiej stronie niszczy godzinę gry.

Do tego dochodzi budowa. Left 4 Dead 2 działa na silniku Source, a serwer Source jest publicznie odnajdywalny po adresie IP i porcie. To warunek działania, a nie przeoczenie: serwer, który nie odpowiada na zapytanie o status, nie stoi na żadnej liście i nie zostanie znaleziony przez żadne lobby. Pytanie nigdy nie brzmi więc, czy atakujący zna twój adres, tylko co się stanie, kiedy zacznie w niego strzelać. Ruch gry idzie przez UDP, a UDP nie zna nawiązywania połączenia, którego można by wymagać, do tego adresy nadawcy da się podrobić. Co przy tym dzieje się technicznie, wyjaśnia wpis Czym jest atak DDoS?.

Trzeci punkt jest właściwy tylko Left 4 Dead 2 i nie ma odpowiednika w Counter-Strike, Garry's Mod czy Team Fortress 2: większość graczy przychodzi nie przez przeglądarkę serwerów, tylko przez system lobby. Lobby liczące do czterech graczy zostaje przydzielone przez matchmaking Steam do serwera dedykowanego, który dostaje za to rezerwację. Ta procedura jest jednocześnie twoim najskuteczniejszym filtrem dostępu i dodatkową powierzchnią ataku. Jedno i drugie opisujemy niżej w szczegółach.

Porty, o które naprawdę chodzi

Serwer Left 4 Dead 2 zajmuje dokładnie jeden port UDP na wszystko, co składa się na grę. Standardem jest 27015, ustalany przez -port względnie +hostport w linii startowej:

./srcds_run -game left4dead2 -console -nohltv \
  -port 27015 \
  +ip 203.0.113.10 \
  +maxplayers 4 \
  +exec server.cfg \
  +map c1m1_hotel

Pierwszy wiersz tej tabeli jest sednem problemu. Ruch gry i zapytania o status dzielą 27015/UDP, osobnego portu zapytań w Left 4 Dead 2 nie ma. Kto zablokuje ten port ogólnie albo obłoży go zgrubnym limitem, tym samym ruchem wyrzuci własnych graczy i zakończy atak za atakującego.

Zapytanie A2S to pakiet o wielkości kilkudziesięciu bajtów, a odpowiedź jest wielokrotnie większa. W UDP adres nadawcy da się podrobić, więc twój serwer staje się nie tylko ofiarą, ale i wzmacniaczem: atakujący odpytuje cudze serwery gier adresem swojego celu i kieruje tam ich odpowiedzi. Valve uzupełniło A2S_INFO w grudniu 2020 o poprzedzające wyzwanie (S2C_CHALLENGE), które pytający musi odesłać, zanim dostanie odpowiedź. To łagodzi reflection, ale jej nie kończy, bo starsze programy odpytujące są nadal obsługiwane.

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

Następna część nic nie kosztuje i opłaca się niezależnie od tego, gdzie stoi twój serwer. Nie zdejmie z ciebie ataku wolumetrycznego, ale sprawi, że małe i średnie ataki spełzną na niczym, i usunie te awarie, które błędnie zgłaszane są jako atak DDoS.

1. Inwentaryzacja: co naprawdę nasłuchuje

Zanim napiszesz regułę, ustal, które usługi są osiągalne. Na rozrośniętym serwerze Left 4 Dead 2 jest ich prawie zawsze więcej, niż się spodziewasz, bo obok srcds działa jeszcze serwer WWW dla kampanii, baza statystyk, a czasem drugi serwer dla Versus:

ss -lntup

Wszystko, co jest przypięte do 127.0.0.1 albo ::1, nie wymaga otwierania portu. Wszystko, co nasłuchuje na 0.0.0.0 albo [::], jest osiągalne z internetu. Spojrzenie oczami atakującego daje skan portów z zewnątrz, a ten z doświadczenia odbiega od własnych oczekiwań:

nmap -Pn -sU -sT -p 27000-27050,80,443,3306 TWOJ.ADRES.IP.SERWERA

Jeśli fundament jest świeżo postawiony albo chcesz go prześledzić, wpis Instalacja serwera gry przez SteamCMD opisuje drogę od SteamCMD do działającego srcds.

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

Jeden port UDP na zewnątrz, jeden port TCP dla własnego adresu, nic więcej. RCON nie ma czego szukać w otwartym internecie, bo kto ma RCON, zmienia mapę, banuje wszystkich graczy i zatrzymuje serwer:

ufw allow 27015/udp comment "L4D2 port gry i A2S"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw allow from 203.0.113.10 to any port 22 proto tcp comment "SSH"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

Zamień 203.0.113.10 na swój własny adres. Jeśli zmienia się on regularnie, droga prowadzi przez przekierowanie portu SSH, a nie przez trwale otwarty port. O tym, czy zamkniesz dostęp samemu sobie, decyduje kolejność przy uruchamianiu firewalla; opisuje ją razem z drogą powrotną wpis Konfiguracja firewalla UFW bez zamykania sobie dostępu. Gdyby jednak do tego doszło: serwery root KVM i serwery dedykowane w KernelHoście nie mają IPMI ani iDRAC, do serwera dostaniesz się przez konsolę VNC w panelu klienta, a ta nie wisi na stosie sieciowym systemu gościa.

3. Ogranicz zapytania A2S, nie wypadając z wyszukiwania lobby

Tutaj kryje się najdroższy błąd w całym temacie. Ponieważ ruch gry i zapytania o status zajmują ten sam port, hamulec musi rozróżniać klasy pakietów, a nie porty.

Fundament Steam Gameserver ma do tego od zmian z grudnia 2020 własny limit, ustawiany przed startem jako zmienna środowiskowa. STEAM_GAMESERVER_RATE_LIMIT_200MS=N odrzuca pakiety bezpołączeniowe (A2S_INFO, A2S_RULES, A2S_PLAYERS) danego adresu nadawcy, gdy tylko w oknie 200 milisekund przyjdzie ich więcej niż N. Valve podaje zakres od 25 do 75 jako sensowny, domyślnie limit jest wyłączony:

export STEAM_GAMESERVER_RATE_LIMIT_200MS=50
./srcds_run -game left4dead2 -console -port 27015 +exec server.cfg +map c1m1_hotel

W jednostce systemd ta sama wartość należy jako Environment=STEAM_GAMESERVER_RATE_LIMIT_200MS=50 do sekcji [Service], inaczej po następnym restarcie jej nie ma. Ten hamulec działa tylko wtedy, gdy twój build serwera przynosi aktualny fundament Steamworks, i chroni czas procesora twojego serwera, a nie twoje łącze: pakiety już dotarły.

Poziom niżej ten sam ruch da się oddzielić w kernelu. Wszystkie bezpołączeniowe pakiety silnika Source, czyli zapytania o status i nawiązywanie połączenia, zaczynają się od czterech ustawionych bajtów (0xffffffff), a ruch graczy już połączonych tego nagłówka nie ma. Na tym można oprzeć limit na adres nadawcy w nftables:

table inet l4d2 {
    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 przez nft -f. Priorytet -10 sprawia, że reguła zadziała przed łańcuchem filtrującym UFW, a @th,64,32 odczytuje pierwsze cztery bajty za nagłówkiem UDP. Zacznij hojnie i zaciskaj limit dopiero wtedy, gdy legalne zapytania w sposób sprawdzalny przechodzą: wisi na tym twój własny wpis na liście serwerów.

4. Wykorzystaj system lobby jako filtr dostępu

To dźwignia, którą mają tylko Left 4 Dead 2 i jego poprzednik. Serwer sam decyduje, czy w ogóle przyjmuje połączenia spoza matchmakingu. Określają to cztery dyrektywy w server.cfg:

sv_allow_lobby_connect_only 1
sv_search_key "twoj-wlasny-klucz"
sv_steamgroup "103582791400000000"
sv_steamgroup_exclusive 2

• sv_allow_lobby_connect_only 1 dopuszcza wyłącznie dołączenia z lobby matchmakingu. connect 203.0.113.10:27015 w konsoli deweloperskiej oraz zaproszenie Steam zostają odrzucone. Wartość 0 dopuszcza jedno i drugie.
• sv_search_key to dowolnie wybierany klucz wyszukiwania. Serwer znajdzie przez matchmaking tylko takie lobby, w którym ustawiony jest ten sam klucz. Bez tego klucza serwer nie pojawia się w wyszukiwaniu publicznym.
• sv_steamgroup wiąże serwer z grupą Steam i każe mu pojawiać się wśród serwerów tej grupy.
• sv_steamgroup_exclusive zna trzy stopnie: 0 dopuszcza każdego, 1 zachowuje się jak 0, ale wymaga dołączenia przez lobby, a 2 przepuszcza już tylko członków grupy oraz bezpośredni dostęp po adresie IP.

Dla stałej społeczności połączenie klucza wyszukiwania z sv_steamgroup_exclusive 2 to najskuteczniejszy darmowy filtr dostępu, jaki zna ta gra. Serwer publiczny nie może z niego skorzystać, bo serwer, którego nikt nie znajdzie, świeci taką samą pustką jak serwer offline.

I teraz część, którą teksty reklamowe chętnie pomijają: te dyrektywy chronią twoją logikę gry, a nie twoje łącze. Atakujący, który zalewa 27015/UDP, wcale nie chce dołączyć. Jego pakiety zostaną odrzucone, ale i tak już dotarły, zużyły przepustowość i kosztowały przebieg przez stos sieciowy. Przeciw zalewowi prób dołączenia z kont jednorazowych sv_allow_lobby_connect_only 1 działa znakomicie, przeciw booterowi nie działa wcale.

5. Rezerwacja lobby i kiedy sv_force_unreserved jest lepszym wyborem

Rezerwacja lobby to ograniczone w czasie zajęcie twojego serwera przez lobby matchmakingu. Dopóki trwa, serwer uchodzi dla innych lobby za zajęty, a wygasa sama dopiero po chwili. Dla serwera z czterema miejscami to zasób deficytowy: inaczej niż w strzelance z 32 albo 64 miejscami, wystarczy bardzo niewiele, żeby zablokować partię.

Kto nie prowadzi swojego serwera przez matchmaking, usuwa tę powierzchnię w całości:

sv_force_unreserved 1
sv_allow_lobby_connect_only 0

sv_force_unreserved 1 sprawia, że serwer nie odpowiada już na zapytania o rezerwację z systemu lobby i odrzuca dołączenia z oznaczeniem rezerwacji. To samo ustawienie i tak jest ci potrzebne, jeśli prowadzisz z L4DToolZ więcej niż cztery miejsca kooperacyjne, bo inaczej lobby dostaje rezerwację, gdy tylko zajęte zostaną pierwsze cztery miejsca, a pozostałe miejsca pozostają nieosiągalne. Druga strona medalu jest jednoznaczna: twoi gracze wchodzą wtedy już tylko przez przeglądarkę serwerów albo przez connect.

Zdecyduj się świadomie na jeden z dwóch trybów pracy. Mieszanka z połowicznie otwartego matchmakingu i połowicznie otwartego dołączania bezpośredniego to wariant, który łączy obie wady.

6. Zabezpiecz RCON

Otwarty port RCON ze słabym hasłem to nie problem DDoS, tylko przejęcie serwera. Nigdy nie zostawiaj rcon_password pustego ani zgadywalnego, w zupełności wystarczy wartość z openssl rand -base64 32. Tytuły na silniku Source mają dodatkowo hamulec na próby logowania:

rcon_password "TUTAJ_LOSOWA_WARTOSC"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

W ten sposób adres zostaje zablokowany na dobę po trzech nieudanych próbach w ciągu 30 sekund; find sv_rcon w konsoli serwera pokaże, które z tych zmiennych zna twój build. Ograniczenie na firewallu z kroku 2 i tak pozostaje skuteczniejsze, bo nie przepuszcza próby aż do aplikacji. Jeśli nie potrzebujesz RCON, zostaw hasło puste: wtedy część TCP portu 27015 nie nasłuchuje.

7. Wynieś kampanie custom zamiast wydawać je przez port gry

Kampanie custom są powodem, dla którego w Left 4 Dead 2 gra się jeszcze po piętnastu latach, a jednocześnie źródłem obciążenia, którego w tej postaci nie ma w Counter-Strike. Kampania to paczka VPK z mapami, modelami, teksturami i dźwiękami, czyli wielokrotność tego, ile waży pojedyncza mapa turniejowa.

Wygodną drogą dla graczy jest Steam Workshop: paczka przychodzi wtedy ze Steama, a nie z twojego serwera, i nie kosztuje cię przepustowości. Jeśli wydajesz luźne pliki sam, ich wydawanie należy do serwera WWW, a nie do portu gry:

sv_allowdownload 1
sv_allowupload 0
sv_downloadurl "https://cdn.example.org/l4d2/"
sv_consistency 1

Pliki dla sv_downloadurl trafiają na serwer WWW jako archiwum bzip2, z mojamapa.bsp robi się więc mojamapa.bsp.bz2. Bez sv_downloadurl srcds wysyła pliki sam przez połączenie gry, i wtedy obowiązuje zasada: każda próba połączenia nowego gracza kosztuje cię pełne pobranie, każde przerwanie w połowie pobierania tak samo. To wyjątkowo tani sposób na zapełnienie łącza, a w żadnej statystyce nie wygląda to jak atak.

Trzy punkty, które w praktyce bolą. sv_allowupload 0 należy ustawić, bo wysyłek od klienta do serwera nie potrzebujesz. Jeśli serwer WWW dla sv_downloadurl stoi na tym samym hoście co gra, pobieranie i ruch gry dzielą to samo łącze i ten sam adres IP, a atak na 443/TCP trafia wtedy także w twoją trwającą partię. A sv_consistency 1 nie jest ochroną przed atakami, tylko przed rozjeżdżającymi się plikami klienta; wyłączaj to tylko wtedy, gdy kampania w sposób sprawdzalny inaczej nie startuje.

8. SourceMod, Metamod i rozszerzenia

Znaczna część awarii zgłaszanych jako DDoS wcale nimi nie jest. To wywalanie się procesu i skoki obciążenia, które wywołuje pojedynczy klient, bo w binarce serwera albo w jakimś rozszerzeniu stoi otworem luka. Nie pomoże na to żadna przepustowość, tylko utrzymanie:

• Trzymaj Metamod:Source i SourceMod w wersji pasującej do silnika. Left 4 Dead 2 nadal dostaje aktualizacje, a niedopasowane rozszerzenie to najczęstszy powód awarii tuż po aktualizacji.
• Left4DHooks zamiast własnych ingerencji. Zdarzenia typowe dla L4D2 są w tym rozszerzeniu zebrane w jednym miejscu. Własne ingerencje w te same funkcje to najszybsza droga do binarki serwera, która wysiada przy określonych sekwencjach pakietów.
• L4DToolZ tylko świadomie. To rozszerzenie podnosi wbudowane na sztywno limity miejsc. Każde dodatkowe miejsce to dodatkowy gracz generujący czas procesora, a w połączeniu z systemem lobby wymaga sv_force_unreserved 1.
• Mniej rozszerzeń. Każdy plugin to kod w tym samym procesie. Rozszerzenia z własnymi usługami webowymi otwierają kolejne porty i często publikują dokładnie ten adres, który chcesz chronić.

Bany trzeba zapisywać trwale, inaczej po restarcie ich nie ma. Tytuły na silniku Source mają do tego banid z writeid oraz addip z writeip, a powstałe pliki wczytuje się z powrotem przez exec banned_user.cfg i exec banned_ip.cfg.

9. Odciąż śledzenie połączeń i bufor odbiorczy

Ten punkt bywa pomijany i wyjaśnia awarie, które wyglądają jak atak wolumetryczny, choć nim nie są. Kernel zakłada dla ruchu UDP wpisy w śledzeniu połączeń (conntrack), a przy podrobionych adresach nadawcy każdy adres oznacza nowy wpis. Kiedy tablica jest pełna, kernel odrzuca pakiety bez różnicy: atak i twoi gracze wylatują razem. Stan i górny limit pokazuje jedno spojrzenie:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Najskuteczniejszym krokiem jest w ogóle nie śledzić ruchu gry, bo silnik zarządza swoimi sesjami sam:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport 27015 notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport 27015 notrack
    }
}

W iptables odpowiednikiem jest iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK oraz ta sama linia dla OUTPUT z --sport. Port potrzebuje potem wyraźnego otwarcia, bo bez śledzenia nie zadziała już żadna reguła sprawdzająca istniejący stan połączenia. Jeśli pakiety docierają szybciej, niż srcds je odbiera, przepełnia się dodatkowo bufor odbiorczy, a dla graczy wygląda to jak utrata pakietów na wolnym łączu:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Plik odkładasz w /etc/sysctl.d/ i aktywujesz przez sysctl -p. Czy te wartości są w ogóle potrzebne, zdradzi sam kernel: jeśli UdpRcvbufErrors w nstat -az rośnie, to znaczy, że działają. Jeśli licznik stoi na zerze, zmiana niczego nie da. To zapas, a nie ochrona.

10. Mierz, żeby w trakcie ataku nie zgadywać

W trakcie ataku najważniejsze pytanie brzmi: ile tego dociera, na którym porcie i czy to ruch zapytań, czy ruch gry. Wystarczą cztery polecenia:

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

Pierwsze polecenie wykonaj dwa razy w odstępie dziesięciu sekund, wtedy dostaniesz tempo zamiast wartości bezwzględnej. Ostatnia linia pokazuje wyłącznie pakiety bezpołączeniowe, czyli dokładnie tę klasę, którą wykorzystuje zalew zapytań; jeśli licznik zapełnia się w kilka sekund, choć prawie nikt nie jest połączony, masz swoją odpowiedź. Trzymaj taki zrzut krótko, bo pod obciążeniem sam kosztuje czas procesora. Jak odczytać te wartości, opisuje wpis Jak rozpoznać atak DDoS na serwerze.

Najważniejszy krok to jednak 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 z pełnym serwerem Versus.

Gdzie te działania się kończą

Teraz część uczciwa. Wszystko opisane do tej pory zadziała dopiero wtedy, gdy pakiety dotarły już na twoją kartę sieciową. 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ę. Przy najmniejszym możliwym rozmiarze pakietu łącze to przenosi około 1,49 miliona pakietów na sekundę, a łącze 10 Gbit/s około 14,88 miliona. To granica fizyczna, niezależna od procesora, kernela i firewalla. 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 mimo to wszystko padło”.

Po drugiej stronie stoją realne ataki. Dwa przykłady z ruchu produkcyjnego w KernelHoście, oba odfiltrowane w czasie rzeczywistym: flood UDP na serwer gry na porcie 7777/UDP z ponad 112,2 Gbit/s i ponad 8,7 miliona pakietów na sekundę oraz atak wielowektorowy na serwer głosowy na porcie 9987/UDP z ponad 473,4 Gbit/s i ponad 41,5 miliona pakietów na sekundę. Przelicz to na swoje łącze: 473,4 Gbit/s to około 470-krotność łącza 1 Gbit/s i wciąż około 47-krotność łącza 10 Gbit/s.

Dlatego dwa rozpowszechnione hamulce awaryjne nie zadowalają. Null-routing (blackholing) zdejmuje atakowany adres IP z sieci i kończy wprawdzie atak, ale razem z nim twój serwer: dla twoich graczy wynik jest identyczny z udanym atakiem. Reaktywne przekierowanie ruchu kosztuje w czasie przełączania dokładnie te minuty, w których rozstrzyga się kampania. Skuteczne jest wyłącznie filtrowanie, które działa nieprzerwanie w sieci przed serwerem.

Co przeciwstawia temu KernelHost

Stała ochrona wliczona w każdy serwer

Ochrona DDoS w KernelHoście jest zbudowana dwustopniowo i działa nieprzerwanie, bez konieczności włączania, zamawiania czy konfigurowania czegokolwiek:

• Stopień 1: 17 Tbps pojemności mitygacji w globalnej sieci scrubbingowej. Ataki wolumetryczne są oczyszczane blisko źródła, na długo zanim dotrą do centrum danych.
• Stopień 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 na warstwach od 3 do 7, pakiet po pakiecie.

Decydujące są dwie cechy. Po pierwsze filtrowanie działa nieprzerwanie, nie ma więc czasu przełączania, w którym twoi gracze wylatują. Po drugie nie stosuje się null-routingu: atakowany adres IP zostaje w sieci, odrzucane są wyłącznie szkodliwe pakiety. Ochrona jest zawarta w każdym pakiecie serwerowym bez dopłat, bez osobnego pakietu ochronnego i bez konfiguracji, a działa od momentu udostępnienia serwera. Serwery stoją w maincubes Premium Datacenter we Frankfurcie 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, zmiennymi wzorcami i zawsze dokładnie w umówiony wieczór kampanii. Dla takich przypadków 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. Twój serwer zostaje na niego przełączony w naszej sieci, przebudowa po twojej stronie nie jest potrzebna.
• Samodzielnie zarządzane reguły ochrony na port i protokół. W panelu klienta ustalasz, który port ma być filtrowany jakim profilem, czyli 27015/UDP inaczej niż serwer WWW wydający twoje kampanie.
• Zmiany działają w czasie rzeczywistym, bez zgłoszenia i bez czekania. Możesz więc korygować ustawienia w trakcie trwającego ataku.
• Profil ochrony dopasowany do konkretnej gry. Zarówno dla Left 4 Dead 2 i pozostałych tytułów na silniku Source, jak i dla ponad 40 innych gier oraz protokołów, do tego swobodne profile TCP i UDP dla zmodyfikowanych serwerów.

Także tutaj obowiązuje model PrePaid: bez minimalnego okresu umowy, bez okresu wypowiedzenia, bez umowy i bez opłaty aktywacyjnej. Kiedy fala ataków minie, po prostu nie przedłużasz.

Porównanie obu stopni

Dla większości projektów Left 4 Dead 2 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 zniknął z wyszukiwania lobby, ale działa dalej: najczęściej 27015/UDP został zablokowany ogólnie albo obłożony zbyt ciasnym limitem, a ponieważ ruch gry i zapytania dzielą ten sam port, zgrubna reguła trafia w jedno i drugie. Pracuj zamiast tego z dopasowaniem do pakietów bezpołączeniowych. Jeśli port jest osiągalny, a serwer mimo to pozostaje niewidoczny, sprawdź sv_search_key, sv_steamgroup_exclusive, sv_lan 0 i sv_region 255 oraz to, czy start nie nastąpił przypadkiem z -nomaster.

W konsoli serwera stoi bez przerwy „Invalid split packet length”: to nie atak wolumetryczny, tylko błędnie złożony pakiet sieciowy wysyłany w szybkiej serii. Ruch pozostaje przy tym mikroskopijny, a serwer i tak się tnie. Sprawdź najpierw, czy przepustowość w ogóle zwraca uwagę, i doprowadź binarkę serwera oraz rozszerzenia do aktualnej wersji. Przepustowość nic tu nie da.

Wszyscy gracze mają wysoki ping, a łącze nie jest pełne: to wskazuje na liczbę pakietów, a nie na wolumen. Obejrzyj odrzucone pakiety w ip -s link show oraz liczniki UDP w nstat -az. Jeśli w logu systemowym stoi nf_conntrack: table full, wyjmij port gry przez notrack.

Reguła firewalla jest poprawna, a mimo to nie działa: sprawdź przez iptables -L INPUT -n -v, czy liczniki trafień rosną. Jeśli stoją na zerze, reguła nie jest osiągana, bo stoi za łańcuchami UFW albo zginęła po ostatnim restarcie. Jeśli rosną, a nic się nie zmienia, wysycone jest łącze przed serwerem, i od tego miejsca pomaga wyłącznie filtrowanie w sieci.

Serwer nie przyjmuje już graczy, choć miejsca są wolne: najczęściej wisi rezerwacja lobby. Albo prowadzisz serwer konsekwentnie przez matchmaking, albo ustawiasz sv_force_unreserved 1 i pozwalasz graczom dołączać przez przeglądarkę serwerów. Przy więcej niż czterech miejscach kooperacyjnych z L4DToolZ to ustawienie i tak jest obowiązkowe.

Nowi gracze ładują się w nieskończoność, a łącze jest przy tym pełne: wtedy srcds wydaje pliki kampanii sam przez port gry. Ustaw sv_downloadurl na serwer WWW i odłóż tam pliki jako archiwum bzip2 albo odeślij graczy do Steam Workshop.

Atak milknie po zmianie adresu IP i wraca po jednym, dwóch dniach: to normalny przebieg, bo twój serwer sam publikuje nowy adres, gdy tylko znów się zarejestruje, a zapomniany wpis DNS albo bot Discord ze statusem robi resztę. Zmiana adresu IP daje godziny, a nie rozwiązanie.

Na serwerze wykonują się cudze polecenia administracyjne: to nie atak DDoS, tylko przejęty dostęp RCON. Natychmiast zmień hasło i ogranicz część TCP portu 27015 do własnego adresu.

Krótkie podsumowanie

• Serwer Left 4 Dead 2 potrzebuje na zewnątrz dokładnie jednego otwartego portu: 27015/UDP. Ruch gry i zapytanie A2S dzielą go między siebie, osobnego portu zapytań nie ma.
• 27015/TCP to RCON i należy go otwierać wyłącznie dla własnego adresu. Kto RCON nie potrzebuje, zostawia rcon_password puste.
• System lobby to najskuteczniejszy darmowy filtr dostępu, jaki zna ta gra: sv_allow_lobby_connect_only 1, własny sv_search_key oraz sv_steamgroup_exclusive 2 odcinają wszystko, co nie przychodzi przez matchmaking. Filtruje dołączenia, a nie pakiety.
• Kampanie custom należą do Steam Workshop albo za sv_downloadurl, nigdy na port gry. Inaczej każda przerwana próba połączenia płaci twoją przepustowością.
• Limit musi rozróżniać pakiety bezpołączeniowe (zaczynające się od 0xffffffff) i ruch gry. Zgrubna reguła na 27015/UDP wyrzuca twoich własnych graczy.
• Przy pakietach po 64 bajty łącze 1 Gbit/s przenosi około 1,49 miliona pakietów na sekundę. Powyżej tego decyduje wyłącznie sieć przed serwerem, a nie ustawienie na samym serwerze.
• W KernelHoście 17 Tbps globalnego scrubbingu oraz filtrowanie Arbor w czasie rzeczywistym o wydajności 3,2 Tbps we Frankfurcie nad Menem filtrują nieprzerwanie i bez dopłat, bez null-routingu i bez czasu przełączania.

Jeśli twój projekt 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 nasz zespół dostroił reguły filtrowania dla twojego adresu IP. 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 (gracze wylatują, serwera nie ma w wyszukiwaniu lobby, wysoki ping). To oszczędza jedną rundę dopytywania, a ona liczy się wtedy, gdy trwa kampania.

Jeśli hostujesz gdzie indziej i jesteś regularnie ostrzeliwany, przeprowadzka do KernelHosta jest drogą krótszą niż każda kolejna reguła na serwerze, którego łącze kończy się wcześniej. Stała ochrona jest częścią każdego pakietu serwerowego, a nie dodatkiem, który wykupujesz dopiero w razie potrzeby.