Minecraft Bedrock szerver védelme DDoS-támadások ellen

Egy Minecraft Bedrock szerver, amely este néhány percre eltűnik a szerverlistából, majd visszatér, ritkán szenved hardverhibától. Többnyire támadás zajlik, méghozzá pontosan akkor, amikor a legtöbb játékos online van. Ez a cikk azt mutatja meg, hogyan védi meg a Minecraft Bedrock szervert a DDoS-támadások ellen: először azt, amit extra költség nélkül maga tud bebiztosítani, azután azt a pontot, ahol ezek az intézkedések fizikailag véget érnek, végül pedig azt, minek kell a szerver előtti hálózatban történnie.

Minden adat egy Bedrock Dedicated Serverre, PocketMine-MP-re vagy Nukkitra vonatkozik Debian 12, Debian 13, Ubuntu 22.04 LTS vagy Ubuntu 24.04 LTS alatt. A parancsok root felhasználóra íródtak, normál felhasználóként tegyen eléjük sudo parancsot. Aki a Java Editiont üzemelteti, az ott jellemző protokolltámadásokat a Minecraft-DDoS-védelem és nullping-védelem című cikkben találja. Egy Bedrock-szerver puszta telepítését a Minecraft Bedrock szerver telepítése Nukkittal című cikk írja le.

Ha a támadás éppen zajlik: most ne módosítson semmit a konfiguráción, és ne indítsa újra a szervert. Először mentse el a mérési értékeket (a „Mérési értékek gyűjtése, mielőtt bedurran” szakasz), a támadás után visszahozhatatlanul elveszíti őket.

Miért olyan gyakran célpontjai a Minecraft Bedrock szerverek a DDoS-támadásoknak

A Bedrock Edition az a kiadás, amely konzolokon, okostelefonokon, táblagépeken és Windowson fut, és ez adja a Minecraft legnagyobb játékosbázisát. Ahol sok szerver áll, ott keletkezik a legnagyobb ösztönzés a támadásokra: konkurens hálózatok, kitiltott játékosok, belső viszályok. Egy támadás a kiváltójának ehhez sem tudást, sem említésre méltó pénzt nem kerül, egy szerver-bootert előfizetésként adnak.

A technikai ok mélyebben van. Egy Bedrock-szerver UDP-t beszél, nem TCP-t, és mindenkinek válaszol, aki kérdez, jóval azelőtt, hogy bármiféle bejelentkezés megtörtént volna. Pontosan ez a két tulajdonság teszi a 19132-es UDP-portot hálás célponttá. Hogy alapvetően mi is egy DDoS-támadás, azt a Mi az a DDoS-támadás? című cikk magyarázza el.

RakNet: olyan UDP-protokoll, amely azelőtt válaszol, hogy bárki bejelentkezett volna

A RakNet az az UDP hálózati könyvtár, amelyen a Minecraft Bedrock Edition a teljes játékforgalmát bonyolítja. Az UDP nem ismer olyan kapcsolatfelépítést, amelyet egy szerver megkövetelhetne, és a feladócímek ezért hamisíthatók. A RakNet saját megbízhatósági réteget épít erre: sorszámokat, visszaigazolásokat (ACK) és negatív visszaigazolásokat (NAK), amelyekkel egy kliens utánkérheti az elveszett csomagokat.

A kapcsolatfelépítés hét csomagból áll, négy a klienstől és három a szervertől:

Client  -> Server   Open Connection Request 1
Server  -> Client   Open Connection Reply 1
Client  -> Server   Open Connection Request 2
Server  -> Client   Open Connection Reply 2
Client  -> Server   Connection Request
Server  -> Client   Connection Request Accepted
Client  -> Server   New Incoming Connection

Csak ezután küldi a kliens a bejelentkezési csomagot az Xbox Live-igazolásaival. Ez a döntő mondat mindenkinek, aki a Bedrock-szerverét be akarja biztosítani: a szerver hét csomagot dolgozott fel, számítási időt és memóriát fordított rájuk, és többször válaszolt, mielőtt egyáltalán megtudná, hogy ki kopogtat. Minden olyan intézkedés tehát, amely a bejelentkezésnél fog hozzá, csak azután érvényesül, hogy a terhelés már létrejött.

Ehhez jön egy második, még korábbi belépési pont. Ahhoz, hogy egy szerver névvel, verzióval és játékosszámmal megjelenjen egy játékos szerverlistájában, megválaszolja az Unconnected Ping csomagot (csomag-azonosító 0x01) egy Unconnected Pong csomaggal (csomag-azonosító 0x1C). Ez a csere a tulajdonképpeni kapcsolatfelépítés előtt történik, semmiféle igazolást nem követel, és a Bedrock Dedicated Server esetében nem kapcsolható ki anélkül, hogy a szervert minden szerverlistából kivennénk.

Az Unconnected Ping mint erősítési vektor: a számok

Az erősítéses támadás (amplification) olyan támadás, amelynél a támadó kis kéréseket küld hamisított feladócímmel idegen szervereknek, hogy azok nagyobb válaszai az áldozatnál érkezzenek meg. A Bedrock-szervert ilyenkor nem megtámadják, hanem használják. Az Unconnected Ping esetében a számítás így néz ki:

Ebből két dolog következik közvetlenül. Először: egy hosszú szervernév növeli a választ, és ezzel azt az erősítési tényezőt is, amelyet idegen támadók rendelkezésére bocsát. A rövid név nem kozmetika, hanem védelmi intézkedés. Másodszor: az alapkonfiguráció 4-es tényezője elég kicsi ahhoz, hogy az Ön szervere reflektorként érdektelen maradjon, de elég nagy ahhoz, hogy egy pingáradat a saját kimenő vonalát a beérkező mennyiség négyszeresével terhelje.

A 2024-es erősítési hiba megmutatja, milyen súlyos lehet, ha magával a megbízhatósági réteggel élnek vissza. Az akkor használt RakNet-könyvtárban a Connection Request Accepted csomag megbízhatóként volt megjelölve. Egy támadó hamisított feladócímmel eddig a pontig végigjátszhatta a kapcsolatfelépítést, majd utána egyetlen negatív visszaigazolást küldhetett a 0-tól 8191-ig terjedő tartománnyal. A szerver erre több ezer csomagot küldött a hamisított címre anélkül, hogy a támadónak további bármit is tennie kellett volna. A javítás úgy történt, hogy a csomagot nem megbízhatóra állították át, hogy az Open Connection Reply 1 csomagban cookie-t küldenek, amelyet egy valódi kliens visszatükröz, és hogy csomagkorlátokat vezettek be: 120 csomag forráscímenként és 10 milliszekundumos ütemenként, összesen 1000 csomag ütemenként.

Bedrock Edition vagy Java Edition: mi más a DDoS-védelemben

Aki már biztosított be Java-szervert, az szinte mindent rosszul visz át. A két kiadás a nevet osztja meg, a hálózati protokollt nem:

A SYN-cookie-król szóló sor a legfontosabb. A Java Edition esetében a Linux-kernel hárít el egy SYN-áradatot anélkül, hogy a Minecraft-folyamat bármit is észrevenne belőle. A Bedrock Edition esetében ez a segítség nincs meg: minden egyes UDP-csomagot továbbadnak egészen a szerverfolyamatig, és ott értékelik ki. Egy Bedrock-szervernek a 19132-es port elleni flood ellen nincs beépített védelme az operációs rendszerben, mert az UDP nem ismer ilyet.

A hiányzó SRV-rekordról szóló sornak van egy gyakorlati következménye, amely sokakat meglep: a Bedrock Edition esetében a portot nem tudja DNS-rekord mögé elbújtatni. A játékosok a címet és a portot kézzel írják be. Aki áthelyezi a portot, annak minden játékossal közölnie kell az új portot.

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

Egy Bedrock Dedicated Server pontosan két portra kötődik, mégpedig mindkettőre UDP-n. A server.properties fájlban:

server-port=19132
server-portv6=19133
enable-lan-visibility=true
online-mode=true
allow-list=false
max-players=10
player-idle-timeout=30
max-threads=8

Ezek a Microsoft alapértékei, a Bedrock Dedicated Server referenciájában utánaolvashatók. E két port körül további szolgáltatások fekszenek, amelyek a szerverszoftvertől függően együtt futnak:

A harmadik és a negyedik sor a leggyakoribb elkerülhető hiba a Bedrock-szervereken. A Nukkit és a PocketMine-MP esetében az enable-query gyárilag be van kapcsolva, a Nukkit esetében pedig egy véletlenül bekapcsolt RCON a 19132 TCP porton landol, tehát ugyanazon a portszámon, mint a játék. Aki csak annyit néz, hogy „a 19132 nyitva van, rendben lesz”, az ezt átnézi.

A hivatalos Bedrock Dedicated Server egy sajátossága szintén ide tartozik: nem ismeri a server-ip direktívát. A PocketMine-MP és a Nukkit rendelkezik vele (server-ip, a PocketMine esetében ezen felül server-ipv6), a hivatalos szerver nem. Tehát mindig a rendszer összes címén figyel, és a tűzfal az Ön egyetlen lehetősége arra, hogy ezt korlátozza.

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

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

1. Leltár: mi figyel egyáltalán a 19132-esen?

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

ss -lntup
ss -lnup sport = :19132

A helyi címet tartalmazó oszlop az érdekes. A 0.0.0.0:19132 és a [::]:19133 azt jelenti, hogy „az egész internetről elérhető”. Ha emellett ugyanazon a portszámon TCP-bejegyzés is feltűnik, akkor RCON fut. A támadó nézőpontját egy kívülről indított portszkennelés adja meg, UDP esetén a -sU kapcsolóval:

nmap -Pn -sU -p 19132,19133 A.SZERVERE.IP.CÍME
nmap -Pn -p- --min-rate 1000 A.SZERVERE.IP.CÍME

2. Csak a 19132 UDP portot hagyja nyitva, minden mást zárjon be

Egy Bedrock-szerverhez egyetlen kifelé irányuló engedélyezés elegendő, IPv6-tal kettő. UFW-vel ez így néz ki, méghozzá pontosan ebben a sorrendben, hogy ne zárja ki saját magát:

ufw allow 22/tcp comment 'SSH'
ufw allow 19132/udp comment 'Bedrock IPv4'
ufw allow 19133/udp comment 'Bedrock IPv6'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Ha nincsenek IPv6-játékosai, hagyja ki a 19133-hoz tartozó sort, és a PocketMine-MP esetében állítsa be ezen felül az enable-ipv6=false értéket. Minden port, amelyet nem engedélyez, olyan port, amelyet nem kell megvédenie. 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ó.

3. A LAN-láthatóság kikapcsolása, különben a 19132 nyitva marad

Ez az a csapda, amelybe szinte mindenki belesétál, aki át akarja helyezni a portot. Az enable-lan-visibility direktíva gyárilag true értéken áll, és arról gondoskodik, hogy a szerver válaszoljon a helyi hálózatban érkező keresésekre. A Microsoft ehhez kifejezetten azt írja, hogy a szerver ezáltal ezen felül a 19132-es és a 19133-as alapértelmezett portra is kötődik, akkor is, ha a server-port és a server-portv6 más értéken áll.

Aki tehát a portot a 19140-esre helyezi át, és biztonságban hiszi magát, az továbbra is a 19132-esen figyel. Egy interneten álló szerver server.properties fájljába ezért ez való:

enable-lan-visibility=false

Utána az ss -lnup paranccsal ellenőrizze, hogy a 19132 valóban eltűnt-e. Mellékesen ugyanez a beállítás megoldja azt a problémát is, hogy két Bedrock-szerver ugyanazon a hoszton elveszi egymástól a portot.

4. A lekérdezés és az RCON kikapcsolása

A PocketMine-MP és a Nukkit magával hozza a GS4-lekérdezést, egy UDP-alapú szerverlekérdezést az UT3-protokoll mintájára, és ezeket a lekérdezéseket ugyanazon a 19132-es porton válaszolja meg, amelyen a játék fut. A részletes válasz tartalmazza a szervernevet, a verziót, a világnevet, az engedélyezőlista állapotát, a címet és a portot, a játékosszámot, minden csatlakozott játékos nevét, a PocketMine-MP esetében pedig kívánságra a teljes pluginlistát. Ez praktikus az állapotoldalaknak és a Discord-botoknak, viszont pontosan elárulja egy támadónak, mikor érdemes támadni, és lekérdezésenként számítási időbe kerül.

enable-query=off
enable-rcon=off

A PocketMine-MP esetében az értékek false, nem off, a pluginlistát pedig a pocketmine.yml fájlban a settings.query-plugins: false beállítással kapcsolja ki. Egy összefüggés, amelyet ritkán olvas az ember: a PocketMine-MP GS4-lekérdezése olyan tokent ellenőriz, amely a feladócímmel van sózva. A nagy válasz így nem tükröztethető hamisított címre. A lekérdezés mégis számítási időbe kerül, a közzétett adatok pedig segítik a támadót a célpont kiválasztásában. A hivatalos Bedrock Dedicated Server sem lekérdezést, sem RCON-t nem ismer, ott ez a pont elesik.

Ha tényleg szüksége van az RCON-ra, a Nukkit esetében feltétlenül állítsa a rcon.port értékét saját értékre, és csak a saját címére engedélyezze. A server-port értékére való visszaesés egyébként azt jelenti, hogy a szervere távoli irányítása a 19132 TCP porton figyel, tehát ugyanazon a számon, amelyet amúgy is mindenhol „nyitottként” vett fel.

5. Az Xbox Live-hitelesítés kikényszerítése

Az Xbox Live-hitelesítés az az ellenőrzés, hogy egy belépő játékos valódi, a Microsoft által aláírt fiókkal rendelkezik-e. Mindhárom szerverszoftverben gyárilag be van kapcsolva, és ott is kell maradnia.

A Bedrock Dedicated Server esetében a direktíva neve online-mode, a PocketMine-MP és a Nukkit esetében xbox-auth. Mindkét esetben a true a gyári állapot és a helyes érték:

online-mode=true
xbox-auth=true

A Microsoft ehhez egy fontos megszorítást fogalmaz meg: azok a kliensek, amelyek a helyi hálózaton kívüli szerverhez kapcsolódnak, amúgy is mindig szükségelik az Xbox Live-hitelesítést, ettől a beállítástól függetlenül. Az igazolás aláírt tokenláncként kerül átvitelre a bejelentkezési csomagban, az Xbox-azonosítóval (XUID) és a megjelenítendő névvel együtt.

És most az a rész, amely a félreértések ellen segít: az Xbox Live-hitelesítés a játéklogikáját védi, nem a vonalát. A bejelentkezési csomagban történik, tehát a teljes RakNet-kapcsolatfelépítés után. Az a támadó, aki elárasztja a szerverét, egyáltalán nem akar belépni. A csomagjait a szerver visszautasítja, de attól még megérkeztek, és pontosan ez a lényeg.

6. Az engedélyezőlista és a játékos-felsőkorlát, és amit nem nyújtanak

Az engedélyezőlista (korábban whitelist) azoknak a játékosoknak a listája, akik beléphetnek. A Bedrock Dedicated Server esetében az allow-list=true beállítással kapcsolja be, a bejegyzések az allowlist.json fájlban állnak névvel, XUID-dal és az ignoresPlayerLimit mezővel. A Nukkit és a PocketMine-MP esetében a direktíva neve továbbra is white-list.

allow-list=true
max-players=60
player-idle-timeout=15

Egy rövid tétlenségi idő a player-idle-timeout segítségével hatásos a férőhelyek kimerítése ellen: azok a játékosok, akik csak egy férőhelyet foglalnak el, a megadott percszám után kirepülnek. A 0 érték azt jelenti, hogy soha senkit nem bont le a szerver tétlenség miatt, és pontosan ezt használja ki az a támadó, aki valódi fiókokkal blokkolja az Ön férőhelyeit.

Itt is érvényes az előző szakasz korlátja, és ez az egyáltalán leggyakrabban átnézett pont: az engedélyezőlistát csak akkor ellenőrzi a szerver, ha a bejelentkezési csomag már fel van dolgozva. Belépéseket akadályoz meg, csomagokat nem.

7. A csomagsebesség korlátozása forráscímenként

A kis támadások és a rosszul megírt botok ellen segít egy forráscímenkénti felső korlát. UDP esetén hashlimit segítségével dolgozunk, nem connlimit segítségével, mert az UDP nem ismer kapcsolatokat:

iptables -I INPUT -p udp --dport 19132 -m hashlimit --hashlimit-name bedrock_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

A szabály eldobja az UDP-csomagokat, amint ugyanaz a forráscím tartósan több mint 400 csomagot küld másodpercenként. Az érték kiindulási érték, nem igazság: egy tele szerver 60 játékossal és nagy látótávolsággal lényegesen több csomagot termel, mint egy üres, és aki túl szűken állít be, az a saját játékosait dobja ki. Először mérjen egy hetet normál üzemben.

Lényegesen szigorúbban állíthat be az Unconnected Ping esetében, mert egy valódi kliens csak addig kérdezi a szerver állapotát, amíg a szerverlista nyitva van, és akkor is másodpercenkénti ütemben. Az nftables segítségével pontosan ez az egy csomag található el, mert a csomag-azonosító az UDP-fejléc utáni első bájt:

nft add table inet bedrock
nft add chain inet bedrock prerouting '{ type filter hook prerouting priority -150 ; policy accept ; }'
nft add rule inet bedrock prerouting udp dport 19132 @th,64,8 0x01 limit rate over 500/second drop

A @th,64,8 kifejezés nyolc bitet olvas a transzportfejléc 64. bitjétől, tehát az UDP hasznos adat első bájtját. A 0x01 érték az Unconnected Ping csomag-azonosítója. Ugyanezt a helyet megfigyelésre is használhatja, mielőtt bármit is eldobna:

tcpdump -ni eth0 'udp dst port 19132 and udp[8] = 0x01' -c 200 -q
tcpdump -ni eth0 'udp src port 19132 and udp[8] = 0x1c' -c 200 -q

Az első sor a bejövő állapotlekérdezéseket számolja, a második az Ön saját válaszait. Ha mindkettő másodpercenkénti ütemben ezresekbe fut, miközben alig játszik valaki, akkor pingáradatot lát, nem a játékosait.

Két megjegyzés a tartósságról. A tiszta iptables-szabályok egy újraindítás után eltűnnek, Debian és Ubuntu alatt így mentjük őket:

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

UFW alatt pedig az ilyen szabályok az /etc/ufw/before.rules fájlba valók, mert egyébként a következő ufw reload parancsnál eltűnnek.

8. A kernel kapcsolatkövetésének tehermentesítése

Egy szűk keresztmetszet, amely az UDP-játékok esetében sokkal hamarabb üt be, mint a TCP esetében: a kernel minden UDP-csomagpárhoz bejegyzést hoz létre a kapcsolatkövetésben. Hamisított feladócímekkel járó áradat esetén minden csomag új forráscím, és ezzel új bejegyzés. Ha a tábla megtelik, a szerver a jogos csomagokat is eldobja, a naplóban pedig az áll, hogy „nf_conntrack: table full, dropping packet”.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Ha a számláló állása tartósan a felső korlát közelében van, kiveheti a játékforgalmat a követés alól. Ez hatásos, de nem következmények nélküli, ezért mindkét irányban és utána egy kapcsolattesztet elvégezve:

iptables -t raw -I PREROUTING -p udp --dport 19132 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 19132 -j NOTRACK

Ezután az állapotalapú szabályok erre a forgalomra már nem érvényesülnek. A 19132 UDP portra vonatkozó engedélyezésének tehát valódi portengedélyezésnek kell lennie, és nem hagyatkozhat az ESTABLISHED állapotra. A beállítás után a conntrack -L | grep 19132 paranccsal ellenőrizze, hogy nem keletkeznek-e már bejegyzések, és kapcsolódjon egyszer a játékkal, mielőtt tartósan elmenti a szabályokat.

9. A Geyser és a Floodgate tiszta üzemeltetése

A Geyser olyan híd, amely lehetővé teszi a Bedrock-klienseknek, hogy Java Edition-szerveren játsszanak: a 19132 UDP porton fogadja a Bedrock-kapcsolatokat, lefordítja a protokollt, és a másik oldalon a 25565 TCP porton beszél a Java-szerverrel. A Floodgate az a kiegészítés, amely ezeknek a Bedrock-játékosoknak Java-fiók nélkül is engedi a belépést. A DDoS-védelem szempontjából ez három dolgot jelent.

Először: tartsa naprakészen a Geysert. Pontosan ez a híd volt kétszer is dokumentált támadások oka. 2024 márciusában a fent leírt erősítési hibát a RakNet-könyvtárban széles körben kihasználták, a javítás a 478-as buildtől van benne. 2025 júliusában egy második eset követte: az erőforráscsomagok visszaigazolására ismételten elküldött csomag több munkamenetet hozott létre játékosonként, a lebontott kliensek pedig továbbra is tudtak csomagot küldeni, mert a hálózati csatorna nem került bezárásra. Javítva a 897-es buildtől. Mindkét esetet a projekt maga tette közzé idővonallal.

Másodszor: a Java-szerver nem való a nyílt hálózatra. A Geyser konfigurációjában a remote.address az auto, illetve a 127.0.0.1 értékre mutat, a remote.port pedig a 25565-re. Kösse ennek megfelelően helyben a Java-szervert, és a 25565 TCP portot ne engedélyezze kifelé. Különben egy helyett két támadási felülete van, és a második az, amelyhez soha nem gondolt ki szabályokat.

Harmadszor: a key.pem fájl titok. Ez az a kulcs, amellyel a Floodgate átlépi a Java-hitelesítést a Bedrock-fiókok számára. Aki nyilvános tárolóba teszi, support-ticketbe másolja vagy képernyőképen megmutatja, az elajándékozta a szervere bejelentkezését. A projekt kifejezetten figyelmeztet erre.

10. Mérési értékek gyűjtése, mielőtt bedurran

A legfontosabb lépés az, amelyet szinte senki nem tesz meg előre: egy összehasonlítási alap létrehozása, 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 conntrack paranccsal a mérés tartósan együtt fut.

sar -n DEV 1 10
ip -s link show eth0
ss -lunp sport = :19132
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|UdpRcvbufErrors'
dmesg -T | tail -50

Ezek közül három érték különösen árulkodó egy Bedrock-szerver esetében. Egy tartósan nullától eltérő Recv-Q a 19132-es UDP-socketen azt jelenti, hogy a szerverfolyamat már nem szedi le elég gyorsan a beérkező csomagokat. Az UdpRcvbufErrors pontosan azokat a csomagokat számolja, amelyeket ezért eldobtak, és ez a legkeményebb bizonyíték arra, hogy nem a vonal, hanem a folyamat a szűk keresztmetszet. Az UdpNoPorts akkor emelkedik, ha valaki olyan portokat lő, amelyeken egyáltalán semmi nem figyel, ez tipikus kép egy széles körben szórt portszkennelésnél a tulajdonképpeni támadás előtt.

A tcpdump parancsra érvényes: mindig korlátozza a -c kapcsolóval, mert egy teljes terhelés alatt készült felvétel tovább terheli az amúgy is túlterhelt szervert. Hogy az értékeket hogyan értékelje ki, arról a DDoS-támadás felismerése című cikk szól.

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

Most jön az a rész, amelyet egyetlen konfigurációs fájl sem 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 meg nem küldötté nem tudja tenni.

Számoljon egyszer velünk. Az Ön vonala tele van, amint valaki több mint 125 megabájtot küld másodpercenként. Egy 5 és 50 Gbit/s közötti támadás ennek az öt-ötvenszeresénél van. Hogy az Ön hashlimit-szabálya mögötte jó-e, akkor már nem játszik szerepet, mert a játékosai csomagjai már előtte sem jutnak át.

A második mennyiség a csomagsebesség, és egy Bedrock-szerver esetében szinte mindig ez üt be először. A teljes játékforgalom sok kis UDP-csomagból áll, és pontosan ebben a diszciplínában a legkedvezőbb a támadó helyzete. Egy támadás, amely a vonalát még harmadáig sem tölti meg, mégis megbéníthatja a szerverét, mert a számítási idő a kiértékelésre és az eldobásra megy el. Az üzemeltetők ezt úgy élik meg, hogy „a kihasználtság nem is volt magas, mégis mindenki kikerült”. A játékban ugyanez lag-tüskékként, gumiszalag-effektusként és építés közepén bekövetkező kapcsolatmegszakadásként jelenik meg.

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 a KernelHost a Bedrock-szerverek elleni DDoS-támadásokkal szembe

A folyamatos védelem, amely minden szerveren benne van

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

• 1. réteg: 17 Tbps mitigációs kapacitás a globális scrubbing-hálózatban. A volumetrikus támadásokat a forrásuk közelében tisztítjuk ki, 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 ismerjük fel és dobjuk el a protokollspecifikus mintákat, csomagról csomagra. Ehhez tartoznak azok a 19132-es porton érkező UDP-minták is, amelyek nem mutatnak RakNet-viselkedést.

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 percek az elején, amikor a szerver elérhetetlen. És nem alkalmazunk null-routingot: az Ön IP-címe a hálózaton marad, csak a káros csomagokat dobjuk 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ó. A helyszín 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 lőtt projektekhez

Egyes projekteket nem alkalmanként, 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 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.
• Önállóan kezelhető védelmi szabályok portonként és protokollonként az ügyfélportálon: Ön állítja be, mi engedélyezett a 19132 UDP porton, mi a 19133 UDP porton, és mi egy eltérő porton, ha áthelyezte a szerverét.
• A módosítások valós időben lépnek érvénybe, tehát egy zajló támadás közben is tud utánaállítani, ahelyett hogy a következő karbantartási ablakra várna.
• Az adott játékhoz illő védelmi profil. A Minecrafthoz készen állnak profilok, ugyanígy módosított és saját alkalmazásokhoz bármilyen TCP- vagy UDP-porton, tehát a Nukkithoz, a PocketMine-MP-hez vagy egy Geyser-példányhoz is egy saját választott porton.

A két szint összehasonlítása

A legtöbb Bedrock-projektnek elegendő a beépített folyamatos védelem egy tiszta szerverkonfigurációval együtt. Az Advanced DDoS Protection arra a helyzetre a válasz, amikor valaki személyes ügyet csinál belőle. Aki a szerverét jelenleg máshol üzemelteti, az a problémát leginkább egy költözéssel oldja meg: a szűrés a szerver előtti hálózatban hat, és ennek a hálózatnak a miénknek kell lennie.

Gyakori hibák és megoldások

„A portot 19140-re módosítottam, a 19132 mégis nyitva van”: ez az enable-lan-visibility=true. A Bedrock Dedicated Server ilyenkor ezen felül a 19132-re és a 19133-ra is kötődik, mindegy, mi áll a server-port értékében. Állítsa false értékre, indítsa újra a szervert, és az ss -lnup paranccsal ellenőrizze.

„Szerkesztettem az allowlist.json fájlt, és már magam sem jutok be”: két ok gyakori. Még egy régi whitelist.json fájl van a könyvtárban, amelyet a szerver helyette olvas, vagy hiányzik, illetve hibás a XUID-bejegyzés. A név egyedül aktív Xbox Live-hitelesítés esetén nem elegendő megbízhatóan.

„A hosztolóm letiltotta a szerveremet, noha én voltam a megtámadott”: ellenőrizze, hogy az Ön szervere maga küldött-e ki csomagokat. Pontosan ez történt a RakNet 2024-es erősítési hibájánál: az érintett szerverek több ezer csomagot küldtek idegen címekre, és az abuse-bejelentésekben a 19132-es port szerepelt forrásként. A tcpdump -ni eth0 'udp src port 19132' -c 200 -q paranccsal látja, hová válaszol a szervere. Egy aktuális build megszünteti az okot.

„Az iptables-szabályaim nem hatnak”: három ok gyakori. A szabályok az UFW-láncok mögött állnak, és soha nem érik el őket; 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 emelkednek-e a találati számlálók. Ha nullán maradnak, a szabályt nem éri el a forgalom.

„A szerver szerepel a listában, de senki nem jut be”: ha a bejegyzés nevet és játékosszámot jelez, akkor az Unconnected Pong működik, tehát a port alapvetően elérhető. Ha a belépés ennek ellenére meghiúsul, az többnyire az Xbox Live-bejelentkezésen vagy az engedélyezőlistán múlik. Ha megfordítva csak az IPv6-játékosok nem jutnak be, akkor a 19133 UDP portra vonatkozó engedélyezés hiányzik.

„A szerver fut, de mindenkinek lag-tüskéi vannak”: ez gyakrabban plugin, mint támadás. Először nézze meg, hogy nő-e a Recv-Q az UDP-socketen, és emelkedik-e az UdpRcvbufErrors. Ha mindkettő nyugodt marad, és a sar -n DEV 1 10 is feltűnésmentes, akkor nem DDoS-támadás volt, hanem maga a szerverfolyamat. A Bedrock Dedicated Server esetében ilyenkor a szkript-watchdogok segítenek tovább, amelyek küszöbei a server.properties fájlban a script-watchdog-hang-threshold és a script-watchdog-slow-threshold alatt állnak.

„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 azután is. Kétség esetén kérdezzen rá, hogy szűrés történik-e vagy null-routing. 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 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ég az az SSH-munkamenet sem ér el Önhöz, amellyel mérni szeretett volna. 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 Minecraft Bedrock szervernek pontosan egy nyitott portra van szüksége kifelé: 19132 UDP, ehhez 19133 UDP csak az IPv6-játékosoknak. A lekérdezés, az RCON, a szkript-debugger a 19144 TCP porton és egy Java-szerver a Geyser mögött a 25565 TCP porton nem való a nyílt hálózatra.
• Aki áthelyezi a portot, annak be kell állítania az enable-lan-visibility=false értéket, különben a Bedrock Dedicated Server ezen felül továbbra is a 19132-re és a 19133-ra kötődik.
• Az Xbox Live-hitelesítés és az engedélyezőlista csak a bejelentkezési csomagban érvényesül, tehát a teljes RakNet-kapcsolatfelépítés után. A játéklogikáját és a férőhelyeit védik, nem a vonalát.
• Az Unconnected Ping 33 bájttal kerül lekérdezésre, és körülbelül 131 bájttal kerül megválaszolásra, ez körülbelül négyes erősítési tényező. Egy rövid szervernév kicsin tartja ezt a tényezőt.
• UDP esetén a hashlimit segít a connlimit helyett, a kernel kapcsolatkövetése pedig hamisított feladócímek esetén telik meg elsőként. Mindkettőt meg kellett volna mérnie az első támadás előtt.
• Körülbelül 1 Gbit/s fölött az Ön vonala tele van, és 64 bájtos csomagok esetén körülbelül 1,49 millió csomag fér oda másodpercenként. Ezen felül 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 benne van, a kiszállítástól aktív és null-routing nélkül működik. Az Advanced DDoS Protection egy 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 support-ticketet, hogy a szűrési szabályokat az Ön IP-címéhez igazítsuk. Zajló támadás esetén ezen felül a WhatsApp-vészhelyzeti chaten ér el minket a +43 650 8209883 számon.