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

Aki a Terraria-szerverét DDoS-támadások ellen szeretné megvédeni, különleges esettel áll szemben: a Terraria kizárólag TCP-t beszél. A játékforgalom pontosan egy porton, a 7777 TCP porton fut, UDP-portot pedig a játék egyáltalán nem nyit meg. A játékszerverek védelméről a hálózaton keringő tanácsok szinte mindegyike UDP-játékokhoz készült, és itt vagy a levegőbe hat, vagy rossz helyen.

Ez a cikk először azt mutatja meg, mit tud Ön többletköltség nélkül saját maga bebiztosítani, utána azt, hol érnek véget ezek az intézkedések műszakilag, végül azt, minek kell utána a szerver előtti hálózatban történnie. Minden adat egy Terraria dedikált szerverre vonatkozik (vanilla, TShock vagy tModLoader) Debian 12, Debian 13, Ubuntu 22.04 LTS vagy Ubuntu 24.04 LTS alatt. A parancsok root felhasználóra vannak írva, normál felhasználóként tegye eléjük a sudo parancsot. Ha a támadás éppen fut, először ne változtasson semmit a konfiguráción, és ne indítsa újra a szervert: mentse el a mérési értékeket (lásd a „Naplózás” című szakaszt), a támadás után már nem lesznek meg.

Miért éppen a Terraria-szervereket találják el a DDoS-támadások

A Terraria-szerverek kényelmes célpontok, mert a címük szükségszerűen nyilvános. A vanilla Terrariának nincs beépített szerverböngészője: a játékosok a „Multiplayer” és a „Join via IP” menüponton keresztül kapcsolódnak, tehát olyan címen, amelyet valakinek előbb közzé kellett tennie. Aki új játékosokat akar, felveszi a szerverét olyan listaoldalakra, mint a terraria-servers.com, a tserverweb.com vagy a topg.org, vagy Discordon terjeszti a címet. Ezek mindegyike ugyanazt adja a támadónak, amit a játékosnak: az IP-címet és a portot nyílt szövegben.

Ha egy Terraria-szerver folyton offline lesz, miközben a hardveren, a világon és a modlistán semmi nem változott, akkor a támadás a legvalószínűbb magyarázat. Ehhez jön egy projekt tipikus felállása: fix játékidők, konkurens szerverek, kitiltott játékosok és vita a közösségben. Egy támadás a megrendelőnek sem tudást, sem érdemi pénzt nem kerül, egy Terraria server booter havi néhány euróért, előfizetésként kapható. Hogy egy DDoS-támadás műszakilag mi, és hogyan épül fel, azt a Mi az a DDoS-támadás? cikk írja le.

A Terraria TCP-n fut, nem UDP-n

Ez a legfontosabb különbség gyakorlatilag minden más játékszerverhez képest. A Terraria dedikált szervere TCP-figyelővel fogadja a kapcsolatokat (a játékmotorban a Terraria.Net.Sockets.TcpSocket osztállyal), és nem nyit UDP-socketet. Ennek négy következménye van, és ezek határozzák meg az egész védelmét:

• Egy teljesen felépített TCP-kapcsolatot nem lehet hamisítani. A támadónak meg kell kapnia a szerver SYN-ACK csomagját, hogy befejezze a kézfogást. Aki tehát valóban kapcsolódik, az valódi címről jön. Az IP-tiltások és a kapcsolatszám felső korlátai a Terraria esetében ezért lényegesen jobban hatnak, mint egy UDP-játéknál.
• Egy SYN-flood viszont igenis hamisítható, mert soha nem fejezi be a kézfogást. Ez ellen a fajta ellen nem segít IP-tiltás, kizárólag a SYN-cookie-k és az előtte lévő hálózatban végzett szűrés.
• A 7777-es portra elfogadott minden TCP-kapcsolat erőforrást foglal a játékfolyamatban, nem csak a kernelben. Ez teszi a férőhelyek kimerítését a legkisebb sávszélességgel járó leghatásosabb támadássá.
• Egy UDP-flood ennek ellenére eltalálja a szerverét. A csomagokat nem kell elfogadni ahhoz, hogy megtöltsék a vonalát. Az, hogy a Terraria nem beszél UDP-t, nem a vonalat védi, csak azt akadályozza meg, hogy maga a játékfolyamat feldolgozza a csomagokat.

Egy kivétel van: ha a dedikált szervert a -steam és a -lobby friends vagy a -lobby private paraméterrel indítja, a kapcsolat a Steam-hálózaton keresztül fut, tehát a 27000 és 27100 közötti UDP-portokon. Ez másik üzemmód, nem a klasszikus, IP-címen elérhető szerver.

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

Egy Terraria-szervernek pontosan egy portra van szüksége a nyílt hálózaton: 7777 TCP. Minden más ebben a táblázatban vagy egyáltalán nem való az internetre, vagy csak a saját címére.

Az, hogy a Terraria sem lekérdezőportot, sem RCON-t nem ismer, a védelem szempontjából jó hír: az a két végpont, amelyet a Counter-Strike, a Rust vagy az ARK esetében rendszeresen reflexiós támadásokra használnak vissza, itt egyszerűen nem létezik. Ehelyett a támadási felület annál erősebben a 7777-es portra összpontosul, és aki TShockot használ, a 7878-as porttal egy második felületet is hoz magának.

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

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

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

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:7777 azt jelenti, hogy „az egész internetről elérhető”, a 127.0.0.1:7878 azt, hogy „csak helyben”, és nem igényel tűzfalszabályt. Ha ebben a listában UDP-bejegyzés jelenik meg a Terraria-folyamatához, a szerver Steam-üzemmódban fut. A támadó nézőpontját egy kívülről indított portszkennelés adja:

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

2. Csak a 7777 TCP portot hagyja nyitva, minden mást zárjon be

A Terrariához egyetlen kifelé irányuló engedélyezés elég. UDP-szabályra nincs szüksége, és egy 7777-re szóló UDP-szabály egyenesen hibás lenne: olyan portra engedne át forgalmat, amelyen semmi nem figyel. UFW-vel ez így néz ki, méghozzá pontosan ebben a sorrendben, hogy ki ne zárja saját magát:

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/tcp comment 'Terraria'
ufw allow from 203.0.113.10 to any port 7878 proto tcp comment 'TShock REST'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

A 203.0.113.10 helyére írja be a saját címét. 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ó. Aki panelt üzemeltet, a 8080-as és a 2022-es portot is a saját címére korlátozza.

3. serverconfig.txt: a jelszó, a maxplayers és a secure helyes beállítása

A Terraria-szerver központi konfigurációs fájljának neve serverconfig.txt, és indításkor a -config serverconfig.txt paraméterrel adják át. Négy direktíva döntő a védelem szempontjából:

port=7777
maxplayers=16
password=EgyHosszuVeletlenJelszo
secure=1
upnp=0
banlist=banlist.txt

A password= a leghatásosabb ingyenes intézkedés azok ellen a belépési áradatok ellen, amelyek a szabályos utat használják. Az ok a protokollban van: a kliens először az 1-es üzenetet küldi a verzióazonosítójával (például Terraria279), a szerver beállított jelszó esetén a 37-es üzenettel válaszol, a kliensnek a 38-as üzenettel helyesen kell válaszolnia, és a szerver csak ezután küldi el a 3-as üzenettel az engedélyt a játékoshellyel együtt. A helyes jelszó nélkül tehát a támadó soha nem jut el a világ átviteléig, ami egy belépés drága része.

A maxplayers 1 és 255 közötti értékeket vesz fel, az alapértelmezés 16 (az 1.4.0.1 verzió előtt 8 volt). A 255-ös felső korlát nem önkényes szám: a Terraria egyetlen bájttal címzi meg a játékosokat. Ne állítsa a maxplayers értékét magasabbra, mint amennyire valóban szüksége van, mert minden férőhely olyan erőforrás, amelyet egy támadó elfoglalhat. A secure=1 bekapcsolja a beépített csalásellenőrzést (a parancssorban -secure), az upnp=0 pedig megakadályozza, hogy a szerver saját kezdeményezésből portokat nyisson egy routeren.

4. A TShock bebiztosítása: REST-API a 7878-on és bejelentkezési flood

A TShock a legelterjedtebb szerverkiegészítés a Terrariához, és a REST-API-val egy második, teljes értékű támadási felületet hoz magával. Alapértelmezés szerint a 7878 TCP porton ül, és a tshock/config.json fájlban van konfigurálva, tehát nem a serverconfig.txt fájlban. Gyári állapotban ki van kapcsolva ("RestApiEnabled": false), és pontosan így is kellene maradnia, amíg nincs rá szüksége.

Ha szüksége van rá, ezek az értékek lényegesek:

"RestApiEnabled": true,
"RestApiPort": 7878,
"EnableTokenEndpointAuthentication": true,
"LogRest": true,
"RESTMaximumRequestsPerInterval": 5,
"RESTRequestBucketDecreaseIntervalMinutes": 1

Két dolog fontos ebben. Először is a /status végpont token nélkül kiadja a szerver nevét, a portot, a játékosok számát és a játékosneveket, amíg az EnableTokenEndpointAuthentication false értéken áll. Ez kényelmes az állapotoldalaknak és a Discord-botoknak, egyszerre pedig ingyenes felderítés minden támadónak, aki tudni akarja, mikor érdemes támadni. Másodszor a /v2/token/create végpont a felhasználónévből és a jelszóból hozzáférési tokent állít elő, és kívülről elérhető, amint a 7878-as port nyitva áll: ez jelszóra irányuló találgatásos támadás az adminfiókja ellen, amely mellékesen számítási időt is fogyaszt. A RESTMaximumRequestsPerInterval és a RESTRequestBucketDecreaseIntervalMinutes értékéből álló vödör ezt lefékezi, de tűzfalszabályt nem helyettesít.

Magára a játékbeli hozzáférésre további TShock-értékek hatnak. A MaximumLoginAttempts 3-on áll, és három hibás kísérlet után kidobja a játékost. A RequireLogin (alapértelmezés false) fiókot követel meg minden játékostól. Az EnableIPBans (alapértelmezés true) és a KickProxyUsers (alapértelmezés true) egy TCP-játéknál különösen hatásos, mert egy felépített kapcsolat forráscíme éppen nem lehet hamisított. A griefing ellen, amelyet gyakran támadásként jelentenek, a TileKillThreshold (60), a TilePlaceThreshold (20), a TileLiquidThreshold (15) és a ProjectileThreshold (50) küszöbérték hat, mindegyik másodpercenkénti műveletszámban.

5. A kapcsolatok korlátozása forráscímenként és a SYN-cookie-k ellenőrzése

Mivel a Terraria TCP-n fut, a leghatásosabb helyi szabály az egyidejű kapcsolatok forráscímenkénti felső korlátja. Egy valódi játékosnak pontosan egy kell:

iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m hashlimit --hashlimit-name terraria_syn --hashlimit-mode srcip --hashlimit-above 10/min --hashlimit-burst 20 -j DROP

Az első szabály eldobja az új kapcsolatokat, amint egy címnek több mint három van egyszerre nyitva. A második ugyanazon forrás kapcsolódási kísérleteinek arányát percenként tízre korlátozza, 20-as ráhagyással. Mindkét szám kiindulási érték, nem igazság: egy közös internet-előfizetés mögött (lakóközösség, iskolai hálózat, mobilszolgáltató) több szabályos játékos is ugyanazon a címen jelenik meg. Mérjen előbb egy hetet normál üzemben.

A puszta iptables-szabályok egy újraindítás után nincsenek meg, Debian és Ubuntu alatt így mentik el őket:

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

UFW alatt az ilyen szabályok a /etc/ufw/before.rules fájlba tartoznak, különben a következő ufw reload parancsnál eltűnnek. A hamisított SYN-csomagok ellen, amelyek soha nem fejezik be a kézfogást, egyik szabály sem segít, hanem maga a kernel. Ellenőrizze a három értéket:

sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn

A net.ipv4.tcp_syncookies értékének 1-en kell állnia, Debian és Ubuntu alatt ez általában már így van. A SYN-cookie-k lemondanak a félig nyitott kapcsolatok várakozási soráról, és a kliens válaszából állítják vissza az állapotot, egy SYN-flood ezzel a levegőbe fut, amíg a vonal nincs tele. A net.core.somaxconn a Linux 5.4 verzió óta 4096-on áll, azelőtt 128-on: ha az érték kicsi, a kernel eldobja a készen felépített kapcsolatokat, még mielőtt a játékfolyamat egyáltalán elfogadhatná őket.

6. A férőhelyek kimerítésének megakadályozása: miért tölti meg egy portszkennelés a szerverét

A férőhelyek kimerítése a legolcsóbb hatásos támadás egy Terraria-szerver ellen: a támadó annyi TCP-kapcsolatot nyit a 7777-es portra, ahány játékoshelye van a szervernek, és nyitva tartja őket. Ez neki szinte semmi sávszélességbe nem kerül, a szervert viszont megtölti. A valódi játékosok a „Server is full” üzenetet látják, és nem jutnak be, miközben a vonalán semmi feltűnő nem történik. Pontosan ez az oka annak, hogy a Terraria esetében az üzemeltetők gyakran észre sem veszik, hogy támadják őket.

Az ok a számolás módjában van: egy kapcsolatot már azelőtt elfogad a szerver, hogy a kliens egyáltalán elküldte volna a verzióazonosítóját. Történetileg az ilyen szellemkapcsolatok addig maradtak lefoglalva, amíg a TCP-munkamenet le nem járt. Az 1.4.5-es sorozat ezt tompította, ott az azonnal újra lekapcsolódó kliensek számára már nem tartanak fenn férőhelyet. Az 1.4.5.7 és az 1.4.5.8 első kiadásában viszont a dedikált szerver kezeletlen ObjectDisposedException hibával összeomlott, amint egy TCP-kapcsolat megnyílt, és a kézfogás nem fejeződött be. Egy nc -z vagy egy monitorozás elérhetőségi ellenőrzése is elég volt hozzá. A hibát néhány hét alatt csendben kijavították, régebbi konténerképekben részben még benne van. Tartsa ezért naprakészen a szerververzióját: ez itt nem közhely, hanem konkrét rendelkezésre állási kérdés.

Két beállítás ezen felül is segít. Aki TShockot használ, a MaxSlots értékét a kívánt játékosszámra állítja, a serverconfig.txt fájlban lévő maxplayers értékét pedig két hellyel magasabbra: ilyenkor a TShock tiszta üzenettel elutasítja a felesleges kapcsolatokat, ahelyett hogy a játékfolyamat beengedné őket az utolsó résbe. A kapcsolatszám előző szakaszban leírt felső korlátja pedig pontosan az a szabály, amely egyetlen címet megakadályoz abban, hogy egyszerre minden férőhelyet elfoglaljon.

7. Az UPnP kikapcsolása, és ne tegye közzé saját maga a címet

A Terraria-szerver alapértelmezés szerint megpróbálja UPnP-vel megnyitni a portját egy routeren. Egy bérelt szerveren ez hatástalan, otthoni hálózatban viszont olyan portokat nyit meg, amelyekről később már nem tud. Kapcsolja ki a serverconfig.txt fájlban az upnp=0 beállítással, vagy a parancssorban a -noupnp paraméterrel.

Itt ráadásul az őszinteség többet ér a vágyálmoknál: az IP-címét nem lehet titokban tartani. Ismeri minden játékos, aki egyszer már kapcsolódott, és egy listaoldalra felvett bejegyzés amúgy is közzéteszi. Két szokás hatásos. Sehol ne tegye közzé saját maga a nyers IP-címet, hanem hostnéven keresztül kösse be a játékosait: a Terraria-kliens feloldja a hostnevet, így éles helyzetben lecserélheti a címet anélkül, hogy minden hivatkozás eltörne. És takarítsa el a régi DNS-bejegyzéseket, mert egy elfelejtett A-rekord a korábbi címre minden cserét hatástalanná tesz.

8. Az állapotlekérdezéseket tárolja el átmenetileg, ne engedje át őket

Mivel a Terrariának nincs lekérdezési protokollja, az állapotoldalak, a Discord-botok és a listaoldalak két út egyikén állapítják meg a szervere állapotát: vagy valódi TCP-kapcsolatot építenek a 7777-es portra és kliensnek adják ki magukat, vagy a TShock REST-API-t kérdezik le. Mindkettő munkába kerül a szerverének, és mindkettő a kérdezők számával együtt nő.

Az ellenintézkedés semmibe nem kerül: soha ne a látogató felől kérdezzen. Egyetlen szolgáltatás hozza be az állapotot fix időközönként (30 vagy 60 másodperc elegendő), tárolja el az eredményt, és minden látogatónak az eltárolt állást adja ki. Egy sokat látogatott állapotoldal így intervallumonként egy lekérdezést okoz, nem látogatónként egyet. Aki ehhez a REST-API-t használja, a 7878-as portot erre az egyetlen szolgáltatásra korlátozza.

9. Naplózás, hogy éles helyzetben legyenek adatai

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

sar -n DEV 1 10
ss -s
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 tcp port 7777 -c 200 -q

A harmadik parancs a Terrariára jellemző: a félig nyitott kapcsolatokat számolja meg. A kétjegyű érték normális, a négy- vagy ötjegyű SYN-flood. Az ss -s emellett a TCP-kapcsolatok összes számát mutatja, és ha ez a szám körülbelül megegyezik a maxplayers értékével, miközben a játékban senki nincs, akkor a férőhelyek kimerítését látja. A tcpdump esetében érvényes: mindig korlátozza a -c kapcsolóval, mert egy teljes terhelés alatt készült rögzítés az amúgy is túlterhelt szervert tovább terheli. Hogy az értékeket hogyan értékelje ki, arról a DDoS-támadás felismerése cikk szól.

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

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

Számoljon utána egyszer. Egy tipikus játékszerver 1 Gbit/s-os vonalon lóg, ez 125 megabájt másodpercenként, és a vonal tele van, amint valaki ennél többet küld. Az ilyen nagyságú játékszerver-projektek elleni támadások szokásosan 5 és 50 Gbit/s között vannak, tehát a vonala öt-ötvenszeresén. Hogy a mögötte lévő connlimit-szabálya jó-e, akkor már nem számít, mert a játékosai csomagjai már előtte sem jutnak át. Pontosan így keletkeznek azok a Terraria-szerveren jelentkező lag-tüskék, amelyek mellett a processzorterhelés normálisnak látszik.

A második mennyiség a csomagsebesség, és ez gyakran hamarabb üt be, mint a sávszélesség. 64 bájtos kis csomagoknál egy 1 Gbit/s-os 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ázezrét dolgozza fel, mielőtt elkezdene eldobni. Egy SYN-flood esetében a határ még alacsonyabban van, mert minden SYN-csomag állapotdöntést vált ki: már másodpercenként néhány tízezer SYN-csomag is elég ahhoz, hogy megbénítsa egy szokványos Linux kapcsolatelfogadását, jóval azelőtt, hogy a vonal megtelne. Az üzemeltetők ezt így élik meg: „a terhelés nem is volt magas, mégis minden elérhetetlen lett”.

A harmadik pont pedig az, amelyet a Terraria esetében a leggyakrabban figyelmen kívül hagynak: a támadó nem az Ön protokolljához igazodik. UDP-áradatokat és reflexiós forgalmat küld a címére, pedig egyetlen UDP-porton sem figyel semmi. A szervere ezeket a csomagokat helyesen eldobja, de már lefoglalták a vonalát, és a Terraria-szervere offline lesz anélkül, hogy egyetlen csomag is elérte volna a játékfolyamatot. A nagyságrendek besorolásához, amelyek valóban előfordulnak: a KernelHost szerverein többek között egy 473,4 Gbit/s feletti támadást szűrtek ki másodpercenként több mint 41,5 millió csomaggal, és egy 112,2 Gbit/s feletti UDP-floodot egy játékszerver ellen. Erre nincs helyi beállítás. A volumetrikus támadásoknak a szerver előtti hálózatban kell véget érniük.

Mit állít ez ellen a KernelHost

A folyamatos védelem, amely minden szerverben benne van

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

• 1. réteg: 17 Tbps mitigációs kapacitás a globális scrubbing-hálózatban. A volumetrikus támadásokat a forrásuk közelében tisztítják 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 ismerik fel és dobják el a protokollspecifikus mintákat, csomagról csomagra. A Terraria esetében ez konkrétan azt jelenti: a 7777 TCP ellen irányuló SYN-áradatok és kapcsolatáradatok itt érnek véget, nem az Ön hálózati kártyáján.

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

Advanced DDoS Protection a tartósan támadott 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, 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 a frankfurti központi hálózatbó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 átépítésre.
• Önállóan kezelhető védelmi szabályok portonként és protokollonként az ügyfélportálon: beállítja, mi engedélyezett a 7777 TCP porton, és minden mást bezárhat anélkül, hogy hibajegyet kellene írnia.
• A módosítások valós időben lépnek érvénybe, tehát futó támadás közben is utánaigazíthat, például szűkebbre húzhatja a forráscímenként engedélyezett kapcsolódási arányt.
• Az alkalmazáshoz illő védelmi profil. Az olyan TCP-játékokhoz, mint a Terraria, valamint a saját és a módosított alkalmazásokhoz tetszőleges TCP- vagy UDP-portokon illeszkedő profilok vannak.

A két szint összehasonlítva

A legtöbb Terraria-projekthez elegendő a beépített 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. Aki a szerverét jelenleg máshol üzemelteti, annak a védelmet nem utólag szerelik fel, hanem a KernelHostra való költözéssel kapja meg: a szűrés a hálózat része, nem a szerverre tett kiegészítés.

Gyakori hibák és megoldások

„A szerver tele van, de nincs benne senki”: ez a férőhelyek kimerítése. Ellenőrizze az ss -tn dst :7777 | wc -l paranccsal, hány kapcsolat van valóban nyitva, és vesse össze a játékoslistával (szerverkonzol: playing). Ha a számok nem egyeznek, idegen kapcsolatok foglalják a férőhelyeket. Ellenszer a kapcsolatszám forráscímenkénti felső korlátja, egy szerverjelszó és egy naprakész szerververzió.

„Engedélyeztem a 7777 UDP portot, és nem változik semmi”: helyes, mert a 7777 UDP porton semmi nem figyel. A Terraria kizárólag TCP-t használ. Az UDP-engedélyezés közvetlenül nem káros, de szükségtelen nyitás, és biztos jele annak, hogy egy másik játékhoz írt útmutatót másoltak le.

„Az iptables-szabályaim nem érvényesülnek”: három ok gyakori. A szabályok az UFW-láncok után állnak, és soha nem érik el őket; az utolsó újraindítás után nem voltak meg (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 emelkednek-e a találati számlálók. Ha nullán maradnak, a szabályt nem érik el.

„A játékosok kirepülnek, pedig nincs támadás”: ha túl szűkre húzza a connlimit-korlátját, az a közös előfizetések mögött lévő játékosokat találja el. TCP esetében ez hamarabb megtörténik, mint UDP-játékoknál, mert egy kimaradás utáni újrakapcsolódás azonnal új kapcsolatot hoz létre, miközben a régi még TIME_WAIT állapotban van. Emelje az értéket lépésenként, és figyelje a találati számlálókat.

„A szerver akadozik, a vonal viszont csendes”: ez gyakrabban egy mod vagy egy bővítmény, mint egy támadás. tModLoader alatt minden további mod számítási időbe kerül ugyanabban a folyamatban, és egy sok entitást tartalmazó világ teljesen kiterheli az egyik processzormagot anélkül, hogy egy csomaggal is több érkezne. Ha a sar -n DEV 1 10 feltűnésmentes marad, nem DDoS-támadás történt.

„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, Önnek viszont az eredmény azonos egy sikeres támadással, többnyire még órákkal utána is. Kétség esetén kérdezzen rá, hogy szűrés vagy null-routing történik. A válasz többet dönt a rendelkezésre állásáról, mint bármilyen hardveres adat.

„A tcpdump kimenetében 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ésnél 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 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 Terraria-szervernek pontosan egy nyitott portra van szüksége: 7777 TCP. A játék nem nyit UDP-socketet, nincs lekérdezési protokollja és nincs RCON-ja.
• A TShock REST-API a 7878 TCP porton a második támadási felület. Hagyja a RestApiEnabled értéket false állapotban, vagy korlátozza a portot a saját címére.
• A serverconfig.txt fájlban megadott szerverjelszó a leghatásosabb ingyenes intézkedés, mert a 37-es üzenetre adott helyes válasz nélkül a támadó soha nem jut el a világ átviteléig.
• A férőhelyek kimerítése a Terraria esetében a legolcsóbb támadás: a 7777-es portra elfogadott minden TCP-kapcsolat elfoglal egy helyet, érdemi sávszélesség nélkül. Ez ellen a forráscímenkénti felső korlát, egy jelszó és egy naprakész szerververzió hat.
• Mivel a Terraria TCP-t használ, egy felépített kapcsolat forráscíme nem hamisítható: az IP-tiltások itt jobban hatnak, mint UDP-játékoknál. A hamisított SYN-áradatok ellen csak a SYN-cookie-k és az előtte lévő hálózatban végzett szűrés segít.
• Egy UDP-flood megbénítja a Terraria-szerverét, pedig az nem beszél UDP-t, mert megtölti a vonalat, még mielőtt a játékfolyamat bármit is látna.
• Körülbelül az uplink-sávszélessége nagyságától kizárólag a szerver előtti hálózat dönt. A KernelHostnál ez a szűrés kétrétegű, tartósan aktív, és felár nélkül benne van minden szervercsomagban.

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 támogatási hibajegyet, hogy a szűrőszabályokat az IP-címéhez igazítsák. Futó támadás esetén ezen felül a WhatsApp-vészhelyzeti chaten ér el minket a +43 650 8209883 számon.