Lineage 2 szerver védelme DDoS-támadások ellen

Ha egy privát Lineage 2 szerveren este senki nem jut túl a bejelentkezőképernyőn, miközben a világban lévő játékosok zavartalanul játszanak tovább, az nem hardverprobléma. Ez a login szerver elleni DDoS-támadás ujjlenyomata, és egy Lineage 2 DDoS-védelemnek pontosan ott kell megfognia a támadást. Ez a cikk előbb azt mutatja meg, amit többletköltség nélkül saját maga is meg tud védeni, utána azt, hogy ezek az intézkedések hol érnek véget műszakilag, végül pedig azt, hogy minek kell történnie a szerver előtti hálózatban.

Minden adat az L2J-re és leszármazottaira (L2J-Mobius, aCis) vonatkozik Debian 12, Debian 13, Ubuntu 22.04 LTS vagy Ubuntu 24.04 LTS alatt, valamint az AuthD, CacheD és L2Server hármassal működő L2OFF-csomagokra. A parancsok root felhasználóhoz készültek, normál felhasználóként tegyen eléjük sudo parancsot.

Ha a támadás éppen zajlik: most ne változtasson a konfiguráción, és ne indítsa újra sem a login szervert, sem a játékszervert. Előbb mentse ki a mérési adatokat (lásd a „Naplózzon" című szakaszt), a támadás után már nem lesznek meg.

Lineage 2 szerver védelme DDoS ellen: miért támadják a privát L2-szervereket

Egy privát Lineage 2 szerverben több olyan tulajdonság találkozik, amely kényelmes célponttá teszi, és a Lineage 2 DDoS-védelemnek pontosan ezeknél a tulajdonságoknál kell megfognia a támadást. Először is az ön címe nyilvános, méghozzá a kezdetektől: a játékosok letöltenek egy módosított System mappát, és annak l2.ini fájljában ott a ServerAddr= sor a login szervere IP-címével. Ezt a címet mindenki ismeri, aki valaha telepítette a projektjét, függetlenül attól, hogy készített-e valaha karaktert.

Másodszor a játékosbázis kötött időpontokhoz kötődik. Az ostromok, az epic raidbossok és az események naptár szerint mennek, egy pontosan ebben az órában bekövetkező kiesés a lehető leglátványosabb. Harmadszor a projektek közvetlen versenyben állnak egymással: aki szervert nyit, ugyanazért a néhány ezer játékosért verseng, mint három másik projekt ugyanazon a hétvégén. A konkurencia kiütése ebben a szcénában bevett stratégia. A támadást szolgáltatásként rendelik meg (a szcénában ez booter vagy stresser néven fut), és a megrendelőnek sem tudásába, sem említésre méltó pénzébe nem kerül. Hogy részleteiben mi is a DDoS-támadás, azt a Mi az a DDoS-támadás? című cikk magyarázza el.

Miért a 2106-os porton futó login szerver az igazi célpont

A Lineage 2 két különálló folyamatra oszlik: egy login szerverre és egy vagy több játékszerverre. A kliens először a 2106 TCP porton csatlakozik a login szerverhez, bejelentkezik, onnan megkapja a szerverlistát a játékszerver külső címével és portjával, majd egy második kapcsolatot épít ki a 7777 TCP porton a játékszerverhez. Mindkét folyamatnak saját konfigurációs fájlja, saját portja és saját terhelhetőségi határa van.

Ebből következik a támadási minta, amelyet az L2-üzemeltetők újra és újra leírnak: a 2106-os port elárasztása kizárólag az új bejelentkezéseket blokkolja. Aki már a világban áll, addig játszik tovább, amíg maga el nem veszíti a kapcsolatot. Az online számláló tehát lassan csökken, nem egy csapásra, a fórumon pedig az áll, hogy „a szerver megy, de nem tudok belépni". Pontosan ez a kép különbözteti meg a login szerver elleni támadást a játékszerver elleni támadástól, amelynél mindenki egyszerre repül ki.

A login szerver ráadásul az olcsóbb célpont, mert a ráfordítás egyenlőtlenül oszlik meg. Az L2J login szervere induláskor tíz darab 1024 bites RSA-kulcspárt és húsz Blowfish-kulcsot készít elő. Minden bejelentkezési kísérlet a kliensnek egyetlen csomag elküldésébe, a szervernek viszont egy privát RSA-kulccsal végzett visszafejtésbe kerül. Egy félbehagyott munkamenet közben foglal egy helyet, amíg a beépített időzítő el nem dobja: a LOGIN_TIMEOUT a forráskódban 60 másodpercen áll. Az alapértelmezett MaxConnectionPerIP = 50 minden forráscímnek ötven egyidejű kapcsolatot enged. Ezer forráscím tehát elég 50 000 egyszerre nyitott munkamenethez, amelyek mindegyike akár egy percig fennmarad.

Ehhez jön a játék egyik sajátossága, amely a legtöbb játékszervertől megkülönbözteti: a Lineage 2 kizárólag TCP-n fut. A gyártó a játékhoz a 80-as, a 2009-es, a 2106-os és a 7777-es TCP-portot adja meg, UDP-ből pedig kizárólag az 53-as portot a névfeloldáshoz. Nincs tehát UDP-s játékforgalom, amelyet szűrni kellene, cserébe a hamisított feladócímekkel küldött klasszikus SYN-flood közvetlenül hatásos, és a kernel kapcsolatkövetése lesz az első szűk keresztmetszet.

Miért jelentkeznek a Lineage 2 szerverek elleni támadások szezonálisan, a szerverindításokhoz kötve

A privát Lineage 2 szerverek elleni támadások a szerverindítások körül sűrűsödnek, mert a nyitás dátuma és időpontja hetekkel korábban nyilvános. A Lineage 2 projektek nyitási naptárai krónika szerint (Interlude, High Five, Classic, Essence) listázzák a közelgő indulásokat, mellettük a rátákkal és a pontos kezdési idővel, és naponta frissülnek. A támadónak semmit nem kell kifürkésznie: a számára legkedvezőbb időpont ott áll az üzemeltető bejelentésében.

A második ok gazdasági. Egy privát Lineage 2 szerver elöl termeli meg a pénzét: a teljes játékosbázis az első napokban gyűlik össze, az adományok az első hetekben érkeznek, utána a népesség folyamatosan fogy. Az a játékos, aki az első órában nem jut be, átpártol ahhoz a projekthez, amely ugyanazon a hétvégén indul, és ilyen projekt mindig van. Egy óra kiesés a nyitás napján ezért nem egy óra bevételbe kerül, hanem a szerver teljes élettartamának egy darabjába.

A harmadik ok műszaki. A grand openingen több ezer játékos próbál egyszerre bejelentkezni. A login szerver pontosan abban a percben amúgy is a határán jár, egy ráadásként érkező flood pedig alig különböztethető meg a csúcsterheléstől. Az a támadás, amely egy nyugodt kedden nyomtalanul maradna, a nyitás órájában elegendő. Ugyanez igaz az üzemelés közben bejelentett időpontokra: a várostromok és az epic raidbossok naptár szerint mennek, és ugyanezért kedvelt támadási ablakok. A nyitási roham után az ösztönzés újra csökken, ezért az üzemeltetők a támadásokat hullámszerűnek és nem állandó állapotnak élik meg.

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

Az alábbi táblázat egy privát Lineage 2 szerver portjait, a hozzájuk tartozó konfigurációs fájlt és az értéket beállító direktívát sorolja fel. Az alapértékek az L2J mellékelt konfigurációs fájljaiból, illetve az L2OFF-csomagok telepítési útmutatóiból származnak.

Két kérdésre ez a táblázat egyúttal válaszol is: a Lineage 2-nek nincs sem query portja, sem RCON-portja. Nincs külön szolgáltatás, amely a játékosszámot egy szerverlistának kiszolgálná, és nincs távvezérlési port sem, mint a Source alapú játékoknál. A szerverlistát maga a login szerver állítja elő, és ugyanazon a 2106-os kapcsolaton küldi el a bejelentkezett kliensnek. A távvezérlés az L2J-ben játékon belüli parancsokon és az adatbázison keresztül zajlik. Ezzel két olyan támadási vektor esik ki, amely más játékoknál megvan, és annál több marad a 2106-os porton.

Nagyságrendek, amelyeket ismernie kell

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

Ez a szakasz a leghosszabb, és ez szándékos. Egy rendesen beállított Lineage 2 szerver a kis és közepes támadásokat saját erőből kibírja, függetlenül attól, hogy kinél áll.

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

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

A helyi címet tartalmazó oszlop az érdekes. A 0.0.0.0:2106 és a 0.0.0.0:7777 odavaló. A 0.0.0.0:9014 és a 0.0.0.0:3306 viszont hiba: ez az a két port, amelyen keresztül egy támadó beakaszkodhat a szerverlistájába vagy megkopogtathatja az adatbázisát. A 127.0.0.1:3306 ezzel szemben azt jelenti, hogy „csak helyben", és nem kell hozzá tűzfalszabály. A támadó nézőpontját egy kívülről végzett portszkennelés adja:

nmap -Pn -p- --min-rate 1000 AZ.ON.SZERVER.IP.CIME

2. Tartsa a 9014-es portot és az adatbázist a nyitott hálózaton kívül

A 9014-es port az a csatorna, amelyen a játékszerver bejelentkezik a login szerverhez, és semmilyen körülmények között nem való a nyitott hálózatba. Az L2J ehhez már a helyes alapértéket szállítja: a LoginHostname = 127.0.0.1 a loopback interfészhez köti a portot, kívülről tehát egyáltalán nem érhető el. Ha a login szerver és a játékszerver két különböző gépen fut, a * helyett a konkrét belső címet írja be, és a portot kizárólag az ellenoldal számára nyissa meg.

Ugyanez a szabály vonatkozik az adatbázisra. Ellenőrizze a /etc/mysql/mariadb.conf.d/50-server.cnf fájlban, hogy ez áll-e benne:

bind-address = 127.0.0.1

És cserélje le az adatbázis-felhasználót. A mellékelt Server.properties a Login = root értéken áll, és maga a fájl fűzi hozzá megjegyzésként, hogy pontosan ez nem ajánlott. Hogy hogyan hoz létre saját, minimális jogú felhasználót, azt a MariaDB és MySQL biztonságossá tétele írja le. Utána ellenőrizze az eredményt:

ss -lntp | grep -E ':9014|:3306'

A fölötte lévő tűzfal rövid marad. Egy Lineage 2 szerverhez két kifelé nyitott port elegendő, méghozzá pontosan ebben a sorrendben, hogy ne zárja ki saját magát:

ufw allow 22/tcp comment 'SSH'
ufw allow 2106/tcp comment 'L2 Login'
ufw allow 7777/tcp comment 'L2 Game'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

A teljes útmutatót a menekülőúttal együtt itt találja: UFW tűzfal beállítása úgy, hogy ne zárja ki saját magát.

3. Kapcsolja ki az AcceptNewGameServer beállítást, amint a szervere regisztrálva van

A LoginServer.properties fájlban gyárilag az AcceptNewGameServer = True áll, és a fölötte lévő megjegyzés pontosan leírja, mit jelent ez: bármelyik játékszerver regisztrálhat a login szervere egy szabad helyére. Amíg a 9014-es port csak a loopback interfészen figyel, ennek nincs következménye. Amint a port valamilyen más okból elérhetővé válik, nyitott ajtó lesz belőle. Állítsa ezért False értékre, amint a saját játékszervere egyszer regisztrált és megkapta az azonosítóját:

AcceptNewGameServer = False

A játékszerver oldalán lévő párja az AcceptAlternateID = True. Ez a felépítés közben kényelmes, mert a login szerver ilyenkor másik azonosítót ad, ha a kívánt foglalt. Éles rendszeren ennek az ellenkezőjét akarja: fix azonosítót, és hibát, ha az foglalt.

4. Állítsa be helyesen a login szerver flood protectionjét

Az L2J saját kapcsolatféket hoz magával a login szerverben. A LoginServer.properties fájlban áll, és minden időérték ezredmásodpercben értendő:

EnableFloodProtection = True
FastConnectionLimit = 15
NormalConnectionTime = 700
FastConnectionTime = 350
MaxConnectionPerIP = 50

Az értékek összefüggenek. Az a kapcsolat, amely ugyanabból a forráscímből az előzőnél kevesebb mint FastConnectionTime idővel később érkezik, gyorsnak számít. FastConnectionLimit darab ilyen kapcsolat után a cím elutasításra kerül. A NormalConnectionTime az a távolság, amelytől a számláló újra leépül. A MaxConnectionPerIP az egyidejűleg nyitott kapcsolatok felső határa címenként.

Ötven egyidejű kapcsolat egyetlen játékosnak nagyon bőkezű, és az alacsonyabb értékek érezhetően segítenek. Mégis óvatosnak kell lenni: az egy háztartásban lévő több játékos, egy internetkávézó és mindenekelőtt a carrier NAT mögötti előfizetések (az L2-szcénában ez sok törökországi, brazíliai és kelet-európai játékost érint) egyetlen nyilvános címen osztoznak. Aki itt 3-ra állítja, valódi játékosokat zár ki. Mérjen előbb egy hetet normál üzemben, utána lépésenként csökkentsen.

És egy korlát, amelyet ismernie kell: ez a fék a login szerver Java-folyamatában fut. Minden csomag, amelyről dönt, már végigment a vonalán, és már gépidőt is felemésztett. Egy maroknyi forrás ellen hatásos, egy botnet ellen nem.

5. Korlátozza a sikertelen kísérleteket, és használja a banned_ip.cfg fájlt

A LoginServer.properties két további direktívája szabályozza, meddig találgathat valaki:

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

A LoginTryBeforeBan az érvénytelen fiók és jelszó kombinációk száma, amely után a cím tiltásra kerül, a LoginBlockAfterBan pedig a tiltás időtartama másodpercben (a 900 tizenöt percnek felel meg). Utána a számlálás elölről kezdődik.

A tartós tiltásokat a login szerver konfigurációs könyvtárában lévő banned_ip.cfg fájlba írja be. Megengedettek az egyes címek, a teljes hálózatok és egy opcionális lejárati időpont Unix-időbélyegként, ezredmásodpercben, a # jel utáni rész pedig megjegyzés:

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

Állítsa ezen felül az AutoCreateAccounts értékét False-ra. Az alapértelmezett True minden ismeretlen fióknévvel történő bejelentkezésnél automatikusan létrehoz egy fiókot. Ez a felépítés közben praktikus, üzem közben viszont ajándék: egy támadó ezzel tetszőleges számú fiókot hoz létre, és mindegyik lekérdezheti a szerverlistát a játékszervere címével. Hagyja inkább, hogy a fiókok a weboldalán lévő regisztráción keresztül jöjjenek létre, akkor ön dönti el, ki kap azonosítót.

6. Korlátozza a kapcsolati rátákat a 2106-os és a 7777-es porton a kernelben

Amiről a Java-fék túl későn dönt, arról a kernel korábban és olcsóbban dönt. A kis támadások és a trehányul megírt botok ellen egy forráscímenkénti felső határ segít:

iptables -I INPUT -p tcp --dport 2106 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 2106 --syn -m hashlimit --hashlimit-name l2login --hashlimit-mode srcip --hashlimit-above 6/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 6 --connlimit-mask 32 -j DROP

Az első szabály eldobja a login szerverhez irányuló új kapcsolatokat, amint egy címnek egyszerre több mint nyolc van nyitva. Egy szabályos kliensnek pontosan egy kell. A második az új kapcsolatok arányát címenként másodpercenként hatra korlátozza, húszas pufferrel, ami egy szerver-újraindítás utáni újracsatlakozási rohamot még átenged. A harmadik a játékszerveren címenként hat egyidejű kapcsolatot enged, mert a többszörös bejelentkezés (dualbox és triplebox) a Lineage 2-ben megszokott, és a túl szűk határ a fizető játékosait érinti.

Mindhárom szám kiindulási érték, nem igazság. Egy 2000 egyidejű játékossal működő szerver máshogy viselkedik, mint egy 200 játékossal működő. Előbb mérjen, utána állítson. A puszta iptables-szabályok egy újraindítás után eltűnnek, Debian és Ubuntu alatt így menti el őket:

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

UFW alatt az ilyen szabályok a /etc/ufw/before.rules fájlba valók, különben a következő ufw reload parancsnál eltűnnek.

7. SYN-flood elfogása: syncookies, backlog és kapcsolatkövetés

Mivel a Lineage 2 kizárólag TCP-n fut, a SYN-flood a kézenfekvő vektor. A SYN-flood olyan támadás, amely hamisított feladócímekkel küld kapcsolatkéréseket, és a visszaigazolásra soha nem válaszol, így a szerver minden kéréshez memóriát foglal, amelyet aztán soha nem használ fel. Négy beállítás enyhíti ezt:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_synack_retries=2

A SYN-cookie-k ebből a legfontosabb sor: a kernel úgy válaszol a kérésre, hogy semmit nem jegyez meg, és az állapotot csak akkor hozza létre, amikor az ellenoldal valóban felépíti a kapcsolatot. A hamisított feladók ezzel a semmibe futnak. Tartósan az értékek egy /etc/sysctl.d/ alatti fájlba kerülnek, és a sysctl --system paranccsal töltődnek be.

Gyakran figyelmen kívül hagyott szűk keresztmetszet a kernel kapcsolatkövetése. Ha megtelik, a szerver a jogos csomagokat is eldobja, a naplóban pedig ez áll: „nf_conntrack: table full, dropping packet". Az állapotot és a felső határt ez mutatja meg:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. Weboldal, login szerver és játékszerver külön IP-címekre

A projekt weboldala a regisztrációval, az adománybolttal és a szavazóoldalakkal a domainjén keresztül mindig megtalálható. Ha ugyanazon az IP-címen van, mint a login szerver, akkor a weboldal elleni támadás egyszerre a bejelentkezést is megbénítja, és fordítva. Ossza szét a három szerepet különböző címekre. Akkor a weboldal elleni támadásnál a játék elérhető marad, a 2106-os port elleni támadásnál pedig a már csatlakozott játékosok tovább játszanak.

Tartsa közben rendben a DNS-bejegyzéseket. A leggyakoribb hiba egy korábbi címre mutató, elfelejtett A-rekord: ez minden címcserét hatástalanná tesz, mert a támadó ugyanazon a néven találja meg az új címet, mint a játékosai.

És ide őszinteség kell, nem vágyálom: a login szervere címét nem lehet titokban tartani. Ott áll az l2.ini fájlban a System mappában, amelyet minden játékos letölt. A játékszerver címét viszont maga a login szerver osztja szét: az L2J-ben külső címként az ipconfig.xml fájlban áll (a régebbi leszármazottakban ExternalHostname néven a Server.properties fájlban), és minden sikeresen bejelentkezett kliens megkapja. A rejtőzködés nem stratégia, a szűrés az.

9. Naplózzon, hogy éles helyzetben legyenek adatai

A legfontosabb lépés az, amelyet szinte senki nem tesz meg előre: hozzon létre összehasonlítási alapot, amíg minden normálisan megy. 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 szombat 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
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 'tcp port 2106' -c 200 -q

A második sor a Lineage 2-nél a legbeszédesebb: a félig nyitott kapcsolatokat számolja. Egy ötjegyű érték néhány száz játékos mellett SYN-flood és semmi más. A tcpdump-nál érvényes: mindig korlátozza a -c kapcsolóval, egy teljes terhelés alatt készült rögzítés az amúgy is túlterhelt szervert tovább terheli. Hogy az értékeket hogyan értékelje ki, azt a DDoS-támadás felismerése írja le.

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

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

Számoljon egyszer utána. Egy átlagos játékszerver 1 Gbit/s-en lóg, ez másodpercenként 125 megabájt, és a vonal megtelik, amint valaki többet küld. Egy Lineage 2 szerver ellen ehhez még nagy támadás sem kell, mert a második mennyiség korábban üt: a csomagsebesség. A 64 bájtos kis csomagokból egy 1 Gbit/s-es vonalba másodpercenként körülbelül 1,49 millió fér. Egy átlagos szerverkernel a CPU-tól és a hálózati kártyától függően ebből néhány százezret dolgoz fel, mielőtt eldobni kezdene.

Egy tisztán TCP-s játéknál egy harmadik korlát is belép. Minden félig nyitott kapcsolat lefoglal egy bejegyzést a kapcsolatkövetésben és a backlogban, az L2J login szervere pedig akár 60 másodpercig tartja a munkameneteit. Egy másodpercenként néhány százezer csomagos támadás, amely a vonalát még harmadáig sem tölti ki, tehát teljesen blokkolhatja a bejelentkezést. Az üzemeltetők ezt így élik meg: „a kihasználtság nem is volt magas, mégsem jutott be senki".

Hogy milyen nagyságrendek fordulnak elő a valóságban: a KernelHost szerverein többek között egy játékszerver ellen irányuló, másodpercenként több mint 8,7 millió csomaggal járó, több mint 112,2 Gbit/s-es támadást és egy hangszerver ellen irányuló, másodpercenként több mint 41,5 millió csomaggal járó, több mint 473,4 Gbit/s-es multivektoros támadást szűrtünk ki. Erre nincs helyi beállítás. A volumetrikus támadásoknak a szerver előtti hálózatban kell véget érniük. Hogy akut esetben mi a teendő, azt a Súlyos DDoS-támadás: mi a teendő? írja le.

Mit állít ez ellen a KernelHost

Az állandó védelem, amely minden szerverben benne van

A KernelHost DDoS-védelme kétlépcsős felépítésű és tartósan aktív, anélkül hogy bármit be kellene kapcsolnia, megrendelnie vagy beállítania:

• 1. lépcső: 17 Tbps mitigációs kapacitás a globális scrubbing hálózatban. A volumetrikus támadásokat a forrásukhoz közel tisztítjuk ki, mielőtt elérnék az adatközpontot.
• 2. lépcső: 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őször reagálnia egy támadásra, nincsenek tehát percek az elején, amikor a szerver nem elérhető. Kifejezetten egy grand openingnél ez a különbség a sikerült és az elvesztett indulás között. És nincs nullrouting: az ön IP-címe a hálózatban marad, csak a káros csomagokat dobjuk el. Aki kiveszi az IP-címet a hálózatból, ugyanazt az eredményt éri el önnél, mint a támadó. Hogy mely játékokra és protokollokra terjed ki a védelem, azt a Játékszerverek valós idejű DDoS-védelme sorolja fel.

Advanced DDoS Protection a tartósan lőtt projektekhez

Egyes projekteket nem alkalomszerűen, hanem célzottan és heteken át támadnak, és a Lineage 2 szcénában ez a normális eset minden olyan szervernél, amely felkerül a szerverlisták felső helyeire. Erre való az Advanced DDoS Protection havi 50,00 EUR díjtó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édelmi 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.
• 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 2106 TCP porton és mi a 7777 TCP porton. Lineage 2-nél ez a döntő pont, mert a két portnak teljesen eltérő a forgalmi mintája: sok rövid kapcsolat az egyik oldalon, kevés nagyon hosszú a másikon.
• A változtatások valós időben érvényesülnek, így futó támadás közben is utánaállíthat, a szabályokat pedig a nyitás órája előtt szigorúbbra állíthatja, utána újra lazíthat.
• Az alkalmazáshoz illő védelmi profil, módosított és saját szerverfájlokhoz is, tetszőleges TCP- vagy UDP-portokon. Hogy L2J-t, L2J-Mobiust, aCist vagy L2OFF-csomagot üzemeltet-e, a szabályrendszer szempontjából mindegy, mert az portra és protokollra épül.

A két lépcső összehasonlítása

A legtöbb Lineage 2 projektnek elegendő a beépített állandó védelem egy rendes szerverkonfigurációval együtt. Az Advanced DDoS Protection arra a helyzetre válasz, amikor valaki személyes ügyet csinál belőle, és ez tapasztalat szerint a grand opening előtti héten történik meg.

Gyakori hibák és megoldások

„A login nem megy, de a játékszerver normálisan fut": Ez nem véletlen, hanem egy Lineage 2 szerver elleni támadás szokásos formája. A login szerver és a játékszerver két folyamat két porton. Mérjen a ss -tn state syn-recv | wc -l és a sar -n DEV 1 10 paranccsal. Ha a félig nyitott kapcsolatok száma emelkedik, miközben a sávszélesség feltűnésmentes marad, akkor kapcsolati flood zajlik a 2106-os porton.

„Cseréltem az IP-címet, és másnap újra offline voltam": A támadó ugyanazon az úton jut hozzá az új címhez, mint a játékosai, vagyis a módosított l2.ini fájlt tartalmazó új System mappán, a bejelentésén vagy egy elfelejtett DNS-bejegyzésen keresztül. A címcsere időnyerés, nem megoldás.

„A MaxConnectionPerIP értékét 3-ra állítottam, most panaszkodnak a játékosok": A dualbox a Lineage 2-ben megszokott, és a carrier NAT mögötti játékosok több százan osztoznak egy nyilvános címen. Menjen vissza egy olyan értékre, amely lefedi a normál üzemben mért értékeit, és inkább az új kapcsolatok arányát korlátozza a kernelben.

„Az iptables-szabályaim nem fognak": Három ok gyakori. A szabályok az UFW-láncok mögött állnak, és a forgalom soha nem éri el őket; az utolsó újraindítás után eltűntek (ilyenkor a netfilter-persistent save vagy egy bejegyzés a /etc/ufw/before.rules fájlban segít); vagy a támadás volumetrikus, és a szabály helyesen dolgozik egy olyan vonalon, amely már tele van. Ellenőrizze az iptables -L INPUT -n -v paranccsal, hogy emelkednek-e a találatszámlálók. Ha nullán maradnak, a szabályt nem éri el a forgalom.

„Minden játékosnak lagspike-jai vannak, a vonal viszont nyugodt": Akkor ez nem DDoS-támadás. Egy Java-szervernél a szokásos gyanúsítottak a szemétgyűjtés szünetei, egy megfelelő indexek nélküli adatbázis, valamint egy ciklusba került szkript vagy egyedi event. Először a sar -n DEV 1 10 parancsot nézze meg: ha a csomagsebességek normálisak maradnak, az ok a szerverben van, nem a hálózatban.

„Az eddigi szolgáltatóm letiltotta az IP-címemet": Ez a nullrouting. A szolgáltató ezzel a saját hálózatát védi, önnek viszont az eredmény azonos egy sikeres támadással, többnyire még órákig utána is. Kétség esetén kérdezze meg, hogy szűrnek-e vagy nullroutolnak. 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 semmi nem érkezik. Ez a normális eset működő szűrésnél. Fordítva viszont igaz: ha a vonal telített, adott esetben már az az SSH-munkamenet sem ér el önhöz, amellyel mérni szeretett volna. Használja ilyenkor az ügyfélfiókban lévő VNC-konzolt, amely a vendégrendszer hálózatától függetlenül működik.

„Két hét múlva van a grand openingem": Akkor most költözzön, és ne az indulás hetében. Egy költözés egy új System mappába kerül a játékosoknak, egy DNS-átállításba és egy próbafutásba. Mindezt maga mögött akarja tudni, mielőtt bejelenti a dátumot, mert a bejelentéstől kezdve minden konkurense ismeri az ön legkedvezőtlenebb időpontját.

Röviden összefoglalva

• Egy privát Lineage 2 szervernek pontosan két portra van szüksége a nyitott hálózatban: 2106 TCP a login szerverhez és 7777 TCP a játékszerverhez. A 9014-es port, az adatbázis (L2J-nél 3306, L2OFF-nál 1433) és a belső L2OFF-portok (2002, 2006, 2008, 2104 és 2108) nem tartoznak ide.
• A Lineage 2 kizárólag TCP-n fut, és nincs sem query portja, sem RCON-portja. A tipikus támadás ezért SYN- vagy kapcsolati flood a 2106-os porton, nem pedig UDP-flood.
• A login szerver elleni támadás csak az új bejelentkezéseket blokkolja. Ha senki nem jut be, miközben a világban lévő játékosok tovább játszanak, az okot a 2106-os porton kell keresni, nem a 7777-esen.
• Állítsa be tudatosan az EnableFloodProtection, a MaxConnectionPerIP, a LoginTryBeforeBan és az AutoCreateAccounts értékét, tegye az AcceptNewGameServer beállítást a regisztráció után False-ra, és korlátozza a kapcsolati rátákat a kernelben is, mert a Java-fék csak a vonal mögött kapcsol be.
• A Lineage 2 szerverek elleni támadások a szerverindításoknál sűrűsödnek, mert a dátum és az időpont hetekkel korábban nyilvános, és a gazdasági kár a nyitás napján a legnagyobb. A védelemnek a bejelentés előtt kell állnia, nem utána.
• A vonal kapacitása felett és másodpercenként néhány százezer csomag felett kizárólag a szerver előtti hálózatban végzett szűrés dönt. A KernelHostnál ez kétlépcsős, tartósan aktív, felár nélküli és nullrouting nélküli.

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 tapasztal, nyisson support ticketet, hogy az IP-címéhez tartozó szűrési szabályokat utánaállítsuk. Futó támadás esetén ezen felül a WhatsApp-vészhelyzeti chaten is elér minket a +43 650 8209883 számon.