Ochrona serwera Mordhau przed atakami DDoS

Serwer Mordhau, który w środku rundy Frontline traci naraz wszystkich graczy, potem na kilka minut znika z sieci i przestaje się pojawiać na liście serwerów, rzadko ma problem ze sprzętem. W zdecydowanej większości przypadków trwa atak na jeden z czterech portów UDP, które serwer dedykowany Mordhau musi trzymać otwarte na zewnątrz. Ten artykuł pokazuje najpierw, co w ochronie Mordhau przed DDoS możesz zrobić sam i bez dodatkowych kosztów, potem, gdzie te działania kończą się fizycznie, a na koniec, co musi wydarzyć się w sieci przed serwerem.

Wszystkie informacje dotyczą oficjalnego serwera dedykowanego Mordhau (Steam App ID 629800, Unreal Engine 4) 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 w konfiguracji i nie restartuj serwera, tylko zabezpiecz pomiary (rozdział 9), bo po ataku już ich nie będzie. Przy Mordhau dochodzi drugi powód, którego wielu operatorów uczy się boleśnie: proces serwera przy zamykaniu zapisuje swój stan z pamięci operacyjnej z powrotem do pliku Game.ini. Kto edytuje ten plik przy działającym serwerze, traci swoje zmiany przy następnym zatrzymaniu.

Dlaczego serwery Mordhau potrzebują ochrony DDoS i kto je atakuje

Serwery Mordhau są atakowane, bo ich adres jest publiczny, cały ruch gry idzie przez UDP, a awaria natychmiast staje się widoczna dla wszystkich. Wpis w przeglądarce serwerów zawiera adres IP i port gry otwartym tekstem, bo inaczej gracze nie mogliby serwera znaleźć. Publiczne listy serwerów i trackery pobierają te same dane przez port zapytań Steam i publikują je po raz drugi. Twój adres nie jest więc tajemnicą, tylko informacją o produkcie.

Do tego dochodzi technika samej gry. Unreal Engine 4 przesyła ruchy, trafienia i parady przez UDP. UDP nie zna nawiązywania połączenia, którego można by wymagać, a adres nadawcy pakietu UDP 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. W Mordhau waży to więcej niż w wielu innych grach: wymiana ciosów rozstrzyga się w zakresie kilku dziesiątych sekundy, a już 200 milisekund dodatkowego opóźnienia czyni walkę wręcz niegrywalną, na długo zanim serwer faktycznie padnie. Właśnie dlatego wystarczy niewielki atak, żeby zniszczyć rundę. Czym dokładnie jest atak DDoS, wyjaśnia wpis Czym jest atak DDoS?.

Typowe powody są nieefektowne: konkurencja między społecznościami, zbanowani gracze, przegrane pojedynki, kłótnie na Discordzie. Atak nie kosztuje zlecającego ani umiejętności, ani liczących się pieniędzy, bo pracę wykonują wynajęte usługi typu booter. Operatorzy regularnie zgłaszają, że ataki zaczynają się dokładnie wtedy, gdy serwer jest pełny, i ustają, gdy tylko się opróżni. To nie przypadek, tylko wskazówka, że ktoś obserwuje twój wpis w przeglądarce serwerów i używa liczby graczy jako wyzwalacza.

Porty, o które w Mordhau naprawdę chodzi

Serwer dedykowany Mordhau potrzebuje na zewnątrz dokładnie czterech portów UDP: 7777, 7778, 15000 i 27015. Wszystko inne jest albo opcjonalne, albo nie należy do otwartej sieci. Porty przekazuje się przy starcie jako parametry:

./MordhauServer.sh FFA_ThePit -log -Port=7777 -QueryPort=27015 -BeaconPort=15000 -RconPort=27020

Dwie rzeczy są przy tym regularnie źle rozumiane. Po pierwsze: port beacona 15000 nie jest dodatkiem. Beacon rezerwuje slot w momencie, w którym gracz dołącza, żeby po załadowaniu mapy nie wyleciał z powrotem. Jeśli 15000 jest zablokowany albo przeciążony, gracze przestają wchodzić, mimo że port 7777 odpowiada. Po drugie: RCON nie jest w Mordhau prekonfigurowany. Staje się aktywny dopiero wtedy, gdy ustawisz RconPassword i RconPort, i działa wówczas przez TCP, a nie przez UDP.

Najważniejsze liczby serwera Mordhau w jednym miejscu:

Wzorce ataków, które spotykają serwery Mordhau

Cztery wzorce pokrywają praktycznie wszystko, co prowadzi się przeciw serwerowi Mordhau, i każdy trafia w inny port.

• Flood UDP na port gry 7777. To standardowy atak bootera: jak najwięcej podrobionych pakietów na port, który stoi w przeglądarce serwerów. Celuje w przepustowość i liczbę pakietów, a nie w lukę, i objawia się najpierw przycinaniem, na długo zanim ktokolwiek straci połączenie.
• Flood zapytań na port zapytań 27015. Zapytanie A2S_INFO ma 25 bajtów, a odpowiedź z nazwą serwera, mapą, trybem gry i liczbą graczy jest wielokrotnie większa. Atakujący inwestuje więc niewiele, a u ciebie wymusza pracę procesora i ruch wychodzący.
• Odbicie przez twój własny port zapytań. Tutaj twój serwer nie jest celem, tylko narzędziem: atakujący wysyła zapytania z podrobionym adresem nadawcy, a twój serwer odpowiada ofierze. Zauważasz to jako niewyjaśniony wysoki ruch wychodzący na 27015 oraz jako zgłoszenie nadużycia od twojego dostawcy.
• Wyczerpanie slotów przez flood połączeń na porcie beacona 15000. Zamiast palić przepustowość, zautomatyzowane próby dołączenia zajmują zarezerwowane sloty. Serwer działa dalej, ale jest pełny, a prawdziwi gracze przestają wchodzić.

Dochodzi do tego piąty wzorzec, gdy tylko RCON stoi otwarty w sieci: próby logowania w rytmie sekundowym przeciw portowi RCON. To rzadko bywa wolumetryczne, kosztuje jednak czas procesora, i jest jedynym z tych pięciu przypadków, w którym trafienie odbiera ci serwer całkowicie.

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

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

1. Inwentaryzacja: co w ogóle nasłuchuje na serwerze?

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

ss -lntup

Interesuje cię kolumna z adresem lokalnym. 0.0.0.0:7777 oraz [::]:7777 oznaczają „osiągalny z całego internetu”, 127.0.0.1:27020 oznacza „tylko lokalnie” i nie potrzebuje żadnej reguły firewalla. Obok gry pojawiają się tam często jeszcze panel WWW, usługa bazy danych oraz dawno zapomniana usługa głosowa. Spojrzenie oczami atakującego daje skan z zewnątrz, dla UDP z krótką listą portów, bo pełny skan UDP jest bardzo wolny:

nmap -Pn -sU -p 7777,7778,15000,27015 TWOJ.ADRES.IP.SERWERA
nmap -Pn -p- --min-rate 1000 TWOJ.ADRES.IP.SERWERA

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

Dla Mordhau wystarczą cztery otwarcia UDP na zewnątrz, cała reszta zostaje ograniczona albo w ogóle nie trafia do sieci. W UFW wygląda to tak, dokładnie w tej kolejności, żebyś nie zamknął dostępu samemu sobie:

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'Mordhau gra'
ufw allow 7778/udp comment 'Mordhau Steam'
ufw allow 15000/udp comment 'Mordhau beacon'
ufw allow 27015/udp comment 'Mordhau zapytania'
ufw allow from 203.0.113.10 to any port 27020 proto tcp comment 'Mordhau 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. Ważne jest to, czego tu nie ma: żadnego otwarcia dla panelu WWW, żadnego dla bazy danych, żadnego dla serwera plików. Każdy dodatkowo otwarty port to dodatkowy cel, który nie ma nic wspólnego z grą. Pełną instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez odcinania sobie dostępu.

3. Ogranicz port zapytań 27015, nie wypadając z listy serwerów

Port zapytań wolno ci ograniczyć, ale nie zamknąć. Jeśli zamkniesz 27015 UDP, twój serwer zniknie z przeglądarki serwerów, bo liczba graczy, nazwa mapy i nazwa serwera są odpytywane dokładnie przez ten port. Górny limit na adres źródłowy rozwiązuje problem bez utraty widoczności:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name mh_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Zwykła przeglądarka serwerów odpytuje twój serwer kilka razy na minutę, a nie kilka razy na sekundę. Dziesięć zapytań na sekundę i adres źródłowy jest zatem hojne dla każdego gracza i ciasne dla każdego bota. Sprawdź potem na liczniku trafień, czy reguła w ogóle działa:

iptables -L INPUT -n -v | head -20
tcpdump -ni eth0 udp port 27015 -c 200 -q

Tu leży też odpowiedź na pytanie o odbicie. Przy odbiciu twój serwer nie jest atakowany, tylko wykorzystywany jako wzmacniacz: zapytania przychodzą z podrobionym adresem nadawcy, a twoje odpowiedzi trafiają obcą ofiarę. Ograniczenie liczby pakietów na adres źródłowy jest przeciwko temu najskuteczniejszym środkiem lokalnym, bo podrobiony adres nadawcy przydaje się tylko tak długo, jak długo twój serwer odpowiada chętnie i bez ograniczeń.

4. Zabierz RCON z otwartej sieci

RCON w Mordhau w żadnym wypadku nie należy nieograniczony do internetu. Dostęp włącza się w pliku Game.ini, w sekcji [/Script/Mordhau.MordhauGameSession]:

[/Script/Mordhau.MordhauGameSession]
ServerName=Moj serwer Mordhau
MaxSlots=64
ServerPassword=
AdminPassword=DlugieLosoweHaslo
RconPassword=InneDlugieLosoweHaslo
RconPort=27020

Mordhau mówi protokołem Source RCON, czyli przez TCP, i dlatego współpracuje z każdym popularnym narzędziem RCON. Dokładnie to wykorzystują także skrypty, które przebierają dane logowania. Trzy zasady pokrywają ten przypadek. Po pierwsze: RconPassword i AdminPassword to dwa różne, długie, losowe hasła, a nie warianty nazwy serwera. Po drugie: otwarcie portu RCON ograniczasz do własnego adresu, tak jak w bloku UFW powyżej. Po trzecie, jeśli nie masz stałego adresu: zostaw port zamknięty z zewnątrz i dostawaj się do niego przez przekierowanie portu w SSH, a potem połącz się lokalnie z 127.0.0.1:27020:

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

Jeśli RCON musi mimo wszystko zostać otwarty, ogranicz przynajmniej liczbę jednoczesnych połączeń na adres źródłowy. Narzędzie RCON potrzebuje jednego połączenia, skrypt bruteforce setek:

iptables -I INPUT -p tcp --dport 27020 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

5. Zabezpiecz port beacona 15000 przed floodami połączeń

Port beacona to niedoceniany punkt ataku na serwer Mordhau. Przez niego gra rezerwuje slot dołączającego gracza, dopóki ten jeszcze się ładuje. Bot, który w szybkim tempie inicjuje kolejne próby dołączenia, zajmuje w ten sposób sloty, nigdy nie docierając do gry. Serwer pozostaje online, a mimo to sprawia wrażenie pełnego. Górny limit na adres źródłowy to wyłapuje, bo prawdziwy gracz wysyła beacon dokładnie raz na jedno dołączenie, a nie dwadzieścia razy na sekundę:

iptables -I INPUT -p udp --dport 15000 -m hashlimit --hashlimit-name mh_beacon --hashlimit-mode srcip --hashlimit-above 20/sec --hashlimit-burst 40 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name mh_game --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

Druga reguła dotyczy portu gry i wymaga wyczucia. Przy tickrate 60 serwer wymienia z każdym podłączonym graczem rzędu 60 pakietów na sekundę w każdym kierunku. Wartość graniczna 400 pakietów na sekundę i adres źródłowy zostawia więc każdemu prawdziwemu graczowi sporo zapasu, a i tak trafia każde źródło, które w oczywisty sposób floodzi. Najpierw mierz przez tydzień w normalnej pracy, zanim zaciśniesz limit: kto ustawi go zbyt ciasno, wyrzuci własnych graczy i weźmie to potem za atak.

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.

6. Game.ini i Engine.ini: co naprawdę coś daje

Mordhau ma dwa pliki konfiguracyjne i oba leżą w Linuksie w Mordhau/Saved/Config/LinuxServer/, a w Windowsie w Mordhau\Saved\Config\WindowsServer\. Plik Game.ini reguluje nazwę serwera, sloty, hasła, listę administratorów, rotację map oraz identyfikatory modów z mod.io, a plik Engine.ini zachowanie sieciowe. Edytuj oba wyłącznie przy zatrzymanym serwerze, bo inaczej proces serwera przy zamykaniu nadpisze twoje zmiany stanem z pamięci operacyjnej.

Trzy ustawienia mają realne znaczenie dla powierzchni ataku. Po pierwsze ServerPassword: trzyma z daleka każdego, kto nie został zaproszony, kosztuje jednak publiczną odnajdywalność i przeciw floodowi na port 7777 nie pomaga w ogóle, bo atakujący wcale nie chce dołączyć. Po drugie realistyczna liczba w MaxSlots: Mordhau jest zaprojektowany na maksymalnie 64 graczy, a każdy dodatkowy slot to dodatkowe źródło pakietów, które musi obsłużyć twój procesor. Po trzecie tickrate w pliku Engine.ini:

[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=60
LanServerMaxTickRate=60

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

Domyślny tickrate serwera Mordhau to 60. Podniesienie do 120 podwaja liczbę pakietów na gracza oraz obciążenie procesora i jest dokładnie tym, czego pod atakiem nie potrzebujesz. Serwer na 64 sloty z tickrate 120 generuje w normalnej pracy już rzędu 8000 pakietów na sekundę w każdym kierunku. Kto jest ostrzeliwany stale, jedzie z 60 wyraźnie stabilniej niż ze 120.

7. Odciąż śledzenie połączeń i bufory odbiorcze

Często przeoczanym wąskim gardłem jest śledzenie połączeń w kernelu. Prowadzi ono własny wpis dla każdego strumienia UDP, a flood z kilkudziesięciu tysięcy podrobionych adresów nadawcy zapełnia tablicę w kilka sekund. 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
dmesg -T | grep -i conntrack | tail -20

Pomagają na to dwie rzeczy. Podnosisz górny limit albo wyłączasz porty gry ze śledzenia w całości. To drugie jest przy serwerze gier zwykle lepszą drogą, bo UDP i tak nie ma stanu, który trzeba by śledzić:

iptables -t raw -I PREROUTING -p udp --dport 7777 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 15000 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 27015 -j NOTRACK

Sensowne są również większe bufory odbiorcze i głębsza kolejka karty sieciowej, żeby krótkie szczyty nie prowadziły od razu do odrzutów:

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=4194304
sysctl -w net.core.netdev_max_backlog=5000

Na stałe te wartości należą do pliku w /etc/sysctl.d/, na przykład 99-gameserver.conf. Ważne dla zrozumienia: większe bufory nie podnoszą twojej odporności na duży atak, zapobiegają tylko temu, żeby krótki wyskok od razu kosztował pakiety.

8. Twój adres stoi na liście serwerów i nie da się tego zmienić

Tutaj opłaca się szczerość zamiast myślenia życzeniowego: adresu IP publicznego serwera Mordhau nie da się utrzymać w tajemnicy. Stoi we wpisie w przeglądarce serwerów, stoi na publicznych listach serwerów osób trzecich, które regularnie odczytują port zapytań, i zna go każdy gracz, który choć raz był połączony. Zmiana adresu daje więc godziny, rzadko dni, bo atakujący znajduje nowy adres tą samą drogą co stary.

Skuteczne są trzy nawyki. Nigdzie nie publikuj surowego adresu IP samodzielnie, czyli ani na kanale Discord, ani na stronie projektu. Podłączaj graczy przez nazwę hosta, żeby zmiana adresu w razie potrzeby nie łamała wszystkich odnośników. I sprzątaj stare wpisy DNS, bo zapomniany rekord A wskazujący na poprzedni adres unieważnia każdą zmianę. To samo dotyczy serwerów testowych: każdy publicznie osiągalny drugi serwer na tej samej maszynie zdradza adres serwera głównego.

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 serwer pracuje 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
dmesg -T | tail -50
tcpdump -ni eth0 'udp port 7777 or udp port 15000 or udp port 27015' -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. Zwróć szczególną uwagę na liczniki odrzutów z ip -s link. Rosnące wartości dropped przy jednocześnie spokojnym procesorze są najwyraźniejszą wskazówką, że problemem jest liczba pakietów, a nie moc obliczeniowa. Jak odczytać te wartości, opisuje wpis Jak rozpoznać atak DDoS. Jak czysto postawić serwer przez SteamCMD i utrzymywać go w aktualnej wersji, opisuje wpis Instalacja serwera gry przez SteamCMD.

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. Pełny serwer Mordhau na 64 sloty potrzebuje z tego jedynie ułamka: przy tickrate 60 ruch gry leży rzędu 4000 pakietów na sekundę w każdym kierunku. Wynajęty booter dostarcza natomiast bez trudu od 5 do 50 Gbit/s, czyli od pięciu do pięćdziesięciu razy więcej, niż wynosi twoje łącze. To, czy twoja reguła iptables za tym łączem jest dobra, nie ma już wtedy znaczenia, bo pakiety twoich graczy nie przechodzą już wcześniej.

Druga wielkość to liczba pakietów na sekundę i uderza ona często wcześniej niż przepustowość. Przy małych pakietach po 64 bajty w łącze 1 Gbit/s mieści się około 1,49 miliona pakietów na sekundę. Zwykły kernel serwera przetworzy z tego, zależnie od procesora i karty sieciowej, kilkaset tysięcy, zanim zacznie odrzucać. Atak, który nie zapełnia twojego łącza nawet w jednej trzeciej, może więc mimo wszystko położyć twój serwer Mordhau, bo cały czas procesora idzie na odrzucanie. Operatorzy przeżywają to jako „przecież obciążenie wcale nie było wysokie, a i tak wszystko padło”.

Dla porządku wielkości, które zdarzają się naprawdę: na serwerach KernelHost odfiltrowano między innymi atak o wolumenie ponad 473,4 Gbit/s przy ponad 41,5 miliona pakietów na sekundę wymierzony w serwer głosowy oraz flood UDP o wolumenie ponad 112,2 Gbit/s w serwer gier. Na to nie ma żadnego ustawienia lokalnego. Ataki wolumetryczne muszą kończyć się w sieci przed serwerem.

Co przeciwstawia temu KernelHost

Stała ochrona wliczona w każdy serwer

Ochrona DDoS w KernelHoście jest zbudowana dwuwarstwowo i stale aktywna, bez konieczności włączania, zamawiania czy konfigurowania czegokolwiek:

• Warstwa 1: 17 Tbps pojemności mitygacji w globalnej sieci scrubbing. Ataki wolumetryczne są oczyszczane blisko źródła, zanim dotrą do centrum danych.
• Warstwa 2: filtrowanie Arbor w czasie rzeczywistym o wydajności 3,2 Tbps we Frankfurcie nad Menem. Bezpośrednio przed serwerem rozpoznawane i odrzucane są wzorce specyficzne dla protokołów, pakiet po pakiecie.

Decydujące są dwie cechy. Ochrona działa nieprzerwanie i nie musi dopiero reagować na atak, nie ma więc kilku minut na starcie, w których serwer znika. I nie stosuje się null-routingu: twój adres IP zostaje w sieci, odrzucane są wyłącznie szkodliwe pakiety. Kto zdejmuje adres IP z sieci, osiąga dla ciebie ten sam efekt co atakujący. Lokalizacja to Frankfurt 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 serwerów Mordhau pod stałym ostrzałem

Niektóre serwery 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 frankfurckiego rdzenia sieci, na który twój serwer zostaje przełączony we własnej sieci. Po twojej stronie nie trzeba niczego przebudowywać.
• Samodzielnie zarządzane reguły ochrony na port i protokół w panelu klienta: osobno ustalasz, co jest dozwolone na 7777 UDP, co na 15000 UDP, a co na 27015 UDP, bez pisania zgłoszenia.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku, zamiast czekać na okno serwisowe.
• Profil ochrony dopasowany do gry. Dla serwerów gier na Unreal Engine po UDP oraz dla portów zapytań Steam istnieją gotowe profile, tak samo dla zmodyfikowanych i własnych aplikacji na dowolnych portach TCP albo UDP.

Advanced DDoS Protection jest skierowana do serwerów, które działają w KernelHoście. Jeśli twój serwer Mordhau stoi obecnie gdzie indziej i jest regularnie wystrzeliwany z sieci, drogą do tego filtrowania jest przeprowadzka.

Porównanie obu wariantów

Dla większości serwerów Mordhau 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

„Zamknąłem port 27015 i teraz mojego serwera nie ma już na liście”: to przewidywalny skutek. Port zapytań Steam dostarcza nazwę, mapę i liczbę graczy do przeglądarki serwerów. Bez niego twój serwer przestaje się pojawiać albo jest pokazywany jako nieosiągalny. Właściwe jest ograniczenie liczby pakietów na adres źródłowy zamiast blokady.

„Gracze nie wchodzą, mimo że serwer działa”: sprawdź najpierw port 15000 UDP. Beacon rezerwuje slot podczas ładowania. Jeśli jest zablokowany, zbyt ciasno filtrowany albo przeciążony, dołączenie zawiesza się, mimo że port 7777 odpowiada, a serwer stoi w przeglądarce.

„Moje zmiany w Game.ini po restarcie znowu zniknęły”: edytowałeś plik przy działającym serwerze. Proces serwera Mordhau przy zamykaniu zapisuje z powrotem swój stan z pamięci operacyjnej i nadpisuje przy tym twoją wersję. Zatrzymać serwer, edytować, uruchomić, w tej kolejności.

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

„Serwer działa, ale wszyscy mają przycinanie i trafienia docierają za późno”: sprawdź najpierw, czy liczba pakietów przychodzących rośnie, podczas gdy procesor pozostaje spokojny. Dokładnie to jest wzorcem ataku. Jeśli liczba pakietów pozostaje normalna, a procesor stoi na 100 procentach, to nie jest atak DDoS, tylko zwykle zbyt wysoki tickrate, zbyt wiele slotów albo jakiś mod.

„Mój dostawca zgłasza wychodzące nadużycie z portu 27015”: twój serwer został wykorzystany jako wzmacniacz do odbicia. Zapytania przychodziły z podrobionym adresem nadawcy, a odpowiadał twój serwer obcej ofierze. Ograniczenie liczby pakietów na 27015 UDP na adres źródłowy to kończy.

„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 dedykowany Mordhau potrzebuje na zewnątrz dokładnie czterech portów UDP: 7777 (gra), 7778 (Steam), 15000 (beacon) i 27015 (zapytania Steam). Cała reszta zostaje zamknięta.
• RCON działa w Mordhau przez TCP według protokołu Source RCON i staje się aktywny dopiero przez RconPassword i RconPort w pliku Game.ini. Ogranicz ten port do własnego adresu.
• Port 27015 UDP wolno ci ograniczyć, ale nie zamknąć: bez niego twój serwer znika z przeglądarki serwerów, bo liczba graczy, mapa i nazwa są odpytywane przez ten port.
• Port 15000 UDP to port beacona i rezerwuje slot podczas ładowania. Jeśli jest zablokowany albo przeciążony, gracze nie wchodzą, mimo że serwer działa.
• Pliki Game.ini i Engine.ini edytuj wyłącznie przy zatrzymanym serwerze, bo proces serwera przy zamykaniu zapisuje z powrotem stan z pamięci operacyjnej.
• Lokalne reguły firewalla kończą się na przepustowości: 1 Gbit/s to 125 megabajtów na sekundę, a przy pakietach po 64 bajty około 1,49 miliona pakietów na sekundę. Powyżej decyduje już wyłącznie sieć przed serwerem.
• W KernelHoście dwuwarstwowa stała ochrona jest zawarta w każdym pakiecie serwerowym bez dopłat i aktywna od udostępnienia, bez null-routingu. Kto chce sterować filtrowaniem samodzielnie, dostaje to z Advanced DDoS Protection od 50,00 € miesięcznie.

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