Mitigazione attacchi DDOS L7
foto di Lucia Zappacosta
Come promesso, pubblico il post del talk che non è stato scelto all’HackInBo. Per chi non lo sapesse, il format è molto carino: il relatore presenta (e quindi prepara) due talk e il pubblico in sala vota e decide quale vuole sentire.
Sicurezza collaborativa
Ultimamente ne sto parlando tanto, ma credo che questo nuovo approccio per cercare di combattere il cybercrimine possa essere davvero efficace. Il cybercrimine è la terza economia al mondo, con ricavi che superano l’industria della droga e il suo costo annuale per la collettività supera quello di tutte le calamità naturali.
Crowdsec si fa bandiera e portavoce per tutti quelli che vogliono collaborare per rendere questo mondo più sicuro.
Attacchi (D)DOS
Gli attacchi DOS/DDOS sono la prima classe d’attacco ufficialmente riconosciuta e il loro primo utilizzo risale a metà degli anni ‘70. In questo post analizzeremo nello specifico gli attacchi layer 7.
Negli ultimi anni, gli attacchi Distributed Denial-of-Service (DDoS) hanno preso di mira tutti i tipi di aziende e sono alcuni degli attacchi più comuni, rimanendo estremamente efficienti e dannosi.
Come funzionano?
Il concetto è semplice: gli attaccanti martellano un determinato obiettivo da luoghi diversi tentano di rendere il “servizio” irraggiungibile dagli utenti reali.
- L3 DDoS (riferito a OSI Model Layer 3). L3 è il livello di rete e l’attacco DDoS L3 in genere prende di mira le apparecchiature di rete e la connessione per inondarle fino al punto in cui ci sono semplicemente troppi pacchetti da gestire. È un attacco estremamente efficiente, ma la maggior parte dei principali provider di hosting e hyperscaler sono ben protetti;
- L4 DDoS (riferito a OSI Model Layer 4). In questa categoria ricadono tutti quegli attacchi che ad esempio utilizzano pacchetti malformati (tcp syn e ack);
- L7 DDoS (per Layer 7) questa tipologia di attacchi prende di mira direttamente le applicazioni. L’obiettivo non è quello di “spegnere” la rete, bensì il servizio stesso, inondandolo di richieste.
DDOS L7 (http)
La tipologia forse più comune di attacchi DDOS L7 è quella che prende di mira servizi http. Uno dei punti chiave per rendere l’attacco difficile da mitigare è il modo in cui viene distribuito. Gli attacchi DDoS L7 sono complessi da gestire: una o due richieste HTTP per fonte li rendono quasi impossibili da mitigare con una semplice correzione a livello di IP (bannare gli IP partendo dai log è inutile, poiché non vengono quasi mai riutilizzati).
Cosa vediamo?
Durante l’attacco: * 70K richieste HTTP; * 1.150 indirizzi IP univoci (ben distribuiti nello spazio degli indirizzi IPV4).
Mitigazione
Una possibile soluzione è integrare un aspetto di geolocalizzazione nelle contromisure: gli attacchi provengono principalmente dai paesi X e Y o dal sistema autonomo (AS) Z e K. Tuttavia, vietare questi determinati paesi significherà falsi positivi e danni collaterali: ad utenti legittimi provenienti da paesi da cui proviene l’attacco verrebbe negato l’accesso al sito Web, e questo potrebbe non essere accettabile (ad es. E-commerce). Ma non temere, l’uso di captcha come contromisura piuttosto che bannare “semplicemente” gli aggressori consentirebbe agli utenti legittimi di passare e ai robot malevole di rimanere fuori a un costo ragionevole.
Vediamo come funziona con CrowdSec.
Durante il DDoS L7, i paesi da cui proviene principalmente l’attacco saranno soggetti a captcha (Cina, Indonesia e India nel nostro esempio), mentre gli altri paesi (Francia e Spagna) rimarranno inalterati.
Tuttavia, gli utenti legittimi dei paesi da cui provengono gli attacchi continueranno a poter usufruire della risorsa (portale web), risolvendo il captcha. Per raggiungere questo obiettivo, l’agente CrowdSec leggerà i log di Apache2, rileverà le fonti DDoS in corso e prenderà le decisioni che il buttafuori utilizzerà per istruire Cloudflare e bloccare gli aggressori. Successivamente, creeremo uno scenario CrowdSec per rilevare il traffico eccessivo da un determinato paese, sistema autonomo o qualsiasi IP.
Ho già trattato l’installazione del bouncer Cloudflare per cui non ripeterò nuovamente i passaggi.
Prima di tutto, lato Cloudflare, possiamo vedere che le nostre regole stanno dando i loro frutti.
Per quanto riguarda le risorse consumate dalla macchina, i risultati sono molto diversi. Entro 5 minuti dall’inizio dell’attacco, le risorse tornano alla normalità e circa 2 di questi 5 minuti rappresentano il ritardo con cui Cloudflare applica le regole.
Sia la CPU che la rete tornano alla normalità entro 5 minuti.
Conclusioni
La soluzione proposta è molto interessante ma presenta dei limiti:
- Cloudflare applica le regole con più o meno 2 min di ritardo;
- nella versione free, Cloudflare permette di inserire fino a 10’000 IP nelle liste firewall.
Se già utilizzi Cloudflare devi di certo prenderla in considerazione, ma per le nuove infrastrutture conviene fare dei ragionamenti più approfonditi.
Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.
Risorse: