Proteggere un server Minecraft Bedrock dagli attacchi DDoS

Un server Minecraft Bedrock che la sera sparisce per qualche minuto dalla lista server e poi ricompare raramente ha un problema hardware. Nella maggior parte dei casi è in corso un attacco, e per giunta proprio quando è collegato il maggior numero di giocatori. Questo articolo mostra come proteggere un server Minecraft Bedrock dagli attacchi DDoS: prima quello che puoi mettere in sicurezza da solo senza costi aggiuntivi, poi il punto in cui queste misure si fermano dal punto di vista fisico e infine che cosa deve succedere nella rete, prima del server.

Tutte le indicazioni si riferiscono a un Bedrock Dedicated Server, a PocketMine-MP o a Nukkit su Debian 12, Debian 13, Ubuntu 22.04 LTS o Ubuntu 24.04 LTS. I comandi sono scritti per root; se lavori come utente normale, anteponi sudo. Chi gestisce la Java Edition trova gli attacchi di protocollo tipici di quella versione in Protezione DDoS e protezione Nullping per Minecraft. La sola installazione di un server Bedrock è descritta in Installare un server Minecraft Bedrock con Nukkit.

Se l'attacco è in corso proprio adesso: non modificare nulla nella configurazione e non riavviare il server. Metti prima al sicuro i valori misurati (paragrafo "Raccogliere i dati prima che scoppi"), perché dopo l'attacco sono persi per sempre.

Perché i server Minecraft Bedrock sono così spesso bersaglio di attacchi DDoS

La Bedrock Edition è la versione che gira su console, smartphone, tablet e Windows, ed è quella che raccoglie la base di giocatori più grande di tutto Minecraft. Dove ci sono molti server nasce il massimo incentivo per gli attacchi: network concorrenti, giocatori bannati, litigi interni. Un attacco non costa a chi lo lancia né competenze né soldi degni di nota, e un server booter si vende in abbonamento.

Il motivo tecnico sta più in profondità. Un server Bedrock parla UDP, non TCP, e risponde a chiunque chieda, molto prima che sia avvenuto un qualsiasi accesso. Sono esattamente queste due caratteristiche a fare della porta 19132 UDP un bersaglio comodo. Che cosa sia in generale un attacco DDoS lo spiega l'articolo Che cos'è un attacco DDoS?.

RakNet: un protocollo UDP che risponde prima che qualcuno abbia effettuato l'accesso

RakNet è la libreria di rete UDP attraverso cui la Minecraft Bedrock Edition gestisce tutto il suo traffico di gioco. UDP non prevede alcuna apertura di connessione che un server possa pretendere, e gli indirizzi mittente si possono quindi falsificare. RakNet costruisce sopra il proprio livello di affidabilità: numeri di sequenza, conferme (ACK) e conferme negative (NAK), con cui un client può richiedere di nuovo i pacchetti persi.

L'apertura della connessione è fatta di sette pacchetti, quattro dal client e tre dal 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

Solo dopo il client invia il pacchetto di login con le sue credenziali Xbox Live. Questa è la frase decisiva per chiunque voglia mettere in sicurezza il proprio server Bedrock: il server ha elaborato sette pacchetti, ha speso tempo di calcolo e memoria e ha risposto più volte, prima ancora di sapere chi stia bussando. Ogni misura che agisce sull'accesso entra quindi in gioco solo dopo che il carico si è già prodotto.

A questo si aggiunge un secondo punto di ingresso, ancora più precoce. Perché un server compaia nella lista server di un giocatore con nome, versione e numero di giocatori, esso risponde all'Unconnected Ping (ID pacchetto 0x01) con un Unconnected Pong (ID pacchetto 0x1C). Questo scambio avviene prima della vera apertura della connessione, non richiede alcuna credenziale e sul Bedrock Dedicated Server non si può disattivare senza togliere il server da ogni lista server.

L'Unconnected Ping come vettore di amplificazione: i numeri

Un attacco di amplificazione è un attacco in cui chi attacca invia piccole richieste con indirizzo mittente falsificato a server di terzi, affinché le loro risposte, più grandi, finiscano sulla vittima. Il server Bedrock non viene attaccato, viene usato. Per l'Unconnected Ping il conto è questo:

Da qui discendono subito due cose. Primo: un nome del server lungo ingrandisce la risposta e con essa il fattore di amplificazione che metti a disposizione di aggressori altrui. Un nome corto non è cosmetica, è una misura di protezione. Secondo: il fattore 4 della configurazione predefinita è abbastanza piccolo da lasciare il tuo server poco interessante come riflettore, ma abbastanza grande perché un flood di ping carichi la tua linea in uscita con il quadruplo di quello che entra.

Il bug di amplificazione del 2024 mostra quanto possa peggiorare la situazione quando viene abusato il livello di affidabilità stesso. Nella libreria RakNet allora in uso il pacchetto Connection Request Accepted era contrassegnato come affidabile. Chi attaccava poteva svolgere l'apertura della connessione con indirizzo mittente falsificato fino a questo punto e poi inviare una singola conferma negativa con l'intervallo da 0 a 8191. Il server spediva di conseguenza migliaia di pacchetti all'indirizzo falsificato, senza che l'aggressore dovesse fare altro. La correzione è arrivata portando il pacchetto a non affidabile, facendo inviare in Open Connection Reply 1 un cookie che un client reale rimanda indietro, e introducendo limiti di pacchetti: 120 pacchetti per indirizzo sorgente e ciclo di 10 millisecondi, 1.000 pacchetti complessivi per ciclo.

Bedrock Edition o Java Edition: che cosa cambia nella protezione DDoS

Chi ha già messo in sicurezza un server Java trasferisce quasi tutto in modo sbagliato. Le due edizioni condividono il nome, ma non il protocollo di rete:

La riga sui SYN cookie è la più importante. Nella Java Edition il kernel Linux respinge un SYN flood senza che il processo Minecraft se ne accorga. Nella Bedrock Edition questo aiuto non esiste: ogni singolo pacchetto UDP viene passato fino al processo del server e lì valutato. Un server Bedrock non ha alcuna protezione integrata nel sistema operativo contro un flood sulla porta 19132, perché UDP non ne prevede nessuna.

La riga sul record SRV mancante ha una conseguenza pratica che sorprende molti: nella Bedrock Edition non puoi nascondere la porta dietro un record DNS. I giocatori inseriscono indirizzo e porta a mano. Chi sposta la porta deve comunicare la nuova porta a ogni giocatore.

Le porte di cui si tratta davvero

Un Bedrock Dedicated Server si lega a esattamente due porte, e su entrambe via UDP. Nel file 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

Queste sono le impostazioni predefinite di Microsoft, consultabili nella documentazione di riferimento del Bedrock Dedicated Server. Intorno a queste due porte ne stanno altre, a seconda del software server in uso:

La terza e la quarta riga sono gli errori evitabili più frequenti sui server Bedrock. In Nukkit e PocketMine-MP enable-query è attivo di serie, e in Nukkit un RCON acceso per sbaglio finisce sulla 19132 TCP, cioè sullo stesso numero di porta del gioco. Chi guarda soltanto "la 19132 è aperta, tutto a posto" non se ne accorge.

Anche una particolarità del Bedrock Dedicated Server ufficiale va messa qui: non conosce la direttiva server-ip. PocketMine-MP e Nukkit ce l'hanno (server-ip, in PocketMine anche server-ipv6), il server ufficiale no. Resta quindi sempre in ascolto su tutti gli indirizzi del sistema, e la firewall è la tua unica possibilità di limitarlo.

Che cosa puoi fare da solo prima di spendere

Questa è la sezione più lunga, e non per caso. Un server Bedrock configurato bene regge con le proprie forze gli attacchi piccoli e medi, a prescindere da chi lo ospita.

1. Inventario: che cosa è in ascolto sulla 19132?

Prima di scrivere anche una sola regola, guarda che cosa offre il tuo server verso l'esterno. Non tirare a indovinare, controlla:

ss -lntup
ss -lnup sport = :19132

La colonna interessante è quella dell'indirizzo locale. 0.0.0.0:19132 e [::]:19133 significano "raggiungibile da tutta internet". Se accanto compare una voce TCP sullo stesso numero di porta, è in funzione RCON. Il punto di vista di chi attacca te lo dà una scansione delle porte dall'esterno, per UDP con -sU:

nmap -Pn -sU -p 19132,19133 IP.DEL.TUO.SERVER
nmap -Pn -p- --min-rate 1000 IP.DEL.TUO.SERVER

2. Lasciare aperta solo la 19132 UDP e chiudere tutto il resto

A un server Bedrock basta una sola apertura verso l'esterno, due con IPv6. Con UFW la cosa si presenta così, e proprio in questo ordine, per non restare chiuso fuori dal tuo server:

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

Se non hai giocatori IPv6, lascia perdere la riga per la 19133 e in PocketMine-MP imposta in più enable-ipv6=false. Ogni porta che non apri è una porta che non devi difendere. La guida completa, via di fuga compresa, è in Configurare il firewall UFW senza bloccarsi fuori.

3. Disattivare la visibilità LAN, altrimenti la 19132 resta aperta

Questa è la trappola in cui cade quasi chiunque voglia spostare la porta. La direttiva enable-lan-visibility è impostata di serie su true e fa in modo che il server risponda alle richieste di ricerca nella rete locale. Microsoft scrive esplicitamente che così il server si lega in più alle porte predefinite 19132 e 19133, anche quando server-port e server-portv6 hanno altri valori.

Chi sposta quindi la porta sulla 19140 e si sente al sicuro resta comunque in ascolto sulla 19132. Per un server su internet nel file server.properties ci vuole perciò:

enable-lan-visibility=false

Dopodiché verifica con ss -lnup che la 19132 sia davvero sparita. Di passaggio, la stessa impostazione risolve il problema di due server Bedrock sullo stesso host che si rubano la porta a vicenda.

4. Disattivare query e RCON

PocketMine-MP e Nukkit portano con sé la query GS4, un'interrogazione UDP del server sul modello del protocollo UT3, e rispondono a queste interrogazioni sulla stessa porta 19132 su cui gira il gioco. La risposta estesa contiene il nome del server, la versione, il nome del mondo, lo stato della whitelist, indirizzo e porta, il numero di giocatori, i nomi di tutti i giocatori collegati e, in PocketMine-MP, a richiesta l'elenco completo dei plugin. È comodo per le pagine di stato e per i bot Discord, ma rivela a chi attacca esattamente quando conviene colpire, e ogni interrogazione costa tempo di calcolo.

enable-query=off
enable-rcon=off

In PocketMine-MP i valori sono false invece di off, e l'elenco dei plugin lo disattivi nel file pocketmine.yml con settings.query-plugins: false. Una precisazione che si legge di rado: la query GS4 di PocketMine-MP verifica un token che viene salato con l'indirizzo mittente. La risposta grande non si può quindi riflettere verso un indirizzo falsificato. L'interrogazione costa comunque tempo di calcolo, e i dati pubblicati aiutano chi attacca a scegliere il bersaglio. Il Bedrock Dedicated Server ufficiale non conosce né query né RCON, lì questo punto non si pone.

Se ti serve davvero RCON, in Nukkit imposta assolutamente rcon.port su un valore proprio e aprilo solo per il tuo indirizzo. Il ripiego su server-port significa altrimenti che un controllo remoto del tuo server resta in ascolto sulla 19132 TCP, cioè sullo stesso numero che hai comunque segnato ovunque come "aperto".

5. Imporre l'autenticazione Xbox Live

L'autenticazione Xbox Live è la verifica che un giocatore in ingresso possieda un account reale, firmato da Microsoft. In tutti e tre i software server è attiva di serie e lì deve anche restare.

Nel Bedrock Dedicated Server la direttiva si chiama online-mode, in PocketMine-MP e Nukkit si chiama xbox-auth. In entrambi i casi true è lo stato di fabbrica e il valore giusto:

online-mode=true
xbox-auth=true

Microsoft formula in proposito una limitazione importante: i client che si collegano a un server fuori dalla rete locale hanno comunque sempre bisogno dell'autenticazione Xbox Live, a prescindere da questa impostazione. La credenziale viene trasmessa come catena di token firmati nel pacchetto di login, insieme all'identificativo Xbox (XUID) e al nome visualizzato.

E adesso la parte che evita i fraintendimenti: l'autenticazione Xbox Live protegge la tua logica di gioco, non la tua linea. Avviene nel pacchetto di login, quindi dopo la completa apertura della connessione RakNet. Chi inonda il tuo server non ha alcuna intenzione di entrare. I suoi pacchetti vengono rifiutati, ma sono comunque arrivati, ed è esattamente questo il punto.

6. Allowlist e limite di giocatori, e che cosa non riescono a fare

L'allowlist (un tempo whitelist) è l'elenco dei giocatori che possono entrare. Nel Bedrock Dedicated Server la attivi con allow-list=true, le voci stanno nel file allowlist.json con nome, XUID e il campo ignoresPlayerLimit. In Nukkit e PocketMine-MP la direttiva si chiama ancora white-list.

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

Un tempo di inattività breve impostato con player-idle-timeout è efficace contro l'esaurimento degli slot: i giocatori che occupano solo un posto vengono espulsi dopo il numero di minuti indicato. Il valore 0 significa che nessuno viene mai disconnesso per inattività, ed è esattamente quello che sfrutta chi blocca i tuoi posti con account reali.

Vale anche qui il limite del paragrafo precedente, ed è il punto più spesso trascurato in assoluto: l'allowlist viene verificata solo quando il pacchetto di login è stato elaborato. Impedisce gli ingressi, non i pacchetti.

7. Limitare le frequenze dei pacchetti per indirizzo sorgente

Contro gli attacchi piccoli e i bot fatti male aiuta un limite massimo per indirizzo sorgente. Per UDP si lavora con hashlimit e non con connlimit, perché UDP non conosce connessioni:

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

La regola scarta i pacchetti UDP non appena lo stesso indirizzo sorgente invia stabilmente più di 400 pacchetti al secondo. Il valore è un punto di partenza, non una verità assoluta: un server pieno con 60 giocatori e grande distanza di visuale produce molti più pacchetti di uno vuoto, e chi stringe troppo butta fuori i propri giocatori. Misura prima una settimana di funzionamento normale.

Puoi stringere molto di più sull'Unconnected Ping, perché un client reale interroga lo stato del server solo finché la lista server è aperta, e lo fa con cadenza di un secondo. Con nftables si riesce a colpire esattamente questo singolo pacchetto, perché l'ID del pacchetto è il primo byte dopo l'intestazione 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

L'espressione @th,64,8 legge otto bit a partire dal 64esimo bit dell'intestazione di trasporto, cioè il primo byte del payload UDP. Il valore 0x01 è l'ID pacchetto dell'Unconnected Ping. Lo stesso punto lo puoi usare per osservare, prima di scartare qualsiasi cosa:

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

La prima riga conta le interrogazioni di stato in ingresso, la seconda le tue risposte. Se entrambe salgono a migliaia al secondo mentre non gioca quasi nessuno, quello che vedi è un flood di ping e non i tuoi giocatori.

Due avvertenze sulla durata. Le semplici regole iptables spariscono dopo un riavvio; su Debian e Ubuntu si salvano così:

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

Con UFW, invece, regole di questo tipo vanno in /etc/ufw/before.rules, altrimenti al prossimo ufw reload spariscono.

8. Alleggerire il tracciamento delle connessioni del kernel

Un collo di bottiglia che con i giochi UDP colpisce molto prima che con TCP: il kernel crea una voce nel tracciamento delle connessioni per ogni coppia di pacchetti UDP. In un flood con indirizzi mittente falsificati ogni pacchetto è un nuovo indirizzo sorgente e quindi una nuova voce. Se la tabella si riempie, il server scarta anche i pacchetti legittimi e nel log compare "nf_conntrack: table full, dropping packet".

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Se il contatore resta stabilmente vicino al limite massimo, puoi escludere il traffico di gioco dal tracciamento. È efficace, ma non senza conseguenze, quindi in entrambe le direzioni e con una prova di connessione subito dopo:

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

Da quel momento le regole basate sullo stato non valgono più per questo traffico. La tua apertura per la 19132 UDP deve quindi essere una vera apertura di porta e non può appoggiarsi allo stato ESTABLISHED. Dopo averle impostate, verifica con conntrack -L | grep 19132 che non nascano più voci, e collegati una volta con il gioco prima di salvare le regole in modo permanente.

9. Gestire Geyser e Floodgate in modo pulito

Geyser è un ponte che permette ai client Bedrock di giocare su un server Java Edition: accetta connessioni Bedrock sulla 19132 UDP, traduce il protocollo e dall'altra parte parla con il server Java sulla 25565 TCP. Floodgate è il complemento che consente a questi giocatori Bedrock di entrare senza un account Java. Per la protezione DDoS questo significa tre cose.

Primo: tieni Geyser aggiornato. Proprio questo ponte è stato due volte all'origine di attacchi documentati. Nel marzo 2024 il bug di amplificazione descritto sopra, nella libreria RakNet, è stato sfruttato su larga scala, corretto a partire dalla build 478. Nel luglio 2025 è seguito un secondo caso: un pacchetto di conferma dei pacchetti risorse, inviato ripetutamente, generava più sessioni per giocatore, e i client disconnessi potevano continuare a inviare pacchetti perché il canale di rete non veniva chiuso. Corretto a partire dalla build 897. Entrambi i casi sono stati pubblicati dal progetto stesso, con tanto di cronologia.

Secondo: il server Java non va sulla rete aperta. Nella configurazione di Geyser remote.address punta su auto ossia 127.0.0.1 e remote.port sulla 25565. Lega quindi il server Java in locale e non aprire la 25565 TCP verso l'esterno. Altrimenti hai due superfici di attacco invece di una, e la seconda è quella per cui non hai mai pensato a delle regole.

Terzo: il file key.pem è un segreto. È la chiave con cui Floodgate salta l'autenticazione Java per gli account Bedrock. Chi la mette in un repository pubblico, la copia in un ticket di supporto o la mostra in uno screenshot ha regalato l'accesso al proprio server. Il progetto mette in guardia esplicitamente.

10. Raccogliere i dati prima che scoppi

Il passo più importante è quello che quasi nessuno compie in anticipo: creare una base di confronto mentre tutto funziona normalmente. Senza un valore di riferimento, dopo un incidente non puoi dire se 40.000 pacchetti al secondo fossero tanti oppure semplicemente un sabato sera. Con apt-get install -y vnstat sysstat conntrack la misurazione resta sempre attiva.

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

Tre di questi valori sono particolarmente significativi su un server Bedrock. Un Recv-Q stabilmente diverso da zero sul socket UDP della 19132 significa che il processo del server non ritira più abbastanza in fretta i pacchetti in arrivo. UdpRcvbufErrors conta esattamente i pacchetti scartati per questo motivo ed è la prova più solida che il collo di bottiglia non è la linea, ma il processo. UdpNoPorts sale quando qualcuno bombarda porte su cui non è in ascolto nulla, un quadro tipico di una scansione delle porte ad ampio raggio prima dell'attacco vero e proprio.

Per tcpdump vale una regola: limita sempre con -c, perché una cattura a pieno carico appesantisce ancora di più un server già sovraccarico. Come interpretare i valori lo trovi in Riconoscere un attacco DDoS.

Dove queste misure si fermano: banda e frequenza dei pacchetti

Adesso la parte che nessun file di configurazione può risolvere. Tutte le misure viste finora girano sul tuo server, quindi all'estremità della linea. Una regola firewall decide di un pacchetto che ha già percorso il cavo. Puoi scartarlo, ma non puoi fare in modo che non sia mai stato spedito.

Fai due conti. La tua linea è satura non appena qualcuno spedisce più di 125 megabyte al secondo. Un attacco da 5 a 50 Gbit/s sta da cinque a cinquanta volte sopra. A quel punto non conta più se la tua regola hashlimit dietro sia buona, perché i pacchetti dei tuoi giocatori si fermano già prima.

La seconda grandezza è la frequenza dei pacchetti, e su un server Bedrock colpisce quasi sempre per prima. Tutto il traffico di gioco è fatto di molti piccoli pacchetti UDP, ed è proprio in questa disciplina che chi attacca spende meno. Un attacco che non riempie nemmeno un terzo della tua linea può comunque mettere fuori gioco il tuo server, perché il tempo di calcolo se ne va nel valutare e nello scartare. Chi gestisce un server lo vive così: "l'utilizzo non era nemmeno alto, eppure erano tutti fuori". Nel gioco la stessa cosa si manifesta come picchi di lag, effetti rubber banding e cadute di connessione mentre si sta costruendo.

Per tutto questo non esiste alcuna impostazione locale. Gli attacchi volumetrici devono finire nella rete, prima del server.

Che cosa mette KernelHost contro gli attacchi DDoS ai server Bedrock

La protezione permanente inclusa su ogni server

La protezione DDoS di KernelHost è costruita su due livelli ed è permanentemente attiva, senza che tu debba attivare, ordinare o configurare nulla:

• Livello 1: 17 Tbps di capacità di mitigazione nella rete di scrubbing globale. Gli attacchi volumetrici vengono ripuliti vicino alla loro origine, prima che raggiungano il datacenter.
• Livello 2: filtraggio Arbor in tempo reale da 3,2 Tbps a Francoforte sul Meno. Subito davanti al server vengono riconosciuti e scartati gli schemi specifici di protocollo, pacchetto per pacchetto. Ne fanno parte anche gli schemi UDP sulla 19132 che non mostrano un comportamento RakNet.

Due caratteristiche sono decisive. La protezione è sempre attiva e non deve prima reagire a un attacco, quindi non ci sono minuti iniziali in cui il server sparisce. E non viene usato il null-routing: il tuo indirizzo IP resta in rete e vengono scartati solo i pacchetti dannosi. Chi toglie l'indirizzo IP dalla rete ottiene per te lo stesso risultato di chi attacca. Il sito è Francoforte sul Meno. Quali giochi e protocolli siano coperti lo elenca Protezione DDoS per game server in tempo reale.

Advanced DDoS Protection per progetti sotto attacco continuo

Certi progetti non vengono colpiti ogni tanto, ma in modo mirato e per settimane. Per questi casi c'è la Advanced DDoS Protection a partire da 50,00 € al mese, PrePaid e senza durata minima. La differenza non sta in una capacità maggiore, ma nel controllo:

• IP di protezione dedicato dal core di Francoforte, sul quale il tuo server viene spostato all'interno della nostra rete. Dalla tua parte non serve alcuna modifica.
• Regole di protezione gestibili da te per porta e protocollo nell'area clienti: imposti che cosa è permesso sulla 19132 UDP, che cosa sulla 19133 UDP e che cosa su una porta diversa, se hai spostato il tuo server.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro durante un attacco in corso invece di aspettare una finestra di manutenzione.
• Profilo di protezione adatto al singolo gioco. Per Minecraft esistono profili già pronti, così come per applicazioni modificate e proprie su porte TCP o UDP a piacere, quindi anche per Nukkit, PocketMine-MP o un'istanza Geyser su una porta scelta da te.

I due livelli a confronto

Per la maggior parte dei progetti Bedrock basta la protezione permanente inclusa, insieme a una configurazione pulita del server. La Advanced DDoS Protection è la risposta al caso in cui qualcuno se la prenda sul personale. Chi al momento gestisce il proprio server altrove risolve il problema soprattutto con un trasferimento: il filtraggio agisce nella rete davanti al server, e quella rete deve essere nostra.

Errori frequenti e soluzioni

"Ho cambiato la porta in 19140, ma la 19132 è comunque aperta": è enable-lan-visibility=true. Il Bedrock Dedicated Server si lega allora in più alla 19132 e alla 19133, qualunque cosa ci sia in server-port. Imposta su false, riavvia il server e verifica con ss -lnup.

"Ho modificato allowlist.json e adesso non entro più nemmeno io": due cause sono frequenti. Nella cartella c'è ancora un vecchio whitelist.json che il server legge al suo posto, oppure la voce XUID manca o è sbagliata. Con l'autenticazione Xbox Live attiva il solo nome non basta in modo affidabile.

"Il mio hoster ha bloccato il mio server anche se l'attaccato ero io": verifica se il tuo server abbia a sua volta spedito pacchetti. È esattamente quello che è successo con il bug di amplificazione RakNet del 2024: i server coinvolti inviavano migliaia di pacchetti a indirizzi altrui, e nelle segnalazioni di abuso compariva la porta 19132 come sorgente. Con tcpdump -ni eth0 'udp src port 19132' -c 200 -q vedi dove risponde il tuo server. Una build aggiornata elimina la causa.

"Le mie regole iptables non funzionano": tre cause sono frequenti. Le regole stanno dopo le catene di UFW e non vengono mai raggiunte, oppure sono sparite con l'ultimo riavvio (allora servono netfilter-persistent save o una voce in /etc/ufw/before.rules), oppure l'attacco è volumetrico e la regola lavora correttamente su una linea che è già satura. Verifica con iptables -L INPUT -n -v se i contatori dei match salgono. Se restano a zero, la regola non viene raggiunta.

"Il server compare nella lista, ma non entra nessuno": se la voce mostra nome e numero di giocatori, l'Unconnected Pong funziona, quindi la porta è in linea di principio raggiungibile. Se l'ingresso fallisce comunque, dipende quasi sempre dall'accesso Xbox Live o dall'allowlist. Se invece non entrano solo i giocatori IPv6, manca l'apertura per la 19133 UDP.

"Il server gira, ma tutti hanno picchi di lag": più spesso si tratta di un plugin che di un attacco. Guarda prima se Recv-Q cresce sul socket UDP e se UdpRcvbufErrors sale. Se entrambi restano tranquilli e sar -n DEV 1 10 non mostra nulla di strano, non era un attacco DDoS, ma il processo del server stesso. Nel Bedrock Dedicated Server aiutano allora i watchdog degli script, le cui soglie stanno nel file server.properties sotto script-watchdog-hang-threshold e script-watchdog-slow-threshold.

"Il mio provider precedente ha bloccato il mio indirizzo IP": quello è null-routing. Il provider protegge così la propria rete, mentre per te il risultato è identico a un attacco riuscito, di solito ancora per ore dopo. Nel dubbio chiedi se filtrano oppure se fanno null-routing. La risposta decide della tua disponibilità più di qualsiasi dato sull'hardware.

"In tcpdump non vedo nulla di anomalo": se il traffico viene già filtrato nella rete a monte, sul server come previsto non arriva nulla. È la situazione normale quando il filtraggio funziona. Vale però anche il contrario: se la linea è satura, può darsi che non ti raggiunga nemmeno la sessione SSH con cui volevi misurare. In quel caso usa la console VNC nell'area clienti, che funziona indipendentemente dalla rete del sistema ospite.

In breve

• Un server Minecraft Bedrock ha bisogno di esattamente una porta aperta verso l'esterno: 19132 UDP, più la 19133 UDP solo per i giocatori IPv6. Query, RCON, il debugger degli script sulla 19144 TCP e un server Java dietro Geyser sulla 25565 TCP non vanno sulla rete aperta.
• Chi sposta la porta deve impostare enable-lan-visibility=false, altrimenti il Bedrock Dedicated Server resta legato anche alla 19132 e alla 19133.
• Autenticazione Xbox Live e allowlist agiscono solo nel pacchetto di login, quindi dopo la completa apertura della connessione RakNet. Proteggono la tua logica di gioco e i tuoi posti, non la tua linea.
• L'Unconnected Ping viene richiesto con 33 byte e ricevuto indietro con circa 131 byte, un fattore di amplificazione di circa quattro. Un nome del server corto tiene basso questo fattore.
• Con UDP serve hashlimit al posto di connlimit, e con indirizzi mittente falsificati il tracciamento delle connessioni del kernel è il primo a riempirsi. Entrambe le cose andrebbero misurate prima del primo attacco.
• Da circa 1 Gbit/s la tua linea è satura, e con pacchetti da 64 byte lì dentro entrano circa 1,49 milioni di pacchetti al secondo. Oltre quella soglia decide esclusivamente il filtraggio nella rete davanti al server.
• Su KernelHost la protezione permanente a due livelli è inclusa in ogni pacchetto server, attiva dal momento della consegna e senza null-routing. La Advanced DDoS Protection la completa con un IP di protezione dedicato e regole per porta gestibili da te.

Se il tuo progetto gira già su KernelHost, il filtraggio è attivo senza che tu debba fare nulla. Se noti comunque delle anomalie, apri un ticket di supporto, così le regole di filtraggio per il tuo indirizzo IP vengono affinate. Durante un attacco in corso ci raggiungi anche tramite la chat WhatsApp di emergenza al numero +43 650 8209883.