Protejarea serverului Mordhau împotriva atacurilor DDoS

Un server Mordhau care pierde dintr-odată toți jucătorii în mijlocul unei runde Frontline, rămâne apoi offline câteva minute și nu mai apare în lista de servere, are rareori o problemă de hardware. În marea majoritate a cazurilor este în curs un atac asupra unuia dintre cele patru porturi UDP pe care un server dedicat Mordhau trebuie să le țină deschise spre exterior. Acest articol arată mai întâi ce puteți rezolva singur în privința protecției DDoS pentru Mordhau, fără costuri suplimentare, apoi unde se opresc fizic aceste măsuri și, la final, ce trebuie să se întâmple în rețeaua din fața serverului.

Toate datele se referă la serverul dedicat oficial Mordhau (Steam App ID 629800, Unreal Engine 4) pe Debian 12, Debian 13, Ubuntu 22.04 LTS sau Ubuntu 24.04 LTS. Comenzile sunt scrise pentru root, ca utilizator obișnuit puneți sudo în față. Dacă atacul este în curs, nu schimbați mai întâi nimic în configurație și nu reporniți serverul, ci salvați valorile măsurate (secțiunea 9), pentru că după atac ele nu mai există. La Mordhau se adaugă un al doilea motiv, pe care mulți operatori îl învață pe pielea lor: la oprire, procesul serverului își scrie starea din memoria de lucru înapoi în Game.ini. Cine editează fișierul cu serverul pornit își pierde modificările la următoarea oprire.

De ce serverele Mordhau au nevoie de protecție DDoS și cine le atacă

Serverele Mordhau sunt atacate pentru că adresa lor este publică, întregul trafic de joc merge prin UDP și o cădere devine imediat vizibilă pentru toată lumea. Intrarea din browserul de servere conține adresa IP și portul de joc în clar, altfel jucătorii nu ar putea găsi serverul. Listele publice de servere și trackerele preiau aceleași date prin portul de interogare Steam și le publică a doua oară. Adresa dumneavoastră nu este deci un secret, ci o informație de produs.

La asta se adaugă tehnica jocului. Unreal Engine 4 transmite mișcările, loviturile și parările prin UDP. UDP nu cunoaște o stabilire de conexiune care să poată fi pretinsă, iar adresa expeditorului unui pachet UDP se poate falsifica. Un atacator nu trebuie deci nici să intre pe serverul dumneavoastră, nici să îl abordeze corect ca să genereze încărcare. La Mordhau asta atârnă mai greu decât la multe alte jocuri: un schimb de lovituri se decide în câteva zecimi de secundă, iar 200 de milisecunde de întârziere în plus fac lupta corp la corp nejucabilă cu mult înainte ca serverul să cadă efectiv. Exact de aceea un atac mic este suficient ca să distrugă o rundă. Ce este în detaliu un atac DDoS explică articolul Ce este un atac DDoS?.

Declanșatoarele tipice sunt banale: concurența dintre comunități, jucători banați, dueluri pierdute, certuri pe Discord. Un atac nu îl costă pe cel care îl comandă nici pricepere, nici bani demni de menționat, pentru că serviciile booter închiriate fac treaba. Operatorii relatează în mod regulat că atacurile pornesc exact atunci când serverul este plin și se opresc de îndată ce se golește. Asta nu este o coincidență, ci un indiciu că cineva urmărește intrarea dumneavoastră din browserul de servere și folosește numărul de jucători ca declanșator.

Porturile despre care este vorba de fapt la Mordhau

Un server dedicat Mordhau are nevoie de exact patru porturi UDP spre exterior: 7777, 7778, 15000 și 27015. Tot restul este fie opțional, fie nu are ce căuta în rețeaua deschisă. Porturile se transmit la pornire ca parametri:

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

Două lucruri sunt înțelese greșit în mod regulat. În primul rând: portul beacon 15000 nu este un accesoriu. Beaconul rezervă slotul în momentul în care un jucător se conectează, ca acesta să nu fie dat afară după încărcarea hărții. Dacă 15000 este blocat sau suprasolicitat, jucătorii nu mai intră, deși portul 7777 răspunde. În al doilea rând: RCON nu este preconfigurat la Mordhau. Devine activ abia când setați RconPassword și RconPort, iar apoi rulează prin TCP, nu prin UDP.

Cele mai importante cifre ale unui server Mordhau, pe scurt:

Tipurile de atac care apar la Mordhau

Patru tipare acoperă practic tot ce se aruncă împotriva unui server Mordhau, iar fiecare lovește un alt port.

• Flood UDP pe portul de joc 7777. Acesta este atacul standard al unui booter: cât mai multe pachete falsificate către portul care apare în browserul de servere. Țintește lățimea de bandă și rata de pachete, nu o vulnerabilitate, și se manifestă mai întâi ca vârfuri de lag, cu mult înainte ca cineva să piardă conexiunea.
• Val de interogări pe portul de interogare 27015. O interogare A2S_INFO are 25 de bytes, iar răspunsul cu numele serverului, harta, modul de joc și numărul de jucători este un multiplu al acestei valori. Atacatorul investește deci puțin și vă impune muncă de calcul și trafic de ieșire.
• Reflection prin propriul port de interogare. Aici serverul dumneavoastră nu este ținta, ci unealta: atacatorul trimite interogări cu adresa expeditorului falsificată, iar serverul dumneavoastră răspunde victimei. Observați asta ca trafic de ieșire inexplicabil de mare pe 27015 și ca sesizare de abuz din partea furnizorului dumneavoastră.
• Epuizarea conectărilor și a sloturilor prin portul beacon 15000. În loc să ardă lățime de bandă, conectările automatizate ocupă sloturile rezervate. Serverul rulează în continuare, dar este plin, iar jucătorii reali nu mai intră.

La acestea se adaugă un al cincilea tipar, de îndată ce RCON este deschis în rețea: încercări de autentificare din secundă în secundă împotriva portului RCON. Rareori este volumetric, dar consumă timp de calcul, și este singurul dintre cele cinci cazuri în care o lovitură reușită vă scoate serverul complet din mână.

Ce puteți face singur înainte de a cheltui bani

Această secțiune este cea mai lungă, și asta în mod intenționat. Un server Mordhau configurat curat rezistă cu forțe proprii la atacuri mici și medii, indiferent la cine este găzduit.

1. Inventar: ce ascultă de fapt pe server?

Înainte de a scrie o singură regulă de firewall, uitați-vă ce oferă serverul dumneavoastră spre exterior. Nu ghiciți, verificați:

ss -lntup

Interesantă este coloana cu adresa locală. 0.0.0.0:7777 și [::]:7777 înseamnă „accesibil din tot internetul”, 127.0.0.1:27020 înseamnă „doar local” și nu are nevoie de o regulă de firewall. Pe lângă joc apar acolo deseori și un panou web, un serviciu de bază de date și un serviciu de voce uitat de mult. Perspectiva atacatorului o oferă o scanare din exterior, pentru UDP cu o listă scurtă de porturi, pentru că o scanare UDP completă este foarte lentă:

nmap -Pn -sU -p 7777,7778,15000,27015 ADRESA.IP.A.SERVERULUI
nmap -Pn -p- --min-rate 1000 ADRESA.IP.A.SERVERULUI

2. Lăsați deschise doar cele patru porturi de care Mordhau are nevoie cu adevărat

Pentru Mordhau sunt suficiente patru deschideri UDP spre exterior, tot restul se restrânge sau nu se publică deloc. Cu UFW arată așa, și anume exact în această ordine, ca să nu vă blocați singur accesul:

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'Mordhau joc'
ufw allow 7778/udp comment 'Mordhau Steam'
ufw allow 15000/udp comment 'Mordhau beacon'
ufw allow 27015/udp comment 'Mordhau interogare'
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

Înlocuiți 203.0.113.10 cu adresa dumneavoastră. Important este ce nu apare aici: nicio deschidere pentru un panou web, niciuna pentru o bază de date, niciuna pentru un server de fișiere. Fiecare port deschis în plus este o țintă în plus, care nu are nimic de-a face cu jocul. Instrucțiunile complete, inclusiv calea de salvare, le găsiți în Configurarea firewallului UFW fără să vă blocați singur accesul.

3. Limitați portul de interogare 27015 fără să ieșiți din lista de servere

Portul de interogare îl puteți limita, dar nu îl puteți închide. Dacă 27015 UDP este blocat, serverul dumneavoastră dispare din browserul de servere, pentru că numărul de jucători, numele hărții și numele serverului sunt citite exact prin acest port. O limită superioară per adresă sursă rezolvă problema fără să vă coste vizibilitatea:

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

Un browser de servere obișnuit interoghează serverul dumneavoastră de câteva ori pe minut, nu de câteva ori pe secundă. Zece interogări pe secundă și per adresă sursă sunt deci generoase pentru orice jucător și strâmte pentru orice bot. Verificați apoi la contorul de potriviri dacă regula chiar se aplică:

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

Aici se află și răspunsul la întrebarea despre reflection. La un reflection serverul dumneavoastră nu este atacat, ci folosit abuziv ca amplificator: interogările vin cu adresa expeditorului falsificată, iar răspunsurile dumneavoastră lovesc o victimă străină. O limitare de rată per adresă sursă este în schimb cea mai eficientă măsură locală, pentru că o adresă de expeditor falsificată este utilă doar atât timp cât serverul dumneavoastră răspunde binevoitor și nelimitat.

4. Scoateți RCON din rețeaua deschisă

La Mordhau, RCON nu are ce căuta în niciun caz nelimitat în internet. Accesul se activează în Game.ini, în secțiunea [/Script/Mordhau.MordhauGameSession]:

[/Script/Mordhau.MordhauGameSession]
ServerName=Serverul meu Mordhau
MaxSlots=64
ServerPassword=
AdminPassword=O-PAROLA-LUNGA-ALEATORIE
RconPassword=ALTA-PAROLA-LUNGA-ALEATORIE
RconPort=27020

Mordhau vorbește protocolul Source RCON, deci TCP, și de aceea lucrează cu orice unealtă RCON obișnuită. Exact asta folosesc și scripturile care încearcă date de acces pe rând. Trei reguli acoperă situația. În primul rând: RconPassword și AdminPassword sunt două parole diferite, lungi, aleatoare, și nu variații ale numelui serverului. În al doilea rând: deschiderea pentru portul RCON o limitați la adresa dumneavoastră, exact ca în blocul UFW de mai sus. În al treilea rând, dacă nu aveți o adresă fixă: nu deschideți portul din exterior și ajungeți la el printr-o redirecționare de port SSH, după care vă conectați local la 127.0.0.1:27020:

ssh -N -L 27020:127.0.0.1:27020 root@ADRESA.IP.A.SERVERULUI

Dacă RCON trebuie totuși să rămână deschis, limitați cel puțin conexiunile simultane per adresă sursă. O unealtă RCON are nevoie de o conexiune, un script de bruteforce de câteva sute:

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

5. Protejați portul beacon 15000 împotriva floodului de conectări

Portul beacon este punctul de atac subestimat al unui server Mordhau. Prin el jocul rezervă slotul unui jucător care se conectează, atât timp cât acesta încă încarcă. Un bot care declanșează conectări în succesiune rapidă ocupă astfel sloturi, fără să ajungă vreodată în joc. Serverul rămâne online și pare totuși plin. O limită superioară per adresă sursă prinde acest comportament, pentru că un jucător real trimite exact un beacon per conectare și nu douăzeci pe secundă:

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

A doua regulă se referă la portul de joc și cere măsură. La un tickrate de 60, serverul schimbă cu fiecare jucător conectat în ordinul de mărime a 60 de pachete pe secundă pe fiecare direcție. O limită de 400 de pachete pe secundă per adresă sursă lasă deci fiecărui jucător real aer din belșug și lovește totuși orice sursă care în mod evident inundă. Măsurați mai întâi o săptămână în regim normal înainte de a strânge limita: cine setează prea strâmt își dă afară proprii jucători și crede după aceea că este un atac.

Regulile iptables simple dispar după o repornire. Pe Debian și Ubuntu se salvează astfel:

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

Sub UFW, astfel de reguli își au locul în /etc/ufw/before.rules, altfel dispar la următorul ufw reload.

6. Game.ini și Engine.ini: ce ajută cu adevărat

Mordhau are două fișiere de configurare, iar ambele se află pe Linux în Mordhau/Saved/Config/LinuxServer/, pe Windows în Mordhau\Saved\Config\WindowsServer\. Fișierul Game.ini reglează numele serverului, sloturile, parolele, lista de administratori, rotația hărților și identificatorii modurilor din mod.io, iar Engine.ini comportamentul de rețea. Editați-le pe amândouă exclusiv cu serverul oprit, altfel procesul serverului suprascrie la oprire modificările dumneavoastră cu starea din memoria de lucru.

Trei setări sunt cu adevărat relevante pentru suprafața de atac. În primul rând un ServerPassword: ține departe pe oricine nu este invitat, dar costă găsirea publică a serverului și nu ajută deloc împotriva unui flood pe portul 7777, pentru că atacatorul nici nu vrea să se conecteze. În al doilea rând o valoare realistă pentru MaxSlots: Mordhau este proiectat pentru până la 64 de jucători, iar fiecare slot suplimentar este o sursă de pachete în plus, pe care procesorul dumneavoastră trebuie să o deservească. În al treilea rând tickrate-ul din Engine.ini:

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

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

Tickrate-ul implicit al unui server Mordhau este 60. O creștere la 120 dublează rata de pachete per jucător și încărcarea procesorului și este deci exact ce nu vă trebuie sub atac. Un server cu 64 de sloturi și tickrate 120 produce deja în regim normal în ordinul de mărime a 8.000 de pachete pe secundă pe fiecare direcție. Cine este atacat permanent merge sensibil mai stabil cu 60 decât cu 120.

7. Degrevați urmărirea conexiunilor și bufferele de recepție

Un blocaj deseori trecut cu vederea este urmărirea conexiunilor din kernel. Ea ține o intrare proprie pentru fiecare flux UDP, iar un flood din zeci de mii de adrese de expeditor falsificate umple tabelul în câteva secunde. Dacă se umple, serverul elimină și pachetele legitime, iar în jurnal apare „nf_conntrack: table full”. Starea și limita superioară le arată:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack | tail -20

Împotriva acestui lucru ajută două variante. Fie ridicați limita superioară, fie scoateți complet porturile de joc din urmărire. A doua variantă este de obicei calea mai bună la un server de joc, pentru că UDP nu are oricum o stare care ar trebui urmărită:

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

La fel de utile sunt buffere de recepție mai mari și o coadă mai adâncă a plăcii de rețea, ca vârfurile scurte să nu ducă imediat la pachete eliminate:

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

Permanent, aceste valori își au locul într-un fișier sub /etc/sysctl.d/, de exemplu 99-gameserver.conf. Important pentru înțelegere: bufferele mai mari nu vă cresc rezistența împotriva unui atac mare, ele împiedică doar ca o oscilație scurtă să coste deja pachete.

8. Adresa dumneavoastră apare în lista de servere, iar asta nu se poate schimba

Aici merită sinceritatea în locul iluziilor: adresa IP a unui server Mordhau public nu poate fi ținută secretă. Apare în intrarea din browserul de servere, apare în listele publice de servere ale terților, care citesc regulat portul de interogare, și o cunoaște fiecare jucător care a fost conectat măcar o dată. O schimbare de adresă aduce de aceea ore, rar zile, pentru că atacatorul găsește noua adresă pe aceeași cale ca pe cea veche.

Eficiente sunt aici trei obiceiuri. Nu publicați nicăieri adresa IP brută, deci nici pe canalul de Discord, nici pe pagina proiectului. Conectați jucătorii printr-un nume de gazdă, ca o schimbare de adresă să nu rupă la nevoie toate referințele. Și curățați intrările DNS vechi, pentru că o înregistrare A uitată către adresa anterioară face orice schimbare inutilă. Același lucru se aplică serverelor de test: orice server secundar accesibil public pe aceeași mașină dezvăluie adresa serverului principal.

9. Măsurați cât timp totul merge normal

Cel mai important pas este acela pe care aproape nimeni nu îl face dinainte: să creați o bază de comparație cât timp serverul merge liniștit. Fără o valoare normală nu puteți spune după un incident dacă 40.000 de pachete pe secundă au fost mult sau pur și simplu sâmbătă seara. Cu apt-get install -y vnstat sysstat măsurarea rulează permanent. În timpul unui incident sunt suficiente patru comenzi:

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

La tcpdump este valabil: limitați întotdeauna cu -c, pentru că o captură la încărcare maximă solicită suplimentar un server deja suprasolicitat. Fiți atent în special la contoarele de pachete eliminate din ip -s link. Valori dropped în creștere cu un procesor liniștit în același timp sunt cel mai clar indiciu că problema este rata de pachete și nu puterea de calcul. Cum evaluați valorile scrie în Recunoașterea unui atac DDoS. Cum configurați serverul curat prin SteamCMD și îl țineți la zi descrie Instalarea unui server de joc cu SteamCMD.

Unde se opresc aceste măsuri: lățimea de bandă și rata de pachete

Acum urmează partea pe care nicio configurație nu o poate rezolva. Toate măsurile de până acum rulează pe serverul dumneavoastră, deci la capătul conexiunii. O regulă de firewall decide asupra unui pachet care a trecut deja prin cablu. Îl puteți elimina, dar nu îl puteți face netrimis.

Faceți o dată socoteala. Un server de joc obișnuit este legat la 1 Gbit/s, adică 125 de megabytes pe secundă, iar conexiunea este plină de îndată ce cineva trimite mai mult. Un server Mordhau plin cu 64 de sloturi are nevoie doar de o fracțiune: la tickrate 60, traficul de joc se află în ordinul de mărime a 4.000 de pachete pe secundă pe fiecare direcție. Un booter închiriat livrează în schimb fără probleme între 5 și 50 Gbit/s, deci de cinci până la cincizeci de ori conexiunea dumneavoastră. Dacă regula iptables din spate este bună nu mai joacă atunci niciun rol, pentru că pachetele jucătorilor dumneavoastră nu mai trec nici înainte de ea.

A doua mărime este rata de pachete, iar ea lovește deseori mai devreme decât lățimea de bandă. La pachete mici de 64 de bytes, într-o conexiune de 1 Gbit/s încap circa 1,49 milioane de pachete pe secundă. Un kernel obișnuit de server prelucrează, în funcție de procesor și placă de rețea, câteva sute de mii dintre ele înainte de a începe să elimine. Un atac care nu vă umple conexiunea nici la o treime poate deci să vă paralizeze serverul Mordhau, pentru că timpul de calcul se duce pe eliminarea pachetelor. Operatorii trăiesc asta ca „încărcarea nici nu era mare, și totuși totul dispăruse”.

Pentru încadrare, ce ordine de mărime apar în realitate: pe serverele KernelHost au fost filtrate, printre altele, un atac de peste 473,4 Gbit/s cu peste 41,5 milioane de pachete pe secundă asupra unui server de voce și un flood UDP de peste 112,2 Gbit/s asupra unui server de joc. Pentru asta nu există nicio setare locală. Atacurile volumetrice trebuie să se termine în rețeaua din fața serverului.

Ce pune KernelHost în față

Protecția permanentă inclusă pe fiecare server

Protecția DDoS de la KernelHost este construită pe două niveluri și este activă permanent, fără să fie nevoie să activați, să comandați sau să configurați ceva:

• Nivelul 1: 17 Tbps capacitate de mitigare în rețeaua globală de scrubbing. Atacurile volumetrice sunt curățate aproape de sursa lor, înainte să ajungă la centrul de date.
• Nivelul 2: filtrare Arbor în timp real cu 3,2 Tbps în Frankfurt pe Main. Direct în fața serverului sunt recunoscute și eliminate tiparele specifice fiecărui protocol, pachet cu pachet.

Două proprietăți sunt decisive. Protecția rulează permanent și nu trebuie să reacționeze mai întâi la un atac, deci nu există minute la început în care serverul dispare. Și nu se folosește nullrouting: adresa dumneavoastră IP rămâne în rețea, eliminate sunt doar pachetele dăunătoare. Cine scoate adresa IP din rețea obține pentru dumneavoastră același rezultat ca atacatorul. Locația este Frankfurt pe Main. Ce jocuri și protocoale sunt acoperite enumeră Protecție DDoS în timp real pentru servere de joc.

Advanced DDoS Protection pentru servere Mordhau atacate permanent

Unele servere nu sunt lovite ocazional, ci țintit și săptămâni la rând. Pentru asta există Advanced DDoS Protection de la 50,00 € pe lună, PrePaid, fără durată minimă și fără taxă de instalare. Diferența nu stă în mai multă capacitate, ci în control:

• IP de protecție dedicat din nucleul de la Frankfurt, pe care serverul dumneavoastră este comutat în rețeaua noastră. De partea dumneavoastră nu este nevoie de nicio modificare.
• Reguli de protecție administrabile de dumneavoastră per port și protocol în panoul clientului: stabiliți separat ce este permis pe 7777 UDP, ce pe 15000 UDP și ce pe 27015 UDP, fără să scrieți un tichet pentru asta.
• Modificările se aplică în timp real, deci puteți ajusta în timpul unui atac în curs, în loc să așteptați o fereastră de mentenanță.
• Profil de protecție potrivit jocului. Pentru serverele de joc Unreal Engine pe UDP și pentru porturile de interogare Steam există profiluri pregătite, la fel și pentru aplicații modificate sau proprii pe orice port TCP sau UDP.

Advanced DDoS Protection se adresează serverelor care rulează la KernelHost. Dacă serverul dumneavoastră Mordhau se află momentan în altă parte și este scos regulat din rețea, mutarea este calea către această filtrare.

Cele două niveluri în comparație

Pentru majoritatea serverelor Mordhau este suficientă protecția permanentă inclusă împreună cu o configurație curată. Advanced DDoS Protection este răspunsul la faptul că cineva o ia personal.

Erori frecvente și soluții

„Am închis portul 27015, acum serverul meu nu mai apare în listă”: Aceasta este consecința previzibilă. Portul de interogare Steam livrează numele, harta și numărul de jucători către browserul de servere. Fără el, serverul dumneavoastră nu mai apare sau este afișat ca inaccesibil. Corect este o limitare de rată per adresă sursă în locul unei blocări.

„Jucătorii nu intră, deși serverul rulează”: Verificați mai întâi portul 15000 UDP. Beaconul rezervă slotul în timpul încărcării. Dacă este blocat, filtrat prea strâmt sau suprasolicitat, conectarea rămâne suspendată, deși portul 7777 răspunde și serverul apare în browser.

„Modificările mele din Game.ini dispar după repornire”: Ați editat fișierul cu serverul pornit. Procesul serverului Mordhau își scrie la oprire starea din memoria de lucru înapoi și suprascrie astfel versiunea dumneavoastră. Opriți serverul, editați, porniți, în această ordine.

„Regulile mele iptables nu se aplică”: Trei cauze sunt frecvente. Regulile stau în spatele lanțurilor UFW și nu sunt atinse niciodată, au dispărut după ultima repornire (atunci ajută netfilter-persistent save sau o intrare în /etc/ufw/before.rules) sau atacul este volumetric și regula lucrează corect pe o conexiune care este de mult plină. Verificați cu iptables -L INPUT -n -v dacă contoarele de potriviri cresc. Dacă rămân la zero, regula nu este atinsă.

„Serverul rulează, dar toți au vârfuri de lag și loviturile ajung prea târziu”: Uitați-vă mai întâi dacă rata pachetelor de intrare crește în timp ce procesorul rămâne liniștit. Exact acesta este tiparul unui atac. Dacă rata de pachete rămâne normală și procesorul stă la 100 la sută, nu este un atac DDoS, ci de obicei un tickrate prea mare, prea multe sloturi sau un mod.

„Furnizorul meu semnalează abuz de ieșire pe portul 27015”: Serverul dumneavoastră a fost folosit abuziv ca amplificator pentru un reflection. Interogările au venit cu adresa expeditorului falsificată, iar serverul dumneavoastră a răspuns unei victime străine. O limitare de rată pe 27015 UDP per adresă sursă pune capăt acestei situații.

„Furnizorul meu de până acum mi-a blocat adresa IP”: Acesta este nullrouting. Furnizorul își protejează astfel propria rețea, iar pentru dumneavoastră rezultatul este identic cu un atac reușit, de obicei încă ore după aceea. Întrebați la nevoie dacă se filtrează sau se face nullrouting. Răspunsul decide mai mult asupra disponibilității dumneavoastră decât orice specificație de hardware.

„În tcpdump nu văd nimic suspect”: Dacă traficul este filtrat deja în rețeaua din față, pe server nu ajunge nimic, așa cum este de așteptat. Acesta este cazul normal la o filtrare care funcționează. Invers este valabil: dacă conexiunea este saturată, este posibil să nu vă mai ajungă nici măcar sesiunea SSH cu care voiați să măsurați. Folosiți atunci consola VNC din panoul clientului, care funcționează independent de rețeaua sistemului oaspete.

Pe scurt

• Un server dedicat Mordhau are nevoie de exact patru porturi UDP spre exterior: 7777 (joc), 7778 (Steam), 15000 (beacon) și 27015 (interogare Steam). Tot restul rămâne închis.
• RCON rulează la Mordhau prin TCP, conform protocolului Source RCON, și devine activ abia prin RconPassword și RconPort în Game.ini. Limitați portul la adresa dumneavoastră.
• Portul 27015 UDP îl puteți limita, dar nu îl puteți închide: fără el serverul dumneavoastră dispare din browserul de servere, pentru că numărul de jucători, harta și numele sunt interogate prin acest port.
• Portul 15000 UDP este portul beacon și rezervă slotul în timpul încărcării. Dacă este blocat sau suprasolicitat, jucătorii nu intră, deși serverul rulează.
• Editați Game.ini și Engine.ini numai cu serverul oprit, pentru că procesul serverului își scrie la oprire starea din memoria de lucru înapoi.
• Regulile locale de firewall se termină la lățimea de bandă: 1 Gbit/s sunt 125 de megabytes pe secundă și, la pachete de 64 de bytes, circa 1,49 milioane de pachete pe secundă. Peste asta decide exclusiv rețeaua din fața serverului.
• La KernelHost, protecția permanentă pe două niveluri este inclusă în fiecare pachet de server fără cost suplimentar și este activă din momentul livrării, fără nullrouting. Cine vrea să controleze singur filtrarea o obține cu Advanced DDoS Protection de la 50,00 € pe lună.

Dacă serverul dumneavoastră Mordhau rulează deja la KernelHost, filtrarea este activă fără să faceți nimic. Dacă observați totuși nereguli, deschideți un tichet de suport, pentru ca regulile de filtrare pentru adresa dumneavoastră IP să fie ajustate. În cazul unui atac în curs ne găsiți suplimentar prin chatul de urgență WhatsApp la +43 650 8209883.