Protejarea serverului Hytale împotriva atacurilor DDoS

Un server Hytale care pierde seara, în mijlocul jocului, toate conexiunile în același timp, este inaccesibil câteva minute și apoi rulează din nou de la sine, are rar o problemă de hardware. De regulă rulează un atac. Acest articol arată cum protejați un server Hytale împotriva atacurilor DDoS: mai întâi ceea ce puteți configura singur, fără costuri suplimentare, apoi punctul în care aceste măsuri se termină tehnic și, la final, ce trebuie să se întâmple în rețeaua din fața serverului pentru ca serverul să rămână accesibil.

Toate datele se referă la serverul dedicat oficial de la Hypixel Studios, deci la HytaleServer.jar împreună cu Assets.zip sub Java 25, operat pe Debian 12, Debian 13, Ubuntu 22.04 LTS sau Ubuntu 24.04 LTS. Comenzile sunt scrise pentru root, ca utilizator obișnuit puneți sudo în față. Hytale este în Early Access și se mișcă repede: de aceea, în acest articol, fiecare afirmație despre joc poartă o dată, iar tot ce nu este documentat oficial este marcat în mod expres ca așteptare sau ca sursă din comunitate. Dacă atacul este în curs chiar acum, este valabilă în plus o ordine: mai întâi măsurați, apoi modificați. O repornire dură sub sarcină aruncă tot ce s-a întâmplat în lume de la ultimul punct de salvare, iar valorile măsurate ale incidentului sunt după aceea de asemenea pierdute.

De ce serverele Hytale sunt paralizate țintit cu atacuri DDoS

Un server Hytale este un public la o adresă fixă, iar acest public este înlocuibil. Cine nu ajunge seara de trei ori la rând pe serverul lui obișnuit își caută altul. Exact acesta este modelul de afaceri din spatele atacurilor asupra serverelor de comunitate: nu este vorba despre date și nu este vorba despre extorcare, ci despre jucători care merg mai departe. Un serviciu booter care bombardează o adresă pentru câțiva euro pe lună nu cere de la cel care îl comandă nici pricepere, nici efort, iar paguba apare din nou la fiecare întrerupere.

La asta se adaugă la Hytale o particularitate: codul serverului este public. Hypixel Studios a anunțat în iunie 2026 programul Hytale Shared Source și pune la dispoziție prin el, pe GitHub, codul complet al serverului, protocolul de rețea și asseturile, accesibile pentru oricine are o licență de joc valabilă. Pentru operatorii de servere este un câștig, deoarece pluginurile apar față de interfețe reale. Pentru partea atacatoare înseamnă că protocolul nu mai trebuie ghicit de nimeni. Cine vrea să știe în ce punct stabilirea conexiunii consumă timp de calcul poate să citească. Ce se petrece tehnic la un asemenea atac explică articolul Ce este un atac DDoS?.

Stadiul Hytale la 27 septembrie 2026

Hytale este din 13 ianuarie 2026 în Early Access, disponibil pentru Windows, macOS și Linux, și a atins în zilele de după lansare peste un milion de jucători. Drumul până acolo a fost neobișnuit, și el explică de ce articolele mai vechi despre Hytale adesea nu mai sunt corecte.

Consecința practică a acestei cronologii: un server Hytale de astăzi nu este un server din ianuarie. Cu Update 6 protocolul de rețea s-a schimbat de la hytale/2 la hytale/3, iar potrivit Patch Notes oficiale din 27 august 2026, serverul și pluginurile trebuie construite din nou înainte să se conecteze. Cine își planifică disponibilitatea planifică de aceea nu doar împotriva atacurilor, ci și împotriva schimbărilor de protocol.

De ce 12 octombrie 2026 este termenul critic

Update-urile mari de conținut acționează ca o a doua lansare în vânzare. Ele aduc înapoi jucătorii vechi, atrag alții noi, iar pentru câteva zile accesibilitatea decide care server de comunitate crește din acest val și care îl ratează. Acest model este documentat la alte jocuri: Palworld a atins în ianuarie 2024, în decurs de câteva zile, milioane de jucători, iar serverele de comunitate din această fază de lansare au fost atacate cel mai mult exact în momentul în care aveau cel mai mult de pierdut. Mecanica din spate este descrisă în detaliu la Protejarea serverelor Palworld împotriva atacurilor DDoS și se poate transfera unu la unu la Hytale.

De aici rezultă un adevăr incomod despre calendar: protecția comandată la 12 octombrie este prea târzie. O conexiune, un IP de protecție, un set de reguli pe fiecare port și o valoare măsurată pentru regimul normal au nevoie de timp înainte, deoarece fără date de comparație nu pot fi setate în mod rezonabil. Cine începe două săptămâni înainte de un update mare are suficient timp. Cine începe în ziua update-ului ajustează pe orbecăite.

Porturile despre care este vorba în realitate la un server Hytale

Un server Hytale are nevoie de exact un port deschis: 5520 UDP. Traficul de joc rulează prin QUIC, deci prin UDP, iar TCP nu este necesar pentru traficul de joc. Cine deschide doar TCP vede aceeași imagine ca la un firewall închis: jucătorii intră într-o depășire de timp. Legarea implicită este 0.0.0.0:5520, un alt port se stabilește la pornire cu --bind.

Acest tabel este mai scurt decât la majoritatea celorlalte jocuri, și aceasta este diferența cea mai importantă. Un server Counter-Strike răspunde la interogări de stare în formatul Steam A2S, un server Minecraft Bedrock răspunde la un Unconnected Ping, un server Palworld ține deschis un port de interogare propriu. Pentru Hytale nu este descris în documentația publică, în afară de 5520 UDP, niciun alt port: niciun port de interogare, niciun port RCON, nicio interfață REST în starea de livrare. Tot ce oferă un server Hytale către exterior se află pe un singur port UDP.

Serverul Hytale în cifre

Valorile următoare sunt baza pentru fiecare decizie privind regulile de filtrare și valorile limită. Proveniența este indicată de fiecare dată, deoarece ea decide asupra gradului de încredere.

Ce schimbă QUIC la suprafața de atac

QUIC este un protocol de transport care stabilește conexiuni securizate peste UDP și care are integrat fix stabilirea criptării potrivit TLS 1.3. Nu există QUIC necriptat. Pentru un operator de server asta înseamnă două lucruri care se contrazic, și amândouă sunt importante.

Primul este o îmbunătățire reală. Deoarece UDP nu impune nicio stabilire de conexiune și adresele expeditorului se pot falsifica, serviciile UDP fără conexiune sunt amplificatoarele clasice pentru atacuri asupra unor terți. QUIC limitează asta în standard. RFC 9000 prevede în secțiunea 8.1 că un server are voie să trimită, înainte de verificarea adresei expeditorului, cel mult tripla cantitate de octeți recepționată, iar secțiunea 14.1 cere ca un client să își umple prima datagramă până la cel puțin 1200 de octeți. Împreună, aceste două reguli ridică factorul de amplificare al unui serviciu QUIC la maximum trei, în timp ce un port de interogare Steam sau un Unconnected Ping Bedrock ajunge la un multiplu din atât. Un server Hytale care lucrează corect este de aceea, ca amplificator de reflexie, practic neinteresant. Acesta este un avantaj structural față de aproape toate celelalte jocuri cu trafic UDP, iar la comparația cu serverele Minecraft Bedrock el se observă clar.

Al doilea este prețul pentru asta. O stabilire de conexiune QUIC costă serverul timp de calcul, deoarece ea cuprinde o negociere TLS 1.3 cu criptografie asimetrică. Un singur pachet falsificat nu poate impune nicio stabilire, dar un val de încercări reale de conectare dintr-un botnet poate. Atacatorul plătește de asemenea timp de calcul, și exact acest raport decide: cât timp serverul depune pe fiecare încercare de conectare mai multă muncă decât atacatorul, atacul este rentabil. Un val de încercări de conectare nu solicită de aceea conexiunea, ci procesorul, și în statistica lățimii de bandă nu arată ca nimic. Este același mecanism care la Minecraft este cunoscut ca Nullping și ca val de handshake și care este descris în detaliu în articolul Protecție DDoS și protecție Nullping pentru Minecraft.

Practic utilizabilă este la asta mai ales regula celor 1200 de octeți. O nouă încercare de conectare trebuie să ajungă ca datagramă de cel puțin 1200 de octeți, altfel, potrivit standardului, nu este o stabilire de conexiune valabilă. Traficul de joc curent este în schimb compus majoritar din pachete mici. Această deosebire se poate turna într-o regulă de filtrare, și ajungem la ea imediat.

Ce nu este documentat public despre Hytale

Această listă face parte dintr-un articol onest, deoarece ea stabilește unde nu aveți voie să vă bazați pe cifre. Tot ce urmează nu este documentat oficial la data de 27 septembrie 2026:

• Dacă serverul folosește QUIC Retry pentru verificarea adresei. RFC 9000 permite în secțiunea 8.1.2 un pachet Retry cu token, cu care un server verifică adresa expeditorului înainte să lege resurse. Dacă și de la ce sarcină face Hytale asta nu este documentat. Presupuneți că nu vă puteți baza pe acest lucru.
• Valorile implicite ale blocurilor RateLimit și ConnectionTimeouts din config.json. Că ambele blocuri există este consistent prin mai multe surse. Cifrele indicate se contrazic însă: o sursă dă valori limită concrete, o alta descrie blocurile ca existente, dar fără efect. De aceea, în acest articol nu se află niciuna dintre aceste cifre, și de aceea nu ar trebui să planificați aceste blocuri ca apărare a dumneavoastră.
• Numele și valorile implicite ale modurilor de autentificare. Documentația din comunitate privind codul de server publicat descrie trei moduri, setate prin --auth-mode, cu authenticated ca valoare implicită, precum și offline și insecure pentru medii private și pentru dezvoltare. Confirmat oficial acest lucru nu este. Regula derivată de aici este totuși clară: nu schimbați modul pentru un server public.
• Detaliile stabilirii TLS. Documentația de protocol din comunitate, care se bazează pe codul de server publicat, descrie un certificat de ambele părți, un certificat de server autoemis, generat la pornire, a cărui amprentă SHA-256 ajunge la clienți prin serviciul de sesiune, precum și un 0-RTT dezactivat. Acest lucru este plauzibil și se potrivește cu TLS 1.3, dar nu este confirmat oficial, și nu schimbă nimic la măsurile de mai jos.
• Dimensiunile atacurilor special împotriva serverelor Hytale. Nu există cifre publice despre asta. Cei 5 până la 50 Gbit/s indicați în tabel sunt o valoare din experiență peste proiecte cu servere de joc și nu sunt în mod expres o statistică Hytale.
• Ratele de pachete în regim normal pe fiecare jucător. Nici pentru asta nu există nicio publicație de încredere. De aceea, în acest articol nu se află nicio valoare limită pe care ați putea să o preluați neverificată, ci o instrucțiune despre cum să o măsurați singur.

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

Pașii următori nu opresc niciun atac volumetric, asta nu o poate realiza niciun software de pe server. Ei curăță însă tot ce se află sub acest nivel: scanări de porturi, valuri de încercări de conectare din puține surse, încercări de preluare prin interfețe de administrare instalate suplimentar și ocuparea tuturor locurilor de către străini. Aceasta este cea mai mare parte din ce deranjează un server Hytale în viața de zi cu zi, și costă o oră bună.

1. Inventar: ce ascultă pe server?

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

ss -lntup

Interesantă este coloana cu adresa locală. 0.0.0.0:5520 înseamnă „accesibil din tot internetul”, 127.0.0.1:8080 înseamnă „doar local” și nu are nevoie de nicio deschidere. Pe lângă procesul Java al serverului apar pe o mașină crescută în timp, adesea, un panou de administrare, un server web pentru afișarea hărții și o bază de date. Perspectiva atacatorului o oferă o scanare de porturi din exterior:

nmap -Pn -sU -p 5520 ADRESA.IP.A.SERVERULUI
nmap -Pn -p- --min-rate 1000 ADRESA.IP.A.SERVERULUI

A doua comandă este cea mai importantă. Ea arată ce mai stă deschis, iar în practică asta este aproape întotdeauna mai mult decât se așteaptă.

2. Lăsați deschis doar 5520 UDP, închideți tot restul

Două deschideri ajung. Cu UFW arată astfel, și anume exact în această ordine, ca să nu vă blocați singur accesul:

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

De o deschidere TCP pe 5520 nu aveți nevoie. Dacă operați serverul pe un port diferit, deschiderea trebuie să se potrivească cu valoarea din --bind, altfel pornirea se desfășoară și jucătorii totuși nu ajung. Instrucțiunile complete, inclusiv calea de salvare, se află în Configurarea firewallului UFW fără să vă blocați singur accesul.

Pentru tot ce ați instalat suplimentar pentru administrare este valabilă aceeași regulă ca la orice alt joc: nu în rețeaua deschisă, ci accesibil printr-o redirecționare de port SSH și apoi lucrați local împotriva lui 127.0.0.1:

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

3. Porniți serverul așa cum este gândit

Pornirea este alcătuită dintr-o singură comandă. Fișierele serverului le obțineți prin downloaderul oficial Hytale sau din propria instalare a jocului:

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

La prima pornire, serverul creează config.json, directorul logs/ și directorul lumii universe/. După aceea îl autentificați o singură dată la contul lui, pentru ca autentificarea jucătorilor să funcționeze. Asta se face printr-un cod de dispozitiv în consola serverului:

/auth login device
/auth status

Nu puneți -Xmx pe toată memoria de lucru a mașinii. Sistemul de operare, cache-ul de sistem de fișiere și consumul mediului de rulare Java din afara heapului au nevoie de asemenea de spațiu, iar un server care intră sub sarcină în memoria de swap arată pentru jucătorii dumneavoastră exact ca un atac.

4. Listă albă, parolă de server și limită de jucători împotriva epuizării sloturilor

Epuizarea sloturilor este cel mai ieftin atac asupra unui server de comunitate și nu are nevoie de lățime de bandă. Cine stabilește suficiente conexiuni simultane ocupă toate locurile și blochează astfel afară comunitatea propriu-zisă, fără să cumpere un singur gigabit. Hytale are pentru asta, spre deosebire de alte jocuri, uneltele potrivite în starea de livrare: o listă albă în whitelist.json, o listă de interdicții în bans.json, drepturi în permissions.json și în config.json cheile Password și MaxPlayers.

{
  "ServerName": "Serverul meu Hytale",
  "MOTD": "",
  "Password": "o valoare pe care o cunoaste doar grupul dumneavoastra",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password este gol din fabrică, deci oricine are adresa și portul intră. Pentru un server închis, o parolă setată este măsura individuală cea mai eficientă împotriva epuizării sloturilor, pentru un server public este lista albă în timpul unui val de atacuri. Și un lucru trebuie să fie clar: o parolă de server vă protejează locurile, nu conexiunea. Un atacator care vă inundă serverul nu vrea deloc să intre.

Editați aceste fișiere doar cu serverul oprit. Procesul de server care rulează își ține propria stare în memorie și poate suprascrie fără comentarii, la închidere, modificările pe care le scrieți în fișier în acest timp. Pentru modificări în timpul funcționării folosiți comenzile din consolă în locul editorului.

5. Lăsați autentificarea pe valoarea implicită

Modul standard cere de la fiecare jucător un cont Hytale valabil. Asta este mai mult decât o verificare de licență: este un filtru de acces care face conturile în masă scumpe. Un atacator care vrea să ocupe locuri are nevoie pentru asta de conturi valabile, iar acestea costă bani. Nu scoateți acest filtru.

Documentația din comunitate descrie, pe lângă standard, două moduri suplimentare, pentru medii private și pentru dezvoltare, cu care se poate intra fără verificarea contului. Pentru un server public ele sunt cea mai proastă setare posibilă, deoarece transformă epuizarea sloturilor de la o chestiune de bani la o chestiune de script. Dacă comutați pentru testare, atunci pe o mașină care nu stă în internet, și comutați înapoi după aceea.

6. Limitați încercările noi de conectare, și anume cu regula celor 1200 de octeți

Acum avantajul structural al QUIC devine practic. O stabilire de conexiune valabilă ajunge, potrivit RFC 9000, ca datagramă de cel puțin 1200 de octeți. Traficul de joc curent este vizibil mai mic. Cu urmărirea conexiunilor puteți deosebi de aceea fluxurile de date noi de cele existente și elimina tot ce este nou și prea mic. Cu nftables, încărcat prin nft -f:

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
    }
}

Prima regulă lucrează pe lungimea UDP, deci 8 octeți de antet plus 1200 de octeți de sarcină utilă, împreună 1208. Ea lovește exclusiv pachetele care vor să deschidă un flux de date nou și care sunt prea mici pentru asta, și nu poate lovi jucătorii conectați. A doua regulă limitează câte conexiuni noi are voie să deschidă o singură adresă sursă pe secundă. Cinci pe secundă sunt generoase: un jucător real stabilește o conexiune și o păstrează. Prioritatea -10 face ca ambele reguli să acționeze înaintea lanțului de filtrare al UFW.

O limită superioară pentru rata de pachete pe fiecare adresă sursă, pe portul de joc însuși, este a treia regulă rezonabilă, și aici este valabil în mod expres: valoarea numerică este o valoare de pornire, nu un adevăr.

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ăsurați mai întâi o săptămână în regim normal, apoi puneți limita pe dublul valorii de vârf măsurate. Pentru Hytale nu există pentru asta nicio cifră de referință publicată, iar valorile atârnă puternic de numărul de jucători și de raza de vizibilitate. Cine setează prea strâns își dă afară propriii jucători, și anume mai întâi pe cei cu cea mai proastă conexiune.

Regulile iptables pure sunt pierdute după o repornire. Sub Debian și Ubuntu le salvați așa:

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

Sub UFW, asemenea reguli se pun suplimentar în /etc/ufw/before.rules, deoarece altfel dispar la următorul ufw reload. Dacă o regulă este în general atinsă arată iptables -L INPUT -n -v: dacă rămân contoarele de potriviri la zero, ea nu acționează.

7. Setați corect urmărirea conexiunilor din kernel

Acest punct explică întreruperi care arată ca un atac volumetric, dar nu sunt. Kernelul creează pentru traficul UDP intrări în urmărirea conexiunilor, iar la adrese de expeditor falsificate fiecare adresă înseamnă o intrare nouă. Dacă tabelul este plin, kernelul elimină pachete fără deosebire, atacul și jucătorii dumneavoastră zboară afară împreună, iar în jurnal scrie „nf_conntrack: table full”. Starea și limita superioară le arată:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

La majoritatea jocurilor, cel mai bun răspuns la asta este să nu lăsați traficul de joc să fie urmărit deloc. La Hytale aceasta este o cântărire reală, deoarece regula celor 1200 de octeți din pasul 6 are nevoie de urmărirea conexiunilor. Fără ea, filtrul nu știe care pachet deschide un flux de date nou. Recomandarea este de aceea: păstrați urmărirea, măriți tabelul, țineți scurtă depășirea de timp pentru UDP. Un supliment sub /etc/sysctl.d/, activat cu sysctl --system:

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

Cine vrea totuși să dezactiveze urmărirea, de exemplu pe o mașină cu foarte mulți jucători simultani, pune udp dport 5520 notrack în tabelul raw și renunță astfel la regula celor 1200 de octeți. Amândouă împreună nu merg. Pentru un singur server Hytale, regula valorează mai mult decât intrările de tabel economisite.

Dacă pachetele ajung mai repede decât le ridică procesul Java, se revarsă în plus bufferul de recepție. Pentru jucători asta arată ca pierdere de pachete, deși conexiunea este liberă. Dacă setările de buffer de mai sus sunt necesare o dezvăluie kernelul însuși: dacă UdpRcvbufErrors crește în nstat -az, atunci ele acționează. Dacă rămâne contorul la zero, ajustarea nu schimbă nimic.

8. Alegeți raza de vizibilitate și numărul de jucători potrivit conexiunii

Acest pas nu este o măsură de securitate, el decide însă cât atac suportați în general. Hypixel Studios a formulat-o clar în cerințele oficiale de hardware din 1 decembrie 2025: dacă dublați raza de vizibilitate, împătriți cantitatea de lume din jurul jucătorului. Recomandarea oficială se află la cel mult 12 chunkuri, adică 384 de blocuri, setată prin MaxViewRadius. Pe partea clientului, aceleași cerințe indică 2 Mbit/s ca minim și 8 Mbit/s ca recomandare pe fiecare jucător pentru jocul în mai mulți.

Faceți o dată socoteala pentru serverul dumneavoastră. Un server cu 40 de jucători la o rază de vizibilitate generoasă mișcă în regim normal un domeniu de megabiți de trei cifre, spre limita de jos. Aceasta este valoarea de care trebuie să se măsoare conexiunea dumneavoastră, și este totodată valoarea pe care un atac trebuie să o depășească pentru a ieși în evidență. Cine umple o conexiune de 1 Gbit/s la o treime în regim normal are mai puțină rezervă decât cineva care se află la cinci la sută. O rază de vizibilitate mai mică nu este de aceea doar o chestiune de performanță, ci și o chestiune de robustețe.

9. Țineți sub observație modurile, pluginurile și schimbările de protocol

Hytale este moddabil pe partea serverului: modurile se află ca .zip sau .jar în directorul mods/, iar pluginurile adresează direct interfața serverului. Asta este comod, deoarece jucătorii nu trebuie să instaleze nimic, și este totodată un risc de disponibilitate care nu are nimic de-a face cu atacurile. Un plugin care lucrează costisitor la fiecare eveniment de rețea este un amplificator în propria dumneavoastră casă.

La asta se adaugă schimbarea protocolului. Cu Update 6, protocolul de rețea s-a schimbat, potrivit Patch Notes oficiale din 27 august 2026, de la hytale/2 la hytale/3, iar serverul și pluginurile trebuie construite din nou înainte să se conecteze. Pentru disponibilitate asta înseamnă: țineți o listă a modurilor dumneavoastră împreună cu versiunea, verificați-le înaintea fiecărui update pe o a doua instanță și planificați înainte de 12 octombrie 2026 o fereastră de mentenanță. Un server care nu pornește după un update nu poate fi deosebit de un atac pentru jucătorii dumneavoastră.

10. Adunați valori măsurate înainte să devină serios

Cel mai important pas este acela pe care aproape nimeni nu îl face dinainte: crearea unei baze de comparație cât timp totul merge normal. Fără o valoare normală nu puteți spune, după un incident, dacă 40.000 de pachete pe secundă au fost mult sau a fost pur și simplu sâmbătă seara. Cu apt-get install -y vnstat sysstat conntrack măsurarea rulează permanent în fundal. În timpul unui incident ajung cinci comenzi:

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"

La tcpdump este valabil: limitați întotdeauna cu -c, o captură sub sarcină maximă solicită suplimentar un server oricum suprasolicitat. Deoarece serverul Hytale rulează pe Java, aveți nevoie de o a doua probă, care exclude cea mai frecventă alarmă falsă. O pauză a colectorului de memorie arată pentru jucători exact ca un atac: toți stau în același timp, după aceea merge mai departe. Diferența stă în cifre.

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

Interpretarea este simplă. Dacă pachetele de intrare cresc mult peste valoarea normală, în timp ce procesul Java abia lucrează, este un atac. Dacă rata de pachete rămâne fără nimic ieșit din comun, în timp ce heapul se umple sau jurnalul arată pauze lungi, este sarcină. Cum interpretați în detaliu valorile de rețea scrie în Recunoașterea unui atac DDoS pe server.

11. Backup, plan de revenire și o rulare de probă înainte de termenul mare

Un concept de protecție care nu a fost niciodată testat este o presupunere. Înaintea unui termen precum 12 octombrie 2026, patru lucruri trebuie rezolvate: un backup al directorului universe/ împreună cu config.json, care se află în afara mașinii, o revenire verificată la versiunea anterioară a serverului, o a doua instanță pe care instalați update-ul mai întâi și un test la sarcină unic, care declanșează propriile dumneavoastră reguli de filtrare.

Testul la sarcină este punctul în care majoritatea operatorilor se opresc, și este cel mai important. Nu verificați dacă regulile dumneavoastră resping atacuri, ci dacă lasă să treacă proprii dumneavoastră jucători. Pentru asta este suficient să observați contoarele de potriviri în timp ce douăzeci de jucători reali intră simultan. Dacă contoarele regulilor de eliminare cresc în acest timp, limita dumneavoastră este setată prea strâns, și ați fi aflat asta în ziua update-ului, în cele mai proaste condiții.

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

Acum partea pe care niciun fișier de configurare 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 server de joc obișnuit atârnă la 1 Gbit/s, asta corespunde cu 125 de megaocteți pe secundă, iar conexiunea este plină de îndată ce cineva trimite mai mult. Atacurile împotriva proiectelor cu servere de joc se află de obicei între 5 și 50 Gbit/s, deci de la de cinci până la de cincizeci de ori conexiunea dumneavoastră. Dacă regula dumneavoastră nftables din spate este bună nu mai joacă atunci niciun rol, deoarece pachetele jucătorilor dumneavoastră nu mai trec nici înainte de asta.

A doua mărime este rata de pachete, și ea lovește adesea mai devreme decât lățimea de bandă. La pachete mici de 64 de octeți, într-o conexiune de 1 Gbit/s încap în jur de 1,49 milioane de pachete pe secundă. Un kernel de server obișnuit prelucrează, în funcție de procesor și de placa de rețea, câteva sute de mii dintre ele, înainte să înceapă să elimine. Un atac care nu umple nici măcar o treime din conexiunea dumneavoastră vă poate deci totuși paraliza serverul, deoarece timpul de calcul se consumă pe eliminare. Operatorii trăiesc asta ca „încărcarea nici nu era mare, și totuși totul a dispărut”.

La Hytale se adaugă o a treia mărime, care la majoritatea jocurilor nu există: timpul de calcul pentru stabilirea conexiunii. Un val de încercări de conectare valabile dintr-un botnet nu umple nicio conexiune și nu produce nicio rată de pachete ieșită din comun, el ocupă procesorul cu criptografie. Asemenea atacuri sunt invizibile în statistica lățimii de bandă și clare în încărcarea procesorului dată de procesul Java, iar împotriva lor nu ajută nici o limitare de rată pe fiecare adresă sursă, nici un buffer de recepție mai mare, dacă sursele sunt suficient de numeroase.

Pentru încadrarea ordinelor de mărime care apar în realitate: pe serverele KernelHost au fost filtrate, printre altele, un atac cu peste 473,4 Gbit/s la peste 41,5 milioane de pachete pe secundă asupra unui server de voce și un flood UDP cu peste 112,2 Gbit/s asupra unui server de joc. Pentru asta nu există nicio setare locală. Atacurile volumetrice trebuie să se termine în rețeaua din fața serverului.

Ce opune KernelHost atacurilor DDoS asupra serverelor Hytale

Protecția permanentă, inclusă în fiecare pachet de 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ă la centrul de date.
• Nivelul 2: filtrare Arbor în timp real cu 3,2 Tbps la Frankfurt pe Main. Direct în fața serverului sunt recunoscute și eliminate modelele specifice fiecărui protocol, 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 lipsește. Și nu se folosește nullrouting: adresa dumneavoastră IP rămâne în rețea, eliminate sunt doar pachetele dăunătoare. Cine scoate adresa IP din rețea obține pentru dumneavoastră același rezultat ca atacatorul. Ce titluri și protocoale sunt acoperite cu profile de protecție proprii le enumeră Protecție DDoS în timp real pentru servere de joc.

Advanced DDoS Protection pentru proiectele Hytale atacate permanent

Unele proiecte nu sunt atacate ocazional, ci țintit și săptămâni la rând, iar la un joc în Early Access asta lovește în special serverele care tocmai cresc. 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 propria noastră rețea. De partea dumneavoastră nu este nevoie de nicio modificare.
• Reguli de protecție administrabile de dumneavoastră, pe fiecare port și protocol în panoul clientului: stabiliți ce este permis pe 5520 UDP, separat de tot restul, și nu aveți nevoie pentru asta de niciun tichet.
• Modificările se aplică în timp real, deci puteți ajusta în timpul unui atac în curs, de exemplu limita mai dur pentru scurt timp conexiunile noi și lăsa neatins traficul de joc curent.
• Set de reguli potrivit protocolului, pentru QUIC peste UDP la fel ca pentru aplicații proprii pe orice porturi TCP sau UDP.

Advanced DDoS Protection se adresează serverelor care stau la KernelHost. Cine operează momentan proiectul lui Hytale în altă parte și este atacat permanent îl mută pentru asta la KernelHost, atunci ambele niveluri acționează de la livrare.

Cele două niveluri în comparație

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

Ce se poate transfera de la alte jocuri la Hytale

Deoarece Hytale este încă tânăr și nu există cifre publice despre atacurile asupra serverelor Hytale, calea cea mai rapidă către cunoștințe de încredere este privirea către jocuri comparabile. Transferabil nu este la asta numărul portului, ci modelul.

• Lansarea explozivă și ce declanșează ea: Palworld arată cum se suprapun în timp un val de jucători noi și un val de atacuri și de ce devin țintă tocmai serverele care cresc.
• Diferența dintre interogare și traficul de joc: Minecraft Bedrock explică pe exemplul Unconnected Ping cum funcționează amplificarea prin UDP. Exact această cale de atac Hytale nu o are, datorită QUIC, și pe ea se înțelege cel mai bine diferența.
• Stabilirea conexiunii ca țintă de atac: Protecție DDoS și protecție Nullping pentru Minecraft descrie valurile de handshake, care se descurcă aproape fără nicio lățime de bandă. Aceasta este cea mai apropiată rudă a valului de conexiuni QUIC.
• Numere mici de jucători și epuizarea sloturilor: Project Zomboid și Conan Exiles arată cât de puțin efort este necesar pentru a bloca afară un grup fix și ce rol joacă la asta lista albă și parola.
• Funcționarea sub sarcină permanentă: Terraria arată cum reacționează la atacuri un singur proces de server cu sarcină pe un singur nucleu. Serverul Hytale este un proces Java, problema de bază este comparabilă.

Greșeli frecvente la serverele Hytale și soluția lor

„Am deschis portul 5520 TCP și jucătorii totuși nu intră”: Traficul de joc rulează prin QUIC, deci prin UDP. O deschidere TCP nu aduce nimic pentru traficul de joc. Deschideți 5520 UDP și verificați din exterior cu nmap -Pn -sU -p 5520. Dacă ați pus serverul cu --bind pe un alt port, deschiderea trebuie să numească acel port.

„Serverul rulează, dar nimeni nu poate intra, iar în jurnal nu scrie nimic despre atacuri”: Verificați autentificarea serverului la contul lui cu /auth status. Un server a cărui autentificare a expirat rulează mai departe și totuși respinge jucătorii. Aceasta nu este o problemă de rețea și nu este o regulă de filtrare.

„După update nu mai pornește nimic”: Acesta nu este un atac, ci schimbarea protocolului. Cu Update 6, protocolul de rețea s-a schimbat de la hytale/2 la hytale/3, iar serverul, precum și pluginurile, au nevoie de o construcție nouă. Instalați update-urile mai întâi pe o a doua instanță, înainte să le lăsați pe serverul de producție.

„Toți jucătorii stau în același timp două secunde, apoi merge mai departe”: Aceasta este cu mare probabilitate colectarea de memorie a mediului de rulare Java și nu un atac. Verificați jcmd ... GC.heap_info și jurnalul serverului. Dacă sar -n DEV 1 10 rămâne la asta fără nimic ieșit din comun, nu a fost niciun atac în joc, ci un heap prea strâns dimensionat sau o rază de vizibilitate prea mare.

„Regula mea împotriva pachetelor mici a blocat jucătorii afară”: Atunci condiția celor 1200 de octeți stă în lanț fără ct state new. Traficul de joc curent este compus majoritar din pachete mici, iar o condiție de lungime fără verificarea stării lovește exact acestea. Condiția este valabilă exclusiv pentru fluxurile de date nou deschise.

„Am schimbat adresa IP și două ore mai târziu eram din nou offline”: Atacatorul are adresa nouă din aceeași sursă ca pe cea veche. La Hytale acestea sunt de obicei o intrare A veche în DNS, un bot de Discord cu afișarea stării sau o intrare în una dintre multele liste de servere ale unor terți. De la Update 6, adresele serverelor din lista oficială de servere sunt ascunse din fabrică, ceea ce închide calea cea mai comodă, dar nu pe toate. O schimbare de adresă este câștig de timp, nu o soluție.

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

„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ă 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 ieșit din comun”: Dacă traficul este filtrat deja în rețeaua din față, pe server nu ajunge nimic, așa cum este de așteptat. Acesta este cazul normal la o filtrare care funcționează. Invers este valabil: dacă conexiunea este saturată, este posibil să nu vă mai ajungă nici măcar sesiunea SSH cu care voiați să măsurați. Folosiți atunci consola VNC din panoul clientului, care funcționează independent de rețeaua sistemului oaspete.

Pe scurt

• Un server Hytale are nevoie de exact un port deschis: 5520 UDP pentru QUIC. TCP nu este necesar pentru traficul de joc, iar în documentația publică nu este descris niciun alt port pentru interogări, RCON sau comandă la distanță.
• Deoarece QUIC are voie, potrivit RFC 9000, să trimită înainte de verificarea adresei cel mult tripla cantitate de octeți recepționată și deoarece o primă încercare de conectare trebuie să aibă cel puțin 1200 de octeți, un server Hytale este ca amplificator de reflexie practic neinteresant. Asta îl deosebește de serverele cu interogare Steam sau cu Unconnected Ping Bedrock.
• Aceeași regulă a celor 1200 de octeți este cea mai bună regulă locală de filtrare: ce vrea să deschidă un flux de date nou pe 5520 UDP și este mai mic nu poate fi o stabilire de conexiune valabilă și se poate elimina fără să lovească jucătorii conectați.
• Partea costisitoare a unei stabiliri QUIC este criptografia, nu lățimea de bandă. Un val de încercări de conectare valabile este invizibil în statistica lățimii de bandă și se vede doar în încărcarea procesorului și în contoarele pentru conexiuni noi.
• Modul standard cu obligativitatea contului este un filtru de acces care face conturile în masă scumpe. Pentru un server public el rămâne neatins, la asta se adaugă whitelist.json, bans.json și o valoare setată în Password împotriva epuizării sloturilor.
• Măsurile locale se termină la conexiune: 1 Gbit/s înseamnă 125 de megaocteți pe secundă, iar la pachete de 64 de octeți încap acolo în jur de 1,49 milioane de pachete pe secundă. Tot ce este peste trebuie să se termine în rețeaua din fața serverului.
• Hytale este din 13 ianuarie 2026 în Early Access, Chapter 1 este anunțat pentru 12 octombrie 2026. Termenele mari sunt termene de atac, iar protecția comandată la termen vine prea târziu.
• La KernelHost, protecția permanentă pe două niveluri este inclusă în fiecare pachet de server fără cost suplimentar și este activă de la livrare, fără nullrouting. Advanced DDoS Protection cu IP de protecție dedicat și cu reguli administrabile de dumneavoastră pe fiecare port începe de la 50,00 € pe lună.

Dacă serverul dumneavoastră Hytale rulează deja la KernelHost, filtrarea este activă fără să fie nevoie să faceți ceva. Dacă observați totuși lucruri ieșite din comun, deschideți un tichet de suport, pentru ca regulile de filtrare pentru adresa dumneavoastră IP să fie ajustate. În cazul unui atac în curs ne găsiți în plus prin chatul de urgență WhatsApp la +43 650 8209883.

Acest articol are stadiul de la 27 septembrie 2026. Hytale este în Early Access, iar protocolul de rețea s-a schimbat deja o dată în acest an. El va fi continuat după Chapter 1 și după fiecare update care privește stabilirea conexiunii, porturile sau lista de servere.