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

Az a Hytale-szerver, amely este a játék közepén egyszerre veszíti el az összes kapcsolatot, néhány percig elérhetetlen, majd magától újra fut, ritkán szenved hardverhibától. Többnyire támadás fut. Ez a cikk megmutatja, hogyan védi meg a Hytale-szerverét a DDoS-támadások ellen: először azt, amit többletköltség nélkül maga tud beállítani, utána azt a helyet, ahol ezek az intézkedések technikailag véget érnek, végül pedig azt, minek kell a szerver előtti hálózatban történnie ahhoz, hogy a szerver elérhető maradjon.

Minden adat a Hypixel Studios hivatalos dedikált szerverére vonatkozik, tehát a HytaleServer.jar fájlra az Assets.zip fájllal együtt Java 25 alatt, Debian 12, Debian 13, Ubuntu 22.04 LTS vagy Ubuntu 24.04 LTS rendszeren üzemeltetve. A parancsok root felhasználóhoz készültek, normál felhasználóként tegye eléjük a sudo parancsot. A Hytale Early Accessben van és gyorsan mozog: ezért a cikkben a játékról szóló minden állítás dátumot hordoz, és mindaz, ami nem hivatalosan bizonyított, kifejezetten elvárásként vagy közösségi forrásként van megjelölve. Ha a támadás éppen fut, ezenfelül egy sorrend is érvényes: először mérni, aztán változtatni. A terhelés alatti kemény újraindítás eldob mindent, ami a világban a legutóbbi mentési pont óta történt, és a rendellenesség mérési értékei is elvesznek utána.

Miért fektetik le célzottan DDoS-támadásokkal a Hytale-szervereket

A Hytale-szerver egy közönség egy fix címen, és ez a közönség pótolható. Aki este háromszor egymás után nem jut be a törzsszerverére, keres egy másikat. Pontosan ez az üzleti modell a közösségi szerverek ellen irányuló támadások mögött: nem adatokról és nem zsarolásról van szó, hanem játékosokról, akik továbbállnak. Az a booter-szolgáltatás, amely havi néhány euróért lő egy címet, a megbízótól sem tudást, sem ráfordítást nem kér, a kár pedig minden kiesésnél újra keletkezik.

Ehhez a Hytale-nál egy különlegesség is jön: a szerverkód nyilvános. A Hypixel Studios 2026 júniusában hirdette meg a Hytale Shared Source programot, és ezen keresztül a teljes szerverkódot, a hálózati protokollt és az assetet GitHubon bocsátja rendelkezésre, mindenki számára elérhetően, akinek érvényes játéklicence van. A szerverüzemeltetők számára ez nyereség, mert a pluginek valódi interfészekre épülnek. A támadó oldal számára viszont azt jelenti, hogy a protokollt már senkinek nem kell kitalálnia. Aki tudni akarja, hol kér processzoridőt a kapcsolatfelépítés, utánaolvashat. Hogy egy ilyen támadásnál technikailag mi történik, azt a Mi az a DDoS-támadás? című cikk magyarázza el.

A Hytale állása 2026. szeptember 27-én

A Hytale 2026. január 13-a óta van Early Accessben, Windowsra, macOS-re és Linuxra kapható, és a rajt utáni napokban több mint egymillió játékost ért el. Az idevezető út szokatlan volt, és megmagyarázza, miért nem stimmelnek már gyakran a Hytale-ról szóló régebbi cikkek.

Ennek a kronológiának a gyakorlati következménye: a mai Hytale-szerver nem januári szerver. A 6. frissítéssel a hálózati protokoll hytale/2-ről hytale/3-ra változott, és a 2026. augusztus 27-i hivatalos patch notes szerint a szervereket és a plugineket újra kell építeni, mielőtt kapcsolódnak. Aki az elérhetőségét tervezi, ezért nem csak a támadások ellen tervez, hanem a protokollváltások ellen is.

Miért 2026. október 12. a kritikus dátum

A nagy tartalmi frissítések úgy hatnak, mint egy második értékesítési rajt. Visszahozzák a régi játékosokat, újakat vonzanak, és néhány napon át az elérhetőség dönti el, melyik közösségi szerver nő ki ebből a hullámból és melyik hagyja ki. Ez a minta más játékokon igazolt: a Palworld 2024 januárjában néhány nap alatt millió játékost ért el, és ennek a rajtfázisnak a közösségi szervereit pontosan akkor támadták a legtöbbet, amikor a legtöbbet veszíthették. Az emögött álló mechanika a Palworld-szerverek védelme DDoS-támadások ellen című cikkben részletesen le van írva, és egy az egyben átvihető a Hytale-ra.

Ebből egy kényelmetlen igazság következik az időrendről: az a védelem, amelyet október 12-én rendelnek meg, túl késő. Egy vonalnak, egy védett IP-nek, egy portonkénti szabályrendszernek és egy normál üzemre szóló mérési értéknek előkészülési idő kell, mert összehasonlító adatok nélkül nem állíthatók be értelmesen. Aki két héttel egy nagy frissítés előtt kezd, annak elég ideje van. Aki a frissítés napján kezd, az műszerek nélkül repül.

A portok, amelyekről egy Hytale-szerver esetében valójában szó van

Egy Hytale-szervernek pontosan egy nyitott portra van szüksége: 5520 UDP. A játékforgalom QUIC-en, tehát UDP-n fut, és a TCP-re a játékforgalomhoz nincs szükség. Aki csak TCP-t engedélyez, ugyanazt a képet látja, mint zárt tűzfal esetén: a játékosok időtúllépésbe futnak. A szabványos kötés 0.0.0.0:5520, más portot indításkor a --bind paraméterrel állítunk be.

Ez a táblázat rövidebb, mint a legtöbb más játék esetében, és ez a legfontosabb különbség. Egy Counter-Strike-szerver A2S Steam-formátumban válaszol az állapotlekérdezésekre, egy Minecraft Bedrock-szerver Unconnected Pingre válaszol, egy Palworld-szerver saját lekérdezőportot tart nyitva. A Hytale-hoz a nyilvános dokumentációban az 5520 UDP mellett nincs további port leírva: nincs lekérdezőport, nincs RCON-port, nincs REST-interfész a kiszállítási állapotban. Mindaz, amit egy Hytale-szerver kifelé kínál, egyetlen UDP-porton áll.

A Hytale-szerver számokban

A következő értékek minden szűrőszabályról és határértékről szóló döntés alapját adják. Az eredet mindegyiknél ott áll, mert az dönt a terhelhetőségről.

Mit változtat a QUIC a támadási felületen

A QUIC olyan szállítási protokoll, amely UDP-n keresztül épít biztosított kapcsolatokat, és a TLS 1.3 szerinti titkosításfelépítést fixen beépítve tartalmazza. Titkosítás nélküli QUIC nem létezik. Egy szerverüzemeltető számára ez két olyan dolgot jelent, amelyek ellentmondanak egymásnak, és mindkettő fontos.

Az első valódi javulás. Mivel az UDP nem kényszerít ki kapcsolatfelépítést, és a feladócímek hamisíthatók, a kapcsolat nélküli UDP-szolgáltatások a klasszikus erősítők a harmadik felek ellen irányuló támadásokhoz. A QUIC ezt a standardban korlátozza. Az RFC 9000 a 8.1. szakaszban előírja, hogy a szerver a feladócím ellenőrzése előtt legfeljebb a fogadott bájtmennyiség háromszorosát küldheti, a 14.1. szakasz pedig megköveteli, hogy a kliens az első datagrammját legalább 1200 bájtra kitöltse. Ez a két szabály együtt legfeljebb háromra viszi le egy QUIC-szolgáltatás erősítési tényezőjét, míg egy Steam-lekérdezőport vagy egy Bedrock-Unconnected-Ping ennek a többszörösére jut. Egy helyesen működő Hytale-szerver ezért reflexiós erősítőként gyakorlatilag érdektelen. Ez strukturális előny szinte minden más, UDP-forgalmat használó játékkal szemben, és a Minecraft Bedrock-szerverekkel való összehasonlításnál szembeszökő.

A második ennek az ára. Egy QUIC-kapcsolatfelépítés processzoridőbe kerül a szervernek, mert TLS 1.3-as egyeztetést foglal magában aszimmetrikus kriptográfiával. Egyetlen hamisított csomag nem tud felépítést kikényszeríteni, de valódi kapcsolódási kísérletek áradata egy botnetből igen. A támadó közben szintén processzoridőt fizet, és pontosan ez az arány dönt: amíg a szerver kapcsolódási kísérletenként több munkát végez, mint a támadó, a támadás gazdaságos. A kapcsolódási kísérletek áradata ezért nem a vonalat terheli, hanem a processzort, és a sávszélesség-statisztikában semminek sem látszik. Ez ugyanaz a mechanizmus, amely a Minecraftnál nullping és kézfogásos áradat néven ismert, és amelyet a Minecraft-DDoS-védelem és nullping-védelem című cikk részletesen leír.

A gyakorlatban mindebből elsősorban az 1200 bájtos szabály hasznosítható. Egy új kapcsolódási kísérletnek legalább 1200 bájtos datagrammként kell megérkeznie, különben a standard szerint nem érvényes kapcsolatfelépítés. A folyamatos játékforgalom ezzel szemben túlnyomórészt kis csomagokból áll. Ez a különbségtétel szűrőszabályba önthető, és mindjárt rá is térünk.

Ami a Hytale-ról nincs nyilvánosan dokumentálva

Ez a lista egy tisztességes cikkbe tartozik, mert megállapítja, hol nem hagyatkozhat számokra. Minden alábbi 2026. szeptember 27-i állás szerint nem hivatalosan bizonyított:

• Hogy a szerver alkalmaz-e QUIC-Retryt a címellenőrzésre. Az RFC 9000 a 8.1.2. szakaszban megenged egy tokennel ellátott Retry-csomagot, amellyel a szerver ellenőrzi a feladócímet, mielőtt erőforrásokat kötne le. Hogy a Hytale ezt megteszi-e, és milyen terheléstől, nincs dokumentálva. Vegye alapul, hogy erre nem hagyatkozhat.
• A RateLimit és a ConnectionTimeouts blokk alapértelmezései a config.json fájlban. Az, hogy mindkét blokk létezik, több forráson keresztül következetesen adott. A megnevezett számok viszont ellentmondanak egymásnak: az egyik forrás konkrét határértékeket nevez meg, a másik létezőként, de hatás nélkülieknek írja le a blokkokat. Ezért ebben a cikkben ezek közül a számok közül egy sem szerepel, és ezért ne is tervezze be ezeket a blokkokat védelemként.
• A hitelesítési módok nevei és alapértelmezései. A nyilvánosságra hozott szerverkódhoz tartozó közösségi dokumentáció három módot ír le, amelyeket az --auth-mode paraméterrel állítunk be, authenticated alapértelmezéssel, valamint offline és insecure módokkal privát környezetekhez és fejlesztéshez. Ez hivatalosan nincs megerősítve. Az ebből levezetett szabály ettől függetlenül egyértelmű: nyilvános szerveren ne változtassa meg a módot.
• A TLS-felépítés részletei. A nyilvánosságra hozott szerverkódon alapuló közösségi protokolldokumentáció kétoldalú tanúsítványt, indításkor előállított, saját kiállítású szervertanúsítványt (amelynek SHA-256 ujjlenyomata a munkamenet-szolgáltatáson keresztül jut el a kliensekhez), valamint kikapcsolt 0-RTT-t ír le. Ez hihető és illik a TLS 1.3-hoz, de hivatalosan nincs megerősítve, és semmit nem változtat a lentebbi intézkedéseken.
• Kifejezetten Hytale-szerverek ellen irányuló támadásméretek. Erről nincsenek nyilvános számok. A táblázatban megnevezett 5 és 50 Gbit/s közötti érték játékszerver-projekteken átnyúló tapasztalati érték, és kifejezetten nem Hytale-statisztika.
• Csomagsebességek normál üzemben, játékosonként. Erre sincs terhelhető publikáció. Ezért ebben a cikkben nem szerepel olyan határérték, amelyet ellenőrzés nélkül átvehetne, hanem útmutató arra, hogyan mérje meg saját maga.

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

A következő lépések egyetlen volumetrikus támadást sem tartanak fel, erre a szerveren futó szoftver nem képes. Elviszik viszont mindazt, ami ez alatt van: portszkennelést, kapcsolódási kísérletek áradatát kevés forrásból, átvételi kísérleteket az ezenfelül telepített kezelőfelületeken keresztül, és az összes férőhely idegenekkel való elfoglalását. Ez a nagyobb része annak, ami egy Hytale-szervert a mindennapokban zavar, és egy jó órába kerül.

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:5520 azt jelenti: „az egész internetről elérhető”, a 127.0.0.1:8080 azt jelenti: „csak helyben”, és nem kell hozzá engedélyezés. A szerver Java-folyamata mellett egy régóta használt gépen gyakran felbukkan egy kezelőpanel, egy webszerver a térképmegjelenítéshez és egy adatbázis. A támadó nézőpontját egy kívülről indított portszkennelés adja meg:

nmap -Pn -sU -p 5520 A.SZERVERE.IP.CÍME
nmap -Pn -p- --min-rate 1000 A.SZERVERE.IP.CÍME

A második hívás a fontosabb. Azt mutatja, mi áll még nyitva, és a gyakorlatban ez szinte mindig több a vártnál.

2. Csak az 5520 UDP maradjon nyitva, minden más zárva

Két engedélyezés elég. 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 5520/udp comment 'Hytale QUIC'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

TCP-engedélyezésre az 5520-on nincs szüksége. Ha a szervert eltérő porton üzemelteti, az engedélyezésnek illeszkednie kell a --bind értékéhez, különben az indítás lefut, és a játékosok mégsem jutnak be. 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 áll.

Mindarra, amit a kezeléshez ezenfelül telepített, ugyanaz a szabály érvényes, mint minden más játéknál: ne a nyílt hálózatba, hanem SSH-porttovábbításon keresztül legyen elérhető, és utána helyben, a 127.0.0.1 címen dolgozzon vele:

ssh -N -L 8080:127.0.0.1:8080 root@A.SZERVERE.IP.CÍME

3. Úgy indítsa a szervert, ahogy azt szánták

Az indítás egyetlen parancsból áll. A szerverfájlokat a hivatalos Hytale-letöltőn keresztül vagy a saját játéktelepítéséből szerzi be:

java -Xms2G -Xmx4G -jar HytaleServer.jar --assets Assets.zip --bind 0.0.0.0:5520

Az első indításnál a szerver létrehozza a config.json fájlt, a logs/ könyvtárat és a universe/ világkönyvtárat. Utána egyszer bejelentkezteti a fiókján, hogy a játékosok hitelesítése működjön. Ez a szerverkonzolban megjelenő eszközkódon keresztül fut:

/auth login device
/auth status

Az -Xmx értékét ne állítsa a gép teljes memóriájára. Az operációs rendszernek, a fájlrendszer gyorsítótárának és a heapen kívüli Java-futtatási ráfordításnak szintén kell hely, az a szerver pedig, amely terhelés alatt a lapozóterületre fut, a játékosai számára pontosan úgy néz ki, mint egy támadás.

4. Whitelist, szerverjelszó és játékos-felsőhatár a férőhely-kimerítés ellen

A férőhely-kimerítés a legolcsóbb támadás egy közösségi szerver ellen, és nem kér sávszélességet. Aki elegendő egyidejű kapcsolatot épít fel, elfoglalja az összes férőhelyet, és ezzel kizárja a tulajdonképpeni közösséget, anélkül hogy egyetlen gigabitet is megvásárolna. A Hytale ehhez néhány más játékkal ellentétben a megfelelő szerszámokat már a kiszállítási állapotban magával hozza: egy whitelistet a whitelist.json fájlban, egy tiltólistát a bans.json fájlban, jogosultságokat a permissions.json fájlban, és a config.json fájlban a Password és a MaxPlayers kulcsot.

{
  "ServerName": "A Hytale-szerverem",
  "MOTD": "",
  "Password": "olyan érték, amelyet csak az Ön csoportja ismer",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

A Password gyárilag üres, tehát mindenki bejut, akinek címe és portja van. Zárt szerver esetében a beállított jelszó a leghatásosabb egyedi intézkedés a férőhely-kimerítés ellen, nyilvános szerver esetében pedig a whitelist egy támadási hullám idején. És egy dolognak világosnak kell lennie: a szerverjelszó a férőhelyeit védi, nem a vonalát. Az a támadó, aki elárasztja a szerverét, egyáltalán nem akar belépni.

Ezeket a fájlokat csak leállított szerver mellett szerkessze. A futó szerverfolyamat a saját állását a memóriában tartja, és a leállításnál megjegyzés nélkül felülírhatja azokat a módosításokat, amelyeket Ön közben ír a fájlba. A folyó üzemben történő módosításokhoz a szerkesztő helyett a konzolparancsokat használja.

5. Hagyja a hitelesítést az alapértelmezett értéken

Az alapértelmezett mód minden játékostól érvényes Hytale-fiókot követel meg. Ez több egy licencellenőrzésnél: hozzáférési szűrő, amely drágává teszi a masszív fiókgyártást. Az a támadó, aki férőhelyeket akar elfoglalni, ehhez érvényes fiókokat kér, azok pedig pénzbe kerülnek. Ne vegye ki ezt a szűrőt.

A közösségi dokumentáció az alapértelmezés mellett két további módot ír le privát környezetekhez és fejlesztéshez, amelyekkel fiókellenőrzés nélkül lehet belépni. Nyilvános szerver esetében ezek a lehető legrosszabb beállítás, mert a férőhely-kimerítést pénzkérdésből szkriptkérdéssé változtatják. Ha tesztelés céljából átvált, akkor olyan gépen tegye, amely nem áll az interneten, és utána váltson vissza.

6. Korlátozza az új kapcsolódási kísérleteket, mégpedig az 1200 bájtos szabállyal

Most lesz gyakorlati a QUIC strukturális előnye. Egy érvényes kapcsolatfelépítés az RFC 9000 szerint legalább 1200 bájtos datagrammként érkezik. A folyamatos játékforgalom lényegesen kisebb. A kapcsolatkövetéssel ezért meg tudja különböztetni az új adatfolyamokat a fennállóktól, és eldobhat mindent, ami új és túl kicsi. Az nft -f paranccsal betöltött nftables-szabály:

table inet hytale {
    chain input {
        type filter hook input priority -10; policy accept;

        ct state new udp dport 5520 udp length < 1208 drop

        ct state new udp dport 5520 \
            meter hyconn { ip saddr limit rate over 5/second burst 10 packets } drop
    }
}

Az első szabály az UDP-hosszon dolgozik, tehát 8 bájt fejrészen plusz 1200 bájt hasznos terhelésen, együtt 1208-on. Kizárólag azokat a csomagokat találja el, amelyek új adatfolyamot akarnak nyitni, és ehhez túl kicsik, a kapcsolódott játékosokat pedig nem tudja eltalálni. A második szabály azt korlátozza, hány új kapcsolatot nyithat egyetlen forráscím másodpercenként. Az öt másodpercenként nagyvonalú: egy valódi játékos felépít egy kapcsolatot, és megtartja. A -10 prioritás gondoskodik arról, hogy mindkét szabály az UFW szűrőlánca előtt fogjon.

A forráscímenkénti csomagsebesség felső határa magán a játékporton a harmadik értelmes szabály, és itt kifejezetten érvényes: a számérték kezdőérték, nem igazság.

iptables -I INPUT -p udp --dport 5520 \
  -m hashlimit --hashlimit-name hytale_udp --hashlimit-mode srcip \
  --hashlimit-above 800/sec --hashlimit-burst 1200 -j DROP

Mérjen először egy hetet normál üzemben, aztán állítsa a határt a mért csúcsérték kétszeresére. A Hytale-hoz ehhez nincs publikált hivatkozási szám, és az értékek erősen függenek a játékosszámtól és a látótávolságtól. Aki túl szorosan állít, a saját játékosait dobja ki, mégpedig először a legrosszabb vonallal rendelkezőket.

A tisztán iptables-alapú szabályok újraindítás után eltűnnek. Debian és Ubuntu alatt így mentheti ki őket:

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

UFW alatt az ilyen szabályok ezenfelül az /etc/ufw/before.rules fájlba valók, mert különben a következő ufw reload alkalmával eltűnnek. Hogy egy szabályt egyáltalán elér-e a forgalom, azt az iptables -L INPUT -n -v mutatja: ha a találati számlálók nullán maradnak, a szabály nem fog.

7. Állítsa be helyesen a kernel kapcsolatkövetését

Ez a pont olyan kieséseket magyaráz meg, amelyek volumenes támadásnak látszanak, de nem azok. A kernel az UDP-forgalomhoz bejegyzéseket hoz létre a kapcsolatkövetésben, és hamisított feladócímek esetén minden cím új bejegyzést jelent. Ha a tábla tele van, a kernel válogatás nélkül eldobja a csomagokat, a támadás és a játékosai együtt esnek ki, a naplóban pedig ez áll: „nf_conntrack: table full”. Az állást és a felső határt ez mutatja:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

A legtöbb játéknál erre az a legjobb válasz, hogy a játékforgalmat egyáltalán nem követjük. A Hytale-nál ez valódi mérlegelés, mert a 6. lépésből származó 1200 bájtos szabályhoz kell a kapcsolatkövetés. Nélküle a szűrő nem tudja, melyik csomag nyit új adatfolyamot. Az ajánlás ezért így hangzik: a követést megtartani, a táblát növelni, az UDP időtúllépését rövidre venni. Egy /etc/sysctl.d/ alatti ráírás, amelyet a sysctl --system aktivál:

net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Aki a követést mégis ki akarja kapcsolni, például egy nagyon sok egyidejű játékossal működő gépen, az udp dport 5520 notrack szabályt állítja be a raw táblában, és ezzel lemond az 1200 bájtos szabályról. A kettő együtt nem megy. Egyetlen Hytale-szerver esetében a szabály többet ér a megkímélt táblabejegyzéseknél.

Ha a csomagok gyorsabban érkeznek, mint ahogy a Java-folyamat elhozza őket, ezenfelül a fogadópuffer is túlcsordul. A játékosok számára ez csomagvesztésnek látszik, pedig a vonal szabad. Hogy a fenti pufferbeállítások szükségesek-e, azt a kernel maga mondja meg: ha az UdpRcvbufErrors értéke az nstat -az kimenetében emelkedik, akkor fognak. Ha a számláló nullán marad, a kiigazítás semmit nem változtat.

8. Válassza a látótávolságot és a játékosszámot a vonalhoz illően

Ez a lépés nem biztonsági intézkedés, de arról dönt, mennyi támadást bír el egyáltalán. A Hypixel Studios a 2025. december 1-i hivatalos hardverkövetelményekben világosan megfogalmazta: ha megduplázza a látótávolságot, megnégyszerezi a játékos körüli világ mennyiségét. A hivatalos ajánlás legfeljebb 12 chunknál, tehát 384 blokknál van, a MaxViewRadius értékkel beállítva. A kliensoldalon ugyanezek a követelmények játékosonként 2 Mbit/s-ot nevezik meg minimumként és 8 Mbit/s-ot ajánlásként a többjátékos módhoz.

Számolja ki ezt egyszer a szerverére. Egy 40 játékossal működő, nagyvonalú látótávolságú szerver normál üzemben alacsony háromjegyű megabit-tartományt mozgat. Ez az az érték, amelyhez a vonalának mérnie kell magát, és egyben az az érték, amelyet egy támadásnak meg kell haladnia ahhoz, hogy feltűnjön. Aki egy 1 Gbit/s-os vonalat normál üzemben egyharmadáig megtölt, kevesebb tartalékkal rendelkezik, mint az, aki öt százaléknál áll. A kisebb látótávolság ezért nemcsak teljesítménykérdés, hanem a robusztusság kérdése is.

9. Tartsa szemmel a modokat, a plugineket és a protokollváltásokat

A Hytale szerveroldalon moddolható: a modok .zip vagy .jar fájlként a mods/ könyvtárban állnak, a pluginek pedig közvetlenül a szerverinterfészt szólítják meg. Ez kényelmes, mert a játékosoknak semmit nem kell telepítenie, és egyben olyan elérhetőségi kockázat, amelynek semmi köze a támadásokhoz. Az a plugin, amely hálózati eseményenként drágán dolgozik, erősítő a saját házában.

Ehhez jön a protokollváltás. A 6. frissítéssel a hálózati protokoll a 2026. augusztus 27-i hivatalos patch notes szerint hytale/2-ről hytale/3-ra változott, és a szervereket, valamint a plugineket újra kell építeni, mielőtt kapcsolódnak. Az elérhetőség számára ez azt jelenti: vezessen listát a modjairól a verzióval együtt, minden frissítés előtt ellenőrizze őket egy második példányon, és 2026. október 12. előtt tervezzen be egy karbantartási ablakot. Az a szerver, amely egy frissítés után nem indul el, a játékosai számára nem különböztethető meg egy támadástól.

10. Gyűjtsön mérési értékeket, mielőtt komolyra fordul

A legfontosabb lépés az, amelyet előre szinte senki nem tesz meg: összehasonlítási alapot felvenni, amíg minden normálisan fut. Normálérték nélkül egy rendellenesség 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 fut. Egy rendellenesség közben öt parancs elég:

sar -n DEV 1 10
ip -s link show eth0
conntrack -C
nstat -az | grep -i -E 'udp|drop'
tcpdump -ni eth0 -c 200 "udp port 5520"

A tcpdump esetében érvényes: mindig a -c paraméterrel korlátozni, mert a teljes terhelés alatti forgalomrögzítés ezenfelül terheli az egyébként is túlterhelt szervert. Mivel a Hytale-szerver Javán fut, egy második próbára is szüksége van, amely kizárja a leggyakoribb tévedést. A szemétgyűjtés szünete a játékosok számára pontosan úgy néz ki, mint egy támadás: mindenki egyszerre áll, utána megy tovább. A különbség a számokban áll.

jcmd $(pgrep -f HytaleServer.jar) GC.heap_info
tail -n 200 logs/latest.log

A kiértékelés egyszerű. Ha a bejövő csomagok messze a normálérték fölé emelkednek, miközben a Java-folyamat alig dolgozik, akkor támadás. Ha a csomagsebesség feltűnésmentes marad, miközben a heap megtelik vagy a napló hosszú szüneteket mutat, akkor terhelés. Hogy a hálózati értékeket részleteiben hogyan értékelje ki, az a DDoS-támadás felismerése a szerveren című cikkben áll.

11. Backup, visszaállási terv és egy próbafutás a nagy dátum előtt

Az a védelmi koncepció, amelyet soha nem teszteltek, feltételezés. Egy 2026. október 12-hez hasonló dátum előtt négy dolgot kell elvégezni: a universe/ könyvtár és a config.json mentését a gépen kívülre, egy ellenőrzött visszatérést az előző szerververzióra, egy második példányt, amelyre a frissítést először játssza fel, és egy egyszeri terheléses tesztet, amely kiváltja a saját szűrőszabályait.

A terheléses teszt az a pont, ahol a legtöbb üzemeltető megáll, és ez a legfontosabb. Ne azt ellenőrizze, hogy a szabályai elhárítják-e a támadásokat, hanem azt, hogy átengedik-e a saját játékosait. Ehhez elég a találati számlálókat figyelni, miközben húsz valódi játékos egyszerre belép. Ha az eldobási szabályok számlálói közben emelkednek, a határa túl szorosan van beállítva, és a frissítés napján, a legrosszabb körülmények között értesült volna róla.

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 tud megoldani. Az összes 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. Eldobhatja, de nem tudja elküldetlenné tenni.

Számoljon egyszer velünk. Egy jellemző játékszerver 1 Gbit/s-on lóg, ez másodpercenként 125 megabájtnak felel meg, és a vonal tele van, amint valaki többet küld. A játékszerver-projektek ellen irányuló támadások szokásosan 5 és 50 Gbit/s között vannak, tehát a vonalának öt- és ötvenszerese között. Hogy az emögött álló nftables-szabálya jó-e, akkor már nem játszik szerepet, mert a játékosai csomagjai már korábban sem jutnak át.

A második mennyiség a csomagsebesség, és ez gyakran korábban csap le, mint a sávszélesség. A 64 bájtos kis csomagokból egy 1 Gbit/s-os vonalba nagyjából 1,49 millió fér másodpercenként. Egy szokásos szerverkernel processzortól és hálózati kártyától függően néhány százezret dolgoz fel ebből, mielőtt eldobni kezd. Az a támadás, amely a vonalát még egyharmadáig sem tölti meg, tehát mégis le tudja fektetni a szerverét, mert az eldobásra megy el a processzoridő. Az üzemeltetők ezt úgy élik meg, hogy „a kihasználtság nem is volt magas, mégis minden elszállt”.

A Hytale-nál egy harmadik mennyiség is jön, amely a legtöbb játéknál nincs: a kapcsolatfelépítés processzorideje. Érvényes kapcsolódási kísérletek áradata egy botnetből nem tölt meg vonalat és nem hoz létre feltűnő csomagsebességet, hanem kriptográfiával foglalja el a processzort. Az ilyen támadások a sávszélesség-statisztikában láthatatlanok, a Java-folyamat processzorterhelésében pedig jól láthatók, és sem a forráscímenkénti sebességkorlátozás, sem egy nagyobb fogadópuffer nem segít ellenük, ha a források elég nagy számban vannak.

Hogy elhelyezzük, milyen nagyságrendek fordulnak elő valóban: KernelHost-szervereken többek között egy több mint 473,4 Gbit/s-os, másodpercenként több mint 41,5 millió csomagot kitevő támadást egy hangszerver ellen, valamint egy több mint 112,2 Gbit/s-os UDP-floodot egy játékszerver ellen szűrt ki a rendszer. 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 Hytale-szerverek ellen irányuló DDoS-támadásokkal szembe

A folyamatos védelem, amely minden szervercsomagban 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, tehát 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 az eredményt éri el, mint a támadó. Hogy mely címek és protokollok vannak saját védelmi profillal lefedve, azt a Játékszerver-DDoS-védelem valós időben sorolja fel.

Advanced DDoS Protection a tartósan lőtt Hytale-projektekhez

Egyes projekteket nem alkalmanként, hanem célzottan és heteken át támadnak, és egy Early Accessben lévő játék esetében ez különösen azokat a szervereket érinti, amelyek éppen növekednek. 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: Ön határozza meg, mi engedélyezett az 5520 UDP-n, mindentől elkülönítve, és nem kell hozzá ticket.
• 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, például az új kapcsolatokat rövid ideig szorosabban korlátozhatja, a folyamatos játékforgalmat pedig érintetlenül hagyhatja.
• A protokollhoz illő szabályrendszer, az UDP fölötti QUIC-hez ugyanúgy, mint saját alkalmazásokhoz tetszőleges TCP- vagy UDP-portokon.

Az Advanced DDoS Protection a KernelHostnál üzemelő szervereknek szól. Aki a Hytale-projektjét jelenleg máshol üzemelteti és tartósan támadás alatt áll, ehhez a KernelHostra helyezi át, és akkor mindkét réteg a kiszállítástól fog.

A két szint összehasonlítása

A legtöbb Hytale-szervernek 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.

Mi vihető át más játékokból a Hytale-ra

Mivel a Hytale még fiatal, és a Hytale-szerverek ellen irányuló támadásokról nincsenek nyilvános számok, a terhelhető tudáshoz a leggyorsabb út az összehasonlítható játékokra vetett pillantás. Nem a portszám vihető át, hanem a minta.

• A robbanásszerű rajt és amit kivált: a Palworld megmutatja, hogyan fedi egymást időben az új játékosok hulláma és a támadások hulláma, és miért válnak célponttá éppen a növekedő szerverek.
• A lekérdezés és a játékforgalom közötti különbség: a Minecraft Bedrock az Unconnected Pingen keresztül magyarázza el, hogyan működik az erősítés UDP-n. Pontosan ez a támadási út nincs meg a Hytale-nál a QUIC miatt, és ezen érthető meg a legjobban a különbség.
• A kapcsolatfelépítés mint támadási cél: a Minecraft-DDoS-védelem és nullping-védelem kézfogásos áradatokat ír le, amelyek szinte semmilyen sávszélességgel kijönnek. Ez a legközelebbi rokona a QUIC-kapcsolatáradatnak.
• Kis játékosszámok és férőhely-kimerítés: a Project Zomboid és a Conan Exiles megmutatja, milyen kevés ráfordítás kell egy fix csoport kizárásához, és milyen szerepet játszik ebben a whitelist és a jelszó.
• Üzem tartós terhelés alatt: a Terraria megmutatja, hogyan reagál egyetlen, egy magot terhelő szerverfolyamat a támadásokra. A Hytale-szerver egy Java-folyamat, az alapprobléma összehasonlítható.

Gyakori hibák a Hytale-szervereknél és a megoldásuk

„Engedélyeztem az 5520-as TCP-portot, és a játékosok mégsem jutnak be”: A játékforgalom QUIC-en, tehát UDP-n fut. A TCP-engedélyezés a játékforgalomhoz semmit nem hoz. Engedélyezze az 5520 UDP-t, és ellenőrizze kívülről az nmap -Pn -sU -p 5520 paranccsal. Ha a szervert a --bind paraméterrel más portra helyezte, az engedélyezésnek ezt a portot kell megnevezni.

„A szerver fut, de senki nem tud belépni, és a naplóban nincs szó támadásról”: Ellenőrizze a szerver bejelentkezését a fiókján az /auth status paranccsal. Az a szerver, amelynek a bejelentkezése lejárt, fut tovább, a játékosokat mégis elutasítja. Ez nem hálózati probléma és nem szűrőszabály.

„A frissítés után semmi nem indul el”: Ez nem támadás, hanem a protokollváltás. A 6. frissítéssel a hálózati protokoll hytale/2-ről hytale/3-ra változott, a szervereknek és a plugineknek pedig új építésre van szükségük. A frissítéseket először egy második példányon játssza fel, mielőtt az éles szerverre engedi őket.

„Minden játékos egyszerre áll két másodpercig, aztán megy tovább”: Ez nagy valószínűséggel a Java-futtatókörnyezet szemétgyűjtése, és nem támadás. Ellenőrizze a jcmd ... GC.heap_info kimenetét és a szervernaplót. Ha a sar -n DEV 1 10 közben feltűnésmentes marad, nem volt támadás a játékban, hanem túl szűkre mért heap vagy túl nagy látótávolság.

„A kis csomagok elleni szabályom kizárta a játékosokat”: Akkor az 1200 bájtos feltétel ct state new nélkül áll a láncban. A folyamatos játékforgalom túlnyomórészt kis csomagokból áll, és egy állapotellenőrzés nélküli hosszfeltétel pontosan ezeket találja el. A feltétel kizárólag az újonnan nyitott adatfolyamokra érvényes.

„Cseréltem az IP-címet, és két órával később újra offline voltam”: A támadó ugyanabból a forrásból kapta az új címet, mint a régit. A Hytale-nál ez többnyire egy régi A-bejegyzés a DNS-ben, egy állapotkijelzéssel működő Discord-bot vagy egy bejegyzés a harmadik felek számos szerverlistájának egyikében. A 6. frissítés óta a szervercímek a hivatalos szerverlistában gyárilag elrejtve vannak, ami a legkényelmesebb utat lezárja, de nem az összeset. A címváltás időnyereség, nem megoldás.

„A szűrő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 az /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álati számlálók.

„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 Hytale-szervernek pontosan egy nyitott portra van szüksége: 5520 UDP a QUIC-hez. A TCP-re a játékforgalomhoz nincs szükség, és a nyilvános dokumentációban nincs leírva további port lekérdezéshez, RCON-hoz vagy távvezérléshez.
• Mivel a QUIC az RFC 9000 szerint a címellenőrzés előtt legfeljebb a fogadott bájtmennyiség háromszorosát küldheti, és egy első kapcsolódási kísérletnek legalább 1200 bájtosnak kell lennie, egy Hytale-szerver reflexiós erősítőként gyakorlatilag érdektelen. Ez különbözteti meg a Steam-lekérdezéssel vagy Bedrock-Unconnected-Pinggel működő szerverektől.
• Ugyanez az 1200 bájtos szabály a legjobb helyi szűrőszabály: ami új adatfolyamot akar nyitni az 5520 UDP-n és ennél kisebb, nem lehet érvényes kapcsolatfelépítés, és eldobható anélkül, hogy a kapcsolódott játékosokat eltalálná.
• Egy QUIC-felépítés drága része a kriptográfia, nem a sávszélesség. Érvényes kapcsolódási kísérletek áradata a sávszélesség-statisztikában láthatatlan, és csak a processzorterhelésben, valamint az új kapcsolatok számlálóiban látható.
• A fiókkötelezettséggel működő alapértelmezett mód hozzáférési szűrő, amely drágává teszi a masszív fiókgyártást. Nyilvános szerveren érintetlen marad, ehhez jön a whitelist.json, a bans.json és egy beállított érték a Password kulcsban a férőhely-kimerítés ellen.
• A helyi intézkedések a vonalnál érnek véget: 1 Gbit/s másodpercenként 125 megabájt, és 64 bájtos csomagok mellett nagyjából 1,49 millió csomag fér oda másodpercenként. Minden e fölöttinek a szerver előtti hálózatban kell véget érnie.
• A Hytale 2026. január 13-a óta van Early Accessben, a Chapter 1 pedig 2026. október 12-re van bejelentve. A nagy dátumok támadási dátumok, és az a védelem, amelyet a dátumon rendelnek meg, túl későn jön.
• A KernelHostnál a kétrétegű folyamatos védelem minden szervercsomagban felár nélkül benne van és a kiszállítástól aktív, null-routing nélkül. A dedikált védett IP-vel és önállóan kezelhető, portonkénti szabályokkal működő Advanced DDoS Protection havi 50,00 EUR-tól indul.

Ha a Hytale-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 egy support-ticketet, 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.

Ez a cikk a 2026. szeptember 27-i állást tükrözi. A Hytale Early Accessben van, és a hálózati protokoll ebben az évben már egyszer megváltozott. A cikket a Chapter 1 után és minden olyan frissítés után továbbírjuk, amely a kapcsolatfelépítést, a portokat vagy a szerverlistát érinti.