L’attività DDoS si è orientata verso gli sciami nel terzo trimestre 2026
L’attività DDoS nel terzo trimestre del 2026 si è spostata verso un maggior numero di sciami e un minor numero di attacchi giganteschi, secondo un rapporto sulle minacce pubblicato da Cloudforce One di Cloudflare il 29 ottobre 2026. DDoS significa distributed denial of service, un attacco nel quale il traffico proveniente da molte fonti sovraccarica un servizio online e impedisce agli utenti legittimi di raggiungerlo. La valutazione principale del rapporto suggerisce che le organizzazioni debbano considerare il numero e la distribuzione degli attacchi, non soltanto le dimensioni del picco di traffico più elevato.
Cloudflare associa il rapporto a botnet, sicurezza e threat intelligence. Una botnet è un insieme di dispositivi connessi a Internet che possono essere controllati in modo coordinato, spesso senza che i proprietari ne siano consapevoli. La parola «sciame» non costituisce di per sé una misura standard dell’intensità DDoS, ma, insieme alla classificazione botnet, indica un’attività coordinata che coinvolge più fonti. Il titolo di Cloudflare indica una tendenza anziché un confronto numerico, quindi non deve essere considerato una prova di uno specifico numero di attacchi, volume di traffico, durata o tasso di variazione.
La distinzione tra sciami e attacchi giganteschi è importante dal punto di vista operativo. Un attacco DDoS gigantesco può essere inteso principalmente come un problema di capacità: la rete e i relativi sistemi di protezione possono assorbire o scartare una quantità sufficiente di traffico dannoso per mantenere disponibile il servizio previsto? Un’attività in stile sciame può porre maggiore enfasi sull’identificazione di numerose fonti distribuite, sul mantenimento di un filtraggio uniforme e sul rilevamento di ripetuti deterioramenti del servizio. Un minor numero di attacchi giganteschi non significa quindi che il rischio per la disponibilità sia scomparso. Anche un evento più piccolo può interrompere un sito web o un’applicazione se supera la capacità del servizio o prende di mira una risorsa la cui elaborazione è onerosa.
Di conseguenza, le organizzazioni dovrebbero evitare di misurare la propria preparazione soltanto rispetto al dato di traffico più elevato mai osservato. Un monitoraggio utile dovrebbe includere disponibilità, response time, error rate e variazioni insolite del volume delle richieste. Il response time indica quanto tempo impiega un servizio a rispondere a una richiesta, mentre un error rate è la quota di richieste che non vengono completate. Osservare insieme questi segnali aiuta i team a distinguere un’interruzione completa da un disservizio parziale e più lento, che potrebbe comunque impedire ai clienti di accedere, effettuare un acquisto o utilizzare un’applicazione in modo affidabile.
La protezione DDoS deve inoltre coprire l’intero percorso verso il servizio. Un sito web pubblico protetto può restare non disponibile se un aggressore riesce a raggiungere direttamente il relativo host sottostante, saturare una connessione di rete non protetta o sovraccaricare un’operazione dell’applicazione che consuma una quantità considerevole di capacità di elaborazione o del database. Per questo motivo, i team dovrebbero documentare quali indirizzi e servizi pubblici sono esposti, dove avviene il filtraggio del traffico e chi è responsabile dell’intervento quando la disponibilità peggiora. Si tratta di questioni infrastrutturali valide indipendentemente dalla piattaforma di hosting o cloud utilizzata.
Il Rate limiting, che limita la frequenza con cui un client può effettuare una richiesta, può ridurre la pressione su determinate funzioni dell’applicazione se configurato con attenzione. Il Caching, che fornisce una copia memorizzata invece di generare ripetutamente lo stesso contenuto, può inoltre ridurre il carico sui livelli dell’applicazione e del database. Nessuno dei due deve essere considerato una soluzione universale: limiti troppo rigidi possono bloccare gli utenti legittimi, mentre il caching non può proteggere le operazioni che devono essere elaborate singolarmente. L’obiettivo pratico è una resilienza a più livelli, anziché la dipendenza da un unico controllo.
Un piano di gestione degli incidenti dovrebbe definire come confermare un’interruzione, come contattare il provider di hosting o di rete, chi può autorizzare modifiche di emergenza alla configurazione e in che modo i clienti riceveranno aggiornamenti. I team dovrebbero inoltre conservare i dati di monitoraggio, in modo da poter verificare quando è iniziato il disservizio, quali servizi non hanno funzionato e se le azioni di ripristino sono state efficaci. Queste evidenze operative sono importanti perché, in caso contrario, un incidente altamente distribuito potrebbe apparire come una normale congestione, un malfunzionamento dell’applicazione o un improvviso aumento della domanda legittima.
Per le organizzazioni che cercano assistenza nella revisione di queste responsabilità operative e di sicurezza, AEU-I fornisce servizi IT, infrastrutturali e di consulenza con la sicurezza al primo posto. La lezione applicabile ad altri contesti che emerge dalla valutazione di Cloudflare sul terzo trimestre 2026 è che la preparazione agli attacchi DDoS dovrebbe affrontare sia le interruzioni distribuite e ripetute sia gli attacchi eccezionalmente grandi. Le procedure di protezione, monitoraggio e risposta devono essere progettate per mantenere utilizzabile il servizio, non semplicemente per resistere a un valore di traffico da prima pagina.