Team Fortress 2: TF2-szerver védelme DDoS-támadások ellen

Ha egy Team Fortress 2 közösségi szerver esténként, a kör kellős közepén veszíti el egyszerre az összes játékost, majd percekre eltűnik a szerverböngészőből, annak ritkán hardverhiba az oka. Az esetek többségében támadás fut a 27015/UDP porton. Ez a cikk megmutatja, hogyan védi meg a TF2-szervert a DDoS-támadásoktól: először azt, amit a következő tíz percben többletköltség nélkül saját maga is megtehet, utána azt a pontot, ahol ezek az intézkedések fizikailag véget érnek, végül azt, aminek ezután a szerver előtt, a hálózatban kell történnie.

Minden adat a SteamCMD-vel telepített Source dedikált szerverre (srcds_run -game tf) vonatkozik Debian 12, Debian 13, Ubuntu 22.04 LTS vagy Ubuntu 24.04 LTS alatt. A parancsok root felhasználóra készültek, normál felhasználóként tegyen eléjük sudo parancsot. Ha a támadás éppen fut: előbb ne változtasson semmin, és ne indítsa újra a szervert, hanem mentse el a 9. szakasz mérési értékeit. A támadás után már nem lesznek meg.

Miért van szükségük a Team Fortress 2 szervereknek DDoS-védelemre

A Team Fortress 2 2011 óta ingyenesen játszható, és pontosan ez tolja el a támadás gazdaságtanát. A támadónak korlátlan számú eldobható fiókja van, egyikért sem kell fizetnie, és egy kitiltással semmit nem kockáztat. Ami egy fizetős játéknál pénzbe kerül, itt egy percbe.

Ehhez jön egy sajátosság, amely a TF2-t a legtöbb más játéktól megkülönbözteti: a 2016 júliusi „Meet Your Match” frissítés óta nincs Quickplay, amely az új játékosokat automatikusan elosztotta a közösségi szerverek között. Az új játékosok Casual módban a Valve szerverein kötnek ki. A közösségi szerverek kizárólag a szerverböngészőn keresztül találhatók meg. Aki kiesik ebből a listából, az az új játékosok számára gyakorlatilag nem létezik, még akkor sem, ha a szerverfolyamat kifogástalanul fut. Az a támadás tehát, amely csak kiszorítja a szerverét a listából, már elérte a célját.

A tipikus célpontok ennek megfelelően a következők: tartósan futó közösségi szerverek törzsjátékosokkal (nonstop 2Fort, Trade, Jailbreak, Surf, Dodgeball, Mann vs. Machine), ligaszerverek fix meccsidőponttal az ETF2L, az RGL és az ozfortress versenyrendszerében, valamint olyan szerverek, amelyek üzemeltetője éppen kitiltott valakit. A kiváltó ok szinte soha nem technikai. Hogy egyáltalán mi a DDoS-támadás, azt a Mi az a DDoS-támadás? című cikk magyarázza el.

Azok a portok, amelyekről egy TF2-szervernél valójában szó van

Egy TF2-szervernek kifelé pontosan egy portra van szüksége: 27015/UDP. Minden más vagy kikapcsolható, vagy korlátozás alá tartozik, vagy amúgy is csak kimenő irányban működik. Ez a táblázat az alapja minden alábbi tűzfalszabálynak:

Ha egy gépen több példány fut, a számok felfelé lépnek: 27016, 27017 és így tovább a játékhoz, 27021 és 27022 a SourceTV-hez. A konfigurációs fájl a tf/cfg/server.cfg helyen található, és a szerver minden pályaváltáskor újraolvassa.

Miért a megosztott 27015-ös port a legérzékenyebb pont

A TF2-nél a játékforgalom és a szerverlekérdezés ugyanazon az UDP-porton osztozik, külön lekérdezőport nincs. Egy A2S_INFO-kérés pontosan 25 bájt hosszú: négy bájt FF FF FF FF, egy bájt 0x54 és a 20 bájtos „Source Engine Query” karakterlánc lezáró nullával. A válasz a szervernévvel, a pályával, a játékosszámmal és a címkékkel ennek a többszöröse. A CISA, az Egyesült Államok illetékes hatósága a TA14-017A riasztásban 5,5-re teszi a Steam-protokoll erősítési tényezőjét.

Mivel az UDP nem ismer kapcsolatfelépítést, és a forráscímek hamisíthatók, ez évekig nyitott erősítési rés volt: a támadó idegen Source-szervereket kérdezett le az áldozata címével mint feladóval, a szerverek pedig az áldozatnak küldték a válaszaikat. Az A2S_PLAYER és az A2S_RULES mindig is előzetesen lekért ellenőrző értéket igényelt, az A2S_INFO nem. A Valve csak 2020 decemberében szerelt fel az A2S_INFO-hoz is ilyen ellenőrző értéket: a szerver a válasz helyett S2C_CHALLENGE üzenetet küldhet vissza, amelyet a lekérdezőnek meg kell ismételnie, és ezzel bizonyítja, hogy nem hamisította a forráscímét.

Ez tompítja a reflexiót, de nem vet véget a bosszúságnak. Minden lekérdező csomag továbbra is megérkezik önhöz, és számítási időbe kerül, mielőtt megválaszolják vagy eldobják. Az a támadó pedig, aki közvetlenül árasztja el a szerverét, amúgy sem szorul erősítésre.

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

Ez a szakasz a leghosszabb, és ez szándékos. Egy tisztán beállított TF2-szerver a saját erejéből kibírja a kis és közepes támadásokat, függetlenül attól, hol üzemel.

1. Helyzetfelmérés: mi figyel, és milyen indítósorral

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 -lntup

Minden, ami a 127.0.0.1 vagy a ::1 címhez kötődik, nem igényel engedélyezést. Minden, ami a 0.0.0.0 vagy a [::] címen figyel, elérhető az internetről, így az a MySQL-adatbázis is, amelyet egy statisztikai bővítmény hozott magával, és az a webszerver, amelyen a FastDL-fájljai vannak. Vesse össze az eredményt az indítósorával:

./srcds_run -game tf -console \
  -port 27015 -steamport 26901 -nohltv \
  +maxplayers 24 +map ctf_2fort +sv_pure 1 \
  +sv_setsteamaccount SAJAT_GSLT_TOKEN

Ebben a sorban minden port tudatos döntés. Hogy az alapot hogyan kell telepíteni, azt a Játékszerver telepítése SteamCMD-vel című cikk írja le.

2. Csak azokat a portokat hagyja nyitva, amelyekre a TF2 valóban rászorul

Egy nyilvános TF2-szervernek kifelé pontosan egy engedélyezésre van szüksége, plusz az RCON-ra a saját címéről. UFW-vel, mégpedig ebben a sorrendben, hogy ne zárja ki saját magát:

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'TF2 játék és A2S'
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

Cserélje ki a 203.0.113.10 címet a sajátjára. A SourceTV szándékosan nem szerepel itt: aki nem közvetít, az a -nohltv kapcsolóval indul, és a 27020/UDP portot el sem foglalja. Ez felezi egy TF2-szerver kívülről elérhető UDP-felületét. Ha ligameccseket közvetít, hozzájön az ufw allow 27020/udp, és akkor a tv_password beállítása is odatartozik.

A teljes útmutató a mentőú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énne: a KernelHost KVM root-szervereit és dedikált szervereit az ügyfélfiók VNC-konzolján keresztül éri el, amely a vendégrendszer hálózatától függetlenül működik.

3. Az A2S-lekérdezések korlátozása anélkül, hogy kiesne a szerverböngészőből

Itt rejlik ennek a témakörnek a legdrágább hibája: a 27015/UDP átfogó lezárása vagy durva sebességkorlátozása kidobja a saját játékosait, és a támadó szándéka szerint vet véget a támadásnak. Mivel a játékforgalom és a lekérdezés ugyanazt a portot foglalja, a határnak a csomagfajták között kell húzódnia, nem a porton.

A motor három konzolváltozót hoz magával erre, amelyek a tf/cfg/server.cfg fájlba valók:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

Az első a forráscímenként megválaszolt lekérdezéseket korlátozza, a második az összes címre vett összeget, a harmadik pedig másodpercben adja meg az átlagolási ablakot. Attól védik a CPU-t, hogy feleslegesen gyártson válaszokat. Az alapértékek játékonként és build szerint különböznek, a szerverkonzolban a find sv_max_queries mutatja meg, mely értékeket ismeri a szervere.

A második érték a kényes a TF2-nél: ez az összes címre vonatkozó válaszokat fedi le. Ha túl alacsonyra állítja, a szervere egy lekérdezésözön alatt a listaszolgáltatások kéréseit sem válaszolja meg többé, és eltűnik a szerverböngészőből, vagyis az egyetlen útról, amelyen az új játékosok megtalálhatják. Kezdjen bőkezűen, és csak akkor húzza szorosabbra, amikor már mérni tudja, hogy a jogos lekérdezések átjutnak.

Egy réteggel lejjebb ugyanez a forgalom tisztán leválasztható. A Source motor minden kapcsolat nélküli csomagja négy beállított bájttal kezdődik (0xffffffff), a már csatlakozott játékosok forgalmának nincs ilyen fejléce. Pontosan erre helyezhető sebességkorlátozás forráscímenként, anélkül hogy a játékforgalomhoz hozzányúlna:

table inet tf2 {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

A fájlt az nft -f paranccsal tölti be. A -10 prioritás gondoskodik arról, hogy a szabály az UFW szűrőlánca előtt érvényesüljön, a @th,64,32 pedig az UDP-fejléc mögötti első négy bájtot olvassa ki.

4. A darabolt csomagok özönének elfogása, amely a naplóban NET_GetLong néven jelenik meg

Ez a támadás a Source motor sajátossága, és a TF2-t különösen érinti, mert a TF2 a mai napig a régi motorágon fut. A szokásos, kapcsolat nélküli csomagok mellett a motor ismeri a darabolt csomagokat is: ezek a FF FF FF FF helyett FE FF FF FF jelzéssel kezdődnek, és azt jelentik be, hogy egy nagyobb üzenet érkezik több részletben. A szervernek el kell tárolnia a részeket, és meg kell várnia a többit.

Pontosan ez használható ki. A támadó tömegesen küld bejelentett, de soha be nem fejezett részcsomagokat hamisított forráscímekkel. A CPU-terhelés nő, a játék akadozik, a szervernaplóban pedig szaporodnak a NET_GetLong bejegyzést tartalmazó sorok. Ehhez egyetlen gép is elég, sávszélességre alig van szükség. Az üzemeltetők ezt rendszeresen DDoS-támadásként jelentik, pedig a vonal szinte üres.

Mivel egy szabályos TF2-kliensnek aligha van oka darabolt csomagokat küldeni a szervernek, itt a szoros korlátozás vállalható:

udp dport 27015 @th,64,32 0xfffffffe \
    meter tf2split { ip saddr limit rate over 5/second burst 10 packets } drop

A sor ugyanabba a láncba való, mint a 3. szakasz szabálya. A kliensoldali feltöltések egyik kevés jogos okát ezen felül az sv_allowupload 0 beállítással veszi ki a játékból (lásd a 7. szakaszt).

5. Az RCON kivétele a nyílt hálózatból

A Source motor RCON-protokollja a jelszót olvasható formában továbbítja TCP-n. Aki le tudja hallgatni az ön és a szerver közötti utat, annak ezután megvan az RCON-jelszava, akinek pedig RCON-ja van, az pályát válthat, kitilthatja az összes játékost és leállíthatja a szervert. Ez nem DDoS-probléma, hanem átvétel, de rendszeresen támadásként jelentik.

Az rcon_password értékét soha ne hagyja üresen, és soha ne válasszon kitalálhatót, az openssl rand -base64 32 kimenete elegendő. Ehhez tartozik egy fék a bejelentkezési kísérletek ellen:

rcon_password "IDE_A_VELETLEN_ERTEK"
sv_rcon_maxfailures 3
sv_rcon_minfailures 3
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Ezzel a szerver három, 30 másodpercen belüli sikertelen kísérlet után 24 órára kitiltja az adott címet, a find sv_rcon pedig megmutatja, mely változókat ismeri a buildje. Ennek ellenére hatásosabb marad a 2. szakasz tűzfalszabálya, mert az a kísérletet el sem engedi az alkalmazásig. A váltakozó helyekről történő hozzáféréshez állítson be helyi továbbítást SSH-n keresztül, és utána a 127.0.0.1 címen szólítsa meg az RCON-t:

ssh -N -L 27015:127.0.0.1:27015 root@A.SZERVER.IP.CIME

6. A sebességek megfogása és a hibernálás bekapcsolva hagyása

A Team Fortress 2 fixen 66,67 tickkel fut másodpercenként. Hogy ebből mennyi forgalom lesz, azt nem a tick dönti el, hanem az, amit egyetlen kliens kérhet. Felső korlát nélkül minden játékos annyit hoz le, amennyit a kliense kér, és ezt ön a kimenő sávszélességével fizeti meg:

sv_minrate 50000
sv_maxrate 100000
sv_mincmdrate 40
sv_maxcmdrate 66
sv_minupdaterate 40
sv_maxupdaterate 66

Számolja végig egyszer: az sv_maxrate 100000 értéknél minden játékos 100 kilobájtot tölthet le másodpercenként, 24 helyen ez másodpercenként 2,4 megabájt, vagyis nagyjából 19 Mbit/s kimenő irányban. Ha az sv_maxrate 0 értéket állítja be, nincs felső korlát. A ligaszerverek ezt tudatosan teszik, egy sok helyes nyilvános szerver ne tegye. Azok a bővítmények, amelyek feloldják a tickrátát, megsokszorozzák a játékosonkénti csomagsebességet, és vele ugyanezt a számítást.

A második pontot gyakran elrontják. A TF2 elalszik, amint senki nincs csatlakozva, és ebben az állapotban szinte semmi CPU-t nem használ. Sok üzemeltető ezt kikapcsolja, hogy a szerver „ébrennek” érződjön. Egy több példányt futtató gépen ez azt jelenti, hogy a CPU már üresjáratban is terhelt, és a támadás egy eleve teli rendszert talál. Hagyja meg az alapbeállítást:

sv_hibernate_when_empty 1
sv_hibernate_postgame_delay 5
tf_allow_server_hibernation 1

7. A FastDL leválasztása és a feltöltések kikapcsolása

A közösségi szerverek saját pályákból élnek, és pontosan ebből fakad egy második támadási felület. Az sv_downloadurl nélkül minden játékos a játék hálózati csatornáján tölti le a tartalmakat, tehát ugyanazon a porton és ugyanabban a folyamatban, amely közben a meccset is számolja. Ez másodpercenként néhány kilobájt, egyik fájl a másik után, és egy 200 megabájtos pályagyűjteménynél ez játékosonként percekre blokkolja a szerverét:

sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64
sv_downloadurl "https://fastdl.example.org/tf/"

A net_maxfilesize alapértelmezés szerint 15 értéken áll, és legfeljebb 64 megabájtra emelhető. Az sv_allowupload 0 megakadályozza, hogy a kliensek saját fájlokat (például spray-képeket) küldjenek a szervernek, és ezzel elveszi a 4. szakasz darabolt csomagjainak egyik kevés jogos okát.

A döntő kérdés az, hol áll a FastDL-kiszolgáló. Ha ugyanazon az IP-címen van, mint a játékszerver, elég egy HTTP-özön a 443/TCP ellen, hogy megteljen a vonal, és ezzel a 27015/UDP is megfulladjon. Tegye a gyors letöltést másik gépre vagy tartalomszolgáltató hálózat mögé, akkor a fájlok elleni támadás nem éri el a játékot.

8. A szavazórendszer, a csatlakozásözön és a bővítmények korlátozása

Nem minden kiesés sávszélesség kérdése. Mivel a TF2 ingyenes, a játéklogika elleni támadás a fiókokon kívül semmibe nem kerül: csatlakozásözön, amely minden helyet elfoglal, hang- és csevegőszemét, valamint visszaélésszerű szavazások, amelyek kidobják a szabályos játékosokat. A TF2 alapbeállításai itt már ésszerűek, de gyakran fellazítják őket:

sv_allow_votes 1
sv_vote_issue_kick_allowed 0
sv_vote_allow_spectators 0
sv_vote_creation_timer 150
sv_vote_failure_timer 300
sv_vote_quorum_ratio 0.6

Ezek az alapértékek: a szavazások engedélyezettek, a kirúgásról szóló szavazások nem, a nézők nem szavaznak, két szavazás között 150 másodperc telik el, egy sikertelen után 300, és egy szavazáshoz 60 százalékos egyetértés kell. Aki az sv_vote_issue_kick_allowed 1 értéket állítja be, az tudja meg, hogy ezzel olyan eszközt nyit meg, amellyel egy nyilvános szerveren megbízhatóan visszaélnek.

Minden, ami ezen túlmutat, a TF2-nél a SourceMod és a Metamod:Source rendszerből jön. Mindkettő a tf/addons/ könyvtárban található, és a konzolban a meta version, illetve az sm version paranccsal jelentkezik. A Counter-Strike 2-vel ellentétben itt az alap kiforrott, és a tiltólistákhoz, a csatlakozás ellenőrzéséhez és a csevegés korlátozásához használt bővítmények a szokásos utat jelentik. Két szabály ehhez: minden bővítmény kód ugyanabban a folyamatban, egy összeomló bővítmény magával viszi a szervert. A saját webszolgáltatást hozó bővítmények pedig további portokat nyitnak, és időnként épp azt a címet hozzák nyilvánosságra, amelyet védeni szeretne. Az sm plugins list mutatja meg, mi fut ténylegesen.

Hogy mennyire komolyan kell venni a motor oldalát, azt 2020 áprilisa mutatja: miután kiszivárogtak a TF2 és a CS:GO régebbi forráskód-állapotai, nagy közösségi üzemeltetők, például a Creators.TF és a Red Sun a kihasználástól tartva átmenetileg lekapcsolták a szervereiket. Tartsa naprakészen a szerverbinárist, a bővítményeket pedig a motorverzióhoz illeszkedően.

9. Mérés és naplózás, mielőtt baj lenne

A legfontosabb lépés az, amelyet előre szinte senki nem tesz meg: összehasonlítási alapot felvenni, amíg minden normálisan fut. Normálérték nélkül egy incidens után nem tudja megmondani, hogy a másodpercenkénti 40 000 csomag sok volt-e, vagy csak péntek este. Incidens közben négy parancs elegendő:

ip -s link show eth0
nstat -az | grep -i udp
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xfffffffe"

Az első parancs interfészenként mutatja a csomagokat, a hibákat és az eldobott elemeket, futtassa le kétszer, tíz másodperc különbséggel, akkor abszolút érték helyett sebességet kap. A két rögzítés elválasztja a lekérdezésözönt a darabolt csomagok özönétől, és ezzel megválaszolja azt a kérdést, hogy a 3. és a 4. szakasz szabályai közül melyiknek kell egyáltalán érvényesülnie. Mindig korlátozza őket a -c kapcsolóval, egy teljes terhelés melletti rögzítés maga is számítási időbe kerül.

A szerveren belül a stats konzolparancs egyetlen sorban adja meg a CPU-terhelést, a bejövő és a kimenő hálózati terhelést kilobájt per másodpercben, a szerver FPS-ét és a játékosszámot. Ha a szerver FPS-e jóval a tickérték alá esik, miközben a játékosszám normális, akkor a szerver valami máson dolgozik, nem a játékon. Hogy az értékeket hogyan kell besorolni, azt a DDoS-támadás felismerése a szerveren című cikk írja le.

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

Most jön az a rész, amelyet egyetlen konfigurációs fájl sem old meg. Az eddigi intézkedések mind az ön szerverén futnak, tehát a vonal végén. Egy tűzfalszabály olyan csomagról dönt, amely már végigfutott a kábelen. Eldobhatja, de nem teheti el nem küldötté.

Állítsa egy teli TF2-szerver normál üzemét egy valódi támadás mellé, és az arány világossá válik:

Egy tipikus játékszerver 1 Gbit/s-os csatlakozáson 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 rendszerint hamarabb üt be, mint a sávszélesség: minden csomag egy áthaladást jelent a hálózati vermen, akkor is, ha utána eldobják. Az a támadás tehát, amely a vonalát még egyharmadáig sem tölti meg, ennek ellenére megbénítja a szerverét. Az üzemeltetők ezt így élik meg: „a kihasználtság nem is volt magas, mégis minden odalett”.

Hogy milyen nagyságrendek fordulnak elő a valóságban: KernelHost-szervereken többek között egy játékszerver elleni, 112,2 Gbit/s feletti UDP-özönt másodpercenként több mint 8,7 millió csomaggal, valamint egy hangszerver elleni, több vektoros, 473,4 Gbit/s feletti támadást másodpercenként több mint 41,5 millió csomaggal szűrtünk valós időben. A 473,4 Gbit/s nagyjából egy 1 Gbit/s-os csatlakozás 470-szerese. Erre nincs helyi beállítás.

A két elterjedt vészfék nem visz tovább. A null-routing kiveszi a megtámadott IP-címet a hálózatból, és ezzel véget vet a támadásnak, de a szerverének is. Egy reaktív átterelés pedig az átkapcsolási idő alatt éppen azokba a percekbe kerül, amelyekben a meccs eldől. Csak az a szűrés hatásos, amely tartósan a szerver előtt, a hálózatban fut.

Mit állít a KernelHost a TF2-szerverek elleni támadásokkal szembe

A folyamatos védelem, amely minden szervercsomagban benne van

A KernelHost DDoS-védelme két rétegből épül fel, és a kiépítéstől fogva tartósan aktív, anélkül hogy bármit meg kellene rendelnie, be kellene kapcsolnia vagy be kellene á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ítják ki, mielőtt elérnék az adatközpontot.
• 2. réteg: Arbor valós idejű szűrés 3,2 Tbps kapacitással Frankfurt am Mainban. Közvetlenül a szerver előtt ismerik fel és dobják el a protokollspecifikus mintákat, csomagról csomagra.

Két tulajdonság döntő egy TF2-szervernél. A szűrés folyamatosan fut, és nem kell előbb reagálnia egy támadásra, tehát nincs átkapcsolási idő, amelyben a játékosai kirepülnek és a szervere kiesik a szerverböngészőből. És nem alkalmazunk null-routingot: az ön IP-címe a hálózatban marad, csak a káros csomagokat dobjuk el. Hogy mely játékok és protokollok vannak lefedve, azt a Játékszerverek valós idejű DDoS-védelme című cikk sorolja fel.

Advanced DDoS Protection a tartósan lőtt szervereknek

Egyes projekteket nem alkalomszerűen, hanem célzottan és heteken át támadnak, váltakozó mintákkal és mindig pontosan a meccs időpontjára. 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, hanem az irányításban rejlik:

• Dedikált védett IP-cím a frankfurti központi hálózatbó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.
• Saját kezűleg kezelhető védelmi szabályok portonként és protokollonként az ügyfélfiókban: külön állítja be, mi engedélyezett a 27015/UDP porton, mi a 27020/UDP porton és mi a 27015/TCP porton, anélkül hogy hibajegyet kellene írnia.
• A változtatások valós időben lépnek érvénybe, tehát futó támadás közben is utánaigazíthat, ahelyett hogy a meccs végéig várna.
• A játékhoz illő védelmi profil, a Team Fortress 2-höz és a többi Source-címhez éppúgy, mint szabadon állítható TCP- és UDP-profilok saját alkalmazásokhoz.

Az ajánlat azokra a szerverekre vonatkozik, amelyek a KernelHostnál futnak. Ha a TF2-szervere jelenleg máshol áll, és rendszeresen lövik, a költözés vezet ehhez a védelemhez.

A két szint összehasonlítása

A legtöbb TF2 közösségi szervernek elegendő a beépített folyamatos védelem egy tiszta szerverkonfigurációval együtt. Az Advanced DDoS Protection arra a válasz, hogy valaki személyes ügyet csinál belőle.

Gyakori hibák és megoldásaik

„A szerver fut, de nincs már benne a szerverböngészőben”: Először a Game Server Login Token azonosítót ellenőrizze. A TF2-szerverek a nyilvános bejegyzéshez tokent igényelnek, amelyet az sv_setsteamaccount állít be, és a 440-es App-ID-hez kell létrehozni. A Steam visszavonja azokat a tokeneket, amelyeket 30 napig nem használtak. Egy szerver, amely hosszabb szünet után eltűnik, gyakran csak új tokent igényel, és egyáltalán nem támadják. Csak ezután jön szóba a túl alacsony sv_max_queries_sec_global vagy egy túl durva tűzfalszabály a 27015/UDP porton.

„A CPU 100 százalékon áll, a vonal szinte üres”: Ez a lekérdezésözön vagy a darabolt csomagok özönének tipikus képe. Nézzen utána a szervernaplóban a NET_GetLong bejegyzést tartalmazó soroknak, és mérje meg a 9. szakasz két tcpdump-sorával, melyik csomagfajta érkezik.

„Az nftables- vagy iptables-szabályaim nem érvényesülnek”: Három ok gyakori. A szabály az UFW láncai mögött áll, és soha nem éri el a csomag (ezért a -10 prioritás), a szabály az utolsó újraindítás után eltűnt, vagy a támadás volumetrikus, és a szabály helyesen dolgozik egy vonalon, amely már tele van. Ellenőrizze az nft list ruleset paranccsal, hogy nőnek-e a számlálók. Ha nullán maradnak, a szabályt nem éri el a forgalom.

„Lecseréltem az IP-címet, és másnap megint offline voltam”: A támadó ugyanabból a forrásból találja meg az új címet, mint a régit. A szervere maga hozza nyilvánosságra, amint újra benne van a szerverböngészőben, a régi DNS-bejegyzések és a Discord-állapotbotok pedig elvégzik a többit. A címcsere órákat hoz, megoldást nem.

„A szerver reprodukálhatóan összeomlik, miközben a sávszélesség nem feltűnő”: Ez többnyire nem DDoS-támadás, hanem egy bővítmény, amely nem illik a motorverzióhoz, vagy egy elavult szerverbináris. Az sm plugins list és a verziók összevetése itt gyorsabb minden szűrőszabálynál.

„A szerver üresjárat után késleltetve reagál”: Ez a hibernálás, és nem hiba. Nullához közelire csökkenti a CPU-terhelést, amíg senki nincs csatlakozva, és éppen ez az az állapot, amelyben tartalékot szeretne.

„A szerveren idegen adminisztrációs parancsok futnak”: Ez nem DDoS-támadás, hanem feltört RCON-hozzáférés. Azonnal állítson be új jelszót, korlátozza a portot a saját címére, és gondoljon arra, hogy a jelszó olvasható formában megy át a vonalon.

„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 utána is. Kétség esetén kérdezze meg, hogy szűrnek vagy null-routingot alkalmaznak. A válasz többet dönt a rendelkezésre állásáról, mint bármely hardveradat.

Röviden összefoglalva

• Egy TF2-szervernek kifelé pontosan a 27015/UDP portra van szüksége. Az RCON a 27015/TCP porton a saját címre korlátozandó, a SourceTV a 27020/UDP porton a -nohltv kapcsolóval kikapcsolandó, ha nem közvetít.
• A játékforgalom és az A2S-lekérdezés ugyanazon a porton osztozik. Aki a 27015/UDP portot átfogóan lezárja vagy sebességkorlátozza, kidobja a saját játékosait. A határnak a csomagfajták között kell húzódnia, ami az UDP-fejléc mögötti első négy bájton felismerhető.
• A FE FF FF FF fejlécű darabolt csomagok özöne sávszélesség helyett CPU-terhelést okoz, és a naplóban NET_GetLong néven jelenik meg. Ennek a csomagfajtának a szoros korlátozása a TF2-nél vállalható.
• A „Meet Your Match” óta az új játékosok már csak a szerverböngészőn keresztül találják meg a közösségi szervereket. Minden olyan intézkedés, amely kiszorítja önt a listából, úgy hat, mint maga a támadás.
• Egy teli, 24 helyes szerver másodpercenként nagyjából 1600 bejövő csomagot dolgoz fel. A közösségi játékszerverek elleni támadások jellemzően 5 és 50 Gbit/s között és másodpercenként több millió csomagnál járnak.
• Az 1 Gbit/s a legkisebb csomagoknál másodpercenként nagyjából 1,49 millió csomagot visz. E határ felett kizárólag a szerver előtti hálózat dönt, nem a szerveren futó szabály.
• A KernelHostnál a kétrétegű folyamatos védelem minden szervercsomagban benne van felár nélkül, a kiépítéstől aktív, null-routing nélkül. Az Advanced DDoS Protection havi 50,00 EUR-tól jön hozzá, ha a portonkénti szabályokat saját maga szeretné irányítani.

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 támogatási hibajegyet, hogy a szűrőszabályokat az ön IP-címéhez igazítsuk. Futó támadás esetén a WhatsApp-vészhelyzeti chaten is elér minket a +43 650 8209883 számon. Adjon meg mindjárt négy adatot: IP-cím, port, időszak az ön időzónájában, és amit lát. Ezzel megspórol egy visszakérdezési kört, az pedig számít, amikor meccs zajlik.