Ochrona serwera DayZ przed atakami DDoS

Serwer DayZ, który wieczorem w środku rozgrywki wyrzuca wszystkich graczy, a potem na kilka minut znika z przeglądarki serwerów, rzadko ma problem ze sprzętem. Najczęściej trwa atak, i to dokładnie wtedy, gdy online jest najwięcej graczy albo gdy zbliża się zaplanowany restart. Kto chce chronić swój serwer DayZ przed atakami DDoS, potrzebuje dlatego obu rzeczy: czystego otwarcia portów na serwerze i filtrowania w sieci przed nim. Ten artykuł pokazuje najpierw, co możesz zabezpieczyć sam i bez dodatkowych kosztów, potem, gdzie te działania kończą się technicznie, a na koniec, co musi wtedy wydarzyć się przed serwerem.

Wszystkie informacje dotyczą własnego dedykowanego serwera DayZ z plikiem serverDZ.cfg, niezależnie od tego, czy działa pod Windows Server, czy pod Debianem i Ubuntu przez warstwę zgodności. Gotowego do produkcji, natywnego programu serwerowego dla Linuksa w gałęzi stable Bohemia Interactive nie dostarcza, a eksperymentalny build dla Linuksa przyjmuje wyłącznie eksperymentalnych klientów. Polecenia linuksowe 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 serverDZ.cfg i nie restartuj serwera. Restart DayZ ładuje od nowa mody i centralną ekonomię, i kosztuje cię kilka minut, w których serwer jest gwarantowanie offline. Zabezpiecz najpierw pomiary (patrz rozdział „Prowadź logi”), po ataku już ich nie będzie.

Dlaczego serwery DayZ tak często są celem ataków DDoS

DayZ łączy kilka cech, które czynią z serwera wygodny cel. Po pierwsze serwer społecznościowy sam publikuje swój adres: żeby pojawić się w przeglądarce serwerów w grze i w launcherze DZSA, musi odpowiadać na zapytania Steam, a ta odpowiedź zawiera adres IP i port otwartym tekstem. Atakujący nie musi więc niczego ustalać, musi tylko przeczytać listę.

Po drugie, rozkład dnia serwera DayZ jest publiczny. Praktycznie wszystkie projekty restartują się automatycznie co trzy do czterech godzin, zapowiadają to wiadomością na czacie i wpisują plan na Discorda. Atak, który trafia dokładnie w to okno czasowe, działa podwójnie: serwer i tak właśnie jest nieosiągalny, a gracze, którzy wiszą w poczekalni, idą gdzie indziej.

Po trzecie, stawka dla graczy jest wysoka. Awaria w niewłaściwej minucie oznacza w DayZ nie tylko frustrację, ale utracone wyposażenie, przerwane raidy i bazę, która stoi w świecie bez ochrony. Właśnie dlatego najczęstszymi zlecającymi są zbanowani gracze, skłócone grupy i konkurencyjne projekty. Atak przez jedną z typowych usług booter nie kosztuje zlecającego ani umiejętności, ani liczących się pieniędzy.

Po czwarte, cały ruch DayZ idzie przez UDP. UDP nie zna nawiązywania połączenia, którego można by wymagać, 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. Że dotyczy to nawet samego producenta, pokazał luty 2025: usługi online Bohemia Interactive dla DayZ i Arma Reforger leżały ponad tydzień pod ostrzałem DDoS, co potwierdzono 3 lutego 2025 i co 6 lutego 2025 wciąż się nie skończyło, a serwery społecznościowe zostały tym dotknięte razem z nimi. Czym atak DDoS jest w szczegółach, wyjaśnia artykuł Czym jest atak DDoS?.

Porty serwera DayZ: tabela faktów

Serwer DayZ mówi wyłącznie przez UDP. Portu gry po TCP nie ma. Jedyną wartością, która w DayZ naprawdę stoi na stałe, jest 2302/UDP jako port gry, cała reszta jest konfigurowalna i różni się zależnie od hostera. Sprawdź dlatego we własnym wierszu startowym i we własnym pliku serverDZ.cfg, zamiast polegać na wartości domyślnej.

Dwie wartości regularnie powodują zamieszanie, dlatego tutaj rozwiązanie. Port zapytań Steam: przykładowa konfiguracja dostarczana przez Bohemię ustawia steamQueryPort = 2305;, podczas gdy duża część hosterów używa 27016/UDP. Obie wartości są prawidłowe, decyduje wyłącznie wartość w twoim pliku. Port BattlEye RCon: tutaj nie ma w ogóle żadnego wiążącego standardu. Rozpowszechniona reguła kciuka to port gry plus trzy, czyli 2305, inni hosterzy ustawiają 2310. Od DayZ 1.13 BattlEye wczytuje parametr RConPort w pliku BEServer_x64.cfg niezawodnie, wcześniej port był trudny do przewidzenia.

Wynika z tego pułapka, która trafia wielu operatorów: nigdy nie ustawiaj steamQueryPort i RConPort na tę samą wartość. Jeśli twoja konfiguracja przewiduje 2305 dla zapytania Steam, RCon należy na inny port, na przykład 2310.

Dlaczego port zapytań Steam jest portem najwrażliwszym

Port zapytań Steam odpowiada na trzy zapytania: A2S_INFO, A2S_PLAYERS i A2S_RULES. A2S_INFO dostarcza nazwę serwera, mapę, liczbę graczy i wersję, A2S_PLAYERS nazwy połączonych graczy, a A2S_RULES ustawione zmienne serwera. Każda z tych odpowiedzi jest wyraźnie większa niż zapytanie, które ją wywołało, i właśnie to czyni ten port podwójnie niebezpiecznym.

Dla ciebie jako celu oznacza to: atakujący może zajmować twój port zapytań kilkoma bajtami na zapytanie, podczas gdy twój serwer za każdym razem składa i wysyła pełną odpowiedź. Dla osób trzecich oznacza to: atakujący może odpytywać twój serwer z podrobionym adresem nadawcy i kierować odpowiedzi na swój właściwy cel. Twój serwer nie jest wtedy tylko ofiarą, ale i wzmacniaczem. Valve uzupełniło dlatego A2S_INFO w grudniu 2020 o zapytanie kontrolne: serwer odpowiada najpierw liczbą losową, którą pytający musi odesłać. To rozbraja wzmocnienie, ale go nie kończy, bo wcale nie każde zapytanie idzie tą drogą.

DayZ ma tutaj cechę, której inne gry nie mają: odpytują cię dwie oddzielne listy serwerów, wbudowana przeglądarka serwerów społecznościowych oraz szeroko rozpowszechniony launcher DZSA. Zwykłe zamknięcie portu zapytań nie jest więc wyjściem, bo wtedy twój projekt znika z obu list, mimo że połączenie bezpośrednie nadal działa. Prawidłową odpowiedzią jest ograniczać zamiast zamykać.

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

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

1. Inwentaryzacja: które porty twój serwer DayZ naprawdę otwiera

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

ss -lnup
ss -lntup

Na serwerze z Windowsem wiersz poleceń daje ten sam obraz:

netstat -ano -p UDP | findstr "2302 2303 2304 2305 27016"

Interesująca jest kolumna z adresem lokalnym. 0.0.0.0:2302 oznacza „osiągalny z całego internetu”, 127.0.0.1:2310 oznacza „tylko lokalnie” i nie potrzebuje żadnego otwarcia. Potem odczytaj rzeczywiste wartości wprost ze swoich plików konfiguracyjnych, zamiast polegać na jakimkolwiek poradniku:

grep -iE "steamQueryPort|maxPlayers|password|enableWhitelist|verifySignatures" serverDZ.cfg
grep -iE "RConPort|RestrictRCon" battleye/BEServer_x64.cfg

Spojrzenie oczami atakującego daje skan portów UDP z zewnątrz, wykonany z innego komputera:

nmap -Pn -sU -p 2302-2310,27015-27020 TWOJ.ADRES.IP.SERWERA

2. Otwieraj tylko to, czego naprawdę potrzebują wiersz startowy i serverDZ.cfg

Dla DayZ wystarczą dwa otwarcia na zewnątrz: blok portu gry i port zapytań. Wszystko inne zostaje ograniczone do twojego własnego adresu 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 2302:2305/udp comment 'DayZ port gry'
ufw allow 27016/udp comment 'DayZ Steam Query'
ufw allow from 203.0.113.10 to any port 2310 proto udp comment 'BattlEye 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, a 27016 na wartość, która naprawdę stoi w twoim wierszu steamQueryPort. Pełną instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu. Na serwerze z Windowsem obowiązuje ta sama zasada: jedna reguła przychodząca na grupę portów, pulpit zdalny ograniczony do własnego adresu, cała reszta zablokowana.

3. Ogranicz port zapytań Steam, zamiast go zamykać

Górny limit na adres źródłowy oddziela prawdziwe listy serwerów od zalewu zapytań. Przeglądarka serwerów odpytuje cię w takcie sekundowym, atakujący w takcie milisekundowym:

iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name dayz_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name dayz_game --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

Pierwsza reguła odrzuca zapytania Steam powyżej trwałych dziesięciu na sekundę z tego samego źródła, druga pakiety gry powyżej 600 na sekundę. Obie liczby to wartości startowe, a nie prawdy objawione. Pełny serwer z 60 graczami generuje wyraźnie więcej pakietów niż pusty, a kto ustawi limit zbyt ciasno, wyrzuci własnych graczy albo wypadnie z listy serwerów. Najpierw mierz przez tydzień w normalnej pracy.

Same reguły iptables znikają po restarcie. Na Debianie i Ubuntu zapisuje się je tak:

apt-get install -y iptables-persistent
netfilter-persistent save

Przy UFW takie reguły należą do /etc/ufw/before.rules, bo inaczej znikną przy następnym ufw reload. Dodatkowo biblioteka serwerowa Steam zna własny hamulec dla pakietów bezpołączeniowych: zmienna środowiskowa STEAM_GAMESERVER_RATE_LIMIT_200MS odrzuca wszystkie pakiety A2S jednego adresu, gdy tylko w oknie 200 milisekund nadejdzie ich więcej niż ustawiona wartość.

Trzeci punkt nie kosztuje w ogóle nic: jeśli twój bot na Discordzie albo twoja strona projektu pokazuje stan graczy, nie odpytuj serwera z przeglądarki odwiedzającego, tylko buforuj wynik w stałych odstępach. Dzięki temu popularna strona ze statusem generuje jedno zapytanie na interwał zamiast jednego na odwiedzającego.

4. Wyjmij BattlEye RCon z otwartej sieci

BattlEye to komponent anti-cheat w DayZ i włącza się go w pliku serverDZ.cfg przez BattlEye = 1;. Zdalne zarządzanie leży natomiast w osobnym pliku, w BEServer_x64.cfg w katalogu BattlEye obok BEServer_x64.dll, który wiersz startowy ustawia przez -BEpath=:

RConPassword DlugieLosoweHaslo
RConPort 2310
RestrictRCon 0

Trzy zasady do tego. Po pierwsze: port RCon działa po UDP, a nie po TCP. Reguła firewalla, która przez pomyłkę mówi proto tcp, niczego nie filtruje, a zarazem sprawia, że narzędzia zarządzania trafiają w pustkę. Po drugie: ogranicz port do adresów swoich administratorów. Kto nie ma stałego adresu, zostawia port z zewnątrz całkiem zamknięty i uruchamia narzędzie zarządzania bezpośrednio na serwerze, dostępne przez SSH albo pulpit zdalny. Po trzecie: RestrictRCon 1 ogranicza polecenia wykonywalne przez RCon i jest właściwym ustawieniem, gdy tylko dostęp ma więcej niż jedna osoba.

Otwarty port RCon jest dwiema rzeczami naraz: zaproszeniem do przebierania w hasłach i kolejnym portem UDP, który da się zalać. Jedno i drugie odpada, gdy tylko otwarcie obowiązuje już tylko dla garstki adresów.

5. Kolejka logowania, whitelista i wyczerpanie slotów

DayZ nie obsługuje wszystkich połączeń jednocześnie, tylko przez kolejkę. Steruje nią pięć wartości w pliku serverDZ.cfg:

maxPlayers = 60;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 100;
guaranteedSlots = 10;
maxPing = 200;

loginQueueConcurrentPlayers ustala, ilu graczy jest wpuszczanych jednocześnie (ustawienie domyślne 5), loginQueueMaxPlayers ogranicza samą kolejkę (zwykłe wartości między 100 a 500). Dokładnie tutaj zaczepia wyczerpanie slotów: atakujący nie potrzebuje przepustowości, potrzebuje tylko dostatecznie wielu kont albo prób połączenia, żeby zająć kolejkę. Prawdziwi gracze nie przedostaną się wtedy do środka, mimo że serwer technicznie działa bez zarzutu. guaranteedSlots rezerwuje miejsca dla twojego zespołu, żebyś w dokładnie takiej sytuacji nadal mógł wejść na serwer.

Pomaga na to wbudowana whitelista. Włącza się ją przez enableWhitelist = 1;, po czym czyta ona plik profiles/whitelist.txt z jednym identyfikatorem Steam64 na wiersz. Każdy niewymieniony identyfikator zostaje przy połączeniu odrzucony. Plik jest wczytywany przy starcie serwera, więc zmiany wymagają restartu. Dodatkowe password w pliku serverDZ.cfg działa podobnie, ale jest słabsze, bo hasło przekazuje się dalej, a identyfikatora Steam64 nie.

Jedno musi być przy tym jasne: whitelista chroni twoje miejsca dla graczy, 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.

6. Mody, kontrola podpisów i okno czasowe po restarcie

Mody w DayZ to nie tylko kwestia wygody, są częścią powierzchni ataku. Cztery ustawienia w pliku serverDZ.cfg należy ustawić w każdym przypadku:

verifySignatures = 2;
forceSameBuild = 1;
allowFilePatching = 0;
BattlEye = 1;

verifySignatures = 2 sprawdza każdy plik PBO względem odpowiadającego mu podpisu .bisign i potrzebuje do tego pasujących plików .bikey w katalogu keys. forceSameBuild = 1 wymaga dokładnie tej samej wersji gry co na serwerze. allowFilePatching = 0 odrzuca klientów, którzy startują ze zmienionymi plikami gry. Żadne z tych ustawień nie zatrzyma ataku wolumetrycznego, ale wszystkie trzy zamykają drogę, którą zmanipulowany klient wytrąca twój serwer z rytmu.

Drugi punkt jest ważniejszy i prawie zawsze bywa przeoczony: faza startu. Serwer DayZ ładuje przy starcie najpierw swoją listę modów z wiersza startowego, a potem centralną ekonomię z wszystkimi tabelami lootu. Przy mocno zmodyfikowanym serwerze to z łatwością kilka minut, w których serwer nie odpowiada na ani jedno zapytanie Steam:

./DayZServer -config=serverDZ.cfg -port=2302 -profiles=./profiles -BEpath=./battleye -mod=@CF;@TwojMod;@KolejnyMod -cpuCount=4 -dologs -adminlog -netlog -freezecheck

Ponieważ praktycznie każdy projekt restartuje się co trzy do czterech godzin i ten plan jeszcze zapowiada, trafienie w to okno czasowe jest dla atakującego trywialne. Trzy środki zaradcze są skuteczne i nic nie kosztują. Trzymaj listę modów tak krótką, jak to możliwe, bo każdy dodatkowy mod wydłuża dokładnie to okno. Ustaw godziny restartów na nierówne wartości zamiast na pełną godzinę. I zmierz raz, jak długo twój start naprawdę trwa, zamiast szacować: przy timeStampFormat = "Full"; i ustawionym logFile czas trwania stoi potem w logu.

7. Śledzenie połączeń, bufory odbiorcze i parametry kernela

Często przeoczonym wąskim gardłem jest śledzenie połączeń w kernelu. UDP wprawdzie nie zna połączeń, ale kernel i tak zakłada wpis dla każdej pary adresu źródłowego i docelowego. Gdy tablica się zapeł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

Dla czystego serwera gier prawidłowym rozwiązaniem jest w ogóle nie dopuścić do śledzenia ruchu gry, a dodatkowo powiększyć bufory odbiorcze i kolejkę karty sieciowej:

iptables -t raw -A PREROUTING -p udp --dport 2302 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 2302 -j NOTRACK
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=1048576
sysctl -w net.core.netdev_max_backlog=5000
sysctl -w net.netfilter.nf_conntrack_max=524288

Uwaga: NOTRACK i reguły stanowe wykluczają się nawzajem. Kto wyjmuje port gry ze śledzenia, nie może już używać dla tego portu żadnej reguły z -m conntrack --ctstate, bo inaczej otwarcie przestanie działać. Na stałe wartości sysctl należą do /etc/sysctl.d/, inaczej znikną po następnym restarcie.

8. Twój adres IP stoi w przeglądarce serwerów

Tutaj opłaca się szczerość zamiast myślenia życzeniowego: adresu IP publicznego serwera DayZ nie da się utrzymać w tajemnicy. Zna go każdy gracz, który choć raz był połączony, przeglądarka serwerów go publikuje, a launcher DZSA go buforuje. Zmiana adresu daje ci godziny, rzadko dni.

Skuteczniejsze są dwa nawyki. Nigdzie dodatkowo nie publikuj surowego adresu IP, czyli ani w przypiętym wpisie na Discordzie, ani na stronie projektu. I uporządkuj swoje wpisy DNS: zapomniany rekord A wskazujący na poprzedni adres unieważnia każdą zmianę, i właśnie na tym większość zmian się wykłada. Kto na starym serwerze zostawia jeszcze działającą usługę statusu, zdradza od razu także nowy adres.

9. Prowadź logi, żebyś w trakcie ataku nie musiał zgadywać

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 sobotni wieczór. Po stronie serwera włącz do tego wbudowane logi:

timeStampFormat = "Short";
logAverageFps = 300;
logPlayers = 300;
logFile = "server_console.log";

logAverageFps jest przy tym najuczciwszą wartością, jaką DayZ dostarcza. Jeśli liczba klatek serwera spada, podczas gdy liczba graczy pozostaje ta sama, to problem moda albo ekonomii. Jeśli liczba klatek pozostaje stabilna, a gracze wylatują, to sprawa sieci. Po stronie systemu pomiary chodzą na stałe w tle po apt-get install -y vnstat sysstat, a 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 2302 -c 200 -q

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 odczytać te wartości, opisuje wpis Jak rozpoznać atak DDoS na serwerze.

Gdzie kończy się ochrona własna: 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.

Liczba pakietów uderza w DayZ często wcześniej niż przepustowość, a ma to prosty powód: ruch gry składa się z wielu małych pakietów UDP, a nie z kilku dużych. Atak, który nie wypełnia twojego łącza nawet w jednej trzeciej, może więc mimo wszystko 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 wszyscy mieli skoki lagów i wylatywali jeden po drugim”.

Ataki wolumetryczne muszą kończyć się w sieci przed serwerem. To nie jest wypowiedź o produkcie, tylko fizyka.

Ochrona DDoS dla DayZ: co przeciwstawia temu KernelHost

Stała ochrona, która działa na każdym serwerze

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 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: sam ustawiasz osobno, co jest dozwolone na 2302/UDP, co na porcie zapytań, a co na porcie RCon. Dokładnie ten rozdział jest w DayZ dźwignią, bo ruch gry i ruch zapytań wyglądają zupełnie inaczej.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku, zamiast czekać na zgłoszenie.
• Profil ochrony dopasowany do gry, także dla mocno zmodyfikowanych serwerów i własnych aplikacji na dowolnych portach TCP albo UDP.

Porównanie obu wariantów

Dla większości projektów DayZ 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. Kto prowadzi swój serwer DayZ obecnie gdzie indziej, nie może tej ochrony dokupić: jest ona częścią sieci i obowiązuje dla serwerów, które stoją w KernelHoście. Drogą do niej jest przeprowadzka, a nie dodatkowy produkt.

Typowe błędy i ich rozwiązania

„Mój serwer zniknął z launchera DZSA i z przeglądarki serwerów, ale przez połączenie bezpośrednie się dostaję”: w większości przypadków to nie atak, tylko port zapytań. Albo w steamQueryPort stoi inna wartość niż w firewallu, albo zbyt ciasne ograniczenie tempa odrzuca zapytania listy serwerów. Sprawdź obie wartości względem siebie, zanim zaczniesz podejrzewać atak.

„RCon przestał się łączyć, odkąd odfiltrowałem porty”: BattlEye RCon działa po UDP. Otwarcie z proto tcp na tym samym porcie niczego nie daje. Sprawdź ponadto, czy RConPort i steamQueryPort przez pomyłkę nie stoją na tej samej wartości.

„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 przeglądarki serwerów, z bota Discord ze statusem albo ze starego wpisu DNS. Zmiana adresu to zysk na czasie, a nie rozwiązanie.

„Atak przychodzi codziennie dokładnie na restart”: to nie przypadek. Plan restartów stoi na Discordzie i jest zapowiadany w grze, a dopóki ładują się mody i ekonomia, serwer i tak nie odpowiada. Krótsza lista modów, nierówne godziny restartów oraz filtrowanie, które działa nieprzerwanie zamiast reagować dopiero na atak, odbierają temu schematowi skuteczność.

„Wszyscy gracze mają skoki lagów, ale sieć jest spokojna”: wtedy to nie był atak DDoS. Sprawdź najpierw w logAverageFps, czy liczba klatek serwera spadła, a potem centralną ekonomię i listę modów. Jeśli sar -n DEV 1 10 nie pokazuje nic nietypowego, to nie sprawa sieci.

„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ą. Jeśli stoją na zerze, reguła nie jest osiągana.

„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

• Serwer DayZ potrzebuje na zewnątrz dokładnie dwóch rzeczy: bloku portu gry od 2302/UDP i portu zapytań Steam z twojego wiersza steamQueryPort. Cała reszta należy ograniczona albo zamknięta.
• Port BattlEye RCon nie ma wiążącego standardu, działa po UDP i ustawia się go w pliku BEServer_x64.cfg przez RConPort. Nigdy nie należy do otwartej sieci i nigdy na tę samą wartość co port zapytań.
• Port zapytań się ogranicza, a nie zamyka: kto go zamknie, znika z przeglądarki serwerów i z launchera DZSA, mimo że połączenie bezpośrednie nadal działa.
• Whitelista, guaranteedSlots i kolejka logowania chronią twoje miejsca dla graczy przed wyczerpaniem slotów, ale nie twoje łącze przed przepustowością.
• Najniebezpieczniejszym oknem czasowym serwera DayZ jest zaplanowany restart co trzy do czterech godzin, bo mody i centralna ekonomia ładują się minutami, a moment jest publicznie znany.
• Od około 1 Gbit/s wolumenu ataku albo od kilkuset tysięcy pakietów na sekundę decyduje wyłącznie sieć przed serwerem, a nie już twój firewall.
• W KernelHoście dwuwarstwowa stała ochrona jest zawarta w każdym pakiecie serwerowym, bez dopłat i bez null-routingu. Advanced DDoS Protection od 50,00 € miesięcznie dochodzi wtedy, gdy chcesz sam sterować regułami na każdym porcie.

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