Arma-3-szerver védelme DDoS-támadások ellen

Aki egy Arma-3-szervert DDoS-támadások ellen akar megvédeni, pontosan öt UDP-porttal van dolga: 2302-től 2306-ig. Egy dedikált szerver, amely este, a bevetés kellős közepén az összes játékos számára egyszerre esik ki, ritkán szenved hardverhibától. Többnyire támadás fut pontosan ezen a portblokkon, méghozzá akkor, amikor a szerverlista a legmagasabb játékosszámot mutatja. Ez a cikk először azt mutatja meg, mit tud Ön többletköltség nélkül saját maga megvédeni, utána azt, hol érnek véget technikailag ezek az intézkedések, végül pedig azt, minek kell a szerver előtti hálózatban történnie.

Minden adat egy dedikált Arma-3-szerverre vonatkozik (SteamCMD-alkalmazás 233780) Debian 12, Debian 13, Ubuntu 22.04 LTS vagy Ubuntu 24.04 LTS alatt. A parancsok root felhasználóhoz készültek, normál felhasználóként tegye eléjük a sudo parancsot. Ha a támadás éppen fut: most ne változtasson a konfiguráción és ne indítsa újra a szervert, hanem előbb mentse ki a mérési értékeket a „Naplózás" szakaszból. A támadás után már nem lesznek meg.

Miért támadják az Arma-3-szervereket, és mikor válik szükségessé a DDoS-védelem

Az Arma 3 több olyan tulajdonságot egyesít, amely kényelmes célponttá teszi a szervert. Először is a szerver maga hozza nyilvánosságra a címét: a 2304-es UDP-porton bejelentkezik a Steam-masterszerverre, a 2303-as UDP-porton pedig névvel, térképpel, játékosszámmal és modlistával válaszol a lekérdezésekre. E két port nélkül senki nem találja meg Önt, velük viszont ott áll az IP-címe minden szerverböngészőben és minden állapotoldalon, amely a szerverböngészőt kérdezi le.

Másodszor a játékosbázis kötött időpontokhoz igazodik. Az Altison és Tanoán futó life-szerepjáték-projektek, az Exile, az Antistasi és a King of the Hill esténként és hétvégén telnek meg, egy este nyolc órai kiesés tehát a lehető legláthatóbb. Harmadszor ott a projektek közötti versengés, a kitiltott játékosok és a belső konfliktusok, egy támadás pedig sem tudást, sem említésre méltó pénzt nem kíván a kiváltójától.

Technikailag jön hozzá a döntő pont: az Arma 3 teljes egészében UDP-n keresztül működik, TCP-re a játékmenethez nincs szüksége. Az UDP nem ismer kapcsolatfelépítést, amelyet meg lehetne követelni, a feladócímek pedig hamisíthatók. A támadónak tehát sem belépnie nem kell a szerverére, sem szabályosan megszólítania ahhoz, hogy terhelést okozzon. Ehhez jön, hogy egy Arma-3-szerver szimulációs ciklusa lényegében egyetlen processzormagon fut: aki elég csomagot küld, ettől az egy magtól vesz el processzoridőt, mégpedig függetlenül attól, hány magja van egyébként a gépnek. Hogy pontosan mi egy DDoS-támadás, azt a Mi az a DDoS-támadás? című cikk magyarázza el.

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

Egy Arma-3-szerver gyárilag a 2302-től 2306-ig terjedő UDP-blokkot foglalja el. A -port=2302 indítási paraméter csak az első portot rögzíti, a másik négy kötötten adódik belőle, mégpedig a játékport plusz 1-től plusz 4-ig. Aki több példányt üzemeltet ugyanazon a gépen, ezért legalább 100 port távolságot hagy (2302, 2402, 2502), különben a példányok elveszik egymás elől a következő portokat.

E nyolc sorból pontosan három való a nyílt internetre: a 2302-es, a 2303-as és a 2304-es UDP-port. Minden más adminisztráció, a nyitva hagyott adminisztrációs portok pedig a leggyakoribb elkerülhető hibát jelentik az Arma-3-szervereken.

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

Ez a szakasz a leghosszabb, és ez szándékos. Egy tisztán konfigurált Arma-3-szerver a kis és közepes támadásokat saját erőből kibírja, függetlenül attól, hol áll.

1. Leltár: mi figyel a szerveren?

Mielőtt egyetlen szabályt is megírna, nézze meg, mit kínál a szervere kifelé. Ne találgasson, nézzen utána:

ss -lntup

Érdekes a helyi címet tartalmazó oszlop. A 0.0.0.0:2302 azt jelenti: „az egész internetről elérhető", a 127.0.0.1:3306 azt jelenti: „csak helyben", és nem kell hozzá tűzfalszabály. A játék mellett egy life-szerveren rendszeresen felbukkan a MariaDB, egy webszerver a frakcióoldalhoz, egy TeamSpeak- vagy hangszolgáltatás és egy elfeledett panel. A támadó nézőpontját egy kívülről indított portszkennelés adja meg:

nmap -Pn -sU -p 2300-2320 AZ.ON.SZERVERENEK.IP.CIME
nmap -Pn -p- --min-rate 1000 AZ.ON.SZERVERENEK.IP.CIME

Az első parancs a játék UDP-blokkját mutatja, a második mindent, ami TCP-n nyitva áll. Egy Arma-3-szervernek a játékmenethez egyetlen nyitott TCP-portra sincs szüksége.

2. Csak azokat a portokat hagyja nyitva, amelyekre az Arma 3-nak tényleg szüksége van

Kifelé három UDP-port elég, minden mást korlátozunk. UFW-vel ez így néz ki, méghozzá pontosan ebben a sorrendben, hogy ne zárja ki saját magát:

ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH'
ufw allow 2302:2304/udp comment 'Arma 3 játék, Steam-query, Steam-master'
ufw allow from 203.0.113.10 to any port 2306 proto udp comment 'BattlEye 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 2305-ös port zárva marad, mert a Bohemia fenntartottként és jelenleg használaton kívüliként tartja nyilván. Fontos az ufw default allow outgoing sor: a BattlEye a szerverről épít kapcsolatot az arma31.battleye.com felé, és ehhez kimenő irányban a 2344-es portra van szüksége TCP-n és UDP-n, valamint a 2345-ösre TCP-n. Aki kimenő irányban mindent letilt, a saját anti-cheatjét zárja ki. Az átállítás után egy valódi csatlakozással ellenőrizze, hogy a BattlEye továbbra is átengedi a játékosait. A teljes útmutató a kimentési úttal együtt az UFW-tűzfal beállítása anélkül, hogy kizárná magát című cikkben olvasható.

Az adatbázisnak semmilyen körülmények között nincs helye a nyílt hálózaton. Az Altis Life és a többi life-keretrendszer az extDB3 kiegészítőn keresztül beszél egy MySQL-adatbázissal, a hozzáférési adatok pedig olvasható szövegként állnak a @extDB3/extdb3-conf.ini fájlban. Ellenőrizze a /etc/mysql/mariadb.conf.d/50-server.cnf fájlban, hogy ez áll-e benne:

bind-address = 127.0.0.1

3. A Steam-query-port hatástalanítása anélkül, hogy kiesne a szerverböngészőből

A 2303-as UDP-port egy nyilvános Arma-3-szerver legérzékenyebb pontja. Ez válaszol az A2S-lekérdezésekre, vagyis a Steam-szerverböngésző szabványos lekérdezésére: az A2S_INFO a nevet, a térképet és a játékosszámot adja vissza, az A2S_PLAYERS a játékoslistát, az A2S_RULES a mod- és aláíráslistát. A lekérdezés egy kis UDP-csomag, a válasz ennek a többszöröse. Az US-CERT a Steam-protokollt a TA14-017A riasztásban 5,5-es sávszélesség-erősítési tényezővel tartja nyilván, az Arma 3-nál pedig különösen nagyra nő a válasz, mert a teljes modlista is vele megy.

Ebből két dolog következik. Először is a szervere erősítőként használható harmadik felek ellen, ha egy támadó hamisított feladócímmel küld lekérdezéseket. Másodszor, és ez az Ön számára a fontosabb, minden lekérdezés processzoridőt vesz el attól az egy magtól, amely a szimulációt viszi. A Bohemia 2015 óta vezet erről egy jegyet (T83469): a játékportra vagy a Steam-query-portra küldött hamisított UDP-csomagok 100 százalékra vitték a processzorhasználatot és befagyasztották a szervert, egy sikeres támadáshoz a query-porton keresztül pedig már 4 Mbit/s is elegendő volt. Ezért veszélyesebb az Arma 3-nál a csomagsebesség, mint a sávszélesség.

Az első fogantyú a válasz mérete. A server.cfg fájlban a steamProtocolMaxDataSize direktíva határozza meg, hány bájtot pakolhat a szerver a lekérdezésre adott válaszába. A nagy modlistákat üzemeltetők 2048-ra vagy feljebb emelik, mert különben a „Query data overflow, Mods/Signatures will not be correctly received by clients" figyelmeztetés kerül a naplóba. Minden emelés viszont pontosan azt a választ növeli, amelyet a támadó felerősít. Ezért állítsa az értéket olyan alacsonyra, amennyire a modlistája még éppen engedi, és takarítsa ki a nem használt modokat az indítóparancsból:

steamProtocolMaxDataSize = 2048;

A második fogantyú egy forráscímenkénti sebességkorlátozás, amely csak a query-portot érinti. Ne zárja le a 2303-as UDP-portot átalányban: a lekérdezésre adott válasz nélkül a szervere eltűnik a szerverböngészőből és minden állapotoldalról, az új játékosok pedig nem találják meg. Egy legitim szerverböngésző percenként néhányszor kérdez le, nem másodpercenként több százszor.

4. Vegye ki a BattlEye-RCont a nyílt hálózatból

A BattlEye az Arma 3 anti-cheatje, és a server.cfg fájlban a BattlEye = 1; sorral kapcsolható be. A hozzá tartozó távvezérlés, a BattlEye RCon, önálló UDP-protokoll, és a BattlEye/beserver_x64.cfg fájlban állítható be (a _x64 kiegészítésű fájl az arma3server_x64 szerverre vonatkozik, ez ma a szokásos):

RConPassword AzOnAlfanumerikusJelszava
RConPort 2306
RConIP 127.0.0.1
MaxPing 350
RestrictRCon 0

Három pont döntő. Az RCon-jelszónak tisztán alfanumerikusnak kell lennie: a különleges karakterek csendben kizökkentik a BattlEye protokollértelmezőjét, egy csendben hibázó RCon-hozzáférés pedig olyan hozzáférés, amely éles helyzetben nincs meg Önnek. Az RConIP határozza meg, melyik címen figyel az RCon: ha 127.0.0.1 áll ott, az interfész csak helyben érhető el, az RCon-eszköze pedig egy SSH-átirányításon keresztül éri el. Az RConPort értékének pedig a játékblokk fölött kell lennie, a szokásos a játékport plusz 4, vagyis 2306. Akinek kifelé kell nyitnia az RCont, az a portot csak az admincsapata rögzített címére engedi.

Egy dolog legyen világos: a BattlEye anti-cheat, nem DDoS-védelem. A már csatlakozott játékosokat ellenőrzi. Az a támadó, aki elárasztja a szerverét, egyáltalán nem akar belépni.

5. Kösse fixen a Headless Clientet

A Headless Client egy második, grafika nélküli Arma-3-példány, amely játékosként csatlakozik a szerverhez, és átveszi tőle a mesterséges intelligencia számítását. Nagy küldetéseknél ez a legfontosabb teljesítménynyereség, mert az MI egyébként ugyanazon a magon ül, mint a szimuláció. A server.cfg fájlban engedélyezhető:

headlessClients[] = {"127.0.0.1"};
localClient[] = {"127.0.0.1"};

Ezek a bejegyzések nélkül a szerver egyetlen Headless-Client-kapcsolatot sem enged, ez a jó hír. A rossz: a localClient[] a bejegyzett címnek korlátlan sávszélességet és gyakorlatilag semmilyen késleltetés-ellenőrzést nem ad. Kizárólag a 127.0.0.1 címet vagy a saját Headless-Client-gépének rögzített címét írja be oda, soha ne egy teljes címtartományt. A klienst a -client -connect=127.0.0.1 -port=2302 -password=... paraméterekkel indítja, és egy helyet foglal a maxPlayers értékből. Ezt tehát tervezze be, különben a játékosai tele szerver előtt állnak.

6. Keményítse meg a csatlakozást, az aláírásokat és a szavazásokat

Ezek a beállítások nem a vonalát védik, hanem mindent lezárnak, ami a szabályos csatlakozási úton érkezik: manipulált kliensek, játékon belüli szkriptfuttatás és szavazásokkal való visszaélés. A következő sorok minden nyilvános szerver server.cfg fájljába odavalók:

verifySignatures = 2;
BattlEye = 1;
kickDuplicate = 1;
allowedFilePatching = 0;
maxPlayers = 64;
disconnectTimeout = 30;
maxPing = 200;
maxDesync = 150;
maxPacketLoss = 50;
kickClientsOnSlowNetwork[] = {1, 1, 1, 1};
voteThreshold = 1.5;
voteMissionPlayers = 100;
onUnsignedData = "kick (_this select 0)";
onHackedData = "kick (_this select 0)";

A verifySignatures = 2 a 2-es verziójú aláírás-ellenőrzést kényszeríti ki minden addonra, és ez a minimális követelmény minden modokat használó nyilvános szerveren. Az allowedFilePatching = 0 megtagadja a belépést azoktól a kliensektől, amelyeket -filePatching kapcsolóval indítottak (az 1-es érték csak a Headless Clienteknek engedi, a 2-es mindenkinek). A kickDuplicate = 1 kidobja ugyanannak az azonosítónak a második kapcsolatát. A kickClientsOnSlowNetwork[] bejegyzésenként dönti el, hogy a maxPing, maxPacketLoss, maxDesync és disconnectTimeout négy küszöbét csak naplózza (0) vagy ki is kényszeríti (1). A disconnectTimeout 5 és 90 másodperc közötti értékeket fogad el. Az 1 fölötti voteThreshold elérhetetlenné teszi a szavazásokat, és ezzel lezárja a legkedveltebb módot arra, hogy valaki egyetlen támadócsomag nélkül zavarja meg a szervert: a küldetésváltást szavazással.

7. Korlátozza a csomag- és kapcsolatszámot forráscímenként

A kis támadások és a rendetlen botok ellen segít egy forráscímenkénti felső határ. Mivel az Arma 3 tisztán UDP-vel dolgozik, a hashlimit modullal dolgozunk, a query-port pedig sokkal szorosabb határt kap, mint a játékport:

iptables -I INPUT -p udp --dport 2303 -m hashlimit --hashlimit-name a3_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name a3_game --hashlimit-mode srcip --hashlimit-above 900/sec --hashlimit-burst 1200 -j DROP
iptables -I INPUT -p udp --dport 2302:2306 -m length --length 0:27 -j DROP

Az első szabály eldobja az ugyanabból a forrásból érkező lekérdezéseket, ha tartósan több mint tíz érkezik másodpercenként, a második a játékcsomagokat tartósan 900 per másodperc fölött, a harmadik a használható hasznos adat nélküli UDP-csomagokat. Mindhárom szám kiindulási érték, nem igazság: egy tele life-szerver 80 játékossal lényegesen több csomagot termel, mint egy hatfős Antistasi-kör, aki pedig túl szorosra állítja, a saját játékosait dobja ki. Először mérjen egy hetet normál üzemben.

Két megjegyzés ehhez. A puszta iptables-szabályok egy újraindítás után eltűnnek, Debian és Ubuntu alatt így mentjük 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, mert különben a következő ufw reload parancsnál eltűnnek. Gyakran figyelmen kívül hagyott szűk keresztmetszet emellett a kernel kapcsolatkövetése: az UDP is bejegyzéseket hoz létre benne, egy sok hamisított címről érkező query-flood pedig másodpercek alatt megtölti a táblát. Ha betelik, a szerver a legitim csomagokat is eldobja, a naplóban pedig a „nf_conntrack: table full" üzenet áll. Az aktuális állást és a felső határt ez mutatja:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. basic.cfg: sávszélesség, csomagméretek és kiegészítő fájlok

Egy Arma-3-szerver második konfigurációs fájlja a basic.cfg, amelyet a -cfg= kapcsoló tölt be, míg a -config= a server.cfg fájlt tölti. A hálózati viselkedést szabályozza, és pontosan egy olyan értéket tartalmaz, amely közvetlenül biztonsági jelentőségű:

MaxMsgSend = 1024;
MaxSizeGuaranteed = 512;
MaxSizeNonguaranteed = 256;
MinBandwidth = 15000000;
MaxBandwidth = 100000000;
MinErrorToSend = 0.001;
MinErrorToSendNear = 0.01;
MaxCustomFileSize = 0;
class sockets { maxPacketSize = 1400; };

A MaxCustomFileSize a játékosok által hozott arc- és hangfájlok maximális mérete bájtban, amelyeket a szerver az összes többinek szétoszt. A 0 érték kikapcsolja ezt az elosztást. Ezzel kiesik egy út, amelyen egyetlen kliens bármiféle támadási infrastruktúra nélkül foglalja le a szervere sávszélességét. A MinBandwidth az a sávszélesség, amelyet a szerver biztosítottnak vesz, irányértéke a játékosszám szorozva 256 kbit/s-mal, tehát nagyjából 16 Mbit/s 64 hely esetén. A túl derűlátó értékek növelik a terhelést és a deszinkronizációt, mert a szerver olyan üzeneteket állít elő, amelyeket utána eldob. A MaxMsgSend korlátozza a szimulációs lépésenkénti csomagokat, és ez az első fogantyú a deszinkronizáció ellen, a 128-as alapérték a mai szerverekhez túl alacsonyra van szabva.

9. Naplózzon, hogy támadás közben ne kelljen találgatnia

A legfontosabb lépés az, amelyet előre szinte senki nem tesz meg: összehasonlítási alapot 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 szombat este. Az apt-get install -y vnstat sysstat paranccsal a mérés tartósan fut, a logFile = "arma3server.log"; sor a server.cfg fájlban pedig megadja hozzá a szerver nézőpontját. Egy incidens alatt négy parancs elegendő:

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

Sokat elárul a portok összehasonlítása. Ha a terhelés szinte teljesen a 2303-ason ül, akkor query-floodról van szó, és az a processzoridőt támadja. Ha egyenletesen oszlik el a 2302-től 2306-ig terjedő portokon, mindig új feladócímekkel, akkor hamisított UDP-floodról van szó, és az a vonalat támadja. A tcpdump esetén érvényes: mindig korlátozza a -c kapcsolóval, egy teljes terhelés alatti csomagrögzítés az amúgy is túlterhelt szervert tovább terheli. Az értékek kiértékeléséről a DDoS-támadás felismerése szól. Arról pedig, hogyan kell a szervert egyáltalán tisztán telepíteni és frissíteni, a Játékszerver telepítése SteamCMD-vel ír.

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

Most jön az a rész, amelyet egyetlen konfigurációs fájl sem old meg. 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 meg nem történtté nem teheti.

Számoljunk egyszer utána. Egy tipikus játékszerver 1 Gbit/s-os vonalon lóg, ez másodpercenként 125 megabájt, és a vonal tele van, amint valaki ennél többet küld. A második mennyiség a csomagsebesség, és az Arma 3-nál szinte mindig ez üt be először. A 64 bájtos kis csomagokból egy 1 Gbit/s-os vonalba nagyjából másodpercenként 1,49 millió fér be. Egy szokásos szerverkernel a processzortól és a hálózati kártyától függően ebből néhány százezret dolgoz fel, mielőtt eldobálni kezdene, az Arma-3-szimuláció pedig ráadásul egyetlen magon lóg.

A 4 Mbit/s-os sor a legkellemetlenebb. Egy támadásnak az Arma 3-nál nem kell nagynak lennie ahhoz, hogy hasson: elég, ha elegendő csomagot küld a megfelelő portra. Az üzemeltetők ezt úgy élik meg, hogy „a kihasználtság nem is volt magas, mégis minden elszállt". Fordítva, a volumetrikus támadásokra az egyszerű fizika érvényes: 473,4 Gbit/s mellett minden helyi beállítás jelentéktelen, mert a játékosai csomagjai már korábban sem jutnak át. A volumetrikus támadásoknak a szerver előtti hálózatban kell véget érniük.

Mit állít ezzel szembe a KernelHost

A folyamatos védelem, amely minden 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ítja meg, 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 ismeri fel és dobja el a protokollspecifikus mintákat, csomagról csomagra.

Két tulajdonság döntő. A védelem folyamatosan fut, és nem kell előbb reagálnia egy támadásra, így nincsenek az elején olyan percek, amikor a szerver elérhetetlen. És nincs null-routing: az IP-címe a hálózatban marad, csak a káros csomagokat dobja el a rendszer. Aki kiveszi az IP-címet a hálózatból, az Ön szempontjából ugyanazt é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 sorolja fel.

Advanced DDoS Protection a tartósan lőtt projektekhez

Egyes projekteket nem alkalmanként, hanem célzottan és heteken át támadnak. Egy állandó játékosbázissal és versengő szcénával rendelkező life-szerver esetében ez a szabály, nem a kivétel. 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, hanem a kontrollban áll:

• Dedikált védett IP a frankfurti központi hálózatból, amelyre a szerverét a saját hálózatunkon belül átállítjuk. Az Ön oldalán semmilyen átalakítás nem szükséges.
• Ö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 2302-es UDP-porton és mi a 2303-ason, és a query-portot így lényegesen szorosabbra foghatja, mint a játékportot.
• A módosítások valós időben lépnek érvénybe, tehát egy futó támadás közben is utánaigazíthat, ahelyett hogy karbantartási ablakra várna.
• Az adott játékhoz illő védelmi profil, ugyanígy a módosított és saját alkalmazásokhoz tetszőleges TCP- vagy UDP-portokon.

A két szint összehasonlítása

A legtöbb Arma-3-projektnek elegendő a csomagban foglalt folyamatos védelem egy tiszta szerverkonfigurációval együtt. Az Advanced DDoS Protection arra a válasz, ha valaki személyes ügyet csinál a dologból.

Gyakori hibák és megoldásaik

„Áttettem a portot 2302-ről 2402-re, a támadás mégis tovább futott": Ez várható volt. A szerver maga jelenti be az új portját a Steam-masterszerveren, a szerverlista pedig azonnal újra közzéteszi. Egy portváltás csak az ellen segít, aki egy régi képernyőképről vett régi adatot használ.

„Teljesen lezártam a 2303-ast, most senki nem talál meg minket": Pontosan ez történik. A Steam-query-porton adott válasz nélkül hiányzik a bejegyzés a szerverböngészőből, és minden állapotoldal és minden Discord-bot offline-ként mutatja a szervert. A helyes megoldás a forráscímenkénti sebességkorlátozás, nem a lezárás.

„A naplóban a NetServer::SendMsg: cannot find channel áll": Ez az üzenet akkor jön, amikor a szerver olyan kapcsolatnak akar írni, amely már nem létezik. Rendszerint megszakadó játékoskapcsolatokat és teljesítménybeesést kísér (a Bohemia ezt a T83936 alatt vezeti), nem feltétlenül támadást. Először ellenőrizze, hogy az interfész csomagsebessége egyáltalán feltűnő-e.

„Az iptables-szabályaim nem fognak": Három ok gyakori. A szabályok az UFW-láncok mögött állnak, és soha nem éri el őket a forgalom; 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 vonalon, amely már tele van. Ellenőrizze az iptables -L INPUT -n -v paranccsal, hogy nőnek-e a találatszámlálók. Ha nullán maradnak, a szabályt nem éri el a forgalom.

„A BattlEye az új tűzfal óta minden játékost kidob": A szerver nem éri el az arma31.battleye.com címet. A kimenő 2344-es portnak TCP-n és UDP-n, valamint a 2345-ösnek TCP-n nyitva kell maradnia, különben megszakad a szerver anti-cheat-kapcsolata.

„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 el az elérhetőségéről, mint bármilyen hardveradat.

„A tcpdumpban semmi feltűnőt nem látok": 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. Ez a normális eset működő szűrés mellett. 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élportál VNC-konzolját, amely a vendégrendszer hálózatától függetlenül működik.

Röviden összefoglalva

• Egy Arma-3-szervernek kifelé pontosan három UDP-portra van szüksége: 2302 a játékhoz és a hanghoz, 2303 a Steam-lekérdezéshez és 2304 a Steam-masterszerverre való bejelentkezéshez. TCP-re a játéknak nincs szüksége.
• A 2306-os UDP-port viszi a BattlEye-t és az RCon-interfészt, és kizárólag a saját admincímeire való, a beserver_x64.cfg fájlban az RConPort és az RConIP értékkel beállítva.
• A 2303-as Steam-query-port a legérzékenyebb pont: a Steam-protokoll erősítési tényezője az US-CERT TA14-017A szerint 5,5, és minden lekérdezés processzoridőt vesz el attól a magtól, amely a szimulációt viszi. Korlátozni kell, nem lezárni.
• A steamProtocolMaxDataSize értékét olyan kicsire kell venni, amekkorát a modlista enged, a basic.cfg fájlba pedig MaxCustomFileSize = 0; való: mindkettő csökkenti azt az adatmennyiséget, amelyet a szervere kérés nélkül kiszolgál.
• Az Arma 3-nál a csomagsebesség dönt, nem a sávszélesség. A Bohemia 2015 óta dokumentálja a T83469 alatt, hogy már 4 Mbit/s a query-porton elegendő volt egy szerver befagyasztásához.
• A helyi intézkedések a vonalnál véget érnek. 1 Gbit/s támadási volumen vagy néhány százezer csomag per másodperc fölött kizárólag a szerver előtti hálózatban végzett szűrés dönt.
• A KernelHostnál a kétrétegű folyamatos védelem minden szervercsomagban felár nélkül benne van és a kiépítéstől aktív, null-routing nélkül. Az Advanced DDoS Protection ezt havi 50,00 EUR-tól dedikált védett IP-vel és önállóan kezelhető, portonkénti szabályokkal egészíti ki.

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 hibajegyet, hogy az IP-címéhez tartozó szűrőszabályokat utánaigazí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.