Il DDoS dura pochi minuti. Il guasto può durare molto di più

Un attacco si ferma, la dashboard torna verde, il traffico sembra normale. Eppure l’applicazione continua a rispondere lentamente, alcuni utenti ricevono errori, le code sono gonfie e qualcuno sta ancora cercando di capire se sia il momento di riavviare qualcosa. È una situazione possibile, non la cronaca di un incidente specifico. Ma racconta meglio di molti record in terabit al secondo che cosa significhi davvero difendere un servizio: non basta che l’attacco sia finito; bisogna verificare che il sistema abbia recuperato.

Il DDoS Threat Report Q3 2026 di Cloudflare, pubblicato il 29 ottobre, offre un dato che dovrebbe far riflettere chi progetta applicazioni e infrastrutture: il 96% degli attacchi DDoS a livello di rete mitigati sulla sua infrastruttura termina in meno di dieci minuti. Dieci minuti sono tanti per un cliente che non riesce a completare un pagamento, ma pochissimi per una catena di allarmi, reperibilità, diagnosi e interventi manuali.

La notizia non è che gli attacchi siano diventati piccoli

Nel terzo trimestre 2026 Cloudflare dichiara di aver mitigato 18,2 milioni di attacchi DDoS a livello rete, in media circa 8.226 ogni ora. Aggiunge 14,4 trilioni di richieste HTTP DDoS: attenzione, sono richieste e non altri 14,4 trilioni di attacchi. Mettere le due cifre nella stessa somma sarebbe un modo spettacolare per produrre un numero privo di significato.

Il 98% degli attacchi network-layer rilevati rimane sotto 1 Gbps. La tentazione è chiamarli “piccoli”. Ma piccolo rispetto a cosa? Rispetto a una rete di mitigazione globale, certo. Non necessariamente rispetto alla connettività disponibile all’origine, alla capacità di un firewall, alla tabella delle connessioni di un apparato o al numero di richieste che un’applicazione riesce a elaborare senza saturare database e pool di worker.

Nello stesso trimestre gli attacchi superiori a 1 Tbps scendono a 251, contro gli 805 del trimestre precedente: una riduzione di circa il 69%. È un cambiamento rilevante, ma non autorizza a concludere che il problema DDoS sia in ritirata. Nel complesso il numero di attacchi a livello rete osservati da Cloudflare cresce del 208% rispetto al terzo trimestre 2025. Sono grandezze diverse, finestre temporali diverse e, soprattutto, distribuzioni che possono cambiare anche quando la minaccia resta operativamente seria.

Il tempo dell’attacco e il tempo del disservizio non coincidono

Immaginiamo una raffica di traffico che satura un collegamento per tre minuti. Il traffico ostile cessa, ma nel frattempo alcuni client hanno ritentato più volte, i timeout hanno prodotto nuove richieste, le connessioni verso il database sono rimaste occupate e un sistema di code ha accumulato lavoro. Anche quando il collo di bottiglia iniziale scompare, gli effetti secondari possono impiegare più tempo a riassorbirsi. Non è una conseguenza inevitabile di ogni DDoS: è uno scenario architetturale da misurare, non da presumere.

Cloudflare aveva già evidenziato nel suo rapporto sul primo semestre 2026 possibili effetti a cascata come instabilità del routing, ritrasmissioni TCP, timeout applicativi e degradazioni successive alla raffica. Il punto è importante: l’evento di sicurezza e l’incidente di disponibilità possono avere durate differenti. Il primo può essere terminato mentre il secondo richiede ancora recupero.

La protezione che blocca il traffico ostile è una componente della resilienza. La prova della resilienza è che il servizio continui a funzionare, o torni a farlo nei tempi promessi.

Il grafico del provider non è la tua esperienza utente

Un report come quello di Cloudflare è prezioso, ma va letto per quello che misura: telemetria della rete Cloudflare, non un censimento di tutti gli attacchi avvenuti su Internet. Un attacco mitigato dal provider non equivale automaticamente a un disservizio percepito dall’utente; allo stesso modo, una richiesta bloccata all’edge non dimostra che tutti i percorsi verso l’origine siano protetti.

È la stessa distinzione affrontata parlando di WAF e prove end-to-end: contare le richieste respinte non basta per certificare la sicurezza del sistema sottostante. Nel caso dei DDoS, la misura che conta per chi gestisce un prodotto è anche un’altra: quante operazioni legittime sono andate a buon fine mentre la protezione lavorava?

Per rispondere servono indicatori correlati: tasso di errori applicativi, latenza ai percentili alti, saturazione dei collegamenti e delle risorse, backlog delle code, tempi di risposta dei servizi dipendenti, disponibilità delle funzioni critiche. La quantità di traffico mitigato è un segnale utile, non il sostituto di questi indicatori.

Tre orologi, non un unico cronometro

1. Tempo di rilevazione

Quanto passa tra l’inizio del comportamento anomalo e il momento in cui il sistema lo identifica? Un alert che arriva dopo sette minuti su un attacco durato quattro non è necessariamente inutile per l’analisi, ma non può essere il meccanismo principale di mitigazione. Le regole devono poter reagire automaticamente, con soglie e controlli che evitino di trattare i clienti legittimi come aggressori.

2. Tempo di mitigazione

Quanto impiega la difesa a ridurre il traffico dannoso senza bloccare quello buono? Qui contano la posizione della protezione, il percorso effettivo del traffico, i limiti di capacità a monte e la distinzione tra layer 3/4 e layer 7. Un filtro HTTP non risolve da solo la saturazione di un link prima che i pacchetti arrivino all’edge. Viceversa, assorbire un flood UDP non garantisce che un endpoint applicativo costoso non sia sotto pressione.

3. Tempo di recupero del servizio

Quanto tempo serve perché login, checkout, API e operazioni di business tornino ai livelli attesi? Questo è il cronometro che il cliente percepisce. Se il traffico malevolo è stato fermato alle 10:03 ma il checkout torna utilizzabile alle 10:21, il recupero ha richiesto altri diciotto minuti. L’esempio è ipotetico, ma la metrica è concreta: va misurata dalla prospettiva delle transazioni, non ricavata dall’ora di chiusura dell’allarme.

Un’architettura non si mette in sicurezza con un solo interruttore

La mitigazione efficace è distribuita su più livelli. A monte serve capacità di assorbimento e filtraggio del traffico di rete. All’edge occorrono regole adattive, rate limiting mirato e protezione delle risorse più costose. All’origine bisogna evitare che il traffico legittimo residuo provochi un collasso per effetto dei retry, dei timeout o della concorrenza non governata. Sul piano applicativo contano circuit breaker, limiti espliciti, backpressure, code con capacità finita e modalità di degradazione controllata.

Non è una lista di prodotti da acquistare. È una serie di confini da verificare. Un rate limit impostato senza conoscere il comportamento reale dei clienti può danneggiare il servizio quanto una regola troppo permissiva. Un autoscaling che rincorre richieste ostili può trasformare il problema di disponibilità in una fattura. Una cache configurata male può scaricare sull’origine proprio il carico che avrebbe dovuto assorbire: una dinamica che ho discusso anche nel caso Cloudflare e il costo nascosto della cache.

La domanda operativa non è “abbiamo un anti-DDoS?”, ma “quale percorso può ancora saturarsi, con quali effetti sulle funzioni critiche e come dimostriamo che il sistema recupera?”. A questa domanda non risponde una dashboard da sola. Rispondono test controllati, metriche coerenti e un piano di ripristino che non richieda di inventare la procedura durante l’incidente.

I vettori cambiano: le difese non possono restare una fotografia

Nel Q3 Cloudflare registra un crollo del 99,5% dei flood CLDAP rispetto al trimestre precedente, mentre l’amplificazione DNS cresce del 215% e i flood UDP generici del 122%. Le percentuali descrivono il mix di attacchi osservato dal provider, non una migrazione perfettamente tracciata degli stessi aggressori. Però mostrano bene il limite delle difese costruite attorno a una sola tecnica: quando cambia il traffico, cambiano anche le condizioni da riconoscere.

Cloudflare osserva inoltre che il calo degli attacchi sopra 1 Tbps coincide con le operazioni contro quattro grandi botnet IoT. Il Dipartimento di Giustizia statunitense ha documentato il 19 marzo 2026 interventi contro Aisuru, KimWolf, JackSkid e Mossad. È corretto collegare temporalmente i due eventi; non sarebbe corretto trasformare la coincidenza in una prova causale. Le infrastrutture criminali si frammentano, cambiano operatori e vettori: la resilienza non può dipendere dalla speranza che l’ultima operazione di polizia abbia risolto il problema.

Il test che farei prima del prossimo incidente

Partirei da una funzione di business precisa, per esempio completare un ordine, e definirei prima i livelli accettabili di errore e latenza. Poi verificherei, in un ambiente autorizzato e con prove non distruttive, che cosa accade quando la connettività peggiora, quando un servizio dipendente rallenta e quando le code raggiungono il limite. Non serve simulare un attacco reale contro Internet per scoprire che il proprio checkout non gestisce i timeout o che un retry infinito può moltiplicare il lavoro.

Misurerei tre momenti separati: quando il sistema rileva l’anomalia, quando la protezione riduce il carico dannoso e quando la transazione torna a funzionare. Registrerei anche i falsi positivi, perché bloccare tutti è il modo più facile di ottenere una percentuale perfetta di richieste malevole respinte. E il modo più rapido di perdere i clienti.

Se c’è una lezione da portare a casa dai numeri del terzo trimestre 2026, non è che serva comprare la protezione con il numero più grande di terabit sulla brochure. È che il tempo di reazione umano non è una strategia sufficiente per eventi che si consumano in pochi minuti. L’automazione deve proteggere, l’osservabilità deve spiegare e l’architettura deve saper recuperare. Altrimenti abbiamo soltanto imparato a dichiarare concluso un attacco mentre il problema, per chi usa il servizio, è ancora aperto.