DDoS Distributed Denial of Service.

Cosa fa davvero un attacco di tipo distributed denial of service

Un attacco di tipo denial of service ha un unico obiettivo: rendere un servizio indisponibile per chi ne dipende. La versione distribuita, il DDoS, lo ottiene generando il traffico da molte macchine contemporaneamente, spesso una botnet di dispositivi compromessi, server dirottati o infrastrutture di attacco noleggiate. Poiché il carico arriva da migliaia di indirizzi distinti, non si può semplicemente bloccare un singolo responsabile, ed è l'enorme numero di sorgenti a permettere all'attaccante di sopraffare una capacità che una singola macchina non potrebbe mai raggiungere. Il bersaglio non deve essere violato né subire un furto di dati. Deve solo essere messo offline, il che fa del DDoS un attacco alla disponibilità anziché alla riservatezza o all'integrità.

I professionisti di solito classificano il DDoS in tre livelli, perché il livello determina la difesa. Gli attacchi volumetrici cercano di saturare la banda del collegamento stesso, ricorrendo spesso all'amplificazione, in cui una piccola richiesta contraffatta innesca una risposta di grandi dimensioni diretta alla vittima. Gli attacchi di protocollo esauriscono lo stato negli apparati di rete e nei server, ad esempio lasciando connessioni semiaperte che non si completano mai. Gli attacchi al livello applicativo sono i più silenziosi: inviano richieste che sembrano legittime, come chiamate ripetute a un endpoint di ricerca o a una pagina di accesso, ed esauriscono l'applicazione anziché il canale. Quest'ultima categoria è la più difficile da separare dagli utenti reali.

Perché la mitigazione non è più la parte difficile

Fermare il traffico DDoS è diventato un servizio di base. Grandi fornitori come Cloudflare, Akamai e AWS Shield assorbono gli attacchi ai margini di reti enormi, incassando le ondate volumetriche molto a monte del cliente e filtrando gli abusi di protocollo e applicativi con scrubbing e limitazione della frequenza. Per la maggior parte delle organizzazioni, la domanda tecnica se un attacco possa essere bloccato ha un sì sicuro, a condizione che il traffico sia instradato attraverso quella protezione. La domanda più difficile, e quella che una funzione di gestione del rischio dovrebbe porsi, è di copertura più che di capacità.

Il divario che fa male è l'asset che nessuno ha instradato attraverso lo scudo. Un sito di marketing pubblico si trova dietro la CDN, ma l'API chiamata dall'app mobile, l'indirizzo IP di origine ereditato che non è mai stato dismesso, l'endpoint di integrazione con un partner o il servizio regionale avviato da un altro team possono risolvere direttamente all'origine, aggirando del tutto la protezione. Gli attaccanti trovano questi percorsi diretti e li prendono di mira. Una difesa DDoS efficace è quindi anzitutto un problema di inventario e instradamento: conoscere ogni servizio esposto su internet, confermare che ciascuno sia effettivamente dietro la mitigazione e dimostrare che l'origine non può essere raggiunta aggirandola.

Dove si colloca il DDoS nella continuità e negli standard

Poiché il DDoS attacca la disponibilità, rientra nella stessa conversazione della gestione della continuità operativa. Un sistema di gestione della sicurezza delle informazioni allineato a ISO/IEC 27001 tratta la disponibilità come una delle tre proprietà che protegge, e uno scenario di denial of service è un input da manuale per un'analisi di impatto sul business: per quanto tempo ogni servizio può restare inattivo, cosa dipende da esso e qual è il ripiego. La risposta è raramente un singolo controllo. Combina la mitigazione a monte, un runbook di risposta agli incidenti con contatti nominativi presso il fornitore di mitigazione e accordi di continuità per il periodo in cui un attacco viene assorbito.

Ciò che i professionisti fanno davvero, oltre ad acquistare la mitigazione, è provare e verificare. Mantengono un inventario accurato dei servizi esposti su internet, confermano che ciascuno sia dietro la protezione e verificano che l'origine sia irraggiungibile direttamente. Tarano i limiti di frequenza e le pagine di sfida per gli abusi del livello applicativo, poiché quegli attacchi imitano il traffico reale e non possono essere risolti con la sola banda. Scrivono il percorso di escalation prima di un incidente, così che durante un'ondata nessuno vada a caccia del numero di telefono giusto. E trattano un evento DDoS come un esercizio di continuità, con soglie chiare per attivare il piano, comunicare ai clienti e rimettere in funzione i servizi una volta che il traffico si attenua.