Call of Duty szerver védelme DDoS-támadások ellen

Egy Call of Duty szerver védelme a DDoS-támadások ellen a klasszikus címeknél örvendetesen konkrét feladat: pontosan egy UDP-portról, néhány Dvarról a server.cfg fájlban és egy erősítési vektorról van szó, amelyet az engine 2003 óta magával hoz. Az a szerver viszont, amely este a kör közepén egyszerre veszíti el az összes játékosát, ritkán szenved hardverhibától. Többnyire támadás zajlik, méghozzá pontosan akkor, amikor a szerver tele van.

Ez a cikk először azt mutatja meg, mely címekre érvényes egyáltalán, azután azt, mit tud Ön extra költség nélkül maga megvédeni, ezt követően azt, hol érnek véget technikailag ezek az intézkedések, végül pedig azt, minek kell utána a szerver előtti hálózatban történnie. A parancsok Debian 12, Debian 13, Ubuntu 22.04 LTS és Ubuntu 24.04 LTS rendszerre íródtak, és root felhasználót feltételeznek, 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 server.cfg fájlban, és ne indítsa újra a szervert. 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.

Mely Call of Duty címeknél tudja a szerverét DDoS ellen védeni

Call of Duty szervert csak azoknál a címeknél tud DDoS ellen védeni, amelyek saját dedikált szervert engedélyeznek. Ezek a Call of Duty (2003), a Call of Duty United Offensive, a Call of Duty 2, a Call of Duty 4 Modern Warfare és a Call of Duty World at War eredeti kiadásai, ehhez jönnek a közösségi platformok: a Plutonium (World at War, Black Ops, Black Ops II, Modern Warfare 3), az IW4x (Modern Warfare 2) és a CoD4X (Call of Duty 4). Mindezek a címek ugyanazt a mintát hozzák magukkal: egy server.cfg fájlt, egy nyitott UDP-portot és egy bejegyzést egy nyilvános szerverlistában.

A modern részekre ez a cikk kifejezetten nem érvényes. A Warzone, a Modern Warfare (2019), a Black Ops Cold War, a Vanguard, a Modern Warfare II, a Modern Warfare III és a Black Ops 6 nem ismer bérelhető dedikált szervert: a meccsek az Activision matchmaking-infrastruktúráján futnak, nincs server.cfg, nincs szerverböngésző és nincs olyan port, amelyet engedélyezhetne vagy bebiztosíthatna. Azok a portlisták, amelyeket az Activision ezekhez a címekhez közzétesz (többek között TCP 3074 és 27014-től 27050-ig, valamint UDP 3074, 3478 és 27000-től 27031-ig), kliens- és platformportokat írnak le, nem szerverportokat. Akinek a Warzone-ban kapcsolatmegszakadásai vannak, annak a saját vonalán van a gondja vagy az Activisionnél, de nem olyan, amelyet egy bérelt szerver megoldana.

Miért pont a Call of Duty szervereket támadják

A Call of Duty szerverek négy olyan tulajdonságot egyesítenek, amely kényelmes célponttá teszi őket. Először: minden listázott szerver maga teszi közzé a címét, a szerverlistában szereplő bejegyzés nyílt szövegben tartalmazza az IP-címet és a portot, különben senki nem tudna belépni. Másodszor: a teljes forgalom UDP-n keresztül megy, az UDP pedig nem ismer olyan kapcsolatfelépítést, amelyet meg lehetne követelni, a feladócímek hamisíthatók. Harmadszor: az engine mindenkinek megválaszolja az állapotlekérdezéseket anélkül, hogy bárkinek el kellene indítania a játékot. Negyedszer: az RCON távoli irányítás ugyanazon a porton ül, mint maga a játék.

Ehhez jön a szociális rész: kitiltott játékosok, klánok közötti konkurencia, viszály egy közösségben, amely évek óta ismeri egymást. Egy támadás a kiváltójának sem tudást, sem említésre méltó pénzt nem kerül, az úgynevezett bootereket és stressereket havi néhány euróért előfizetésként adják, és a játékszervereken keresztüli erősítéses támadások ott az alapkínálat részei. 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.

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

Egy klasszikus Call of Duty szerver pontosan egy UDP-portot foglal el, mégpedig a 28960-at. Ezen az egy porton három dolog fut egyidejűleg: a játékforgalom, a szerverlista állapotlekérdezései és az RCON távoli irányítás. Külön lekérdezési port és külön RCON-port nincs. Egy dedikált szerver indítósora minden címnél ugyanúgy néz ki, csak a végrehajtható fájl neve különbözik:

+set dedicated 2 +set net_ip 0.0.0.0 +set net_port 28960 +set sv_maxclients 32 +exec server.cfg +map_rotate

A mesterszerver-portok nem tartoznak az Ön tűzfalengedélyezései közé. A 20810 és a 20800 célport a túloldalon, nem figyelőport az Ön gépén: az Ön szervere magától szólítja meg a listát. Sok portengedélyezési útmutató mégis azt javasolja, hogy bejövő irányban nyissa meg őket. Ez minden ellenérték nélkül növeli a támadási felületet.

Szokásos nagyságrendek a Call of Duty esetében

A második táblázat a fontosabb, ha fel akarja mérni, hogy egyedül is kézben tudja-e még tartani. Egy tele szerver normál terhelését állítja szembe azokkal a számokkal, amelyekről egy támadás esetén szó van.

Miért fekszik a játék, a lekérdezés és az RCON ugyanazon a porton

Ez a Call of Duty szempontjából döntő sajátosság. Az id Tech 3 engine, amelyre az összes klasszikus Call of Duty cím épül, nem ismer külön portot a játék, a lekérdezés és a távoli irányítás számára. Minden az úgynevezett kapcsolat nélküli csomagokon keresztül fut azon az egy UDP-porton. A kapcsolat nélküli csomag olyan UDP-csomag, amely négy 0xFF bájttal kezdődik, és utána nyílt szövegben viszi a parancs nevét: getstatus, getinfo, getchallenge, connect vagy rcon.

A gyakorlati következmény kényelmetlen: az RCON-t tűzfallal nem tudja leválasztani a játékról anélkül, hogy a játékot is bezárná. Egy szabály a 28960-as porton mindig mindent eltalál. Aki a lekérdezési áradatokat és az RCON-támadásokat célzottan akarja kiszűrni, annak a csomag tartalmába kell néznie, nem csak a portszámra. Pontosan ezért érnek a portalapú tűzfalszabályok a Call of Duty esetében hamarabb a határukhoz, mint az olyan játékoknál, amelyeknek külön lekérdezési portja van.

Mi a getstatus-reflexió a Call of Duty esetében?

A getstatus-reflexió olyan erősítéses támadás, amelynél a támadó kis állapotlekérdezéseket küld hamisított feladócímmel sok játékszervernek, hogy azok lényegesen nagyobb válaszai a tényleges áldozatnál érkezzenek meg. A játékszerverek ilyenkor nem a célpont, hanem az erősítő. Ez a vektor az id Tech 3 engine esetében több mint egy évtized óta dokumentált, és a Call of Dutyt ugyanúgy érinti, mint a Quake 3-at és annak többi leszármazottját.

Két irányból éri Önt. Megtámadottként a getstatus-kérések áradatát kapja, amely számítási időt és kimenő sávszélességet fogyaszt, a játékosai pedig lag-tüskékként észlelik. Akaratlan erősítőként Ön küld válaszokat egy idegen áldozatnak, és az abuse-bejelentés Önnél landol. Mindkettő ugyanazon a porton történik, ugyanazokkal a csomagokkal, és mindkettő először ártalmatlannak látszik a kihasználtsági grafikonon.

Hogyan néz ki egy getstatus-csomag

A kérés négy 0xFF bájtból és a getstatus szóból áll, összesen 13 bájt hasznos adat. IP- és UDP-fejléccel együtt ez 41 bájt a vonalon. Pontosan erre céloz a hosszellenőrzés azokban a tűzfalszabályokban, amelyek évek óta járnak körbe a Call of Duty fórumokon:

iptables -A INPUT -p udp -m length --length 41:45 -m recent --set --name getstatus_cod
iptables -A INPUT -p udp -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP

A válasz összehasonlíthatatlanul nagyobb. Egy statusResponse a teljes szerverkonfigurációt karakterláncként tartalmazza, plusz egy sort minden csatlakozott játékosról, tele szerver esetén tehát több kilobájtot. A CISA a Quake hálózati protokollt az UDP-erősítéses támadásokról készített áttekintésében (TA14-017A) 63,9-es erősítési tényezővel vezeti, és visszaélésre használt parancsként kifejezetten a szerverinformációk kicserélését nevezi meg. Így 1 Mbit/s hamisított kérésből körülbelül 64 Mbit/s lesz az áldozatnál. Összehasonlításként: a DNS ugyanebben az áttekintésben 28 és 54 között áll, az NTP 556,9-en.

A beépített fék: sv_queryIgnoreTime és sv_queryIgnoreMegs

A Call of Duty 4 az 1.7-es szerververzió óta beépített lekérdezési fékkel rendelkezik. Megjegyez minden címet, amely állapotlekérdezést küldött, és ugyanattól a címtől érkező további lekérdezéseket egy beállítható időre figyelmen kívül hagy. Ezt négy Dvar irányítja, a következő alapértékekkel:

sv_queryIgnoreMegs        1
sv_queryIgnoreTime        2000
sv_queryBounceIgnoreTime  12000
sv_queryIgnoreDebug       0

Az sv_queryIgnoreMegs határozza meg, mennyi memóriát foglalhat a figyelmen kívül hagyott címek listája. 1 megabájt körülbelül 65 000 címet fog be, minden további megabájt nagyjából 87 000 továbbit. A 0 érték teljesen kikapcsolja a féket, és pontosan ez a helyzet sok szerveren, mert a konfiguráció egy régi sablonból származik. Az sv_queryIgnoreTime a tiltási idő milliszekundumban. Az sv_queryBounceIgnoreTime akkor érvényesül, amikor a válasz „ICMP Port Unreachable” hibával jön vissza, tehát pontosan akkor, amikor az Ön szerverét éppen erősítőként használják ki egy idegen áldozat ellen. Az sv_queryIgnoreDebug 1 naplóba írja a találatokat, hogy egyáltalán lássa, történik-e valami.

Aki CoD4X-et használ, annak ezen felül fix felső korlátok vannak a szerverkódban: legfeljebb 20 getstatus-válasz 20 másodpercenként, legfeljebb 100 getinfo-válasz 100 másodpercenként és legfeljebb egy RCON-hibaüzenet 100 milliszekundumonként. A forráskódban lévő megjegyzés világosan megnevezi a szándékot: a szervert hagyják nyugodtan elárasztani, de közben ne fecséreljen kimenő sávszélességet. Ez a helyes prioritás, de nem helyettesíti a szerver előtti szűrést.

Miért jelent az RCON a Call of Duty esetében történetileg problémát

Az RCON a szerver távoli irányítása, és a Call of Duty esetében titkosítatlan UDP-csomag a játékporton. Egy RCON-parancs így néz ki a vonalon: négy 0xFF bájt, aztán az rcon szó, aztán a jelszó nyílt szövegben, aztán a tulajdonképpeni parancs. Nincs titkosítás, nincs munkamenet, nincs felhasználói fiók és nincs második faktor. Ebből három probléma következik, és mindhárom valós:

• Lehallgatás. Aki az út bármely pontján látja a forgalmat, nyílt szövegben olvassa az Ön RCON-jelszavát. Ez minden hálózatra érvényes Ön és a szerver között, és minden olyan eszközre, amelynek megadja a jelszót.
• Találgatás. Nincs olyan bejelentkezés, amelyet le lehetne tiltani, és nincs fiókzárolás tíz sikertelen kísérlet után. A támadó bármilyen sebességgel végigpróbálja a jelszavakat. Az eredeti szerver ezt egyáltalán nem fékezi, a CoD4X mindössze a választ fékezi le egy hibaüzenetre 100 milliszekundumonként, és a kísérletet „Bad rcon” néven naplózza.
• Reflexió. Egy RCON-hibaüzenet is válasz egy hamisított csomagra. Aki az Ön szerverét hamisított RCON-csomagokkal lövi, kis erősítőként használja, az Ön szervere pedig közben teleírja a naplót.

A gyakorlati következmény: az rcon_password értékét csak akkor állítsa be, ha valóban szüksége van az RCON-ra. Ha igen, akkor hosszúra és véletlenszerűre. A CoD4X legalább nyolc karaktert követel meg, ez alsó korlát és nem javaslat. A hétköznapokban SSH-n és a szerverkonzolon keresztül adminisztráljon, ne RCON-nal a nyílt hálózatból. És ha olyan kezelőeszközt üzemeltet, mint az IW4MAdmin, amely a maga részéről RCON-on keresztül beszél, akkor annak az 1624-es porton lévő webes felülete nem való a nyílt hálózatra.

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 Call of Duty 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?

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:28960 és a [::]:28960 azt jelenti, hogy „az egész internetről elérhető”, a 127.0.0.1:3306 pedig azt, hogy „csak helyben”, és nem kell hozzá tűzfalszabály. A játék mellett gyakran feltűnik ott az IW4MAdmin, egy webszerver a Fast Download számára, egy adatbázis a statisztikákhoz és egy elfelejtett második játékpéldány. A támadó nézőpontját egy kívülről indított portszkennelés adja meg:

nmap -Pn -sU -p 28960-28970,4976,27016 A.SZERVERE.IP.CÍME
nmap -Pn -p- --min-rate 1000 A.SZERVERE.IP.CÍME

2. Csak azt hagyja nyitva, amire a játéknak valóban szüksége van

Egyetlen Call of Duty szerverhez egyetlen kifelé irányuló engedélyezés elegendő, minden más korlátozás alá kerül, vagy egyáltalán nem is 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 28960/udp comment 'Call of Duty'
ufw allow from 203.0.113.10 to any port 1624 proto tcp comment 'IW4MAdmin'
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. Plutonium T6 esetén a 4976/udp lép a 28960/udp helyére, Plutonium IW5 esetén a 27016/udp. Ha több példányt üzemeltet, kizárólag a tényleg használt tartományt engedélyezze, tehát például a 28960:28962/udp tartományt, és ne általánosan a 28960-tól 28970-ig terjedőt. Minden port, amelyen semmi nem figyel, ugyan nem behatolási pont, támadás esetén viszont mégis munkába kerül a kernelnek. 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.

3. A lekérdezési fék bekapcsolása a server.cfg fájlban

Ez a négy sor minden Call of Duty 4 szerver server.cfg fájljába való, és nem kerül másba, mint néhány megabájt memóriába:

set sv_queryIgnoreMegs "4"
set sv_queryIgnoreTime "2000"
set sv_queryBounceIgnoreTime "12000"
set sv_queryIgnoreDebug "0"

4 megabájt körülbelül 326 000 címet fog be, ez egy komoly floodhoz is elég. Az sv_queryIgnoreTime értékét csak óvatosan emelje a beállított 2000 milliszekundum fölé: a szerverlista és minden szerverböngésző ugyanezen a mechanizmuson keresztül kérdezi le a szerverét, és aki túl magasra veszi a tiltási időt, az eltűnik a listából. Az sv_queryIgnoreDebug értékét állítsa átmenetileg 1-re, ha tudni akarja, hogy a fék egyáltalán érvényesül-e, utána pedig újra 0-ra, hogy a napló ne töltse meg a lemezt.

4. A lekérdezési áradatok kiszűrése a tűzfalban

Az engine-ben lévő fék csak azután érvényesül, hogy a csomag elérte a játékfolyamatot. Egy tűzfalszabály korábban dönt, és kevesebbe kerül. Ez a két sor forráscímenként korlátozza a getstatus kéréseket:

iptables -A INPUT -p udp --dport 28960 -m length --length 41:45 -m recent --set --name cod_query --rsource
iptables -A INPUT -p udp --dport 28960 -m string --algo bm --string "getstatus" -m recent --update --seconds 2 --hitcount 4 --name cod_query --rsource -j DROP

Az első sor megjegyez minden forráscímet, amely egy állapotlekérdezés tipikus hosszában küld csomagot. A második eldob minden további getstatus-kérést, amint ugyanaz a cím két másodperc alatt négynél többet küldött belőle. Négy kérés két másodpercenként minden szerverböngészőnek elegendő. A fórumokon 20 kérés másodpercenkénti változatok is keringenek, amelyek lényegesen bőkezűbbek, és inkább a durva botok ellen hatnak, mint egy tiszta reflexiós hullám ellen.

A tiszta iptables-szabályok egy újraindítás után eltűnnek, Debian és Ubuntu alatt így mentjük őket:

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

UFW alatt az ilyen szabályok az /etc/ufw/before.rules fájlba valók, mert egyébként a következő ufw reload parancsnál eltűnnek. Utána ellenőrizze az iptables -L INPUT -n -v paranccsal, hogy emelkednek-e a találati számlálók. Ha nullán maradnak, a szabályt nem éri el a forgalom.

5. Az RCON kikapcsolása vagy szoros vezetése

A legbiztonságosabb RCON-hozzáférés az, amelyik nem létezik. Egy üres rcon_password minden RCON-csomagot elutasít:

set rcon_password ""

Ügyeljen közben egy finomságra: a szerver ilyenkor is válaszol, mégpedig hibaüzenettel, és ezzel kis erősítő marad. Aki ezt ki akarja zárni, és amúgy is csak egy fix címről használja az RCON-t, az előbb eldobja a csomagokat:

iptables -A INPUT -p udp --dport 28960 ! -s 203.0.113.10 -m string --algo bm --string "rcon " -j DROP

Ennek a szabálynak van egy mellékhatása, amelyet ismernie kell: az rcon karakterlánc elméletileg egy csatlakozott játékos csevegőcsomagjában is felbukkanhat, és a csomagot akkor szintén eldobná. A gyakorlatban ez elviselhető. Aki nem akarja a mellékhatást, az kihagyja a szabályt, és csak üres vagy nagyon hosszú jelszóval dolgozik.

6. A csatlakozási flood és a férőhelyek kimerítésének kivédése

A csatlakozási flood nem a vonalra céloz, hanem a játéklogikára: a támadó gyors sorozatban getchallenge- és connect-csomagokat küld, amíg minden férőhely félbemaradt kapcsolatokkal van tele. A valódi játékosok ekkor a „Server is full” üzenetet kapják, noha a játékban senki nem áll. Ez ellen a következő beállítások hatnak:

set sv_maxclients "32"
set sv_reconnectLimit "3"
set sv_floodProtect "1"
set sv_connectTimeout "30"
set sv_timeout "120"

Az sv_reconnectLimit korlátozza, milyen gyakran kapcsolódhat újra ugyanaz a játékos egymás után. Az sv_floodProtect korlátozza, hány kliensparancsot dolgoz fel a szerver játékosonként, és ezzel megakadályozza, hogy egyetlen kliens kommandókkal lefékezze a szervert. Az sv_connectTimeout és az sv_timeout határozza meg, mennyi ideig blokkol egy férőhelyet egy félbemaradt, illetve egy hallgató kapcsolat: aki itt bőkezű értékeket hagy egy régi sablonból, az könnyűvé teszi a támadónak a férőhelyek kimerítését.

CoD4X esetén ehhez jön az sv_authorizemode. Az 1 érték csak érvényes példánnyal rendelkező játékosokat engedi be, a 0 csak a nélkülieket, a -1 pedig mindkettőt. Aki 1-et állít be, az kizárja az eldobható kliensek nagy részét, de elveszíti az eredeti példány nélküli valódi játékosokat is. A legkeményebb eszköz a szerverjelszó a g_password segítségével, amely minden ellen hat, ami a szabályos csatlakozási utat használja. És egy dolognak világosnak kell lennie: a jelszó 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 szerverlista-bejegyzés és az Ön saját címe

Itt megéri az őszinteség a vágyálom helyett: az Ön IP-címét nem lehet titokban tartani. Minden játékos, aki egyszer csatlakozva volt, ismeri, a listabejegyzés pedig amúgy is közzéteszi, a porttal együtt. A bejegyzést kikapcsolhatja azzal, hogy a server.cfg fájlban nem állít be mesterszervert (a Dvarok neve sv_master1, sv_master2 és így tovább). Ez viszont az új játékosok felé minden láthatóságba kerül, és csak a legkényelmesebb támadók ellen segít.

Egy megjegyzés a listák helyzetéről: az Activision eredeti mesterszerverei (codmaster.activision.com a 20510-en, cod2master.activision.com a 20710-en, cod4master.activision.com a 20810-en) a régi címek számára már semmit nem válaszolnak meg. Aki ma listázva akar lenni, az a közösségi listákat használja: a CoD4X sajátot üzemeltet, és ehhez tokent követel az sv_authtoken értékében, a Plutonium pedig saját szerverlistát hoz magával. Magán a dolgon ez semmit nem változtat, a cím ott ugyanúgy nyílt szövegben áll.

Két szokás mégis hatásos. Ne tegye közzé maga a nyers IP-címet sehol, tehát ne a Discord-csatornán és ne a klánoldalon. És a játékosait hosztnéven keresztül kapcsolja, hogy vészhelyzetben cserélhesse a címet anélkül, hogy minden hivatkozás eltörne. A klasszikus hiba ilyenkor egy elfelejtett A-rekord a régi címre: ez minden cserét hatástalanná tesz.

8. A webes felületek, az adatbázis és a Fast Download kivétele a nyílt hálózatból

A játék mellett a legtöbb Call of Duty szerveren még több is fut: az IW4MAdmin a webes felületével az 1624-es porton, egy webszerver a pályák Fast Download-jához, néha egy adatbázis a statisztikákhoz. Mindegyik ilyen szolgáltatás önálló támadási felület, és egyik sem való korlátlanul a nyílt hálózatra.

Korlátozza az 1624-es portot a saját címére, vagy érje el a felületet SSH-továbbításon keresztül, és nyissa meg utána helyben a http://127.0.0.1:1624 címet:

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

Az adatbázist kösse a 127.0.0.1 címhez, a nyílt hálózatban semmi keresnivalója. A Fast Downloadot pedig tegye saját webszerverre a játékfolyamat helyett: egy terhelés alatt lévő webszerver máskülönben pontosan azt a számítási időt veszi el a játéktól, amelyre a szimulációhoz szüksége van.

9. Naplózás, hogy vészhelyzetben 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 négy parancs elegendő:

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

A Call of Duty esetében van egy ötödik, amely a döntő kérdésre válaszol. Ez a felvétel kizárólag a kapcsolat nélküli csomagokat mutatja, tehát pontosan a getstatus, getinfo, getchallenge, connect és rcon parancsokat:

tcpdump -ni eth0 'udp port 28960 and udp[8:4] = 0xffffffff' -c 200 -A

Ha ott százszor szerepel a getstatus mindig új címekről, akkor lekérdezési áradata van. Ha ott rcon szerepel, valaki az Ön jelszavát próbálja kitalálni. Ha csak getchallenge és connect szerepel, akkor csatlakozási flood. A tcpdump parancsra 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 hogyan értékelje ki, arról a DDoS-támadás felismerése című cikk szól.

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 tele, 32 helyes szerver kimenő irányban körülbelül 6,4 Mbit/s-ot termel, ez kevesebb, mint egy gigabites vonal egy százaléka. Ugyanez a vonal megtelik, amint valaki 125 megabájtot küld másodpercenként, és pontosan erre vannak kitalálva azok a támadások, amelyeket havi tíz euróért meg lehet rendelni. Hogy az Ön iptables-szabálya mögötte jó-e, akkor már nem játszik szerepet, mert a játékosai csomagjai már előtte sem jutnak át.

A második mennyiség a csomagsebesség, és a Call of Duty esetében rendszeresen hamarabb üt be, mint a sávszélesség. Kis, 64 bájtos csomagok esetén egy 1 Gbit/s-os vonalba körülbelül 1,49 millió csomag fér másodpercenként. Egy normál szerverkernel processzortól és hálózati kártyától függően néhány százezret dolgoz fel ebből, mielőtt eldobni kezdene. Egy getstatus-kérés 41 bájttal még ennél is kisebb: egy támadás, amely a vonalát még harmadáig sem tölti meg, mégis megbénítja a szerverét, mert a teljes számítási idő az eldobásra megy el. Az üzemeltetők ezt úgy élik meg, hogy „a kihasználtság nem is volt magas, mégis minden eltűnt”.

A Call of Duty esetében ehhez jön egy sajátosság, amely élesíti a számítást. Mivel a játék, a lekérdezés és az RCON ugyanazon a porton fekszik, a 28960-as portot vészhelyzetben nem tudja bezárni: az ugyanaz lenne, mint kikapcsolni a szervert. És mivel az engine minden állapotlekérdezésre a kérés méretének többszörösével válaszol, a támadó ugyanahhoz a hatáshoz kevesebb saját sávszélességet fogyaszt, mint más játékoknál.

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 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 ezzel szembe a KernelHost

A folyamatos védelem, amely minden szerveren 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 reagálnia egy támadásra, tehát nincsenek percek az elején, amikor a szerver elérhetetlen. És nem alkalmazunk null-routingot: 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 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 lőtt projektekhez

Egyes klánokat és közösségeket 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 é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, amelyre a szerverét a saját hálózatunkban átállítjuk. Az Ön oldalán nincs szükség átalakításra.
• Önállóan kezelhető védelmi szabályok portonként és protokollonként az ügyfélportálon: Ön állítja be, mi engedélyezett a 28960 UDP porton, anélkül hogy ehhez ticketet kellene írnia, több példány esetén pedig portonként külön.
• 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.
• Az adott játékhoz illő védelmi profil, módosított és saját alkalmazásokhoz is, bármilyen TCP- vagy UDP-porton. Ez a Plutonium és a CoD4X esetében a fontos pont, mert azok portjai eltérhetnek az alapértékektől.

Az Advanced DDoS Protection azokhoz a szerverekhez szól, amelyek a KernelHostnál állnak. Ha az Ön Call of Duty szervere jelenleg máshol fut, és ott rendszeresen kiveszik a hálózatból, akkor a KernelHostra költözés az az út, amely változtat valamit.

A két szint összehasonlítása

A legtöbb Call of Duty szervernek elegendő a beépített folyamatos védelem egy tiszta server.cfg fájllal 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

„Lecseréltem az IP-címet, és két órával később ismét offline voltam”: a támadó az új címet ugyanabból a forrásból kapta meg, mint a régit, többnyire a listabejegyzésből, egy állapotkijelzős Discord-botból vagy egy régi DNS-rekordból. Egy címcsere időnyereség, nem megoldás.

„A szolgáltatóm abuse-bejelentést küld nekem, noha én vagyok az áldozat”: akkor az Ön szervere nem a célpont, hanem az erősítő. Valaki hamisított getstatus-kéréseket küld, az Ön szervere pedig szorgalmasan válaszol egy idegen áldozatnak. Először ellenőrizze, hogy az sv_queryIgnoreMegs 0 értéken áll-e, és állítsa be a négy lekérdezési Dvart, valamint a 4. szakaszban szereplő tűzfalszabályt.

„A szerver teltként szerepel a listában, de üres”: ez csatlakozási flood, és a játéklogikát találja el, nem a vonalat. Ez ellen az sv_reconnectLimit, az sv_connectTimeout és az sv_timeout rövidebb értékei, kétség esetén pedig egy szerverjelszó hat.

„A szerver a támadás közben eltűnik a szerverlistából”: ez a következmény, nem az ok. A szerverlista ugyanezeken az állapotlekérdezéseken keresztül ellenőrzi, hogy él-e az Ön szervere. Ha a válaszok nem jutnak át, vagy a saját féke dobta el őket, a szerver offline-nak számít. Ellenőrizze, hogy az sv_queryIgnoreTime nem áll-e túl magasan, mielőtt a tűzfalat gyanúsítja.

„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 segít a netfilter-persistent save vagy egy bejegyzés az /etc/ufw/before.rules fájlban); 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 szerver fut, de minden játékosnak lag-tüskéi vannak”: először a hálózati interfész csomagsebességét nézze meg, ne a processzorterhelést. Ha a sar -n DEV 1 10 feltűnésmentes marad, és mégis akadozik, az ok többnyire egy mod, egy túlzott sv_maxRate érték, vagy egyszerűen túl sok bot a körben.

„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 szeretett volna. Használja ilyenkor az ügyfélportálon elérhető VNC-konzolt, amely a vendégrendszer hálózatától függetlenül működik.

Röviden összefoglalva

• Egy klasszikus Call of Duty szervernek pontosan egy nyitott portra van szüksége: 28960 UDP. Plutonium T6 esetén ez 4976 UDP, Plutonium IW5 esetén 27016 UDP.
• A játék, az állapotlekérdezés és az RCON a Call of Duty esetében ugyanazon a porton fekszik. Az RCON-t portszabállyal nem tudja leválasztani a játékról, ehhez olyan szabály kell, amely a csomag tartalmába néz.
• A getstatus-reflexió a játékra jellemző erősítési vektor: 41 bájt a kérés, a CISA TA14-017A figyelmeztetése szerint 63,9-es tényező a Quake hálózati protokollnál, tehát körülbelül 2600 bájt a válasz.
• Kapcsolja be a lekérdezési féket: sv_queryIgnoreMegs 4, sv_queryIgnoreTime 2000, sv_queryBounceIgnoreTime 12000. Sok szerveren 0 értéken áll, tehát ki van kapcsolva.
• Az rcon_password értékét csak akkor állítsa be, ha valóban szüksége van az RCON-ra: a jelszó titkosítatlanul megy át UDP-n, és fiókzárolás nélkül bármennyi alkalommal kitalálható.
• A 20810-es és a 20800-as mesterszerver-port kimenő célport, és nem tartozik az Ön bejövő engedélyezései közé.
• Körülbelül 1 Gbit/s vagy néhány százezer csomag másodpercenkénti sebesség fölött kizárólag a szerver előtti hálózat dönt, nem már az Ön konfigurációja.

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.