Protezione DDoS aziendale: livelli e playbook

Un attacco distributed denial of service non ha bisogno di violare nulla per danneggiare un'azienda. Gli basta esaurire una sola risorsa da cui dipende l'applicazione: la banda di un uplink, la tabella di stato di un firewall, il pool di connessioni di un load balancer o la CPU di un database.

Una buona protezione DDoS, quindi, non dipende tanto da un singolo prodotto quanto dal sapere quale risorsa colpisce ciascun tipo di attacco e dall'assicurarsi che davanti a quella risorsa ci sia un controllo con più capacità dell'attaccante.

Tre classi di attacco, tre colli di bottiglia diversi

Gli attacchi vengono di solito raggruppati in base al livello che sollecitano. Il raggruppamento è importante perché ogni classe si misura in modo diverso, satura un componente diverso e viene fermata in un punto diverso.

• Volumetrico. L'obiettivo è saturare il collegamento. Il traffico si misura in bit al secondo, e gli eventi più grandi raggiungono centinaia di gigabit o terabit. Sono comuni la riflessione e l'amplificazione, in cui server di terze parti su internet vengono indotti a inviare risposte di grandi dimensioni verso la vittima. Nessuna ottimizzazione dei server aiuta: se l'uplink è da 10 Gbps e ne arrivano 40, il link è saturo prima che un solo pacchetto raggiunga il firewall.
• Protocollo. L'obiettivo è esaurire la capacità di gestione dello stato o di elaborazione dei pacchetti dei dispositivi di rete. Questi attacchi si misurano in pacchetti al secondo anziché in banda. SYN flood e flood di pacchetti frammentati sono esempi tipici. Come riferimento, un link da 1 Gbps che trasporta frame Ethernet di dimensione minima consegna circa 1,49 milioni di pacchetti al secondo, e un link da 10 Gbps circa 14,9 milioni, abbastanza da sopraffare firewall stateful e load balancer dimensionati per il traffico normale.
• Livello applicativo. L'obiettivo è costringere l'applicazione a svolgere lavoro oneroso. Il traffico si misura in richieste al secondo e spesso sembra normale HTTPS. Qualche migliaio di richieste al secondo verso un endpoint di ricerca, un form di login o una pagina di report non in cache può esaurire le connessioni al database mentre la banda complessiva resta modesta. Sono gli attacchi più difficili da rilevare, perché ogni singola richiesta può essere valida.

Gli incidenti reali spesso combinano più classi. Pianifica separatamente per ciascuna classe, poi verifica che cosa succede quando ne arrivano due insieme.

Dove avviene la mitigazione

Il traffico di attacco può essere filtrato in quattro punti. Più un controllo si trova a monte, più volume può assorbire, ma meno sa della tua applicazione.

• Edge di rete e provider a monte. Il provider di hosting o di transito può scartare il traffico prima che raggiunga la propria porta, usando access list, rilevamento basato sui flussi e blackholing attivato da remoto. Il blackholing protegge il resto della rete ma scarta anche il traffico legittimo diretto all'indirizzo preso di mira, quindi è un'ultima risorsa, non una difesa.
• Scrubbing. Sistemi di mitigazione dedicati, inline nella rete del provider oppure in centri di scrubbing remoti raggiunti reindirizzando il traffico tramite BGP o DNS, ispezionano il traffico ad alto volume e inoltrano solo i pacchetti puliti. Lo scrubbing è la risposta principale agli attacchi volumetrici e di protocollo. Chiedere se è sempre attivo o viene attivato al rilevamento, e quanto tempo richiede l'attivazione, perché i primi minuti di un attacco sono spesso i più dannosi.
• CDN e WAF. Una content delivery network termina le connessioni in molte località edge, assorbe il traffico su un'ampia infrastruttura distribuita e serve contenuti in cache senza toccare l'origin. Un web application firewall aggiunge regole a livello HTTP, rilevamento dei bot e pagine di challenge. È il livello principale contro gli attacchi applicativi verso siti web e API pubblici.
• Applicazione e origin. I propri load balancer, reverse proxy e codice applicano limiti di connessione, timeout, quote per utente e degrado controllato. Questo livello ha più contesto (chi è l'utente, quanto costa l'endpoint) ma meno capacità. Non dovrebbe mai essere la prima linea di difesa contro i volumi.

I controlli a monte proteggono la capacità, CDN e WAF proteggono la superficie applicativa e l'origin si protegge da tutto ciò che riesce a passare. L'errore comune è presumere che un livello copra gli altri, per esempio affidarsi a un WAF mentre l'indirizzo IP dell'origin è pubblicamente noto e raggiungibile direttamente.

Rate limiting che regge sotto carico

Il rate limiting è il controllo più utile contro gli attacchi a livello applicativo, e anche il più facile da sbagliare. Il lavoro sta nello scegliere la chiave giusta, la soglia giusta e la risposta giusta.

• Partire da baseline misurate. Raccogliere almeno due-quattro settimane di tassi di richiesta per endpoint, per client e per minuto, eventi di picco inclusi. Impostare le soglie a un multiplo del 99° percentile osservato anziché a un numero tondo.
• Scegliere la chiave con attenzione. Limitare solo per indirizzo IP non funziona per i clienti dietro NAT aziendali o gateway degli operatori mobili, dove migliaia di utenti condividono un solo indirizzo. Dove possibile, combinare l'IP con la sessione, la chiave API o l'ID dell'utente autenticato.
• Ponderare i limiti in base al costo. Un'immagine statica e una ricerca full text non dovrebbero condividere lo stesso budget. Assegnare agli endpoint onerosi (login, ricerca, esportazione, checkout) limiti propri più stringenti.
• Applicare i limiti su più livelli. Applicare limiti grossolani sulla CDN o sul WAF e limiti più fini, basati sull'identità, sull'API gateway o nell'applicazione. L'edge ferma il traffico massivo a basso costo, mentre l'origin intercetta ciò che sull'edge sembra legittimo.
• Rispondere in modo proporzionato. Restituire HTTP 429 con un header Retry-After ai client corretti, usare challenge per i browser sospetti e scartare silenziosamente il traffico solo quando si è certi che sia ostile.
• Usare contatori condivisi. Se si eseguono più nodi applicativi, tenere i contatori in uno store condiviso come Redis, altrimenti ogni nodo applica il proprio limite e il tetto effettivo si moltiplica per il numero di nodi.

Testa i limiti prima di averne bisogno. Riproduci i pattern del traffico di produzione in un ambiente di staging, aumenta il volume gradualmente e verifica che i flussi legittimi continuino a funzionare mentre l'eccesso viene respinto.

Pattern architetturali che riducono l'esposizione

Il filtraggio è solo metà della difesa. L'altra metà consiste nel progettare il sistema in modo che ci sia meno da attaccare e più margine per assorbire ciò che arriva.

• Nascondere l'origin. Mettere i servizi pubblici dietro una CDN o un proxy e consentire il traffico in ingresso verso l'origin solo dagli intervalli di indirizzi pubblicati da quel provider. Cambiare gli indirizzi dell'origin se sono trapelati tramite vecchi record DNS, header delle email o log di certificate transparency.
• Separare i percorsi critici. Ospitare il sito marketing, l'applicazione per i clienti, l'API e le interfacce amministrative su indirizzi diversi e, dove possibile, su infrastrutture diverse. Un attacco alla home page pubblica non deve mettere fuori servizio l'API dei pagamenti.
• Tenere la gestione fuori dall'internet pubblico. SSH, RDP, porte dei database e pannelli di controllo devono essere raggiungibili solo tramite VPN o rete privata, mai sugli stessi indirizzi che servono i clienti.
• Usare la cache in modo aggressivo. Ogni risposta servita dalla cache è una richiesta che l'origin non vede mai. Rivedere gli header di cache delle pagine che potrebbero essere messe in cache anche solo per 30-60 secondi; durante un attacco, un TTL breve elimina gran parte del carico sull'origin.
• Progettare per il degrado. Individuare le funzionalità che si possono disattivare sotto pressione, come raccomandazioni, ricerca in tempo reale o widget non essenziali, e metterle dietro feature flag, così che il percorso transazionale principale continui a funzionare.
• Distribuire su più località. Operare in due o più regioni, con instradamento via DNS o anycast, fa sì che un sito saturo non interrompa il servizio. Offre anche un luogo verso cui spostare il traffico mentre un provider attiva la mitigazione.
• Pianificare il margine. Conoscere la capacità di ogni link e dispositivo lungo il percorso. Una porta da 1 Gbps trasferisce circa 10 TB al giorno a pieno carico, il che sembra molto ma è poco rispetto ai volumi di un attacco, quindi la mitigazione a monte deve assorbire ciò che la propria porta non regge.

Il DNS è un frequente single point of failure: usare un provider con una grande rete anycast, oppure due provider, e mantenere i TTL dei record abbastanza brevi da poter apportare modifiche rapidamente durante un incidente.

Playbook per gli incidenti

Gran parte dei danni in un incidente DDoS deriva da decisioni lente, non dalla mancanza di tecnologia. Un playbook scritto, con nomi e numeri di telefono, trasforma un'ora di confusione in quindici minuti di routine.

• 1. Rilevare. Impostare alert sul traffico e sul comportamento, non solo sullo stato dei server: banda in ingresso, pacchetti al secondo, richieste al secondo per endpoint, tassi di errore e latenza sull'edge e sull'origin. Definire le soglie in anticipo, così che l'ingegnere reperibile non debba valutare sul momento.
• 2. Classificare. Stabilire se l'attacco è volumetrico, di protocollo o a livello applicativo, quali indirizzi ed endpoint sono presi di mira e se l'impatto riguarda il link, i dispositivi di rete o l'applicazione. I dati di flusso e i log dell'edge forniscono la risposta più rapidamente dei log dei server.
• 3. Attivare il livello giusto. Per gli attacchi volumetrici e di protocollo, contattare il provider di hosting o il servizio di scrubbing attraverso il canale concordato e verificare che la mitigazione sia attiva. Per gli attacchi applicativi, inasprire le regole del WAF e i rate limit, attivare le challenge e sospendere le funzionalità non essenziali.
• 4. Proteggere il nucleo. Dare priorità al percorso che genera ricavi e all'autenticazione dei clienti. Se necessario, limitare temporaneamente l'accesso per area geografica o bloccare intere categorie di client, accettando un certo impatto collaterale per un breve periodo.
• 5. Comunicare. Pubblicare presto un aggiornamento sulla status page, fornire al supporto clienti uno script breve e tenere informati i dirigenti a cadenza fissa. Evitare ipotesi sull'origine dell'attacco.
• 6. Sorvegliare le fasi successive. Spesso gli attacchi cambiano vettore quando il primo viene bloccato. Mantenere un monitoraggio rafforzato per almeno 24-48 ore e prestare attenzione ad altre attività, come tentativi di login o di intrusione, che possono nascondersi dietro il rumore.
• 7. Analizzare. Entro una settimana, documentare la cronologia, cosa è stato rilevato e quando, quali controlli hanno funzionato, cosa è stato lento e quali soglie vanno modificate. Aggiornare il playbook e pianificare le correzioni.

Prova il playbook almeno due volte l'anno con un'esercitazione tabletop. Non eseguire mai test non annunciati sulla produzione o su infrastrutture di terzi.

Checklist di preparazione ai DDoS

Usa questo elenco nella prossima revisione dell'infrastruttura.

• Inventario. Tutti gli indirizzi IP pubblici, i domini e gli endpoint sono elencati, insieme al servizio di business che ciascuno supporta.
• Mitigazione del fornitore. Si sa quale protezione DDoS includono i propri provider di hosting e di transito, la sua capacità, se è sempre attiva e come richiederne l'attivazione.
• Contatti di escalation. I contatti del supporto e della mitigazione del fornitore sono documentati e testati, anche al di fuori dell'orario lavorativo.
• Protezione dell'origin. I server di origin accettano traffico web solo dalla CDN o dal proxy, e i vecchi indirizzi dell'origin sono stati dismessi.
• Accesso di gestione. Le porte e i pannelli amministrativi non sono esposti su indirizzi pubblici.
• Resilienza del DNS. Il DNS è ospitato su una grande rete anycast o su due provider, con TTL rivisti.
• Rate limit. I limiti esistono per ogni endpoint, si basano su baseline misurate, usano contatori condivisi e possono essere modificati tramite configurazione.
• Regole WAF. Un set di regole di emergenza testato è pronto per essere attivato, inclusi la modalità challenge e le restrizioni geografiche.
• Caching. Le pagine e gli asset memorizzabili in cache sono effettivamente in cache sull'edge, con monitoraggio degli hit ratio.
• Degrado. Le funzionalità non essenziali possono essere disattivate tramite feature flag senza un deploy.
• Monitoraggio. Gli alert coprono banda, pacchetti al secondo, richieste al secondo, tassi di errore e latenza sull'edge e sull'origin.
• Playbook. Esiste un playbook scritto, che indica un responsabile dell'incidente ed è stato provato negli ultimi sei mesi.
• Comunicazione. Status page, script per il supporto e modelli di aggiornamento per i dirigenti sono pronti.
• Analisi post-incidente. Esistono un modello standard e una scadenza entro cui completarla.

Come può aiutare Vonahost

I server dedicati Vonahost sono macchine AMD EPYC single-tenant con una porta dedicata da 1 Gbps su un fabric di rete da 100/200 Gbps e includono la mitigazione DDoS Arbor, quindi il filtraggio volumetrico e di protocollo avviene nella rete prima che il traffico raggiunga la tua porta. Il cloud gestito Vonahost include CDN, monitoraggio e Redis, che coprono il caching all'edge e i contatori condivisi di rate limiting descritti sopra, e gira sulla piattaforma di Vonahost, su AWS o su Google Cloud.

Ogni proposta indica configurazione, località, responsabilità e prezzo mensile in dollari statunitensi, così che sia chiaro quali parti di questa checklist sono coperte dal fornitore e quali restano al proprio team. Il paese di ciascun server è scelto dal cliente, e i dati non vengono spostati senza la sua approvazione.