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

Ha egy DayZ-szerver este, játék közben kidobja az összes játékost, majd percekre eltűnik a szerverböngészőből, annak ritkán van hardveres oka. Többnyire támadás fut, méghozzá pontosan akkor, amikor a legtöbb játékos online van, vagy amikor esedékes a tervezett újraindítás. Aki a DayZ-szerverét meg akarja védeni a DDoS-támadásoktól, annak ezért mindkettőre szüksége van: tiszta portengedélyezésre a szerveren és szűrésre a szerver előtti hálózatban. Ez a cikk először azt mutatja meg, mit tud Ön többletköltség nélkül saját maga bebiztosítani, utána azt, hol érnek véget műszakilag ezek az intézkedések, végül pedig azt, minek kell ezután a szerver előtt történnie.

Minden adat saját DayZ dedikált szerverre vonatkozik serverDZ.cfg fájllal, mindegy, hogy Windows Server alatt fut, vagy Debian és Ubuntu alatt kompatibilitási rétegen keresztül. Éles üzemre kész natív Linux-szerverprogramot a stabil ághoz a Bohemia Interactive nem ad ki, a kísérleti Linux-build kizárólag kísérleti klienseket fogad. A Linux-parancsok root felhasználóra íródtak, normál felhasználóként tegyen eléjük sudo parancsot.

Ha a támadás éppen fut: most ne változtasson semmit a serverDZ.cfg fájlon, és ne indítsa újra a szervert. Egy DayZ-újraindítás újratölti a modokat és a központi ökonómiát, és több percébe kerül, amely alatt a szerver garantáltan offline. Először mentse el a mérési értékeket (lásd a „Naplózás” szakaszt), a támadás után már nem lesznek meg.

Miért olyan gyakran célpontjai a DayZ-szerverek a DDoS-támadásoknak

A DayZ több olyan tulajdonságot egyesít, amelyek kényelmes célponttá tesznek egy szervert. Először is egy közösségi szerver magától közzéteszi a címét: ahhoz, hogy megjelenjen a játék szerverböngészőjében és a széles körben használt DZSA-launcherben, válaszolnia kell a Steam-lekérdezésekre, és ez a válasz nyílt szövegben tartalmazza az IP-címet és a portot. A támadónak tehát semmit nem kell kiderítenie, csak el kell olvasnia egy listát.

Másodszor egy DayZ-szerver napirendje nyilvános. Gyakorlatilag minden projekt három-négy óránként automatikusan újraindul, ezt chatüzenetben jelzi, a tervet pedig kiírja a Discordra. Egy támadás, amely pontosan ebbe az időablakba esik, kétszeresen hat: a szerver amúgy sem elérhető éppen, a várakozó játékosok pedig máshová mennek.

Harmadszor a tét magas a játékosok számára. A rossz percben bekövetkező kiesés a DayZ-ben nem csupán bosszúság, hanem elvesztett felszerelés, félbeszakadt raid és egy bázis, amely védtelenül áll a világban. Pontosan ezért a kitiltott játékosok, az ellenséges csoportok és a konkurens projektek a leggyakoribb megrendelők. Egy támadás a szokásos booter-szolgáltatások egyikén keresztül sem tudást, sem említésre méltó pénzt nem igényel a megrendelőtől.

Negyedszer a teljes DayZ-forgalom UDP-n keresztül megy. Az UDP nem ismer kapcsolatfelépítést, amelyet meg lehetne követelni, és a feladó címe hamisítható. A támadónak tehát sem belépnie nem kell a szerverére, sem szabályosan megszólítania azt ahhoz, hogy terhelést keltsen. Hogy ez még a gyártót is érinti, azt 2025 februárja mutatta meg: a Bohemia Interactive DayZ és Arma Reforger online szolgáltatásai több mint egy héten át DDoS-tűz alatt álltak, ezt 2025. február 3-án erősítették meg, és 2025. február 6-án még mindig nem ért véget, a közösségi szerverek pedig együtt szenvedték el. Hogy pontosan mi a DDoS-támadás, azt a Mi az a DDoS-támadás? cikk magyarázza el.

Egy DayZ-szerver portjai: ténytáblázat

Egy DayZ-szerver kizárólag UDP-t beszél. TCP-játékport nem létezik. Az egyetlen érték, amely a DayZ-nél valóban fix, a 2302/UDP játékportként, minden más konfigurálható, és szolgáltatónként eltér. Ezért a saját indítósorában és a saját serverDZ.cfg fájljában nézzen utána, ahelyett hogy egy alapértékre hagyatkozna.

Két érték okoz rendszeresen zavart, ezért itt a feloldás. A Steam-query-port: a Bohemia által mellékelt mintakonfiguráció a steamQueryPort = 2305; értéket állítja be, miközben a szolgáltatók jelentős része a 27016/UDP portot használja. Mindkét érték érvényes, egyedül a saját fájljában szereplő érték a döntő. A BattlEye-RCon-port: itt egyáltalán nincs kötelező alapérték. Az elterjedt ökölszabály a játékport plusz három, tehát 2305, más szolgáltatók a 2310-et állítják be. A DayZ 1.13 óta a BattlEye megbízhatóan értelmezi a RConPort paramétert a BEServer_x64.cfg fájlban, korábban a port nehezen volt előre kiszámítható.

Ebből egy olyan csapda következik, amely sok üzemeltetőt elér: a steamQueryPort és a RConPort értéket soha ne állítsa azonosra. Ha a konfigurációja a 2305-öt szánja a Steam-lekérdezésre, akkor az RCon egy másik portra tartozik, például a 2310-re.

Miért a Steam-query-port a legérzékenyebb port

A Steam-query-port három lekérdezésre válaszol: A2S_INFO, A2S_PLAYERS és A2S_RULES. Az A2S_INFO a szerver nevét, a térképet, a játékosszámot és a verziót adja vissza, az A2S_PLAYERS a csatlakozott játékosok nevét, az A2S_RULES a beállított szerverváltozókat. Mindegyik válasz jóval nagyobb, mint a kérés, amely kiváltotta, és pontosan ez teszi a portot kétszeresen veszélyessé.

Az Ön számára célpontként ez azt jelenti: a támadó kérésenként néhány bájttal képes lefoglalni a query-portját, miközben a szervere minden alkalommal teljes választ állít össze és küld el. Harmadik felek számára azt jelenti: a támadó hamisított feladócímmel kérdezheti le a szerverét, és a válaszokat a tulajdonképpeni célpontjára irányíthatja. A szervere ilyenkor nemcsak áldozat, hanem erősítő is. A Valve ezért 2020 decemberében kiegészítette az A2S_INFO lekérdezést egy challenge-kérdéssel: a szerver először egy véletlen számmal válaszol, amelyet a kérdezőnek vissza kell küldenie. Ez tompítja az erősítést, de nem szünteti meg, mert korántsem minden lekérdezés jár be ezen az úton.

A DayZ-nek itt van egy sajátossága, amely más játékoknál nincs: két különálló szerverlista kérdezi le Önt, a beépített közösségi szerverböngésző és a széles körben elterjedt DZSA-launcher. A query-portot egyszerűen bezárni ezért nem opció, mert akkor a projektje mindkét listából eltűnik, noha a közvetlen csatlakozás továbbra is működik. A helyes válasz a korlátozás a bezárás helyett.

Amit saját maga megtehet, mielőtt pénzt költene

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

1. Leltár: mely portokat nyitja meg valójában a DayZ-szervere

Mielőtt egyetlen tűzfalszabályt is írna, nézze meg, mit kínál a szervere kifelé. Ne találgasson, nézzen utána. Linux alatt:

ss -lnup
ss -lntup

Windows Server alatt a parancssor ugyanezt a képet adja:

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

A helyi címet tartalmazó oszlop az érdekes. A 0.0.0.0:2302 azt jelenti, hogy „az egész internetről elérhető”, a 127.0.0.1:2310 azt, hogy „csak helyben”, és nem igényel engedélyezést. Ezután a tényleges értékeket közvetlenül a saját konfigurációs fájljaiból olvassa ki, ahelyett hogy egy útmutatóra hagyatkozna:

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

A támadó nézőpontját egy kívülről, másik gépről futtatott UDP-portszkennelés adja:

nmap -Pn -sU -p 2302-2310,27015-27020 A.SZERVER.IP.CIME

2. Csak azt engedélyezze, amire az indítósornak és a serverDZ.cfg fájlnak valóban szüksége van

A DayZ-hez két engedélyezés elég kifelé: a játékportblokk és a query-port. Minden mást a saját címére korlátoz, vagy közzé sem tesz. UFW-vel ez így néz ki, méghozzá pontosan ebben a sorrendben, hogy ki ne zárja saját magát:

ufw allow 22/tcp comment 'SSH'
ufw allow 2302:2305/udp comment 'DayZ jatekport'
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

A 203.0.113.10 helyére írja be a saját címét, a 27016 helyére pedig azt az értéket, amely valóban a steamQueryPort sorában áll. A teljes útmutatót a mentőúttal együtt az UFW-tűzfal beállítása anélkül, hogy kizárná magát cikkben találja. Windows-szerveren ugyanaz az elv érvényes: egy bejövő szabály portcsoportonként, a távoli asztal a saját címre korlátozva, minden más blokkolva.

3. A Steam-query-portot korlátozza, ne zárja be

Egy forráscímenkénti felső korlát elválasztja a valódi szerverlistákat a lekérdezési floodoktól. Egy szerverböngésző másodperces ütemben kérdezi Önt, egy támadó ezredmásodperces ütemben:

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

Az első szabály eldobja azokat a Steam-lekérdezéseket, amelyek tartósan tíznél többet tesznek ki másodpercenként ugyanabból a forrásból, a második a másodpercenként 600-nál több játékcsomagot. Mindkét szám kiindulási érték, nem igazság. Egy 60 játékossal tele szerver lényegesen több csomagot termel, mint egy üres, és aki túl szorosra állítja, az a saját játékosait dobja ki, vagy kirepül a szerverlistából. Először mérjen egy hetet normál üzemben.

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

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

UFW alatt az ilyen szabályok a /etc/ufw/before.rules fájlba tartoznak, mert különben a következő ufw reload parancsnál eltűnnek. Ezen felül a Steam szerverkönyvtára ismer egy saját féket a kapcsolat nélküli csomagokra: a STEAM_GAMESERVER_RATE_LIMIT_200MS környezeti változó eldobja egy cím összes A2S-csomagját, amint egy 200 ezredmásodperces ablakban a beállított értéknél több érkezik.

A harmadik pont semmibe nem kerül: ha a Discord-botja vagy a projektoldala mutatja a játékosok számát, ne a látogató felől kérdezze le a szervert, hanem fix időközönként tárolja el az eredményt. Ezzel egy sokat látogatott állapotoldal intervallumonként egy lekérdezést okoz, nem látogatónként egyet.

4. Vegye ki a BattlEye-RCon-t a nyílt hálózatból

A BattlEye a DayZ csalásellenes komponense, és a serverDZ.cfg fájlban a BattlEye = 1; sorral kapcsolható be. A távoli adminisztráció ezzel szemben külön fájlban van, a BEServer_x64.cfg fájlban, a BattlEye könyvtárban a BEServer_x64.dll mellett, amelyet az indítósor a -BEpath= paraméterrel állít be:

RConPassword EgyHosszuVeletlenJelszo
RConPort 2310
RestrictRCon 0

Három szabály tartozik ehhez. Először: az RCon-port UDP, nem TCP. Az a tűzfalszabály, amely véletlenül proto tcp értéket mond, semmit nem szűr, és egyúttal üresbe futtatja az adminisztrációs eszközöket. Másodszor: korlátozza a portot az adminisztrátorai címeire. Akinek nincs fix címe, az a portot kívülről teljesen zárva hagyja, és az adminisztrációs eszközt közvetlenül a szerveren indítja, SSH-n vagy távoli asztalon keresztül elérve. Harmadszor: a RestrictRCon 1 korlátozza az RCon-on keresztül futtatható parancsokat, és ez a helyes beállítás, amint egynél több személynek van hozzáférése.

Egy nyitott RCon-port két dolog egyszerre: meghívó a jelszavak végigpróbálására és egy további UDP-port, amelyet el lehet árasztani. Mindkettő megszűnik, amint az engedélyezés már csak néhány címre vonatkozik.

5. Bejelentkezési várólista, whitelist és slot-kimerítés

A DayZ nem dolgozza fel egyszerre az összes kapcsolódást, hanem várólistán keresztül. Öt érték vezérli ezt a serverDZ.cfg fájlban:

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

A loginQueueConcurrentPlayers határozza meg, hány játékost engednek be egyszerre (alapértelmezés 5), a loginQueueMaxPlayers magát a várólistát korlátozza (szokásos értékek 100 és 500 között). Pontosan itt kezdődik a slot-kimerítés: a támadónak nincs szüksége sávszélességre, csak elegendő fiókra vagy kapcsolódási kísérletre, hogy elfoglalja a várólistát. A valódi játékosok ilyenkor nem jutnak be, noha a szerver műszakilag kifogástalanul fut. A guaranteedSlots helyeket tart fenn a csapatának, hogy pontosan ebben a helyzetben Ön még fel tudjon jutni a szerverre.

Ez ellen segít a beépített whitelist. Az enableWhitelist = 1; sorral aktiválható, és ezután a profiles/whitelist.txt fájlt olvassa be, soronként egy Steam64-azonosítóval. Minden nem listázott azonosítót elutasít a rendszer a kapcsolódásnál. A fájlt a szerver indításakor olvassa be, a módosításokhoz tehát újraindítás kell. A serverDZ.cfg fájlban lévő további password hasonlóan hat, de gyengébb, mert egy jelszót továbbadnak, egy Steam64-azonosítót pedig nem.

Egy dolognak közben világosnak kell lennie: a whitelist a játékos-férőhelyeit védi, nem a vonalát. A támadó, aki elárasztja a szerverét, egyáltalán nem akar csatlakozni. A csomagjait elutasítják, de már megérkeztek, és pontosan ez a lényeg.

6. Modok, aláírás-ellenőrzés és az újraindítás utáni időablak

A DayZ-nél a modok nem csupán kényelmi kérdés, hanem a támadási felület részei. Négy beállítást a serverDZ.cfg fájlban mindenképpen be kell állítani:

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

A verifySignatures = 2 minden PBO-fájlt ellenőriz a hozzá tartozó .bisign aláírással szemben, és ehhez a megfelelő .bikey fájlokra van szüksége a keys mappában. A forceSameBuild = 1 pontosan ugyanazt a játékverziót követeli meg, mint ami a szerveren fut. Az allowFilePatching = 0 elutasítja azokat a klienseket, amelyek módosított játékfájlokkal indulnak. Egyik beállítás sem állít meg volumetrikus támadást, de mindhárom lezárja azt az utat, amelyen egy manipulált kliens kibillenti a szerverét.

A második pont a fontosabb, és szinte mindig figyelmen kívül marad: az indulási fázis. Egy DayZ-szerver induláskor először a modlistáját tölti be az indítósorból, utána pedig a központi ökonómiát az összes loot-táblázattal. Egy erősen modifikált szervernél ez könnyen több perc, amely alatt a szerver egyetlen Steam-lekérdezésre sem válaszol:

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

Mivel gyakorlatilag minden projekt három-négy óránként újraindul, és ezt a tervet ráadásul be is jelenti, az időablakot triviálisan könnyű eltalálni egy támadónak. Három ellenintézkedés hatásos, és semmibe nem kerül. Tartsa a modlistát a lehető legrövidebben, mert minden további mod pontosan ezt az ablakot hosszabbítja meg. Az újraindítási időpontokat kerek óra helyett tegye törtidőpontokra. És mérje meg egyszer, valójában mennyi ideig tart az indulás, ahelyett hogy becsülné: a timeStampFormat = "Full"; beállítással és egy megadott logFile értékkel az időtartam utána ott áll a naplóban.

7. Kapcsolatkövetés, fogadási pufferek és kernelparaméterek

Gyakran figyelmen kívül hagyott szűk keresztmetszet a kernel kapcsolatkövetése. Az UDP ugyan nem ismer kapcsolatokat, a kernel mégis bejegyzést hoz létre minden forrás- és célcímpárhoz. Ha a tábla megtelik, a szerver a legitim csomagokat is eldobja, a naplóban pedig ez áll: nf_conntrack: table full. Az állapotot és a felső korlátot ez mutatja:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Egy tisztán játékszerver esetében a tiszta megoldás az, hogy a játékforgalmat egyáltalán ne kövesse a rendszer, ezen felül pedig a hálózati kártya fogadási pufferét és várósorát meg kell növelni:

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

Figyelem: a NOTRACK és az állapottartó szabályok kizárják egymást. Aki a játékportot kiveszi a követésből, az ehhez a porthoz nem használhat több -m conntrack --ctstate szabályt, különben az engedélyezés már nem érvényesül. Tartósan a sysctl értékek a /etc/sysctl.d/ könyvtárba tartoznak, különben a következő újraindítás után eltűnnek.

8. Az IP-címe ott áll a szerverböngészőben

Itt az őszinteség többet ér a vágyálomnál: egy nyilvános DayZ-szerver IP-címét nem lehet titokban tartani. Ismeri minden játékos, aki egyszer már kapcsolódott, a szerverböngésző közzéteszi, a DZSA-launcher pedig eltárolja. Egy címcsere órákat nyer Önnek, ritkán napokat.

Két szokás hatásosabb. Sehol ne tegye közzé ezen felül a nyers IP-címet, tehát se a kitűzött Discord-bejegyzésben, se a projektoldalon. És tegyen rendet a DNS-rekordjai között: egy elfelejtett A-rekord a korábbi címre minden cserét hatástalanná tesz, és a legtöbb csere pontosan ezen bukik el. Aki a régi szerveren még futni hagy egy állapotszolgáltatást, az mindjárt az új címet is elárulja.

9. Naplózás, hogy a támadás közben ne kelljen találgatnia

A legfontosabb lépés az, amelyet előtte szinte senki nem tesz meg: összehasonlítási alapot kell felvenni, amíg minden normálisan fut. Normálérték nélkül egy incidens után nem tudja megmondani, hogy a másodpercenkénti 40 000 csomag sok volt-e, vagy egyszerűen csak szombat este. Szerveroldalon ehhez kapcsolja be a beépített naplókat:

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

A logAverageFps a legőszintébb érték, amelyet a DayZ szolgáltat. Ha a szerver képkockasebessége beszakad, miközben a játékosszám változatlan marad, az mod- vagy ökonómiaprobléma. Ha a képkockasebesség stabil marad, miközben a játékosok kirepülnek, akkor a hálózat az ok. Rendszeroldalon a mérések az apt-get install -y vnstat sysstat paranccsal folyamatosan futnak, egy incidens alatt pedig négy parancs elegendő:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 udp port 2302 -c 200 -q

A tcpdump esetében érvényes: mindig korlátozza a -c kapcsolóval, mert egy teljes terhelés alatt készült rögzítés az amúgy is túlterhelt szervert tovább terheli. Hogy az értékeket hogyan értékelje ki, azt a DDoS-támadás felismerése a szerveren cikk írja le.

Hol ér véget az önvédelem: sávszélesség és csomagszám

Most az a rész következik, amelyet semmilyen konfigurációs fájl nem old meg. Minden eddigi intézkedés az Ön szerverén fut, tehát a vonal végén. Egy tűzfalszabály olyan csomagról dönt, amely már végigment a kábelen. El tudja dobni, de nem tudja meg nem küldötté tenni.

A csomagszám a DayZ-nél gyakran hamarabb üt be, mint a sávszélesség, és ennek egyszerű oka van: a játékforgalom sok kis UDP-csomagból áll, nem kevés nagyból. Egy támadás, amely a vonalát még harmadáig sem tölti meg, ezért akkor is megbéníthatja a szerverét, mert a számítási idő az eldobásra megy el. Az üzemeltetők ezt így élik meg: „a kihasználtság nem is volt magas, mégis mindenkinek lagcsúcsai voltak, és sorban repültek ki”.

A volumetrikus támadásoknak a szerver előtti hálózatban kell véget érniük. Ez nem termékállítás, hanem fizika.

DayZ-DDoS-védelem: mit állít ez ellen a KernelHost

A folyamatos védelem, amely minden szerveren fut

A KernelHost DDoS-védelme kétrétegű felépítésű és tartósan aktív, anélkül hogy Önnek bármit be kellene kapcsolnia, meg kellene rendelnie vagy konfigurálnia:

• 1. réteg: 17 Tbps mitigációs kapacitás a globális scrubbing-hálózatban. A volumetrikus támadásokat a forrásuk közelében tisztítják ki, 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őbb egy támadásra reagálnia, tehát nincsenek percek az elején, amikor a szerver elérhetetlen. És nincs null-routing: 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 az Ön szempontjából ugyanazt az eredményt éri el, mint a támadó. Hogy mely játékok és protokollok vannak lefedve, azt a Játékszerver-DDoS-védelem valós időben cikk sorolja fel.

Advanced DDoS Protection a tartósan támadott projektekhez

Egyes projekteket nem alkalmanként, hanem célzottan és heteken át támadnak. Erre való az Advanced DDoS Protection havi 50,00 €-tól, PrePaid alapon és minimális futamidő nélkül. A különbség nem a nagyobb kapacitásban van, hanem az irányításban:

• 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 átépítésre.
• Önállóan kezelhető védelmi szabályok portonként és protokollonként az ügyfélportálon: külön állítja be, mi engedélyezett a 2302/UDP porton, mi a query-porton és mi az RCon-porton. Pontosan ez a szétválasztás a DayZ-nél az igazi emelő, mert a játékforgalom és a lekérdezési forgalom teljesen máshogy néz ki.
• 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 egy hibajegyre várna.
• A játékhoz illő védelmi profil, az erősen modifikált szerverekhez és a saját alkalmazásokhoz is, tetszőleges TCP- vagy UDP-portokon.

A két szint összehasonlítva

A legtöbb DayZ-projekthez elegendő a beépített folyamatos védelem egy tiszta szerverkonfigurációval együtt. Az Advanced DDoS Protection arra a válasz, hogy valaki személyes ügyet csinál belőle. Aki a DayZ-szerverét jelenleg máshol üzemelteti, az a védelmet nem tudja utólag beszerelni: az a hálózat része, és azokra a szerverekre érvényes, amelyek a KernelHostnál állnak. Az odavezető út a költözés, nem egy kiegészítő termék.

Gyakori hibák és megoldások

„A szerverem eltűnt a DZSA-launcherből és a szerverböngészőből, közvetlen csatlakozással viszont felmegyek rá”: ez az esetek többségében nem támadás, hanem a query-port. Vagy más érték áll a steamQueryPort beállításban, mint a tűzfalban, vagy egy túl szoros sebességkorlátozás dobja el a szerverlista lekérdezéseit. Vesse össze a két értéket, mielőtt támadást feltételezne.

„Az RCon nem kapcsolódik, amióta szűröm a portokat”: a BattlEye-RCon UDP-n keresztül megy. Egy proto tcp engedélyezés ugyanarra a portra semmit nem ér el. Ezenkívül ellenőrizze, nem áll-e a RConPort és a steamQueryPort véletlenül ugyanazon az értéken.

„Lecseréltem az IP-címet, és két órával később megint offline voltam”: a támadó ugyanabból a forrásból szerezte meg az új címet, mint a régit, többnyire a szerverböngészőből, egy állapotjelző Discord-botból vagy egy régi DNS-rekordból. A címcsere időnyereség, nem megoldás.

„A támadás minden nap pontosan az újraindításkor érkezik”: ez nem véletlen. Az újraindítási terv ott áll a Discordon, és a játékban be is jelentik, a modok és az ökonómia betöltése közben pedig a szerver amúgy sem válaszol. A rövidebb modlista, a törtidőpontos újraindítás és az a szűrés, amely folyamatosan fut ahelyett, hogy csak egy támadásra reagálna, elveszi ennek a mintának a hatását.

„Minden játékosnak lagcsúcsai vannak, a hálózat viszont nyugodt”: akkor nem DDoS-támadás volt. Először a logAverageFps értékben nézze meg, beszakadt-e a szerver képkockasebessége, utána pedig a központi ökonómiában és a modlistában. Ha a sar -n DEV 1 10 feltűnésmentes marad, akkor nem a hálózat az ok.

„Az iptables-szabályaim nem fognak”: három ok gyakori. A szabályok az UFW-láncok mögött állnak, és soha nem éri el őket a forgalom, a legutóbbi újraindítás után eltűntek (ilyenkor 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 vonalon, amely már 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ályt nem éri el a forgalom.

„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, Önnek viszont az eredmény azonos egy sikeres támadással, többnyire még órákkal utána is. Kétség esetén kérdezzen rá, hogy szűrés vagy null-routing történik. A válasz többet dönt a rendelkezésre állásáról, mint bármilyen hardveres adat.

„A tcpdump kimenetében 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 nem érkezik semmi. Működő szűrésnél ez a normális eset. Fordítva is igaz: ha a vonal 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ál VNC-konzolját, amely a vendégrendszer hálózatától függetlenül működik.

Röviden összefoglalva

• Egy DayZ-szervernek kifelé pontosan két dologra van szüksége: a 2302/UDP porttól induló játékportblokkra és a steamQueryPort sorában szereplő Steam-query-portra. Minden más korlátozásra vagy zárásra való.
• A BattlEye-RCon-portnak nincs kötelező alapértéke, UDP-n keresztül megy, és a BEServer_x64.cfg fájlban a RConPort értékkel állítható be. Soha nem való a nyílt hálózatba, és soha nem állhat ugyanazon az értéken, mint a query-port.
• A query-portot korlátozni kell, nem bezárni: aki bezárja, eltűnik a szerverböngészőből és a DZSA-launcherből, noha a közvetlen csatlakozás továbbra is működik.
• A whitelist, a guaranteedSlots és a bejelentkezési várólista a játékos-férőhelyeit védi a slot-kimerítés ellen, de nem a vonalát a sávszélesség ellen.
• Egy DayZ-szerver legveszélyesebb időablaka a három-négy óránkénti tervezett újraindítás, mert a modok és a központi ökonómia percekig töltenek, az időpont pedig nyilvánosan ismert.
• Körülbelül 1 Gbit/s támadási volumentől vagy néhány százezer csomagtól másodpercenként kizárólag a szerver előtti hálózat dönt, nem a tűzfala.
• A KernelHostnál a kétrétegű folyamatos védelem minden szervercsomagban benne van, felár nélkül és null-routing nélkül. Az Advanced DDoS Protection havi 50,00 €-tól akkor jön ehhez hozzá, ha a portonkénti szabályokat saját maga szeretné irányítani.

Ha a projektje 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 támogatási hibajegyet, hogy a szűrőszabályokat az IP-címéhez igazítsák. Futó támadás esetén ezen felül a WhatsApp-vészhelyzeti chaten ér el minket a +43 650 8209883 számon.