Che cos'è un attacco DDoS? Tecnica, livelli e difesa

Un attacco DDoS è il tentativo di rendere irraggiungibile un servizio con un sovraccarico prodotto artificialmente, portato avanti nello stesso momento da moltissimi mittenti diversi. La sigla sta per Distributed Denial of Service, cioè per un rifiuto del servizio provocato in modo distribuito. Non viene attaccato né il contenuto di un server né una falla di sicurezza nel suo software, ma una risorsa che è finita: la banda della linea, la frequenza dei pacchetti della scheda di rete, un posto in una tabella di stato del kernel oppure il tempo di calcolo che l'applicazione impiega per una singola richiesta. Quando una di queste quattro risorse è occupata, gli utenti reali non riescono più a passare, e questo senza che nessuno sia entrato nel sistema.

Questo articolo è l'introduzione al tema. Spiega i tre livelli su cui si svolgono gli attacchi, con quali fattori di amplificazione da un byte di richiesta nascono 51.000 byte di risposta, da dove arriva la capacità d'attacco e quanto costa sul mercato, da che cosa riconosci un attacco nei tuoi stessi valori misurati, che cosa aiuta ancora sul server stesso e dove passa esattamente questo confine. Tutti i numeri sono riportati con la loro fonte, così puoi verificarli. Se il tuo servizio è fermo proprio adesso, leggi per primo il paragrafo "Che cosa fare in caso di attacco" e misura, invece di mettere mano alle impostazioni.

Che cos'è tecnicamente un attacco DDoS

Ogni attacco DDoS vive di un'asimmetria: spedire un pacchetto deve costare a chi attacca meno di quanto costi al bersaglio elaborare quel pacchetto. Tutto il resto è soltanto la domanda su dove questa asimmetria sia più grande. I punti sono esattamente quattro, e ognuno ha un limite massimo rigido che si può calcolare.

La banda della linea. Una connettività da 1 Gbit/s trasporta 125 megabyte al secondo, non di più. Chi manda di più produce perdite, e le perdite colpiscono i pacchetti dei tuoi utenti esattamente come quelli di chi attacca, perché una linea piena non seleziona.

La frequenza dei pacchetti. Il pacchetto Ethernet più piccolo ammesso è lungo 64 byte e, con preambolo e intervallo fra i pacchetti, occupa 84 byte sulla linea. In 1 Gbit/s ce ne stanno circa 1,49 milioni 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. La frequenza dei pacchetti è quindi quasi sempre il limite che viene raggiunto prima della banda.

Le tabelle di stato. Il kernel tiene memoria delle connessioni TCP aperte a metà e dei flussi di pacchetti. Queste tabelle sono limitate nel numero, non in bit al secondo. Si possono riempire con pochissima banda, se ogni pacchetto porta un nuovo indirizzo mittente.

Il tempo di calcolo dell'applicazione. Una ricerca, un tentativo di accesso con verifica della password oppure un'interrogazione del server che restituisce un'intera lista delle mod costa al bersaglio mille volte più che al mittente. Qui a un attacco efficace spesso non servono nemmeno 10 Mbit/s.

DoS e DDoS: la differenza che si può misurare

La base terminologica arriva dalla RFC 4732, "Internet Denial-of-Service Considerations", una pubblicazione informativa della IETF del novembre 2006. Là si legge testualmente: "A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work." Un attacco DoS è quindi definito attraverso l'effetto, non attraverso il numero delle sorgenti. Distribuito, cioè DDoS, lo è quando queste sorgenti sono numerose e indipendenti l'una dall'altra.

In pratica la differenza conta in un punto solo: nella lunghezza della tua lista di blocco. Un attacco DoS da una sola sorgente lo fermi con una regola. Cloudflare ha documentato nel maggio 2025 un attacco che arrivava da 122.145 indirizzi sorgente diversi, da 161 paesi e da 5.433 sistemi autonomi, in media 26.855 nuovi indirizzi al secondo, con un picco di 45.097. Contro una cosa del genere non esiste lista di blocco che cresca abbastanza in fretta, e ogni voce al suo interno costa in più memoria e tempo di ricerca sull'apparato che è già sovraccarico.

La guida comune "Understanding and Responding to Distributed Denial-of-Service Attacks" di CISA, FBI e MS-ISAC suddivide gli attacchi in esattamente tre tecniche: volumetrica, di protocollo e applicativa. Questa tripartizione è la più utile che esista, perché descrive nello stesso momento quale delle tue quattro risorse venga attaccata e dove debba stare la difesa.

I tre livelli di un attacco DDoS

Attacchi volumetrici su Layer 3 e 4

Un attacco volumetrico non vuole altro che riempire la linea davanti al bersaglio. Si misura in bit al secondo. Lo strumento è di regola un UDP flood, perché UDP non prevede alcuna apertura di connessione da pretendere e perché gli indirizzi mittente si possono falsificare.

L'esempio più grande attualmente documentato in pubblico: Cloudflare segnala, per il periodo fino alla fine del 2025, un attacco respinto in automatico da 31,4 Tbit/s, durato 35 secondi. È la capacità di circa 31.400 connettività da 1 Gbit/s, tutte insieme, per un buon mezzo minuto. Nello stesso rapporto c'è un secondo valore, che rende l'ordine di grandezza più afferrabile del picco: nel 2025 lo stesso operatore ha respinto 47,1 milioni di attacchi DDoS, il 121 per cento in più rispetto all'anno precedente, in media 5.376 attacchi all'ora.

Il caso meglio documentato del maggio 2025 mostra che aspetto abbia un attacco simile quando lo si scompone: 7,3 Tbit/s di picco, 37,4 terabyte di dati in 45 secondi, cioè in media circa 830 gigabyte al secondo. Una linea da 1 Gbit/s avrebbe avuto bisogno di tre giorni abbondanti per la stessa quantità di dati. Il 99,996 per cento del traffico erano puri UDP flood, distribuiti in media su 21.925 porte di destinazione contemporaneamente, con un picco di 34.517. Questa distribuzione su tutte le porte è tipica: chi attacca non sa quale porta sia importante, quindi le prende tutte.

Attacchi di protocollo: le tabelle, non la linea

Un attacco di protocollo sfrutta il fatto che il kernel debba tenere memoria degli stati. L'esempio classico è il SYN flood: chi attacca manda pacchetti TCP con il bit SYN impostato e con indirizzo mittente falsificato, il server crea per ognuno una voce nella sua coda delle connessioni aperte a metà, risponde con SYN-ACK a un indirizzo che non ha mai risposto e aspetta. Qui si misura in pacchetti al secondo, non in gigabit.

La lunghezza di questa coda sta in net.ipv4.tcp_max_syn_backlog e su un server normale è dell'ordine delle migliaia. Una coda con 1.024 posti, con 1,49 milioni di pacchetti SYN al secondo, è piena in meno di un millisecondo. Per farlo bastano, sulla carta, 1 Gbit/s, e se il bersaglio è soltanto la tabella ne basta una frazione.

Alla stessa famiglia appartiene un procedimento descritto soltanto nel 2021: la reflection TCP attraverso apparati intermedi che mantengono lo stato. Il lavoro "Weaponizing Middleboxes for TCP Reflected Amplification" mostra che firewall e infrastrutture di censura, che seguono lo stato TCP solo a metà, rispondono a un singolo pacchetto falsificato con intere pagine di risposta. Con questo, per la prima volta, anche il TCP si può abusare per l'amplificazione, cosa che fino ad allora era considerata praticamente impossibile.

Attacchi applicativi su Layer 7

Un attacco applicativo sembra traffico normale, perché è traffico normale, solo nella quantità sbagliata. Si misura in richieste al secondo. Arriva attraverso una connessione stabilita per intero, quindi sopravvive a ogni controllo che valuti soltanto l'apertura della connessione, e ha bisogno di poca banda: 10.000 richieste HTTP al secondo sono, a seconda della dimensione della richiesta, meno di 50 Mbit/s, e bastano comunque a mettere in ginocchio un database.

Il metro di paragone si chiama HTTP/2 Rapid Reset, reso pubblico il 10 ottobre 2023 come CVE-2023-44487. La vulnerabilità sta nella capacità di multiplexing di HTTP/2: chi attacca apre un flusso di dati, manda la richiesta e interrompe subito il flusso. Il server ha già cominciato il lavoro, mentre chi attacca ha già di nuovo un posto libero nella finestra. I valori raggiunti così erano 201 milioni di richieste al secondo (Cloudflare), 398 milioni (Google) e 155 milioni (Amazon). Per confronto: l'attacco Layer 7 più grande misurato fino ad allora da Cloudflare era di 71 milioni di richieste al secondo.

Sui server di gioco il livello Layer 7 è l'apertura della connessione stessa. Nullping, QuietException e flood di handshake falsi contro le reti Minecraft non hanno quasi bisogno di banda e paralizzano interi gruppi di proxy, perché ogni pacchetto costringe il proxy a una costosa decisione di stato. Che aspetto abbiano esattamente questi schemi sta in Protezione DDoS per Minecraft e protezione Nullping.

I tre livelli a confronto

Gli attacchi reali non si attengono a questa suddivisione. Il caso più spiacevole nella pratica è l'attacco a più livelli: una parte volumetrica che tiene occupata la linea, più una parte Layer 7 che passa proprio nel momento in cui l'attenzione è sulla banda. Uno degli attacchi filtrati da KernelHost e mostrati più avanti era composto da oltre dodici schemi principali diversi nello stesso momento.

Attacchi di amplificazione: come da un byte se ne fanno 51.000

Un attacco di amplificazione è un attacco in cui chi attacca non spara lui stesso sul bersaglio, ma spinge servizi altrui, raggiungibili pubblicamente, a farlo al posto suo. Manda una piccola richiesta a un servizio aperto e come mittente inserisce l'indirizzo IP della vittima. Il servizio risponde diligentemente, solo che risponde alla vittima, e la risposta è più grande della richiesta di un multiplo.

Il rapporto fra dimensione della risposta e dimensione della richiesta si chiama Bandwidth Amplification Factor, in breve BAF. Un BAF di 50 significa che chi attacca, con 1 Gbit/s di connettività propria, dirige 50 Gbit/s sul bersaglio. Perché funzioni servono due cose insieme: un protocollo su UDP che risponda più di quanto gli venga chiesto, e la possibilità di falsificare l'indirizzo mittente. Per questo l'IP spoofing è il presupposto di ogni attacco di amplificazione e non soltanto una tattica per nascondersi.

Per chi si difende ne deriva una caratteristica sgradevole: il traffico arriva da server reali e legittimi. Sono resolver DNS reali, server di orario reali, server di gioco reali. Una lista di blocco per indirizzo sorgente o esclude mezzi paesi, oppure non ha effetto.

I fattori di amplificazione dei protocolli abusati

I fattori che seguono vengono dall'alert TA14-017A di US-CERT, oggi CISA, "UDP-Based Amplification Attacks", che dal 2014 viene ampliato di continuo. È il riferimento a cui si rifà tutto il settore.

La tabella spiega perché la lista delle porte bloccate in ogni firewall curato bene si somigli sempre. Quello che puoi fare tu è poco, ma importante: verifica con ss -lnup se sul tuo server ci sia un servizio di questa tabella aperto sulla rete. Un memcached che non sia legato a 127.0.0.1 trasforma il tuo server in un'arma contro terzi, ti costa la tua stessa banda in uscita e porta il tuo indirizzo IP su liste di blocco da cui è difficile uscire.

Perché i protocolli di interrogazione dei giochi rientrano nel gruppo

I server di gioco stanno in questa tabella con due ruoli. Sono amplificatori, perché la loro porta di query risponde a un piccolo pacchetto con nome, mappa, numero di giocatori e la lista completa delle mod. E sono vittime, perché la stessa interrogazione costa tempo di calcolo, spesso proprio sul core che porta avanti la simulazione di gioco.

Il fattore di amplificazione del protocollo Steam è basso, 5,5, quello del più vecchio protocollo Quake è alto, 63,9. L'effetto però non dipende dal solo fattore, ma dalla dimensione della risposta nel singolo caso: un server con 200 mod consegna una risposta nettamente più grande di uno senza. Bohemia Interactive documenta per Arma 3, dal 2015 sotto il ticket T83469, che bastavano già 4 Mbit/s di interrogazioni falsificate verso la porta di query Steam per congelare un server. Quattro megabit al secondo sono meno di quanto produca una singola connessione domestica.

Da qui deriva la regola che vale per ogni gioco: limitare la porta di query, non bloccarla. Chi la blocca sparisce dalla lista dei server e i nuovi giocatori non lo trovano più. Quale sia questa porta per ogni gioco e quanto stretta si possa tenere sta negli articoli specifici più in basso, per esempio per Arma 3, CS2 e i titoli Source oppure Rust.

Il caso memcached: 1,35 Tbit/s contro GitHub

Il 28 febbraio 2018 GitHub è stato irraggiungibile dalle 17:21 alle 17:26 UTC e fino alle 17:30 UTC raggiungibile solo a tratti. L'attacco ha raggiunto 1,35 Tbit/s con 126,9 milioni di pacchetti al secondo e arrivava da oltre 1.000 sistemi autonomi diversi e da decine di migliaia di singoli endpoint. È stato amplificato tramite memcached, con un fattore fino a 51.000: un byte di chi attaccava generava fino a 51 kilobyte in direzione del bersaglio.

Questo caso è ancora oggi la lezione migliore, perché mostra tre cose in una volta sola. Primo: l'amplificazione batte la dimensione della botnet. A chi attaccava non servivano centomila dispositivi, gli servivano istanze memcached aperte, e allora ce n'erano più di 90.000 in rete nel mondo. Secondo: 126,9 milioni di pacchetti al secondo sono circa 85 volte quanto una linea da 1 Gbit/s riesca in assoluto a trasportare. Nessuna impostazione sul server cambia qualcosa. Terzo: la difesa ha funzionato perché il traffico è stato dirottato in una rete di filtraggio, e il tempo di disservizio è finito così dopo nove minuti invece che dopo nove ore.

Da dove arriva la capacità per un attacco DDoS

Botnet di dispositivi compromessi

Una botnet è un insieme di dispositivi altrui, presi sotto controllo con software malevolo, che chi attacca comanda a distanza da un punto centrale. I proprietari di regola non se ne accorgono, perché il dispositivo continua a fare quello per cui è stato comprato. Vengono attaccati soprattutto gli apparecchi che stanno in rete in permanenza, che si aggiornano di rado e che portano password predefinite: router, telecamere di sorveglianza, videoregistratori di rete, box televisive.

Il metro di paragone è Mirai, il cui codice sorgente è stato pubblicato alla fine di settembre 2016. Il lavoro "Understanding the Mirai Botnet" (USENIX Security 2017) segue la rete per sette mesi e quantifica il massimo raggiunto in oltre 600.000 dispositivi infettati. L'attacco al sito di Brian Krebs nel settembre 2016 ha raggiunto 620 Gbit/s e arrivava da più di 175.000 dispositivi. Nell'attacco al gestore DNS Dyn del 21 ottobre 2016, che ha reso irraggiungibili Twitter, Spotify e Reddit nello stesso momento, sono stati contati circa 107.000 indirizzi IP attaccanti.

Nove anni dopo l'ordine di grandezza è un altro. Cloudflare riconduce l'attacco record da 31,4 Tbit/s a una botnet di dimensioni stimate fra uno e quattro milioni di dispositivi infettati, in prevalenza box televisive Android. Nell'ondata di attacchi del dicembre 2025 sono stati contati 902 attacchi ipervolumetrici, in media 53 al giorno, con picchi di 9 miliardi di pacchetti al secondo, 24 Tbit/s e 205 milioni di richieste al secondo. La dimensione delle botnet è quindi cresciuta nel giro di un decennio di un fattore 5, la banda raggiunta di un fattore 50.

Servizi booter e stresser, e quanto costa un attacco

Fra la botnet e chi commissiona l'attacco c'è un servizio che vende la capacità d'attacco in abbonamento. Questi servizi si presentano come "booter", "stresser" oppure "IP stresser" e nelle loro condizioni d'uso sostengono di servire al test di carico dei sistemi propri. Non verificano mai se il bersaglio inserito appartenga all'utente, ed è esattamente questa la differenza fra uno strumento e un'offerta.

L'uso è un'interfaccia web con tre campi: bersaglio, porta, durata. Ci sono procedure di pagamento, assistenza clienti e programmi per rivenditori. I pacchetti di ingresso stanno intorno ai 10 o 20 euro al mese, i pacchetti più grandi, con più banda e durata d'attacco maggiore, a qualche centinaio di euro al mese. Con questo è risolta la domanda sul perché vengano colpiti anche i progetti piccoli: un attacco che costa a un server di gioco il sabato sera costa a chi lo lancia meno di due biglietti del cinema e nessuna conoscenza tecnica.

Dall'altra parte c'è una pressione investigativa permanente. Nella settimana d'azione dell'operazione internazionale PowerOFF, nell'aprile 2026, le autorità di 21 paesi hanno preso il controllo di 53 domini di servizi di questo tipo, arrestato quattro persone e svolto 25 perquisizioni. Gli inquirenti hanno così ottenuto accesso ai dati di oltre tre milioni di account utente, e più di 75.000 utenti identificati sono stati contattati. Nel dicembre 2024, nella stessa operazione, erano state chiuse 27 piattaforme. Chi paga un servizio del genere lascia quindi una traccia di pagamento in una banca dati che prima o poi viene sequestrata.

Da che cosa riconosci un attacco DDoS

Che cosa segnalano gli utenti, e che cosa dice già questo

La prima informazione arriva quasi sempre dagli utenti, ed è più utilizzabile di quanto sembri. Quattro segnalazioni hanno un significato chiaro:

• "Siamo saltati fuori tutti nello stesso momento." Un'interruzione simultanea per tutti gli utenti parla per la linea o per il processo del servizio, non per singole connessioni. Un problema di carico colpisce gli utenti uno dopo l'altro.
• "Il ping salta da 20 a 400 e torna indietro." Una latenza che oscilla mentre la connessione resta in piedi è lo schema di una coda piena davanti al bersaglio, non di un processo sovraccarico.
• "La lista dei server ci mostra offline, ma io riesco a collegarmi." Questo è l'indizio di un flood di query: la porta di query non risponde più, la porta di gioco sì.
• "Dalla rete mobile entro, dalla mia connessione no." Un comportamento diverso a seconda della rete di accesso indica che non è saturo il tuo server, ma una strada che porta fino a lui.

I quattro valori da misurare sul server

Poi si misura, e proprio in quest'ordine: frequenza dei pacchetti, banda, stati delle connessioni, contatori dei pacchetti scartati. L'indicatore di carico della CPU viene per ultimo, perché in un attacco di rete resta spesso poco appariscente.

sar -n DEV 1 10
ip -s link show eth0
ss -s
ss -tn state syn-recv | wc -l
nstat -az TcpExtListenDrops TcpExtListenOverflows TcpExtTCPReqQFullDrop UdpRcvbufErrors UdpInErrors UdpNoPorts
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

sar -n DEV 1 10 fornisce pacchetti e byte al secondo per interfaccia su dieci secondi. Decisivo è il rapporto: molti pacchetti con pochi byte significa pacchetti piccoli, quindi un attacco di protocollo. Pochi pacchetti con moltissimi byte significa pacchetti grandi, quindi un attacco di amplificazione. ip -s link show mostra nelle colonne dropped e overrun se il kernel stia già scartando. ss -tn state syn-recv conta le connessioni aperte a metà: un valore a tre cifre è normale, uno a cinque cifre è un SYN flood. E nstat fornisce i contatori che restano anche quando l'attacco è finito.

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 non puoi dire se 40.000 pacchetti al secondo siano tanti oppure semplicemente un sabato sera. Con apt-get install -y vnstat sysstat la misurazione resta sempre attiva. La guida dettagliata all'interpretazione sta in Riconoscere un attacco DDoS.

Le righe di log che non lasciano dubbi

Quattro messaggi nel log del kernel e nel log del server web sono praticamente una prova. dmesg -T | tail -50 mostra i primi tre:

kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
kernel: net_ratelimit: 2247 callbacks suppressed
nginx: [alert] 1123#1123: 768 worker_connections are not enough

La prima riga significa che la coda delle connessioni aperte a metà è traboccata e che il kernel è passato ai SYN cookie. Se lì c'è invece Dropping request, net.ipv4.tcp_syncookies è impostato a 0 e il server scarta richieste, comprese quelle vere. La seconda riga significa che il tracciamento delle connessioni è pieno, e da quel momento il server scarta anche il traffico legittimo. La terza riga è un effetto collaterale: il kernel sopprime i messaggi, perché altrimenti sarebbe occupato a scrivere log. La quarta riga sposta il problema dentro l'applicazione.

Nel log degli accessi del server web due cose sono significative. Una quota improvvisa del codice di stato 499 significa che il client chiude la connessione prima che la risposta sia pronta, ed è esattamente quello che fa un attacco Layer 7 che vuole soltanto generare lavoro e non leggere. E un campo referrer vuoto in quasi tutte le richieste distingue un attacco da un vero afflusso di visitatori, che porta con sé referrer da motori di ricerca e reti sociali.

La controprova: attacco, afflusso oppure errore tuo

Che cosa aiuta sul server stesso

Sul server si ottiene più di quanto spesso si dica, e cioè contro tutto ciò che resta piccolo: bot fatti male, sorgenti singole, flood di query e attacchi applicativi. Gli strumenti sono nftables, il tracciamento delle connessioni, i SYN cookie e una limitazione della frequenza per indirizzo sorgente. Tutte le indicazioni che seguono valgono per Debian 12, Debian 13, Ubuntu 22.04 LTS e Ubuntu 24.04 LTS e sono scritte per root.

nftables: scartare presto, calcolare poco

Il principio è questo: un pacchetto destinato a essere scartato va scartato il prima possibile e nel modo più economico possibile. Ogni regola che gira prima costa tempo di calcolo moltiplicato per la frequenza dei pacchetti. Il set di regole che segue, per /etc/nftables.conf, lascia passare un server web e un servizio di gioco e scarta il resto, con una limitazione della frequenza per le nuove connessioni TCP per indirizzo sorgente:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set newconn {
        type ipv4_addr
        size 131072
        flags dynamic,timeout
        timeout 1m
    }

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

        iif lo accept
        ct state established,related accept
        ct state invalid counter drop

        ip saddr @adminips tcp dport 22 accept

        tcp dport { 80, 443 } ct state new add @newconn { ip saddr limit rate over 30/second burst 60 packets } counter drop
        tcp dport { 80, 443 } accept

        udp dport 25565 accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward { type filter hook forward priority filter; policy drop; }
    chain output  { type filter hook output  priority filter; policy accept; }
}

Inserisci sotto adminips il tuo indirizzo fisso prima di caricare, altrimenti ti chiudi fuori da SSH. La verifica e l'attivazione si fanno così:

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset
nft list set inet filter newconn

Tre punti decidono dell'efficacia. ct state established,related accept sta di proposito come seconda regola, perché le connessioni esistenti non attraversino l'intero set di regole. ct state invalid counter drop elimina le combinazioni di flag errate e i frammenti in ritardo, senza che tu debba descriverli uno per uno. E counter prima di ogni drop è il motivo per cui dopo sai quale regola abbia fatto effetto: se i contatori restano a zero, la regola non viene raggiunta, e questa è una diagnosi completamente diversa da un set di regole inefficace.

SYN cookie e il limite del backlog

I SYN cookie sono un procedimento con cui il server non tiene memoria di una connessione aperta a metà, ma scrive i dati necessari, cifrati, nel proprio numero di risposta. Quando torna il terzo pacchetto dell'apertura di connessione, il server ricalcola da lì lo stato. Così la coda non trabocca più, perché per queste connessioni non esiste alcuna coda.

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216

Questi valori vanno in un file sotto /etc/sysctl.d/ e si applicano con sysctl --system, altrimenti dopo il prossimo riavvio spariscono. Su Debian e Ubuntu tcp_syncookies è di serie a 1, ed è giusto così. Il valore 1 non significa "sempre cookie", ma "cookie non appena la coda trabocca".

Il prezzo di tutto questo è reale e viene detto di rado. In un cookie non c'è posto per le opzioni TCP della controparte. Linux salva l'ingrandimento della finestra e la conferma selettiva soltanto se net.ipv4.tcp_timestamps è a 1, perché in quel caso quei dati viaggiano nel timestamp. Senza timestamp vanno persi, e la connessione resta più lenta per tutto il resto della sua durata. In più, per la dimensione massima dei pacchetti sono disponibili soltanto tre bit, quindi otto gradini grossolani invece del valore esatto. I SYN cookie sono un funzionamento d'emergenza che salva le connessioni, non un'impostazione per la normalità.

conntrack: la tabella che si riempie per prima

Il tracciamento delle connessioni del kernel crea una voce per ogni flusso di pacchetti, anche per UDP, benché UDP non conosca connessioni. È proprio questa tabella, in un attacco distribuito, la prima risorsa a finire, e finisce molto in fretta: con 1,49 milioni di pacchetti al secondo, ciascuno con un nuovo indirizzo mittente, una tabella con 262.144 posti è piena in meno di un quinto di secondo.

net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

Una voce occupa circa 300 byte, quindi 524.288 voci occupano circa 150 megabyte di memoria del kernel. La dimensione della tabella hash non si imposta con sysctl, ma come parametro del modulo, di solito a un quarto del limite massimo, in /etc/modprobe.d/nf_conntrack.conf:

options nf_conntrack hashsize=131072

Per un server puramente di gioco o vocale la soluzione più elegante è non far tracciare affatto il traffico di gioco. Così si risparmia del tutto la tabella:

nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority raw; }'
nft add rule ip raw prerouting udp dport 25565 notrack

Attenzione: notrack e le regole che tengono conto dello stato si escludono a vicenda. Chi esclude una porta dal tracciamento non può più usare per quella porta alcuna regola con ct state, altrimenti l'apertura non ha più effetto e il servizio resta chiuso.

Limitazione della frequenza per indirizzo sorgente

Una limitazione della frequenza per indirizzo sorgente è la singola misura più efficace sul server, perché colpisce esattamente quello che fa chi attacca e lascia passare esattamente quello che fa un utente. La differenza è grande: un browser dei server reale interroga qualche volta al minuto, chi attacca centinaia di volte al secondo. Con nftables si lavora per questo con insiemi dinamici, come nel set di regole più sopra, con il classico iptables con hashlimit:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27015 -m length --length 0:27 -j DROP

Tutti i numeri in regole di questo tipo sono valori di partenza, non verità assolute. Misura prima una settimana di funzionamento normale, altrimenti butti fuori i tuoi stessi utenti, e nel momento peggiore. Tieni inoltre presente che le semplici regole iptables spariscono dopo un riavvio (apt-get install -y iptables-persistent, poi netfilter-persistent save) e che con UFW vanno in /etc/ufw/before.rules, altrimenti al prossimo ufw reload spariscono. Il set di regole completo per il funzionamento quotidiano sta in Proteggere il server dagli attacchi DDoS.

Dove finisce ogni filtraggio sul server

Adesso la parte che nessun file di configurazione risolve. 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. Se la linea a monte è piena, i pacchetti dei tuoi utenti si fermano già prima, e questo a prescindere da quanto sia buono il tuo set di regole.

Questa tabella risponde caso per caso alla domanda se l'autoprotezione basti. L'attacco a GitHub, con 126,9 milioni di pacchetti al secondo, entra a stento come frequenza dei pacchetti in una connettività da 100 Gbit/s, ma con 1,35 Tbit/s di volume ne servirebbero quattordici contemporaneamente. L'attacco record da 31,4 Tbit/s corrisponde a 314 connettività da 100 Gbit/s completamente sature. Un server di gioco è tipicamente collegato a 1 Gbit/s oppure a due volte 1 Gbit/s: il limite dell'autoprotezione sta quindi intorno a 1,5 o 3 milioni di pacchetti al secondo, e in pratica nettamente più in basso, perché il kernel molla prima.

C'è poi un secondo limite, ancora più spiacevole. Non appena la linea è satura, può darsi che non ti raggiunga nemmeno la sessione SSH con cui volevi misurare. Chi a quel punto non ha un accesso indipendente dalla rete, per esempio una console VNC nell'area clienti, non riesce nemmeno più a guardare che cosa stia succedendo.

Che cosa aiuta solo prima del server: filtraggio nella rete e scrubbing

Può filtrare davvero solo chi ha più capacità dell'attacco. Questo presuppone un punto in cui confluiscono molte linee, quindi una rete e non una macchina. Là ci sono due procedimenti che si completano a vicenda.

Filtraggio in tempo reale nella rete. Tutto il traffico passa in permanenza attraverso uno stadio di filtraggio che valuta ogni pacchetto prima di consegnarlo al server. Il vantaggio è che non c'è alcuna commutazione: la protezione non deve prima riconoscere un attacco per avere effetto. È proprio questo a decidere nei giochi, perché un tempo di commutazione di due minuti è una partita persa, e un tempo di commutazione di due minuti contro un attacco che dura 35 secondi non è affatto una difesa.

Scrubbing. Se la rete riconosce un grande attacco volumetrico, il traffico interessato viene deviato verso centri di filtraggio, là ripulito delle parti dannose e poi consegnato in direzione del bersaglio. Il senso di questa deviazione è la vicinanza: il traffico d'attacco finisce nel punto in cui entra, invece che soltanto al datacenter. Le regole di filtraggio vengono per questo distribuite nella rete, descritte tecnicamente nella RFC 8955 come Flow Specification.

La contromisura strutturale contro gli indirizzi mittente falsificati è del resto nota dall'anno 2000 e sta nella RFC 2827, il BCP 38: chi collega un cliente scarta a quel confine tutti i pacchetti il cui indirizzo mittente non appartenga a quel cliente. La RFC 3704 estende la cosa alle reti collegate a più operatori. Se tutti gli operatori di rete lo applicassero, l'intera classe degli attacchi di amplificazione sarebbe liquidata. Non lo è, perché basta che alcuni non lo facciano.

E c'è un terzo metodo che bisogna conoscere, perché viene spesso venduto come protezione: il null-routing, tecnicamente Remote Triggered Black Hole Filtering secondo la RFC 5635. In questo caso l'indirizzo IP attaccato viene annunciato nella rete come irraggiungibile, e tutto il traffico diretto a lui viene scartato, quello d'attacco come quello dei tuoi utenti. Questo protegge la rete del provider, 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.

Che cosa mette davanti KernelHost

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 è permanente ed è attiva dal momento della consegna del server, quindi non ci sono minuti iniziali di un attacco in cui il servizio sparisce. E non viene usato il null-routing: il tuo indirizzo IP resta in rete e vengono scartati solo i pacchetti dannosi. Quali giochi e protocolli abbiano profili di filtro propri 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, ogni sera alla stessa ora e con schemi che cambiano. 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 porta di gioco e che cosa sulla porta di query, e puoi così sfruttare esattamente l'asimmetria descritta nel paragrafo sui protocolli di interrogazione.
• 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 servizio, così come per applicazioni modificate e scritte da te su porte TCP o UDP a piacere.

La Advanced DDoS Protection si rivolge ai clienti KernelHost e presuppone un server presso KernelHost. Se il tuo progetto gira attualmente altrove e là viene attaccato con regolarità, la strada è il trasferimento qui, non un'assistenza a distanza del tuo indirizzo attuale.

I due livelli a confronto

Sei attacchi reali filtrati in produzione

I sei attacchi che seguono hanno colpito server di clienti KernelHost e sono stati filtrati interamente in tempo reale, ogni volta senza alcun disservizio. Le immagini vengono dal monitoraggio live della difesa.

Server vocale TeamSpeak 3, porta 9987 UDP. Attacco complesso con più schemi contemporanei, oltre 473,4 Gbit/s e oltre 41,5 milioni di pacchetti al secondo. È circa 28 volte la frequenza dei pacchetti di una connettività da 1 Gbit/s.

Game server ARK, porta 7777 UDP. Semplice UDP flood senza struttura complessa, in compenso oltre 112,2 Gbit/s e oltre 8,7 milioni di pacchetti al secondo. Come si metta in sicurezza un cluster ARK sta in Proteggere un server ARK dagli attacchi DDoS.

Attacco su tutte le porte, da 0 a 65535 TCP e UDP. Oltre dodici schemi d'attacco principali diversi contro tutte le porte nello stesso momento, in totale oltre 21,3 Gbit/s e oltre 3,9 milioni di pacchetti al secondo. Questo caso mostra la dispersione su tutte le porte che si ritrova anche nel caso Cloudflare del maggio 2025, con una media di 21.925 porte di destinazione.

Minecraft e OpenVPN, porte 25565 TCP e 1194 UDP. Attacco combinato con oltre sedici schemi d'attacco principali diversi, oltre 4 milioni di pacchetti al secondo e oltre 8,6 Gbit/s. Entrambi i servizi sono rimasti raggiungibili senza interruzioni, pur parlando protocolli diversi.

UDP flood contro una singola porta di servizio, otto minuti. Il più duro dei sei casi: 745,5 Gbit/s e 73,1 milioni di pacchetti al secondo, circa 49 volte la frequenza dei pacchetti di una connettività da 1 Gbit/s. Il 99,93 per cento del traffico era diretto a una sola porta di destinazione, le sorgenti erano completamente distribuite. Dopo otto minuti l'attacco era finito, il servizio è rimasto raggiungibile senza interruzioni.

Attacco prolungato nell'arco di tre ore e 31 minuti. 501,2 Gbit/s e 43,9 milioni di pacchetti al secondo, non come picco isolato, ma come una successione di ondate senza pause. Sette schemi d'attacco contemporanei, fra cui amplificazione via SSDP, MS SQL RS, L2TP e RIPv1. Le porte di destinazione si sono disperse su tutto l'intervallo da 1024 a 65535, quindi cambiare porta non sarebbe servito a nulla. Di più su entrambi i casi in Quanto dura un attacco DDoS.

Che cosa fare in caso di attacco, in quest'ordine

L'ordine conta più dei singoli passi, perché gli errori più frequenti succedono nei primi cinque minuti.

1. Misurare, non mettere mano alle impostazioni. Metti prima al sicuro in un file i valori di sar -n DEV 1 10, ip -s link show, ss -s e dmesg -T. Dopo l'attacco non ci sono più, e senza di essi nessuno può aiutarti.
2. Non riavviare. Un riavvio cancella tutti i contatori, tutti gli stati delle connessioni e ogni prova, e il carico torna dopo pochi secondi.
3. Stabilire di quale livello si tratti. I byte divisi per i pacchetti danno la dimensione media dei pacchetti. Sotto i 100 byte indica un attacco di protocollo, sopra i 1.000 byte un attacco di amplificazione, dimensioni normali con carico della CPU alto indicano il Layer 7.
4. Chiudere le porte di amministrazione. Pannello, database, RCON e tutto ciò che non deve essere pubblico va limitato al tuo indirizzo. Questo riduce subito la superficie d'attacco e senza rischi per gli utenti.
5. Impostare una limitazione della frequenza, stretta sulla porta di query e larga sulla porta di utilizzo. Non bloccare la porta di query, altrimenti sparisci da ogni lista dei server.
6. Non cambiare il proprio indirizzo troppo in fretta. Un cambio di indirizzo funziona solo finché il nuovo indirizzo non torna pubblico, e un vecchio record DNS dimenticato rende il cambio inutile.
7. Coinvolgere il provider con i numeri alla mano. Apri un ticket con orario, porta di destinazione, frequenza dei pacchetti, banda e dimensione media dei pacchetti. Sono questi cinque dati a decidere quanto in fretta vengano affinate le regole di filtraggio per il tuo indirizzo.
8. Documentare dopo. Annota quando è cominciato, quanto è durato e quale schema fosse. Gli attacchi che si ripetono alla stessa ora sono il criterio per capire se un progetto abbia bisogno di un IP di protezione dedicato.

Il procedimento dettagliato per un attacco pesante e di lunga durata sta in Attacco DDoS pesante: che cosa fare.

Quadro giuridico: un attacco DDoS è un reato

In Austria un attacco DDoS ricade sotto il § 126b del codice penale austriaco (StGB), "disturbo della funzionalità di un sistema informatico". La fattispecie base prevede la reclusione fino a sei mesi oppure una pena pecuniaria fino a 360 quote giornaliere. Se il disturbo dura per un periodo prolungato, si arriva a due anni. Se vengono attaccati molti sistemi con un programma palesemente creato a tale scopo, si arriva a tre anni. E in caso di danno superiore a 300.000 euro, di attacco a infrastrutture critiche oppure di partecipazione a un'associazione criminale, la cornice va da sei mesi a cinque anni. In aggiunta il § 126c StGB punisce già la produzione, la diffusione e la messa a disposizione dei programmi destinati allo scopo.

In Germania si applica il § 303b StGB, "sabotaggio informatico": fino a tre anni di reclusione oppure una pena pecuniaria, fino a cinque anni quando l'elaborazione dei dati serve a un esercizio, a un'impresa o a un'autorità, e nei casi particolarmente gravi da sei mesi a dieci anni, per esempio in caso di attività professionale oppure di pregiudizio a infrastrutture critiche. Il tentativo è punibile, e per gli atti preparatori il § 303b comma 5 StGB rinvia al § 202c StGB.

I servizi booter e stresser non sono quindi una zona grigia, ma la parte pagata di un reato. Tre punti vengono fraintesi con regolarità. Primo, l'avvertenza "solo per test di carico dei sistemi propri" non rende legale nulla, perché quei servizi non verificano a chi appartenga il bersaglio inserito. Secondo, è punibile anche chi commissiona l'attacco, non soltanto chi gestisce il servizio: dopo la settimana d'azione dell'aprile 2026 Europol ha scritto espressamente a più di 75.000 utenti identificati proprio per chiarirlo. Terzo, nemmeno un test di carico sul proprio server attraverso un servizio del genere è una soluzione, perché il traffico d'attacco passa per la rete del provider e quindi per le linee di altri clienti, cosa che ogni contratto di hosting vieta. Chi vuole davvero misurare la resistenza del proprio servizio lo fa con preavviso e d'accordo con il provider. Questo paragrafo riporta lo stato della legge e non è una consulenza legale.

La guida giusta per il tuo servizio

Questo articolo spiega il principio. Quale porta debba restare aperta, quale direttiva di configurazione limiti quale interrogazione e dove stia il limite per il singolo gioco: questo sta negli articoli sul singolo servizio, ognuno con la tabella dei dati sulle porte.

• Basi e procedura: Riconoscere un attacco DDoS, Proteggere il server dagli attacchi DDoS, Attacco DDoS pesante: che cosa fare, Protezione DDoS per i giochi con filtraggio in tempo reale
• Minecraft e voce: Minecraft e Nullping, Minecraft Bedrock, TeamSpeak 3, Hytale
• Roleplay su base GTA: FiveM, RedM, RAGE MP e alt:V, SA-MP e open.mp, MTA:SA
• Sopravvivenza e costruzione: Rust, ARK, DayZ, Palworld, Conan Exiles, Project Zomboid, Terraria, Unturned
• Tattica e sparatutto: CS2 e Source, Arma 3, Call of Duty, Team Fortress 2, Left 4 Dead 2, Garry's Mod, Mordhau, Lineage 2

In breve

• Un attacco DDoS occupa una di quattro risorse finite: banda, frequenza dei pacchetti, una tabella di stato del kernel oppure il tempo di calcolo dell'applicazione. Non sfrutta alcuna falla di sicurezza, quindi aggiornare da solo non protegge.
• La RFC 4732 definisce un attacco DoS attraverso l'effetto, non attraverso il numero delle sorgenti. Distribuito lo si chiama quando le sorgenti sono numerose: nel caso Cloudflare del maggio 2025 erano 122.145 indirizzi da 161 paesi.
• CISA, FBI e MS-ISAC distinguono tre tecniche: volumetrica in Gbit/s, di protocollo in pacchetti al secondo, applicativa in richieste al secondo. Ognuna richiede una difesa diversa.
• Gli attacchi di amplificazione abusano di servizi UDP aperti. I fattori vanno da 5,5 del protocollo Steam, passando per 30,8 di SSDP e 556,9 di NTP, fino a 51.000 di memcached, come riportato nell'alert US-CERT TA14-017A.
• La capacità arriva da botnet di dispositivi compromessi, da 600.000 di Mirai nel 2016 fino a un numero stimato fra uno e quattro milioni dietro l'attacco record da 31,4 Tbit/s, e viene rivenduta a partire da circa 10 euro al mese.
• Sul server funzionano nftables, i SYN cookie, limiti di conntrack adattati e una limitazione della frequenza per indirizzo sorgente. Finiscono intorno a 1,5 milioni di pacchetti al secondo, perché una connettività da 1 Gbit/s non ne trasporta di più.
• Oltre questo limite decide esclusivamente il filtraggio nella rete prima del server. Il null-routing non è una difesa, ma il risultato che chi attacca voleva ottenere.
• Su KernelHost la protezione permanente a due livelli è inclusa in ogni pacchetto server senza sovrapprezzo ed è attiva dalla consegna, senza null-routing: 17 Tbps di capacità di mitigazione nella rete di scrubbing globale più filtraggio Arbor in tempo reale da 3,2 Tbps a Francoforte sul Meno. La Advanced DDoS Protection la completa a partire da 50,00 € al mese con un IP di protezione dedicato e regole per porta gestibili da te.
• Un attacco DDoS è punibile in Austria secondo il § 126b StGB e in Germania secondo il § 303b StGB, per chi lo commissiona esattamente come per chi gestisce i servizi.

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 con i cinque dati del passo 7, 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.