RedM szerver védelme DDoS-támadások ellen

Az a RedM-szerver, amely este a session kellős közepén eltűnik, majd tíz perccel később újra megjelenik, ritkán küzd hardverhibával. Többnyire támadás fut a 30120-as port ellen, méghozzá pontosan akkor, amikor a legtöbb játékos online van. Ez a cikk bemutatja, hogyan védhet meg egy RedM-szervert a DDoS-támadásoktól: először azt, amit többletköltség nélkül saját maga is biztosíthat, utána ezeknek az intézkedéseknek a fizikai határát, végül pedig azt, aminek a szerver előtti hálózatban kell történnie, ha a támadás nagyobb, mint az Ön vonala.

Minden adat egy gamename rdr3 beállítású FXServerre vonatkozik 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. A RedM a Cfx.re Red Dead Redemption 2-höz készült módosítása és a FiveM testvérprojektje. Mindkettő ugyanazon a szerverprogramon fut, ezért a hálózati technika egy része valóban azonos. Ahol ez így van, ott itt egyetlen mondat áll, a részletes rész pedig a FiveM-szerver védelme DDoS-támadások ellen című cikkben olvasható. Minden más ebben a szövegben RedM-specifikus.

Ha a támadás éppen zajlik: most ne változtasson semmit a server.cfg fájlon, és ne indítsa újra a szervert. Előbb mentse a mérési adatokat (lásd a „Mérési adatok gyűjtése" szakaszt), a támadás után már nem lesznek meg.

Miért válnak a RedM-szerverek ilyen gyakran DDoS-támadások célpontjává

Egy RedM-szerver értékesebb célpont, mint amit a játékosszáma sejtetne. Az ok éppen a szcéna kis mérete. 2026 szeptemberében a nyilvános szerverlista-trackerek mintegy 2000 aktív RedM-szervert számoltak körülbelül 12 400 egyidejű játékossal, szemben a mintegy 39 000 FiveM-szerverrel és körülbelül 325 000 játékossal. Aki 2000 RedM-szerver egyikét bénítja meg, a teljes szcéna jóval nagyobb hányadát veszi le a hálózatról, mint aki 39 000 FiveM-szerver egyikét találja el. Egy támadó számára, aki egy konkurens projektnek akar ártani, az emelőhatás tehát összehasonlíthatatlanul nagyobb.

Ehhez jön a közösségek szerkezete. A RedM-roleplay rögzített időpontokban tartott, állandó sessionökből él, gyakran jelentkezéssel és karakterjóváhagyással. Egy este nyolckor bekövetkező kiesés nem akárkiket érint, hanem pontosan azokat, akik arra az estére jelentkeztek. Sok projekt ráadásul hobbiként, kis költségvetéssel fut, egyetlen olcsó szerveren lóg, és nincs második példány, amelyre át lehetne kapcsolni. A RedM-szcénából nyilvánosan dokumentált esetek hónapokon át, szinte napi ütemben zajló támadássorozatokról számolnak be, amelyek egyszerre érték a játékszervert és a különálló hangszervert.

Technikailag ehhez társul, hogy a játékforgalom UDP-n megy. Az UDP kapcsolat nélküli szállítási protokoll: nincs kapcsolatfelépítés, amelyet a szerver megkövetelhetne, a feladócímek pedig hamisíthatók. Egy támadónak tehát sem belépnie nem kell az Ön RedM-szerverére, sem szabályosan megszólítania azt ahhoz, hogy terhelést okozzon. Hogy pontosan mi a DDoS-támadás és hogyan épül fel, 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 RedM-szerver alapértelmezés szerint egyetlen portra kötődik, méghozzá mindkét protokollon. A server.cfg fájlban ez így néz ki:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
set gamename rdr3
sv_enforceGameBuild 1491
sv_licenseKey "cfxk_..."

A set gamename rdr3 sor az egyetlen, amely megkülönbözteti a RedM-szervert a FiveM-szervertől. Ha hiányzik, ugyanaz az FXServer GTA V-szerverként jelentkezik be, és egy RedM-kliens nem tud csatlakozni. A RedM-nek nincs saját query-portja és saját RCON-portja: a szerverlekérdezés, a kapcsolatfelépítés, a játékforgalom és az RCON mind ugyanazon a két bejegyzésen, a 30120-on fut. Ez a kemény számsor:

A négy felsorolt portból pontosan kettő való a nyílt hálózatba: a 30120 TCP és a 30120 UDP. A 40120-as port és a 3306-os port nem oda való, az SSH-t pedig a 22-es porton a saját címeire kell korlátozni. Ez a leggyakoribb elkerülhető hiba a RedM-szervereken, mert sok projekt kész txAdmin-recepttel indul, és utána soha nem ellenőrzi, mit kínál a szerver kifelé.

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

Ez a szakasz a leghosszabb, és ez szándékos. Egy rendesen beállított RedM-szerver saját erőből kibírja a kisebb és közepes támadásokat, függetlenül attól, hogy kinél áll. A sorrend tudatosan választott: először mér, utána zár, és csak azután korlátoz.

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

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

A helyi címet tartalmazó oszlop az érdekes. A 0.0.0.0:30120 és a [::]:30120 azt jelenti, hogy „az egész internetről elérhető", a 127.0.0.1:3306 pedig azt, hogy „csak helyben", és nem igényel tűzfalszabályt. Az FXServer mellett egy RedM-szerveren rendszeresen felbukkan a txAdmin a 40120-on, a MariaDB a 3306-on, egy webszerver a projektoldalhoz és alkalmanként egy hangszolgáltatás. A támadó nézőpontját egy kívülről indított portszkennelés adja meg:

nmap -Pn -p- --min-rate 1000 A.SZERVERE.IP.CIME

2. Csak a 30120 TCP és UDP maradjon nyitva

A RedM-hez két kifelé irányuló engedélyezés elég, minden mást korlátozni kell vagy közzé sem szabad tenni. Az UFW-vel ez így néz ki, pontosan ebben a sorrendben, hogy ne zárja ki saját magát:

ufw allow 22/tcp comment 'SSH'
ufw allow 30120/tcp comment 'RedM'
ufw allow 30120/udp comment 'RedM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

A 203.0.113.10 helyére írja be a saját címét. Változó című előfizetésnél ez kényelmetlen, a jobb utat a txAdminról szóló következő szakasz írja le. A teljes útmutatót a kimentési úttal együtt az UFW-tűzfal beállítása úgy, hogy ne zárja ki saját magát című cikkben találja.

Az adatbázisnak semmilyen körülmények között nincs helye a nyílt hálózatban. A VORP, az RSGCore és a RedEM:RP mind MariaDB-t vagy MySQL-t igényel, többnyire az oxmysql révén, a server.cfg fájlba írt kapcsolati sztringgel. Ez a kapcsolat helyben fut, a portnak tehát nem kell kívülről elérhetőnek lennie. 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. Az FXServer HTTP-végpontjainak biztosítása

Az FXServer a 30120 TCP-oldalán HTTP-kéréseket válaszol meg anélkül, hogy bárkinek el kellene indítania a Red Dead Redemption 2-t. Nézze meg, mit szolgál ki ott az Ön RedM-szervere:

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600
curl -s http://127.0.0.1:30120/dynamic.json

A /players.json felsorolja a csatlakozott játékosokat az azonosítóikkal együtt, az /info.json a szerverkonfigurációt és a betöltött erőforrásokat, a /dynamic.json pedig a pillanatnyi telítettséget. Pontosan ez a három végpont a dokumentált Layer 7-es támadási út a FiveM- és RedM-szerverek ellen: bejelentkezés nélkül elérhetők, tetszőlegesen sokszor lekérdezhetők, minden lekérdezés munkába kerül a szervernek, a tartalom pedig elárulja a támadónak, mikor éri meg a támadás. Két ellenintézkedés semmibe nem kerül. Először is a játékosok végpontjainak nincs helye a válaszban, ehhez egyetlen sor elég a server.cfg fájlban:

sv_endpointPrivacy true

Ez a beállítás elrejti a játékosai IP-címeit a szerver nyilvános kimeneteiből. Másodszor: ha a Discord-botja vagy a projektoldala megjeleníti a játékosok számát, ne a látogató felől kérdezze le a végpontot, hanem tárolja az eredményt gyorsítótárban rögzített időközönként. Így egy sokat látogatott állapotoldal intervallumonként egy lekérdezést okoz, nem pedig látogatónként egyet. Egy olyan kis szcénánál, mint a RedM, ez kétszeresen esik latba, mert egyetlen szerverállapot-bot több Discord-szerverben is be lehet kötve egyszerre.

4. A txAdmin kivétele a nyílt hálózatból a 40120-as porton

A txAdmin az a kezelőfelület, amely a FiveM-hez és a RedM-hez készült FXServer-buildben benne van, és alapértelmezés szerint a 40120 TCP-n figyel. Mögötte a szervere feletti teljes hozzáférés áll: újraindítások, tiltólista, játékosadatbázis, erőforrás-kezelés. Fix IP-cím nélküli engedélyezés esetén ne engedje kívülről a portot, hanem érje el SSH-val létrehozott helyi porttovábbításon keresztül, majd nyissa meg a böngészőben a http://127.0.0.1:40120 címet:

ssh -N -L 40120:127.0.0.1:40120 root@A.SZERVERE.IP.CIME

Aki nyilvánosan hagyja a txAdmint, egyszerre két gondot kap: egy bejelentkezési felületet, amely ellen bejelentkezési floodot lehet indítani, és egy szolgáltatást, amely minden kérésnél munkát végez, pedig semmi köze a játékhoz. Kétség esetén kösse a txAdmint eleve helyben, vagyis engedje, hogy a szolgáltatás csak a 127.0.0.1 címen figyeljen.

5. Kapcsolat- és csomagszám korlátozása forráscímenként

A kisebb támadások és a szabálytalan botok ellen segít egy forráscímenkénti felső korlát. A két szabály a 30120-ra vonatkozik, vagyis a játék mindkét protokolljára:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name redm_udp --hashlimit-mode srcip --hashlimit-above 500/sec --hashlimit-burst 750 -j DROP

Az első szabály eldobja az új TCP-kapcsolatokat, amint egy címnek egyszerre több mint nyolc van nyitva, a második pedig az UDP-csomagokat, ha ugyanabból a forrásból tartósan több mint 500 csomag érkezik másodpercenként. A kezdőértékek itt valamivel alacsonyabbak, mint egy FiveM-szerveren, mert egy 32 slotos RedM-szerver egyszerűen kevesebb legitim kapcsolatot hoz létre címenként. A kezdőértékek azonban nem igazságok: egy telt RP-est lényegesen több csomagot okoz, mint egy üres szerver, és aki túl szűkre állít, a saját játékosait dobja ki. Előbb mérjen egy hetet normál üzemben.

Két megjegyzés ehhez. A tiszta iptables-szabályok újraindítás után eltűnnek, Debian és Ubuntu alatt így lehet menteni őket:

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

UFW alatt pedig az ilyen szabályok helye az /etc/ufw/before.rules fájl, mert különben a következő ufw reload parancsnál eltűnnek. Gyakran figyelmen kívül hagyott szűk keresztmetszet ezen felül a kernel kapcsolatkövetése: ha megtelik, a szerver a legitim csomagokat is eldobja, a naplóban pedig ez áll: „nf_conntrack: table full". Az állapotot és a felső korlátot ez mutatja meg:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

6. A 32 slot védelme a csatlakozási floodok ellen

Egy RedM-szervernek OneSync nélkül pontosan 32 slotja van. OneSynckel 48, ezen felül pedig Element Club-előfizetés kell a legfeljebb 1024 helyhez. Ez a szám biztonsági szempontból is fontos, mert ez az a felső korlát, amelyet egy támadónak meg kell töltenie: aki 32 csatlakozási kísérletet tart nyitva egyszerre, teljesen elfoglal egy alapértelmezett szervert anélkül, hogy egyetlen játékos is ténylegesen beérkezne a játékba. Egy 128 helyes FiveM-projektnél ugyanez a küszöb négyszer ilyen magas.

Egy RedM-specifikus előny ezt részben kiegyenlíti: a RedM a Red Dead Redemption 2 valódi példányát feltételezi, mindegy, hogy Steamen, az Epic Gamesen vagy a Rockstarnál vásárolták, ehhez pedig a Rockstar-launchert. Az ingyenes játékoknál megszokott, több ezer eldobható fiókkal indított csatlakozási flood tehát itt valódi pénzbe kerül. A támadások emiatt a hálózati rétegre és a HTTP-végpontokra tolódnak, ahol nincs szükség játékpéldányra.

Minden ellen, ami a szabályos csatlakozási utat használja, mégis hatásos egy whitelist. Szerveroldalon a playerConnecting eseményben valósul meg, ahol a deferrals-függvényekkel megállítja a kapcsolatot, ellenőrzi az azonosítót, és csak utána engedi tovább. Ehhez jön a szigorú fiókellenőrzés és egy reális játékos-felsőkorlát:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

Az sv_authMaxVariance 1-től 5-ig terjedő érték, és azt adja meg, mennyire változhat egy játékos azonosítója egy szolgáltatónál; az 1 a legszigorúbb beállítás. Az sv_authMinTrust szintén 1-től 5-ig fut, és azt írja le, mennyire kell valószínűtlennek lennie egy hamisított azonosságnak; itt az 5 a legszigorúbb érték. RCON-jelszót csak akkor állítson be, ha valóban szüksége van az RCON-ra, mert a hozzáférés ugyanazon a nyitott 30120-as porton van. És egy dolognak világosnak kell lennie: a whitelist a játéklogikáját védi, nem a vonalát. Az a támadó, aki elárasztja a szerverét, nem is akar csatlakozni. A csomagjait a szerver elutasítja, de attól azok már megérkeztek, és pontosan ez a lényeg.

7. A RedM-szerverlistás bejegyzés helyes megítélése

Itt az őszinteség többet ér a vágyálomnál: az IP-címét nem lehet titokban tartani. A RedM ugyanazt a Cfx.re-mesterszerverek alkotta infrastruktúrát használja, mint a FiveM, a listabejegyzés pedig a connectEndPoints mezőben nyílt szövegként tartalmazza a kapcsolódási végpontot. A servers-frontend.fivem.net alatti nyilvános felületen minden cfx.re-kódhoz lekérdezhető a hozzá tartozó cím, a RedM esetében ugyanúgy, mint a FiveM-nél. Aki egyáltalán nem igényli a nyilvános bejegyzést, mert a projekt tisztán Discordon és közvetlen kapcsolódáson keresztül fut, az sv_master1 "" beállítással privátként viheti a szervert: ekkor a szerverlistán keresztül már nem lehet csatlakozni hozzá. Ez viszont a teljes láthatóságba kerül az új játékosok felé, egy 2000 szerveres szcénában pedig a láthatóság a tényleges növekedési motor.

Hatásosabb két szokás. Sehol ne tegye közzé saját maga a nyers IP-címet, tehát se a Discord-csatornán, se a projektoldalon. A játékosait pedig hosztnéven keresztül kösse be, hogy szükség esetén címet tudjon váltani anélkül, hogy minden hivatkozás eltörne. A klasszikus buktató ilyenkor a régi DNS-bejegyzés: egy elfelejtett, a korábbi címre mutató A-rekord minden váltást hatástalanná tesz.

8. A VORP-, RSGCore- és RedEM-események szerveroldali ellenőrzése

Sok kiesés, amelyet DDoS-támadásként jelentenek, egyetlen szkriptre vezethető vissza. A RedM-erőforrások hálózati eseményeken keresztül kommunikálnak, és egy olyan esemény, amelyet a szerver ellenőrzés nélkül hajt végre, nyitott ajtó: aki a kliensben tetszőleges értékekkel küld egy TriggerServerEvent hívást, dollárt hozhat létre, lovakat spawnolhat vagy ciklusban indíthat adatbázis-lekérdezéseket, amíg a szerver le nem áll. Ez mind a három elterjedt keretrendszert egyformán érinti: a VORP Core-t, amelynek 2020 óta a legnagyobb a szkriptbázisa, az RSGCore-t és a régebbi RedEM:RP-t.

Különösen sérülékenyek az inventár- és karaktererőforrások, mert minden hívásnál az adatbázisba írnak. Egy olyan eseményciklus, amely másodpercenként tízszer ment el egy inventárállapotot, jobban terheli a RedM-szervert, mint némelyik csomagáradat, és belülről jön, ahol nem fog a tűzfal.

Három szabály ennek a nagy részét felfogja. A RegisterNetEvent hívással kizárólag olyan eseményeket regisztráljon, amelyeknek valóban a klienstől kell érkezniük. Soha ne támaszkodjon olyan értékekre, amelyeket a kliens küld, hanem szerveroldalon, a source alapján állapítsa meg a játékost. És korlátozza, hányszor válthatja ki ugyanazt az eseményt egy játékos, különösen mindennél, ami adatbázis-lekérdezéssel jár. Ha a szerver akadozik, miközben a vonal nyugodt, a kliens konzoljában a resmon 1 parancs megmutatja az erőforrásonkénti számítási időt, és a bűnös többnyire legfelül áll.

9. Mérési adatok gyűjtése, mielőtt szüksége lenne rájuk

A legfontosabb lépés az, amelyet előre szinte senki nem tesz meg: hozzon létre összehasonlítási alapot, 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 egy jól látogatott keddi este. Az apt-get install -y vnstat sysstat paranccsal a mérés folyamatosan együtt fut. Egy incidens alatt négy parancs elég: csomagszám másodpercenként, az interfész eldobási aránya, kernelüzenetek és egy rövid forgalmi mintavétel.

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 port 30120 -c 200 -q

A tcpdump parancsnál érvényes: mindig korlátozza a -c kapcsolóval, egy teljes terhelés alatti rögzítés ráadásul terheli az amúgy is túlterhelt szervert. Figyeljen arra is, hogy a terhelés a 30120 UDP- vagy TCP-oldalán van-e. Az UDP-terhelés a játékforgalom elleni csomagáradatra utal, a TCP-terhelés a HTTP-végpontok elleni floodra, és a kettő eltérő ellenintézkedést igényel. Hogy miként értékelje ki az értékeket, azt a DDoS-támadás felismerése című cikk írja le.

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

Most jön az a rész, amelyet semmilyen server.cfg nem old meg. Minden eddigi intézkedés az Ön szerverén fut, vagyis a vonal végén. Egy tűzfalszabály olyan csomagról dönt, amely már végigfutott a kábelen. Eldobhatja, de nem teheti meg nem küldötté.

Számoljon egyszer utána. Egy tipikus játékszerver 1 Gbit/s-on lóg, ez másodpercenként 125 megabájt, és a vonal megtelik, amint valaki többet küld. A roleplay-projektek elleni támadások szokásosan 5 és 50 Gbit/s között vannak, vagyis a vonala öt- és ötvenszerese között. Az, hogy mögötte jó-e az iptables-szabálya, ekkor 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 gyakran hamarabb üt be, mint a sávszélesség. A 64 bájtos kis csomagokból egy 1 Gbit/s-os vonalba másodpercenként mintegy 1,49 millió fér bele. Egy normál szerverkernel a CPU-tól és a hálózati kártyától függően néhány százezret dolgoz fel ebből, mielőtt eldobálni kezdene. Egy támadás, amely a vonalát még egyharmadáig sem tölti meg, tehát mégis megbéníthatja a RedM-szerverét, mert az eldobásra megy el a számítási idő. Az üzemeltetők ezt így élik meg: „a kihasználtság nem is volt magas, mégis minden odalett". Pontosan ezek a látható szerverterhelés nélküli lag spike-ok a csomagszám elleni támadás tipikus tünetei.

Hogy lássa, milyen nagyságrendek fordulnak elő valóban: a KernelHost szerverein többek között egy 473,4 Gbit/s feletti, másodpercenként 41,5 milliónál több csomaggal érkező támadást szűrtek ki egy hangszerver ellen, valamint 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.

Miben más a RedM, mint a FiveM

A rövid válasz: a hálózati technika azonos, a környezet nem. Mindkettő ugyanazon az FXServeren fut, mindkettő a 30120 TCP-t és UDP-t használja, mindkettőt a txAdmin kezeli a 40120-on. Minden, amit fent a portokról, a rátákról és a végpontokról olvas, mindkettőre érvényes. A keretfeltételek különböznek, és éppen azok döntik el, milyen gyorsan hat egy támadás:

Ebből a táblázatból három pont döntő a védekezés szempontjából. Először is a kisebb szcéna minden egyes RedM-szervert értékesebb célponttá tesz, mert egy kiesés a játékosok nagyobb hányadát érinti. Másodszor a 32 slotos alapértelmezett korlát leszállítja azt a küszöböt, amelytől egy csatlakozási flood lezárja a szervert. Harmadszor pedig a RedM-hez kevesebb kész védelmi recept található a neten, mint a FiveM-hez, ezért sok projekt változatlan alapkonfigurációval fut. A védekezés ugyanaz, a kiindulási állapot rosszabb.

Mit állít ezzel szembe a KernelHost

A folyamatos védelem, amely minden szerverben benne van

A KernelHost DDoS-védelme két rétegből áll é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ítják ki, még 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 reagálnia egy támadásra, tehát nincsenek kezdeti percek, amelyekben a RedM-szerver eltűnik. É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 Ön számára ugyanazt az eredményt éri el, mint a támadó. A szűrés helyszíne Frankfurt am Main. 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 alkalomszerűen, hanem célzottan és heteken át támadnak. Erre való az Advanced DDoS Protection havi 50,00 EUR-tól, PrePaid alapon és minimális futamidő nélkül. A különbség nem a nagyobb kapacitásban 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ózatunkon belül á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: külön állítja be, mi engedélyezett a 30120 UDP-n és mi a 30120 TCP-n, anélkül hogy ehhez hibajegyet kellene írnia. Éppen a RedM-nél hasznos ez a szétválasztás, mert a játékforgalom és a HTTP-végpontok ugyanazon a portszámon vannak, a mintázatuk pedig teljesen eltérő.
• A módosítások valós időben lépnek érvénybe, tehát folyamatban lévő támadás közben is utánaigazíthat.
• Az alkalmazáshoz illő védelmi profil. A 30120-on futó Cfx.re-szerverekhez van megfelelő profil, ugyanígy a módosított és saját alkalmazásokhoz tetszőleges TCP- vagy UDP-portokon.

Mindkettő azokra a szerverekre érvényes, amelyek a KernelHostnál állnak. Ha a RedM-projektje jelenleg máshol fut, és rendszeresen lelövik a hálózatról, akkor a költözés az ajánlás, nem egy további termék.

A két fokozat összehasonlítása

A legtöbb RedM-projekthez elég a beleértett folyamatos védelem egy rendesen beállított szerverkonfigurációval együtt. Az Advanced DDoS Protection arra a válasz, hogy valaki személyes ügyet csinál belőle.

Gyakori hibák és megoldásaik

„A szerverem nem jelenik meg a RedM-szerverlistán, támadásra gyanakszom": Először a konfigurációt ellenőrizze. Ha hiányzik a set gamename rdr3, az FXServer GTA V-szerverként jelentkezik be, és nem jelenik meg a RedM-listán. Ha a portal.cfx.re oldalról származó licenckulcs hiányzik vagy nem stimmel, a bejegyzés szintén nem jön létre. Egy támadás máshogy néz ki: a bejegyzés megmarad, a kapcsolódás hiúsul meg.

„Több száz játékos kap hibát csatlakozáskor, ez floodnak néz ki": Többnyire játékverzió-probléma. Ha az sv_enforceGameBuild nem illik ahhoz, amit az erőforrásai várnak, a kliens azt jelzi: „server specified an invalid game enforcement". Állítsa be azt az értéket, amelyet a keretrendszere megkövetel, szokásosan az 1436-ot vagy az 1491-et, és indítsa újra teljesen a szervert.

„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 listabejegyzésből, egy Discord-botból vagy egy régi DNS-bejegyzésből. A címváltás időnyerés, nem megoldás.

„Az iptables-szabályaim nem fognak": Három ok gyakori. A szabályok az UFW-láncok mögött állnak, és soha nem érnek odáig a csomagok; a legutóbbi újraindítás után eltűntek (ilyenkor segít a netfilter-persistent save vagy egy bejegyzés az /etc/ufw/before.rules fájlban); vagy a támadás volumetrikus, és a szabály helyesen dolgozik egy olyan vonalon, amely már megtelt. 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ály nem kerül sorra.

„A szerver fut, de minden játékos gumiszalag-effektust tapasztal": Ez gyakrabban szkript, mint támadás. Nézze meg először a resmon 1 paranccsal, hogy egy erőforrás felemészti-e a számítási időt, és ellenőrizze a keretrendszere inventár- és karaktererőforrásait. Ha a sar -n DEV 1 10 feltűnésmentes marad, nem DDoS-támadás volt.

„A txAdmin több száz sikertelen kapcsolódási kísérletet mutat": Ez csatlakozási flood, és a játéklogikát éri, nem a vonalat. Ez ellen hat a whitelist, a fiókellenőrzés az sv_authMinTrust révén és a forráscímenkénti kapcsolatkorlát.

„A korábbi 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 a rendelkezésre állásá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űrik, a szerverre a várakozásoknak megfelelően nem érkezik semmi. Ez a normális eset működő szűrésnél. Fordítva viszont érvényes: ha a vonal telített, adott esetben már az az SSH-munkamenet sem ér el Önhöz, amellyel mérni akart. Használja ilyenkor az ügyfélportálon elérhető VNC-konzolt, amely a vendégrendszer hálózatától függetlenül működik.

Röviden összefoglalva

• Egy RedM-szervernek pontosan két nyitott portra van szüksége: 30120 TCP és 30120 UDP, az endpoint_add_tcp és az endpoint_add_udp révén beállítva. Saját query-port vagy RCON-port nincs.
• A txAdminnak a 40120 TCP-n és az adatbázisnak a 3306 TCP-n nincs helye a nyílt hálózatban, hanem a saját címére, illetve a 127.0.0.1-re valók.
• Az sv_endpointPrivacy true kiveszi a játékosok IP-címeit a nyilvános kimenetekből, egy gyorsítótárazott szerverállapot pedig terhet vesz le a /players.json végpontról, amely a dokumentált Layer 7-es támadási út a Cfx.re-szerverek ellen.
• Egy RedM-szervernek OneSync nélkül 32 slotja van, OneSynckel 48, Element Clubbal pedig 1024-ig. Minél kisebb a slotszám, annál olcsóbb egy csatlakozási flood, és annál fontosabb a whitelist és a fiókellenőrzés.
• A RedM és a FiveM ugyanazon az FXServeren fut, egyedül a set gamename rdr3 sor különbözteti meg őket. A hálózati védekezés ezért azonos, a környezet nem: a mintegy 2000 RedM-szerver a mintegy 39 000 FiveM-szerverrel szemben minden egyes RedM-projektet értékesebb célponttá tesz.
• A helyi tűzfalszabályok ott érnek véget, ahol a vonal megtelik: 1 Gbit/s másodpercenként 125 megabájt, és 64 bájtos csomagokból mintegy 1,49 millió fér bele másodpercenként. Minden, ami ezen felül van, a szerver előtti hálózatban kell hogy véget érjen.
• A KernelHostnál a kétrétegű folyamatos védelem minden szervercsomagban benne van, a kiépítéstől kezdve aktív, és null-routing nélkül működik. Aki maga akarja vezérelni a szűrést, az Advanced DDoS Protectionnel havi 50,00 EUR-tól dedikált védett IP-t és saját szabályokat kap portonként és protokollonként.

Ha a RedM-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 support-hibajegyet, hogy a szűrési szabályokat az IP-címéhez igazítsuk. Folyamatban lévő támadás esetén emellett elérhet minket a WhatsApp-vészhelyzeti chaten a +43 650 8209883 számon.