Protejarea unui server Minecraft Bedrock împotriva atacurilor DDoS

Un server de Minecraft Bedrock care seara dispare câteva minute din lista de servere și apoi revine are rar o problemă de hardware. De regulă rulează un atac, și el rulează exact atunci când sunt online cei mai mulți jucători. Acest articol arată cum protejați un server de Minecraft Bedrock împotriva atacurilor DDoS: mai întâi ce puteți securiza singur, fără costuri suplimentare, apoi locul în care aceste măsuri se opresc fizic și, la final, ce trebuie să se întâmple în rețeaua din fața serverului.

Toate informațiile se referă la un Bedrock Dedicated Server, la PocketMine-MP sau la Nukkit 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ță. Cine folosește Java Edition găsește atacurile de protocol tipice acolo în Protecție DDoS și protecție Nullping pentru Minecraft. Instalarea propriu-zisă a unui server Bedrock este descrisă în Instalarea unui server Minecraft Bedrock cu Nukkit.

Dacă atacul este în desfășurare chiar acum: nu modificați nimic în configurație și nu reporniți serverul. Salvați mai întâi valorile măsurate (secțiunea „Colectați măsurători înainte de prima lovitură”), după atac ele sunt pierdute definitiv.

De ce serverele de Minecraft Bedrock sunt atât de des ținta atacurilor DDoS

Bedrock Edition este versiunea care rulează pe console, pe telefoane, pe tablete și pe Windows, și reprezintă cea mai mare bază de jucători din Minecraft. Unde există multe servere apare și cel mai mare stimulent pentru atacuri: rețele concurente, jucători banați, conflicte interne. Un atac nu îl costă pe cel care îl declanșează nici pricepere, nici bani demni de menționat, un server booter se vinde pe abonament.

Motivul tehnic se află mai adânc. Un server Bedrock vorbește UDP, nu TCP, și răspunde oricui întreabă, cu mult timp înainte să aibă loc vreo autentificare. Exact aceste două proprietăți fac din portul 19132 UDP o țintă comodă. Ce este, în principiu, un atac DDoS explică articolul Ce este un atac DDoS?.

RakNet: un protocol UDP care răspunde înainte ca cineva să se fi autentificat

RakNet este biblioteca de rețea UDP prin care Minecraft Bedrock Edition derulează tot traficul de joc. UDP nu cunoaște o stabilire de conexiune pe care un server ar putea să o pretindă, iar adresele sursă se pot de aceea falsifica. RakNet construiește deasupra propriul strat de fiabilitate: numere de secvență, confirmări (ACK) și confirmări negative (NAK), cu care un client poate cere din nou pachetele pierdute.

Stabilirea conexiunii constă din șapte pachete, patru de la client și trei de la server:

Client  -> Server   Open Connection Request 1
Server  -> Client   Open Connection Reply 1
Client  -> Server   Open Connection Request 2
Server  -> Client   Open Connection Reply 2
Client  -> Server   Connection Request
Server  -> Client   Connection Request Accepted
Client  -> Server   New Incoming Connection

Abia după aceea clientul trimite pachetul de login cu acreditările sale Xbox Live. Aceasta este propoziția decisivă pentru oricine vrea să își securizeze serverul Bedrock: serverul a procesat șapte pachete, a consumat timp de calcul și memorie și a răspuns de mai multe ori, înainte să afle măcar cine bate la ușă. Orice măsură care acționează la autentificare intră deci în vigoare abia după ce încărcarea a apărut deja.

La asta se adaugă un al doilea punct de intrare, încă mai timpuriu. Pentru ca un server să apară în lista de servere a unui jucător cu nume, versiune și număr de jucători, el răspunde la Unconnected Ping (ID de pachet 0x01) cu un Unconnected Pong (ID de pachet 0x1C). Acest schimb are loc înainte de stabilirea propriu-zisă a conexiunii, nu pretinde niciun fel de dovadă și nu poate fi dezactivat la Bedrock Dedicated Server fără să scoateți serverul din orice listă de servere.

Unconnected Ping ca vector de amplificare: cifrele

Un atac de amplificare (amplification) este un atac în care atacatorul trimite cereri mici cu adresă sursă falsificată către servere străine, pentru ca răspunsurile mai mari ale acestora să ajungă la victimă. Serverul Bedrock nu este atacat în acest caz, ci folosit. La Unconnected Ping, calculul arată astfel:

Din asta rezultă imediat două lucruri. În primul rând: un nume de server lung mărește răspunsul și, cu el, factorul de amplificare pe care îl puneți la dispoziția atacatorilor străini. Un nume scurt nu este cosmetică, ci o măsură de protecție. În al doilea rând: factorul 4 al configurației standard este suficient de mic pentru ca serverul dumneavoastră să rămână neinteresant ca reflector, dar suficient de mare pentru ca un flood de ping să încarce propria conexiune de ieșire cu de patru ori ce intră.

Eroarea de amplificare din 2024 arată cât de rău poate deveni când stratul de fiabilitate însuși este abuzat. În biblioteca RakNet folosită atunci, pachetul Connection Request Accepted era marcat ca fiabil. Un atacator putea derula stabilirea conexiunii cu adresă sursă falsificată până în acest punct și apoi trimitea o singură confirmare negativă cu intervalul 0 până la 8191. Serverul trimitea în consecință mii de pachete către adresa falsificată, fără ca atacatorul să mai facă altceva. Remedierea a constat în trecerea pachetului pe nefiabil, în trimiterea în Open Connection Reply 1 a unui cookie pe care un client real îl reflectă înapoi și în introducerea unor limite de pachete: 120 de pachete per adresă sursă la fiecare 10 milisecunde, 1.000 de pachete în total pe interval.

Bedrock Edition sau Java Edition: ce este diferit la protecția DDoS

Cine a securizat deja un server Java transferă aproape totul greșit. Cele două ediții împart numele, dar nu protocolul de rețea:

Linia despre SYN-cookies este cea mai importantă. La Java Edition, kernelul Linux respinge un flood de SYN fără ca procesul Minecraft să observe ceva. La Bedrock Edition acest ajutor nu există: fiecare pachet UDP în parte este transmis până în procesul serverului și evaluat acolo. Un server Bedrock nu are, împotriva unui flood pe portul 19132, nicio protecție integrată în sistemul de operare, pentru că UDP nu cunoaște niciuna.

Linia despre înregistrarea SRV lipsă are o consecință practică ce surprinde pe mulți: la Bedrock Edition nu puteți ascunde portul în spatele unei înregistrări DNS. Jucătorii introduc adresa și portul manual. Cine mută portul trebuie să comunice fiecărui jucător noul port.

Porturile despre care este vorba în realitate

Un Bedrock Dedicated Server se leagă la exact două porturi, și anume pe ambele prin UDP. În server.properties:

server-port=19132
server-portv6=19133
enable-lan-visibility=true
online-mode=true
allow-list=false
max-players=10
player-idle-timeout=30
max-threads=8

Acestea sunt valorile implicite de la Microsoft, de citit în referința pentru Bedrock Dedicated Server. În jurul acestor două porturi se află alte servicii care rulează în paralel, în funcție de software-ul de server:

A treia și a patra linie sunt cele mai frecvente greșeli evitabile pe serverele Bedrock. La Nukkit și PocketMine-MP, enable-query este activat din fabrică, iar la Nukkit un RCON pornit din greșeală ajunge pe 19132 TCP, adică pe același număr de port ca jocul. Cine se uită doar după „19132 este deschis, e în regulă” trece asta cu vederea.

O particularitate a Bedrock Dedicated Server oficial aparține de asemenea aici: el nu cunoaște directiva server-ip. PocketMine-MP și Nukkit o au (server-ip, la PocketMine în plus server-ipv6), serverul oficial nu. El ascultă deci mereu pe toate adresele sistemului, iar firewallul este singura dumneavoastră posibilitate de a limita asta.

Ce puteți face singur, înainte de a da bani

Această secțiune este cea mai lungă, și asta intenționat. Un server Bedrock configurat curat rezistă singur atacurilor mici și medii, indiferent la cine este găzduit.

1. Inventar: ce ascultă, de fapt, pe 19132?

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

ss -lntup
ss -lnup sport = :19132

Interesantă este coloana cu adresa locală. 0.0.0.0:19132 și [::]:19133 înseamnă „accesibil din tot internetul”. Dacă apare lângă ele o intrare TCP pe același număr de port, rulează RCON. Perspectiva atacatorului o oferă o scanare de porturi din exterior, pentru UDP cu -sU:

nmap -Pn -sU -p 19132,19133 ADRESA.IP.A.SERVERULUI
nmap -Pn -p- --min-rate 1000 ADRESA.IP.A.SERVERULUI

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

Pentru un server Bedrock este suficientă o singură deschidere către exterior, două cu IPv6. Cu UFW asta arată astfel, și anume exact în această ordine, ca să nu vă blocați singur accesul:

ufw allow 22/tcp comment 'SSH'
ufw allow 19132/udp comment 'Bedrock IPv4'
ufw allow 19133/udp comment 'Bedrock IPv6'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Dacă nu aveți jucători pe IPv6, omiteți linia pentru 19133 și puneți la PocketMine-MP în plus enable-ipv6=false. Fiecare port pe care nu îl deschideți este un port pe care nu trebuie să îl apărați. Ghidul complet, inclusiv calea de salvare, se află în Configurarea firewallului UFW fără să vă blocați singur accesul.

3. Dezactivați vizibilitatea LAN, altfel 19132 rămâne deschis

Aceasta este capcana în care cade aproape oricine vrea să mute portul. Directiva enable-lan-visibility este din fabrică pe true și face ca serverul să răspundă la cererile de căutare din rețeaua locală. Microsoft scrie explicit despre asta că serverul se leagă în plus la porturile standard 19132 și 19133, chiar dacă server-port și server-portv6 au alte valori.

Cine mută deci portul pe 19140 și se crede în siguranță ascultă în continuare pe 19132. Pentru un server din internet, în server.properties aparține deci:

enable-lan-visibility=false

După aceea verificați cu ss -lnup că 19132 a dispărut într-adevăr. Pe lângă asta, aceeași setare rezolvă problema că două servere Bedrock pe aceeași mașină își iau portul unul altuia.

4. Dezactivați Query și RCON

PocketMine-MP și Nukkit aduc cu ele query GS4, o interogare de server pe UDP după modelul protocolului UT3, și răspund la aceste interogări pe același port 19132 pe care rulează jocul. Răspunsul detaliat conține numele serverului, versiunea, numele lumii, starea listei albe, adresa și portul, numărul de jucători, numele tuturor jucătorilor conectați și, la PocketMine-MP, la cerere, lista completă de plugin-uri. Asta este practic pentru pagini de status și boți de Discord, dar dezvăluie unui atacator exact când merită un atac și costă timp de calcul la fiecare interogare.

enable-query=off
enable-rcon=off

La PocketMine-MP valorile sunt false în loc de off, iar lista de plugin-uri o dezactivați în pocketmine.yml cu settings.query-plugins: false. O încadrare care se citește rar: query-ul GS4 de la PocketMine-MP verifică un token care include un salt derivat din adresa sursă. Răspunsul mare nu se poate deci reflecta către o adresă falsificată. Interogarea costă totuși timp de calcul, iar datele publicate îl ajută pe atacator la alegerea țintei. Bedrock Dedicated Server oficial nu cunoaște nici Query, nici RCON, acolo acest punct dispare.

Dacă aveți într-adevăr nevoie de RCON, puneți la Nukkit obligatoriu rcon.port pe o valoare proprie și deschideți-l numai pentru adresa dumneavoastră. Revenirea la server-port înseamnă altfel că un control la distanță al serverului dumneavoastră ascultă pe 19132 TCP, adică pe același număr pe care l-ați notat oricum peste tot ca „deschis”.

5. Impuneți autentificarea Xbox Live

Autentificarea Xbox Live este verificarea dacă un jucător care intră deține un cont real, semnat de Microsoft. Ea este activată din fabrică în toate cele trei software-uri de server și trebuie să rămână acolo.

La Bedrock Dedicated Server directiva se numește online-mode, la PocketMine-MP și Nukkit se numește xbox-auth. În ambele cazuri true este starea din fabrică și valoarea corectă:

online-mode=true
xbox-auth=true

Microsoft formulează în acest context o limitare importantă: clienții care se conectează la un server din afara rețelei locale au nevoie oricum întotdeauna de autentificarea Xbox Live, independent de această setare. Dovada este transmisă ca lanț de token-uri semnat în pachetul de login, împreună cu identificatorul Xbox (XUID) și cu numele afișat.

Și acum partea care ajută împotriva neînțelegerilor: autentificarea Xbox Live protejează logica jocului dumneavoastră, nu conexiunea dumneavoastră. Ea are loc în pachetul de login, deci după stabilirea completă a conexiunii RakNet. Un atacator care vă inundă serverul nu vrea deloc să intre. Pachetele lui sunt respinse, dar au ajuns totuși, și exact acesta este punctul.

6. Allowlist și limita de jucători, și ce nu pot ele face

Allowlist (fosta listă albă) este lista jucătorilor care au voie să intre. La Bedrock Dedicated Server o activați cu allow-list=true, intrările se află în allowlist.json cu nume, XUID și câmpul ignoresPlayerLimit. La Nukkit și PocketMine-MP directiva se numește în continuare white-list.

allow-list=true
max-players=60
player-idle-timeout=15

Un timp de inactivitate scurt prin player-idle-timeout este eficient împotriva epuizării sloturilor: jucătorii care doar ocupă un loc sunt dați afară după numărul de minute indicat. Valoarea 0 înseamnă că nimeni nu este deconectat vreodată din cauza inactivității, și exact asta exploatează un atacator care vă blochează locurile cu conturi reale.

Și aici este valabilă limita din secțiunea precedentă, iar ea este punctul cel mai des trecut cu vederea: allowlist este verificată abia când pachetul de login a fost procesat. Ea împiedică intrări, nu pachete.

7. Limitați rata de pachete per adresă sursă

Împotriva atacurilor mici și a boților neglijenți ajută o limită superioară per adresă sursă. Pentru UDP se lucrează cu hashlimit, nu cu connlimit, pentru că UDP nu cunoaște conexiuni:

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

Regula elimină pachetele UDP în momentul în care aceeași adresă sursă trimite constant mai mult de 400 de pachete pe secundă. Valoarea este o valoare de start, nu un adevăr: un server plin, cu 60 de jucători și distanță mare de vizibilitate, generează sensibil mai multe pachete decât unul gol, iar cine reglează prea strâns își dă afară propriii jucători. Măsurați mai întâi o săptămână în funcționare normală.

Sensibil mai strict aveți voie să reglați la Unconnected Ping, pentru că un client real interoghează starea serverului doar cât timp lista de servere este deschisă, și atunci o dată pe secundă. Cu nftables se poate ținti exact acest singur pachet, pentru că ID-ul de pachet este primul octet după antetul UDP:

nft add table inet bedrock
nft add chain inet bedrock prerouting '{ type filter hook prerouting priority -150 ; policy accept ; }'
nft add rule inet bedrock prerouting udp dport 19132 @th,64,8 0x01 limit rate over 500/second drop

Expresia @th,64,8 citește opt biți începând cu bitul 64 al antetului de transport, adică primul octet al sarcinii utile UDP. Valoarea 0x01 este ID-ul de pachet al Unconnected Ping. Același loc îl puteți folosi pentru observare, înainte să eliminați ceva:

tcpdump -ni eth0 'udp dst port 19132 and udp[8] = 0x01' -c 200 -q
tcpdump -ni eth0 'udp src port 19132 and udp[8] = 0x1c' -c 200 -q

Prima linie numără interogările de stare care intră, a doua răspunsurile dumneavoastră. Dacă amândouă ajung, secundă de secundă, la mii, în timp ce aproape nimeni nu joacă, vedeți un flood de ping și nu jucătorii dumneavoastră.

Două observații despre durabilitate. Regulile iptables simple dispar după o repornire, pe Debian și Ubuntu se salvează astfel:

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

Iar sub UFW, astfel de reguli aparțin în /etc/ufw/before.rules, pentru că altfel dispar la următorul ufw reload.

8. Degrevați urmărirea conexiunilor din kernel

Un punct critic care lovește la jocurile pe UDP mult mai devreme decât la TCP: kernelul creează pentru fiecare pereche de pachete UDP o intrare în urmărirea conexiunilor. La un flood cu adrese sursă falsificate, fiecare pachet este o adresă sursă nouă și deci o intrare nouă. Dacă tabela se umple, serverul elimină și pachete legitime, iar în jurnal apare „nf_conntrack: table full, dropping packet”.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Dacă valoarea contorului stă constant aproape de limita superioară, puteți scoate traficul de joc din urmărire. Asta este eficient, dar nu fără consecințe, de aceea în ambele direcții și cu un test de conexiune după:

iptables -t raw -I PREROUTING -p udp --dport 19132 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 19132 -j NOTRACK

După aceea, regulile bazate pe stare nu se mai aplică acestui trafic. Deschiderea dumneavoastră pentru 19132 UDP trebuie deci să fie o deschidere reală de port și nu are voie să se bazeze pe starea ESTABLISHED. Verificați după setare, cu conntrack -L | grep 19132, că nu mai apar intrări, și conectați-vă o dată cu jocul înainte să salvați regulile permanent.

9. Operați curat Geyser și Floodgate

Geyser este o punte care permite clienților Bedrock să joace pe un server Java Edition: acceptă conexiuni Bedrock pe 19132 UDP, traduce protocolul și vorbește pe cealaltă parte cu serverul Java pe 25565 TCP. Floodgate este completarea care permite acestor jucători Bedrock să intre fără cont Java. Pentru protecția DDoS asta înseamnă trei lucruri.

În primul rând: țineți Geyser la zi. Exact această punte a fost de două ori motivul unor atacuri documentate. În martie 2024, eroarea de amplificare descrisă mai sus din biblioteca RakNet a fost exploatată pe scară largă, remediată începând cu build 478. În iulie 2025 a urmat un al doilea caz: un pachet trimis repetat pentru confirmarea pachetelor de resurse crea mai multe sesiuni per jucător, iar clienții deconectați puteau trimite pachete în continuare, pentru că canalul de rețea nu era închis. Remediat începând cu build 897. Ambele cazuri au fost publicate de proiect însuși, cu cronologie.

În al doilea rând: serverul Java nu are ce căuta în internetul deschis. În configurația Geyser, remote.address indică auto, respectiv 127.0.0.1, iar remote.port indică 25565. Legați serverul Java local în consecință și nu deschideți 25565 TCP către exterior. Altfel aveți două suprafețe de atac în loc de una, iar a doua este exact cea pentru care nu v-ați gândit niciodată la reguli.

În al treilea rând: fișierul key.pem este un secret. El este cheia cu care Floodgate sare peste autentificarea Java pentru conturile Bedrock. Cine îl pune într-un repository public, îl copiază într-un tichet de suport sau îl arată într-o captură de ecran a dăruit autentificarea serverului său. Proiectul avertizează explicit despre asta.

10. Colectați măsurători înainte de prima lovitură

Pasul cel mai important este cel pe care aproape nimeni nu îl face din timp: să creați o bază 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ă erau mult sau pur și simplu sâmbătă seara. Cu apt-get install -y vnstat sysstat conntrack măsurarea rulează permanent.

sar -n DEV 1 10
ip -s link show eth0
ss -lunp sport = :19132
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|UdpRcvbufErrors'
dmesg -T | tail -50

Trei dintre aceste valori sunt deosebit de concludente la un server Bedrock. Un Recv-Q constant diferit de zero pe socketul UDP de pe 19132 înseamnă că procesul serverului nu mai preia pachetele care sosesc suficient de repede. UdpRcvbufErrors numără exact pachetele care au fost eliminate din acest motiv și este dovada cea mai clară că nu conexiunea, ci procesul este punctul critic. UdpNoPorts crește atunci când cineva bombardează porturi pe care nu ascultă nimic, o imagine tipică la o scanare de porturi larg răspândită înaintea atacului propriu-zis.

La tcpdump este valabil: limitați întotdeauna cu -c, o captură sub sarcină maximă încarcă suplimentar un server deja suprasolicitat. Cum interpretați valorile scrie în Cum recunoașteți un atac DDoS.

Unde se termină aceste măsuri: lățime de bandă și rată de pachete

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

Faceți o dată calculul. Conexiunea dumneavoastră este plină imediat ce cineva trimite mai mult de 125 de megaocteți pe secundă. Un atac de 5 până la 50 Gbit/s este de cinci până la cincizeci de ori mai mult. Dacă regula dumneavoastră hashlimit din spate este bună nu mai are atunci nicio importanță, pentru că pachetele jucătorilor dumneavoastră nu mai trec încă mai înainte.

A doua mărime este rata de pachete, iar la un server Bedrock ea lovește aproape întotdeauna prima. Tot traficul de joc constă din multe pachete UDP mici, și exact în această disciplină un atacator este cel mai ieftin. Un atac care nu vă umple conexiunea nici pe o treime vă poate totuși paraliza serverul, pentru că timpul de calcul se duce pe evaluarea și eliminarea pachetelor. Operatorii trăiesc asta ca „încărcarea nu era deloc mare, și totuși toți erau afară”. În joc, același lucru se manifestă ca vârfuri de lag, efecte de elastic și întreruperi de conexiune în mijlocul construcției.

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 serverelor Bedrock

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ă trebuiască să porniț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 în Frankfurt pe Main. Direct în fața serverului sunt recunoscute și eliminate tiparele specifice protocolului, pachet cu pachet. Din ele fac parte și tiparele UDP pe 19132 care nu arată un comportament RakNet.

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, sunt eliminate doar pachetele dăunătoare. Cine scoate adresa IP din rețea obține pentru dumneavoastră același rezultat ca atacatorul. Locația este Frankfurt pe Main. Ce jocuri și protocoale sunt acoperite listează Protecție DDoS pentru servere de joc în timp real.

Advanced DDoS Protection pentru proiectele atacate constant

Unele proiecte nu sunt atacate ocazional, ci țintit și săptămâni la rând. Pentru asta există Advanced DDoS Protection, de la 50,00 EUR pe lună, PrePaid și fără durată minimă. 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 noastră. La dumneavoastră nu este nevoie de nicio modificare.
• Reguli de protecție administrabile de dumneavoastră, per port și protocol, în panoul clientului: stabiliți ce este permis pe 19132 UDP, ce pe 19133 UDP și ce pe un port diferit, dacă v-ați mutat serverul.
• Modificările intră în vigoare în timp real, deci puteți ajusta în timpul unui atac în desfășurare, în loc să așteptați o fereastră de mentenanță.
• Profil de protecție potrivit jocului respectiv. Pentru Minecraft există profiluri gata făcute, la fel și pentru aplicații modificate sau proprii pe orice porturi TCP sau UDP, deci și pentru Nukkit, PocketMine-MP sau o instanță Geyser pe un port ales de dumneavoastră.

Cele două niveluri în comparație

Pentru majoritatea proiectelor Bedrock este suficientă protecția permanentă inclusă, împreună cu o configurație de server curată. Advanced DDoS Protection este răspunsul la situația în care cineva o ia personal. Cine își operează serverul momentan în altă parte rezolvă problema cel mai bine printr-o mutare: filtrarea acționează în rețeaua din fața serverului, iar această rețea trebuie să fie a noastră.

Erori frecvente și soluții

„Am schimbat portul pe 19140, 19132 este totuși deschis”: aceasta este enable-lan-visibility=true. Bedrock Dedicated Server se leagă atunci în plus la 19132 și 19133, indiferent ce scrie în server-port. Puneți pe false, reporniți serverul, verificați cu ss -lnup.

„Am editat allowlist.json și acum nu mai intru nici eu”: două cauze sunt frecvente. Mai există în director un whitelist.json vechi, pe care serverul îl citește în locul celuilalt, sau intrarea XUID lipsește, respectiv este greșită. Numele singur nu este suficient de fiabil când autentificarea Xbox Live este activă.

„Furnizorul meu de hosting mi-a blocat serverul, deși eu eram cel atacat”: verificați dacă serverul dumneavoastră a trimis el însuși pachete. Exact asta s-a întâmplat la eroarea de amplificare RakNet din 2024: serverele afectate trimiteau mii de pachete către adrese străine, iar în raportările de abuz apărea portul 19132 ca sursă. Cu tcpdump -ni eth0 'udp src port 19132' -c 200 -q vedeți încotro răspunde serverul dumneavoastră. Un build actual elimină cauza.

„Regulile mele iptables nu se aplică”: trei cauze sunt frecvente. Regulile stau după lanțurile 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ă urcă contoarele de potriviri. Dacă rămân la zero, regula nu este atinsă.

„Serverul apare în listă, dar nimeni nu intră”: dacă intrarea afișează numele și numărul de jucători, Unconnected Pong funcționează, deci portul este în principiu accesibil. Dacă intrarea eșuează totuși, cauza este de obicei autentificarea Xbox Live sau allowlist. Dacă, invers, doar jucătorii pe IPv6 nu intră, lipsește deschiderea pentru 19133 UDP.

„Serverul merge, dar toți au vârfuri de lag”: asta este mai des un plugin decât un atac. Verificați mai întâi dacă Recv-Q crește pe socketul UDP și dacă UdpRcvbufErrors urcă. Dacă amândouă rămân liniștite și sar -n DEV 1 10 nu arată nimic ieșit din comun, nu a fost un atac DDoS, ci procesul serverului însuși. La Bedrock Dedicated Server ajută atunci mai departe watchdog-urile de script, ale căror praguri se află în server.properties la script-watchdog-hang-threshold și script-watchdog-slow-threshold.

„Furnizorul meu anterior 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 dacă se aplică nullrouting. Răspunsul decide mai mult despre disponibilitatea 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, previzibil, nimic. Acesta este cazul normal la o filtrare funcțională. 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 de Minecraft Bedrock are nevoie de exact un port deschis către exterior: 19132 UDP, la care se adaugă 19133 UDP doar pentru jucătorii pe IPv6. Query, RCON, depanatorul de scripturi de pe 19144 TCP și un server Java în spatele Geyser pe 25565 TCP nu au ce căuta în internetul deschis.
• Cine mută portul trebuie să pună enable-lan-visibility=false, altfel Bedrock Dedicated Server se leagă în plus, în continuare, la 19132 și 19133.
• Autentificarea Xbox Live și allowlist acționează abia în pachetul de login, deci după stabilirea completă a conexiunii RakNet. Ele protejează logica jocului și locurile dumneavoastră, nu conexiunea dumneavoastră.
• Unconnected Ping este cerut cu 33 de octeți și primește răspuns cu circa 131 de octeți, un factor de amplificare de circa patru. Un nume de server scurt ține acest factor mic.
• La UDP ajută hashlimit în loc de connlimit, iar urmărirea conexiunilor din kernel se umple prima la adrese sursă falsificate. Pe amândouă ar trebui să le fi măsurat înainte de primul atac.
• De la circa 1 Gbit/s conexiunea dumneavoastră este plină, iar la pachete de 64 de octeți încap acolo circa 1,49 milioane de pachete pe secundă. Peste asta decide exclusiv filtrarea în rețeaua din fața serverului.
• La KernelHost, protecția permanentă pe două niveluri este inclusă în fiecare pachet de server, activă de la livrare și fără nullrouting. Advanced DDoS Protection o completează cu un IP de protecție dedicat și cu reguli administrabile de dumneavoastră per port.

Dacă proiectul dumneavoastră rulează deja la KernelHost, filtrarea este activă fără să fie nevoie să faceți ceva. Dacă totuși observaț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 găsiți în plus prin chatul WhatsApp de urgență la +43 650 8209883.