Proteggere un server Hytale dagli attacchi DDoS

Un server Hytale che la sera, nel bel mezzo del gioco, perde tutte le connessioni nello stesso momento, resta irraggiungibile per qualche minuto e poi riparte da solo raramente ha un problema hardware. Di regola è in corso un attacco. Questo articolo mostra come proteggere un server Hytale dagli attacchi DDoS: prima quello che puoi configurare da solo senza spese aggiuntive, poi il punto in cui queste misure si fermano dal punto di vista tecnico e infine che cosa deve succedere nella rete, prima del server, perché il server resti raggiungibile.

Tutte le indicazioni si riferiscono al server dedicato ufficiale di Hypixel Studios, quindi a HytaleServer.jar insieme a Assets.zip sotto Java 25, su Debian 12, Debian 13, Ubuntu 22.04 LTS oppure Ubuntu 24.04 LTS. I comandi sono scritti per root; se lavori come utente normale, anteponi sudo. Hytale è in Early Access e si muove in fretta: per questo in questo articolo ogni affermazione sul gioco porta una data, e tutto ciò che non è ufficialmente documentato è contrassegnato espressamente come aspettativa oppure come fonte della comunità. Se l'attacco è in corso proprio adesso, vale inoltre un ordine preciso: prima misurare, poi cambiare. Un riavvio forzato sotto carico butta via tutto quello che nel mondo è accaduto dall'ultimo punto di salvataggio, e anche i valori misurati dell'incidente dopo sono persi.

Perché i server Hytale vengono messi fuori uso con attacchi DDoS mirati

Un server Hytale è un pubblico a un indirizzo fisso, e questo pubblico è sostituibile. Chi tre sere di fila non riesce a entrare nel suo server di riferimento se ne cerca un altro. È esattamente questo il modello di business dietro gli attacchi ai server delle comunità: non si tratta di dati e non si tratta di estorsione, ma di giocatori che se ne vanno. Un servizio booter che bersaglia un indirizzo per pochi euro al mese non richiede a chi lo commissiona né competenze né fatica, e il danno nasce di nuovo a ogni disservizio.

A questo si aggiunge in Hytale una particolarità: il codice del server è pubblico. Hypixel Studios ha annunciato nel giugno 2026 il programma Hytale Shared Source e attraverso di esso mette a disposizione su GitHub il codice completo del server, il protocollo di rete e gli asset, accessibili a chiunque abbia una licenza di gioco valida. Per chi gestisce un server è un guadagno, perché i plugin nascono su interfacce reali. Per il lato attaccante significa che il protocollo nessuno deve più indovinarlo. Chi vuole sapere in quale punto l'apertura della connessione costa tempo di calcolo può leggerselo. Che cosa succeda tecnicamente durante un attacco di questo tipo lo spiega l'articolo Che cos'è un attacco DDoS?.

La situazione di Hytale al 27 settembre 2026

Hytale è in Early Access dal 13 gennaio 2026, disponibile per Windows, macOS e Linux, e nei giorni dopo il lancio ha superato il milione di giocatori. La strada che ha portato fin lì è stata inconsueta, e spiega perché gli articoli più vecchi su Hytale spesso non siano più validi.

La conseguenza pratica di questa cronologia: un server Hytale di oggi non è un server di gennaio. Con l'Update 6 il protocollo di rete è passato da hytale/2 a hytale/3, e secondo le patch notes ufficiali del 27 agosto 2026 server e plugin devono essere ricompilati prima di potersi collegare. Chi pianifica la propria disponibilità non pianifica quindi soltanto contro gli attacchi, ma anche contro i cambi di protocollo.

Perché il 12 ottobre 2026 è la data critica

I grandi aggiornamenti di contenuto funzionano come un secondo lancio di vendita. Riportano i vecchi giocatori, ne attirano di nuovi, e per qualche giorno è la raggiungibilità a decidere quale server della comunità cresca da quell'ondata e quale la perda. Questo schema è documentato per altri giochi: Palworld ha raggiunto nel gennaio 2024 milioni di giocatori nel giro di pochi giorni, e i server della comunità di quella fase di lancio erano i più attaccati esattamente nel momento in cui avevano più da perdere. Il meccanismo che sta dietro è descritto in dettaglio in Proteggere i server Palworld dagli attacchi DDoS e si può trasferire uno a uno su Hytale.

Da qui deriva una verità scomoda sul calendario: una protezione ordinata il 12 ottobre arriva troppo tardi. Una linea, un IP di protezione, un set di regole per porta e un valore misurato del funzionamento normale hanno bisogno di tempo, perché senza dati di confronto non si possono impostare in modo sensato. Chi comincia due settimane prima di un grande aggiornamento ha tempo a sufficienza. Chi comincia il giorno dell'aggiornamento regola alla cieca.

Le porte di cui si tratta davvero su un server Hytale

Un server Hytale ha bisogno di esattamente una porta aperta: 5520 UDP. Il traffico di gioco passa da QUIC, quindi da UDP, e il TCP per il traffico di gioco non serve. Chi apre solo il TCP vede lo stesso quadro di un firewall chiuso: i giocatori finiscono in una scadenza dei tempi. Il collegamento predefinito è 0.0.0.0:5520, una porta diversa si imposta all'avvio con --bind.

Questa tabella è più corta che nella maggior parte degli altri giochi, ed è la differenza più importante. Un server Counter-Strike risponde alle interrogazioni di stato nel formato Steam A2S, un server Minecraft Bedrock risponde a un Unconnected Ping, un server Palworld tiene aperta una porta di query propria. Per Hytale nella documentazione pubblica, oltre alla 5520 UDP, non è descritta nessun'altra porta: nessuna porta di query, nessuna porta RCON, nessuna interfaccia REST allo stato di consegna. Tutto ciò che un server Hytale offre verso l'esterno sta su una sola porta UDP.

Un server Hytale in numeri

I valori che seguono sono la base per ogni decisione su regole di filtraggio e valori soglia. Ogni volta è indicata la provenienza, perché è quella a decidere quanto siano solidi.

Che cosa cambia QUIC nella superficie d'attacco

QUIC è un protocollo di trasporto che stabilisce connessioni protette su UDP e ha integrato in modo fisso l'instaurazione della cifratura secondo TLS 1.3. Non esiste QUIC non cifrato. Per chi gestisce un server questo significa due cose che si contraddicono, e sono importanti entrambe.

La prima è un miglioramento reale. Poiché UDP non impone alcuna apertura di connessione e gli indirizzi mittente si possono falsificare, i servizi UDP senza connessione sono gli amplificatori classici per gli attacchi a terzi. QUIC limita questo per standard. La RFC 9000 prescrive nella sezione 8.1 che un server, prima della verifica dell'indirizzo mittente, possa inviare al massimo il triplo della quantità di byte ricevuta, e la sezione 14.1 richiede che un client riempia il suo primo datagramma fino ad almeno 1200 byte. Insieme, queste due regole portano il fattore di amplificazione di un servizio QUIC al massimo a tre, mentre una porta di query Steam o un Unconnected Ping di Bedrock arrivano a un multiplo di quel valore. Un server Hytale che lavora correttamente è quindi praticamente inutile come amplificatore per la reflection. È un vantaggio strutturale rispetto a quasi tutti gli altri giochi con traffico UDP, e nel confronto con i server Minecraft Bedrock si nota con chiarezza.

La seconda è il prezzo di tutto questo. Un'apertura di connessione QUIC costa al server tempo di calcolo, perché comprende una negoziazione TLS 1.3 con crittografia asimmetrica. Un singolo pacchetto falsificato non può imporre un'apertura, ma una piena di veri tentativi di connessione da una botnet sì. Anche chi attacca paga tempo di calcolo, ed è esattamente questo rapporto a decidere: finché il server compie per ogni tentativo di connessione più lavoro di chi attacca, l'attacco è conveniente. Una piena di tentativi di connessione non carica quindi la linea, ma il processore, e nella statistica della banda non sembra niente. È lo stesso meccanismo che in Minecraft è conosciuto come Nullping e piena di handshake, ed è descritto in dettaglio nell'articolo Protezione DDoS per Minecraft e protezione Nullping.

Praticamente utilizzabile, di tutto questo, è soprattutto la regola dei 1200 byte. Un nuovo tentativo di connessione deve arrivare come datagramma di almeno 1200 byte, altrimenti secondo lo standard non è un'apertura di connessione valida. Il traffico di gioco corrente, invece, è composto in prevalenza da pacchetti piccoli. Questa distinzione si può trasformare in una regola di filtraggio, e ci arriviamo subito.

Che cosa di Hytale non è documentato pubblicamente

Questo elenco appartiene a un articolo onesto, perché stabilisce dove non ti puoi affidare ai numeri. Tutto quello che segue, al 27 settembre 2026, non è confermato ufficialmente:

• Se il server usi QUIC Retry per la verifica dell'indirizzo. La RFC 9000 consente nella sezione 8.1.2 un pacchetto Retry con token, con cui un server verifica l'indirizzo mittente prima di impegnare risorse. Se e da quale carico Hytale lo faccia non è documentato. Parti dal presupposto di non poterci contare.
• I valori predefiniti dei blocchi RateLimit e ConnectionTimeouts in config.json. Che entrambi i blocchi esistano è coerente su più fonti. I numeri indicati però si contraddicono: una fonte riporta valori soglia concreti, un'altra descrive i blocchi come presenti ma senza effetto. Per questo in questo articolo non compare nessuno di quei numeri, e per questo non dovresti mettere in conto quei blocchi come tua difesa.
• I nomi e i valori predefiniti delle modalità di autenticazione. La documentazione della comunità sul codice del server pubblicato descrive tre modalità, impostate tramite --auth-mode, con authenticated come predefinita e inoltre offline e insecure per ambienti privati e per lo sviluppo. Ufficialmente non è confermato. La regola che ne deriva è comunque chiara: per un server pubblico non cambiare la modalità.
• I dettagli dell'instaurazione TLS. La documentazione del protocollo della comunità, che si basa sul codice del server pubblicato, descrive un certificato reciproco, un certificato del server autofirmato e generato all'avvio, la cui impronta SHA-256 arriva ai client tramite il servizio di sessione, e inoltre uno 0-RTT disattivato. È plausibile e coerente con TLS 1.3, ma non è confermato ufficialmente, e non cambia nulla nelle misure più sotto.
• Le dimensioni degli attacchi specificamente contro server Hytale. Non esistono numeri pubblici in proposito. I 5 a 50 Gbit/s indicati nella tabella sono un valore d'esperienza trasversale ai progetti di game server ed espressamente non una statistica su Hytale.
• Le frequenze di pacchetti per giocatore in funzionamento normale. Anche per questo non esiste una pubblicazione solida. Per questo in questo articolo non compare alcun valore soglia che tu possa riprendere senza verificarlo, ma una guida su come misurarlo da solo.

Che cosa puoi fare da solo prima di spendere

I passi che seguono non fermano alcun attacco volumetrico, e questo nessun software sul server riesce a farlo. Portano via però tutto quello che sta sotto: scansioni delle porte, piene di tentativi di connessione da poche sorgenti, tentativi di presa di controllo tramite interfacce di amministrazione installate in aggiunta e l'occupazione di tutti i posti da parte di estranei. È la maggior parte di ciò che disturba un server Hytale nella vita quotidiana, e costa una buona ora.

1. Inventario: che cosa è in ascolto sul server?

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

ss -lntup

La colonna interessante è quella dell'indirizzo locale. 0.0.0.0:5520 significa "raggiungibile da tutta internet", 127.0.0.1:8080 significa "solo in locale" e non richiede alcuna apertura. Accanto al processo Java del server, su una macchina cresciuta nel tempo compaiono spesso un pannello di amministrazione, un server web per la visualizzazione della mappa e un database. Il punto di vista di chi attacca lo dà una scansione delle porte dall'esterno:

nmap -Pn -sU -p 5520 IP.DEL.TUO.SERVER
nmap -Pn -p- --min-rate 1000 IP.DEL.TUO.SERVER

Il secondo comando è il più importante. Mostra che cosa sia aperto oltre a quello, e nella pratica è quasi sempre più di quanto si aspetti.

2. Lasciare aperta solo la 5520 UDP, chiudere tutto il resto

Bastano due aperture. Con UFW la cosa si presenta così, e proprio in questo ordine, per non restare chiuso fuori da solo:

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

Un'apertura TCP sulla 5520 non ti serve. Se gestisci il server su una porta diversa, l'apertura deve corrispondere al valore di --bind, altrimenti l'avvio va a buon fine e i giocatori comunque non arrivano. La guida completa, via di fuga compresa, sta in Configurare il firewall UFW senza bloccarsi fuori.

Per tutto quello che hai installato in aggiunta per l'amministrazione vale la stessa regola di ogni altro gioco: non sulla rete aperta, ma raggiungibile tramite un inoltro di porta SSH, e poi lavorare in locale su 127.0.0.1:

ssh -N -L 8080:127.0.0.1:8080 root@IP.DEL.TUO.SERVER

3. Avviare il server come è pensato

L'avvio consiste in un unico comando. I file del server li ottieni tramite il downloader ufficiale di Hytale oppure dalla tua stessa installazione del gioco:

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

Al primo avvio il server crea config.json, la cartella logs/ e la cartella del mondo universe/. Dopo lo registri una volta sola sul suo account, così l'autenticazione dei giocatori funziona. La cosa passa da un codice dispositivo nella console del server:

/auth login device
/auth status

Non impostare -Xmx su tutta la memoria di lavoro della macchina. Il sistema operativo, la cache del file system e il consumo della runtime Java fuori dall'heap hanno bisogno anch'essi di spazio, e un server che sotto carico finisce nell'area di swap, per i tuoi giocatori, sembra esattamente un attacco.

4. Whitelist, password del server e limite dei giocatori contro l'esaurimento degli slot

L'esaurimento degli slot è l'attacco più economico contro un server di una comunità e non richiede banda. Chi apre abbastanza connessioni contemporanee occupa tutti i posti e chiude fuori così la comunità vera, senza comprare un solo gigabit. Hytale, a differenza di altri giochi, ha gli strumenti giusti già allo stato di consegna: una whitelist in whitelist.json, una lista di blocco in bans.json, i permessi in permissions.json e in config.json le chiavi Password e MaxPlayers.

{
  "ServerName": "Il mio server Hytale",
  "MOTD": "",
  "Password": "un valore che conosce solo il tuo gruppo",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password è vuota di serie, quindi entra chiunque abbia indirizzo e porta. Per un server chiuso una password impostata è la singola misura più efficace contro l'esaurimento degli slot, per un server pubblico lo è la whitelist durante un'ondata di attacchi. E una cosa deve essere chiara: una password del server protegge i tuoi posti, non la tua linea. Chi inonda il tuo server non ha alcuna intenzione di entrare.

Modifica questi file soltanto a server fermo. Il processo del server in esecuzione tiene il proprio stato in memoria e può sovrascrivere senza avvisare, allo spegnimento, le modifiche che scrivi nel file nel frattempo. Per le modifiche a server acceso usa i comandi di console invece dell'editor.

5. Lasciare l'autenticazione sul valore predefinito

La modalità predefinita richiede a ogni giocatore un account Hytale valido. È più di una verifica della licenza: è un filtro di accesso che rende costosi gli account in massa. Chi vuole occupare posti ha bisogno di account validi, e quelli costano soldi. Non togliere questo filtro.

La documentazione della comunità descrive, accanto a quella predefinita, altre due modalità per ambienti privati e per lo sviluppo, con le quali si può entrare senza verifica dell'account. Per un server pubblico sono l'impostazione peggiore possibile, perché trasformano l'esaurimento degli slot da una questione di soldi in una questione di script. Se passi a una di esse per fare prove, fallo su una macchina che non sta su internet, e dopo torna indietro.

6. Limitare i nuovi tentativi di connessione, e proprio con la regola dei 1200 byte

Adesso il vantaggio strutturale di QUIC diventa pratico. Un'apertura di connessione valida, secondo la RFC 9000, arriva come datagramma di almeno 1200 byte. Il traffico di gioco corrente è nettamente più piccolo. Con il tracciamento delle connessioni puoi quindi distinguere i flussi di dati nuovi da quelli esistenti e scartare tutto ciò che è nuovo e troppo piccolo. Con nftables, caricato tramite 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
    }
}

La prima regola lavora sulla lunghezza UDP, quindi 8 byte di intestazione più 1200 byte di carico utile, insieme 1208. Colpisce esclusivamente i pacchetti che vogliono aprire un nuovo flusso di dati e che per farlo sono troppo piccoli, e non può colpire i giocatori collegati. La seconda regola limita quante nuove connessioni un singolo indirizzo sorgente possa aprire al secondo. Cinque al secondo sono generose: un giocatore reale apre una connessione e la mantiene. La priorità -10 fa in modo che entrambe le regole abbiano effetto prima della catena di filtraggio di UFW.

Un limite massimo per la frequenza dei pacchetti per indirizzo sorgente sulla porta di gioco stessa è la terza regola sensata, e qui vale espressamente: il valore numerico è un valore di partenza, non una verità assoluta.

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

Misura prima una settimana di funzionamento normale, poi imposta il limite al doppio del picco misurato. Per Hytale non esiste un numero di riferimento pubblicato, e i valori dipendono molto dal numero di giocatori e dalla distanza di visuale. Chi stringe troppo butta fuori i propri giocatori, e per primi quelli con la linea peggiore.

Le semplici regole iptables spariscono dopo un riavvio. Su Debian e Ubuntu le salvi così:

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

Con UFW regole di questo tipo vanno in aggiunta in /etc/ufw/before.rules, altrimenti al prossimo ufw reload spariscono. Se una regola venga raggiunta del tutto lo mostra iptables -L INPUT -n -v: se i contatori dei match restano a zero, non ha effetto.

7. Impostare correttamente il tracciamento delle connessioni del kernel

Questo punto spiega disservizi che sembrano un attacco volumetrico ma non lo sono. Il kernel crea per il traffico UDP voci nel tracciamento delle connessioni, e con indirizzi mittente falsificati ogni indirizzo significa una voce nuova. Se la tabella è piena, il kernel scarta pacchetti senza distinzione, l'attacco e i tuoi giocatori volano fuori insieme, e nel log compare "nf_conntrack: table full". Stato e limite li mostra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Nella maggior parte dei giochi la risposta migliore è non far tracciare affatto il traffico di gioco. In Hytale è una scelta da valutare davvero, perché la regola dei 1200 byte del passo 6 ha bisogno del tracciamento delle connessioni. Senza di esso il filtro non sa quale pacchetto apra un nuovo flusso di dati. La raccomandazione è quindi: tenere il tracciamento, ingrandire la tabella, mantenere corta la scadenza dei tempi per UDP. Un file aggiuntivo sotto /etc/sysctl.d/, attivato con 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

Chi vuole comunque disattivare il tracciamento, per esempio su una macchina con moltissimi giocatori contemporanei, imposta udp dport 5520 notrack nella tabella raw e rinuncia così alla regola dei 1200 byte. Le due cose insieme non si possono avere. Per un singolo server Hytale la regola vale più delle voci di tabella risparmiate.

Se i pacchetti arrivano più in fretta di quanto il processo Java li prelevi, si riempie in aggiunta il buffer di ricezione. Per i giocatori sembra perdita di pacchetti, benché la linea sia libera. Se le impostazioni del buffer qui sopra siano necessarie lo rivela il kernel stesso: se UdpRcvbufErrors in nstat -az cresce, allora servono. Se il contatore resta a zero, l'adattamento non cambia nulla.

8. Scegliere distanza di visuale e numero di giocatori adatti alla linea

Questo passo non è una misura di sicurezza, ma decide quanto attacco tu riesca in assoluto a sopportare. Hypixel Studios lo ha formulato con chiarezza nei requisiti hardware ufficiali del 1 dicembre 2025: se raddoppi la distanza di visuale, quadruplichi la quantità di mondo intorno al giocatore. La raccomandazione ufficiale è di al massimo 12 chunk, quindi 384 blocchi, impostati tramite MaxViewRadius. Sul lato client gli stessi requisiti indicano 2 Mbit/s come minimo e 8 Mbit/s come raccomandazione per giocatore per il gioco in multigiocatore.

Fai il conto una volta per il tuo server. Un server con 40 giocatori e distanza di visuale generosa muove, in funzionamento normale, un ordine di grandezza di poche centinaia di megabit. È il valore su cui la tua linea deve misurarsi, ed è nello stesso tempo il valore che un attacco deve superare per farsi notare. Chi in funzionamento normale riempie per un terzo una linea da 1 Gbit/s ha meno riserva di chi sta al cinque per cento. Una distanza di visuale più piccola non è quindi soltanto una questione di prestazioni, ma anche una questione di robustezza.

9. Tenere d'occhio mod, plugin e cambi di protocollo

Hytale è moddabile sul lato server: le mod stanno come .zip oppure .jar nella cartella mods/, e i plugin parlano direttamente con l'interfaccia del server. È comodo, perché i giocatori non devono installare nulla, e nello stesso tempo è un rischio per la disponibilità che non ha niente a che fare con gli attacchi. Un plugin che per ogni evento di rete lavora in modo costoso è un amplificatore in casa tua.

A questo si aggiunge il cambio di protocollo. Con l'Update 6 il protocollo di rete è passato, secondo le patch notes ufficiali del 27 agosto 2026, da hytale/2 a hytale/3, e server e plugin devono essere ricompilati prima di potersi collegare. Per la disponibilità questo significa: tieni un elenco delle tue mod con la relativa versione, verificale prima di ogni aggiornamento su una seconda istanza e metti in programma una finestra di manutenzione prima del 12 ottobre 2026. Un server che dopo un aggiornamento non parte, per i tuoi giocatori non è distinguibile da un attacco.

10. Raccogliere valori misurati prima che la cosa diventi seria

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. Durante un incidente bastano cinque comandi:

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"

Per tcpdump vale una regola: limita sempre con -c, perché una cattura a pieno carico appesantisce ancora di più un server già sovraccarico. Poiché il server Hytale gira su Java, ti serve una seconda prova, che escluda il falso allarme più frequente. Una pausa della garbage collection, per i giocatori, sembra esattamente un attacco: tutti si bloccano nello stesso momento, poi la cosa riparte. La differenza sta nei numeri.

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

L'interpretazione è semplice. Se i pacchetti in ingresso salgono molto sopra il valore normale mentre il processo Java lavora poco, è un attacco. Se la frequenza dei pacchetti resta normale mentre l'heap si riempie oppure il log mostra pause lunghe, è carico. Come interpretare nel dettaglio i valori di rete sta in Riconoscere un attacco DDoS sul server.

11. Backup, piano di ripiego e una prova prima della grande data

Un piano di protezione che non è mai stato provato è una supposizione. Prima di una data come il 12 ottobre 2026 ci sono quattro cose da sbrigare: un backup della cartella universe/ insieme a config.json, conservato fuori dalla macchina, un ritorno verificato alla versione precedente del server, una seconda istanza su cui installi per primo l'aggiornamento e un test di carico fatto una volta, che faccia scattare le tue stesse regole di filtraggio.

Il test di carico è il punto in cui la maggior parte di chi gestisce un server si ferma, ed è il più importante. Non verificare se le tue regole respingano gli attacchi, ma se lascino passare i tuoi stessi giocatori. Per farlo basta osservare i contatori dei match mentre venti giocatori reali entrano nello stesso momento. Se durante quella prova i contatori delle regole di scarto salgono, il tuo limite è impostato troppo stretto, e lo avresti scoperto il giorno dell'aggiornamento, nelle condizioni peggiori.

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. Un game server tipico ha una connettività da 1 Gbit/s, cioè 125 megabyte al secondo, e la linea è piena non appena qualcuno spedisce di più. Gli attacchi contro progetti di game server stanno di solito fra 5 e 50 Gbit/s, quindi da cinque a cinquanta volte la tua linea. Che la tua regola nftables dietro sia buona non ha più alcuna importanza, perché i pacchetti dei tuoi giocatori non passano già prima.

La seconda grandezza è la frequenza dei pacchetti, e colpisce spesso prima della banda. Con pacchetti piccoli da 64 byte, in una linea da 1 Gbit/s entrano circa 1,49 milioni di pacchetti al secondo. Un normale kernel di server ne elabora, a seconda di processore e scheda di rete, qualche centinaio di migliaia prima di cominciare a scartare. Un attacco che non riempie nemmeno per un terzo la tua linea può quindi comunque paralizzare il tuo server, perché il tempo di calcolo se ne va nello scartare. Chi gestisce un server lo vive così: "l'utilizzo non era nemmeno alto, eppure era sparito tutto".

In Hytale si aggiunge una terza grandezza, che nella maggior parte dei giochi non esiste: il tempo di calcolo per l'apertura della connessione. Una piena di tentativi di connessione validi da una botnet non riempie alcuna linea e non produce una frequenza di pacchetti evidente, occupa il processore con la crittografia. Attacchi di questo tipo sono invisibili nella statistica della banda ed evidenti nel carico del processore del processo Java, e contro di essi non aiuta né una limitazione della frequenza per indirizzo sorgente né un buffer di ricezione più grande, se le sorgenti sono abbastanza numerose.

Per inquadrare quali ordini di grandezza si presentino realmente: su server KernelHost sono stati filtrati, fra gli altri, un attacco da oltre 473,4 Gbit/s con oltre 41,5 milioni di pacchetti al secondo su un server vocale e un UDP flood da oltre 112,2 Gbit/s su un game server. Per questo non esiste alcuna impostazione locale. Gli attacchi volumetrici devono finire nella rete, prima del server.

Che cosa mette davanti KernelHost contro gli attacchi DDoS ai server Hytale

La protezione permanente inclusa in ogni pacchetto 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.

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. Quali titoli e protocolli siano coperti da profili di protezione propri lo elenca Protezione DDoS per game server in tempo reale.

Advanced DDoS Protection per progetti Hytale sotto attacco continuo

Certi progetti non vengono colpiti ogni tanto, ma in modo mirato e per settimane, e in un gioco in Early Access questo riguarda soprattutto i server che stanno crescendo. Per questi casi c'è la Advanced DDoS Protection a partire da 50,00 € al mese, PrePaid, senza durata minima e senza costi di attivazione. 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: stabilisci che cosa è permesso sulla 5520 UDP, separatamente da tutto il resto, e per farlo non ti serve alcun ticket.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro durante un attacco in corso, per esempio limitare per un po' in modo più duro le nuove connessioni e lasciare intatto il traffico di gioco in corso.
• Set di regole adatto al protocollo, per QUIC su UDP così come per applicazioni proprie su porte TCP o UDP a piacere.

La Advanced DDoS Protection si rivolge ai server che stanno presso KernelHost. Chi gestisce il proprio progetto Hytale attualmente altrove e viene attaccato in permanenza lo trasferisce qui, e allora entrambi i livelli valgono dalla consegna.

I due livelli a confronto

Per la maggior parte dei server Hytale 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.

Che cosa si può trasferire su Hytale dagli altri giochi

Poiché Hytale è ancora giovane e sugli attacchi ai server Hytale non esistono numeri pubblici, la strada più rapida verso conoscenze solide è lo sguardo ai giochi comparabili. Trasferibile non è la numerazione delle porte, ma lo schema.

• Il lancio esplosivo e che cosa provoca: Palworld mostra come un'ondata di nuovi giocatori e un'ondata di attacchi si sovrappongano nel tempo e perché diventino bersaglio proprio i server in crescita.
• La differenza fra interrogazione e traffico di gioco: Minecraft Bedrock spiega sull'esempio dell'Unconnected Ping come funzioni l'amplificazione tramite UDP. È esattamente questa via d'attacco che Hytale, grazie a QUIC, non ha, e da lì si capisce meglio la differenza.
• L'apertura della connessione come bersaglio: Protezione DDoS per Minecraft e protezione Nullping descrive le piene di handshake, che si accontentano di quasi nessuna banda. È il parente più vicino alla piena di connessioni QUIC.
• Numeri di giocatori piccoli ed esaurimento degli slot: Project Zomboid e Conan Exiles mostrano quanto poco sforzo serva per chiudere fuori un gruppo stabile, e quale ruolo ci giochino whitelist e password.
• Funzionamento sotto carico continuo: Terraria mostra come un singolo processo di server con carico su un solo core reagisca agli attacchi. Il server Hytale è un processo Java, il problema di fondo è comparabile.

Errori frequenti sui server Hytale e come risolverli

"Ho aperto la porta 5520 TCP e i giocatori comunque non entrano": il traffico di gioco passa da QUIC, quindi da UDP. Un'apertura TCP per il traffico di gioco non serve a niente. Apri la 5520 UDP e verificala dall'esterno con nmap -Pn -sU -p 5520. Se hai messo il server con --bind su un'altra porta, l'apertura deve indicare quella porta.

"Il server gira, ma nessuno riesce a entrare, e nel log non c'è traccia di attacchi": verifica la registrazione del server sul suo account con /auth status. Un server la cui registrazione è scaduta continua a girare e respinge comunque i giocatori. Non è un problema di rete e non è una regola di filtraggio.

"Dopo l'aggiornamento non parte più niente": non è un attacco, è il cambio di protocollo. Con l'Update 6 il protocollo di rete è passato da hytale/2 a hytale/3, e server e plugin hanno bisogno di una nuova compilazione. Installa gli aggiornamenti prima su una seconda istanza, prima di mandarli sul server di produzione.

"Tutti i giocatori si bloccano nello stesso momento per due secondi, poi riparte": con alta probabilità è la garbage collection della runtime Java e non un attacco. Verifica jcmd ... GC.heap_info e il log del server. Se sar -n DEV 1 10 intanto resta normale, non c'era alcun attacco in gioco, ma un heap dimensionato troppo stretto oppure una distanza di visuale troppo grande.

"La mia regola contro i pacchetti piccoli ha chiuso fuori i giocatori": allora la condizione dei 1200 byte sta nella catena senza ct state new. Il traffico di gioco corrente è composto in prevalenza da pacchetti piccoli, e una condizione sulla lunghezza senza verifica dello stato colpisce esattamente quelli. La condizione vale esclusivamente per i flussi di dati appena aperti.

"Ho cambiato l'indirizzo IP ed ero di nuovo offline due ore dopo": chi attacca ha preso il nuovo indirizzo dalla stessa fonte di quello vecchio. In Hytale di solito sono un vecchio record A nel DNS, un bot Discord con indicazione dello stato oppure una voce in una delle tante liste server di terze parti. Dall'Update 6 gli indirizzi dei server sono nascosti di serie nella lista ufficiale, cosa che chiude la strada più comoda, ma non tutte. Un cambio di indirizzo è tempo guadagnato, non una soluzione.

"Le mie regole di filtraggio 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 oppure una voce in /etc/ufw/before.rules), oppure l'attacco è volumetrico e la regola lavora correttamente su una linea che è già piena. Verifica con iptables -L INPUT -n -v se i contatori dei match salgano.

"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 Hytale ha bisogno di esattamente una porta aperta: 5520 UDP per QUIC. Il TCP per il traffico di gioco non serve, e nella documentazione pubblica non è descritta alcuna altra porta per interrogazioni, RCON o gestione remota.
• Poiché QUIC secondo la RFC 9000, prima della verifica dell'indirizzo, può inviare al massimo il triplo della quantità di byte ricevuta e un primo tentativo di connessione deve essere di almeno 1200 byte, un server Hytale è praticamente inutile come amplificatore per la reflection. Questo lo distingue dai server con interrogazione Steam oppure con Unconnected Ping di Bedrock.
• La stessa regola dei 1200 byte è la migliore regola di filtraggio locale: ciò che vuole aprire un nuovo flusso di dati sulla 5520 UDP ed è più piccolo non può essere un'apertura di connessione valida e si può scartare senza colpire i giocatori collegati.
• La parte costosa di un'apertura QUIC è la crittografia, non la banda. Una piena di tentativi di connessione validi è invisibile nella statistica della banda e si vede soltanto nel carico del processore e nei contatori delle nuove connessioni.
• La modalità predefinita con obbligo di account è un filtro di accesso che rende costosi gli account in massa. Per un server pubblico resta intatta, e a essa si aggiungono whitelist.json, bans.json e un valore impostato in Password contro l'esaurimento degli slot.
• Le misure locali finiscono alla linea: 1 Gbit/s sono 125 megabyte al secondo, e con pacchetti da 64 byte là dentro entrano circa 1,49 milioni di pacchetti al secondo. Tutto ciò che sta sopra deve finire nella rete, prima del server.
• Hytale è in Early Access dal 13 gennaio 2026, Chapter 1 è annunciato per il 12 ottobre 2026. Le grandi date sono date da attacco, e una protezione ordinata alla data arriva troppo tardi.
• Su KernelHost la protezione permanente a due livelli è inclusa in ogni pacchetto server senza sovrapprezzo ed è attiva dalla consegna, senza null-routing. La Advanced DDoS Protection con IP di protezione dedicato e regole per porta gestibili da te parte da 50,00 € al mese.

Se il tuo server Hytale 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.

Questo articolo è aggiornato al 27 settembre 2026. Hytale è in Early Access, e il protocollo di rete è già cambiato una volta in quest'anno. Verrà aggiornato dopo Chapter 1 e dopo ogni aggiornamento che riguardi l'apertura della connessione, le porte oppure la lista dei server.