Proteggere un server Unturned dagli attacchi DDoS

Un server Unturned che la sera sparisce per qualche minuto dalla lista dei server e nel farlo butta fuori tutti i giocatori con un timeout raramente ha un problema hardware. Nella maggior parte dei casi è in corso un attacco, e per giunta proprio quando c'è più movimento. Questo articolo mostra prima che cosa puoi mettere in sicurezza da solo senza costi aggiuntivi, poi dove queste misure si fermano dal punto di vista tecnico e infine che cosa deve succedere nella rete, prima del server.

Tutte le indicazioni si riferiscono all'Unturned Dedicated Server (U3DS, app ID SteamCMD 1110390) 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. Se l'attacco è in corso proprio adesso, non modificare nulla nella configurazione e non riavviare il server: metti prima al sicuro i valori misurati (sezione 10), perché dopo l'attacco non ci sono più.

Perché proprio i server Unturned vengono attaccati

I server Unturned vengono attaccati perché il loro indirizzo è pubblico, perché il traffico di gioco passa da UDP e perché un attacco non costa a chi lo lancia né competenze né soldi degni di nota. Tutti e tre i punti valgono qui più che nella maggior parte degli altri giochi.

Un server Unturned pubblico pubblica il proprio indirizzo IP di sua iniziativa. Deve farlo, altrimenti nessuno lo troverebbe: il browser dei server di Steam lo interroga direttamente, e le liste di terze parti come unturned-servers.net o BattleMetrics riportano indirizzo IP e porta in chiaro. unturned-servers.net, per sua stessa indicazione, verifica ogni cinque minuti se il server accetta connessioni UDP sulla porta del server. Per chi attacca non è un lavoro, è un modulo da compilare.

A questo si aggiunge il pubblico. Unturned è gratuito, la soglia di ingresso è pari a zero, e fra progetti roleplay e survival c'è una concorrenza reale per gli stessi giocatori. Un giocatore bannato, un ex amministratore offeso oppure un progetto vicino non hanno bisogno di alcun accesso al tuo server per renderlo inutilizzabile per un'ora. Che cosa sia tecnicamente un attacco DDoS e perché gli indirizzi mittente falsificati lo rendano così difficile da risalire lo spiega l'articolo Che cos'è un attacco DDoS?.

Le porte di cui si tratta davvero

Un server Unturned occupa esattamente due porte UDP consecutive: il valore impostato nella Commands.dat e quel valore più uno. Nella configurazione predefinita sono 27015 e 27016. La documentazione ufficiale di Smartly Dressed Games descrive così la suddivisione: la prima porta trasporta le query della lista dei server, la seconda il traffico di gioco. Si imposta solo la prima, la seconda ne deriva automaticamente.

Name Il mio server Unturned
Port 27015
MaxPlayers 24
Map PEI
Mode Normal
Perspective Both
Owner 76561198000000000

Il file Commands.dat si trova in U3DS/Servers/<Istanza>/Server/Commands.dat. Il suo formato è particolare ed è una fonte di errori frequente: un comando per riga, nessun segno di uguale, valore separato da uno spazio, e i comandi distinguono fra maiuscole e minuscole. Le righe che cominciano con // sono commenti.

Il punto più importante per il firewall è questo: la porta 27017 non serve più dalla versione 3.21.30.0 del 21 novembre 2021. Prima di allora un server Unturned richiedeva tre porte, perché la query Steam stava sulla porta più due. Con quell'aggiornamento la query condivide la porta con il server stesso e la terza porta è venuta meno. Nonostante questo, guide per router, wiki di hoster e messaggi nei forum citano la 27017 ancora oggi. Una 27017 aperta non ti porta più alcun vantaggio, è pura superficie di attacco.

Altrettanto importante: Unturned non ha una porta RCON integrata. La documentazione ufficiale conosce solo input e output da console, che si possono sostituire attraverso l'interfaccia ICommandInputOutput. Qualsiasi controllo remoto che vedi su un server Unturned arriva quindi da un plugin e porta con sé una propria porta TCP. Quella porta devi trovarla tu e limitarla tu, perché nessuno l'ha messa in sicurezza al posto tuo.

Che cosa puoi fare da solo prima di spendere

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

1. Inventario: che cosa è davvero in ascolto

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

ss -lnup
ss -lntp

Il primo comando mostra i socket UDP in ascolto, il secondo quelli TCP. La colonna interessante è quella dell'indirizzo locale. 0.0.0.0:27015 e [::]:27015 significano "raggiungibile da tutta internet", 127.0.0.1:3306 significa "solo in locale" e non richiede alcuna regola firewall. Accanto al gioco lì si trovano spesso un plugin RCON, un pannello web, un database e un vecchio server di prova sulla 27017 che nessuno usa più. Il punto di vista di chi attacca te lo dà una scansione delle porte dall'esterno, per Unturned espressamente con UDP:

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

2. Lasciare aperte solo la 27015 e la 27016

Per Unturned bastano due aperture UDP verso l'esterno. Per il gioco in sé non serve nemmeno una porta TCP: la documentazione ufficiale richiede espressamente UDP per entrambe le porte, e il livello di rete del gioco (Steam Networking Sockets, impostazione predefinita da un aggiornamento in poi) lavora esclusivamente su UDP. Chi apre in più anche TCP sta seguendo una guida superata.

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Unturned query'
ufw allow 27016/udp comment 'Unturned gioco'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

L'ordine è importante, altrimenti resti chiuso fuori dal tuo server. La guida completa, via di fuga compresa, è in Configurare il firewall UFW senza bloccarsi fuori. Se gestisci più istanze, rispetta la distanza di due consigliata (27015, 27017, 27019) e apri per ogni istanza esattamente le due porte che occupa davvero.

Un pannello web, un database o un plugin RCON non hanno niente a che fare con la rete aperta. Limita la porta corrispondente al tuo indirizzo con ufw allow from 203.0.113.10 to any port 8080 proto tcp, oppure raggiungi l'interfaccia attraverso un inoltro locale via SSH con ssh -N -L 8080:127.0.0.1:8080 root@IP.DEL.TUO.SERVER. Il database si lega a 127.0.0.1.

3. Mettere in sicurezza la porta di query senza uscire dalla lista dei server

La porta di query è il punto più delicato di un server Unturned. Attraverso di essa il server risponde alle query Steam A2S_INFO, A2S_PLAYERS e A2S_RULES. Se la blocchi del tutto, il server sparisce da ogni lista dei server, anche se gira senza problemi.

Una risposta A2S è nettamente più grande della richiesta. Nella sua panoramica sugli attacchi di amplificazione UDP (TA14-017A), l'US-CERT indica per il protocollo Steam un fattore di amplificazione della banda di 5,5. In concreto significa: chi attacca spedisce query con indirizzo mittente falsificato a game server altrui e dirotta le risposte, circa cinque volte e mezzo più grandi, sul proprio vero bersaglio. In quel caso il tuo server non è la vittima, ma l'amplificatore contro un terzo. Nella direzione opposta basta un flood di query per far sparire il server dal browser dei server, senza che voli fuori nemmeno un giocatore. I gestori segnalano esattamente questo: il server gira, i giocatori sopra non si accorgono di nulla, ma non è più rintracciabile.

Contro i flood di query piccoli aiuta un limite massimo per indirizzo sorgente. Le query legittime arrivano di rado: il browser di Steam interroga una volta per visualizzazione, i servizi di stato ogni pochi minuti.

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name unturned_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name unturned_game --hashlimit-mode srcip --hashlimit-above 300/sec --hashlimit-burst 500 -j DROP

Il secondo numero deriva direttamente dal gioco: Unturned limita un giocatore a 50 pacchetti al secondo già di fabbrica (Max_Packets_Per_Second). 300 pacchetti al secondo per indirizzo sorgente lasciano quindi molto spazio a una singola connessione, anche quando dietro allo stesso indirizzo siedono più giocatori. Entrambi i valori sono valori di partenza, non verità assolute. Misura prima una settimana di funzionamento normale, altrimenti butti fuori i tuoi stessi giocatori.

Le semplici regole iptables spariscono dopo un riavvio. Su Debian e Ubuntu si salvano con apt-get install -y iptables-persistent e netfilter-persistent save. Con UFW, invece, regole di questo tipo vanno in /etc/ufw/before.rules, altrimenti al prossimo ufw reload spariscono.

A questo si aggiunge un'abitudine che non costa nulla: se il tuo sito o il tuo bot Discord mostrano il numero di giocatori, non interrogare il server dal browser del visitatore, ma salva il risultato in cache a intervalli fissi. Altrimenti una pagina di stato molto visitata genera un'interrogazione per visitatore invece di una per intervallo.

4. Impostare i limiti integrati nella Config.json

Nella Config.json, nella stessa cartella Server in cui si trova la Commands.dat, Unturned porta con sé una sezione più importante per la difesa di quanto il suo nome lasci supporre. I valori predefiniti sono questi:

"Server": {
    "VAC_Secure": true,
    "BattlEye_Secure": true,
    "Max_Ping_Milliseconds": 750,
    "Timeout_Queue_Seconds": 15.0,
    "Timeout_Game_Seconds": 30.0,
    "Max_Packets_Per_Second": 50.0,
    "Join_Rate_Limit_Window_Seconds": 40.0,
    "Rate_Limit_Kick_Threshold": 10,
    "Use_FakeIP": false
}

Max_Packets_Per_Second limita un giocatore connesso a 50 pacchetti al secondo. Join_Rate_Limit_Window_Seconds e Rate_Limit_Kick_Threshold buttano fuori una connessione che nell'arco di 40 secondi supera il limite più di dieci volte. VAC_Secure e BattlEye_Secure richiedono entrambi i sistemi anti-cheat sul lato del giocatore e tengono così lontana la gran parte dei client usa e getta.

Una cosa deve però essere chiara: questi limiti agiscono contro i client che entrano davvero o che ci provano. Contro un flood con indirizzi mittente falsificati non agiscono, perché lì non nasce mai una sessione. Restano comunque importanti, perché intercettano il singolo caso più frequente: un client manipolato che da solo sovraccarica il server. Lasciare Max_Ping_Milliseconds a 750 ha senso; impostato più in basso, il server butta fuori mezzi round a ogni piccolo scatto di rete.

5. Alleggerire il tracciamento delle connessioni

Questo punto viene quasi sempre trascurato e spiega disservizi che sembrano un attacco volumetrico senza esserlo. Il kernel crea voci nel tracciamento delle connessioni (conntrack) anche per il traffico UDP, e con indirizzi mittente falsificati ogni nuovo indirizzo significa una nuova voce. Quando la tabella è piena il kernel scarta i pacchetti senza distinzione: l'attacco e i tuoi giocatori volano fuori insieme. Nel log di sistema compare allora nf_conntrack: table full, dropping packet.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack

Il passo più efficace è non far tracciare affatto il traffico di Unturned. Il gioco gestisce da sé le proprie sessioni e non ha bisogno di alcun tracciamento di stato nel kernel:

iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK
iptables -t raw -A PREROUTING -p udp --dport 27016 -j NOTRACK

Fai attenzione: da quel momento le tue aperture per queste due porte non possono più passare da ESTABLISHED,RELATED, ma devono esistere come regole di accettazione proprie. Solo dopo vale la pena alzare nf_conntrack_max. Chi ingrandisce prima la tabella sposta il problema solo di qualche minuto e per farlo consuma memoria.

Se i pacchetti arrivano più velocemente di quanto il processo del server riesca a prelevarli, va in overflow anche il buffer di ricezione del socket. Per i giocatori questo somiglia a una perdita di pacchetti, anche se la linea è libera:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Metti i valori sotto /etc/sysctl.d/ e attivali con sysctl --system. Se siano necessari te lo dice il kernel: se UdpRcvbufErrors in nstat -az sale oppure se in ss -lunp resta stabilmente qualcosa nella coda di ricezione, allora servono. Se entrambi restano a zero, la modifica non cambia nulla. Questa è riserva, non protezione.

6. Flood di ingressi, coda e whitelist

Un flood di ingressi è un attacco in cui chi attacca usa la normale via di ingresso per consumare slot e tempo di calcolo, invece di riempire la linea. Contro questo Unturned mette a disposizione quattro strumenti, che stanno tutti nella Commands.dat:

• Queue_Size 32 imposta la coda. Il valore predefinito è 8 posti, il massimo è 64. Una coda troppo grande aiuta chi attacca, una troppo piccola scarta i giocatori veri a ogni riavvio.
• Whitelisted porta il server in modalità lista di accesso. Si inserisce da console con permit <SteamID64> e si rimuove con unpermit <SteamID64>.
• Password LaTuaPassword esclude tutto ciò che ha l'indirizzo solo perché l'ha preso da una lista.
• Filter respinge i giocatori con caratteri non ammessi nel nome, e MaxPlayers 24 tiene il numero di posti a quello che l'hardware regge davvero.

Una whitelist protegge la tua logica di gioco, non la tua linea. 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.

7. RocketMod, OpenMod e il lato dei plugin

Unturned ha due piattaforme di plugin diffuse, ed entrambe girano nello stesso processo del server. RocketMod è la più vecchia: i curatori originali hanno interrotto la manutenzione il 20 dicembre 2019 e hanno pubblicato il codice sorgente sotto licenza MIT. Da allora Smartly Dressed Games cura il derivato Legally Distinct Missile (LDM), che viene già fornito insieme al Dedicated Server: si copia Rocket.Unturned dalla cartella Extras nella cartella Modules. Gli sviluppatori consigliano espressamente il derivato, perché risolve vecchi problemi di Rocket come gli errori di threading e gli exploit di teletrasporto.

OpenMod è il successore più recente, sviluppato da uno dei curatori originali di Rocket. Non sostituisce RocketMod, ma gira accanto a esso e può riutilizzare i plugin Rocket esistenti attraverso un'integrazione. Per la difesa questo significa due cose.

Primo: ogni plugin è superficie di attacco nel processo principale. Un plugin che a ogni messaggio in chat o a ogni evento di gioco scatena un'interrogazione al database è un denial of service fatto in casa. Un singolo giocatore che fa scattare un evento in un ciclo blocca allora il server senza alcuna banda. Tieni corta la lista dei plugin, preferisci i plugin open source e misura il frame rate del server dopo ogni aggiunta.

Secondo: poiché Unturned non ha una porta RCON propria, qualsiasi controllo remoto arriva da un plugin. Dopo l'installazione verifica con ss -lntp quale porta TCP è stata aperta e limitala al tuo indirizzo. Una porta di controllo remoto aperta con una password debole non è un problema di DDoS, è un problema di presa di possesso.

8. Contenuti Workshop e processo di ingresso

I contenuti Workshop rendono costoso l'ingresso, e questo incide direttamente sulla vulnerabilità. La cosa si governa attraverso la WorkshopDownloadConfig.json, nella stessa cartella Server:

{
    "File_IDs": [],
    "Ignore_Children_File_IDs": [],
    "Query_Cache_Max_Age_Seconds": 600,
    "Max_Query_Retries": 2,
    "Use_Cached_Downloads": true,
    "Should_Monitor_Updates": true,
    "Shutdown_Update_Detected_Timer": 600
}

In File_IDs stanno gli identificatori Workshop delle mappe e delle mod. All'avvio il server le scarica insieme alle dipendenze, e ogni giocatore le scarica automaticamente quando si connette. Dovresti conoscere tre conseguenze. Primo, con liste di mod grandi l'ingresso dura a lungo, e dopo un attacco tutti i giocatori tornano contemporaneamente, il che carica il server una seconda volta. Secondo, Should_Monitor_Updates ferma il server non appena un file Workshop viene aggiornato: il valore predefinito di Shutdown_Update_Detected_Timer, pari a 600 secondi, porta allora a un riavvio che in caso di attacco i gestori scambiano regolarmente per un successo di chi attacca. Terzo, ogni mod è codice altrui sul tuo server.

In pratica significa: tieni la lista il più corta possibile, dopo ogni riavvio inatteso controlla per prima cosa nel log del server il messaggio relativo all'aggiornamento Workshop, e disattiva Should_Monitor_Updates solo se pianifichi tu stesso gli aggiornamenti.

9. Lista dei server, codice del server e funzione Fake IP

Il tuo indirizzo IP non si può tenere segreto finché il server è elencato pubblicamente. Lo conosce ogni giocatore che si è connesso anche una sola volta, e le liste di terze parti lo pubblicano comunque. Due abitudini aiutano lo stesso: non pubblicare tu stesso l'indirizzo grezzo da nessuna parte, e fai collegare i tuoi giocatori tramite un hostname, così un cambio di indirizzo non rompe ogni riferimento. Il classico è il record A dimenticato che punta al vecchio indirizzo e rende inefficace qualsiasi cambio.

Per il funzionamento su internet ti serve comunque un Game Server Login Token (GSLT) dalla gestione server di Steam per l'app ID 304930. Fa inoltre in modo che il codice del tuo server resti lo stesso attraverso i riavvii, invece di essere generato di nuovo a ogni avvio.

Unturned offre inoltre una funzione Fake IP. Si attiva con "Use_FakeIP": true nella Config.json, e il comando di console CopyFakeIP fornisce l'indirizzo che poi pubblichi. Da quel momento il traffico passa dalla rete di relay Steam Datagram Relay, gli indirizzi assegnati stanno nell'intervallo da 169.254.0.0 a 169.254.255.255 e l'indirizzo reale del server non viene più mostrato ai giocatori. Valve descrive quel traffico come autenticato, cifrato e limitato nella frequenza.

Il prezzo è alto e viene detto di rado: indirizzo e porta cambiano a ogni riavvio, un nome di dominio non si può puntare su di essi senza script propri, e le liste Steam "Preferiti" e "Cronologia" con questa funzione non funzionano, ma solo la funzione dei segnalibri. Soprattutto, però, la funzione protegge solo la via di gioco. Il tuo server mantiene il suo indirizzo reale, e SSH, pannello web, database e sito restano raggiungibili attraverso di esso. Chi conosce l'indirizzo da un vecchio record DNS, da una pagina di stato o da una connessione precedente continua ad attaccarlo direttamente. La funzione Fake IP non sostituisce quindi un filtraggio nella rete davanti al server, riduce soltanto il numero di persone che conoscono il tuo indirizzo.

10. Registrare i log, per non dover tirare a indovinare durante un attacco

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 venerdì sera. Con apt-get install -y vnstat sysstat la misurazione resta sempre attiva. Durante un incidente bastano quattro comandi:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 udp portrange 27015-27016 -c 200 -q

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

Dove queste misure si fermano

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 è satura non appena qualcuno spedisce di più. Il funzionamento normale resta ben al di sotto: con 24 giocatori e i 50 pacchetti per giocatore al secondo consentiti di fabbrica arrivano circa 1.200 pacchetti al secondo. Un servizio booter ne genera un multiplo senza alcuna preparazione.

La seconda grandezza è la frequenza dei pacchetti, e colpisce quasi sempre 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 CPU e scheda di rete, qualche centinaio di migliaia prima di cominciare a scartare. Un attacco che non riempie nemmeno un terzo della tua linea può quindi mettere comunque fuori gioco 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".

Per dare un ordine di grandezza reale: sui server di KernelHost sono stati filtrati, fra gli altri, un attacco con oltre 473,4 Gbit/s e oltre 41,5 milioni di pacchetti al secondo contro un server vocale e un UDP flood con oltre 112,2 Gbit/s contro 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

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.

Due caratteristiche sono decisive. La protezione è permanente 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. La sede di filtraggio è 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, 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: imposti separatamente che cosa è permesso sulla 27015 UDP (le query) e che cosa sulla 27016 UDP (il traffico di gioco), senza dover aprire un ticket.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro anche durante un attacco in corso, per esempio stringendo le query e lasciando intatto il traffico di gioco.
• Profilo di protezione adatto al gioco, come pure per applicazioni modificate e proprie su porte TCP o UDP a piacere, quindi anche per un plugin con una porta propria.

I due livelli a confronto

Per la maggior parte dei progetti Unturned 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.

Errori frequenti e soluzioni

"La mia guida dice che devo aprire dalla 27015 alla 27017": la guida è più vecchia di novembre 2021. Dalla versione 3.21.30.0 un server Unturned ha bisogno solo di due porte, perché la query Steam non sta più sulla porta più due. Chiudi la 27017, a meno che lì non giri una seconda istanza.

"Il server gira, ma non compare più in nessuna lista dei server": è l'immagine tipica di un flood di query oppure di una tua regola troppo stretta sulla 27015 UDP. Verifica con iptables -L INPUT -n -v se la tua regola conta dei match. Se i contatori salgono molto, stai filtrando via le tue stesse voci di lista. Non bloccare mai del tutto la 27015.

"Tutti i giocatori volano fuori insieme con un timeout": controlla per prima cosa se il tracciamento delle connessioni è andato in overflow (dmesg -T | grep -i conntrack). Se la tabella è piena, il kernel scarta senza distinzione. Timeout_Game_Seconds è impostato di fabbrica su 30 secondi: chi torna entro quel tempo mantiene il proprio posto.

"Il server si riavvia durante il funzionamento": raramente è un attacco. Controlla nel log il messaggio relativo all'aggiornamento Workshop rilevato. Should_Monitor_Updates spegne il server dopo l'intervallo predefinito di 600 secondi.

"Ho cambiato indirizzo IP e due ore dopo ero di nuovo offline": chi attacca ha preso il nuovo indirizzo dalla stessa fonte del vecchio, di solito una lista dei server, un bot Discord oppure un vecchio record DNS. Cambiare indirizzo fa guadagnare tempo, non è una soluzione.

"Ho attivato la funzione Fake IP e vengo attaccato lo stesso": nasconde l'indirizzo ai nuovi giocatori, ma non lo toglie al server. Chi lo conosce da una vecchia voce di lista, da una pagina di stato o da una connessione precedente raggiunge ancora direttamente il tuo server, e con esso SSH e ogni pannello web che vi gira sopra.

"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 Unturned ha bisogno di esattamente due porte UDP aperte: la Port impostata nella Commands.dat (predefinita 27015) e quel valore più uno (27016). Il gioco in sé non ha bisogno di TCP.
• La porta 27017 è superflua dalla versione 3.21.30.0 del 21 novembre 2021, perché la query Steam non sta più sulla porta più due. Chi la tiene ancora aperta sta seguendo una guida superata.
• Unturned non ha una porta RCON integrata. Qualsiasi controllo remoto arriva da un plugin, porta con sé una propria porta TCP e devi limitarla tu.
• La porta di query 27015 è il punto più delicato: un flood di query rende il server invisibile nella lista dei server senza colpire un solo giocatore, e secondo US-CERT TA14-017A il protocollo Steam ha un fattore di amplificazione di 5,5.
• I limiti nella Config.json (Max_Packets_Per_Second 50,0, Rate_Limit_Kick_Threshold 10 ogni 40 secondi) agiscono solo contro i client che entrano davvero, non contro gli indirizzi mittente falsificati.
• Una linea da 1 Gbit/s è satura a 125 megabyte al secondo, e con pacchetti da 64 byte già a circa 1,49 milioni di pacchetti al secondo. Il funzionamento normale con 24 giocatori si colloca intorno ai 1.200 pacchetti al secondo. Tutto ciò che sta sopra lo decide la rete davanti al server, non il tuo firewall.
• Da KernelHost la protezione permanente a due livelli è inclusa in ogni pacchetto server senza sovrapprezzo ed è attiva dalla consegna, senza null-routing. Chi vuole gestire da sé le regole di filtraggio aggiunge la Advanced DDoS Protection a partire da 50,00 € al mese.

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.