Mordhau-szerver védelme DDoS-támadások ellen

Ha egy Mordhau-szerver egy Frontline-kör közepén egyszerre veszíti el az összes játékost, utána néhány percre offline marad, és eltűnik a szerverlistáról, annak ritkán hardverhiba az oka. Az esetek túlnyomó többségében támadás fut a négy UDP-port valamelyike ellen, amelyeket egy Mordhau dedikált szervernek kifelé nyitva kell tartania. Ez a cikk először azt mutatja meg, mit tehet a Mordhau DDoS-védelméért többletköltség nélkül saját maga, utána azt, hol érnek véget fizikailag ezek az intézkedések, végül pedig azt, minek kell a szerver előtti hálózatban történnie.

Minden adat a hivatalos Mordhau dedikált szerverre vonatkozik (Steam App ID 629800, Unreal Engine 4) Debian 12, Debian 13, Ubuntu 22.04 LTS vagy Ubuntu 24.04 LTS alatt. A parancsok root felhasználóra íródtak, normál felhasználóként tegyen eléjük sudo parancsot. Ha éppen fut a támadás, először ne változtasson semmit a konfiguráción és ne indítsa újra a szervert, hanem mentse el a mérési adatokat (9. szakasz), mert a támadás után már nem lesznek meg. Mordhau esetében jön ehhez egy második ok is, amelyet sok üzemeltető fájdalmasan tanul meg: a szerverfolyamat leálláskor a memóriában tárolt állapotát írja vissza a Game.ini fájlba. Aki futó szerver mellett szerkeszti a fájlt, a következő leállításkor elveszíti a módosításait.

Miért van szükségük a Mordhau-szervereknek DDoS-védelemre, és ki támadja őket

A Mordhau-szervereket azért támadják, mert a címük nyilvános, a teljes játékforgalom UDP-n megy, és egy kiesés azonnal mindenki számára láthatóvá válik. A szerverböngészőben szereplő bejegyzés nyílt szövegben tartalmazza az IP-címet és a játékportot, mert a játékosok különben nem találnák meg a szervert. A nyilvános szerverlisták és trackerek ugyanezeket az adatokat a Steam-lekérdezőporton keresztül olvassák ki, és másodszor is közzéteszik. A címe tehát nem titok, hanem termékadat.

Ehhez jön a játék technikája. Az Unreal Engine 4 a mozgásokat, a találatokat és a hárításokat UDP-n továbbítja. Az UDP nem ismer kapcsolatfelépítést, amelyet meg lehetne követelni, és egy UDP-csomag feladócíme hamisítható. A támadónak tehát sem belépnie nem kell a szerverére, sem helyesen megszólítania azt ahhoz, hogy terhelést okozzon. Mordhau esetében ez többet nyom a latban, mint sok más játéknál: egy összecsapás néhány tizedmásodperc alatt dől el, és már 200 ezredmásodpercnyi többletkésleltetés játszhatatlanná teszi a közelharcot, jóval azelőtt, hogy a szerver ténylegesen kiesne. Pontosan ezért elég egy kis támadás ahhoz, hogy tönkretegyen egy kört. Hogy részleteiben mi a DDoS-támadás, azt a Mi az a DDoS-támadás? című cikk magyarázza el.

A tipikus kiváltó okok nem látványosak: közösségek közötti versengés, kitiltott játékosok, elvesztett párbajok, veszekedés a Discordon. Egy támadás a megrendelőjének sem tudást, sem említésre méltó pénzt nem kerül, mert a bérelhető booter-szolgáltatások elvégzik a munkát. Az üzemeltetők rendszeresen beszámolnak arról, hogy a támadások pontosan akkor indulnak, amikor tele van a szerver, és akkor állnak le, amikor kiürül. Ez nem véletlen, hanem arra utal, hogy valaki figyeli a szerverböngésző-bejegyzését, és a játékosszámot használja kiváltó jelként.

A portok, amelyekről Mordhau esetében valójában szó van

Egy Mordhau dedikált szervernek pontosan négy UDP-portra van szüksége kifelé: 7777, 7778, 15000 és 27015. Minden más vagy opcionális, vagy nem való a nyílt hálózatra. A portokat indításkor paraméterként adja át:

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

Két dolgot értenek ezzel kapcsolatban rendszeresen félre. Először: a 15000-es beacon-port nem mellékes. A beacon abban a pillanatban foglalja le a slotot, amikor egy játékos csatlakozik, hogy a pálya betöltése után ne repüljön ki újra. Ha a 15000-es port blokkolva van vagy túlterhelt, a játékosok nem jutnak be, hiába válaszol a 7777-es port. Másodszor: az RCON Mordhau alatt nincs előre beállítva. Csak akkor válik aktívvá, ha beállítja a RconPassword és a RconPort értéket, és akkor TCP-n fut, nem UDP-n.

Egy Mordhau-szerver legfontosabb adatai egy pillantásra:

A Mordhau esetében előforduló támadási minták

Négy minta gyakorlatilag mindent lefed, amit egy Mordhau-szerver ellen bevetnek, és mindegyik más portot ér.

• UDP-flood a 7777-es játékport ellen. Ez egy booter alapértelmezett támadása: minél több hamisított csomag arra a portra, amely a szerverböngészőben szerepel. Sávszélességet és csomagsebességet céloz, nem pedig sebezhetőséget, és először lag-tüskékként jelentkezik, jóval azelőtt, hogy bárki elveszítené a kapcsolatot.
• Lekérdezésflood a 27015-ös lekérdezőport ellen. Egy A2S_INFO-lekérdezés 25 bájt, a szervernevet, a pályát, a játékmódot és a játékosszámot tartalmazó válasz ennek többszöröse. A támadó tehát keveset fektet be, és Önnél kényszerít ki számítási munkát meg kimenő forgalmat.
• Reflexiós támadás a saját lekérdezőportján keresztül. Itt nem a szervere a célpont, hanem az eszköz: a támadó hamisított feladócímmel küld lekérdezéseket, és a szervere az áldozatnak válaszol. Ezt megmagyarázhatatlanul magas kimenő forgalomként érzékeli a 27015-ös porton, illetve a szolgáltatója visszaélési bejelentéseként.
• Csatlakozás- és slotkimerítés a 15000-es beacon-porton keresztül. Sávszélesség elégetése helyett automatizált csatlakozások foglalják le a lefoglalt slotokat. A szerver tovább fut, de tele van, és a valódi játékosok nem jutnak be.

Ehhez jön egy ötödik minta, amint az RCON nyitottan áll a hálózaton: másodpercenkénti bejelentkezési kísérletek az RCON-port ellen. Ez ritkán volumetrikus, de processzoridőt emészt, és az öt eset közül ez az egyetlen, amelyben egy találat teljesen kiveszi a kezéből a szervert.

Mit tehet saját maga, mielőtt pénzt költene

Ez a szakasz a leghosszabb, és ez szándékos. Egy tisztán beállított Mordhau-szerver saját erőből kibírja a kis és közepes támadásokat, függetlenül attól, kinél üzemel.

1. Leltár: mi figyel egyáltalán a szerveren?

Mielőtt egyetlen tűzfalszabályt is írna, nézze meg, mit kínál a szervere kifelé. Nem találgatni, hanem megnézni:

ss -lntup

A helyi címet tartalmazó oszlop az érdekes. A 0.0.0.0:7777 és a [::]:7777 azt jelenti, hogy „az egész internetről elérhető", a 127.0.0.1:27020 pedig azt, hogy „csak helyileg", és nem igényel tűzfalszabályt. A játék mellett ott gyakran felbukkan még egy webes vezérlőpult, egy adatbázis-szolgáltatás és egy rég elfeledett hangszolgáltatás is. A támadó nézőpontját egy kívülről indított vizsgálat adja, UDP esetén rövid portlistával, mert a teljes UDP-vizsgálat nagyon lassú:

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

2. Csak azt a négy portot hagyja nyitva, amelyre a Mordhaunak valóban szüksége van

A Mordhauhoz négy UDP-engedélyezés elég kifelé, minden mást korlátozni kell, vagy eleve nem szabad közzétenni. UFW-vel ez így néz ki, méghozzá pontosan ebben a sorrendben, nehogy kizárja saját magát:

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'Mordhau játék'
ufw allow 7778/udp comment 'Mordhau Steam'
ufw allow 15000/udp comment 'Mordhau beacon'
ufw allow 27015/udp comment 'Mordhau lekérdezés'
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

Cserélje ki a 203.0.113.10 címet a sajátjára. Az a fontos, ami itt nem szerepel: nincs engedélyezés webes vezérlőpulthoz, nincs adatbázishoz, nincs fájlszerverhez. Minden további nyitott port egy további célpont, amelynek semmi köze a játékhoz. A teljes útmutatót a menekülőúttal együtt az UFW-tűzfal beállítása anélkül, hogy kizárná magát című cikkben találja.

3. A 27015-ös lekérdezőport korlátozása anélkül, hogy kikerülne a szerverlistáról

A lekérdezőportot korlátozhatja, de nem zárhatja le. Ha a 27015-ös UDP-portot bezárja, a szervere eltűnik a szerverböngészőből, mert a játékosszámot, a pálya nevét és a szervernevet pontosan ezen a porton keresztül kérdezik le. Egy forráscímenkénti felső korlát megoldja a problémát anélkül, hogy a láthatóságba kerülne:

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

Egy szabályos szerverböngésző percenként néhányszor kérdezi le a szerverét, nem másodpercenként néhányszor. A forráscímenkénti tíz lekérdezés másodpercenként tehát bőkezű minden játékos felé és szűk minden bot felé. Utána a találatszámlálón ellenőrizze, hogy a szabály egyáltalán érvényesül-e:

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

Itt van a reflexiós kérdés válasza is. Egy reflexiós támadásnál nem a szerverét támadják, hanem erősítőként élnek vissza vele: a lekérdezések hamisított feladócímmel érkeznek, és az Ön válaszai egy idegen áldozatot érnek. A forráscímenkénti sebességkorlátozás ezzel szemben a leghatásosabb helyi intézkedés, mert egy hamisított feladócím csak addig hasznos, amíg a szervere készségesen és korlátlanul válaszol.

4. Az RCON kivétele a nyílt hálózatból

Az RCON Mordhau esetében semmiképpen nem való korlátozás nélkül az internetre. A hozzáférést a Game.ini fájlban, a [/Script/Mordhau.MordhauGameSession] szakaszban kapcsolja be:

[/Script/Mordhau.MordhauGameSession]
ServerName=A Mordhau szerverem
MaxSlots=64
ServerPassword=
AdminPassword=EgyHosszuVeletlenJelszo
RconPassword=EgyMasikHosszuVeletlenJelszo
RconPort=27020

A Mordhau a Source RCON protokollt beszéli, tehát TCP-n megy, és ezért minden elterjedt RCON-eszközzel együttműködik. Pontosan ezt használják ki azok a szkriptek is, amelyek bejelentkezési adatokat próbálgatnak. Három szabály lefedi ezt az esetet. Először: a RconPassword és az AdminPassword két különböző, hosszú, véletlenszerű jelszó, nem pedig a szervernév változata. Másodszor: az RCON-port engedélyezését korlátozza a saját címére, ahogy a fenti UFW-blokkban. Harmadszor, ha nincs fix címe: hagyja a portot kívülről zárva, és egy SSH-porttovábbításon keresztül érje el, majd csatlakozzon helyileg a 127.0.0.1:27020 címre:

ssh -N -L 27020:127.0.0.1:27020 root@A.SZERVERE.IP.CIME

Ha az RCON-nak mégis nyitva kell maradnia, legalább a forráscímenkénti egyidejű kapcsolatok számát korlátozza. Egy RCON-eszköznek egy kapcsolat kell, egy bruteforce-szkriptnek több száz:

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

5. A 15000-es beacon-port védelme a csatlakozásfloodok ellen

A beacon-port egy Mordhau-szerver alábecsült támadási pontja. Ezen keresztül foglalja le a játék a csatlakozó játékos slotját, amíg az még tölt. Egy bot, amely gyors egymásutánban indít csatlakozásokat, így slotokat foglal le anélkül, hogy valaha is megérkezne a játékba. A szerver online marad, és mégis telinek tűnik. Egy forráscímenkénti felső korlát ezt elfogja, mert egy valódi játékos csatlakozásonként pontosan egyszer küld beacont, nem pedig másodpercenként hússzor:

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 második szabály a játékportra vonatkozik, és mértéket kíván. 60-as tickrate mellett a szerver minden csatlakozott játékossal nagyságrendileg 60 csomagot vált másodpercenként irányonként. A forráscímenkénti 400 csomag másodpercenkénti határérték tehát minden valódi játékosnak bőven hagy levegőt, és mégis elér minden olyan forrást, amely láthatóan floodol. Mérjen előbb egy hetet normál üzemben, mielőtt szűkebbre állítja: aki túl szűkre állítja, kidobja a saját játékosait, és azt utána támadásnak hiszi.

A puszta iptables-szabályok újraindítás után eltűnnek. Debian és Ubuntu alatt így menti el őket:

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

UFW alatt az ilyen szabályok helye a /etc/ufw/before.rules fájl, mert különben a következő ufw reload parancsnál eltűnnek.

6. Game.ini és Engine.ini: ami valóban számít

A Mordhaunak két konfigurációs fájlja van, és mindkettő Linux alatt a Mordhau/Saved/Config/LinuxServer/, Windows alatt a Mordhau\Saved\Config\WindowsServer\ könyvtárban található. A Game.ini szabályozza a szervernevet, a slotokat, a jelszavakat, az adminlistát, a pályarotációt és a mod.io-ról származó modazonosítókat, az Engine.ini pedig a hálózati viselkedést. Mindkettőt kizárólag leállított szerver mellett szerkessze, különben a szerverfolyamat leálláskor felülírja a módosításait a memóriában lévő állapottal.

Három beállítás igazán lényeges a támadási felület szempontjából. Először egy ServerPassword: mindenkit távol tart, akit nem hívtak meg, de a nyilvános megtalálhatóságba kerül, és a 7777-es port elleni flood ellen egyáltalán nem segít, mert a támadó nem is akar csatlakozni. Másodszor egy reális MaxSlots érték: a Mordhau legfeljebb 64 játékosra készült, és minden további slot egy további csomagforrás, amelyet a processzorának ki kell szolgálnia. Harmadszor a tickrate az Engine.ini fájlban:

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

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

Egy Mordhau-szerver alapértelmezett tickrate-je 60. A 120-ra emelés megkétszerezi a játékosonkénti csomagsebességet és a processzorterhelést, tehát pontosan az, amire támadás alatt nincs szüksége. Egy 64 slotos szerver 120-as tickrate mellett normál üzemben már nagyságrendileg 8000 csomagot állít elő másodpercenként irányonként. Aki tartósan tűz alatt áll, 60-nal érezhetően stabilabban jár, mint 120-szal.

7. A kapcsolatkövetés és a fogadópufferek tehermentesítése

Gyakran figyelmen kívül hagyott szűk keresztmetszet a kernel kapcsolatkövetése. Minden UDP-folyamhoz külön bejegyzést vezet, és egy több tízezer hamisított feladócímből álló flood másodpercek alatt megtölti a táblát. Ha megtelik, a szerver a jogos csomagokat is eldobja, a naplóban pedig ez áll: „nf_conntrack: table full". Az állapotot és a felső korlátot ez mutatja meg:

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

Ez ellen kétféleképpen lehet tenni. Vagy megemeli a felső korlátot, vagy teljesen kiveszi a játékportokat a követésből. Utóbbi egy játékszervernél többnyire a jobb út, mert az UDP-nek amúgy sincs állapota, amit követni kellene:

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

Szintén érdemes nagyobb fogadópuffereket és mélyebb hálózatikártya-várósort beállítani, hogy a rövid csúcsok ne vezessenek azonnal eldobásokhoz:

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

Tartósan ezeknek az értékeknek a helye egy /etc/sysctl.d/ könyvtárban lévő fájl, például a 99-gameserver.conf. Fontos a megértéshez: a nagyobb pufferek nem növelik a nagy támadással szembeni terhelhetőségét, csak azt akadályozzák meg, hogy már egy rövid kilengés is csomagokba kerüljön.

8. A címe benne van a szerverlistában, és ezen nem lehet változtatni

Itt megéri az őszinteség a vágyálom helyett: egy nyilvános Mordhau-szerver IP-címét nem lehet titokban tartani. Benne van a szerverböngésző-bejegyzésben, benne van a harmadik felek nyilvános szerverlistáiban, amelyek rendszeresen kiolvassák a lekérdezőportot, és ismeri minden játékos, aki egyszer csatlakozott. Egy címcsere ezért órákat, ritkán napokat nyer, mert a támadó ugyanazon az úton találja meg az új címet, mint a régit.

Ezzel szemben három szokás hatásos. Sehol ne tegye közzé maga a nyers IP-címet, tehát se a Discord-csatornán, se a projekt oldalán. A játékosait hosztnéven keresztül kösse be, hogy egy címcsere komoly esetben ne törje el az összes hivatkozást. És takarítsa ki a régi DNS-bejegyzéseket, mert egy elfelejtett, a korábbi címre mutató A-rekord minden cserét hatástalanná tesz. Ugyanez vonatkozik a tesztszerverekre: minden nyilvánosan elérhető második szerver ugyanazon a gépen elárulja a főszerver címét.

9. Mérjen, amíg minden normálisan fut

A legfontosabb lépés az, amelyet előre szinte senki sem tesz meg: összehasonlítási alapot létrehozni, amíg a szerver nyugodtan fut. Normálérték nélkül egy incidens után nem tudja megmondani, hogy a 40 000 csomag másodpercenként sok volt-e, vagy csak szombat este. Az apt-get install -y vnstat sysstat paranccsal a mérés tartósan fut. Egy incidens alatt négy parancs elég:

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

A tcpdump esetében érvényes: mindig korlátozza a -c kapcsolóval, mert egy teljes terhelés alatti rögzítés tovább terheli az amúgy is túlterhelt szervert. Különösen figyeljen az ip -s link eldobásszámlálóira. A növekvő dropped értékek nyugodt processzor mellett a legegyértelműbb jelei annak, hogy a csomagsebesség és nem a számítási teljesítmény a probléma. Hogy az értékeket hogyan értékelje ki, azt a DDoS-támadás felismerése írja le. Hogy a szervert hogyan állítsa be tisztán SteamCMD-vel és hogyan tartsa naprakészen, azt a Játékszerver telepítése SteamCMD-vel ismerteti.

Hol érnek véget ezek az intézkedések: sávszélesség és csomagsebesség

Most jön az a rész, amelyet semmilyen konfigurációs fájl nem old meg. Minden eddigi intézkedés az Ön szerverén fut, tehát a vezeték végén. Egy tűzfalszabály olyan csomagról dönt, amely már végigfutott a kábelen. Eldobhatja, de nem teheti el nem küldötté.

Számoljon egyszer utána. Egy tipikus játékszerver 1 Gbit/s-en lóg, ez 125 megabájt másodpercenként, és a vezeték megtelik, amint valaki többet küld. Egy teli, 64 slotos Mordhau-szervernek ennek csak töredékére van szüksége: 60-as tickrate mellett a játékforgalom nagyságrendileg 4000 csomag másodpercenként irányonként. Egy bérelt booter ezzel szemben gond nélkül szállít 5 és 50 Gbit/s közötti forgalmat, tehát a vezetéke ötszörösét vagy akár ötvenszeresét. Hogy az iptables-szabálya mögötte jó-e, akkor már nem számít, mert a játékosai csomagjai már előtte sem jutnak át.

A második mennyiség a csomagsebesség, és gyakran hamarabb üt be, mint a sávszélesség. 64 bájtos kis csomagok esetén egy 1 Gbit/s-es vezetékbe nagyjából 1,49 millió csomag fér el másodpercenként. Egy normál szerverkernel a processzortól és a hálózati kártyától függően ebből néhány százezret dolgoz fel, mielőtt elkezdene eldobni. Egy támadás, amely a vezetékét még egyharmadáig sem tölti meg, tehát mégis megbéníthatja a Mordhau-szerverét, mert a processzoridő az eldobásra megy el. Az üzemeltetők ezt így élik meg: „a terhelés nem is volt magas, mégis minden elveszett".

Hogy milyen nagyságrendek fordulnak elő a valóságban: a KernelHost szerverein többek között egy 473,4 Gbit/s feletti támadást 41,5 millió csomag másodpercenkénti értékkel egy hangszerver ellen, valamint egy 112,2 Gbit/s feletti UDP-floodot egy játékszerver ellen szűrtek ki. Erre nincs helyi beállítás. A volumetrikus támadásoknak a szerver előtti hálózatban kell véget érniük.

Mit állít ezzel szembe a KernelHost

A folyamatos védelem, amely minden szerverben benne van

A KernelHost DDoS-védelme kétrétegű felépítésű és tartósan aktív, anélkül hogy bármit be kellene kapcsolnia, megrendelnie vagy beállítania:

• 1. réteg: 17 Tbps mitigációs kapacitás a globális scrubbing-hálózatban. A volumetrikus támadásokat a forrásukhoz közel tisztítják meg, mielőtt elérnék az adatközpontot.
• 2. réteg: Arbor valós idejű szűrés 3,2 Tbps kapacitással Frankfurt am Mainban. Közvetlenül a szerver előtt ismerik fel és dobják el a protokollspecifikus mintákat, csomagról csomagra.

Két tulajdonság döntő. A védelem folyamatosan fut, és nem kell először reagálnia egy támadásra, tehát nincsenek kezdeti percek, amelyekben a szerver eltűnik. És nem alkalmaznak null-routingot: az IP-címe a hálózatban marad, csak a káros csomagokat dobják el. Aki kiveszi az IP-címet a hálózatból, az Ön számára ugyanazt az eredményt éri el, mint a támadó. A helyszín Frankfurt am Main. Hogy mely játékok és protokollok vannak lefedve, azt a Játékszerverek valós idejű DDoS-védelme sorolja fel.

Advanced DDoS Protection a tartósan támadott Mordhau-szerverekhez

Némelyik szervert nem alkalmanként, hanem célzottan és heteken át támadják. Erre való az Advanced DDoS Protection havi 50,00 eurótól, PrePaid alapon, minimális futamidő és beállítási díj nélkül. A különbség nem a nagyobb kapacitásban, hanem a kontrollban van:

• Dedikált védett IP a frankfurti központi hálózatból, amelyre a szerverét a saját hálózaton belül átállítják. Az Ön oldalán nincs szükség átalakításra.
• Önállóan kezelhető védelmi szabályok portonként és protokollonként az ügyfélportálon: külön határozza meg, mi engedélyezett a 7777 UDP-n, mi a 15000 UDP-n és mi a 27015 UDP-n, anélkül hogy ehhez ticketet kellene írnia.
• A módosítások valós időben lépnek érvénybe, tehát futó támadás közben is utánaigazíthat, ahelyett hogy karbantartási ablakra várna.
• A játékhoz illő védelmi profil. Az UDP-n futó Unreal Engine játékszerverekhez és a Steam-lekérdezőportokhoz kész profilok vannak, ugyanígy a módosított és saját alkalmazásokhoz tetszőleges TCP- vagy UDP-portokon.

Az Advanced DDoS Protection a KernelHostnál futó szerverekhez szól. Ha a Mordhau-szervere jelenleg máshol áll, és rendszeresen kilövik a hálózatról, a költözés vezet el ehhez a szűréshez.

A két szint összehasonlítása

A legtöbb Mordhau-szerverhez elegendő a beépített folyamatos védelem egy tiszta konfigurációval együtt. Az Advanced DDoS Protection arra a válasz, hogy valaki személyes ügyet csinál belőle.

Gyakori hibák és megoldások

„Lezártam a 27015-ös portot, és most már nem szerepel a szerverem a listában": Ez a várható következmény. A Steam-lekérdezőport szolgáltatja a nevet, a pályát és a játékosszámot a szerverböngészőnek. Nélküle a szervere már nem jelenik meg, vagy nem elérhetőként szerepel. A helyes megoldás a forráscímenkénti sebességkorlátozás a zárolás helyett.

„A játékosok nem jutnak be, pedig a szerver fut": Először a 15000-es UDP-portot ellenőrizze. A beacon a betöltés alatt foglalja le a slotot. Ha zárolva van, túl szűken van szűrve vagy túlterhelt, a csatlakozás elakad, hiába válaszol a 7777-es port és hiába szerepel a szerver a böngészőben.

„A Game.ini fájlban végzett módosításaim újraindítás után eltűnnek": Futó szerver mellett szerkesztette a fájlt. A Mordhau szerverfolyamata leálláskor visszaírja a memóriában lévő állapotát, és eközben felülírja az Ön verzióját. Szerver leállítása, szerkesztés, indítás, ebben a sorrendben.

„Az iptables-szabályaim nem érvényesülnek": Három ok gyakori. A szabályok az UFW-láncok mögött állnak, és soha nem kerülnek sorra; a legutóbbi újraindítás után eltűntek (ekkor a netfilter-persistent save vagy egy bejegyzés a /etc/ufw/before.rules fájlban segít); vagy a támadás volumetrikus, és a szabály helyesen dolgozik egy olyan vezetéken, amely már rég tele van. Az iptables -L INPUT -n -v paranccsal ellenőrizze, nőnek-e a találatszámlálók. Ha nullán maradnak, a szabály nem kerül sorra.

„A szerver fut, de mindenkinek lag-tüskéi vannak, és a találatok késve érkeznek meg": Először nézze meg, nő-e a bejövő csomagsebesség, miközben a processzor nyugodt marad. Pontosan ez egy támadás mintázata. Ha a csomagsebesség normális marad, és a processzor mégis 100 százalékon áll, akkor nem DDoS-támadásról van szó, hanem többnyire túl magas tickrate-ről, túl sok slotról vagy egy modról.

„A szolgáltatóm kimenő visszaélést jelez a 27015-ös portról": A szerverét erősítőként használták fel egy reflexiós támadáshoz. A lekérdezések hamisított feladócímmel érkeztek, a szervere pedig egy idegen áldozatnak válaszolt. A 27015-ös UDP-porton alkalmazott, forráscímenkénti sebességkorlátozás ennek véget vet.

„Az eddigi szolgáltatóm letiltotta az IP-címemet": Ez a null-routing. A szolgáltató ezzel a saját hálózatát védi, az Ön számára az eredmény azonos egy sikeres támadáséval, többnyire még órákkal utána is. Kétség esetén kérdezzen rá, hogy szűrnek-e vagy null-routingolnak. A válasz többet dönt el a rendelkezésre állásáról, mint bármelyik hardveradat.

„A tcpdumpban nem látok semmi feltűnőt": Ha a forgalmat már az előtte lévő hálózatban kiszűrik, a szerverre a várakozásnak megfelelően semmi nem érkezik meg. Működő szűrés mellett ez a normális eset. Fordítva viszont igaz: ha a vezeték telített, adott esetben már az az SSH-munkamenet sem ér el Önhöz, amellyel mérni szeretett volna. Használja ilyenkor az ügyfélportálon elérhető VNC-konzolt, amely a vendégrendszer hálózatától függetlenül működik.

Röviden összefoglalva

• Egy Mordhau dedikált szervernek pontosan négy UDP-portra van szüksége kifelé: 7777 (játék), 7778 (Steam), 15000 (beacon) és 27015 (Steam-lekérdezés). Minden más marad zárva.
• Az RCON Mordhau alatt TCP-n, a Source RCON protokoll szerint fut, és csak a Game.ini fájlba írt RconPassword és RconPort értékkel válik aktívvá. Korlátozza a portot a saját címére.
• A 27015-ös UDP-portot korlátozhatja, de nem zárhatja le: nélküle a szervere eltűnik a szerverböngészőből, mert a játékosszámot, a pályát és a nevet ezen a porton kérdezik le.
• A 15000-es UDP-port a beacon-port, és a betöltés alatt foglalja le a slotot. Ha blokkolva van vagy túlterhelt, a játékosok nem jutnak be, hiába fut a szerver.
• A Game.ini és az Engine.ini fájlt csak leállított szerver mellett szerkessze, mert a szerverfolyamat leálláskor visszaírja a memóriában lévő állapotot.
• A helyi tűzfalszabályok a sávszélességnél érnek véget: 1 Gbit/s az 125 megabájt másodpercenként, és 64 bájtos csomagok esetén nagyjából 1,49 millió csomag másodpercenként. Ezen felül kizárólag a szerver előtti hálózat dönt.
• A KernelHostnál a kétrétegű folyamatos védelem minden szervercsomagban felár nélkül benne van, és a kiépítéstől aktív, null-routing nélkül. Aki maga akarja vezérelni a szűrést, az Advanced DDoS Protection szolgáltatással havi 50,00 eurótól megkapja.

Ha a Mordhau-szervere már a KernelHostnál fut, a szűrés aktív, anélkül hogy bármit tennie kellene. Ha mégis rendellenességet észlel, nyisson egy support-ticketet, hogy az IP-címéhez tartozó szűrési szabályokat utánaigazítsák. Futó támadás esetén ezen felül a WhatsApp-vészhelyzeti csevegésen is elér minket a +43 650 8209883 számon.