DoS & DDoS mitigation: guida per capire, quando funziona e quando non funziona

Questo documento descrive quanto si cela sotto le due semplici sigle DoS e DDoS che racchiudono invece una moltitudine di aspetti da tenere in considerazione per meglio comprendere dinamiche e soluzioni.

Il documento vuole essere un riferimento per chi si pone delle domande il giorno dopo aver acquistato servizi anti DoS / DDoS e le applicazioni continuano ad essere afflitte da questo problema.

Tipologie DoS / DDoS

Innanzitutto chiariamo immediatamente le due terminologie che sembrano scontate, visti gli acronimi, ma in realtà anche gli acronimi possono essere male interpretati.

DoS (Denial of Service) è l'acronimo che indica un attacco proveniente da un unico indirizzo IP mentre, DDoS (Distributed Denial of Service) indica un attacco proveniente da più indirizzi IP.

In realtà, anche un attacco DoS può provenire da diversi indirizzi che, per effetti di reti NAT o sistemi proxy, nascondono le provenienze reali. Questi attacchi sono facilmente riconoscibili.

Gli attacchi DDoS sono invece attacchi che, sempre, vengono attuati da indirizzi IP differenti e sono caratterizzati per tipologie e provenienza.

Tipologie:

1. Attacchi volumetrici o quantitativi

2. Attacchi qualitativi

Provenienza:

1. Provenienti da indirizzi completamente diversi e leciti

2. Provenienti da specifiche subnet

DDoS volumetrico o quantitativo

Per attacco DDoS volumetrico o quantitativo, si intende un attacco dove la quantità di dati trasferiti è tale da poter saturare la capacità della rete fino al collasso. Questi attacchi sono solitamente pesantissimi e spesso provengono direttamente da service provider o addirittura da CDN che, essendo state violate, conducono, a loro insaputa, attacchi massivi. Le linee dedicate o CDN si distinguono per categorie e più precisamente:

EUROPA

STATI UNITI

Spesso e storicamente, questi nodi sono attestati su centri di ricerca e proprio per questo motivo diventano vettore di attacco involontario per violazioni che si possono verificare nei laboratori che, tipicamente e per loro natura, non adottano sistemi di sicurezza elevati o addirittura non ne adottano per niente.

DDoS qualitativi

Per attacchi DDoS qualitativi, si intendono gli attacchi provenienti da più indirizzi IP che, seppur non movimentano masse di dati elevate, incidono sulla qualità del sevizio. Solitamente questi attacchi puntano a saturare l'applicazione e non la rete e per questo gli strumenti di rete non sono in grado di distinguerli. Sono degli attacchi mirati allo strato applicativo, cioè di trasporto e protocollo applicativo (4-7 OSI) oppure a fragilità costruttiva dell'applicazione, cioè il codice scritto per eseguire il servizio.

Distinguere un attacco DDoS dal traffico lecito

Distinguere un attacco DDoS dal traffico lecito risulterebbe a prima vista semplice! Al verificarsi di un aumento di volume o di un aumento di richieste rispetto alla norma, potrebbe sembrare essere sufficiente a determinare un attacco e al porvi rimedio. Niente di più sbagliato, un aumento di quantità di richieste o di volume o di entrambe, non è sufficiente.

A titolo di esempio possiamo citare alcuni casi. Immaginate un sito di e-commerce dove il marketing ha confezionato una campagna vendite attraverso sconti su un determinato gruppo di articoli. Il marketing, una volta ultimata la definizione della campagna, decide di inviare tramite e-mail la promozione a un numero molto elevato di indirizzi, ad esempio 600.000 indirizzi e-mail. È statisticamente provato che il 25% / 30% delle e-mail inviate vengano aperte e la persona che le riceve vada a vedere il contenuto della promozione richiedendone il servizio con un click, tutto questo simultaneamente. In questo caso stiamo parlando pessimisticamente di 150.000 utenti!

Dal punto di vista rilevazione un sistema DDoS, poco intelligente, potrebbe pensare a un attacco valutando che il traffico medio nelle due ultime settimane è stato di 6000 utenti contemporanei con punte di 25000 utenti.

Ovviamente non è un attacco, è una campagna marketing ben studiata e andata a buon fine come trasformazione da e-mail a contatti e che per un 4% si trasforma in vendite. Se un sistema DDoS bloccasse questo traffico probabilmente ci sarebbe una richiesta danni per mancati incassi. Tenete presente questa considerazione perché ci torneremo più avanti.

Un altro esempio potrebbe essere quello che in Italia viene chiamato "click-day" (Nota, questo nome, tra le altre cose molto pertinente, non esiste in nessun'altra parte al mondo!), cioè un "momento" prestabilito in cui si abilita un servizio per ottenere delle prestazioni/servizi che però sono attribuite in base a "chi primo arriva meglio alloggia". Ovviamente in quel momento prestabilito tutti coloro che vogliono concorrere dovranno essere pronti al "click" per accedere alla prestazione/servizio causando inesorabilmente un aumento sia in volume, che di solito non è rilevante, ma soprattutto in numero di richieste contemporanee. Gli effetti sono noti a tutti. Anche in questo caso se un sistema anti DDoS cercasse di determinare statisticamente un attacco verrebbe tratto in inganno. Poi, in dipendenza della natura della prestazione/servizio, si potrebbero paventare azioni legali per mancata possibilità di accesso alla prestazione/servizio.

Altri motivi, tra i tanti, per cui sistemi anti DoS/DDoS potrebbero non distinguere un attacco, sono derivati da applicazioni, non esseri umani, che in determinate circostanze o momenti, eseguono un numero elevato di transazioni dovute a un fattore contingente. Pensiamo ad esempio a sistemi di trading online che reagiscono con vendite o acquisti automatici. L'aumento delle richieste di servizio potrebbe essere causato da un evento oppure da errori, di rete/applicazione, che determinano, in particolari situazioni, una ripetizione e reiterazione compulsiva dell'operazione che non va a buon fine. Se anche in questo caso un sistema anti DDoS entrasse in azione bloccando le transazioni il problema sicuramente porterebbe a delle conseguenze legali e a richieste di risarcimento.

A questo punto siamo pronti a capire meglio perché alcune volte i sistemi non intervengono!

Distinguiamo quindi i sistemi anti DDoS in 4 categorie:

1. Volumetrici

2. Statistici

3. Database di indirizzi malevoli

4. Rilevamento del livello di stress dell'applicazione (application stress level detection) In questa categoria distinguiamo inoltre altre due categorie:

   a. Con agenti di rilevazione

   b. Senza agenti di rilevazione (Agent-less)

Sistemi anti DDoS volumetrici

I sistemi anti DDoS volumetrici o meglio, mitigazione degli effetti DDoS basati sul volume, sono quelli che tipicamente utilizzano i telco provider. Questi sistemi rilevano il volume di traffico e agiscono in base a un parametro finito, la capacità di throughput della rete osservata. Questi sistemi sono molto affidabili perché agiscono su un parametro certo**, peccato che non garantiscano una efficace copertura per le applicazioni.**

Infatti, il parametro su cui basano la reazione è il volume di dati trasferiti e questo, quando viene rilevato, è già troppo tardi per le applicazioni. Di fatto sono molto efficaci per proteggere i core-switch del telco operator e solo in caso il sistema rilevi possibili compromissioni di questi apparati reagiscono spostando il routing dei border router su "buchi neri" che salvaguardano l'operatività degli apparati. È di fatto una protezione degli apparti del telco operator che non sono in grado di garantire l'operatività delle applicazioni (servizi) perché non sono in grado di comprendere l'affaticamento applicativo e una reazione alla variazione del volume potrebbe compromettere il business dell'applicazione con effetti di azioni legali per mancato guadagno o disservizio.

In definitiva, questo tipo di rilevazione potrebbe essere equiparato a un sistema di rilevazione dello stress ma che non è applicativo bensì relativo agli apparati del telco-operator.

Sistemi anti DDoS statistici

Ricadono sotto questo segmento i prodotti basati sulla variazione dello stato. Il sistema apprende e memorizza una esperienza di volume e o richieste e al variare di queste reagisce bloccando gli indirizzi di provenienza.

Anche in questo caso l'algoritmo sbaglia clamorosamente in tutti quei casi in cui il traffico, a volume o per richieste, varia oltrepassando alcune soglie ma i servizi stanno funzionando perfettamente.

Questo sistema è il più deleterio in quanto, non tiene conto dello stress applicativo!

Per questo motivo tutti i sistemi basati su questo algoritmo, nel migliore dei casi, semplicemente non reagiscono e si limitano a fornire una piattaforma "post-mortem" del servizio per rilevare quali indirizzi IP hanno determinato il crash.

La maggior parte dei sistemi oggi sul mercato è basato su questo algoritmo associato, per mitigarne gli effetti negativi, ad altri algoritmi come ad esempio quelli basati su Database di indirizzi malevoli.

Sistemi anti DDoS con database indirizzi malevoli

Per sopperire alle inefficienze dei sistemi anti DDoS statistici si sono sviluppati nel tempo dei database di indirizzi malevoli**. I database di indirizzi malevoli sono alimentati dalle rilevazioni "post-mortem" di sistemi anti DDoS statistici, quindi sempre troppo tardi per il malcapitato.**

Inoltre, un problema importante, è che se l'indirizzo rilevato è di un servizio lecito, questi risulterà bloccato per tutti coloro che utilizzano quel database all'insaputa dell'erogatore del servizio che si vedrà abbattere il volume di traffico e peggio, se è un esercizio commerciale, il suo volume di vendite.

Questi tipi di sistemi sono altamente inaffidabili anche alla luce degli ultimi attacchi la cui provenienza avviene sempre da indirizzi leciti e non ancora all'interno di questi database con l'effetto che, post-mortem, anche questi indirizzi sembreranno non leciti. In pratica questo sistema è ormai sorpassato e addirittura dannoso se si pensa a possibili usi impropri come ad esempio concorrenza sleale ad opera di personale non fidato che inserisce nel database indirizzi da bloccare a scopo di lucro.

Inoltre e non per ultimo, essendo i database alimentati dalle esperienze di crash dei servizi sono una esfiltrazione spontanea di dati sensibili che spesso non vengono segnalati all'utilizzatore che magari li paga come servizio. Di fatto all'interno di questo database non ci sono solo gli indirizzi che hanno bloccato il sito ma spesso anche il sito e il servizio bloccato esponendo ancora di più quello specifico servizio a possibili attacchi mirati perché dichiaratamente evidenziati dal crash.

Sistemi anti DDoS con rilevamento del livello di stress applicativo

Questi sistemi sono tra i più efficaci nel rilevare attacchi DDoS o meglio, come vedremo, nel rilevare un possibile problema che determinerà uno stop del servizio.

È chiaro che il sistema a rilevazione dello stress entra in azione solamente nel momento in cui, indipendentemente dalla causa, il servizio rallenta al punto di diventare inservibile per gli utenti quindi in vero stato di Denial of Service.

Questo sistema è l'unico che dovrebbe essere annoverato tra i sistemi DDoS in quanto rileva effettivamente il "Denial of Service" e non il "Denial of Tool" (core-swicth fault) o l'incremento delle richieste.

L'algoritmo quindi è abbastanza buono per mitigare gli effetti di un overload del servizio ma anche qui dipende da chi esegue il rilevamento e su quali basi viene determinato l'overload e inoltre, se è in grado di segnalare e reagire per tempo prima che si arrivi al crash del servizio.

Cominciamo con il distinguere due tipi di rilevatori, quelli ad agenti e senza agenti (agent-less).

Sistemi anti DDoS con agenti di rilevazione dello stress applicativo

I rilevatori ad agenti si distinguono nuovamente con agenti a bordo dell'applicazione (plugin-agent) a bordo del server (agent) oppure all'esterno, sistemi di monitoraggio oppure sistemi ibridi.

Tipicamente questi agenti sono di tracciamento "post-mortem" oppure per alzare degli allarmi. Negli ultimi anni si sono evoluti anche per rilevare lo stress e aumentare il numero di risorse per sopperire al maggior carico (vedi EC2 autoscaling, Kubernetes Horizontal Pod Autoscaling etc.), difficilmente integrabili a sistemi che reagiscono bloccando l'overload non lecito.

I sistemi a rilevazione con agenti hanno anche un problema di entropia. Se i servizi sono pochi e ben definiti sono applicabili, se i servizi gestiti sono diverse migliaia il mantenimento degli agenti è costosissimo in termini di costi di installazione e mantenimento. Al variare delle release o aggiornamenti degli agenti il mantenimento diventa impossibile da tenere sotto controllo e si arriva quasi sempre a uno stato di inconsistenza.

I sistemi a plugin-agent, cioè integrati sul middlware applicativo, web server o application server, soffrono anche di problemi di incompatibilità tra release del middlware e plugin-agent causando spesso problemi al servizio ancor prima di risolverli.

Inoltre, i sistemi ad agenti riescono difficilmente a rilevare i nuovi attacchi di tipo lento "slow" che tendono a creare pochissimo traffico ma a tenere impegnati i server con connessioni che trasmettono pochissimi dati tenendo impegnate tutte le risorse scambiando solo qualche byte per non far cadere in time-out la connessione ma saturare la memoria fino all'overflow, memoria che, nel caso dei plugin-agent, ricordo è condivisa sullo stesso spazio di indirizzamento del web-server o application server!

Sistemi anti DDoS agent-less di rilevazione dello stress applicativo

Questi sistemi sono il miglior strumento DoS/DDoS attack mitigation oggi sul mercato perché, basandosi sulla rilevazione dello stress applicativo, non hanno bisogno di installare agenti che in infrastrutture con migliaia di servizi e non necessitano di nessun tipo di manutenzione sui servizi anche se servono migliaia di nodi e applicazioni.

Inoltre, dovendo essere il tramite (pass-through) del traffico, sono, in maniera spontanea, anche il sistema dove possono essere prese delle decisioni istantanee e quindi poter essere dei mitigatori perfetti di fenomeni DoS/DDoS avendo rilevato l'effettiva necessità dell'azione. Con questi strumenti la rilevazione è puntuale, nel momento in cui i sistemi stanno rallentando, e sono in grado di prendere una iniziativa immediata.

Ovviamente la rilevazione non può essere individuata a livello e con apparati di rete, si dovrebbe tener conto della logicità dei pacchetti! Quindi non può essere effettuata da uno switch e nemmeno da un sistema che "ispezioni" il traffico a pacchetti, peraltro ormai sempre più spesso criptato in quasi tutti i datacenter anche nelle intranet per evitare fughe di dati sensibili.

Oplon DoS/DDoS attack mitigation

Il sistema Oplon DoS/DDoS attack mitigation racchiude il meglio della tecnologia oggi a disposizione.

È un sistema della categoria anti DoS/DDoS qualitativo con rilevazione dello stress applicativo e con reazione istantanea (5 millisecondi) alla rilevazione del rallentamento senza l'uso di agenti di nessun tipo (agent-less).

Il sistema è basato su studi relativi alla scalabilità software che hanno portato a costruire un motore a risorse finite che, se adeguatamente configurato, non può soffrire di out-of-memory o out-of-resource per eccesso di carico e per questo motivo è in grado di reagire ad un attacco anche se massivo.

Il sistema inizializza allo startup i seguenti elementi fondamentali:

1. I listener

2. I tunnel

3. Una coda di "incoming connections to resolve"

4. Una coda di "incoming connections to clean"

5. Una Washing machine

6. Una Quarantine addresses/subnets table

7. Rilevatore di attacco DoS/DDoS

Il sistema quindi è basato su un numero finito di tunnel che tipicamente sono stati dimensionati per il traffico da sostenere in un momento definito "normale", prendendo in considerazione anche "picchi" in base all'esperienza e alle indicazioni dei sistemisti applicativi e del sizing delle applicazioni.

Il rapporto tra tunnel e client, con applicazioni di tipo consultativo, è tipicamente 1/7, 1/10 che scende se le applicazioni mantengono connessioni persistenti.

Il sistema che sovrintende alla rilevazione degli eventi, Oplon DoS/DDoS attack mitigation, è un sistema asincrono che a intervalli di 5 millisecondi esegue una scansione su tutti gli elementi e verifica:

1. Soglia dei tunnel attivi

2. Soglia di accodamento su incoming connections

3. Soglie di raggiungimento occorrenze IP ricorsivi

4. Catalogazione delle occorrenze IP Subnets

5. Catalogazione delle occorrenze temporali di impegno IP e IP subnets

6. A layer 7 http catalogazione delle occorrenze delle catene X-FORWARDED-FOR

7. Soglia del raggiunto limite del survivor tunnel space

Conclusione e benefici

Di seguito i benefici della soluzione Oplon DoS/DDoS attack mitigation e cosa invece non non copre.

Benefici

1. Il sistema è completamente agent-less

2. Il sistema si basa sull'affaticamento applicativo

3. Il sistema reagisce in 5 millisecondi dalla rilevazione

4. Il sistema reagisce anche a rallentamenti applicativi non causati dall'esterno

5. Il sistema è in grado di "lavare" (washing machine) indirizzi IP che vengono posti in quarantena

6. La washing machine non influisce sulle risorse destinate alla risoluzione dei protocolli (tunnel e incoming connections to resolve protocol)

7. Il sistema permette un tracciamento fine degli indirizzi IP che stanno determinando il problema

8. Il sistema "quarantena" permette di porre in stato di non poter nuocere indirizzi da cui, temporaneamente, stanno causando un problema ma sono leciti

9. Il sistema può intercettare attacchi di tipo "slow"

10. Il sistema consente, anche durante un attacco, ad un servizio di lasciare risorse libere per gli altri servizi che stanno condividendo le risorse (tunnel survivor space)

Cosa non fa:

Non è volumetrico, questo sistema deve essere coadiuvato da sistemi anti "DDoS" o meglio "DDoT" (Denial of Tool) volumetrici messi a disposizione dai telco provider.

Autore: Valerio Mezzalira