Ochrona serwera Project Zomboid przed atakami DDoS

Kto chce chronić swój serwer Project Zomboid przed atakami DDoS, musi najpierw wiedzieć, w co atakujący w ogóle strzela. Serwer dedykowany zajmuje dokładnie dwa porty UDP, 16261 i 16262, i oba muszą stać otwarte w sieci, bo inaczej nikt nie dołączy. Ten wpis idzie w kolejności, która liczy się w sytuacji poważnej: 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ę technicznie, a na koniec to, co musi wydarzyć się przed serwerem w sieci.

Wszystkie informacje dotyczą serwera dedykowanego (Steam-App 380870) na Debianie 12, Debianie 13, Ubuntu 22.04 LTS albo Ubuntu 24.04 LTS, zarówno dla builda 41, jak i builda 42. Plik konfiguracyjny nazywa się servertest.ini i leży w ~/Zomboid/Server/, dane świata leżą w ~/Zomboid/Saves/Multiplayer/. 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 teraz niczego w servertest.ini i nie restartuj serwera. Zabezpiecz najpierw pomiary (sekcja 9), po ataku już ich nie będzie. Restart kosztuje dodatkowo czas, którego serwer potrzebuje na wczytanie świata, a właśnie ten czas atakujący chce ci zabrać.

Dlaczego serwery Project Zomboid stają się celem ataków DDoS

Project Zomboid to gra z trwałą śmiercią i światem, który toczy się przez miesiące. Zerwane połączenie w środku niebezpiecznej sytuacji kosztuje tutaj więcej niż w prawie każdym innym gatunku: postać przepada, a świat to pamięta. Właśnie to czyni z awarii broń. Atak o 20:00 trafia stałą społeczność i trafia ją w miejscu, w którym ma ona najwięcej do stracenia.

Do tego dochodzi fakt, że sam atak nic nie kosztuje i nie wymaga umiejętności. Wynajmowane usługi ataku, w środowisku nazywane booterami albo stresserami, kierują się kilkoma kliknięciami przeciw adresowi IP i portowi, a w Project Zomboid cel jest zawsze ten sam: 16261 UDP. Kto jest w sporze z zbanowanym graczem albo prowadzi konkurencyjną społeczność, ma tym samym w ręku narzędzie, do którego nie potrzebuje ani wiedzy, ani liczących się pieniędzy.

Do tego dochodzi fakt, że serwer gier musi opublikować swój adres. Jeśli w servertest.ini stoi Public=true, serwer pojawia się w przeglądarce gry, a serwer z podpięciem do Steama i tak jest widoczny w przeglądarce serwerów Steam. Pytanie nigdy nie brzmi więc, czy atakujący znajdzie twój adres IP, tylko co się stanie, gdy w niego strzeli.

Technicznie najbardziej nieprzyjemna część przychodzi na koniec: cały ruch gry idzie przez UDP. UDP nie zna nawiązywania połączenia, którego można by wymagać, każdy pakiet stoi sam za siebie, a adres nadawcy da się podrobić. Atakujący nie musi więc ani wchodzić na twój serwer, ani poprawnie się z nim komunikować, żeby wygenerować obciążenie. Czym dokładnie jest atak DDoS, wyjaśnia wpis Czym jest atak DDoS?.

Których portów serwer Project Zomboid naprawdę potrzebuje

Dedykowany serwer Project Zomboid potrzebuje dokładnie dwóch otwartych portów: 16261 UDP i 16262 UDP. Oficjalna lista portów gry nie wymienia trzeciego. W servertest.ini stoją one jako dwie osobne dyrektywy, drugi port nie wynika automatycznie z pierwszego:

DefaultPort=16261
UDPPort=16262
SteamPort1=8766
SteamPort2=8767
RCONPort=27015
RCONPassword=

Podział zadań jest jednoznaczny. 16261 UDP niesie ruch gry i nawiązywanie połączenia oraz odpowiada na zapytania przeglądarki serwerów. 16262 UDP to port połączenia bezpośredniego klientów. Brakuje pierwszego, to nikt serwera nie znajdzie, brakuje drugiego, to twoi gracze widzą wpis, a mimo to nie wchodzą do środka. Stąd właśnie bierze się najbardziej znany komunikat błędu tej gry, że port 16262 jest zamknięty.

Dwa punkty, które regularnie sprawiają kłopoty. Po pierwsze: każda instancja serwera potrzebuje dwóch wolnych portów UDP. Kto prowadzi drugi świat na tej samej maszynie, przydziela na to drugą parę, na przykład 16274 i 16275, i wpisuje obie wartości do servertest.ini drugiej instancji. Po drugie: SteamPort1 i SteamPort2 stoją w pliku konfiguracyjnym z wartościami 8766 i 8767, należą jednak do podpięcia do Steama, a nie do ruchu gry. Otwieraj je tylko wtedy, gdy bez nich twój serwer nie pojawia się na liście Steam, a nie zapobiegawczo.

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

Ten rozdział jest najdłuższy i to celowo. Czysto skonfigurowany serwer wytrzyma małe i średnie ataki o własnych siłach, niezależnie od tego, u kogo stoi. Ataku wolumetrycznego ci nie zdejmie, ale sprawi, że tanie ataki pozostaną bez skutku, a w sytuacji poważnej będziesz miał liczby zamiast przypuszczeń.

1. Inwentaryzacja: co naprawdę nasłuchuje

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

ss -lntup

Interesuje cię kolumna z adresem lokalnym. 0.0.0.0:16261 oraz [::]:16261 oznaczają „osiągalny z całego internetu”, 127.0.0.1:27015 oznacza „tylko lokalnie” i nie potrzebuje żadnej reguły zezwalającej. Porównaj wynik ze swoją konfiguracją, zamiast polegać na wartościach domyślnych:

grep -E "^(DefaultPort|UDPPort|SteamPort1|SteamPort2|RCONPort|Public|Open|MaxPlayers|MaxAccountsPerUser)=" ~/Zomboid/Server/servertest.ini

Spojrzenie oczami atakującego daje skan portów z zewnątrz. Ponieważ Project Zomboid używa wyłącznie UDP, potrzebny jest do tego skan UDP, a czysty skan TCP w ogóle nie pokaże portu gry:

nmap -Pn -sU -p 16261,16262,8766,8767 TWOJ.ADRES.IP.SERWERA
nmap -Pn -p- --min-rate 1000 TWOJ.ADRES.IP.SERWERA

2. Zostaw otwarte tylko 16261 i 16262

Dwie reguły zezwalające na zewnątrz wystarczą, 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 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid połączenie bezpośrednie"
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. O tym, czy zamkniesz dostęp samemu sobie, decyduje kolejność przy uzbrajaniu firewalla. Stoi ona razem z drogą powrotną we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu. Gdyby jednak do tego doszło: przy serwerach root KVM i serwerach dedykowanych od KernelHost dotrzesz do systemu przez konsolę VNC w panelu klienta, która pracuje niezależnie od sieci systemu gościa.

Słowo o bazach danych i usługach dodatkowych: Project Zomboid ich nie potrzebuje. Co obok gry nasłuchuje na 0.0.0.0, pochodzi z wcześniejszej instalacji albo z panelu zarządzania i należy albo związać z 127.0.0.1, albo wyłączyć.

3. Zdejmij RCON na porcie 27015 z internetu

RCON to zdalne sterowanie serwerem i działa w Project Zomboid na 27015 TCP. W dostarczonym pliku servertest.ini stoi RCONPassword= bez wartości. Kto korzysta z RCON, ustawia długie losowe hasło, bo protokół przesyła bez szyfrowania, a osiągalny port RCON ze słabym hasłem oddaje serwer w całości, i to bez potrzeby wysyłania choćby jednego pakietu ruchu atakującego.

Bezpieczna droga to w ogóle nie otwierać portu na zewnątrz i dostawać się do niego przez przekierowanie portu po SSH. Potem rozmawiasz lokalnie z 127.0.0.1:27015:

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

Kto nie potrzebuje RCON, zostawia pole hasła puste, a port zamknięty. Usługa, która nie jest osiągalna, nie zostanie ani przełamana zgadywaniem, ani zalana.

4. Ogranicz liczbę pakietów na adres źródłowy

Przeciw małym atakom i niechlujnym botom pomaga górny limit na adres źródłowy. Ponieważ oba porty gry leżą obok siebie, wystarczy jedna reguła na cały zakres:

iptables -I INPUT -p udp --dport 16261:16262 -m hashlimit --hashlimit-name pz_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP
iptables -L INPUT -n -v

Reguła odrzuca pakiety UDP, gdy ten sam adres źródłowy wysyła trwale więcej niż 400 pakietów na sekundę. Wartość jest wartością startową, a nie prawdą objawioną: serwer z 30 graczami w tym samym mieście generuje wyraźnie więcej ruchu niż taki z czterema graczami w różnych zakątkach mapy, a kto ustawi limit zbyt ciasno, wyrzuci własnych graczy. Najpierw mierz przez tydzień w normalnej pracy, a potem ustaw granicę na wielokrotność wartości szczytowej.

Dwie uwagi do tego. Same reguły iptables znikają po restarcie, na Debianie i Ubuntu zabezpiecza 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ź licznikami trafień z iptables -L INPUT -n -v, czy reguła jest w ogóle osiągana. Jeśli liczniki stoją na zerze, reguła stoi w złym miejscu.

5. Odciąż śledzenie połączeń

Często przeoczone wąskie gardło siedzi w kernelu. Śledzenie połączeń zakłada także dla UDP wpis na adres źródłowy i port, a flood z podrobionymi nadawcami zapełnia tę tablicę w sekundy. Gdy się przepełni, serwer odrzuca także legalne pakiety, a w logu stoi „nf_conntrack: table full”. Stan i górny limit pokazuje:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Ruch gry Project Zomboid nie potrzebuje śledzenia stanu, bo UDP stanu nie ma. Możesz więc trzymać oba porty gry poza tablicą:

iptables -t raw -I PREROUTING -p udp --dport 16261:16262 -j NOTRACK

To odczuwalnie odciąża kernel. Ważne: reguła pasuje tylko tak długo, jak długo serwer dostaje pakiety bezpośrednio. Kto prowadzi przed nim translację adresów, na przykład w układzie kontenerowym z przekazywaniem portów, nie może jej ustawiać, bo kierunek powrotny nie zostanie już przypisany.

6. Zabezpiecz dołączanie i sloty

Następne wiersze nic nie kosztują i działają przeciw wszystkiemu, co przychodzi zwykłą drogą dołączania:

Password=DLUGIE-LOSOWE-HASLO
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password to wspólne hasło serwera i jest oddzielone od konta pojedynczego gracza. Open=false oznacza, że dołączyć mogą tylko konta wcześniej założone przez administratora, i to jest whitelista tej gry. MaxAccountsPerUser ogranicza, ile kont może założyć na twoim serwerze pojedynczy użytkownik Steam, a wartość domyślna 0 oznacza bez ograniczeń. MaxPlayers stoi fabrycznie na 32, a powyżej tej wartości dokumentacja wyraźnie ostrzega przed złym doczytywaniem mapy i desynchronizacją.

PingLimit jest w tym miejscu pułapką. Dyrektywa wyrzuca graczy od pewnego opóźnienia w milisekundach i stoi fabrycznie na 0, czyli jest wyłączona. Pod atakiem opóźnienie twoich własnych graczy rośnie jako pierwsze, więc ciasna wartość wykopuje dokładnie tych ludzi, których chcesz zatrzymać. Zostaw tę granicę wyłączoną albo ustaw ją hojnie.

I jedno musi być jasne: whitelista chroni twoją logikę gry, a nie twoje łącze. Atakujący, który zalewa twój serwer, wcale nie chce dołączyć. Jego pakiety zostaną odrzucone, ale i tak już dotarły, i o to właśnie chodzi.

7. Porównanie modów przy łączeniu to najdroższa sekunda twojego serwera

Project Zomboid sprawdza przy łączeniu więcej niż hasło. Lista modów serwera stoi w dwóch wierszach servertest.ini: WorkshopItems zawiera numeryczne identyfikatory Workshopu, a Mods identyfikatory ładowania modów, obie rozdzielone średnikami. Przy dołączaniu klient porównuje tę listę, dociąga brakujące treści Workshopu automatycznie przez Steama i dopiero potem dostaje strumieniowo dane świata. Dodatkowo przy DoLuaChecksum=true serwer porównuje sumy kontrolne plików gry i wyrzuca klientów, których pliki do jego plików nie pasują.

Dla atakującego interesujące jest dokładnie to, bo praca przypada przed właściwym udziałem w grze. Każda próba połączenia kosztuje serwer czas procesora na wersję, sumę kontrolną, listę modów i dane mapy, także ta próba, która na końcu zostaje odrzucona. Długa lista modów czyni każdą z tych prób droższą. Flood dołączeń jest więc na mocno zmodyfikowanym serwerze skuteczniejszy niż na niezmienionym, a potrzebuje do tego ułamka przepustowości ataku wolumetrycznego. Gra ma przeciw temu dwa wbudowane hamulce:

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

DenyLoginOnOverloadedServer odrzuca nowe logowania, dopóki serwer jest przeciążony, zamiast zrywać razem z nimi trwającą rozgrywkę. LoginQueueEnabled ustawia dołączających w kolejkę, zamiast obsługiwać ich jednocześnie, a LoginQueueConnectTimeout ustala, jak długo może trwać dołączenie, wartość domyślna to 60 sekund, dozwolone jest od 20 do 1200.

Jeden szczegół do tego należy, bo bywa rozwiązywany błędnie: na serwerach linuksowych istnieje udokumentowany błąd, przy którym DoLuaChecksum podnosi fałszywy alarm i nie wpuszcza graczy. Operatorzy wyłączają dlatego tę kontrolę. To zrozumiałe, ale usuwa mechanizm, który trzyma z dala klientów ze zmienionymi plikami gry. Kto musi ją wyłączyć, powinien tym surowiej ustawić hasło serwera, whitelistę i limit kont.

8. Lista serwerów, UPnP i własny adres

Tutaj opłaca się szczerość zamiast myślenia życzeniowego: twojego adresu IP nie da się utrzymać w tajemnicy. Public=true pokazuje serwer w przeglądarce gry, a serwer z podpięciem do Steama jest według dokumentacji i tak widoczny w przeglądarce serwerów Steam. Public=false odbiera ci więc widoczność dla nowych graczy, nie czyniąc cię niewidzialnym.

Public=true
PublicName=Mój serwer Zomboid
UPnP=false
server_browser_announced_ip=

UPnP stoi fabrycznie na true i każe serwerowi próbować samodzielnie ustawić przekierowanie portu na bramie internetowej. Na wynajętym serwerze takiej bramy nie ma, próba idzie w pustkę i należy ją wyłączyć. server_browser_announced_ip zostaje puste, chyba że twój serwer ma kilka adresów i ma pojawiać się celowo pod jednym z nich. Dokładnie tego pola potrzebujesz później znowu, gdy przejdziesz na dedykowany chroniony adres IP.

Dwa nawyki pomagają bardziej niż jakiekolwiek ustawienie. Nigdzie nie publikuj surowego adresu IP samodzielnie, czyli ani na kanale Discord, ani na stronie projektu, i daj swoim graczom nazwę hosta. Klasykiem przy zmianie adresu są stare wpisy DNS: zapomniany rekord A wskazujący na poprzedni adres unieważnia każdą zmianę.

9. Mierz, dopóki wszystko działa normalnie

Najważniejszy krok to ten, którego prawie nikt nie robi wcześniej: przygotuj bazę porównawczą, dopóki jest spokojnie. Bez wartości normalnej po incydencie nie powiesz, czy 40 000 pakietów na sekundę to dużo, czy po prostu sobotni 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
tcpdump -ni eth0 "udp port 16261 or udp port 16262" -c 200 -q
journalctl -u zomboid --since "-15 min" | tail -50

Dwa pierwsze pokazują liczbę pakietów i liczniki odrzuceń na interfejsie, trzecie krótką próbkę ruchu, a czwarte komunikaty serwera, o ile działa on jako usługa systemd (nazwę usługi dostosuj). Przy tcpdump obowiązuje zasada: zawsze ograniczaj przez -c, bo zrzut przy pełnym obciążeniu dodatkowo obciąża i tak przeciążony serwer. Jak oceniać 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.

Policz to razem ze mną. 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 na sekundę i uderza ona często wcześniej niż przepustowość: przy małych pakietach po 64 bajty w 1 Gbit/s mieści się około 1,49 miliona pakietów na sekundę, podczas gdy zwykły kernel serwera przetworzy z tego, zależnie od CPU i karty sieciowej, tylko kilkaset tysięcy, 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. Operatorzy przeżywają to jako „przecież obciążenie wcale nie było wysokie, a i tak wszystko padło”.

Zwykłe ataki na społeczności serwerów gier mieszczą się między 5 a 50 Gbit/s, czyli od pięciu do pięćdziesięciu razy powyżej normalnego łącza. Na to nie ma żadnego ustawienia lokalnego. Ataki wolumetryczne muszą kończyć się w sieci przed serwerem.

Co KernelHost stawia przeciw atakom DDoS na serwery gier

Stała ochrona, która jest 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 projekty są atakowane nie okazjonalnie, tylko celowo i przez wiele tygodni. Dla nich jest Advanced DDoS Protection od 50,00 € miesięcznie, w modelu PrePaid, bez minimalnego okresu umowy i bez opłaty aktywacyjnej. 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ć, nowy adres wpisujesz jedynie tam, gdzie twoi gracze znajdują serwer.
• Samodzielnie zarządzane reguły ochrony na port i protokół w panelu klienta: ustalasz, co jest dozwolone na 16261 i 16262 UDP, a cała reszta zostaje zamknięta, bez pisania zgłoszenia.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku.
• Pasujący profil ochrony. Dla popularnych gier istnieją gotowe profile, a dla zmodyfikowanych i własnych aplikacji ustawiasz reguły na port i protokół sam. Project Zomboid daje się przy tym ograniczyć szczególnie dokładnie, bo cały ruch gry idzie przez dwa sąsiadujące porty UDP.

Porównanie obu stopni

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

Typowe błędy i ich rozwiązania

„Moi gracze dostają komunikat, że port 16262 jest zamknięty”: to nie atak, tylko brakująca reguła zezwalająca. Serwer potrzebuje obu portów, 16261 UDP i 16262 UDP, i to jako reguły UDP. Zezwolenie TCP na tych samych numerach nie da nic. Sprawdź przez ufw status verbose oraz skanem UDP z zewnątrz, czy naprawdę oba są otwarte.

„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, od bota Discord ze statusem albo ze starego wpisu DNS. W Project Zomboid zmiana kosztuje dodatkowo: klienty odkładają dane mapy lokalnie pod adresem i portem, w folderze według wzorca 123.45.0.12_16261_... w Zomboid/Saves. Po zmianie każdy gracz pobiera poznaną mapę na nowo z serwera. Zmiana adresu to więc zysk na czasie z kosztami dodatkowymi, a nie rozwiązanie.

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

„Gracze wylatują przy dołączaniu, ale serwer działa dalej normalnie”: to prawie zawsze porównanie plików, a nie atak. Przyczyną jest różnica wersji między klientem a serwerem, brakujący albo przestarzały wpis Workshopu lub suma kontrolna, która nie pasuje. Klient podaje z reguły mody, które się nie zgadzają. Porównaj WorkshopItems i Mods wiersz po wierszu.

„Co kilka minut skoki lagów, potem znowu działa”: to zwykły wzorzec krótkich ataków, które trwają tylko tak długo, aż zirytowani gracze przestaną grać. Spójrz najpierw na liczniki sieciowe, a nie na obciążenie CPU. Jeśli sar -n DEV 1 10 i liczniki odrzuceń pozostają niepodejrzane, to nie był atak, tylko obciążenie: zbyt wielu graczy w tej samej komórce, drogi mod albo za mało pamięci operacyjnej dla instancji Javy.

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

Krótkie podsumowanie

• Dedykowany serwer Project Zomboid potrzebuje dokładnie dwóch otwartych portów: 16261 UDP (DefaultPort) i 16262 UDP (UDPPort). Oba stoją jako osobne dyrektywy w servertest.ini.
• RCON działa na 27015 TCP i jest fabrycznie wpisany bez hasła. Ten port nie należy do otwartego internetu, tylko ma być ograniczony do własnego adresu albo zamknięty.
• Porównanie modów przy łączeniu to najdroższe miejsce: wersja, suma kontrolna, lista Workshopu i dane mapy kosztują czas procesora, także przy każdej odrzuconej próbie. DenyLoginOnOverloadedServer i kolejka dołączania są przeciw temu wbudowanymi hamulcami.
• Hasło serwera, Open=false i MaxAccountsPerUser=1 chronią logikę gry. Przeciw wysyconemu łączu nie działa żadne z tych ustawień.
• Granica fizyczna jest stała: 1 Gbit/s to 125 megabajtów na sekundę, a przy pakietach po 64 bajty około 1,49 miliona pakietów na sekundę. Zwykłe ataki na serwery gier mieszczą się w przedziale od 5 do 50 Gbit/s.
• Ataki wolumetryczne muszą kończyć się w sieci przed serwerem. W KernelHoście to 17 Tbps pojemności mitygacji w globalnej sieci scrubbing oraz filtrowanie Arbor w czasie rzeczywistym o wydajności 3,2 Tbps we Frankfurcie nad Menem, bez dopłat i bez null-routingu.
• Kto jest ostrzeliwany stale, steruje filtrowaniem sam dzięki Advanced DDoS Protection: dedykowany chroniony adres IP, reguły na port i protokół, zmiany w czasie rzeczywistym, od 50,00 € miesięcznie.

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.