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

Az a Palworld-szerver, amely este játék közben egyszerre dobja ki az összes játékost, néhány percre elérhetetlenné válik, majd magától újra elérhető lesz, ritkán küzd hardverproblémával. Rendszerint támadás zajlik ellene. Ez a cikk megmutatja, hogyan védheti meg a Palworld-szervert a DDoS-támadásoktól: először azt, amit többletköltség nélkül saját maga is beállíthat, utána azt a pontot, ahol ezek az intézkedések technikailag véget érnek, végül pedig azt, aminek a szerver előtti hálózatban kell történnie ahhoz, hogy a szerver elérhető maradjon.

Minden adat a Pocketpair hivatalos dedikált szerverére vonatkozik (Steam-alkalmazásazonosító 2394010) Debian 12, Debian 13, Ubuntu 22.04 LTS vagy Ubuntu 24.04 LTS alatt. A parancsok root felhasználóra készültek, normál felhasználóként tegye eléjük a sudo parancsot. Ha a támadás éppen zajlik, egy sorrend érvényes: előbb mérés, utána változtatás. A terhelés alatti kemény újraindítás eldob mindent, ami az utolsó automatikus mentési pont óta történt a világban, és az eset mérési adatai is elvesznek vele.

Miért bénítják meg célzottan DDoS-támadásokkal a Palworld-szervereket

Egy Palworld-szerver kicsi, állandó közönséget jelent egy állandó címen. A dedikált szerver 32 játékosra van korlátozva, ezt a ServerPlayerMaxNum vezérli, amelynek érvényes tartománya 1 és 32 között van. Aki ehelyett a játék menüjéből házigazdaként indít világot, négy játékosig jut, és csak addig, amíg ő maga online van. Ebből a 32 férőhelyből következik minden további: a csapat fix esti időpontokban játszik, a tagjai ismerik egymást, és egy este nyolckori kiesés nem a játékosok töredékét éri, hanem mindenkit.

A szerver címe eközben nem titok. A Palworld nem ismer szolgáltatói közvetítést: a játékosok maguk írják be az IP-címet és a portot a közvetlen csatlakozás mezőjébe, aki pedig a szerverét a közösségi szerverlistában is szerepeltetni szeretné, a -publiclobby kapcsolóval indítja, és válaszoltatja a lekérdezési portot. Így mindenki ismeri a célpontot, aki valaha csatlakozott. Egy booter-szolgáltatás, amely ezt a címet havi néhány euróért lövi, a megrendelőjétől sem tudást, sem ráfordítást nem igényel.

Ehhez jön, hogy a teljes játékforgalom UDP-n keresztül megy. Az UDP nem ismer olyan kapcsolatfelépítést, amelyet meg lehetne követelni, és egy UDP-csomag feladói címe hamisítható. A támadónak tehát sem belépnie nem kell a szerverre, sem szabályosan megszólítania ahhoz, hogy terhelést okozzon. Hogy egy ilyen támadás során technikailag mi történik, azt a Mi az a DDoS-támadás? című cikk magyarázza el.

Azok a portok, amelyekről egy Palworld-szervernél valójában szó van

Egy Palworld-szervernek pontosan egy nyitott portra van szüksége: 8211 UDP. Minden más opcionális, sőt feladattól függően kifejezetten káros, ha kint áll az interneten. Ebből egy hasznos megkülönböztetés következik: a 8211-es port elleni DDoS-támadás mindig magát a játékforgalmat éri, a 27015 UDP elleni támadás ezzel szemben csak a szerverlistában szereplő bejegyzést.

Az összes ide tartozó kapcsoló egyetlen fájlban áll: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini, Windows alatt ennek megfelelően Pal\Saved\Config\WindowsServer\PalWorldSettings.ini. A fájl a [/Script/Pal.PalGameWorldSettings] szakaszsorral kezdődik, utána egyetlen OptionSettings=(...) sor következik, amely az összes beállítást listaként tartalmazza. A zárójelen belüli sortörés az egész konfigurációt érvénytelenné teszi, és a szerver megjegyzés nélkül visszaáll az alapértékekre. A szerverkönyvtárban lévő DefaultPalWorldSettings.ini mintafájlt nem szerkeszti, mert azt minden frissítés felülírja.

A Palworld-szerver számokban

Az alábbi értékek minden szűrőszabályról és határértékről szóló döntés alapját adják.

Miért a 27015-ös lekérdezési port a legérzékenyebb pont

A lekérdezési port Steam-formátumú (A2S) állapotkérdésekre válaszol, vagyis ugyanarra a lekérdezésre, amelyet a Counter-Strike- és az ARK-szerverek is kiszolgálnak. Egy A2S_INFO-kérés néhány tucat bájtos, kapcsolat nélküli UDP-csomag, a szervernevet, a világot, a játékosszámot és az állást tartalmazó válasz ennek a többszöröse. Mivel UDP esetén a feladói cím hamisítható, a támadó idegen lekérdezési portokat szólíthat meg, és a nagyobb válaszokat a tényleges célpontjára terelheti. Ilyenkor az ön szervere nem az áldozat, hanem az erősítő, és a számlát az ő hálózati kapcsolata fizeti.

A Valve ezért 2020. december 8-án egy előzetes ellenőrzéssel (challenge) egészítette ki az A2S_INFO-t: a szerver először S2C_CHALLENGE üzenettel válaszol, a kérdezőnek vissza kell küldenie a tokent, és ezzel bizonyítja, hogy nem hamisítja a feladói címét. Ez enyhíti az erősítést, de nem szünteti meg, és a valódi címekről érkező, egyforma lekérdezések puszta áradata ellen egyáltalán nem hat.

A Palworld számára ebből fontos előny származik a Source motorhoz képest: a játékforgalom és a szerverlekérdezés külön portokon fut. A Counter-Strike 2-ben mindkettő a 27015-ös porton osztozik, ott egy durva sebességkorlát a saját játékosokat is kidobja. A Palworldnél a 27015 UDP keményen korlátozható vagy teljesen lezárható anélkül, hogy a 8211 UDP-n futó játékforgalom egyetlen csomagját is érintené. Akinek nincs szüksége a listabejegyzésre, elhagyja a -publiclobby kapcsolót és a lekérdezési portot, és ezzel egy teljes támadási felületet vesz ki a hálózatból.

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

Az alábbi lépések egyetlen volumetrikus támadást sem állítanak meg, ezt a szerveren futó szoftver nem tudja megoldani. Mindent leszednek viszont, ami ez alatt van: a portszkennelést, a lekérdezési áradatokat, az adminisztrációs portokon keresztüli átvételi kísérleteket és mind a 32 férőhely idegenek általi elfoglalását. Ez a nagyobbik része annak, ami egy Palworld-szervert a hétköznapokban zavar, és fél órába kerül.

1. Leltár: mi figyel a szerveren?

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

ss -lntup

Az érdekes oszlop a helyi címé. A 0.0.0.0:8211 azt jelenti, hogy „az egész internetről elérhető", a 127.0.0.1:8212 azt, hogy „csak helyben", és ehhez nem kell tűzfalszabály. A játékfolyamat mellett egy hosszabb ideje működő szerveren gyakran feltűnik még egy adminisztrációs panel, egy webszerver a térkép megjelenítéséhez és egy adatbázis is. A támadó nézőpontját egy kívülről indított portszkennelés adja:

nmap -Pn -sU -p 8211,27015 A.SZERVER.IP.CIME
nmap -Pn -p- --min-rate 1000 A.SZERVER.IP.CIME

2. Csak azt nyissa meg, amire a Palworldnek valóban szüksége van

Két engedélyezés elég, és a második opcionális. 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 8211/udp comment 'Palworld játékforgalom'
ufw allow 27015/udp comment 'Palworld Steam-lekérdezés'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

A harmadik sort hagyja ki, ha a szervere nem akar szerepelni a közösségi szerverlistában. A játékosai ekkor is csatlakoznak az IP-cím és a 8211-es port megadásával, a szerver csupán a nyilvános listából tűnik el. A teljes útmutató a menekülőúttal együtt itt olvasható: UFW-tűzfal beállítása anélkül, hogy kizárná magát.

3. A 25575-ös RCON-port és a 8212-es REST API kivétele az internetről

Mindkét port teljes felügyeletet adó adminisztrációs hozzáférés, és mindkettő gyárilag ki van kapcsolva: RCONEnabled=False és RESTAPIEnabled=False. Aki bekapcsolja őket, tudja, mit tesz közzé.

A 8212 TCP-n futó REST API HTTP Basic Auth segítségével hitelesít a rögzített admin felhasználónévvel és az AdminPassword értékével, méghozzá titkosítatlan HTTP felett. Az adminisztrációs jelszó így minden egyes kérésnél visszafejthető formában halad át a vonalon. A 25575 TCP-n futó RCON ugyanilyen titkosítatlan szöveges protokoll, és a Pocketpair a REST API javára elavultnak jelölte. Új telepítéseknél a REST API a helyes választás, mindkettőre ugyanaz a szabály érvényes: nem való a nyílt hálózatba.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="egy hosszú véletlenszerű érték"

A felületet SSH-porttovábbítással teszi elérhetővé, utána helyben dolgozik a 127.0.0.1:8212 címmel szemben:

ssh -N -L 8212:127.0.0.1:8212 root@A.SZERVER.IP.CIME

Az AdminPassword értékét soha ne hagyja üresen, mert az üres az alapértelmezés. Egy openssl rand -base64 32 parancsból származó érték elegendő. Ugyanez érvényes a ServerPassword beállításra, erről mindjárt bővebben.

4. A 27015-ös lekérdezési port korlátozása a listabejegyzés elvesztése nélkül

A kapcsolat nélküli Steam-csomagok négy beállított bájttal kezdődnek (0xffffffff), a szabályos játékforgalomnak nincs ilyen fejléce. Erre forráscímenkénti sebességkorlát tehető, amely fékezi a lekérdezéseket, és megőrzi a listabejegyzést. nftables-szel, nft -f paranccsal betöltve:

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

A -10 prioritás gondoskodik arról, hogy a szabály az UFW szűrőlánca előtt fogjon, a @th,64,32 pedig az UDP-fejléc mögötti első négy bájtot olvassa ki. Klasszikus iptables-szel ugyanezt a szétválasztást az A2S_INFO azonosítójára történő illesztés éri el:

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Másodpercenként és címenként tíz lekérdezés bőkezűen mért érték: egy listaszolgáltatás jellemzően néhány percenként kérdez, nem másodpercenként többször. Csak az a fontos, hogy ez a szabály a 27015-ösön álljon, és ne a 8211-esen, különben a saját játékosait találja el.

5. A csomagráta korlátozása a 8211 UDP-n

Magán a játékporton a forráscímenkénti felső korlát a kevés forrásból érkező kis áradatok ellen segít. A Palworldnél ezt a korlátot viszonylag veszélytelen beállítani, mert legfeljebb 32 játékos csatlakozik egyszerre, és mindegyikük pontosan egy forráscímet foglal el:

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

A szám kiindulási érték, nem végső igazság. Egy 32 játékossal és sok bázissal teli szerver jóval több csomagot állít elő, mint egy négyfős kör, és aki túl szűkre állítja, a saját játékosait dobja ki. Előbb mérjen egy hetet normál üzemben, utána állítsa a korlátot a mért csúcsérték kétszeresére.

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

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

UFW alatt az ilyen szabályok ezen felül a /etc/ufw/before.rules fájlba valók, mert különben a következő ufw reload parancsnál eltűnnek. Hogy egy szabályhoz egyáltalán eljut-e a forgalom, azt az iptables -L INPUT -n -v mutatja meg: ha a találatszámlálók nullán maradnak, a szabály nem fog.

6. Szerverjelszó, tiltólista és a 32 férőhely a slotkimerítés ellen

A slotkimerítés, vagyis az összes férőhely lefoglalása, a legolcsóbb támadás egy Palworld-szerver ellen, és nem igényel sávszélességet. Egy dedikált szervernek legfeljebb 32 férőhelye van, tehát 32 egyidejű kapcsolat elég az egész közösség kizárásához. Egy volumetrikus támadás pénzébe kerül a megrendelőnek, 32 munkamenet semmibe. Ez teszi ezt az utat kis szervereknél vonzóbbá minden áradatnál.

A Palworldnek nincs beépített engedélylistája. A moderációs eszközök a kirúgás, a kitiltás és a szerverjelszó, és pontosan a szerverjelszó a leghatásosabb egyedi intézkedés a slotkimerítés ellen:

ServerPassword="egy érték, amelyet csak az ön csapata ismer"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

A ServerPassword gyárilag üres, vagyis IP-címmel és porttal bárki bejut. A BanListURL alapértelmezés szerint a Pocketpair által karbantartott listára mutat, és átirányítható saját szövegfájlra, ha projektspecifikus tiltásokat szeretne vezetni. A ServerPlayerMaxNum értékét ne állítsa 32 fölé: a magasabb értékek nem támogatottak, és legkésőbb a következő frissítésnél visszaütnek. É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, nem is akar csatlakozni.

7. A kapcsolatkövetés tehermentesítése és a pufferek növelése

Ez a pont olyan kieséseket magyaráz meg, amelyek volumetrikus támadásnak látszanak, de nem azok. A kernel az UDP-forgalomhoz bejegyzéseket hoz létre a kapcsolatkövetésben (conntrack), és hamisított feladói címeknél minden cím új bejegyzést jelent. Ha a tábla megtelik, a kernel válogatás nélkül eldobja a csomagokat, a támadás és a játékosai együtt repülnek ki, a naplóban pedig ez áll: „nf_conntrack: table full". Az állást és a felső korlátot ez mutatja meg:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

A leghatásosabb lépés az, ha a játékforgalmat egyáltalán nem követteti, hiszen a Palworld maga kezeli a munkameneteit:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

Az iptables megfelelője az iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK, valamint ugyanez a sor az OUTPUT lánchoz a --sport kapcsolóval. A portoknak ezután kifejezett engedélyezés kell, mert követés nélkül egyetlen olyan szabály sem fog, amely meglévő állapotot vizsgál. Ha a csomagok gyorsabban érkeznek, mint ahogy a szerverfolyamat elveszi őket, ezen felül a fogadópuffer is túlcsordul. A játékosok számára ez csomagvesztésnek látszik, pedig a vonal szabad. Egy /etc/sysctl.d/ alá helyezett kiegészítés, sysctl -p paranccsal aktiválva:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Hogy szükség van-e ezekre az értékekre, azt maga a kernel árulja el: ha az nstat -az kimenetében nő az UdpRcvbufErrors, akkor fognak. Ha a számláló nullán marad, a módosítás nem változtat semmin.

8. Mérési adatok gyűjtése, mielőtt komolyra fordul

A legfontosabb lépés az, amit előre szinte senki nem tesz meg: összehasonlítási alapot felvenni, amíg minden normálisan működik. Normálérték nélkül egy eset után nem tudja megmondani, hogy a másodpercenkénti 40 000 csomag sok volt-e, vagy csak szombat este. Az apt-get install -y vnstat sysstat paranccsal a mérés tartósan fut. Egy eset alatt négy parancs elegendő:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 -c 200 "udp port 8211 or udp port 27015"

A tcpdump esetében érvényes: mindig korlátozza a -c kapcsolóval, mert a teljes terhelés alatti rögzítés egy amúgy is túlterhelt szervert tovább terhel. A Palworld ezen felül olyan mérőszámot ad, amilyen egyetlen más eszközben sincs. Ha a REST API aktív, a metrikavégpont többek között a szerver képkockasebességét, az aktuális játékosszámot és a futásidőt adja vissza:

curl -s -u admin:AZ_ADMIN_JELSZAVA http://127.0.0.1:8212/v1/api/metrics

Ez az egyetlen szám tisztán elválasztja egymástól a két leggyakoribb okot. Ha a szerver képkockasebessége beszakad, miközben a csomagráták feltűnésmentesek maradnak, akkor nem támadásról van szó, hanem terhelésről vagy a szerverfolyamat ismert memórianövekedéséről. Ha a képkockasebesség stabil marad, miközben a bejövő csomagok messze a normálérték fölé emelkednek, akkor támadás zajlik. Hogy a hálózati értékeket részleteiben hogyan értékelje ki, arról a DDoS-támadás felismerése a szerveren című cikk szól.

Ahol ezek az intézkedések véget érnek: sávszélesség és csomagráta

Most az a rész következik, amelyet egyetlen konfigurációs fájl sem old meg. Az eddigi intézkedések mind az ön szerverén futnak, 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 meg nem történtté nem teheti.

Számoljunk egyszer. Egy jellemző játékszerver 1 Gbit/s sávszélességű vonalon lóg, ez másodpercenként 125 megabájtnak felel meg, és a vonal megtelik, amint valaki többet küld. A játékszerver-projektek elleni támadások szokásosan 5 és 50 Gbit/s között mozognak, tehát a vonala ötszöröse és ötvenszerese között. Hogy az iptables-szabálya mögötte jó-e, akkor már nem számít, mert a játékosai csomagjai már korábban nem jutnak át.

A második mennyiség a csomagráta, és ez gyakran hamarabb üt be, mint a sávszélesség. 64 bájtos kis csomagoknál egy 1 Gbit/s sávszélességű vonalba körülbelül 1,49 millió csomag fér másodpercenként. Egy normál szerverkernel a processzortól és a hálózati kártyától függően ennek néhány százezres részét dolgozza fel, mielőtt eldobásba kezdene. Az a támadás tehát, 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ő az eldobásra megy el. Az üzemeltetők ezt így élik meg: „a kihasználtság nem is volt magas, mégis minden elszállt", a Palworldnél pedig először lagcsúcsok formájában jelentkezik, és csak utána kapcsolatbontásként.

Egy Palworld-szervernél ehhez kedvezőtlen arány társul. Egy 32 játékossal teljesen feltöltött szerver egy 1 Gbit/s sávszélességű vonalnak csak a töredékét terheli. A támadásnak tehát nem kell nagynak lennie ahhoz, hogy a normál üzem többszörösét elérje, és pontosan ezért itt már olyan támadások is elegendőek, amelyek egy nagy platformon fel sem tűnnének.

Hogy milyen nagyságrendek fordulnak elő a valóságban: KernelHost-szervereken többek között egy 473,4 Gbit/s fölötti, másodpercenként több mint 41,5 millió csomagos támadást szűrtek ki egy hangszerver ellen, valamint egy 112,2 Gbit/s fölötti 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.

Amit a KernelHost állít ezzel szembe

A folyamatos védelem, amely minden szervercsomagban benne van

A KernelHost DDoS-védelme kétlépcsős felépítésű és tartósan aktív, anélkül hogy bármit be kellene kapcsolnia, meg kellene rendelnie vagy be kellene állítania:

• 1. lépcső: 17 Tbps mitigációs kapacitás a globális scrubbing-hálózatban. A volumetrikus támadásokat a forrásukhoz közel tisztítják meg, mielőtt elérnék az adatközpontot.
• 2. lépcső: 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ázatokat, 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, amelyek alatt a szerver eltűnik. És nem alkalmaznak nullroutingot: 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 Palworld a saját védelmi profillal rendelkező játékok közé tartozik, hogy mely további címek és protokollok vannak lefedve, azt a Valós idejű DDoS-védelem játékszervereknek című cikk sorolja fel.

Advanced DDoS Protection a tartósan lőtt Palworld-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, minimális futamidő és beállítási díj nélkül. A különbség nem a nagyobb kapacitásban van, hanem az irányításban:

• Dedikált védett IP-cím a frankfurti magból, amelyre a szerverét a saját hálózaton belül átállítják. Az ön oldalán nincs szükség átalakításra.
• Portonként és protokollonként saját kezűleg kezelhető védelmi szabályok az ügyfélterületen: külön határozza meg, mi engedélyezett a 8211 UDP-n, és mi a 27015 UDP-n, anélkül hogy ehhez jegyet kellene írnia.
• A módosítások valós időben fognak, tehát futó támadás közben is utánaállíthat, például átmenetileg keményebben korlátozhatja a lekérdezési portot, a játékportot pedig érintetlenül hagyhatja.
• A játékhoz illő védelmi profil, a Palworldhöz ugyanúgy, mint a tetszőleges TCP- vagy UDP-portokon futó saját alkalmazásokhoz.

Az Advanced DDoS Protection a KernelHostnál elhelyezett szerverekre vonatkozik. Aki a Palworld-projektjét jelenleg máshol üzemelteti, és tartósan támadják, ehhez átköltözteti a KernelHosthoz, és akkor mindkét lépcső a kiépítéstől kezdve véd.

A két lépcső összehasonlítása

A legtöbb Palworld-szerverhez elegendő a csomagban foglalt folyamatos védelem egy tiszta 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 Palworld-szervereknél és megoldásuk

„Letiltottam a 27015-öst, és most eltűnt a szerver a közösségi listából": Ez a várt viselkedés, mert a listabejegyzést a lekérdezési port hordozza. Ne tiltsa le teljesen, hanem korlátozza a kapcsolat nélküli csomagokat forráscímenként a 4. lépésben leírt módon. Ha a listabejegyzésre amúgy sincs szüksége, hagyja a portot zárva, törölje a -publiclobby kapcsolót, és adja meg a játékosainak az IP-címet és a 8211-es portot a közvetlen csatlakozáshoz.

„Lecseréltem az IP-címet, és két órával később megint elérhetetlen voltam": A támadó ugyanabból a forrásból szerezte meg az új címet, mint a régit. A Palworldnél ez majdnem mindig három út egyike: egy játékos, akinek a cím amúgy is ott áll a közvetlen csatlakozás mezőjében, egy állapotot kijelző Discord-bot, amely újra közzéteszi, vagy egy régi A rekord a DNS-ben, amely az előző címre mutat. A címcsere időnyerés, nem megoldás.

„A szerveren lagcsúcsok vannak, de a vonal nyugodt": Ez a Palworldnél gyakrabban terhelés, mint támadás. A szerverfolyamat a futásideje alatt folyamatosan egyre több memóriát foglal, ezért a tervezett újraindítás a normál üzem része, és nem szükségmegoldásként kell értelmezni. Ellenőrizze a szerver képkockasebességét a metrikavégponton és a folyamat memóriahasználatát. Ha eközben a sar -n DEV 1 10 feltűnésmentes marad, akkor nem DDoS-támadás történt.

„Mind a 32 férőhely foglalt, de a játékban senki nem látszik": Ez slotkimerítés, és a játéklogikát éri, nem a vonalat. Állítson be ServerPassword értéket, tiltsa ki a feltűnő fiókokat a tiltólistán keresztül, és korlátozza a forráscímenkénti csomagszámot a 8211 UDP-n.

„A REST API pár napig kívülről elérhető volt": Akkor az adminisztrációs jelszava kompromittálódott, mert a HTTP Basic Auth titkosítatlan HTTP felett minden kérésnél visszafejthető formában továbbítja. Változtassa meg az AdminPassword értékét, zárja le kifelé a 8212 TCP-t, és a felületet ezután már csak SSH-porttovábbítással érje el.

„Az iptables-szabályaim nem fognak": Három ok gyakori. A szabályok az UFW láncai mögött állnak, és a forgalom soha nem jut el hozzájuk; az utolsó újraindítás után eltűntek (ilyenkor a netfilter-persistent save vagy egy bejegyzés a /etc/ufw/before.rules fájlban segít); vagy a támadás volumetrikus, és a szabály helyesen dolgozik egy vonalon, amely már tele van. Ellenőrizze az iptables -L INPUT -n -v paranccsal, hogy nőnek-e a találatszámlálók.

„Az eddigi szolgáltatóm letiltotta az IP-címemet": Ez a nullrouting. 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ákig utána is. Kétség esetén kérdezze meg, hogy szűrnek vagy nullroutingot alkalmaznak. 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űrik, a szerverre a várakozásnak megfelelően nem érkezik semmi. Működő szűrés mellett ez a normális eset. Fordítva is igaz: ha a vonal telített, adott esetben már az az SSH-munkamenet sem ér el önhöz, amellyel mérni akart. Ilyenkor használja az ügyfélterületen lévő VNC-konzolt, amely a vendégrendszer hálózatától függetlenül működik.

Röviden összefoglalva

• Egy Palworld-szervernek pontosan egy nyitott portra van szüksége: 8211 UDP. A 27015 UDP lekérdezési port csak a közösségi szerverlistában szereplő bejegyzéshez kell.
• A 25575 TCP-n futó RCON és a 8212 TCP-n futó REST API soha nem való a nyílt hálózatba, mert mindkettő titkosítatlanul továbbítja a hozzáférési adatait. Az RCON-t a Pocketpair ezen felül elavultnak jelölte.
• Mivel a Palworldnél a játékforgalom és a szerverlekérdezés külön portokon fut, a 27015 UDP keményen korlátozható anélkül, hogy a 8211 UDP-n futó játékforgalom sérülne.
• A dedikált szerver 32 férőhelyre korlátozott, ezért a slotkimerítés a legolcsóbb támadás. Ez ellen a beállított ServerPassword a leghatásosabb egyedi intézkedés, mert a Palworldnek nincs beépített engedélylistája.
• A helyi intézkedések a vonalnál érnek véget: 1 Gbit/s másodpercenként 125 megabájt, és 64 bájtos csomagoknál körülbelül 1,49 millió csomag fér bele másodpercenként. Minden, ami efölött van, a szerver előtti hálózatban kell hogy véget érjen.
• A KernelHostnál a kétlépcsős folyamatos védelem minden szervercsomagban felár nélkül benne van, és a kiépítéstől aktív, nullrouting nélkül. Az Advanced DDoS Protection dedikált védett IP-címmel és portonként saját kezűleg kezelhető szabályokkal havi 50,00 EUR-tól indul.

Ha a Palworld-szervere már a KernelHostnál fut, a szűrés aktív, anélkül hogy bármit tennie kellene. Ha ennek ellenére rendellenességet tapasztal, nyisson támogatási jegyet, hogy a szűrőszabályokat az ön IP-címére igazítsuk. Futó támadás esetén emellett a WhatsApp-os vészhelyzeti csevegésen is elér minket a +43 650 8209883 számon.