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

Annak az Unturned-szervernek, amely este néhány percre eltűnik a szerverlistából, és közben minden játékost időtúllépéssel kidob, ritkán van hardveres problémája. Többnyire támadás fut, méghozzá pontosan akkor, amikor a legnagyobb a forgalom. 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 ezek az intézkedések műszakilag, végül azt, minek kell utána a szerver előtti hálózatban történnie.

Minden adat az Unturned Dedicated Serverre vonatkozik (U3DS, SteamCMD app-azonosító 1110390) Debian 12, Debian 13, Ubuntu 22.04 LTS vagy Ubuntu 24.04 LTS alatt. A parancsok root felhasználóra vannak írva, normál felhasználóként tegye eléjük a sudo parancsot. Ha a támadás éppen fut, először ne változtasson semmit a konfiguráción, és ne indítsa újra a szervert: mentse el a mérési értékeket (10. szakasz), a támadás után már nem lesznek meg.

Miért éppen az Unturned-szervereket támadják

Az Unturned-szervereket azért támadják, mert a címük nyilvános, a játékforgalom UDP-n fut, és egy támadás a kiváltójának sem tudást, sem érdemi pénzt nem kerül. Mindhárom pont erősebben érvényes itt, mint a legtöbb más játék esetében.

Egy nyilvános Unturned-szerver saját magától teszi közzé az IP-címét. Meg is kell tennie, különben senki nem találná meg: a Steam-szerverböngésző közvetlenül kérdezi le, a harmadik felek listái pedig, mint az unturned-servers.net vagy a BattleMetrics, nyílt szövegben tüntetik fel az IP-címet és a portot. Az unturned-servers.net saját közlése szerint ehhez ötpercenként megvizsgálja, hogy a szerver fogad-e UDP-kapcsolatokat a szerverporton. A támadónak ez nem ráfordítás, hanem egy űrlap.

Ehhez jön a játékosbázis. Az Unturned ingyenes, a belépési küszöb nulla, a roleplay- és a survival-projektek között pedig valódi verseny van ugyanazokért a játékosokért. Egy kitiltott játékosnak, egy megbántott ex-adminnak vagy egy szomszédos projektnek nincs szüksége hozzáférésre a szerveréhez ahhoz, hogy egy órára használhatatlanná tegye. Hogy egy DDoS-támadás műszakilag mi, és miért olyan nehezen visszakövethető a hamisított feladócímek miatt, azt a Mi az a DDoS-támadás? cikk írja le.

A portok, amelyekről valójában szó van

Egy Unturned-szerver pontosan két egymást követő UDP-portot foglal el: a Commands.dat fájlban beállított értéket és ezt az értéket plusz egyet. Alapértelmezés szerint ez a 27015 és a 27016. A Smartly Dressed Games hivatalos dokumentációja így írja le a felosztást: az első port viszi a szerverlista lekérdezéseit, a második a játékforgalmat. Csak az elsőt kell beállítani, a második automatikusan adódik.

Name Az én Unturned szerverem
Port 27015
MaxPlayers 24
Map PEI
Mode Normal
Perspective Both
Owner 76561198000000000

A Commands.dat a U3DS/Servers/<példány>/Server/Commands.dat útvonalon található. A formátuma egyedi és gyakori hibaforrás: egy parancs soronként, egyenlőségjel nélkül, az értéket egy szóköz választja el, és a parancsok érzékenyek a kis- és nagybetűkre. A // jellel kezdődő sorok megjegyzések.

A tűzfal szempontjából a legfontosabb pont így hangzik: a 27017-es portra a 2021. november 21-én kiadott 3.21.30.0 verzió óta nincs többé szükség. Azelőtt egy Unturned-szerver három portot igényelt, mert a Steam-lekérdezés a port plusz kettőn ült. Ezzel a frissítéssel a lekérdezés magával a szerverrel osztozik a porton, és a harmadik port megszűnt. A router-útmutatók, a szolgáltatói wikik és a fórumbejegyzések ennek ellenére máig a 27017-et említik. Egy nyitott 27017 már semmilyen előnyt nem jelent Önnek, csupán támadási felület.

Szintén fontos: az Unturnednek nincs beépített RCON-portja. A hivatalos dokumentáció csak konzolbemenetet és konzolkimenetet ismer, amelyek az ICommandInputOutput felületen keresztül lecserélhetők. Minden távvezérlés, amelyet egy Unturned-szerveren lát, egy bővítményből származik, és saját TCP-portot hoz magával. Ezt a portot Önnek magának kell megtalálnia és magának kell korlátoznia, mert senki nem biztosította be Ön 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 Unturned-szerver a kis és közepes támadásokat saját erőből kibírja, függetlenül attól, hol áll.

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

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

ss -lnup
ss -lntp

Az első parancs a figyelő UDP-socketeket mutatja, a második a TCP-socketeket. Az érdekes oszlop a helyi cím. A 0.0.0.0:27015 és a [::]:27015 azt jelenti, hogy „az egész internetről elérhető”, a 127.0.0.1:3306 azt, hogy „csak helyben”, és nem igényel tűzfalszabályt. A játék mellett gyakran ott van egy RCON-bővítmény, egy webpanel, egy adatbázis és egy régi tesztszerver a 27017-en, amelyet már senki nem használ. A támadó nézőpontját egy kívülről indított portszkennelés adja, az Unturned esetében kifejezetten UDP-re is:

nmap -Pn -sU -p 27000-27050 A.SZERVERE.IP.CÍME
nmap -Pn -p- --min-rate 1000 A.SZERVERE.IP.CÍME

2. Csak a 27015-öt és a 27016-ot hagyja nyitva

Az Unturnedhez két kifelé irányuló UDP-engedélyezés elegendő. Magához a játékhoz egyetlen TCP-portra sincs szükség: a hivatalos dokumentáció mindkét portra kifejezetten UDP-t követel meg, a játék hálózati rétege (Steam Networking Sockets, egy frissítés óta az alapértelmezés) pedig kizárólag UDP-n dolgozik. Aki ezen felül TCP-t is engedélyez, elavult útmutatót követ.

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Unturned lekérdezés'
ufw allow 27016/udp comment 'Unturned játék'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

A sorrend fontos, különben kizárja saját magát. A teljes útmutató a mentőúttal együtt az UFW-tűzfal beállítása anélkül, hogy kizárná magát cikkben olvasható. Ha több példányt üzemeltet, tartsa be a javasolt kettes lépésközt (27015, 27017, 27019), és példányonként pontosan azt a két portot engedélyezze, amelyet az valóban elfoglal.

Egy webpanel, egy adatbázis vagy egy RCON-bővítmény nem való a nyílt hálózatba. Korlátozza az adott portot a saját címére az ufw allow from 203.0.113.10 to any port 8080 proto tcp paranccsal, vagy érje el a felületet helyi SSH-porttovábbításon keresztül az ssh -N -L 8080:127.0.0.1:8080 root@A.SZERVERE.IP.CÍME paranccsal. Az adatbázist a 127.0.0.1 címhez kell kötni.

3. A lekérdezőport bebiztosítása anélkül, hogy kiesne a szerverlistából

A lekérdezőport egy Unturned-szerver legérzékenyebb pontja. Ezen keresztül válaszolja meg a szerver az A2S_INFO, az A2S_PLAYERS és az A2S_RULES Steam-lekérdezést. Ha teljesen letiltja, a szerver eltűnik minden szerverlistáról, akkor is, ha egyébként hibátlanul fut.

Egy A2S-válasz lényegesen nagyobb a kérésnél. Az US-CERT az UDP-erősítéses támadásokról szóló áttekintésében (TA14-017A) 5,5-es sávszélesség-erősítési tényezővel vezeti a Steam-protokollt. Konkrétan ez azt jelenti: a támadó hamisított feladócímmel küld lekérdezéseket idegen játékszerverekre, és a körülbelül öt és félszer nagyobb válaszokat a tényleges célpontjára irányítja. A szervere ilyenkor nem az áldozat, hanem az erősítő egy harmadik fél ellen. Az ellenkező irányban egy lekérdezési áradat is elegendő ahhoz, hogy a szerver eltűnjön a szerverböngészőből anélkül, hogy egyetlen játékos is kirepülne. Az üzemeltetők pontosan ezt jelentik: a szerver fut, a rajta lévő játékosok nem észlelnek semmit, de már nem lehet megtalálni.

A kis lekérdezési áradatok ellen egy forráscímenkénti felső korlát segít. A szabályos lekérdezések ritkán jönnek: a Steam-böngésző megjelenítésenként egyszer kérdez, az állapotszolgáltatások néhány percenként.

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name unturned_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name unturned_game --hashlimit-mode srcip --hashlimit-above 300/sec --hashlimit-burst 500 -j DROP

A második szám közvetlenül a játékból származik: az Unturned gyárilag másodpercenként 50 csomagra korlátoz egy játékost (Max_Packets_Per_Second). A másodpercenkénti és forráscímenkénti 300 csomag tehát bőven hagy levegőt egyetlen előfizetésnek, akkor is, ha több játékos ül ugyanazon a címen. Mindkét érték kiindulási érték, nem igazság. Mérjen előbb egy hetet normál üzemben, különben a saját játékosait dobja ki.

A puszta iptables-szabályok egy újraindítás után nincsenek meg. Debian és Ubuntu alatt az apt-get install -y iptables-persistent és a netfilter-persistent save paranccsal mentik el őket. UFW alatt az ilyen szabályok a /etc/ufw/before.rules fájlba tartoznak, különben a következő ufw reload parancsnál eltűnnek.

Ehhez jön egy szokás, amely semmibe nem kerül: ha a weboldala vagy a Discord-botja mutatja a játékosszámot, ne a látogató felől kérdezze le a szervert, hanem fix időközönként tárolja el az eredményt. Egy sokat látogatott állapotoldal különben látogatónként egy lekérdezést okoz, nem intervallumonként egyet.

4. A Config.json fájlban lévő beépített korlátok beállítása

Az Unturned a Commands.dat fájllal azonos Server könyvtárban lévő Config.json fájlban olyan szakaszt hoz magával, amely a védelem szempontjából fontosabb, mint amit a neve sejtet. Az alapértelmezések a következők:

"Server": {
    "VAC_Secure": true,
    "BattlEye_Secure": true,
    "Max_Ping_Milliseconds": 750,
    "Timeout_Queue_Seconds": 15.0,
    "Timeout_Game_Seconds": 30.0,
    "Max_Packets_Per_Second": 50.0,
    "Join_Rate_Limit_Window_Seconds": 40.0,
    "Rate_Limit_Kick_Threshold": 10,
    "Use_FakeIP": false
}

A Max_Packets_Per_Second egy csatlakozott játékost másodpercenként 50 csomagra korlátoz. A Join_Rate_Limit_Window_Seconds és a Rate_Limit_Kick_Threshold kidobja azt a kapcsolatot, amely 40 másodpercen belül több mint tízszer túllépi a korlátot. A VAC_Secure és a BattlEye_Secure mindkét csalásellenes rendszert megköveteli a játékos oldalán, és ezzel távol tartja az eldobható kliensek nagy részét.

Egy dolognak világosnak kell lennie: ezek a korlátok azok ellen a kliensek ellen hatnak, amelyek valóban csatlakoznak, vagy megpróbálják. A hamisított feladócímekkel folyó áradat ellen nem hatnak, mert ott soha nem jön létre munkamenet. Mégis fontosak, mert a leggyakoribb egyedi esetet fogják el: egyetlen manipulált klienst, amely egymaga terheli túl a szervert. A Max_Ping_Milliseconds értékét érdemes 750-en hagyni; alacsonyabbra állítva a szerver minden rövid hálózati akadásnál fél környi játékost kidob.

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

Ezt a pontot szinte mindig figyelmen kívül hagyják, és olyan kieséseket magyaráz meg, amelyek volumetrikus támadásnak látszanak, de nem azok. A kernel az UDP-forgalomhoz is bejegyzéseket hoz létre a kapcsolatkövetésben (conntrack), hamisított feladócímek esetén pedig minden új cím új bejegyzést jelent. Ha a tábla megtelik, a kernel különbségtétel nélkül dobja el a csomagokat: a támadás és az Ön játékosai együtt repülnek ki. A rendszernaplóban ilyenkor az áll, hogy nf_conntrack: table full, dropping packet.

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

A leghatásosabb lépés az, ha az Unturned-forgalmat egyáltalán nem követteti. A játék maga kezeli a munkameneteit, és nincs szüksége állapotkövetésre a kernelben:

iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK
iptables -t raw -A PREROUTING -p udp --dport 27016 -j NOTRACK

Ügyeljen arra, hogy erre a két portra szóló engedélyezései ezután már nem futhatnak az ESTABLISHED,RELATED állapoton keresztül, hanem önálló elfogadási szabályként kell állniuk. Csak ezután érdemes megnövelni az nf_conntrack_max értékét. Aki először a táblát nagyobbítja meg, az csak percekkel tolja el a problémát, és memóriát fogyaszt hozzá.

Ha a csomagok gyorsabban érkeznek, mint ahogy a szerverfolyamat elviszi őket, ezen felül túlcsordul a socket fogadópuffere. Ez a játékosok számára úgy néz ki, mint csomagvesztés szabad vonalon:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Helyezze el az értékeket egy /etc/sysctl.d/ alatti fájlban, és aktiválja őket a sysctl --system paranccsal. Hogy szükség van-e rájuk, azt maga a kernel árulja el: ha az nstat -az kimenetében emelkedik az UdpRcvbufErrors értéke, vagy az ss -lunp kimenetében tartósan áll valami a fogadási várakozási sorban, akkor érvényesülnek. Ha mindkettő nullán marad, a módosítás semmit nem változtat. Ez tartalék, nem védelem.

6. Csatlakozási áradat, várakozási sor és engedélyezőlista

A csatlakozási áradat olyan támadás, amelyben a támadó a szabályos csatlakozási utat használja arra, hogy férőhelyeket és számítási időt fogyasszon, ahelyett hogy a vonalat töltené meg. Az Unturned négy eszközt hoz ez ellen, és mind a Commands.dat fájlban áll:

• A Queue_Size 32 állítja be a várakozási sort. Az alapértelmezés 8 hely, a maximum 64. A túl nagy várakozási sor a támadónak segít, a túl kicsi pedig minden újraindításnál lemorzsolja a valódi játékosokat.
• A Whitelisted átállítja a szervert hozzáférési listára. A felvétel a konzolon a permit <SteamID64> paranccsal történik, az eltávolítás az unpermit <SteamID64> paranccsal.
• A Password AzOnJelszava kizár mindenkit, aki a címet csak egy listáról szerezte.
• A Filter elutasítja azokat a játékosokat, akiknek a nevében nem engedélyezett karakterek vannak, a MaxPlayers 24 pedig annyin tartja a férőhelyek számát, amennyit a hardver valóban elbír.

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 csatlakozni. A csomagjait elutasítják, de attól még megérkeztek, és pontosan ez a lényeg.

7. RocketMod, OpenMod és a bővítmények oldala

Az Unturnednek két elterjedt bővítményplatformja van, és mindkettő ugyanabban a folyamatban fut, mint a szerver. A RocketMod a régebbi: az eredeti gondozók 2019. december 20-án hagyták abba a fejlesztést, és a forráskódot MIT-licenc alá helyezték. A Smartly Dressed Games azóta a Legally Distinct Missile (LDM) nevű leszármazottat gondozza, amelyet a dedikált szerverrel már együtt szállítanak: a Rocket.Unturned fájlt kell átkopírozni az Extras könyvtárból a Modules könyvtárba. A fejlesztők kifejezetten a leszármazottat ajánlják, mert az kijavítja a régi Rocket-problémákat, például a szálkezelési hibákat és a teleportálásos kihasználásokat.

Az OpenMod az újabb utód, amelyet az eredeti Rocket-gondozók egyike fejlesztett. Nem váltja le a RocketModot, hanem mellette fut, és egy integráción keresztül a meglévő Rocket-bővítményeket is használni tudja. A védelem szempontjából ez két dolgot jelent.

Először is: minden bővítmény támadási felület a főfolyamatban. Az a bővítmény, amely minden chatüzenetnél vagy minden játékeseménynél adatbázis-lekérdezést indít, saját kezűleg épített denial of service. Egyetlen játékos, aki ciklusban vált ki egy eseményt, ilyenkor sávszélesség nélkül bénítja meg a szervert. Tartsa rövid a bővítménylistát, részesítse előnyben a nyílt forráskódú bővítményeket, és minden kiegészítés után mérje meg a szerver képkockasebességét.

Másodszor: mivel az Unturnednek nincs saját RCON-portja, minden távvezérlés egy bővítményből származik. A telepítés után ellenőrizze az ss -lntp paranccsal, melyik TCP-portot nyitotta meg, és korlátozza a saját címére. Egy nyitott távvezérlési port gyenge jelszóval nem DDoS-probléma, hanem átvételi probléma.

8. A Workshop-tartalmak és a csatlakozás folyamata

A Workshop-tartalmak drágává teszik a csatlakozást, és ez közvetlenül kihat a támadhatóságra. Ezt az ugyanabban a Server könyvtárban lévő WorkshopDownloadConfig.json fájl szabályozza:

{
    "File_IDs": [],
    "Ignore_Children_File_IDs": [],
    "Query_Cache_Max_Age_Seconds": 600,
    "Max_Query_Retries": 2,
    "Use_Cached_Downloads": true,
    "Should_Monitor_Updates": true,
    "Shutdown_Update_Detected_Timer": 600
}

A File_IDs értékben a térképek és a modok Workshop-azonosítói állnak. Indításkor a szerver letölti őket a függőségeikkel együtt, és minden játékos automatikusan utánatölti őket csatlakozáskor. Három következményt érdemes ismerni. Először is nagy modlisták esetén hosszú a csatlakozás, és egy támadás után minden játékos egyszerre tér vissza, ami másodszor is megterheli a szervert. Másodszor a Should_Monitor_Updates leállítja a szervert, amint egy Workshop-fájl frissül: a Shutdown_Update_Detected_Timer előre beállított 600 másodperces értéke ilyenkor újraindításhoz vezet, amelyet az üzemeltetők támadás esetén rendszeresen a támadás sikerének tartanak. Harmadszor minden mod idegen kód az Ön szerverén.

A gyakorlatban ez azt jelenti: tartsa a listát a lehető legrövidebben, minden váratlan újraindítás után először a szervernaplót vizsgálja meg a Workshop-frissítésről szóló bejegyzés miatt, és csak akkor kapcsolja ki a Should_Monitor_Updates beállítást, ha a frissítéseket saját maga tervezi be.

9. Szerverlista, szerverkód és a Fake-IP funkció

Az IP-címét nem lehet titokban tartani, amíg a szerver nyilvánosan szerepel a listákban. Ismeri minden játékos, aki egyszer már kapcsolódott, és a harmadik felek listái amúgy is közzéteszik. Két szokás mégis segít: sehol ne tegye közzé saját maga a nyers címet, és hostnéven keresztül kösse be a játékosait, hogy egy címcsere ne törjön el minden hivatkozást. A klasszikus hiba az elfelejtett A-rekord a régi címre, amely minden cserét hatástalanná tesz.

Az internetes üzemeltetéshez amúgy is szükség van egy Game Server Login Tokenre (GSLT) a Steam szerverkezelő felületéről, a 304930 app-azonosítóhoz. Ez ráadásul arról is gondoskodik, hogy a szervere szerverkódja újraindításokon át ugyanaz maradjon, ahelyett hogy minden indításkor újra létrejönne.

Az Unturned ezen felül Fake-IP funkciót is kínál. A Config.json fájlban a "Use_FakeIP": true beállítással kapcsolható be, a CopyFakeIP konzolparancs pedig megadja azt a címet, amelyet aztán közzétehet. A forgalom ezután a Steam Datagram Relay reléhálózaton keresztül fut, a kiosztott címek a 169.254.0.0 és a 169.254.255.255 közötti tartományba esnek, és a szerver valódi címét már nem mutatják meg a játékosoknak. A Valve a forgalmat hitelesítettként, titkosítottként és sebességkorlátozottként írja le.

Ennek az ára magas, és ritkán teszik hozzá: a cím és a port minden újraindításnál változik, egy domainnevet saját szkriptek nélkül nem lehet rá irányítani, és a Steam „Kedvencek” és „Előzmények” listája így nem működik, csak a könyvjelző funkció. Legfőképpen azonban a funkció csak a játék útját védi. A szervere megtartja a valódi címét, és az SSH, a webpanel, az adatbázis és a weboldal azon keresztül továbbra is elérhető marad. Aki a címet egy régi DNS-bejegyzésből, egy állapotoldalról vagy egy korábbi kapcsolatból ismeri, továbbra is közvetlenül támadja. A Fake-IP funkció tehát nem helyettesíti a szerver előtti hálózatban végzett szűrést, csupán csökkenti azoknak a számát, akik egyáltalán ismerik a címét.

10. Naplózás, hogy 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 létrehozni, 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 péntek 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
dmesg -T | tail -50
tcpdump -ni eth0 udp portrange 27015-27016 -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, és hogyan különítse el a támadást egy szoftverhibától, arról a DDoS-támadás felismerése a szerveren cikk szól.

Hol érnek véget ezek az intézkedések

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.

Számoljon utána egyszer. Egy tipikus játékszerver 1 Gbit/s-os vonalon lóg, ez 125 megabájt másodpercenként, és a vonal tele van, amint valaki ennél többet küld. A normál üzem messze ez alatt marad: 24 játékos és a gyárilag engedélyezett, játékosonkénti és másodpercenkénti 50 csomag mellett körülbelül 1200 csomag érkezik másodpercenként. Egy booter-szolgáltatás minden előkészület nélkül ennek a többszörösét termeli.

A második mennyiség a csomagsebesség, és ez majdnem mindig hamarabb üt be, mint a sávszélesség. 64 bájtos kis csomagoknál egy 1 Gbit/s-os vonalba körülbelül 1,49 millió csomag fér másodpercenként. Egy normál szerverkernel a processzortól és a hálózati kártyától függően ennek néhány százezrét dolgozza fel, mielőtt elkezdene eldobni. Egy támadás, amely a vonalát még harmadáig sem tölti meg, tehát ettől függetlenül 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 terhelés nem is volt magas, mégis minden elérhetetlen lett”.

A nagyságrendek besorolásához, amelyek valóban előfordulnak: a KernelHost szerverein többek között egy 473,4 Gbit/s feletti támadást szűrtek ki másodpercenként több mint 41,5 millió csomaggal egy hangszerver ellen, és egy 112,2 Gbit/s feletti UDP-floodot egy játékszerver ellen. 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 ez ellen a KernelHost

A folyamatos védelem, amely minden szerverben benne van

A KernelHostnál minden szerver árában benne van egy 3,2 Tbps kapacitású DDoS-alapvédelem. Tartósan aktív, anélkül, hogy bármit be kellene kapcsolnia, meg kellene rendelnie vagy konfigurálnia, és az Advanced DDoS Protection szolgáltatással bővíthető:

• Az árban benne van: Arbor valós idejű szűrés 3,2 Tbps kapacitással Frankfurt am Mainban. Az elterjedt floodokat, például az UDP-, SYN- és ICMP-floodokat, valamint a reflexiós és erősítéses támadásokat közvetlenül a szerver előtt ismeri fel és dobja el, csomagról csomagra.
• Az Advanced DDoS Protection szolgáltatással: akár 17 Tbps mitigációs kapacitás a globális scrubbing-hálózatban. A nagyon nagy támadásokat a forrásuk közelében tisztítja meg, mielőtt elérnék az adatközpontot, a specializált profilok pedig kiszűrik az egyes játékok elleni célzott támadásokat.

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ó. A helyszín Frankfurt am Main. Hogy az Advanced DDoS Protection mely játékokat és protokollokat fedi le saját profilokkal, 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 EUR-ért, PrePaid alapon, minimális futamidő és beállítási díj nélkül. Akár 17 Tbps mitigációs kapacitást nyújt a globális scrubbing-hálózatban, és jóval nagyobb kontrollt ad:

• 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 27015 UDP porton (a lekérdezések) és mi a 27016 UDP porton (a játékforgalom), anélkül hogy hibajegyet 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, például szűkebbre fogja a lekérdezéseket, a játékforgalmat viszont érintetlenül hagyja.
• A játékhoz illő védelmi profil, ugyanígy a módosított és a saját alkalmazásokhoz is, tetszőleges TCP- vagy UDP-portokon, tehát egy saját porttal rendelkező bővítményhez is.

A két szint összehasonlítva

Az elterjedt floodok ellen elegendő a csomagban foglalt alapvé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.

Gyakori hibák és megoldások

„Az útmutatóm azt írja, hogy a 27015-től a 27017-ig kell engedélyeznem”: az útmutató 2021 novemberénél régebbi. A 3.21.30.0 verzió óta egy Unturned-szervernek már csak két portra van szüksége, mert a Steam-lekérdezés már nem a port plusz kettőn ül. Zárja be a 27017-et, kivéve ha ott egy második példány fut.

„A szerver fut, de már egyetlen szerverlistában sem szerepel”: ez a lekérdezési áradat vagy egy túl szigorú saját szabály tipikus képe a 27015 UDP porton. Ellenőrizze az iptables -L INPUT -n -v paranccsal, hogy a saját szabálya számol-e találatokat. Ha a számlálók erősen emelkednek, éppen a saját listabejegyzéseit szűri ki. A 27015-öt soha ne tiltsa le teljesen.

„Minden játékos egyszerre repül ki időtúllépéssel”: először nézze meg, nem csordult-e túl a kapcsolatkövetés (dmesg -T | grep -i conntrack). Ha a tábla megtelt, a kernel különbségtétel nélkül dobja el a csomagokat. A Timeout_Game_Seconds gyárilag 30 másodpercen áll: aki ezen belül visszatér, megtartja a helyét.

„A szerver üzem közben újraindul”: ez ritkán támadás. Vizsgálja meg a naplót az észlelt Workshop-frissítésről szóló bejegyzés miatt. A Should_Monitor_Updates az előre beállított 600 másodperces időtartam után leállítja a szervert.

„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 egy szerverlistából, egy Discord-botból vagy egy régi DNS-bejegyzésből. A címcsere időnyereség, nem megoldás.

„Bekapcsoltam a Fake-IP funkciót, és mégis támadnak”: a funkció elrejti a címet az új játékosok elől, de nem veszi el a szervertől. Aki egy régi listabejegyzésből, egy állapotoldalról vagy egy korábbi kapcsolatból ismeri, továbbra is közvetlenül eléri a szerverét, ugyanígy az SSH-t és minden rajta futó webpanelt is.

„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 Unturned-szervernek pontosan két nyitott UDP-portra van szüksége: a Commands.dat fájlban beállított Port értékre (alapértelmezés 27015) és ennek az értéknek a plusz egyére (27016). TCP-re magának a játéknak nincs szüksége.
• A 27017-es port a 2021. november 21-én kiadott 3.21.30.0 verzió óta felesleges, mert a Steam-lekérdezés már nem a port plusz kettőn ül. Aki még nyitva tartja, elavult útmutatót követ.
• Az Unturnednek nincs beépített RCON-portja. Minden távvezérlés egy bővítményből jön, saját TCP-portot hoz magával, és Önnek magának kell korlátoznia.
• A 27015-ös lekérdezőport a legérzékenyebb pont: egy lekérdezési áradat láthatatlanná teszi a szervert a szerverlistában anélkül, hogy egyetlen játékost is eltalálna, a Steam-protokoll erősítési tényezője pedig az US-CERT TA14-017A szerint 5,5.
• A Config.json fájlban lévő korlátok (Max_Packets_Per_Second 50,0, Rate_Limit_Kick_Threshold 10 negyven másodpercenként) csak azok ellen a kliensek ellen hatnak, amelyek valóban csatlakoznak, a hamisított feladócímek ellen nem.
• Egy 1 Gbit/s-os vonal 125 megabájt másodpercenként értéknél tele van, 64 bájtos csomagoknál pedig már körülbelül 1,49 millió csomagnál másodpercenként. A 24 játékossal futó normál üzem körülbelül 1200 csomag másodpercenként. Minden ezen felüli esetben a szerver előtti hálózat dönt, nem az Ön tűzfala.
• A KernelHostnál a 3,2 Tbps kapacitású alapvédelem minden szervercsomagban felár nélkül benne van, és a kiszállítástól aktív, null-routing nélkül. Aki a szűrőszabályokat saját maga akarja irányítani, ahhoz veszi az Advanced DDoS Protection szolgáltatást havi 50,00 EUR-ért.

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.