5 nov 2012

Come (non) difendersi dagli attacchi DDoS


Ho letto ieri l'articolo riguardo gli attacchi DDoS pubblicato a cura di OAI su Office Automation (disponibile gratuitamente al questo link) e avrei qualche osservazione in merito. Disclaimer: lavoro per una società che produce apparati per la protezione dagli attacchi DDoS.
L'articolo afferma, correttamente, che "costruire una strategia di difesa non è banale", ed è benemerita l'opera di sensibilizzazione sul tema, ma poi conclude presentando un esempio di tecniche di "protezione" datate e non efficaci. La strategia di difesa presentata si articola in tre fasi, che vorrei commentare separatamente.
1) "Individuazione proattiva dell'attacco". Parole sante: è indispensabile avere a disposizione strumenti di anomaly detection in grado di rilevare "stranezze" nella rete senza dover attendere la telefonata del cliente disperato.
2) "Mitigazione di primo livello senza degrado del servizio": qui iniziano le dolenti note. Dice l'articolo: "tra le misure di filtraggio del traffico con ACL sui border router o in modi più avanzati sui firewall, se necessario dedicandone uno o più al cliente sotto attacco in maniera rapida ed automatica". Avere le opportune ACL impostate sui router di frontiera dovrebbe essere visto come una Best Practice, non come uno strumento di mitigation "on demand". Spesso i clienti vengono colpiti da flood basati su protocolli "esotici" che non hanno alcuna ragione d'essere e che andrebbero bloccati di default sui router di frontiera. Nel 99% dei casi la policy di default dovrebbe essere quella di bloccare tutto sui border router tranne i protocolli 6, 17 e (forse) 1. Agire tramite ACL non è una modalità di mitigation efficace in quanto un'ACL non potrà mai gestire con successo la dinamicità di un DDoS generato da migliaia di sorgenti diverse. In aggiunta, l'ACL agisce solo a livello 3 e 4 e non serve a nulla in caso di attacchi application-layer basati sugli ormai comunissimi tool che simulano, ad esempio, richieste HTTP perfettamente lecite da un punto di vista sintattico. Va anche sfatato il mito che i firewall siano una protezione "avanzata" contro i DDoS. La stragrande maggioranza dei clienti con cui parlo afferma di essersi resa conto di essere sotto attacco a causa del crash del firewall, impegnato a cercare di gestire tramite un'ispezione stateful flood costituiti da milioni di connessioni apparentemente legittime. Quale tipo di valore aggiunto possono offrire i firewall in questo caso? Praticamente nessuno. Se le access list sui border router hanno fatto il loro dovere, il traffico "non permesso" è già stato bloccato, e pensare di bloccare un DDoS attraverso tecniche di deep packet inspection è una pericolosa illusione. E' come pretendere di perquisire uno per uno tutti i 50.000 spettatori del derby facendoli passare da un solo tornello: è chiaro che non regge. Ma pensiamoci: se i firewall fossero in qualche modo utili a contrastare i DDoS, come mai sentiamo ancora parlare di questo tipo di attacchi, visto che il firewall ormai ce l'hanno tutti? Idem dicasi per IDS e IPS. Questi sono apparati destinati a fare ALTRO: ispezione stateful layer 7, cpu- e ram-intensive. Mi sento ancora peggio quando leggo di provisioning "rapido e automatico" di firewall dedicati, che mi fa pensare a soluzioni VM, che non fanno altro che aggiungere altri potenziali punti di failure a fronte delle quantità di traffico in ballo. L'articolo menziona anche la possibile attivazione di funzioni di "transparent proxy": ma bene! aggiungiamo pure un ulteriore livello di proxy stateful: un altro apparato che deve esaminare tutte le sessioni come se fossero legittime, un altro punto vulnerabile lungo il percorso del traffico.
3) "Mitigazione di secondo livello don degrado della raggiungibilità utilizzando prevalentemente tecniche di blackholing". Per chi non lo sapesse, il blackholing NON è "un insieme di indirizzi IP cui vengono destinati i pacchetti dei flussi malevoli di un DDoS": il blackholing è la procedura per cui, SU BASE DESTINAZIONE, tutto il traffico viene scartato a monte della rete. In parole molto povere, una volta rilevata l'indirizzo IP destinazione dell'attacco, questo viene comunicato all'upstream provider chiedendo che il traffico verso di esso non venga più ruotato verso la destinazione, ma venga invece scartato prima di entrare nella rete. Il blackholing è una modalità di protezione dell'infrastruttura dell'ISP, che si libera del flusso di attacco che altrimenti transiterebbe nella sua rete e degli eventuali effetti collaterali che esso causerebbe, ma per quanto riguarda il cliente vittima, non fa altro che completare il successo dell'attacco, scartando indiscriminatamente sia il traffico buono che quello cattivo. Esistono soluzioni "avanzate" derivate dal blackholing, come il Source-Based BH o il FlowSpec, che cercano di coniugare la granularità delle access list con la facilità d'uso degli annunci BGP alla base del blackholing, pur con le rigidità che ne conseguono.

Mi fermo qui, senza dettagliare ciò che INVECE andrebbe fatto, onde evitare il rischio di apparire come quello che in fin dei conti voleva solo tirare acqua al proprio mulino. Ma mitigare i DDoS con firewall e blackholing fa tanto anni '90.

2 commenti:

Anonimo ha detto...

Lodevole iniziativa OAI, ma non si dovrebbero limitare solo ad osservare? :D

marco.bozzetti ha detto...

La pregherei di indicare in una ulteriore nota , anche a grandi linee, il suo approccio su come "mitigare" un attacco DDoS. Lo potrà poi mostrare e completare il dibattito interessante anche sul Gruppo OAI in LionkedIn

Grazie e presto
Marco Bozzetti