Protejarea serverului Project Zomboid împotriva atacurilor DDoS

Cine vrea să își protejeze serverul Project Zomboid împotriva atacurilor DDoS trebuie să știe mai întâi în ce trage de fapt un atacator. Un server dedicat ocupă exact două porturi UDP, 16261 și 16262, iar amândouă trebuie să stea deschise în rețea, pentru că altfel nimeni nu se poate conecta. Acest articol merge în ordinea care contează în caz serios: mai întâi ceea ce puteți face singur în următoarele zece minute, fără costuri suplimentare, apoi punctul în care aceste măsuri se termină din motive tehnice și, la final, ceea ce trebuie să se întâmple înainte de asta, în rețea.

Toate datele se referă la serverul dedicat (aplicația Steam 380870) sub Debian 12, Debian 13, Ubuntu 22.04 LTS sau Ubuntu 24.04 LTS, atât pentru Build 41, cât și pentru Build 42. Fișierul de configurație se numește servertest.ini și se află în ~/Zomboid/Server/, datele lumii se află în ~/Zomboid/Saves/Multiplayer/. Comenzile sunt scrise pentru root, ca utilizator obișnuit puneți sudo în față.

Dacă atacul este chiar acum în curs: Nu modificați nimic acum în servertest.ini și nu reporniți serverul. Salvați mai întâi valorile măsurate (secțiunea 9), după atac ele dispar. O repornire costă suplimentar timpul de care are nevoie serverul pentru încărcarea lumii, și exact acest timp vrea atacatorul să vi-l ia.

De ce serverele Project Zomboid devin ținta atacurilor DDoS

Project Zomboid este un joc cu moarte permanentă și o lume care merge înainte luni de zile. O întrerupere de conexiune în mijlocul unei situații periculoase costă aici mai mult decât în aproape orice alt gen: personajul este pierdut, iar lumea își amintește de asta. Exact acest lucru transformă o cădere în armă. Un atac la ora 20 lovește o comunitate stabilă, și o lovește exact acolo unde are cel mai mult de pierdut.

La asta se adaugă faptul că atacul în sine nu costă nimic și nu cere nicio pricepere. Serviciile de atac contra cost, numite în mediul respectiv booter sau stresser, se îndreaptă cu câteva clicuri împotriva unei adrese IP și a unui port, iar la Project Zomboid ținta este întotdeauna aceeași: 16261 UDP. Cine este în conflict cu un jucător exclus sau conduce o comunitate concurentă are astfel în mână un instrument pentru care nu îi trebuie nici cunoștințe, nici bani de luat în seamă.

La asta se adaugă faptul că un game server trebuie să își publice adresa. Dacă în servertest.ini stă Public=true, serverul apare în browserul jocului, iar un server cu legătură la Steam este oricum vizibil în browserul de servere Steam. Întrebarea nu este deci niciodată dacă un atacator găsește adresa dumneavoastră IP, ci doar ce se întâmplă atunci când trage în ea.

Din punct de vedere tehnic, partea cea mai neplăcută vine la final: tot traficul de joc circulă prin UDP. UDP nu cunoaște nicio deschidere de conexiune care ar putea fi pretinsă, fiecare pachet stă pe cont propriu, iar adresa expeditorului poate fi falsificată. Un atacator nu trebuie deci nici să intre pe serverul dumneavoastră, nici să i se adreseze corect pentru a genera încărcare. Ce este în detaliu un atac DDoS explică articolul Ce este un atac DDoS?.

De ce porturi are nevoie cu adevărat un server Project Zomboid

Un server dedicat de Project Zomboid are nevoie de exact două porturi deschise: 16261 UDP și 16262 UDP. Lista oficială de porturi a jocului nu numește niciun al treilea. În servertest.ini ele stau ca două directive separate, al doilea port nu rezultă automat din primul:

DefaultPort=16261
UDPPort=16262
SteamPort1=8766
SteamPort2=8767
RCONPort=27015
RCONPassword=

Împărțirea sarcinilor este clară. 16261 UDP transportă traficul de joc și deschiderea conexiunii și răspunde interogărilor browserului de servere. 16262 UDP este portul pentru conexiunea directă a clienților. Dacă lipsește primul, nimeni nu găsește serverul, dacă lipsește al doilea, jucătorii dumneavoastră văd intrarea în listă și totuși nu intră. Exact de aici provine cel mai cunoscut mesaj de eroare al jocului, cel care spune că portul 16262 ar fi închis.

Două puncte care produc necazuri în mod regulat. În primul rând: fiecare instanță de server are nevoie de două porturi UDP libere. Cine operează o a doua lume pe aceeași mașină alocă pentru asta o a doua pereche, de exemplu 16274 și 16275, și trece ambele valori în servertest.ini a celei de a doua instanțe. În al doilea rând: SteamPort1 și SteamPort2 stau cu 8766 și 8767 în fișierul de configurație, dar aparțin legăturii la Steam și nu traficului de joc. Deschideți-le numai dacă serverul dumneavoastră nu apare fără ele în lista Steam, nu preventiv.

Ce puteți face singur înainte să dați bani

Această secțiune este cea mai lungă, și asta în mod intenționat. Un server configurat curat rezistă cu forțe proprii la atacuri mici și medii, independent de locul unde este găzduit. El nu vă scutește de un atac volumetric, dar are grijă ca atacurile ieftine să rămână fără efect și ca în caz serios să aveți cifre în loc de presupuneri.

1. Inventar: ce ascultă în realitate

Înainte să scrieți o singură regulă, verificați ce oferă serverul dumneavoastră în exterior. Nu ghiciți, verificați:

ss -lntup

Interesantă este coloana cu adresa locală. 0.0.0.0:16261 și [::]:16261 înseamnă „accesibil din întregul internet”, 127.0.0.1:27015 înseamnă „numai local” și nu are nevoie de nicio permisiune. Comparați rezultatul cu configurația dumneavoastră, în loc să vă bazați pe valorile implicite:

grep -E "^(DefaultPort|UDPPort|SteamPort1|SteamPort2|RCONPort|Public|Open|MaxPlayers|MaxAccountsPerUser)=" ~/Zomboid/Server/servertest.ini

Perspectiva atacatorului o oferă o scanare de porturi din exterior. Deoarece Project Zomboid folosește exclusiv UDP, este nevoie pentru asta de scanarea UDP, o scanare pur TCP nu arată deloc portul de joc:

nmap -Pn -sU -p 16261,16262,8766,8767 ADRESA.IP.A.SERVERULUI
nmap -Pn -p- --min-rate 1000 ADRESA.IP.A.SERVERULUI

2. Lăsați deschise numai 16261 și 16262

Două permisiuni către exterior sunt suficiente, tot restul este restrâns sau nici nu este publicat. Cu UFW arată așa, și exact în această ordine, ca să nu vă blocați singur accesul:

ufw allow 22/tcp comment "SSH"
ufw allow 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid conexiune directă"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Înlocuiți 203.0.113.10 cu adresa dumneavoastră proprie. Ordinea la activare decide dacă vă blocați singur accesul. Ea se află, împreună cu calea de întoarcere, în articolul Configurarea firewallului UFW fără să vă blocați singur accesul. Dacă totuși se întâmplă: la serverele root KVM și la serverele dedicate de la KernelHost ajungeți la sistem prin consola VNC din panoul clientului, care lucrează independent de rețeaua sistemului oaspete.

Un cuvânt despre baze de date și servicii suplimentare: Project Zomboid nu are nevoie de niciunul. Ce ascultă pe 0.0.0.0 în afară de joc provine dintr-o instalare anterioară sau de la un panou de administrare și trebuie fie legat la 127.0.0.1, fie oprit.

3. Scoateți RCON de pe portul 27015 de pe internet

RCON este controlul la distanță al serverului și rulează la Project Zomboid pe 27015 TCP. În servertest.ini livrată stă RCONPassword= fără valoare. Cine folosește RCON setează o parolă aleatorie lungă, deoarece protocolul transmite necriptat, iar un port RCON accesibil cu o parolă slabă predă serverul în întregime, fără să fie nevoie pentru asta de un singur pachet de trafic de atac.

Calea sigură este să nu deschideți deloc portul către exterior și să ajungeți la el printr-o redirecționare de port prin SSH. După aceea vorbiți local cu 127.0.0.1:27015:

ssh -N -L 27015:127.0.0.1:27015 root@ADRESA.IP.A.SERVERULUI

Cine nu are nevoie de RCON lasă câmpul de parolă gol și portul închis. Un serviciu care nu este accesibil nu poate fi nici testat prin încercări repetate, nici inundat.

4. Limitați ratele de pachete pe adresă sursă

Împotriva atacurilor mici și a boților prost făcuți ajută o limită superioară pe adresă sursă. Deoarece ambele porturi de joc se află unul lângă altul, o singură regulă pentru intervalul lor este suficientă:

iptables -I INPUT -p udp --dport 16261:16262 -m hashlimit --hashlimit-name pz_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP
iptables -L INPUT -n -v

Regula elimină pachetele UDP de îndată ce aceeași adresă sursă trimite permanent mai mult de 400 de pachete pe secundă. Valoarea este una de pornire, nu un adevăr absolut: un server cu 30 de jucători în același oraș generează vizibil mai mult trafic decât unul cu patru jucători în colțuri diferite ale hărții, iar cine setează prea strâns își aruncă afară jucătorii proprii. Măsurați mai întâi o săptămână în regim normal, apoi puneți limita la un multiplu al valorii de vârf.

Două observații la asta. Regulile pure de iptables dispar după o repornire, sub Debian și Ubuntu se salvează astfel:

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

Iar sub UFW, astfel de reguli trebuie trecute în /etc/ufw/before.rules, deoarece altfel dispar la următorul ufw reload. Verificați cu contoarele de potriviri din iptables -L INPUT -n -v dacă regula este atinsă efectiv. Dacă contoarele rămân la zero, ea stă în locul greșit.

5. Degrevați urmărirea conexiunilor

Un blocaj deseori trecut cu vederea stă în kernel. Urmărirea conexiunilor creează și pentru UDP o intrare pe fiecare adresă sursă și port, iar un flood cu expeditori falsificați umple acest tabel în câteva secunde. Dacă se umple, serverul elimină și pachete legitime, iar în jurnal apare „nf_conntrack: table full”. Starea și limita superioară se văd cu:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Traficul de joc al Project Zomboid nu are nevoie de urmărirea stării, deoarece UDP nu are nicio stare. Puteți deci ține cele două porturi de joc în afara tabelului:

iptables -t raw -I PREROUTING -p udp --dport 16261:16262 -j NOTRACK

Asta degrevează kernelul în mod sesizabil. Important: regula se potrivește numai atât timp cât serverul primește pachetele direct. Cine operează în fața lui o traducere de adrese, de exemplu într-o construcție cu containere și transmitere de porturi, nu are voie să o seteze, deoarece direcția de întoarcere nu mai poate fi atribuită.

6. Securizați conectarea și sloturile

Liniile următoare nu costă nimic și acționează împotriva a tot ce vine pe calea obișnuită de conectare:

Password=O-PAROLA-LUNGA-ALEATORIE
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password este parola comună a serverului și este separată de contul jucătorului individual. Open=false înseamnă că au voie să se conecteze numai conturile create în prealabil de un administrator, aceasta este lista albă a jocului. MaxAccountsPerUser limitează câte conturi are voie să creeze un singur utilizator Steam pe serverul dumneavoastră, valoarea implicită 0 înseamnă nelimitat. MaxPlayers stă din fabrică pe 32, iar peste această valoare documentația avertizează în mod explicit asupra încărcării proaste a hărții și asupra desincronizării.

PingLimit este capcana în acest punct. Directiva aruncă afară jucătorii de la o anumită latență în milisecunde și stă din fabrică pe 0, deci este oprită. Sub un atac, latența jucătorilor dumneavoastră proprii crește prima, deci o valoare strânsă dă afară exact oamenii pe care vreți să îi păstrați. Lăsați limita oprită sau setați-o generos.

Și un lucru trebuie să fie clar: o listă albă vă protejează logica jocului, nu conexiunea. Un atacator care vă inundă serverul nu vrea deloc să se conecteze. Pachetele lui sunt respinse, dar au sosit totuși, și exact asta este problema.

7. Verificarea modurilor la conectare este cea mai scumpă secundă a serverului dumneavoastră

Project Zomboid verifică la conectare mai mult decât o parolă. Lista de moduri a serverului stă în două linii din servertest.ini: WorkshopItems conține ID-urile numerice din Workshop, Mods conține ID-urile de încărcare ale modurilor, ambele separate prin punct și virgulă. La conectare, clientul compară această listă, descarcă automat prin Steam conținutul lipsă din Workshop și abia după aceea primește datele lumii prin streaming. Suplimentar, la DoLuaChecksum=true serverul compară sumele de control ale fișierelor jocului și aruncă afară clienții ale căror fișiere nu se potrivesc cu ale lui.

Pentru un atacator exact asta este interesant, deoarece munca se face înainte de participarea propriu-zisă la joc. Fiecare încercare de conectare costă serverul timp de calcul pentru versiune, sumă de control, listă de moduri și date de hartă, inclusiv încercarea care este respinsă la final. O listă lungă de moduri face fiecare dintre aceste încercări mai scumpă. Un flood de conectări este de aceea mai eficient pe un server puternic modificat decât pe unul nemodificat, și are nevoie pentru asta de o fracțiune din lățimea de bandă a unui atac volumetric. Jocul aduce împotriva acestui lucru două frâne încorporate:

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

DenyLoginOnOverloadedServer respinge conectările noi cât timp serverul este suprasolicitat, în loc să prăbușească și runda în desfășurare. LoginQueueEnabled pune cei care se conectează într-o coadă de așteptare, în loc să îi prelucreze simultan, iar LoginQueueConnectTimeout stabilește cât timp are voie să dureze o conectare, valoarea implicită 60 de secunde, permise sunt 20 până la 1200.

Un detaliu face parte din asta, pentru că este rezolvat frecvent greșit: pe serverele Linux există o eroare documentată la care DoLuaChecksum dă alarme false și nu lasă jucătorii să intre. Operatorii opresc de aceea verificarea. Asta este de înțeles, dar înlătură un control care ține la distanță clienții cu fișiere de joc modificate. Cine trebuie să o oprească ar trebui să seteze cu atât mai strict parola serverului, lista albă și limita de conturi.

8. Lista de servere, UPnP și adresa proprie

Aici merită sinceritatea în locul gândirii dorite: adresa dumneavoastră IP nu poate fi ținută secretă. Public=true arată serverul în browserul jocului, iar un server cu legătură la Steam este, conform documentației, oricum vizibil în browserul de servere Steam. Public=false vă ia deci vizibilitatea pentru jucătorii noi, fără să vă facă invizibil.

Public=true
PublicName=Serverul meu Zomboid
UPnP=false
server_browser_announced_ip=

UPnP stă din fabrică pe true și lasă serverul să încerce să configureze singur o permisiune de port la un gateway de internet. Pe un server închiriat nu există un asemenea gateway, încercarea se duce în gol și trebuie oprită. server_browser_announced_ip rămâne gol, cu excepția cazului în care serverul dumneavoastră are mai multe adrese și trebuie să apară în mod țintit sub una dintre ele. Exact de acest câmp aveți nevoie din nou mai târziu, când comutați pe un IP de protecție dedicat.

Două obiceiuri ajută mai mult decât orice setare. Nu publicați nicăieri singur adresa IP brută, deci nici pe canalul de Discord, nici pe pagina proiectului, și dați jucătorilor dumneavoastră un nume de gazdă. Clasicul la schimbarea de adresă sunt înregistrările DNS vechi: o înregistrare A uitată către adresa anterioară face orice schimbare lipsită de efect.

9. Măsurați cât timp totul merge normal

Pasul cel mai important este cel pe care aproape nimeni nu îl face dinainte: să creați o bază de comparație cât timp totul este liniștit. Fără o valoare normală nu puteți spune, după un incident, dacă 40.000 de pachete pe secundă au fost mult sau pur și simplu sâmbătă seara. Cu apt-get install -y vnstat sysstat măsurarea rulează permanent. În timpul unui incident sunt suficiente patru comenzi:

sar -n DEV 1 10
ip -s link show eth0
tcpdump -ni eth0 "udp port 16261 or udp port 16262" -c 200 -q
journalctl -u zomboid --since "-15 min" | tail -50

Primele două arată rata de pachete și contoarele de pachete eliminate ale interfeței, a treia o probă scurtă a traficului, a patra mesajele serverului, în măsura în care el rulează ca serviciu systemd (adaptați numele serviciului). La tcpdump se aplică o regulă: limitați întotdeauna cu -c, o captură sub încărcare maximă apasă suplimentar un server oricum suprasolicitat. Cum evaluați valorile se află în Recunoașterea unui atac DDoS pe server.

Unde se termină aceste măsuri: lățimea de bandă și rata de pachete

Acum partea pe care niciun fișier de configurație nu o poate rezolva. Toate măsurile de până acum rulează pe serverul dumneavoastră, deci la capătul conexiunii. O regulă de firewall decide asupra unui pachet care a trecut deja prin cablu. Îl puteți elimina, dar nu îl puteți face netrimis.

Faceți o dată socoteala. Un game server tipic atârnă de o conexiune de 1 Gbit/s, adică 125 de megaocteți pe secundă, iar conexiunea este plină de îndată ce cineva trimite mai mult. A doua mărime este rata de pachete, iar ea lovește adesea mai devreme decât lățimea de bandă: la pachete mici de 64 de octeți încap în 1 Gbit/s circa 1,49 milioane de pachete pe secundă, în timp ce un kernel obișnuit de server prelucrează, în funcție de CPU și de placa de rețea, doar câteva sute de mii dintre ele înainte să înceapă să elimine. Un atac care nu vă umple conexiunea nici măcar la o treime poate deci să vă scoată serverul din funcțiune. Operatorii trăiesc asta ca „încărcarea nici nu era mare, și totuși totul era pierdut”.

Atacurile obișnuite împotriva comunităților de game server se situează între 5 și 50 Gbit/s, adică la de cinci până la cincizeci de ori o conexiune normală. Pentru asta nu există nicio setare locală. Atacurile volumetrice trebuie să se termine în rețeaua din fața serverului.

Ce pune KernelHost împotriva atacurilor DDoS asupra game serverelor

Protecția permanentă, inclusă pe fiecare server

Protecția DDoS de la KernelHost este construită pe două niveluri și este activă permanent, fără să fie nevoie să activați, să comandați sau să configurați ceva:

• Nivelul 1: 17 Tbps capacitate de mitigare în rețeaua globală de scrubbing. Atacurile volumetrice sunt curățate aproape de sursa lor, înainte să ajungă în centrul de date.
• Nivelul 2: filtrare Arbor în timp real cu 3,2 Tbps în Frankfurt pe Main. Direct în fața serverului, modelele specifice de protocol sunt recunoscute și eliminate, pachet cu pachet.

Două proprietăți sunt decisive. Protecția rulează permanent și nu trebuie să reacționeze abia la un atac, deci nu există minute la început în care serverul este pierdut. Și nu se folosește nullrouting: adresa dumneavoastră IP rămâne în rețea, eliminate sunt numai pachetele dăunătoare. Cine scoate adresa IP din rețea obține pentru dumneavoastră același rezultat ca atacatorul. Ce jocuri și protocoale sunt acoperite le enumeră Protecție DDoS în timp real pentru game servere.

Advanced DDoS Protection pentru proiectele bombardate permanent

Unele proiecte nu sunt atacate ocazional, ci în mod țintit și săptămâni în șir. Pentru asta există Advanced DDoS Protection de la 50,00 € pe lună, PrePaid, fără durată minimă și fără taxă de instalare. Diferența nu stă în mai multă capacitate, ci în control:

• IP de protecție dedicat din nucleul de la Frankfurt, pe care serverul dumneavoastră este comutat în rețeaua proprie. De partea dumneavoastră nu este nevoie de nicio modificare, adresa nouă trebuie doar trecută acolo unde jucătorii dumneavoastră găsesc serverul.
• Reguli de protecție administrabile de dumneavoastră, pe port și pe protocol, în panoul clientului: stabiliți ce este permis pe 16261 și 16262 UDP, iar tot restul rămâne închis, fără să scrieți pentru asta un tichet.
• Modificările au efect în timp real, deci puteți ajusta chiar în timpul unui atac în desfășurare.
• Profil de protecție potrivit. Pentru jocurile răspândite există profiluri gata făcute, pentru aplicațiile modificate și proprii setați singur regulile pe port și pe protocol. Project Zomboid se poate delimita deosebit de exact, deoarece tot traficul de joc circulă prin două porturi UDP vecine.

Cele două niveluri în comparație

Pentru majoritatea serverelor Project Zomboid, protecția permanentă inclusă este suficientă împreună cu o configurație curată. Advanced DDoS Protection este răspunsul la faptul că cineva o ia personal.

Greșeli frecvente și soluții

„Jucătorii mei primesc mesajul că portul 16262 ar fi închis”: Acesta nu este un atac, ci o permisiune lipsă. Serverul are nevoie de ambele porturi, 16261 UDP și 16262 UDP, și anume ca regulă UDP. O permisiune TCP pe aceleași numere nu are niciun efect. Verificați cu ufw status verbose și cu o scanare UDP din exterior dacă amândouă sunt cu adevărat deschise.

„Am schimbat adresa IP și două ore mai târziu eram iar offline”: Atacatorul a luat adresa nouă din aceeași sursă ca pe cea veche, de obicei din intrarea în lista de servere, de la un bot de Discord cu afișare de stare sau dintr-o veche înregistrare DNS. La Project Zomboid schimbarea costă suplimentar: clienții depun datele de hartă local, sub adresă și port, într-un folder după modelul 123.45.0.12_16261_... în Zomboid/Saves. După o schimbare, fiecare jucător descarcă din nou de pe server harta explorată. O schimbare de adresă este deci câștig de timp cu costuri suplimentare, nu o soluție.

„Regulile mele de iptables nu acționează”: Trei cauze sunt frecvente. Regulile stau în spatele lanțurilor UFW și nu sunt atinse niciodată, ele au dispărut după ultima repornire (atunci ajută netfilter-persistent save sau o intrare în /etc/ufw/before.rules), sau atacul este volumetric și regula lucrează corect pe o conexiune care este deja plină. Verificați cu iptables -L INPUT -n -v dacă contoarele de potriviri cresc.

„Jucătorii zboară afară la conectare, dar serverul merge normal mai departe”: Asta este aproape întotdeauna verificarea, nu un atac. Cauzele sunt o diferență de versiune între client și server, o intrare din Workshop lipsă sau învechită ori o sumă de control care nu se potrivește. Clientul numește de regulă modurile care nu corespund. Comparați WorkshopItems și Mods linie cu linie.

„La câteva minute apar vârfuri de lag, apoi merge iar”: Acesta este modelul obișnuit al atacurilor scurte, care rulează numai atât timp cât jucătorii renunță de nervi. Uitați-vă mai întâi la contoarele de rețea, nu la încărcarea procesorului. Dacă sar -n DEV 1 10 și contoarele de pachete eliminate rămân neremarcabile, nu a fost un atac, ci încărcare: prea mulți jucători în aceeași celulă, un mod scump sau prea puțină memorie RAM pentru instanța Java.

„Furnizorul meu de până acum mi-a blocat adresa IP”: Acesta este nullrouting. Furnizorul își protejează astfel propria rețea, pentru dumneavoastră rezultatul este identic cu un atac reușit, de obicei încă pentru ore după aceea. Întrebați la nevoie dacă se filtrează sau se face nullrouting. Răspunsul decide mai mult asupra disponibilității dumneavoastră decât orice specificație de hardware.

„În tcpdump nu văd nimic neobișnuit”: Dacă traficul este filtrat deja în rețeaua din față, pe server nu ajunge nimic, așa cum era de așteptat. Acesta este cazul normal la o filtrare care funcționează. Invers se aplică: dacă conexiunea este saturată, în anumite situații nu mai ajunge la dumneavoastră nici măcar sesiunea SSH cu care voiați să măsurați. Folosiți atunci consola VNC din panoul clientului.

Pe scurt

• Un server dedicat de Project Zomboid are nevoie de exact două porturi deschise: 16261 UDP (DefaultPort) și 16262 UDP (UDPPort). Amândouă stau ca directive separate în servertest.ini.
• RCON rulează pe 27015 TCP și este trecut din fabrică fără parolă. Portul nu are ce căuta pe internetul deschis, ci trebuie limitat la adresa proprie sau închis.
• Verificarea modurilor la conectare este locul cel mai scump: versiunea, suma de control, lista din Workshop și datele de hartă costă timp de calcul, inclusiv la fiecare încercare respinsă. DenyLoginOnOverloadedServer și coada de așteptare la conectare sunt frânele încorporate împotriva acestui lucru.
• Parola serverului, Open=false și MaxAccountsPerUser=1 protejează logica jocului. Împotriva unei conexiuni saturate nu are efect niciuna dintre aceste setări.
• Limita fizică este fixă: 1 Gbit/s sunt 125 de megaocteți pe secundă și, la pachete de 64 de octeți, circa 1,49 milioane de pachete pe secundă. Atacurile obișnuite împotriva game serverelor se situează la 5 până la 50 Gbit/s.
• Atacurile volumetrice trebuie să se termine în rețeaua din fața serverului. La KernelHost acestea sunt 17 Tbps capacitate de mitigare în rețeaua globală de scrubbing și o filtrare Arbor în timp real cu 3,2 Tbps în Frankfurt pe Main, fără cost suplimentar și fără nullrouting.
• Cine este bombardat permanent conduce singur filtrarea cu Advanced DDoS Protection: IP de protecție dedicat, reguli pe port și pe protocol, modificări în timp real, de la 50,00 € pe lună.

Dacă serverul dumneavoastră rulează deja la KernelHost, filtrarea este activă fără să trebuiască să faceți ceva. Dacă observați totuși nereguli, deschideți un tichet de suport, pentru ca regulile de filtrare pentru adresa dumneavoastră IP să fie ajustate. În timpul unui atac în desfășurare ne puteți contacta suplimentar prin chatul de urgență WhatsApp la +43 650 8209883.