Nov 12, 2012

Come prepararsi a un attacco DDoS

Visto l'invito ricevuto qui e qui, provo a mettere giù due note su cosa fare per prepararsi a mitigare al meglio un attacco DDoS verso la propria rete.

In primo luogo vanno bloccati tutti i protocolli e le porte destinazione non necessari. Ciò va fatto tramite ACL stateless sui router di frontiera, il più a monte possibile.
Servizi "accessori" come DNS, NTP o Windows Update e simili vanno, se possibile, centralizzati: ad esempio, per risolvere i nomi host i server della rete si rivolgeranno al DNS interno, e solo quest'ultimo si occuperà delle ulteriori query verso Internet eventualmente necessarie. Ciò semplifica la protezione, soprattutto riguardo le ACL stateless menzionate sopra.
Vanno ovviamente configurati opportunamente i servizi che si intende proteggere, in modo da non offrire il fianco ad attacchi particolarmente banali. Non è questa l'occasione per entrare in tali dettagli, non sono un esperto del settore e, soprattutto, basta una ricerca in rete. Idem dicasi per tutti gli apparati di rete (router, switch, load balancer, ecc.) e sicurezza (firewall, IPS, ecc.) presenti "a monte" del sistema da proteggere: se hanno delle funzioni di auto-protezione, attivatele; se c'è modo di ottimizzarne le performance, fatelo.
Un esempio classico di questo tipo di approccio è questo.

Peccato però che tutti questi sforzi rimangano fondamentalmente vani a fronte dei moderni attacchi DDoS, che possono ormai facilmente saturare la capacità di CPU, RAM e banda di qualunque azienda. Prima di procedere ulteriormente, fatevi un'idea della dimensione del problema che stiamo cercando di mitigare: qui, qui, qui, oppure con un'altra bella ricerca google. Quanto è facile scatenare un attacco DDoS? Leggete qui.

Detto ciò, è quindi necessario attrezzarsi con soluzioni di protezione ad hoc. Gli apparati di DDoS Mitigation devono essere basati su meccanismi di analisi stateless, per non diventare essi stessi un collo di bottiglia durante gli attacchi, e ciò esclude quindi ogni soluzione basata su proxying delle applicazioni. Una trattazione esaustiva del tema DDoS non esiste e probabilmente mai esisterà, in quanto si tratta della consueta gara dei "buoni" all'inseguimento delle sempre nuove tecniche escogitate dai "cattivi": molto spesso la DDoS Mitigation richiede un alto grado di esperienza e "skill" specifici nel fare troubleshooting sia degli aspetti applicativi che prettamente volumetrici del traffico sotto osservazione, al fine di riuscire a distinguere il grano dal loglio e bloccare quindi il traffico malevolo causando i minori problemi possibili alle sessioni legittime.
Ad altissimo livello, possiamo provare a descrivere alcune tipologie di DDoS e le relative contromisure che un apparato di mitigation dovrebbe implementare.
1. Attacchi botnet-based o generati tramite tool "standard" da volontari ingaggiati per l'occasione. Spesso è possibile riconoscere le query generate da tali tool tramite opportune signature.
2. Attacchi basati su flood di richieste applicative (ad es. HTTP o DNS) apparentemente legittime. E' necessario, preferibilmente attraverso la conoscenza approfondita delle modalità di funzionamento dei sistemi sotto protezione, riconoscere i pattern delle richieste utilizzate per l'attacco al fine di bloccarle selettivamente. Ciò può essere fatto più o meno manualmente: naturalmente, con l'aumentare dell'automatismo, aumenta anche il rischio di falsi positivi. Nel caso l'attacco si concentri su un numero limitato di URL specifici, è possibile bloccare gli IP sorgenti responsabili di un rate di query anomalo o eccessivo. In casi di attacchi più smart, sarà necessario bloccare le query malevole tramite regular expression apposite. E' possibile inoltre utilizzare meccanismi light di challenge-response per verificare il regolare comportamento degli host sorgenti, al fine di bloccare il traffico generato dai bot.
3. Attacchi basati su flood TCP-based. In primo luogo è necessario implementare meccanismi di "autenticazione" delle sorgenti al fine di bloccare il traffico generato da indirizzi IP spoofed, in modo che, ad esempio, i SYN generati da tali sorgenti non vadano a impegnare le risorse del sistema vittima. Se gli host sorgenti sono invece in grado di completare correttamente il three-way TCP handshake, è possibile implementare ulteriori controlli ad esempio sul numero simultaneo di sessioni aperte, o sulla quantità di traffico inviato su ogni sessione, per bloccare ad esempio attacchi di tipo slow.
4. Flood basati su protocolli connectionless, come UDP o ICMP. Premesso che l'utilizzo di tali protocolli va limitato a monte ai soli utilizzi necessari, sono possibili diversi approcci di mitigation, basati sul blocco delle sorgenti responsabili di rate anomali di traffico, o sul blocco / rate limiting del protocollo nel suo complesso. Nel caso specifico del DNS, possono essere utilizzate tecniche più avanzate di "autenticazione" delle sorgenti.

E' necessario che le soluzioni di DDoS Mitigation forniscano le funzionalità di visibilità e reporting necessarie a un troubleshooting efficace: analisi a livello di singolo pacchetto da un lato, report storici statistici dall'altro. Altre funzionalità utili sono ad esempio il blocco o il rate limiting selettivo del traffico ad esempio per nazione sorgente o per URL destinazione, o basandosi su attributi applicativi "avanzati", come ad esempio il Referrer HTTP.

Anche in caso tali sistemi siano presenti, però, è spesso necessario un ulteriore tassello. Le capacità di mitigation utilizzabili da una "comune" azienda sono ovviamente limitate dalla quantità massima di banda Internet a disposizione. In un mercato come quello italiano, dove la banda a disposizione delle aziende di ecommerce si aggira sulle decine o centinaia di Mbps e gli attacchi superano ormai facilmente i Gbps, è chiaro che tale sproporzione può essere colmata solo grazie all'intervento, a monte, degli Internet Service Provider, che devono quindi offrire servizi di mitigation "cloud" in grado di intervenire quando la dimensione degli attacchi supera quanto è possibile trattare "localmente" presso la rete della vittima.

No comments: