Conan Exiles szerver védelme a DDoS-támadások ellen

Ha egy Conan Exiles szerver éppen a raid-ablak kezdetén válik elérhetetlenné, annak ritkán van hardveres oka. Az esetek túlnyomó részében támadás fut, méghozzá pontosan akkor, amikor a legnagyobb kárt okozza. Ez a cikk megmutatja, miért van szükségük a Conan Exiles szervereknek DDoS-védelemre, mit tud Ön a következő tíz percben többletköltség nélkül saját maga bebiztosítani, hol érnek véget ezek az intézkedések műszakilag, és minek kell utána a szerver előtti hálózatban történnie.

Minden adat a Funcom dedikált szerverére vonatkozik, tehát a ConanSandboxServer.exe illetve a StartServer.bat fájlra. A konfiguráció három fájlban található a ConanSandbox\Saved\Config\WindowsServer\ könyvtárban: ServerSettings.ini, Engine.ini és Game.ini. Ez akkor is így van, ha a szervert Linux alatt, kompatibilitási rétegen keresztül üzemelteti, mert a Funcom kizárólag a Windows-alkalmazást adja ki, és az útvonal ezért ott is WindowsServer.

Ha a támadás éppen fut: először mentse el a mérési értékeket (9. szakasz), a támadás után már nem lesznek meg. És most ne szerkesszen INI-fájlt. A Conan Exiles a memóriában tartja a konfigurációját, és leálláskor írja vissza, így a futó szerveren végzett minden módosítás elvész.

Miért van szükségük a Conan Exiles szervereknek DDoS-védelemre

A legtöbb játéknál egy szerverkiesés bosszantó. A Conan Exilesnál egy PvP-szerveren ez játéklépés. A veszteségek véglegesek, egy bázis csak egy meghatározott időablakon belül sérülhet, és aki a védőket ebben az ablakban kiveszi a játékból, az senki ellen raidel. A támadásnak így konkrét haszna és előre ismert időpontja van, és megismétlődik, amint egyszer működött.

Az időablak nem titok. A ServerSettings.ini fájlban a RestrictPVPTime szabályozza a játékosok közötti harcot, a RestrictPVPBuildingDamageTime pedig az épületek sérülését, és minden üzemeltető önként beleírja a szerver nevébe, a szabályzatba és a Discordba, mert a játékosok különben nem ismernék. A támadónak tehát semmit nem kell kifürkésznie: onnan olvassa le a raid-időt, ahol azt hirdetik, és ugyanarra az órára időzíti a támadását.

A ráfordítás a másik oldalon eközben minimális. Az úgynevezett booter- vagy stresser-szolgáltatások percre pontosan árulnak egy adott IP-cím és egy adott port elleni áradatot. Egy 7777 UDP elleni port-DDoS sem játékhozzáférést, sem a szerverről szóló tudást nem feltételez, elég hozzá a cím és a portszám. Pontosan ezért a kis szervereket ugyanolyan megbízhatóan eltalálja, mint a nagyokat.

Ehhez jön egy sajátosság, amely a Conan Exilest a legtöbb túlélőjátéktól megkülönbözteti. A ServerSettings.ini ismeri a LogoutCharactersRemainInTheWorld kapcsolót. Ha True értéken áll, a játékos karaktere a kapcsolat megszakadása után is a világban marad, ahelyett hogy eltűnne. Egy támadás, amely az összes játékost egyszerre dobja ki a játékból, ilyenkor mozdulatlan figurák sorát hagyja hátra, a felszerelésükkel együtt. Hogy egy ilyen támadásnál műszakilag mi történik, azt a Mi az a DDoS-támadás? cikk írja le.

Műszakilag a teljes játékforgalom UDP-n keresztül megy. Az UDP nem ismer kapcsolatfelépítést, amelyet meg lehetne követelni, a feladó címe pedig hamisítható. A támadónak tehát sem belépnie nem kell a szerverére, sem szabályosan megszólítania azt ahhoz, hogy terhelést keltsen. Azt sem kell tudnia, hogy online van-e valaki.

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

Egy Conan Exiles szervernek kifelé pontosan három UDP-portra van szüksége: 7777, 7778 és 27015. Minden további vagy opcionális, vagy egyáltalán nem való a nyílt hálózatba. A Funcom így dokumentálja a kiosztást:

Három dolgot rontanak el ebben rendszeresen. Először is a 7778 nem szabadon választható port, hanem mindig a játékport plusz egy. Aki két példányt üzemeltet ugyanazon a gépen, annak ezért kettesével kell lépkednie: 7777 és 7778 az elsőnek, 7779 és 7780 a másodiknak, ehhez jön 27015 és 27016 lekérdezőportként. Aki a második példányt a 7778-ra teszi, az elveszi az elsőtől a pingert.

Másodszor a 7777-es TCP-engedélyezés a modátvitel. A Funcom csak egy kliens kérésére nyitja meg, és kizárólag az Epic Games Store kliensei kérik. A Steam-kliensek a modokat továbbra is a Steam Workshop felületén keresztül töltik le. Ha a játékosai kizárólag Steamen keresztül érkeznek, erre az engedélyezésre nincs szüksége.

Harmadszor az RCON gyárilag ki van kapcsolva. A RconEnabled alapértelmezés szerint 0 értéken áll. Aki a portot mégis nyitva találja, az saját maga kapcsolta be, vagy egy szolgáltató kész sablonját vette át.

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

A következő kilenc lépés semmibe nem kerül, és az ellen hat, ami a gyakorlatban a leggyakrabban előfordul: kis, célzott áradatok néhány forrásból, visszaélésre használt lekérdezőportok, bejelentkezési kísérletek az RCON-on és egyetlen módosítás okozta túlterhelés. Akkor is megérik, ha a szerver előtt már dolgozik egy hálózati szűrő.

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. Windows alatt:

Get-NetUDPEndpoint | Where-Object LocalPort -in 7777,7778,27015
Get-NetTCPConnection -State Listen | Sort-Object LocalPort
netstat -ano -p UDP | findstr "7777 7778 27015"

Ha a szerver Linux alatt, kompatibilitási rétegben fut, a megfelelője:

ss -lnup
ss -lntp

Az érdekes oszlop a helyi cím. A 0.0.0.0:7777 azt jelenti, hogy „az egész internetről elérhető”, a 127.0.0.1:25575 azt, hogy „csak helyben”, és nem igényel tűzfalszabályt. A támadó nézőpontját egy kívülről indított portszkennelés adja, méghozzá kifejezetten UDP-re is, mert egy tisztán TCP-alapú szkennelés a Conan Exilesnál szinte semmit nem talál:

nmap -Pn -sU -p 7777,7778,27015 A.SZERVER.IP.CIME
nmap -Pn -p 7777,25575 A.SZERVER.IP.CIME

2. Csak a három UDP-portot nyissa meg

Windows alatt két szabály elég a beépített tűzfalban. Az első megnyitja a játékforgalmat, a második az RCON-t a saját címére korlátozza, ahelyett hogy a portot mindenki számára megnyitná:

New-NetFirewallRule -DisplayName "Conan Exiles" -Direction Inbound -Protocol UDP -LocalPort 7777,7778,27015 -Action Allow
New-NetFirewallRule -DisplayName "Conan RCON" -Direction Inbound -Protocol TCP -LocalPort 25575 -RemoteAddress 203.0.113.10 -Action Allow
Get-NetFirewallRule -DisplayName "Conan*" | Format-Table DisplayName,Enabled,Direction,Action

Linux alatt ugyanez UFW-vel így néz ki, méghozzá pontosan ebben a sorrendben, hogy ki ne zárja saját magát:

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'Conan Exiles'
ufw allow 7778/udp comment 'Conan Exiles pinger'
ufw allow 27015/udp comment 'Conan Exiles lekerdezoport'
ufw allow from 203.0.113.10 to any port 25575 proto tcp comment 'RCON'
ufw default deny incoming
ufw --force enable
ufw status verbose

A 203.0.113.10 helyére írja be a saját címét. A teljes útmutató a mentőúttal együtt az UFW-tűzfal beállítása anélkül, hogy kizárná magát cikkben olvasható. A 7777-es TCP-engedélyezést hagyja el mindaddig, amíg egyetlen játékosa sem az Epic Games Store-on keresztül érkezik.

3. Az RCON bebiztosítása vagy teljes kikapcsolása

Az RCON távvezérlés, teljes hozzáféréssel a szerveréhez: játékosok kirúgása, kitiltása, üzenetek küldése, parancsok futtatása. A 25575-ös TCP-porton fut, és a Game.ini fájlban konfigurálható:

[RconPlugin]
RconEnabled=0
RconPort=25575
RconPassword=
RconMaxKarma=60

Ha nincs szüksége az RCON-ra, hagyja a RconEnabled=0 beállítást. Ez az alapértelmezés és egyben a legbiztonságosabb beállítás. Ha szüksége van rá, három szabály érvényes. Először: a RconPassword legyen hosszú és véletlenszerű, mert az RCON-protokoll titkosítatlanul viszi át a jelszót a vonalon. Másodszor: a port nem a nyílt internetre való, hanem a saját címére korlátozva vagy egy SSH-hozzáférés mögé. Harmadszor: a RconMaxKarma a beépített védelem a bejelentkezési áradatok ellen, alapértéke 60. A számláló korlátozza, hány kérést adhat le egy forrás rövid egymásutánban, mielőtt elutasítanák.

Egy nyitott RCON-port ráadásul megbízható jelzés arról, hogy Ön jelen van a hálózaton. Aki széles körben szkenneli a 25575-öt, játékszervereket talál, és egy szűrés nélküli játékszerver kifizetődő célpont.

4. A lekérdezőportot korlátozza, ne zárja be

A 27015 UDP Steam-formátumú állapotlekérdezésekre válaszol. Az A2S-lekérdezés rövid UDP-kérés, amellyel egy kliens a szerver nevét, a térképet, a játékosszámot és a játékidőt kéri le anélkül, hogy elindítaná a játékot. Pontosan erre van szüksége a szerverlistának, az Ön állapotoldalának és minden Discord-botnak, amely a játékosok számát mutatja.

Ne zárja be ezt a portot. A szervere különben eltűnik a szerverlistából, és az új játékosok nem találják meg. A helyes kezelés egy forráscímenkénti felső korlát. Linux alatt:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name conan_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -L INPUT -n -v | head -20

Másodpercenként tíz lekérdezés forrásonként elég a valódi játékosoknak és minden monitorozásnak, de eldobja azt a forrást, amely másodpercenként több ezer kérést küld. Mentse el a szabályt az apt-get install -y iptables-persistent és a netfilter-persistent save paranccsal, különben a következő újraindítás után nincs meg. UFW alatt a /etc/ufw/before.rules fájlba tartozik.

Itt azonban van egy kemény határ, és ez a Conan Exiles üzemeltetők többségét érinti: a Windows tűzfala nem ismer forráscímenkénti korlátozást. Meg tud nyitni egy portot, be tudja zárni, vagy rögzített címekre tudja korlátozni, de azt nem tudja mondani, hogy „legfeljebb tíz csomag másodpercenként és feladónként”. Egy Windows-szerveren erre a feladatra egyszerűen nincs beépített eszköz, és a korlátozásnak a szerver előtti hálózatban kell megtörténnie.

A második pont az ellenkező irányú visszaélést érinti. A reflexió azt jelenti: a támadó hamisított feladócímmel küld lekérdezéseket több ezer játékszervernek, és a válaszok mind egy harmadik félnél futnak össze. Mivel egy A2S-válasz nagyobb, mint a kérés, a forgalom útközben megsokszorozódik. A szervere ilyenkor nem az áldozat, hanem a fegyver, és Ön fizeti a kimenő forgalmat. A Valve erre kérdés-válasz eljárást vezetett be: a szerver egy A2S-lekérdezésre először visszakérdezéssel válaszolhat, amelyet hamisított címmel dolgozó feladó nem tud megválaszolni. Ez csak ott hatásos, ahol be is van kapcsolva, ezért a 27015 sebességkorlátozása minden esetben hozzátartozik.

5. Szerverjelszó, adminjelszó és férőhelyek

A ServerSettings.ini három olyan beállítást tartalmaz, amelyek közvetlenül döntenek a támadási felületről:

[ServerSettings]
AdminPassword=
ServerPassword=
MaxPlayers=40
IsBattlEyeEnabled=True

Az AdminPassword az egész fájl legkritikusabb értéke. Nem konzolhozzáférés, hanem az a jelszó, amellyel egy szabályosan csatlakozott játékos a játékon belül adminjogot ad saját magának. Egy rövid vagy kitalálható adminjelszó nem lagot jelent, hanem a szerver elvesztését. Állítsa be hosszúra és véletlenszerűre, és cserélje le, amint egy csapattag távozik.

A ServerPassword nyilvános szerverből zártat csinál. Ez a trollok ellen, az eldobható fiókok ellen és mindenki ellen hat, aki a szabályos belépési utat használja. A vonal elleni támadás ellen nem hat: aki elárasztja a szerverét, egyáltalán nem akar csatlakozni. A csomagjait elutasítják, de már megérkeztek, és pontosan ez a lényeg.

A MaxPlayers korlátozza a férőhelyek számát, és a -MaxPlayers= indítási paraméterrel is beállítható. A reális felső korlát egyben védelmi intézkedés is: minden csatlakozott kliens folyamatosan csomagokat termel, és az a szerver, amelynek több férőhelye van, mint amennyit a gép elbír, már normál üzemben is beszakad.

6. Mit nyújt a BattlEye, és mit nem

A Conan Exiles a ServerSettings.ini fájl IsBattlEyeEnabled kapcsolójával csalásellenes ellenőrzést hoz magával. Ennek bekapcsolva kell lennie, de nem DDoS-védelem, méghozzá szerkezeti okból: a csalásellenes rendszer a már csatlakozott klienseket ellenőrzi. Ugyanabban a folyamatban fut, mint a játék, és egy csomagot csak akkor lát, amikor a szerver azt amúgy is feldolgozta. Ha ez a folyamat ki van terhelve, az ellenőrző logika vele együtt megy tönkre.

Ugyanez érvényes minden szerveroldali eszközre, amelyet ezen felül telepít. Minden, ami a szerveren fut, csak olyasmit tud eldobni, ami már megérkezett. A csalásellenes rendszer a játékszabályokat védi, nem a rendelkezésre állást.

7. Tartsa tisztán a modokat

A modifikált Conan Exiles szervereken jelentett kiesések jelentős része nem támadás. A modlista modlist.txt néven ugyanabban a konfigurációs könyvtárban áll, és minden módosítás ugyanabban a folyamatban fut, mint a játék. Egyetlen olyan módosítás, amelyben végtelen ciklus, túl szoros tick vagy korlátlan adatbázis-lekérdezés van, ugyanúgy megállítja a szervert, mint egy támadás, csak éppen feltűnő csomagszámok nélkül.

A megkülönböztetés egyszerű, és mindig az elején kell állnia. Ha a hálózati kártya csomagszáma erősen megnő, miközben a gép alig dolgozik, akkor támadás. Ha a csomagszám normális marad, és mégis minden akadozik, akkor a szoftver az ok. Kétség esetén vegye ki a modlista felét és indítsa újra, ez két menetben leszűkíti az okot.

Egy második, nagyon gyakorlatias pont: egy játékfrissítés után a modok és a szerververzió gyakran már nem illenek össze. A játékosok belépéskor kirepülnek, a Discordon az áll, hogy „szerver down”, és mindenki olyan támadást keres, amely nem is létezik. Minden frissítés után először a modlistát ellenőrizze.

8. A cím és a raid-idő

Az IP-címét nem lehet titokban tartani. Benne áll a szerverlista-bejegyzésben, mert különben senki nem tudna csatlakozni, és ismeri minden játékos, aki egyszer már kapcsolódott. A címcsere időt nyer, de nem megoldás: a támadó ugyanabból a forrásból olvassa ki az új címet, mint a régit, többnyire perceken vagy órákon belül.

Két szokás mégis segít. Sehol ne tegye közzé saját maga a nyers IP-címet, tehát se a Discordon, se a projektoldalon, és a játékosait hostnéven keresztül kösse be, hogy egy címcsere ne törjön el minden hivatkozást. A klasszikus hiba ilyenkor egy elfelejtett A-rekord a régi címre, amely minden cserét hatástalanná tesz.

A raid-időnél az elrejtés ellenkezője érvényes: nyilvánosan kell tartania, különben nem működik a szervere. Használja inkább a diagnózishoz. Ha a szervere három estén egymás után 18:05-kor esik ki, és a raid-ablaka 18:00-kor kezdődik, az már nem feltételezés, hanem minta, amelyet egy hibajegyhez csatolhat.

9. Mérjen, ne találgasson

A legfontosabb lépés az, amelyet előtte szinte senki nem tesz meg: összehasonlítási alapot kell 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 egy telt házas péntek este. Windows alatt ehhez elegendők a beépített eszközök:

Get-NetAdapterStatistics
typeperf "\Network Interface(*)\Packets Received/sec" -sc 20
typeperf "\Network Interface(*)\Bytes Received/sec" -sc 20

Linux alatt a megfelelője:

sar -n DEV 1 10
ip -s link show eth0
tcpdump -ni eth0 udp port 7777 or udp port 27015 -c 200 -q

A tcpdump esetében érvényes: mindig korlátozza a -c kapcsolóval, mert egy teljes terhelés alatt készült rögzítés az amúgy is túlterhelt szervert tovább terheli. A Conan Exiles szervernaplója a ConanSandbox\Saved\Logs\ könyvtárban található, és a -log indítási paraméterrel egy ablakba is kiíródik. A mentett játékállás egyetlen fájlként a ConanSandbox\Saved\game.db útvonalon van: mentse el, mielőtt nyomás alatt bármit átállítana. Hogy a mérési értékeket hogyan értékelje ki, azt a DDoS-támadás felismerése cikk írja le.

Hol érnek véget ezek az intézkedések: sávszélesség és csomagszám

Most az a rész következik, amelyet semmilyen INI-fájl nem 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 nem tudja meg nem küldötté tenni.

Számoljon utána egyszer. Egy tipikus játékszerver 1 Gbit/s-os vonalon lóg, ez 125 megabájt másodpercenként, és a vonal tele van, amint valaki ennél többet küld. A túlélőjáték-szerverek elleni támadások szokásosan 5 és 50 Gbit/s között vannak, tehát a vonala öt-ötvenszeresén. Hogy a mögötte lévő szabálya jó-e, akkor már nem számít, mert a játékosai csomagjai már előtte sem jutnak át.

A második mennyiség a csomagszám, és ez majdnem mindig hamarabb üt be, mint a sávszélesség. 64 bájtos kis csomagoknál egy 1 Gbit/s-os vonalba körülbelül 1,49 millió csomag fér másodpercenként. Egy normál szerver a processzortól és a hálózati kártyától függően ennek néhány százezrét dolgozza fel, mielőtt elkezdene eldobni. Egy támadás, amely a vonalát még harmadáig sem tölti meg, tehát ettől függetlenül megbéníthatja a Conan Exiles szerverét, mert a számítási idő az eldobásra megy el. Az üzemeltetők ezt így élik meg: „a terhelés nem is volt magas, mégis minden elérhetetlen lett”.

A Conan Exilesnál súlyosbítja a helyzetet, hogy a teljes játékvilág egyetlen folyamatban fut. Nincs második példány, amely tovább futna, amíg az első el van foglalva. Amint ez a folyamat nem kap több számítási időt, egyszerre áll le a harc, az építés és a mentés.

A nagyságrendek besorolásához, amelyek valóban előfordulnak: a KernelHost szerverein többek között egy 473,4 Gbit/s feletti támadást szűrtek ki másodpercenként több mint 41,5 millió csomaggal egy hangszerver ellen, és 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 ez ellen 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, meg kellene rendelnie 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í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ő. A védelem folyamatosan fut, és nem kell előbb egy támadásra reagálnia, tehát nincsenek percek az elején, amikor a szerver elérhetetlen. Pontosan ez számít egy raid-ablaknál, amely amúgy is csak néhány óráig tart. És nincs null-routing: az IP-címe a hálózatban marad, csak a káros csomagokat dobják 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ékszerver-DDoS-védelem valós időben cikk sorolja fel.

Advanced DDoS Protection a tartósan támadott szerverekhez

Egyes szervereket nem alkalmanként, hanem célzottan és heteken át támadnak, rendszerint mindig ugyanabban az órában. Erre való az Advanced DDoS Protection havi 50,00 EUR-tól, PrePaid alapon, minimális futamidő és beállítási díj 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 központi hálózatból, amelyre a szerverét a saját hálózaton belül átállítják. Az Ön oldalán nincs szükség átépítésre.
• Önállóan kezelhető védelmi szabályok portonként és protokollonként az ügyfélportálon: külön állítja be, mi engedélyezett a 7777 UDP-n, a 7778 UDP-n és a 27015 UDP-n. Pontosan ez a szétválasztás hiányzik magán a szerveren, különösen Windows alatt.
• A módosítások valós időben lépnek érvénybe, tehát futó támadás közben is utánaigazíthat, ahelyett hogy a következő reggelig várna.
• A játékhoz illő védelmi profil, ugyanígy a modifikált és a saját alkalmazásokhoz is, tetszőleges TCP- vagy UDP-portokon.

A két szint összehasonlítva

A legtöbb Conan Exiles szerverhez elegendő a beépített folyamatos védelem egy tiszta konfigurációval együtt. Az Advanced DDoS Protection arra a válasz, hogy valaki személyes ügyet csinál belőle. Aki a szerverét jelenleg máshol üzemelteti, és ott rendszeresen kiveszik a hálózatból, az a legmegbízhatóbban költözéssel oldja meg: a szűrés abba a hálózatba tartozik, amelyben a szerver áll.

Gyakori hibák és megoldások

„A ServerSettings.ini fájlban végzett módosításaim az újraindítás után eltűntek”: a szerver a szerkesztéskor még futott. A Conan Exiles a memóriában tartja a konfigurációt, és leálláskor írja vissza a fájlba, amivel felülírja az Ön módosítását. Állítsa le a szervert, várjon, szerkesszen, indítsa el. Ezenkívül a Saved\Config\WindowsServer\ könyvtárban lévő fájlokat szerkessze, ne a mellettük lévő sablonokat, különben a következő játékfrissítés mindent felülír.

„Megváltoztattam a portokat, és most nincs benne a szerver a listában”: a lekérdezőportot nem húzták utána. A játékport és a lekérdezőport két külön érték, és a játékport plusz egyen ülő pingernek szintén szabadnak és engedélyezettnek kell lennie. Vesse össze az Engine.ini fájlban a [URL] Port és a PeerPort értéket a ServerQueryPort értékkel és a tűzfalszabályaival.

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

„Az RCON-naplóban több száz sikertelen bejelentkezés áll”: ez bejelentkezési flood a 25575 TCP-n, és a játéklogikát terheli, nem a vonalat. A RconMaxKarma lefékezi, ténylegesen úgy ér véget, hogy a portot a saját címére korlátozza, vagy az RCON-t a RconEnabled=0 beállítással kikapcsolja.

„Néhány percenként lagcsúcsok vannak, de a szerver soha nincs teljesen offline”: ez a lüktető áradat tipikus képe. Néhány másodperces lökések is elegendők ahhoz, hogy csomagokat dobjon el a rendszer, de minden olyan küszöb alatt maradnak, amely riasztást váltana ki. Ezért másodperces felbontásban mérjen, ne ötperces átlagokban, különben a kiértékelése csak egy feltűnésmentes átlagot mutat, miközben a játékosai néhány percenként kirepülnek a harcból.

„Minden játékosnál akadozik a játék, de a hálózati számlálók feltűnésmentesek”: ez nem DDoS-támadás. Ha a Get-NetAdapterStatistics illetve a sar -n DEV 1 10 a normál tartományban marad, az ok a szoftverben van. Először a modlistát ellenőrizze, utána a szerververziót a modverziókkal szemben.

„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, Önnek viszont az eredmény azonos egy sikeres támadással, többnyire még órákkal utána is. Kétség esetén kérdezzen rá, hogy szűrés vagy null-routing történik. A válasz többet dönt a rendelkezésre állásáról, mint bármilyen hardveres adat.

„A forgalomrögzítésben nem látok semmi feltűnőt”: ha a forgalmat már az előtte lévő hálózatban kiszűrik, a szerverre a várakozásnak megfelelően nem érkezik semmi. Működő szűrésnél ez a normális eset. Fordítva is igaz: ha a vonal telített, adott esetben már a távoli karbantartási hozzáférés sem ér el Önhöz, amellyel mérni szeretett volna. Használja ilyenkor az ügyfélportál VNC-konzolját, amely a vendégrendszer hálózatától függetlenül működik.

Röviden összefoglalva

• Egy Conan Exiles szervernek kifelé pontosan három UDP-portra van szüksége: 7777 a játékforgalomhoz, 7778 a pingerhez és 27015 az állapotlekérdezéshez. A 7777 TCP csak az Epic-kliensek felé történő modátvitelhez kell, a 25575 TCP csak aktív RCON mellett.
• A pinger fixen a játékport plusz egy. Több példányt ugyanazon a gépen ezért kettesével lépkedve kell kiosztani.
• Az RCON a RconEnabled=0 beállítással gyárilag ki van kapcsolva, és maradjon is kikapcsolva mindaddig, amíg nincs rá szüksége. A jelszó titkosítatlanul megy át a vonalon.
• A 27015-ös portot korlátozni kell, nem bezárni: bezárva a szerver eltűnik a szerverlistából, korlátozás nélkül pedig egyszerre célpont és reflektor.
• A Windows tűzfala meg tud nyitni, be tud zárni és címekre tud korlátozni portokat, de forráscímenkénti sebességet nem tud korlátozni. Ez a feladat a szerver előtti hálózatba tartozik.
• 1 Gbit/s-nál a vonal 125 megabájt másodpercenként értéknél tele van, 64 bájtos csomagoknál ez körülbelül 1,49 millió csomag másodpercenként. Efölött már semmilyen helyi szabály nem segít.
• A KernelHostnál 17 Tbps mitigációs kapacitás a globális scrubbing-hálózatban és egy Arbor valós idejű szűrés 3,2 Tbps kapacitással Frankfurt am Mainban folyamatosan együtt szűr, felár nélkül és null-routing nélkül.

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 dátummal, időponttal és a mérési értékeivel, hogy a szűrőszabályokat az IP-címéhez igazítsák. Futó támadás esetén ezen felül a WhatsApp-vészhelyzeti chaten ér el minket a +43 650 8209883 számon.