Project Zomboid szerver védelme DDoS-támadások ellen

Aki a Project Zomboid szerverét DDoS-támadások ellen akarja megvédeni, annak először azt kell tudnia, mire lő egyáltalán egy támadó. Egy dedikált szerver pontosan két UDP-portot foglal el, a 16261-est és a 16262-est, és mindkettőnek nyitva kell lennie a hálózaton, mert különben senki nem tud belépni. Ez a cikk abban a sorrendben haladva mutatja be a lépéseket, amely éles helyzetben számít: először azt, amit a következő tíz percben többletköltség nélkül maga tud megtenni, utána azt a helyet, ahol ezek az intézkedések technikailag véget érnek, végül azt, aminek előtte a hálózatban kell történnie.

Minden adat a dedikált szerverre vonatkozik (Steam-alkalmazás 380870) Debian 12, Debian 13, Ubuntu 22.04 LTS vagy Ubuntu 24.04 LTS alatt, a 41-es és a 42-es buildre egyaránt. A konfigurációs fájl neve servertest.ini, és a ~/Zomboid/Server/ útvonalon található, a világadatok a ~/Zomboid/Saves/Multiplayer/ útvonalon vannak. A 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 zajlik: most ne módosítson semmit a servertest.ini fájlban, és ne indítsa újra a szervert. Először mentse el a mérési értékeket (9. pont), mert a támadás után már nem lesznek meg. Az újraindítás ezen felül annyi időbe kerül, amennyi a szervernek a világ betöltéséhez kell, és pontosan ezt akarja elvenni Öntől a támadó.

Miért lesznek a Project Zomboid szerverek DDoS-támadások célpontjai

A Project Zomboid végleges halállal dolgozó játék, amelyben a világ hónapokon át fut tovább. Egy kapcsolatszakadás egy veszélyes helyzet közepén itt többe kerül, mint szinte bármely más műfajban: a karakter elveszik, és a világ emlékszik rá. Pontosan ez teszi a kiesést fegyverré. Egy este nyolckor indított támadás egy állandó közösséget ér, méghozzá ott, ahol a legtöbbet veszítheti.

Ehhez jön, hogy maga a támadás semmibe nem kerül, és nem kíván tudást. A megvásárolt támadási szolgáltatások, amelyeket a szcénában booternek vagy stressernek neveznek, néhány kattintással egy IP-címre és egy portra irányulnak, a Project Zomboid esetében pedig a cél mindig ugyanaz: 16261 UDP. Aki vitában áll egy kitiltott játékossal, vagy konkurens közösséget üzemeltet, olyan eszközt tart a kezében, amelyhez sem tudásra, sem említésre méltó pénzre nincs szüksége.

Ehhez jön, hogy egy játékszervernek közzé kell tennie a címét. Ha a servertest.ini fájlban a Public=true érték áll, a szerver megjelenik a játék böngészőjében, egy Steam-kapcsolattal működő szerver pedig amúgy is látható a Steam szerverböngészőjében. A kérdés tehát soha nem az, hogy egy támadó megtalálja-e az IP-címét, hanem csak az, hogy mi történik, ha rálő.

Technikailag a legkellemetlenebb rész a végére marad: a teljes játékforgalom UDP-n keresztül megy. Az UDP nem ismer olyan kapcsolatfelépítést, amelyet meg lehetne követelni, minden csomag önmagában áll, és a feladócím hamisítható. Egy támadónak tehát sem belépnie nem kell az Ön szerverére, sem helyesen megszólítania azt ahhoz, hogy terhelést hozzon létre. Hogy részleteiben mi is egy DDoS-támadás, azt a Mi az a DDoS-támadás? című cikk magyarázza el.

Mely portokra van valóban szüksége egy Project Zomboid szervernek

Egy dedikált Project Zomboid szervernek pontosan két nyitott portra van szüksége: 16261 UDP és 16262 UDP. A játék hivatalos portlistája harmadikat nem nevez meg. A servertest.ini fájlban két külön direktívaként szerepelnek, a második port nem adódik automatikusan az elsőből:

DefaultPort=16261
UDPPort=16262
SteamPort1=8766
SteamPort2=8767
RCONPort=27015
RCONPassword=

A munkamegosztás egyértelmű. A 16261 UDP viszi a játékforgalmat és a kapcsolatfelépítést, és megválaszolja a szerverböngésző lekérdezéseit. A 16262 UDP a kliensek közvetlen kapcsolatának portja. Ha az első hiányzik, senki nem találja meg a szervert, ha a második hiányzik, a játékosai látják a bejegyzést, és mégsem jutnak be. Pontosan innen származik a játék legismertebb hibaüzenete, amely szerint a 16262-es port zárva van.

Két pont, amely rendszeresen bajt okoz. Először: minden szerverpéldánynak két szabad UDP-portra van szüksége. Aki második világot üzemeltet ugyanazon a gépen, annak második párt kell kiosztania, például a 16274-est és a 16275-öset, és mindkét értéket be kell írnia a második példány servertest.ini fájljába. Másodszor: a SteamPort1 és a SteamPort2 a 8766 és 8767 értékkel szerepel a konfigurációs fájlban, de a Steam-kapcsolathoz tartozik és nem a játékforgalomhoz. Csak akkor nyissa meg őket, ha a szervere nélkülük nem jelenik meg a Steam-listában, ne elővigyázatosságból.

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 szerver saját erőből kibírja a kis és közepes támadásokat, függetlenül attól, hogy hol áll. Egy volumetrikus támadást nem vesz le a válláról, de gondoskodik arról, hogy a filléres támadások hatástalanok maradjanak, és hogy éles helyzetben számai legyenek, ne feltevései.

1. Leltár: mi figyel valójában

Mielőtt egyetlen szabályt is megírna, nézze meg, mit kínál a szervere kifelé. Ne tippeljen, nézzen utána:

ss -lntup

A helyi címet tartalmazó oszlop az érdekes. A 0.0.0.0:16261 és a [::]:16261 azt jelenti, hogy „az egész internetről elérhető”, a 127.0.0.1:27015 pedig azt, hogy „csak helyben”, és nem kell hozzá engedélyezés. Vesse össze az eredményt a saját konfigurációjával, ahelyett hogy az alapértékekre hagyatkozna:

grep -E "^(DefaultPort|UDPPort|SteamPort1|SteamPort2|RCONPort|Public|Open|MaxPlayers|MaxAccountsPerUser)=" ~/Zomboid/Server/servertest.ini

A támadó nézőpontját egy kívülről indított portszkennelés adja meg. Mivel a Project Zomboid kizárólag UDP-t használ, ehhez UDP-szkennelés kell, egy tisztán TCP-alapú szkennelés a játékportot egyáltalán nem mutatja:

nmap -Pn -sU -p 16261,16262,8766,8767 A.SZERVERE.IP.CÍME
nmap -Pn -p- --min-rate 1000 A.SZERVERE.IP.CÍME

2. Csak a 16261-es és a 16262-es portot hagyja nyitva

Két kifelé irányuló engedélyezés elegendő, minden más korlátozásra kerül, vagy egyáltalán nem kerül közzétételre. UFW-vel ez így néz ki, méghozzá pontosan ebben a sorrendben, hogy ne zárja ki saját magát:

ufw allow 22/tcp comment "SSH"
ufw allow 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid közvetlen kapcsolat"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

A 203.0.113.10 helyére írja a saját címét. Az élesítés sorrendje dönti el, hogy kizárja-e saját magát. Ez a visszaúttal együtt az UFW-tűzfal beállítása anélkül, hogy kizárná magát című cikkben olvasható. Ha mégis megtörténik: a KernelHost KVM root-szerverein és dedikált szerverein az ügyfélportálon elérhető VNC-konzolon keresztül jut be a rendszerbe, amely a vendégrendszer hálózatától függetlenül működik.

Egy szó az adatbázisokról és a kiegészítő szolgáltatásokról: a Project Zomboidnak nincs rájuk szüksége. Ami a játék mellett a 0.0.0.0 címen figyel, az egy korábbi telepítésből vagy egy kezelőpanelből származik, és vagy a 127.0.0.1 címhez kell kötni, vagy le kell állítani.

3. Az RCON kivétele az internetről a 27015-ös porton

Az RCON a szerver távvezérlése, és a Project Zomboid esetében a 27015 TCP porton fut. A szállított servertest.ini fájlban a RCONPassword= érték nélkül szerepel. Aki használja az RCON-t, az hosszú véletlen jelszót állít be, mert a protokoll titkosítatlanul továbbít, és egy gyenge jelszóval elérhető RCON-port teljesen átadja a szervert, anélkül hogy ehhez egyetlen csomag támadási forgalom is kellene.

A biztonságos út az, ha a portot egyáltalán nem nyitja meg kifelé, és SSH-porttovábbításon keresztül éri el. Ezután helyben a 127.0.0.1:27015 címmel beszél:

ssh -N -L 27015:127.0.0.1:27015 root@A.SZERVERE.IP.CÍME

Akinek nincs szüksége az RCON-ra, az üresen hagyja a jelszó mezőt és zárva a portot. Egy szolgáltatást, amely nem elérhető, sem végigpróbálni, sem elárasztani nem lehet.

4. A csomagsebesség korlátozása forráscímenként

A kis támadások és a rosszul megírt botok ellen egy forráscímenkénti felső korlát segít. Mivel a két játékport egymás mellett van, egy tartományra szóló szabály elegendő:

iptables -I INPUT -p udp --dport 16261:16262 -m hashlimit --hashlimit-name pz_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP
iptables -L INPUT -n -v

A szabály eldobja az UDP-csomagokat, amint ugyanaz a forráscím tartósan másodpercenként 400 csomagnál többet küld. Az érték kiindulási érték és nem igazság: egy szerver 30 játékossal ugyanabban a városban lényegesen több forgalmat hoz létre, mint egy négy játékossal a térkép különböző sarkaiban, és aki túl szűken állít be, az a saját játékosait dobja ki. Mérjen először egy hétig normál üzemben, azután tegye a határt a csúcsérték többszörösére.

Két megjegyzés ehhez. A tisztán iptables-alapú szabályok újraindítás után eltűnnek, Debian és Ubuntu alatt így mentjük el őket:

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

UFW alatt pedig az ilyen szabályok az /etc/ufw/before.rules fájlba valók, mert különben a következő ufw reload parancsnál eltűnnek. Ellenőrizze az iptables -L INPUT -n -v parancs találati számlálóival, hogy a szabályt egyáltalán eléri-e a forgalom. Ha a számlálók nullán maradnak, a szabály rossz helyen áll.

5. A kapcsolatkövetés tehermentesítése

Egy gyakran elnézett szűk keresztmetszet a kernelben ül. A kapcsolatkövetés UDP esetén is bejegyzést hoz létre forráscímenként és portonként, és egy hamisított feladókkal dolgozó flood másodpercek alatt megtölti ezt a táblát. Ha a tábla megtelik, a szerver a jogos csomagokat is eldobja, a naplóban pedig az áll, hogy „nf_conntrack: table full”. Az aktuális állást és a felső határt ez mutatja meg:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

A Project Zomboid játékforgalmának nincs szüksége állapotkövetésre, mert az UDP-nek nincs állapota. A két játékportot ezért kiveheti a táblából:

iptables -t raw -I PREROUTING -p udp --dport 16261:16262 -j NOTRACK

Ez érzékelhetően tehermentesíti a kernelt. Fontos: a szabály csak addig illik, amíg a szerver közvetlenül kapja a csomagokat. Aki előtte címfordítást üzemeltet, például porttovábbítással működő konténeres felépítésben, annak nem szabad beállítania, mert a visszaút ilyenkor már nem rendelhető hozzá.

6. A belépés és a férőhelyek bebiztosítása

A következő sorok semmibe nem kerülnek, és minden ellen hatnak, ami a szabályos belépési úton jön:

Password=EGY-HOSSZÚ-VÉLETLEN-JELSZÓ
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

A Password a közös szerverjelszó, és el van választva az egyes játékosok fiókjától. Az Open=false azt jelenti, hogy csak olyan fiókok léphetnek be, amelyeket egy rendszergazda előzőleg létrehozott, ez a játék engedélyezőlistája. A MaxAccountsPerUser azt korlátozza, hány fiókot hozhat létre egyetlen Steam-felhasználó az Ön szerverén, a 0-as alapérték korlátlant jelent. A MaxPlayers gyárilag 32-n áll, és ezen felül a dokumentáció kifejezetten figyelmeztet a térkép hibás utántöltésére és a deszinkronizációra.

A PingLimit ezen a ponton a csapda. A direktíva egy milliszekundumban megadott késleltetés fölött kidobja a játékosokat, és gyárilag 0-n áll, tehát ki van kapcsolva. Egy támadás alatt először a saját játékosainak késleltetése emelkedik, egy szűk érték tehát pontosan azokat rúgja ki, akiket meg akar tartani. Hagyja kikapcsolva a határt, vagy állítsa be bőkezűen.

És egy dolognak világosnak kell lennie: az engedélyezőlista a játéklogikáját védi, nem a vonalát. Az a támadó, aki elárasztja a szerverét, egyáltalán nem akar belépni. A csomagjait a szerver visszautasítja, de attól még megérkeztek, és pontosan ez a lényeg.

7. A modok egyeztetése a kapcsolódásnál az Ön szerverének legdrágább másodperce

A Project Zomboid a kapcsolódásnál többet ellenőriz egy jelszónál. A szerver modlistája a servertest.ini fájl két sorában áll: a WorkshopItems a numerikus Workshop-azonosítókat tartalmazza, a Mods a modok betöltési azonosítóit, mindkettő pontosvesszővel elválasztva. Belépéskor a kliens egyezteti ezt a listát, a hiányzó Workshop-tartalmakat automatikusan letölti a Steamen keresztül, és csak utána kapja meg folyamként a világadatokat. Ezen felül a szerver DoLuaChecksum=true beállítás mellett összehasonlítja a játékfájlok ellenőrzőösszegeit, és kidobja azokat a klienseket, amelyek fájljai nem illenek az övéihez.

Egy támadó számára pontosan ez érdekes, mert a munka a tényleges játékrészvétel előtt keletkezik. Minden kapcsolódási kísérlet számítási időbe kerül a szervernek a verzió, az ellenőrzőösszeg, a modlista és a térképadatok miatt, az a kísérlet is, amelyet a végén visszautasít. Egy hosszú modlista minden ilyen kísérletet drágábbá tesz. Egy belépési áradat ezért egy erősen módosított szerveren hatékonyabb, mint egy változatlanon, és ehhez egy volumetrikus támadás sávszélességének töredéke kell. A játék ezzel szemben két beépített féket hoz magával:

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

A DenyLoginOnOverloadedServer visszautasítja az új bejelentkezéseket, amíg a szerver túlterhelt, ahelyett hogy a futó menetet is magával szakítaná. A LoginQueueEnabled várólistára teszi a belépőket, ahelyett hogy egyszerre dolgozná fel őket, a LoginQueueConnectTimeout pedig megadja, meddig tarthat egy belépés, az alapérték 60 másodperc, a megengedett tartomány 20 és 1200 között van.

Egy részlet ide tartozik, mert gyakran rosszul oldják meg: Linux-szervereken létezik egy dokumentált hiba, amelynél a DoLuaChecksum hamis riasztást ad, és nem engedi be a játékosokat. Az üzemeltetők ezért kikapcsolják az ellenőrzést. Ez érthető, de elvesz egy olyan kontrollt, amely távol tartja a módosított játékfájlokkal rendelkező klienseket. Akinek ki kell kapcsolnia, az annál szigorúbban állítsa be a szerverjelszót, az engedélyezőlistát és a fiókkorlátot.

8. Szerverlista, UPnP és a saját cím

Itt az őszinteség többet ér a vágyálmoknál: az IP-címét nem lehet titokban tartani. A Public=true megjeleníti a szervert a játék böngészőjében, egy Steam-kapcsolattal működő szerver pedig a dokumentáció szerint amúgy is látható a Steam szerverböngészőjében. A Public=false tehát elveszi az új játékosok felé való láthatóságot, anélkül hogy láthatatlanná tenné Önt.

Public=true
PublicName=A Zomboid-szerverem
UPnP=false
server_browser_announced_ip=

Az UPnP gyárilag true értéken áll, és megengedi a szervernek, hogy egy internetes átjárón maga állítson be portengedélyezést. Egy bérelt szerveren nincs ilyen átjáró, a kísérlet üresbe fut, és le kell kapcsolni. A server_browser_announced_ip üresen marad, kivéve ha a szerverének több címe van, és célzottan egy adott cím alatt kell megjelennie. Pontosan ez a mező kell majd később ismét, ha dedikált védett IP-re áll át.

Két szokás többet segít bármilyen beállításnál. A nyers IP-címet sehol ne tegye közzé maga, tehát se a Discord-csatornán, se a projektoldalon, és adjon a játékosainak hosztnevet. A címcsere klasszikus hibája a régi DNS-bejegyzés: egy elfelejtett, a korábbi címre mutató A-bejegyzés minden cserét hatástalanná tesz.

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

A legfontosabb lépés az, amelyet szinte senki nem tesz meg előre: egy összehasonlítási alap létrehozása, amíg minden nyugodt. 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 szombat este. Az apt-get install -y vnstat sysstat paranccsal a mérés tartósan együtt fut. Egy incidens alatt négy parancs elegendő:

sar -n DEV 1 10
ip -s link show eth0
tcpdump -ni eth0 "udp port 16261 or udp port 16262" -c 200 -q
journalctl -u zomboid --since "-15 min" | tail -50

Az első kettő az interfész csomagsebességét és eldobási számlálóit mutatja, a harmadik a forgalom rövid mintáját, a negyedik a szerver üzeneteit, feltéve hogy systemd-szolgáltatásként fut (a szolgáltatás nevét igazítsa hozzá). A tcpdump parancsnál érvényes: mindig korlátozza a -c kapcsolóval, mert egy teljes terhelés alatt készült felvétel tovább terheli az amúgy is túlterhelt szervert. Hogy az értékeket hogyan értelmezze, arról a DDoS-támadás felismerése a szerveren című cikk szól.

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

Most jön az a rész, amelyet egyetlen konfigurációs fájl sem 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 meg nem küldötté nem tudja tenni.

Számoljon egyszer velünk. Egy tipikus játékszerver 1 Gbit/s sebességen lóg, ez másodpercenként 125 megabájt, és a vonal megtelik, amint valaki többet küld. A második mennyiség a csomagsebesség, és ez gyakran hamarabb üt be, mint a sávszélesség: 64 bájtos kis csomagokból 1 Gbit/s sebességbe nagyjából másodpercenként 1,49 millió fér bele, miközben egy normál szerverkernel processzortól és hálózati kártyától függően csak néhány százezret dolgoz fel ebből, mielőtt eldobni kezdene. Egy támadás, amely a vonalát még harmadáig sem tölti meg, tehát megbéníthatja a szerverét. Az üzemeltetők ezt úgy élik meg, hogy „a kihasználtság nem is volt magas, mégis minden eltűnt”.

A játékszerver-közösségek elleni szokásos támadások 5 és 50 Gbit/s között vannak, tehát egy normál vonal ötszöröse és ötvenszerese között. 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 szembe a KernelHost a játékszerverek elleni DDoS-támadásokkal

A folyamatos védelem, amely minden szervercsomagban benne van

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, 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ásuk közelében tisztítjuk 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 ismerjük fel és dobjuk 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 null-routingot nem alkalmazunk: az Ön IP-címe a hálózaton marad, csak a káros csomagokat dobjuk el. Aki kiveszi az IP-címet a hálózatból, 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ékszerverek DDoS-védelme valós időben című cikk sorolja fel.

Advanced DDoS Protection a tartósan támadott projekteknek

Egyes projekteket nem alkalmanként, hanem célzottan és heteken át támadnak. 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 van, hanem az irányításban:

• Dedikált védett IP a frankfurti magból, amelyre a szerverét a saját hálózatunkban átállítjuk. Az Ön oldalán nincs szükség átalakításra, az új címet mindössze ott kell beírnia, ahol a játékosai megtalálják a szervert.
• Önállóan kezelhető védelmi szabályok portonként és protokollonként az ügyfélportálon: Ön határozza meg, mi engedélyezett a 16261 és a 16262 UDP porton, minden más zárva marad, anélkül hogy ehhez ticketet kellene írnia.
• A módosítások valós időben lépnek érvénybe, tehát egy zajló támadás közben is tud utánaállítani.
• Illeszkedő védelmi profil. A bevett játékokhoz készen állnak profilok, a módosított és a saját alkalmazásokhoz a szabályokat portonként és protokollonként maga állítja be. A Project Zomboid ennél különösen pontosan körülhatárolható, mert a teljes játékforgalom két egymás melletti UDP-porton fut.

A két védelmi szint összehasonlítása

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

Gyakori hibák és megoldások

„A játékosaim azt az üzenetet kapják, hogy a 16262-es port zárva van”: ez nem támadás, hanem hiányzó engedélyezés. A szervernek mindkét portra szüksége van, a 16261 UDP-re és a 16262 UDP-re, méghozzá UDP-szabályként. Egy TCP-engedélyezés ugyanazokon a számokon semmit nem ér. Ellenőrizze az ufw status verbose paranccsal és egy kívülről indított UDP-szkenneléssel, hogy valóban mindkettő nyitva van-e.

„Lecseréltem az IP-címet, és két órával később ismét offline voltam”: a támadó ugyanabból a forrásból szerezte meg az új címet, mint a régit, többnyire a listabejegyzésből, egy állapotjelzős Discord-botból vagy egy régi DNS-bejegyzésből. A Project Zomboid esetében a csere ezen felül költséggel jár: a kliensek a térképadatokat helyben, cím és port alatt tárolják, a Zomboid/Saves mappában egy 123.45.0.12_16261_... minta szerinti mappában. Egy csere után minden játékos újra letölti a felfedezett térképet a szerverről. Egy címcsere tehát időnyereség többletköltséggel, nem megoldás.

„Az iptables-szabályaim nem hatnak”: három ok gyakori. A szabályok az UFW-láncok mögött állnak, és soha nem érik el őket; a legutóbbi újraindítás után eltűntek (ilyenkor a netfilter-persistent save vagy egy bejegyzés az /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 megtelt. Ellenőrizze az iptables -L INPUT -n -v paranccsal, hogy emelkednek-e a találati számlálók.

„A játékosok belépéskor kirepülnek, a szerver viszont normálisan fut tovább”: ez majdnem mindig az egyeztetés és nem támadás. Az okok között verziókülönbség van a kliens és a szerver között, hiányzó vagy elavult Workshop-bejegyzés, vagy nem illeszkedő ellenőrzőösszeg. A kliens általában megnevezi azokat a modokat, amelyek nem egyeznek. Vesse össze a WorkshopItems és a Mods értékét sorról sorra.

„Néhány percenként lag-tüskék, azután megint megy”: ez a rövid támadások szokásos mintája, amelyek csak addig futnak, amíg a játékosok idegességükben abbahagyják. Először a hálózati számlálókat nézze meg, ne a processzorterhelést. Ha a sar -n DEV 1 10 kimenete és az eldobási számlálók feltűnésmentesek maradnak, akkor nem támadásról volt szó, hanem terhelésről: túl sok játékos ugyanabban a cellában, egy drága mod, vagy túl kevés memória a Java-példány számára.

„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ással, többnyire még órákkal azután is. Kétség esetén kérdezzen rá, hogy szűrés történik-e vagy null-routing. A válasz többet dönt el az elérhetőségéről, mint bármilyen hardveradat.

„A tcpdumpban nem látok semmi feltűnőt”: ha a forgalmat már az előtte lévő hálózatban kiszűrjük, akkor a szerverre a várakozásnak megfelelően nem érkezik semmi. Ez a normális eset működő szűrés mellett. Fordítva viszont igaz: ha a vonal telített, adott esetben még az az SSH-munkamenet sem ér el Önhöz, amellyel mérni szeretne. Használja ilyenkor az ügyfélportálon elérhető VNC-konzolt.

Röviden összefoglalva

• Egy dedikált Project Zomboid szervernek pontosan két nyitott portra van szüksége: 16261 UDP (DefaultPort) és 16262 UDP (UDPPort). Mindkettő külön direktívaként szerepel a servertest.ini fájlban.
• Az RCON a 27015 TCP porton fut, és gyárilag jelszó nélkül van beírva. A port nem való a nyílt internetre, hanem a saját címre korlátozva vagy zárva.
• A modok egyeztetése a kapcsolódásnál a legdrágább hely: a verzió, az ellenőrzőösszeg, a Workshop-lista és a térképadatok számítási időbe kerülnek, minden visszautasított kísérlet esetén is. A DenyLoginOnOverloadedServer és a belépési várólista ezzel szemben a beépített fékek.
• A szerverjelszó, az Open=false és a MaxAccountsPerUser=1 a játéklogikát védi. Egy telített vonal ellen ezek közül egyik beállítás sem hat.
• A fizikai határ fix: 1 Gbit/s másodpercenként 125 megabájt, és 64 bájtos csomagok esetén nagyjából másodpercenként 1,49 millió csomag. A játékszerverek elleni szokásos támadások 5 és 50 Gbit/s között vannak.
• A volumetrikus támadásoknak a szerver előtti hálózatban kell véget érniük. A KernelHostnál ez 17 Tbps mitigációs kapacitás a globális scrubbing-hálózatban és Arbor valós idejű szűrés 3,2 Tbps kapacitással Frankfurt am Mainban, felár nélkül és null-routing nélkül.
• Akit tartósan lőnek, az maga irányítja a szűrést az Advanced DDoS Protection szolgáltatással: dedikált védett IP, szabályok portonként és protokollonként, a módosítások valós időben, havi 50,00 EUR-tól.

Ha a 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 a szűrési szabályokat az Ön IP-címéhez igazítsuk. Zajló támadás esetén ezen felül a WhatsApp-vészhelyzeti chaten ér el minket a +43 650 8209883 számon.