Protezione DDoS per i server di gioco: un runbook per l'era degli attacchi di 10 minuti

La tua coda di matchmaking si blocca alle 21:14. Alle 21:19 è di nuovo attiva. Controlli il grafico e trovi uno spike da 620 Mbps, largo sei minuti, già sparito prima che l'allerta raggiungesse il tuo telefono. Nessuno del tuo team di due persone lo ha visto dal vivo, e i tuoi giocatori l'hanno archiviato come "lag".

Quella forma di attacco ora è il default. Il Q3 2026 DDoS Threat Report di Cloudflare ha conteggiato 18,2 milioni di attacchi a livello di rete mitigati nel trimestre: circa 8.226 all'ora, cioè uno ogni 0,44 secondi. Di questi, il 96% è finito in meno di 10 minuti e il 98% è rimasto sotto 1 Gbps. Gli attacchi iper-volumetrici sopra 1 Tbps sono scesi da 805 nel Q2 a 251 nel Q3, un calo del ~69% che il rapporto attribuisce alle operazioni delle forze dell'ordine contro le botnet IoT Aisuru, KimWolf, JackSkid e Mossad.

Meno giganti. Più sciami. E lo sciame è il modello di minaccia per cui un piccolo backend di gioco è il peggio preparato, perché è contemporaneamente troppo piccolo per attivare il tier di mitigazione del tuo provider e abbastanza grande da saturare una singola istanza di gioco.

Questo è un runbook per quella fascia di banda.

Cosa è cambiato davvero nel Q3 2026

Tre cambiamenti contano se gestisci server di gioco. Il primo è la durata. Un aumento del 208% su base annua degli attacchi a raffica breve e bassa banda è la firma operativa dei servizi DDoS a noleggio "booter": economici, ripetibili e sparati a raffiche. Aspettati 40 attacchi in una serata, non uno.

Il secondo è il ricambio dei vettori. La riflessione CLDAP — controller di dominio pubblici abusati sulla UDP 389 — è crollata del 99,5% trimestre su trimestre, arrivando a solo lo 0,05% degli attacchi, dopo essere rimasta calda per tutto il primo semestre. Gli attaccanti non si sono fermati; hanno ruotato. L'amplificazione DNS è balzata del 215%, raggiungendo il 3,43% degli attacchi a livello di rete, e le flood UDP generali sono passate dal 14,06% al 31,31%.

Il terzo è che i bersagli si sono ampliati. I media sono rimasti il settore più attaccato ma hanno perso circa tre quarti della loro quota del Q2. L'infrastruttura internet è passata da fuori dalla top 10 al #6, mentre Consumer Services e Adult Entertainment sono entrati al #8 e #9. I giochi si trovano esattamente in quel cluster di target consumer-facing e sensibili alla latenza.

La lezione per chi difende: non costruire la tua strategia attorno al vettore del trimestre scorso. Costruiscila attorno alle quattro categorie — flood UDP, amplificazione DNS, abuso di riflessione ed esaurimento SYN — e presupponi che i pesi continuino a muoversi.

Cosa si rompe per primo in un backend di gioco

Non tutto fallisce insieme, e conoscere l'ordine ti evita di combattere l'incendio sbagliato.

• La porta di gioco. Una flood UDP sulla porta autoritativa del server satura le code della NIC prima della CPU. Il server risulta "up" per l'health check dell'orchestratore perché il processo è vivo, mentre il kernel scarta pacchetti.
• Gli endpoint di sessione e login. Le flood HTTP colpiscono l'autenticazione. I giocatori che si disconnettono durante il picco non riescono a rientrare, e quelli già in gioco abbandonano perché il loop di riconnessione fallisce.
• Le letture delle classifiche. Sono il percorso di lettura più amplificato nella maggior parte dei backend di gioco: una singola richiesta client si espande in una scansione di range sul database. 5.000 richieste al secondo sono banali da inviare e costose da servire.
• L'ingestione della telemetria. Spesso non autenticata o con rate limit lassista, spesso l'endpoint più economico da colpire.
• La tabella conntrack. Riempirla abbatte ogni servizio sull'host, incluso l'accesso SSH: è così che un attacco di quattro minuti diventa un'outage di quattro ore.

Gli attacchi di riflessione meritano una nota specifica: il traffico arriva da resolver DNS legittimi e altri server di terze parti, quindi il blocco basato sulla reputazione IP fallisce by design. Sei tu a essere colpito da infrastruttura innocente.

Rilevamento: i segnali che scattano prima dei grafici

I dashboard vanno in ritardo. I contatori del kernel no. Il pre-indicatore più importante è il rapporto tra pacchetti al secondo e bit al secondo. Un traffico di gioco legittimo da 300 Mbps corrisponde a circa 25.000-40.000 pacchetti al secondo con dimensioni tipiche dei payload. Una flood UDP da 300 Mbps con pacchetti da 64 byte si avvicina a 500.000 pps. Stessa banda, 15 volte i pacchetti, e uccide l'host mentre il grafico della banda sembra moderato.

Esegui questi comandi sulla macchina sospetta:

# socket and memory pressure summary
ss -s

# per-protocol counters and the ones that predict a lockup
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|TcpExtListenDrops|TcpExtTCPReqQFullDrop'

# current conntrack table occupancy vs max
conntrack -C && sysctl net.netfilter.nf_conntrack_max

# what is actually arriving on the wire
tcpdump -nn -i eth0 'udp and not port 7777' -c 200

Leggili così:

• UdpInDatagrams in aumento mentre il game loop riporta meno giocatori = flood.
• UdpNoPorts in aumento = scanner che spazza il range di porte, spesso un precursore.
• TcpExtTCPReqQFullDrop diverso da zero = overflow della coda SYN, quindi stai già perdendo handshake legittimi.
• conntrack -C sopra il 70% di nf_conntrack_max = sei a minuti dal collasso completo dell'host, non solo del server di gioco.

Se preferisci la vista per endpoint a quella del kernel, il protocollo diagnostico per i crash dei server UEFN spiega come distinguere uno stallo a livello di rete da uno a livello di engine: è la prima decisione in ogni triage.

Per la difesa in-process contro la spazzatura che riesce a passare, un token bucket per sorgente a livello di socket è economico ed efficace. Questo esempio in C# filtra i pacchetti in ingresso prima che raggiungano il tick della simulazione:

using System.Diagnostics;
using System.Net;

public sealed class PacketGate
{
    private readonly Dictionary<IPAddress, Bucket> _buckets = new();
    private readonly int _ratePerSecond;
    private readonly int _burst;

    // A legit client at 30 Hz sends ~30 packets/s. 120/s allows
    // headroom for retransmits without letting a flood through.
    public PacketGate(int ratePerSecond = 120, int burst = 240)
    {
        _ratePerSecond = ratePerSecond;
        _burst = burst;
    }

    public bool Allow(IPAddress source)
    {
        long now = Stopwatch.GetTimestamp();

        if (!_buckets.TryGetValue(source, out var bucket))
        {
            bucket = new Bucket { Tokens = _burst, LastRefill = now };
            _buckets[source] = bucket;
        }

        double elapsed = (now - bucket.LastRefill) / (double)Stopwatch.Frequency;
        bucket.Tokens = Math.Min(_burst, bucket.Tokens + elapsed * _ratePerSecond);
        bucket.LastRefill = now;

        if (bucket.Tokens < 1.0) return false;
        bucket.Tokens -= 1.0;
        return true;
    }

    private sealed class Bucket
    {
        public double Tokens;
        public long LastRefill;
    }
}

Sii chiaro su cosa fa e cosa non fa. Filtra la spazzatura per sorgente che sta dentro la banda disponibile. Non fa nulla una volta che la linea è satura: a quel punto i pacchetti vengono scartati a monte del processo, qualunque cosa decida il tuo codice.

Runbook di rimedio: i primi dieci minuti

Dato che il 96% degli attacchi termina prima che un umano possa rispondere, il lavoro del runbook non è farti risolvere l'attacco. È farti catturare prove e ridurre il blast radius mentre l'attacco si consuma.

Da T+0 a T+2 minuti — conferma, non scalare. Resisti al riflesso di aggiungere istanze. Scalare dentro una flood moltiplica la bolletta e la superficie d'attacco. Conferma il vettore con i contatori qui sopra, annota pps e banda e controlla se la tabella conntrack si sta riempiendo. Se sì, passa subito alla protezione host di emergenza T+0.

Da T+2 a T+5 minuti — elimina il carico non essenziale. Disattiva tutto ciò che non è gameplay: batching della telemetria, refresh delle classifiche, polling del negozio, feed social. Se il backend supporta la configurazione remota, basta un flag, non un deploy.

Da T+5 a T+10 minuti — applica rate limit a livello di host. Il filtraggio nel kernel è di ordini di grandezza più economico del filtraggio a livello applicativo:

table inet gameguard {
    set udp_flood {
        type ipv4_addr
        flags dynamic, timeout
        timeout 60s
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        tcp dport { 22, 443 } accept
        tcp dport 7777-7800 accept
        udp dport 7777-7800 accept

        # drop fragmented UDP - your game protocol should never need it
        ip frag-off & 0x1fff != 0 udp drop

        # per-source UDP cap well above a real client's send rate
        udp dport 7777-7800 update @udp_flood \
            { ip saddr limit rate over 200/second burst 400 packets } drop
    }
}

Carica con nft -f gameguard.nft. Verifica con nft list ruleset e nft list set inet gameguard udp_flood. Se sbagli e ti chiudi fuori, hai trasformato un incidente di rete in un incidente di accesso fisico: testalo prima in staging e tieni le regole in version control.

Da T+10 in poi — scala al tuo upstream. Ti serve capacità di scrubbing o blackhole al network edge, non sull'host. La maggior parte dei provider di game hosting gestiti la offre; se il tuo no, è un problema di procurement da risolvere prima del prossimo attacco. Chiedi esplicitamente la loro soglia di mitigazione UDP sotto 1 Gbps, perché la maggior parte degli SLA pubblicati è scritta per attacchi terabit che non vedrai mai.

Per tutto il tempo: tieni un log con timestamp. Inizio attacco, vettore, picco pps, picco Gbps, cosa hai cambiato e quando. Il postmortem vale più della mitigazione.

Playbook dei vettori: adattare la risposta alla forma

Flood UDP (31,31% degli attacchi). Porte casuali o mirate, che costringono l'host a verificare se c'è un listener e a generare ICMP unreachable. L'articolo sull'architettura di fallback a livello di rete spiega come mantenere una modalità degradata ma giocabile quando il trasporto principale è sotto attacco. Risposta: rate limit per sorgente con nftables, chiudi tutte le porte UDP che non sono la porta di gioco e disabilita la generazione di ICMP unreachable sull'host.

Amplificazione DNS (3,43%, in aumento del 215%). Query con sorgente falsificata verso resolver aperti, grandi risposte indirizzate a te. Risposta: non puoi bloccare per sorgente, perché le sorgenti sono resolver legittimi. Puoi solo assorbire o filtrare per dimensione e frequenza delle risposte. Verifica di non essere tu stesso a gestire un resolver aperto con dig +short txt chaos version.bind @your.ip — se risponde, chiudilo oggi.

CLDAP (crollato allo 0,05%). Attualmente tranquillo, storicamente enorme. Il promemoria è che l'amplificazione CLDAP gira su UDP 389, quindi a meno che tu non abbia bisogno di LDAP, tienilo filtrato sia sul firewall dell'host sia su quello cloud. Gli attaccanti tornano sulle porte non protette quando ruotano di nuovo.

SYN flood. Raramente volume, sempre esaurimento. Abilita i SYN cookies (sysctl -w net.ipv4.tcp_syncookies=1), alza net.core.somaxconn e assicurati che la tabella conntrack sia dimensionata per il tuo caso realistico peggiore, non per il default.

Prevenzione: un'architettura che sopravvive a un picco di quattro minuti

Prima i calcoli di capacità, perché eliminano molte illusioni. Un server da 64 giocatori a 100 tick muove circa 15-20 KB/s per giocatore — diciamo 1,2 MB/s, ovvero circa 10 Mbps per istanza. Un attacco da 400 Mbps è 40 volte il traffico legittimo di quell'istanza. Dato che il 98% degli attacchi è sotto 1 Gbps, quasi ogni attacco nella distribuzione attuale è abbastanza grande da spianare una singola istanza di gioco, ma troppo piccolo per interessare l'auto-mitigazione di un provider di scrubbing tier-1.

Questo vincola la tua architettura in tre modi.

Separa il piano account dal piano di gioco. Se l'endpoint di login, le letture delle classifiche e i salvataggi dei giocatori girano sullo stesso host dei server di gioco, una flood sulla porta di gioco abbatte anche gli account, e i giocatori non riescono nemmeno a vedere una schermata "torniamo subito". Eseguire quei servizi legati all'account su horizOn — autenticazione, Cloud Save e classifiche sono tutti gestiti lì — significa che un picco sulla porta di gioco degrada il gameplay senza chiudere fuori dal profilo tutti i giocatori.

Rendi la riduzione delle funzionalità un cambiamento di configurazione, non un deploy. Quando arriva la flood hai secondi. La configurazione remota ti permette di spegnere all'istante i percorsi di lettura costosi. Se la tua unica opzione è pushare una build, non lo farai.

Costruisci l'health check per vedere il guasto di rete. Un check di processo riporta "healthy" mentre il kernel scarta il 90% dei pacchetti. Sonda la raggiungibilità effettiva del gameplay — un client sintetico che esegue un handshake reale e si aspetta una risposta entro 250ms — e lascia che sia questo a guidare il failover.

Best practice: cinque modifiche da rilasciare questa settimana

1. Allerta sul packet rate, non solo sulla banda. Imposta una soglia a 2,5x il tuo pps al 95° percentile. Le allerte basate solo sulla banda perdono del tutto i picchi brevi; il rilevamento di anomalie sui pps cattura una flood da 300 Mbps su un host con link a 1 Gbps che nessun grafico di banda segnalerebbe.
2. Dimensiona la tabella conntrack con criterio. Imposta net.netfilter.nf_conntrack_max in base al picco di sessioni concorrenti, non al default della distro, e allerta al 70% di occupazione. Questa singola modifica previene l'escalation più comune da "attacco diventato outage".
3. Scrivi in anticipo il ruleset nftables e testalo ogni trimestre. Tienilo nel repo accanto alla config di deploy. Una regola firewall non testata applicata durante un incidente è un secondo incidente.
4. Pubblica ai giocatori un contratto per la modalità degradata. Se classifiche e chat si spengono per dieci minuti durante la mitigazione, dillo nelle patch notes e nella status page. Il silenzio viene letto come un gioco morto. Se vuoi un modello, i pattern di resilienza nell'analisi dell'architettura backend post-compromissione si traducono direttamente in incidenti di disponibilità.
5. Registra ogni attacco come evento strutturato. Timestamp, vettore, picco pps, picco Gbps, durata, mitigazione applicata. Dopo cinque vedrai il tuo pattern: la maggior parte dei backend indie viene colpita nello stesso giorno della settimana, alla stessa ora, dallo stesso booter.

In sintesi

Il profilo delle minacce 2026 è ostile ai team che pianificano per attacchi terabit e ignorano il picco da 400 Mbps di sei minuti. I giganti sono giù del 69%; gli sciami su del 208%. La mitigazione deve essere automatizzata, economica e nel kernel, perché nessun essere umano può agire dentro un attacco che finisce prima che l'allerta venga letta.

Inizia dai contatori, non dai dashboard. Aggiungi il rate limit per sorgente, dimensiona la tabella conntrack, separa il piano account dal piano di gioco e prova il runbook di dieci minuti finché non diventa noioso.

Se parte di quella separazione è lavoro poco glamour che preferiresti non gestire — autenticazione dei giocatori, Cloud Save con gestione delle revisioni, classifiche, configurazione remota che puoi attivare durante un incidente — è la parte che gestisce horizOn, così il tuo tempo in on-call va ai server di gioco. Provalo gratis o leggi la documentazione prima della prossima finestra di lancio.

---

Fonte: Cloudflare DDoS Threat Report 2026 Q3: più sciami, meno giganti