Left 4 Dead 2 szerver védelme a DDoS-támadások ellen

Egy Left 4 Dead 2 szerver ritkán esik ki alkalmas pillanatban. Egy kampány utolsó szakaszában esik ki, egy Versus-meccs második körében, vagy pontosan akkor, amikor egy kitiltott játékost harmadszor is elutasított. Akit éppen lőnek, annak nem hálózattechnikai alapvitára van szüksége, hanem sorrendre. Ez a cikk először azt mutatja meg, hogyan védi meg a Left 4 Dead 2 szerverét a DDoS-támadások ellen, amíg ez saját eszközökkel még megy, utána azt, hol érnek véget fizikailag ezek a lehetőségek, végül azt, minek kell ez előtt a hálózatban történnie.

Minden adat egy dedikált szerverre (srcds) vonatkozik, amelyet a SteamCMD a 222860 App-ID alatt telepít, 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. Egy pont előre, mert ez határozza meg a sorrendet: zajló támadás közben ne módosítson semmit vaktában, és ne indítsa újra a szervert, amíg a mérési értékeket nem mentette el. A támadás után már nem lesznek meg.

Miért vonzó DDoS-célpontok a Left 4 Dead 2 szerverek

A 64 férőhelyes lövöldözős játékokhoz képest a különbség a kör méretében van. Egy koop-kampányban négy férőhely van a túlélőknek, egy Versus-meccsben nyolc a két oldalnak együtt. Egy kiesés ezért soha nem egyes játékosokat érint, hanem mindig a teljes partit: aki egy kampányt az öt szakaszból a harmadikban szakít meg, az mindenki számára befejezte az estét. Pontosan ez teszi a támadást vonzóvá a kiváltója számára, mert sem tudásba, sem említésre méltó pénzbe nem kerül neki, miközben a másik oldalon egy óra játékidőt tesz semmivé.

Ehhez jön a felépítés. A Left 4 Dead 2 a Source-engine-en fut, egy Source-szerver pedig IP-címmel és porttal nyilvánosan megtalálható. Ez feltétel, nem tévedés: az a szerver, amely egyetlen lekérdezésre sem válaszol, egyetlen listában sem szerepel, és egyetlen lobby sem találja meg. A kérdés tehát soha nem az, hogy egy támadó ismeri-e a címét, hanem csak az, hogy mi történik, ha rálő. A játékforgalom UDP-n keresztül megy, az UDP pedig nem ismer olyan kapcsolatfelépítést, amelyet meg lehetne követelni, a feladócímek ráadásul hamisíthatók. Hogy ilyenkor műszakilag mi zajlik, azt a Mi az a DDoS-támadás? című cikk magyarázza el.

Egy harmadik pont kizárólag a Left 4 Dead 2 sajátja, és a Counter-Strike, a Garry's Mod vagy a Team Fortress 2 esetében nincs megfelelője: a játékosok többsége nem a szerverböngészőn keresztül érkezik, hanem a lobby-rendszeren keresztül. A legfeljebb négy játékosból álló lobbyt a Steam-matchmaking egy dedikált szerverre irányítja, amely ehhez foglalást kap. Ez az eljárás egyszerre a leghatásosabb hozzáférési szűrője és egy további támadási felület. Mindkettő részletesen lentebb áll.

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

Egy Left 4 Dead 2 szerver pontosan egy UDP-portot foglal mindenre, ami a játékot alkotja. Az alapérték a 27015, amelyet a -port illetve a +hostport kapcsoló állít be az indítósorban:

./srcds_run -game left4dead2 -console -nohltv \
  -port 27015 \
  +ip 203.0.113.10 \
  +maxplayers 4 \
  +exec server.cfg \
  +map c1m1_hotel

Ennek a táblázatnak az első sora a probléma magja. A játékforgalom és a szerverlekérdezés osztozik a 27015/UDP porton, külön lekérdezési port a Left 4 Dead 2 esetében nincs. Aki ezt a portot általánosan letiltja vagy durván sebességkorlátozza, az ugyanazzal a mozdulattal kidobja a saját játékosait, és a támadó szándéka szerint fejezi be a támadást.

Egy A2S-kérés néhány tucat bájtos csomag, a válasz ennek többszöröse. UDP esetén a feladócím hamisítható, és ezzel az Ön szervere nem csupán áldozat lesz, hanem erősítő is: a támadó idegen játékszervereket kérdez le a célpontja címével, és azok válaszait oda irányítja. A Valve 2020 decemberében egy előzetes felszólítással (S2C_CHALLENGE) egészítette ki az A2S_INFO-t, amelyet a lekérdezőnek vissza kell küldenie, mielőtt megkapja a választ. Ez csökkenti a reflexió élét, de nem szünteti meg, mert a régebbi lekérdező programokat a szerver továbbra is kiszolgálja.

Mit tehet saját maga, mielőtt pénzt költene

A következő rész semmibe nem kerül, és attól függetlenül megtérül, hogy hol áll a szervere. Volumetrikus támadást nem vesz le a válláról, de a kis és közepes támadásokat hatástalanná teszi, és megszünteti azokat a kieséseket, amelyeket tévesen DDoS-támadásként jelentenek.

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

Mielőtt egyetlen szabályt is megírna, tisztázza, mely szolgáltatások érhetők el. Egy megnőtt Left 4 Dead 2 szerveren ez szinte mindig több a vártnál, mert az srcds mellett fut még egy webszerver a kampányokhoz, egy statisztikai adatbázis és néha egy második szerver a Versushoz:

ss -lntup

Minden, ami a 127.0.0.1 vagy a ::1 címhez van kötve, nem igényel engedélyezést. Minden, ami a 0.0.0.0 vagy a [::] címen figyel, elérhető az internetről. A támadó nézőpontját egy kívülről indított portszkennelés adja meg, és ez a tapasztalat szerint eltér a saját várakozástól:

nmap -Pn -sU -sT -p 27000-27050,80,443,3306 A.SZERVERE.IP.CÍME

Ha az alapréteg frissen van felállítva, vagy utána szeretné követni, a Játékszerver telepítése SteamCMD-vel című cikk leírja az utat a SteamCMD-től a futó srcds-ig.

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

Egy UDP-port kifelé, egy TCP-port a saját címre, több nem. Az RCON nem a nyílt internetre való, mert akinek RCON-ja van, az pályát vált, kitilt minden játékost és leállítja a szervert:

ufw allow 27015/udp comment "L4D2 játékport és A2S"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw allow from 203.0.113.10 to any port 22 proto tcp comment "SSH"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

A 203.0.113.10 helyére írja a saját címét. Ha ez rendszeresen változik, az út egy SSH-porttovábbításon vezet, nem tartós engedélyezésen. Az élesítés sorrendje dönti el, hogy kizárja-e saját magát; ez a mentőúttal együtt az UFW-tűzfal beállítása anélkül, hogy kizárná magát cikkben olvasható. Ha mégis megtörténne: a KernelHost KVM root-szerverein és dedikált szerverein nincs IPMI és nincs iDRAC, a szervert az ügyfélportálon elérhető VNC-konzolon keresztül éri el, és ez nem a vendégrendszer hálózati vermén lóg.

3. Az A2S-lekérdezés korlátozása anélkül, hogy kiesne a lobby-keresésből

Itt van ennek a témakörnek a legdrágább hibája. Mivel a játékforgalom és a szerverlekérdezés ugyanazt a portot foglalja, a féknek a két csomagosztály között kell különbséget tennie, nem a portok között.

A Steam játékszerver-alapréteg a 2020 decemberi változtatások óta saját korlátozást hoz ehhez, amelyet indítás előtt környezeti változóként kell beállítani. A STEAM_GAMESERVER_RATE_LIMIT_200MS=N eldobja egy feladócím kapcsolat nélküli csomagjait (A2S_INFO, A2S_RULES, A2S_PLAYERS), amint egy 200 milliszekundumos ablakban ezekből N-nél több érkezik. A Valve a 25 és 75 közötti értéket nevezi használható tartománynak, alapértelmezés szerint a korlátozás ki van kapcsolva:

export STEAM_GAMESERVER_RATE_LIMIT_200MS=50
./srcds_run -game left4dead2 -console -port 27015 +exec server.cfg +map c1m1_hotel

Egy systemd-unitban ugyanez az érték Environment=STEAM_GAMESERVER_RATE_LIMIT_200MS=50 formában a [Service] szakaszba tartozik, különben a következő újraindítás után nincs meg. Ez a fék csak akkor érvényesül, ha a szerverbuildje a jelenlegi Steamworks-alapréteget hozza magával, és a szervere számítási idejét védi, nem a vonalát: a csomagok már megérkeztek.

Egy szinttel lejjebb ugyanez a forgalom leválasztható a kernelben. A Source-engine minden kapcsolat nélküli csomagja, tehát a szerverlekérdezések és a kapcsolatfelépítés is, négy beállított bájttal kezdődik (0xffffffff), a már csatlakozott játékosok forgalmának nincs ilyen fejléce. Erre nftables segítségével feladócímenkénti sebességkorlátozás tehető:

table inet l4d2 {
    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. Kezdjen bőkezűen, és csak akkor húzza szorosabbra a határt, ha a jogos lekérdezések bizonyítottan átjutnak: a saját szerverlista-bejegyzése is ezen függ.

4. A lobby-rendszer használata hozzáférési szűrőként

Ez az a fogódzó, amely csak a Left 4 Dead 2 és az elődje sajátja. A szerver maga dönti el, hogy egyáltalán elfogad-e a matchmakingen kívüli kapcsolatokat. Négy direktíva határozza ezt meg a server.cfg fájlban:

sv_allow_lobby_connect_only 1
sv_search_key "a-sajat-kulcsa"
sv_steamgroup "103582791400000000"
sv_steamgroup_exclusive 2

• sv_allow_lobby_connect_only 1 kizárólag a matchmaking-lobbyból érkező belépéseket engedi. A fejlesztői konzolban kiadott connect 203.0.113.10:27015 és a Steam-meghívó elutasításra kerül. A 0 érték mindkettőt engedi.
• sv_search_key egy szabadon választható keresőkulcs. Csak az a lobby találja meg a szervert a matchmakingen keresztül, amelyben ugyanez a kulcs be van állítva. A kulcs nélkül a nyilvános keresésben nem jelenik meg.
• sv_steamgroup egy Steam-csoporthoz köti a szervert, és a csoport szerverei között jeleníti meg.
• sv_steamgroup_exclusive három szintet ismer: a 0 mindenkit beenged, az 1 úgy viselkedik, mint a 0, de lobbyn keresztüli belépést követel, a 2 pedig már csak a csoport tagjait és az IP-címen keresztüli közvetlen hozzáférést engedi át.

Egy állandó közösség számára a keresőkulcs és az sv_steamgroup_exclusive 2 kombinációja a leghatásosabb ingyenes hozzáférési szűrő, amelyet a játék ismer. Egy nyilvános szerver nem tudja használni, mert az a szerver, amelyet senki nem talál meg, ugyanolyan üres, mint az, amelyik offline.

És most az a rész, amelyet a reklámszövegek szívesen elhagynak: ezek a direktívák a játéklogikáját védik, nem a vonalát. Az a támadó, aki elárasztja a 27015/UDP portot, egyáltalán nem akar belépni. A csomagjait elutasítják, de attól még megérkeztek, sávszélességet fogyasztottak és egy áthaladásba kerültek a hálózati vermen. Az eldobható fiókokból érkező belépési áradat ellen az sv_allow_lobby_connect_only 1 kitűnően hat, egy booter ellen egyáltalán nem.

5. A lobbyfoglalás, és mikor jobb választás az sv_force_unreserved

A lobbyfoglalás az Ön szerverének időben korlátozott lefoglalása egy matchmaking-lobby által. Amíg fennáll, a szerver más lobbyk számára foglaltnak számít, és csak egy idő után jár le magától. Egy négy férőhelyes szerveren ez szűkös erőforrás: egy 32 vagy 64 férőhelyes lövöldözős játékkal ellentétben itt nagyon kevés is elég egy parti megbénításához.

Aki nem a matchmakingen keresztül üzemelteti a szerverét, az ezt a felületet teljesen kiveszi:

sv_force_unreserved 1
sv_allow_lobby_connect_only 0

Az sv_force_unreserved 1 hatására a szerver már nem válaszol a lobby-rendszerből érkező foglalási kérésekre, és elutasítja a foglalási jellemzővel érkező belépéseket. Ugyanerre a beállításra amúgy is szüksége van, ha L4DToolZ segítségével négynél több koop-férőhelyet üzemeltet, mert különben a lobby foglalást kap, amint az első négy férőhely betöltött, a többi férőhely pedig elérhetetlen marad. A hátulütő egyértelmű: a játékosai ilyenkor már csak a szerverböngészőn vagy a connect parancson keresztül érkeznek be.

Válasszon tudatosan a két üzemmód közül. A félig nyitott matchmaking és a félig nyitott közvetlen belépés keveréke az a változat, amely mindkét hátrányt egyesíti.

6. Az RCON bebiztosítása

Egy nyitott RCON-port gyenge jelszóval nem DDoS-probléma, hanem átvétel. Az rcon_password értéke soha ne legyen üres és soha ne legyen kitalálható, egy openssl rand -base64 32 értéke elegendő. A Source-címek ezen felül saját féket hoznak a bejelentkezési kísérletek ellen:

rcon_password "ITT_EGY_VÉLETLEN_ÉRTÉK"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Ezzel egy cím 30 másodpercen belüli három sikertelen kísérlet után egy napra kitiltásra kerül; a szerverkonzolban kiadott find sv_rcon megmutatja, ezek közül a változók közül melyeket ismeri a buildje. A 2. lépés tűzfalkorlátozása ennek ellenére hatékonyabb marad, mert a kísérletet el sem engedi az alkalmazásig. Ha nincs szüksége az RCON-ra, hagyja üresen a jelszót: akkor a 27015 TCP-része nem figyel.

7. A Custom-kampányok kiszervezése a játékporton történő kiszolgálás helyett

A Custom-kampányok az oka annak, hogy a Left 4 Dead 2 tizenöt év után is játékban van, és egyben olyan terhelési forrás, amely a Counter-Strike esetében ebben a formában nem létezik. Egy kampány VPK-csomag pályákkal, modellekkel, textúrákkal és hangokkal, tehát többszöröse annak, amennyit egyetlen versenypálya nyom.

A játékosok számára a kényelmes út a Steam-Workshop: a csomag ilyenkor a Steamről jön, nem az Ön szerveréről, és nem kerül Önnek sávszélességbe. Ha egyedi fájlokat saját maga szolgál ki, a kiszolgálás webszerverre való, nem a játékportra:

sv_allowdownload 1
sv_allowupload 0
sv_downloadurl "https://cdn.example.org/l4d2/"
sv_consistency 1

Az sv_downloadurl fájljai bzip2-archívumként valók a webszerverre, a sajatpalya.bsp fájlból tehát sajatpalya.bsp.bz2 lesz. Az sv_downloadurl nélkül az srcds maga küldi a fájlokat a játékkapcsolaton keresztül, és akkor ez érvényes: egy új játékos minden kapcsolódási kísérlete a teljes letöltésbe kerül Önnek, és a letöltés közepén történő minden megszakítás is. Ez kifejezetten olcsó módja egy vonal megtöltésének, és egyetlen statisztikában sem látszik támadásnak.

Három pont ehhez, amelyek a gyakorlatban fájnak. Az sv_allowupload 0 beállítást be kell állítani, mert a klienstől a szerverre történő feltöltésre nincs szüksége. Ha az sv_downloadurl webszervere ugyanazon a gépen van, mint a játék, a letöltés és a játékforgalom ugyanazon a vonalon és ugyanazon az IP-címen osztozik, és egy 443/TCP elleni támadás ilyenkor a futó partit is eltalálja. Az sv_consistency 1 pedig nem a támadások ellen véd, hanem az eltérő kliensfájlok ellen; csak akkor kapcsolja ki, ha egy kampány különben bizonyítottan nem indul el.

8. A SourceMod, a Metamod és a bővítmények

A DDoS-ként jelentett kiesések jelentős része nem az. Összeomlásokról és terhelési csúcsokról van szó, amelyeket egyetlen kliens vált ki, mert a szerverbinárisban vagy egy bővítményben nyitva áll egy rés. Ez ellen nem sávszélesség segít, hanem gondozás:

• Tartsa a Metamod:Source és a SourceMod rendszert a motorverzióhoz illeszkedően. A Left 4 Dead 2 továbbra is kap frissítéseket, és egy nem illeszkedő bővítmény a leggyakoribb oka a közvetlenül egy frissítés után jelentkező összeomlásoknak.
• Left4DHooks a saját beavatkozások helyett. Az L4D2-re jellemző események ebben a bővítményben összefogva állnak rendelkezésre. A saját beavatkozás ugyanezekbe a funkciókba a leggyorsabb út egy olyan szerverbinárishoz, amely bizonyos csomagsorozatoknál kiszáll.
• Az L4DToolZ-t csak tudatosan használja. A bővítmény feloldja a fixen beépített férőhelyhatárokat. Minden további férőhely egy további játékos, aki számítási időt termel, és a lobby-rendszerrel együtt a bővítménynek sv_force_unreserved 1 beállításra van szüksége.
• Kevesebb bővítmény. Minden plugin kód ugyanabban a folyamatban. A saját webszolgáltatással érkező bővítmények további portokat nyitnak meg, és gyakran pontosan azt a címet teszik közzé, amelyet védeni szeretne.

A kitiltásokat tartósan el kell menteni, különben az újraindítás után nincsenek meg. A Source-címek ehhez a banid és a writeid, valamint az addip és a writeip parancsot ismerik, a létrejött fájlokat pedig az exec banned_user.cfg és az exec banned_ip.cfg olvassa be újra.

9. A kapcsolatkövetés és a fogadópuffer tehermentesítése

Ezt a pontot gyakran 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 bejegyzéseket hoz létre a kapcsolatkövetésben (conntrack), hamisított feladócímek esetén pedig minden 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. Az aktuális állást és a felső határt egy pillantás megmutatja:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

A leghatásosabb lépés az, ha a játékforgalmat egyáltalán nem követteti, mert az engine maga kezeli a saját munkameneteit:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport 27015 notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport 27015 notrack
    }
}

Iptables esetén a megfelelője az iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK, és ugyanez a sor az OUTPUT lánchoz a --sport kapcsolóval. A portnak ezután kifejezett engedélyezés kell, mert követés nélkül már nem érvényesül olyan szabály, amely meglévő állapotot vizsgál. Ha a csomagok gyorsabban érkeznek, mint ahogy az srcds elviszi őket, ráadásul túlcsordul a fogadópuffer, és 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

A fájlt az /etc/sysctl.d/ könyvtárba tegye, és a sysctl -p paranccsal aktiválja. Hogy egyáltalán szükség van-e az értékekre, azt maga a kernel árulja el: ha az nstat -az kimenetében emelkedik az UdpRcvbufErrors értéke, akkor érvényesülnek. Ha a számláló nullán marad, a módosítás semmit nem változtat. Ez tartalék, nem védelem.

10. Mérjen, hogy a támadás alatt ne kelljen találgatnia

Támadás közben ez a legfontosabb kérdés: mennyi érkezik, melyik porton, és lekérdezési vagy játékforgalom-e. Négy parancs elegendő:

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

Az első parancsot tíz másodperc eltéréssel kétszer futtassa le, akkor abszolút érték helyett sebességet kap. Az utolsó sor kizárólag a kapcsolat nélküli csomagokat mutatja, tehát pontosan azt az osztályt, amellyel egy lekérdezési áradat visszaél; ha a számláló másodpercek alatt megtelik, miközben alig van valaki csatlakozva, megvan a válasza. A rögzítést tartsa rövidre, mert terhelés alatt maga is számítási időbe kerül. Hogy az értékeket hogyan helyezze el, arról a DDoS-támadás felismerése a szerveren című cikk szól.

A legfontosabb lépés azonban 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 telt házas Versus-szerverrel.

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

Most jön az őszinte rész. Minden eddig leírt dolog csak akkor hat, ha a csomagok megérkeztek az Ön hálózati kártyájára. 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. A lehető legkisebb csomagméret mellett ez a vonal másodpercenként nagyjából 1,49 millió csomagot visz el, egy 10 Gbit/s-os vonal nagyjából 14,88 milliót. Ez a fizikai felső határ, a processzortól, a kerneltől és a tűzfaltól függetlenül. Egy normál szerverkernel a processzortól és a hálózati kártyától függően másodpercenként néhány százezret dolgoz fel, 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 a 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 elérhetetlen lett”.

Ezzel szemben valódi támadások állnak. Két példa a KernelHost üzemeltetéséből, mindkettőt valós időben szűrtük: egy UDP-flood egy játékszerver ellen a 7777/UDP porton 112,2 Gbit/s feletti sebességgel és másodpercenként több mint 8,7 millió csomaggal, valamint egy multivektoros támadás egy hangszerver ellen a 9987/UDP porton 473,4 Gbit/s feletti sebességgel és másodpercenként több mint 41,5 millió csomaggal. Vetítse ezt a saját vonalára: a 473,4 Gbit/s nagyjából 470-szerese egy 1 Gbit/s-os csatlakozásnak, és még mindig nagyjából 47-szerese egy 10 Gbit/s-os csatlakozásnak.

Ezért nem kielégítő a két elterjedt vészfék. A null-routing (blackholing) kiveszi a hálózatból a megtámadott IP-címet, és véget vet ugyan a támadásnak, de a szerverének is: a játékosai számára az eredmény azonos egy sikeres támadással. Egy reaktív átirányítás az átkapcsolási idő alatt pontosan azokba a percekbe kerül, amelyekben a kampány eldől. Csak az a szűrés hatásos, amely tartósan a szerver előtti hálózatban fut.

Mit állít ezzel szembe a KernelHost

A folyamatos védelem, amely minden szerverben 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 konfigurálnia:

• 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, jóval azelőtt, hogy 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 a 3. rétegtől a 7. rétegig, csomagról csomagra.

Két tulajdonság döntő. Először: a szűrés tartósan fut, tehát nincs átkapcsolási idő, amely alatt a játékosai kirepülnének. Másodszor: null-routingot nem alkalmazunk, a megtámadott IP-cím a hálózaton marad, és csak a káros csomagokat dobjuk el. A védelem minden szervercsomagban felár nélkül benne van, külön védelmi csomag és beállítás nélkül, és a kiszállítástól aktív. A szerverek a Frankfurt am Main-i maincubes Premium Datacenterben állnak. Hogy mely játékok és protokollok vannak lefedve, azt a Játékszerverek DDoS-védelme valós időben című cikk sorolja fel.

Advanced DDoS Protection a tartósan támadott projektekhez

Egyes projekteket nem alkalmanként, hanem célzottan és heteken át támadnak, váltakozó mintákkal és mindig pontosan a megbeszélt kampányest idején. Ezekre az esetekre 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:

• Egy dedikált védett IP. A szerverét a saját hálózatunkban erre a címre állítjuk át, 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 határozza meg, melyik portot melyik profillal szűrjük, tehát a 27015/UDP portot másként, mint azt a webszervert, amely a kampányait kiszolgálja.
• A módosítások valós időben lépnek érvénybe, ticket és várakozási idő nélkül. Egy zajló támadás közben is tud tehát utánaállítani.
• Az adott játékhoz illő védelmi profil. A Left 4 Dead 2-hez és a többi Source-címhez ugyanúgy, mint további több mint 40 játékhoz és protokollhoz, ehhez jönnek a szabad TCP- és UDP-profilok a módosított szerverekhez.

Itt is a PrePaid-modell érvényes: nincs minimális futamidő, nincs felmondási idő, nincs szerződés és nincs beállítási díj. Ha a támadási hullám elmúlt, egyszerűen nem hosszabbít.

A két szint összehasonlítása

A legtöbb Left 4 Dead 2 projekthez 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ások

A szerver eltűnt a lobby-keresésből, de tovább fut: többnyire a 27015/UDP portot tiltották le általánosan, vagy túl szűkre vették a sebességkorlátozását, és mivel a játékforgalom és a lekérdezés ugyanazon a porton osztozik, egy durva szabály mindkettőt eltalálja. Dolgozzon helyette a kapcsolat nélküli csomagokra illesztéssel. Ha a port elérhető, és a szerver mégis láthatatlan, ellenőrizze az sv_search_key, az sv_steamgroup_exclusive, az sv_lan 0 és az sv_region 255 beállítást, valamint azt, hogy az indítás nem véletlenül a -nomaster kapcsolóval történt-e.

A szerverkonzolban folyamatosan az „Invalid split packet length” áll: ez nem volumetrikus támadás, hanem hibásan összeállított hálózati csomag, amelyet gyors egymásutánban küldenek. A forgalom eközben csepp marad, a szerver mégis akadozik. Először ellenőrizze, hogy a sávszélesség egyáltalán feltűnő-e, és hozza naprakész állapotba a szerverbinárist és a bővítményeket. A sávszélesség itt semmit nem segít.

Minden játékosnak magas a pingje, a vonal viszont nincs tele: ez csomagsebességre utal, nem volumenre. Nézze meg az ip -s link show kimenetében az eldobott csomagokat és az nstat -az kimenetében az UDP-számlálókat. Ha a rendszernaplóban az nf_conntrack: table full áll, vegye ki a játékportot a notrack kapcsolóval.

A tűzfalszabály helyes, mégsem hat: 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, mert az UFW-láncok mögött áll, vagy a legutóbbi újraindítás után elveszett. Ha emelkednek, és semmi nem változik, a szerver előtti vonal telített, és onnantól már csak a hálózatban végzett szűrés segít.

A szerver már nem vesz fel játékosokat, noha vannak szabad férőhelyek: többnyire egy lobbyfoglalás ragadt be. Vagy következetesen a matchmakingen keresztül üzemelteti a szervert, vagy beállítja az sv_force_unreserved 1 értéket, és a játékosait a szerverböngészőn keresztül engedi belépni. Ha L4DToolZ segítségével négynél több koop-férőhelyet üzemeltet, ez a beállítás amúgy is kötelező.

Az új játékosok örökké töltenek, és a vonal eközben tele van: ilyenkor az srcds maga szolgálja ki a kampányfájlokat a játékporton keresztül. Állítsa az sv_downloadurl értékét egy webszerverre, és tegye oda a fájlokat bzip2-archívumként, vagy irányítsa a játékosait a Steam-Workshopra.

A támadás egy címcsere után szünetet tart, és egy-két nap múlva visszatér: ez az alapeset, mert a szervere maga teszi közzé az új címet, amint újra regisztrálva van, egy elfelejtett DNS-rekord vagy egy állapotjelző Discord-bot pedig elvégzi a többit. Egy címcsere órákat szerez, nem megoldást.

A szerveren idegen adminisztrációs parancsok futnak: ez nem DDoS-támadás, hanem kompromittált RCON-hozzáférés. Azonnal cserélje le a jelszót, és korlátozza a 27015 TCP-részét a saját címére.

Röviden összefoglalva

• Egy Left 4 Dead 2 szervernek kifelé pontosan egy nyitott portra van szüksége: 27015/UDP. A játékforgalom és az A2S-lekérdezés osztozik rajta, külön lekérdezési port nincs.
• A 27015/TCP az RCON, és kizárólag a saját címre való. Akinek nincs szüksége az RCON-ra, az üresen hagyja az rcon_password értékét.
• A lobby-rendszer a leghatásosabb ingyenes hozzáférési szűrő, amelyet a játék ismer: az sv_allow_lobby_connect_only 1, egy saját sv_search_key és az sv_steamgroup_exclusive 2 kizár mindent, ami nem a matchmakingen keresztül érkezik. Belépéseket szűr, nem csomagokat.
• A Custom-kampányok a Steam-Workshopba vagy az sv_downloadurl mögé valók, soha nem a játékportra. Különben minden megszakított kapcsolódási kísérletet az Ön sávszélessége fizet.
• A sebességkorlátozásnak különbséget kell tennie a kapcsolat nélküli csomagok (amelyek a 0xffffffff értékkel kezdődnek) és a játékforgalom között. Egy durva szabály a 27015/UDP porton kidobja a saját játékosait.
• 64 bájtos csomagok esetén egy 1 Gbit/s-os vonal másodpercenként nagyjából 1,49 millió csomagot visz el. Ezen felül kizárólag a szerver előtti hálózat dönt, nem a szerveren végzett beállítás.
• A KernelHostnál 17 Tbps globális scrubbing és egy Arbor valós idejű szűrés 3,2 Tbps kapacitással Frankfurt am Mainban tartósan és felár nélkül szűr, null-routing és átkapcsolási idő nélkül.

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 egy support-ticketet, hogy a csapatunk az Ön IP-címéhez igazítsa a szűrőszabályokat. Zajló támadás esetén ezen felül a WhatsApp-vészhelyzeti chaten ér el minket a +43 650 8209883 számon. Adjon meg rögtön négy adatot: IP-cím, port, időszak az Ön időzónájában, és hogy mit tapasztal (a játékosok kirepülnek, a szerver nincs a lobby-keresésben, magas ping). Ez megkímél egy visszakérdezési körtől, és az számít, amikor éppen zajlik egy kampány.

Ha máshol hosztol, és rendszeresen lövik, a KernelHostra költözés rövidebb út, mint bármelyik további szabály egy olyan szerveren, amelynek a vonala előbb véget ér. A folyamatos védelem minden szervercsomag része, nem olyan kiegészítés, amelyet csak a baj esetén rendel meg.