MTA:SA-szerver védelme DDoS-támadások ellen

Egy Multi Theft Auto: San Andreas szerver DDoS-támadás alatt másként viselkedik, mint bármely más GTA-többjátékos projekt, mert egyszerre három elkülönült hálózati szolgáltatást kínál: a játékforgalmat a 22003 UDP porton, egy teljes értékű HTTP-szervert a 22005 TCP porton és az ASE-lekérdezést a 22126 UDP porton. Ez a három szolgáltatás egyenként támadható, és mindegyik másképp esik ki. Ez a cikk először azt mutatja meg, mit tud Ön többletköltség nélkül maga bebiztosítani, utána azt, hol érnek véget ezek az intézkedések a vonal fizikáján, végül azt, mit kell egy hatékony MTA:SA-DDoS-védelemnek a szerver előtti hálózatban teljesítenie.

Ha a támadás éppen zajlik, a legfontosabb kérdés az, hogy a három szolgáltatás közül melyiket érte. Ha a játékosok csatlakozva maradnak, de belépéskor már nem töltődnek le az erőforrások, akkor a 22005-ös porton lévő HTTP-szervert érte. Ha a szerver eltűnik a böngészőből, miközben a csatlakozott játékosok normálisan játszanak tovább, akkor a 22126-os porton futó ASE-lekérdezést érte. Ha minden kapcsolat egyszerre szakad meg, akkor vagy a 22003-as port a célpont, vagy a vonal tele van. Minden adat egy MTA-szerverre vonatkozik 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.

Miért lesznek az MTA:SA-szerverek olyan gyakran DDoS-támadások célpontjai

Az MTA:SA-projektek kényelmes célpontok, mert maguknak kell közzétenniük a címüket. Egy szerver csak akkor jelenik meg a játékböngészőben, ha bejelentkezik a mesterszerver-listára, és utána megválaszolja a kívülről érkező lekérdezéseket. A lista nyílt szövegként tartalmazza az IP-címet és a portot, egy támadónak tehát semmilyen előzetes felderítésre nincs szüksége.

Ehhez jön maga a szcéna. A német és a brazil szerepjáték-szerverek, a drift-szerverek és a DayZ-átdolgozások ugyanazért a játékosbázisért versengenek, és egy csúcsidőben bekövetkező kiesés a lehető legjobban látszik. Egy kitiltott játékosnak, egy szétesett csapatnak vagy egy konkurens projektnek sem tudásra, sem említésre méltó pénzre nincs szüksége ahhoz, hogy egy estét használhatatlanná tegyen. A megvásárolható támadási szolgáltatások, amelyeket a szcénában booternek vagy stressernek neveznek, havi néhány euróért pontosan két eredményt adnak el: az MTA-szerver percekre offline vitelét, vagy azt, hogy lag-tüskékkel játszhatatlan legyen. Hogy technikailag mi is egy DDoS-támadás, és milyen támadástípusok vannak, azt a Mi az a DDoS-támadás? című cikk magyarázza el.

Technikailag az MTA:SA két helyen könnyíti meg a támadók dolgát más többjátékos módosításokhoz képest. Először is a lekérdezés saját UDP-porton ül, amely egyetlen bájtra több kilobájt méretű választ küld. Másodszor minden MTA-szerverhez tartozik egy HTTP-szerver, amely az összes erőforrás kliensoldali fájljait kiszolgálja, méghozzá bejelentkezés nélkül mindenkinek, aki kéri.

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

Egy MTA:SA-szervernek pontosan három portra van szüksége: 22003 UDP a játékhoz, 22005 TCP a belső HTTP-szerverhez és 22126 UDP az ASE-lekérdezéshez. A harmadik port nem szabadon választható beállítás, hanem fixen a játékport plusz 123 értékéből adódik. Aki a serverport értékét 22010-re állítja, annak a lekérdezés a 22133-as porton lesz.

Két finomság így áll a szállított mtaserver.conf fájlban, és rendszeresen elnézik. A httpport ugyanazt a számértéket viselheti, mint a serverport, mert az egyik port TCP, a másik UDP. A serverip pedig auto értéken áll, és ott is kell maradnia: egy fixen beírt érték pontosan arra a címre köti az ASE-socketet, és elrontja a listabejegyzést, amint a cím megváltozik.

Az ASE-lekérdezőprotokoll, és miért működik erősítőként

Az ASE (All-Seeing Eye) tisztán UDP-alapú lekérdezőprotokoll: a csomag első bájtja határozza meg a választ, kapcsolatfelépítés nincs. Az MTA-szerver öt lekérdezést ismer, és a 22126-os porton válaszolja meg őket:

• Az s a teljes ASE-lekérdezés. A válasz az EYE1 karakterekkel kezdődik, és tartalmazza a szerver nevét, a játéktípust, a térkép nevét, a verziót, a jelszó állapotát, a játékosszámot, a setRuleValue hívással beállított összes szabály teljes listáját, majd minden csatlakozott játékost névvel, pontszámmal és pinggel. Ennek a válasznak nincs méretkorlátja.
• A b és az r a játékböngésző számára készült könnyebb lekérdezések. A válasz az EYE2 karakterekkel kezdődik, és a forráskód 1340 bájtnál elvágja, hogy elkerülje a töredezettséget.
• Az x rövidített állapotüzenetet ad, a v csak az ASE-verzióazonosítót.

Ebből adódik a probléma. Egy kérés egyetlen bájt hasznos adatból áll, a vezetéken tehát 29 bájtból (20 bájt IP-fejléc, 8 bájt UDP-fejléc, 1 bájt hasznos adat). Egy 1400 bájt hasznos adatot tartalmazó válasz a vezetéken 1428 bájt. Az arány nagyjából 49-szeres, és mivel az UDP nem ismer kapcsolatfelépítést, a feladócím hamisítható. Egy támadó tehát erősítőként használhatja az Ön szerverét egy harmadik célpont ellen, anélkül hogy valaha belépne a játékába. A teljes lekérdezés esetén a tényező a játékosszámmal és minden olyan szabállyal növekszik, amelyet az Ön gamemode-ja beállít.

Az MTA ezzel szemben két beépített féket hoz magával, amelyeket érdemes ismerni, mert megmagyarázzák, miért hatnak egyes áradatok és mások miért nem. A szerver forráscímenként legfeljebb öt lekérdezést válaszol meg hat másodperc alatt, és utána hét másodpercig figyelmen kívül hagyja a címet. Ezen felül tíz másodpercig gyorsítótárban tartja a válaszokat, ahelyett hogy kérésenként újra összeállítaná őket. A forráscímenkénti számolást viszont teljesen kihagyja, amint száznál több különböző feladócím szerepel egyszerre a listában. Pontosan ez a normális eset egy botnetből érkező vagy hamisított feladókkal dolgozó elosztott áradat esetén, és ezért nem segít a beépített fék egy komoly támadás ellen.

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 MTA-szerver saját erőből kibírja a kis és közepes támadásokat, függetlenül attól, hogy hol áll.

1. Leltár: mi figyel egyáltalán

Először nézze meg, mit kínál a szervere kifelé. Ne tippeljen, nézzen utána:

ss -lntup

Az MTA-folyamattól három sor várható: 0.0.0.0:22003 UDP-n, 0.0.0.0:22005 TCP-n és 0.0.0.0:22126 UDP-n. Ha ezen felül megjelenik egy adatbázis a 0.0.0.0:3306 címen, egy webszerver vagy egy elfelejtett hangszolgáltatás, azt le kell állítani. A támadó nézőpontját egy kívülről indított portszkennelés adja meg:

nmap -Pn -sU -p 22003,22126 A.SZERVERE.IP.CÍME
nmap -Pn -p 22005 A.SZERVERE.IP.CÍME

A szerver ehhez saját konzolparancsot is hoz magával. A szerverkonzolban az openports ellenőrzi, hogy mindhárom port elérhető-e kívülről.

2. Csak azokat a portokat hagyja nyitva, amelyekre az MTA-nak valóban szüksége van

UFW-vel egy tartható kiindulási konfiguráció í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 22003/udp comment 'MTA játék'
ufw allow 22005/tcp comment 'MTA HTTP'
ufw allow 22126/udp comment 'MTA ASE'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

A teljes útmutató a mentőúttal együtt az UFW-tűzfal beállítása című cikkben olvasható. A KernelHost KVM root-szerverein és dedikált szerverein vészhelyzetben az ügyfélportálon elérhető VNC-konzolon keresztül jut be a rendszerbe, akkor is, ha a vonal telített.

Az adatbázis nem való a nyílt hálózatra. Ha az ss -lntp | grep 3306 parancs 0.0.0.0:3306 értéket mutat, írja be az /etc/mysql/mariadb.conf.d/50-server.cnf fájlba a bind-address = 127.0.0.1 sort, és indítsa újra a szolgáltatást.

3. Az ASE-port korlátozása anélkül, hogy kiesne a szerverlistából

Az SA-MP-vel szemben az MTA:SA esetében a lekérdezés saját porton ül, tehát a játékmenettől függetlenül korlátozható. Ez ennek az architektúrának a legnagyobb gyakorlati előnye: egy 22126-os portra tett szabály egyetlen játékost sem dob ki.

nftables-szel saját táblában, hogy a szabálykészlet ne kerüljön az UFW útjába:

nft add table inet mtaguard
nft add chain inet mtaguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet mtaguard input udp dport 22126 meter aseperip '{ ip saddr limit rate over 3/second burst 6 packets }' drop
nft add rule inet mtaguard input udp dport 22126 limit rate over 2000/second burst 500 packets drop
nft list table inet mtaguard

Az első szabály minden egyes forráscímet korlátoz, a második az egész portot. Mindkettő együtt fontos: egy elosztott áradat átfut a sok egyedi forrás közötti résen, ha csak címenként van korlátozás. Az értékek szűkre vannak szabva, és ez itt védhető, mert egy valódi szerverböngésző csak néhány másodpercenként kérdezi le a szerverét. Az iptables esetében a hashlimit modul ugyanezt éri el:

iptables -A INPUT -p udp --dport 22126 -m hashlimit --hashlimit-name mta_ase \
  --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 6 \
  --hashlimit-htable-expire 30000 -j DROP

A port teljes bezárása mérlegelés kérdése és nem titkos trükk: ASE nélkül a szervere eltűnik a játékböngészőből, és ezzel az organikus játékosforgalomból is. Ha mégis ezt akarja, az <ase>0</ase> beállítás nem elegendő. A forráskódban a port megnyitása az internetmód és a LAN-mód vagy-kapcsolatán függ, tehát az <ase>0</ase> beállítás mellett a socket továbbra is nyitva marad, amíg a <donotbroadcastlan>0</donotbroadcastlan> érték áll. Aki valóban be akarja zárni a portot, az mindkettőt beállítja:

<ase>0</ase>
<donotbroadcastlan>1</donotbroadcastlan>

Egy növekvő projekt számára az őszintébb út a következő: hagyja nyitva a portot, korlátozza a sebességet, és tartsa kicsin az erősítési hatást azzal, hogy a gamemode-ja nem tesz közzé szükségtelen szabályokat a setRuleValue hívással. Minden szabály benne van a teljes lekérdezésben, és növeli a választ.

4. A belső HTTP-szerver tehermentesítése

A 22005-ös porton lévő HTTP-szerver az MTA:SA esetében önálló támadási felület, mert minden belépő játékos onnan tölti le az összes futó erőforrás teljes kliensoldali fájlkészletét. Egy saját modellekkel dolgozó szerepjáték-projektnél ez gyorsan több száz megabájt, több száz egyedi fájlra szétosztva. A beépített szerver szándékosan egyszerű: nincs tömörítés, a munkaszálak száma pedig fixen adott. Néhány tucat egyidejű letöltés is elegendő ahhoz, hogy valódi játékosok percekig a betöltőképernyőn ragadjanak.

A leghatásosabb lépés az, ha a letöltéseket teljesen kiveszi a játékszerverből. Az MTA a kiszolgálandó fájlokat ehhez maga készíti elő, a mods/deathmatch/resource-cache/http-client-files útvonalon. Ezt a mappát nginx vagy lighttpd segítségével szolgálja ki, a címet pedig írja be az mtaserver.conf fájlba:

<httpdownloadurl>http://cdn.sajat-domain.hu/mta</httpdownloadurl>

Ez két dolgot hoz egyszerre. A letöltések olyan webszerveren futnak, amelyet erre építettek, és már nem az Ön játékszerverének címén futnak. Ha a webszerver másik gépen vagy egy tartalomkiszolgáló hálózat mögött van, a letöltések elleni áradat már nem éri a játékmenetet. Fontos: ha a külső cím hibás vagy nem elérhető, az MTA szó nélkül visszaáll a belső szerverre.

Ha a belső szerver használatban marad, használja a saját korlátait. Az mtaserver.conf fájlban:

<httpmaxconnectionsperclient>5</httpmaxconnectionsperclient>
<httpdosthreshold>20</httpdosthreshold>
<http_dos_exclude></http_dos_exclude>
<httpthreadcount>8</httpthreadcount>

A httpmaxconnectionsperclient kliensenként 5-re korlátozza az egyidejű kapcsolatokat, a megengedett tartomány 1 és 8 között van. A httpdosthreshold azt korlátozza, hány kapcsolatot építhet fel egyetlen IP-cím rövid idő alatt, az alapérték 20. A http_dos_exclude egyes címeket kivesz ebből, például az Ön saját állapotoldalát. A httpthreadcount a munkaszálak számát határozza meg, az alapérték 8, a tartomány 1 és 20 között van. A magasabb érték sok kis fájl esetén segít, de olyan számítási időt visz el, amely a játékmenettől hiányzik.

Gondoljon ezen felül arra is, mi kerül még kiszolgálásra ugyanazon a porton. A webadmin és a resourcebrowser erőforrás a szállított konfigurációban el van indítva, és a 22005-ös porton keresztül böngészőből elérhető. Egy kezelőfelület nem való védelem nélkül a nyílt hálózatra: adjon tiszta jogosultságokat az acl.xml fájlban, hozzon létre saját fiókot hosszú véletlen jelszóval, és állítsa le az erőforrást, ha nincs rá szüksége.

5. Az mtaserver.conf beépített korlátainak használata

Az MTA több védelmi korlátot hoz magával, mint amennyit a legtöbb projekt használ. Néhány fixen a forráskódban áll, mások az mtaserver.conf fájlban. Ez a táblázat azokat foglalja össze, amelyek egy támadás során szerepet játszanak:

Három beállítás megér egy tudatos döntést. A maxplayers 32-n áll, és a valósághoz kell igazodnia: minden további férőhely növeli a teljes lekérdezést, és növeli azoknak a kapcsolatoknak a számát, amelyeket egy támadó lefoglalhat. A bandwidth_reduction medium értéken áll, a maximum érték érzékelhetően csökkenti a kimenő terhelést, de szinkronizációs pontosságot visz el. A <password></password> pedig ráfordítás nélkül zárt körré alakítja a szerverét, miközben a listabejegyzés megmarad: ez a leggyorsabb vészfék egy zajló belépési áradat esetén.

6. A belépési áradatok és az eseményáradatok szétválasztása

Két támadási minta nem a vonalat célozza, hanem a játéklogikát, és rendszeresen összekeverik őket.

A belépési áradat gyors egymásutánban valódi kapcsolatokat épít fel, amíg minden férőhely be nem telik, vagy amíg a szerver már nem bírja a felépítést. Az MTA ezt magától négy kapcsolatra korlátozza forráscímenként 30 másodpercen belül, és utána 30 másodpercig figyelmen kívül hagyja a címet. Hogy a fék éppen mit tesz, azt a debugjoinflood konzolparancs mutatja. A korlát címenként hat, egy ezer címmel rendelkező botnet elmegy mellette. Ez ellen szerverjelszó, a gamemode-ban lévő engedélyezőlista és a 22003-as portra tett sebességkorlátozás segít.

Az eseményáradat ezzel szemben már csatlakozott játékosoktól jön: egy módosított kliens ciklusban küldi a triggerServerEvent hívást, amíg a szerver már nem tudja előállítani a számítási időt. Az MTA ehhez gyárilag 100 eseményt engedélyez játékosonként és másodpercenként, és ezen felül eseményáradatról szóló üzenettel dobja ki a klienst. Ha a gamemode-ja sok kis eseményt használ, ellenőrizze az értéket, mielőtt csökkentené: túl szűken beállítva a saját játékosait dobja ki.

Ettől függetlenül szerveroldalon ugyanaz a szabály érvényes, mint bárhol máshol: soha ne hagyatkozzon olyan értékekre, amelyeket a kliens küld, a játékost az esemény feladójából állapítsa meg, és korlátozzon mindent, ami adatbázis-lekérdezést indít. Egyetlen ellenőrzés nélküli esemény, amely lekérdezést indít, elegendő ahhoz, hogy bármiféle hálózati támadás nélkül megállítson egy szervert.

7. Szerverlista, IP-cím, és mit árul még el

Az IP-címét nem lehet titokban tartani. Minden játékos, aki egyszer csatlakozott, ismeri, a mesterszerver-lista bejegyzése pedig amúgy is közzéteszi. Egy elé tett domain nem segít: a kliens egyszer feloldja a nevet, és utána közvetlenül a címmel beszél.

Ehelyett ellenőrizze, mi árulja még el a címét. Az MTA-projektek tipikus szivárgásai a régi A- és AAAA-bejegyzések a DNS-ben, a projektoldal ugyanazon a gépen, egy állapotjelzős Discord-bot, amely nyilvánosan olvassa ki az ASE-lekérdezést, a régi hosztneveket tartalmazó TLS-tanúsítványok és a kezdeti időkből származó fórumbejegyzések. Ebből olyan szabály következik, amelyet sok projekt túl későn tanul meg: ha védett címre költözik, egyszerre cserélje le a régi címet is. Ha az megmarad, benne van minden szkenner-adatbázisban, és a támadás elmegy a védelem mellett.

Az mtaserver.conf fájl két bejegyzése közvetlenül érinti a láthatóságot. A <serverip>auto</serverip> auto értéken marad, kivéve ha pontosan tudja, miért nem. Az <owner_email_address> pedig kitöltésre való: ha a bejegyzés hiányzik vagy hibás, az korlátozhatja a láthatóságot a mesterszerver-listában.

8. Naplózás, hogy éles helyzetben legyenek adatai

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 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 először válassza el egymástól a három portot. Ez a négy parancs elegendő:

sar -n DEV 1 10
nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
tcpdump -ni eth0 -c 200 -q 'udp port 22126'
ss -tn state established '( dport = :22005 or sport = :22005 )' | wc -l

Az értelmezés egyszerűbb, mint amilyennek látszik. Ha a pufferhibák alacsony processzorterhelés mellett emelkednek, több forgalom érkezik Önhöz, mint amennyit a folyamat fel tud dolgozni. Ha egy processzormag a végén jár, miközben a forgalom normálisnak látszik, a probléma a gamemode-ban van és nem a hálózatban. Ha a 22126-os porton készült felvétel sok, egyetlen bájt hasznos adatot tartalmazó csomagot mutat, akkor ASE-áradatról van szó. Ha a 22005-ös porton a nyitott kapcsolatok száma tartósan négyjegyű, akkor a HTTP-szervert érte. A tcpdump parancsnál mindig érvényes: 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 egyenként hogyan értelmezze, arról a DDoS-támadás felismerése a szerveren című cikk szól.

Maga a szervernapló a logs/server.log útvonalon található, a szkriptnapló a logs/scripts.log útvonalon. Mindkét útvonal az mtaserver.conf fájlban áll, és áthelyezhető.

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

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 64 bájtos csomagok esetén nagyjából másodpercenként 1,49 millió csomag. Az ilyen nagyságrendű játékszerver-projektek elleni támadások szokásosan 5 és 50 Gbit/s között vannak, tehát az Ön vonalának ötszöröse és ötvenszerese között. Hogy a mögötte lévő nftables-szabálya jó-e, akkor már nem játszik szerepet, mert a játékosai csomagjai már előtte sem jutnak át.

A csomagsebesség ennél gyakran hamarabb üt be, mint a sávszélesség. Egy normál szerverkernel processzortól és hálózati kártyától függően néhány százezer csomagot dolgoz fel másodpercenként, 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, mert az eldobásra megy el a számítási idő. Az üzemeltetők ezt úgy élik meg, hogy „a kihasználtság nem is volt magas, mégis minden eltűnt”.

Az MTA:SA esetében jön egy harmadik korlát, és az ér be a legkorábban. A szerver egyetlen munkamenetben olvassa a hálózati portokat. Egy 22126-os portra irányuló lekérdezési áradat annyira lefoglalja ezt a menetet, hogy a valódi játékosok szinkronizációs csomagjai elvesznek a fogadópufferben, jóval azelőtt, hogy a vonal megtelne. A folyamat ettől nem áll le, csak lassú lesz, a játékosok pedig gumiszalag-hatást látnak. Ugyanez érvényes a HTTP-szerverre is: a számítási időt a játékmenettel osztja meg.

Hogy elhelyezhető legyen, milyen nagyságrendek fordulnak elő a valóságban: KernelHost-szervereken többek között egy 473,4 Gbit/s feletti, másodpercenként több mint 41,5 millió csomagot elérő támadást szűrtünk ki egy hangszerver ellen, valamint egy 112,2 Gbit/s feletti, másodpercenként több mint 8,7 millió csomagot elérő UDP-floodot egy játékszerver ellen. Az első eset nagyjából a 473-szorosa annak a sávszélességnek és körülbelül a 28-szorosa annak a csomagsebességnek, amelyet egy 1 Gbit/s-os vonal egyáltalán fel tud venni. 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 szervercsomagban benne van

A KernelHost minden szervere tartósan aktív, kétrétegű szűrés mögött áll:

• 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 egyáltalán elérnék a Frankfurt am Main-i adatközpontot.
• 2. réteg: Arbor valós idejű szűrés 3,2 Tbps kapacitással közvetlenül a helyszínen, Frankfurt am Mainban. Közvetlenül a szerver előtt ismerjük fel a protokollspecifikus mintákat, és csomagról csomagra dobjuk el őket.

Három tulajdonság döntő. A védelem tartósan aktív, tehát nincs felismerési szakasz, amely alatt a szervere offline lenne. Null-routingot nem alkalmazunk: a megtámadott cím a hálózaton marad, csak a káros csomagokat dobjuk el, miközben a valódi játékosok kapcsolatai tovább futnak. És nem kerül semmibe külön, hanem a kiszállítástól kezdve minden szervercsomagban benne van, a KVM root-szervertől a játékszerveren át a dedikált szerverig. A szűrés a 3., 4. és 7. rétegen történik minden TCP- és UDP-porton, tehát a 22003 UDP, a 22005 TCP és a 22126 UDP porton egyszerre. Ez a maincubes adatközpontban működik, Frankfurt am Mainban, Németországban. Hogy mely játékoknak és protokolloknak van saját profilja, azt a Játékszerverek DDoS-védelme valós időben című cikk mutatja meg.

Advanced DDoS Protection a tartósan támadott projekteknek

Egyes projekteket nem alkalmanként ér támadás, hanem heteken át célzottan támadják őket. Erre az esetre való az Advanced DDoS Protection havi 50,00 EUR-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 magból. A szerverét a KernelHost hálózatán belül állítjuk át rá, Önnek a saját oldalán nincs mit átalakítania.
• Önállóan kezelhető védelmi szabályok portonként és protokollonként az ügyfélportálon. Pontosan ez a lényeg az MTA:SA esetében: a 22003 UDP, a 22005 TCP és a 22126 UDP portra külön szabályokat állít be, ahelyett hogy három nagyon különböző szolgáltatást egy kalap alá vennénk.
• A módosítások valós időben lépnek érvénybe, ticket és várakozás nélkül. Tehát egy zajló támadás közepén is tud utánaállítani.
• Az adott játékhoz illő védelmi profil. A Multi Theft Auto saját profilként megvan, ugyanígy a webszerverek, a hangszerverek és a saját TCP- vagy UDP-alkalmazások, amelyek ugyanazon védett cím mögé illeszthetők.

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

A legtöbb MTA:SA-projektnek elegendő a beépített folyamatos védelem egy tiszta szerverkonfigurá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

„Letiltottam a 22126-os portot, a szerver mégsem szerepel egyetlen listában sem, de továbbra is érkeznek lekérdezések”: akkor a socket még nyitva van. Az <ase>0</ase> egymagában nem zárja be a portot, amíg a <donotbroadcastlan>0</donotbroadcastlan> érték be van állítva. Ellenőrizze az ss -lnup | grep 22126 paranccsal, hogy valóban nem figyel-e már semmi.

„A játékosok a betöltőképernyőn ragadnak, maga a játék normálisan fut”: ez nem a 22003-as port elleni támadás, hanem a 22005-ös porton lévő HTTP-szerver a határán. Szervezze ki a letöltéseket a httpdownloadurl segítségével, és ellenőrizze a httpmaxconnectionsperclient és a httpthreadcount értéket.

„A szerver eltűnt a böngészőből, a rajta lévő játékosok nem észlelnek semmit”: akkor kizárólag a 22126-os portot érte. A csatlakozott játékosok számára ez következmények nélküli, az új játékosok beáramlása számára nem. A helyes válasz egy erre az egy portra tett sebességkorlátozás, nem egy a játékportra tett.

„Lecseréltük az IP-címet, és két órával később ismét offline voltunk”: 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 állapotlekérdezéses Discord-botból vagy egy régi DNS-bejegyzésből. Egy címcsere időnyereség, nem megoldás.

„A 22003-as portra címenként és másodpercenként 20 csomagos sebességkorlátot tettünk”: ez túl szűk. Már egyetlen játékos is efölött van aktív szinkronizáció mellett, és az ugyanazon NAT-cím mögötti több játékos ugyanazon a kereten osztozik. Ezzel a saját játékosait dobja ki. A 22126-os porton ezzel szemben a szűk értékek nem jelentenek problémát.

„Tűzfallal kizártuk magunkat”: az újraindítás nem segít, mert az UFW a felállás során visszaállítja a szabályait. A KernelHostnál nyissa meg az ügyfélportálon elérhető VNC-konzolt, és futtassa ott az ufw disable parancsot. A VNC-konzol a vendégrendszer hálózatától függetlenül működik.

„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.

„Egyszerűen kivárjuk a támadást”: azokat a támadásokat, amelyek hatnak, megismétlik. Dokumentálja az időpontot időzónával, a tartamot, a csúcsértékeket és az érintett portot. Pontosan ezekre az adatokra van szüksége egy support-ticketnek is, hogy a szűrést célzottan utánaigazítsuk.

Röviden összefoglalva

• Egy MTA:SA-szervernek pontosan három portra van szüksége: 22003 UDP a játékhoz, 22005 TCP a belső HTTP-szerverhez és 22126 UDP az ASE-lekérdezéshez. A harmadik fixen a játékport plusz 123 értékéből adódik.
• Az ASE-lekérdezés saját porton ül, ezért anélkül korlátozható, hogy egyetlen játékost is kizárna. Ez a legfontosabb különbség az SA-MP-hez képest, ahol a játék és a lekérdezés ugyanazon a porton osztozik.
• Egyetlen kérésbájt a 22126-os porton akár több kilobájtos választ hoz létre, a feladócím pedig hamisítható. Egy korlátozás nélküli ASE-port így egyszerre célpont és erősítő.
• Az MTA beépített fékei forráscímenként hatnak: öt lekérdezés hat másodperc alatt, négy belépés 30 másodperc alatt. Száznál több egyidejű forráscím esetén a lekérdezések számolása kimarad, egy elosztott áradat tehát átfut.
• A 22005-ös porton lévő belső HTTP-szerver önálló támadási felület. Aki a letöltéseket a httpdownloadurl segítségével külső webszerverre szervezi ki, kiveszi őket a játékmenetből.
• Minden, ami a szerveren fut, csak a kis támadásokról dönt. 1 Gbit/s esetén nagyjából másodpercenként 1,49 millió csomagnál van a vége, függetlenül attól, milyen jók a szabályai.
• A KernelHost kétrétegű folyamatos védelme minden szervercsomagban benne van felár nélkül, és null-routing nélkül dolgozik. Aki portonként maga akarja irányítani a szabályokat, az havi 50,00 EUR-tól hozzáveszi az Advanced DDoS Protection szolgáltatást.

Ha a projektje már a KernelHostnál fut, a szűrés tartósan aktív, Önnek nincs mit bekapcsolnia. Ha mégis rendellenességet észlel, nyisson egy support-ticketet az időszakkal, a porttal és a megfigyelt viselkedéssel, hogy a szabályokat az Ön 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. Ha még máshol hosztol, és rendszeresen érik támadások, a Frankfurt am Mainba való költözés a rövidebb megoldás: az akut esetre vonatkozó további lépések a Súlyos DDoS-támadás: mit tegyünk? című cikkben olvashatók.