L’Agenzia per la Cybersicurezza Nazionale ha identificato un aumento degli attacchi di tipo Distributed Denial of Service (DDoS) da parte di gruppi di hacktivisti – secondo fonti aperte, di origini russe – ai danni di soggetti istituzionali nazionali.
Gli attacchi, rassicura l’Agenzia, hanno carattere dimostrativo e non sembra che abbiano intaccato l’integrità e la confidenzialità delle informazioni e dei sistemi interessati.
Il CSIRT Italia (Computer Security Incident Response Team – Italia) dell’Agenzia ha adottato prontamente tecniche di segregazione geografica dinamica del traffico (cosiddetta geofencing) per scoraggiare gli attaccanti. L’Agenzia raccomanda dunque di mantenere alto il livello di attenzione sulla protezione delle proprie infrastrutture informatiche, di verificare e aumentare le misure di protezione relative agli attacchi DDoS.
Attacchi che, secondo alcune fonti aperte, sono destinati a continuare o intensificarsi nei prossimi mesi.
Attacchi DDoS – Tipologie e azioni di mitigazione dell’ACN
Di seguito vengono descritte in maggiore dettaglio le tre principali categorie di attacchi DDoS e vengono descritte le linee guida generali per la gestione del rischio e la loro mitigazione.
Attacchi volumetrici
Gli attacchi volumetrici mirano a consumare la banda di rete destinata alla fruizione di un servizio target (attacco frontale) o di uno dei servizi accessori essenziali al suo raggiungimento (attacco laterale).
Dato un servizio target e una certa banda di rete a sua disposizione, generando traffico malevolo di volume pari o superiore alla stessa, si negherà l’accesso da parte degli utilizzatori legittimi. Questo tipo di attacco può essere definito “frontale”.
Per attacco “laterale” si intende invece la possibilità di negare l’accesso a un servizio target colpendo frontalmente un secondo servizio essenziale per il funzionamento del primo. L’esempio più noto di attacco laterale è il DDoS Volumetrico verso i server DNS, questo attacco, successivamente esposto in maggiore dettaglio, potrebbe non incidere sulla reale raggiungibilità del servizio, ma potrebbe renderlo comunque non disponibile, rendendo indisponibile la risoluzione del nome di dominio nel relativo IP di pubblicazione del servizio.
DNS Amplification
Il servizio DNS viene erogato da un insieme di database distribuiti con struttura gerarchica i quali vengono acceduti tramite una richiesta DNS, alla quale ne seguirà una contenente i dati richiesti.
Secondo l’RFC 1035 un messaggio DNS su protocollo UDP, sia questo di query o di answer, deve occupare al massimo 512 byte ovvero deve essere completamente contenuto in un solo pacchetto UDP.
Considerando che una query DNS può occupare al minimo 8byte e un’answer può occupare al massimo 512Byte, è possibile calcolare il cosiddetto “fattore di amplificazione” teorico di 64 volte. Effettuando query di dimensione minima che corrispondono a un’answer di dimensione massima6, si obbliga il server DNS a occupare una larghezza di banda di 64 volte superiore a quella dell’attaccante, nei casi reali si assume che il fattore di amplificazione del protocollo DNS sia 60.
Il protocollo DNS può essere incapsulato sia nel protocollo TCP che in quello UDP; l’utilizzo del protocollo UDP è in generale più frequente e permette all’attaccante di utilizzare la già citata tecnica della “riflessione”.
Un attaccante in grado di generare pacchetti UDP artefatti tramite spoofing dell’indirizzo sorgente e contenenti query DNS opportunamente predisposte per massimizzare l’effetto di amplificazione, può indurre un server DNS a compiere del traffico verso una destinazione target. Questo contesto apre a diverse modalità di attacco di seguito elencate.
Attacco diretto
L’attaccante inoltra DNS query verso il server DNS autoritativo del servizio target, il servizio sarà costretto a rispondere con un ugual numero di DNS answer con un fattore di amplificazione teorico di 60.
Un attaccante in grado di generare un traffico pari a 1/61 della banda a disposizione del server DNS può quindi inibire l’accesso al servizio DNS del sistema target. Anche nel caso in cui la connettività del sistema target sia differente da quella con la quale il servizio è pubblicato, gli utenti internet potrebbero non accedere al servizio in quanto impossibilitati a risolvere il nome di dominio.
Gli attacchi di questo tipo potrebbero apparire distribuiti pur provenendo dalla stessa sorgente fisica, in quanto – potendo alterare l’indirizzo IP sorgente – l’attaccante è in grado di simulare un attacco effettuato da parte di una botnet, pur generando il traffico da un solo nodo di rete.
Da un punto di vista tecnico, l’utilizzo di più nodi reali e distribuiti su più AS complica le attività di mitigazione. Di fatto, ogni AS potrebbe essere di per sé connesso all’AS in cui si trova il servizio target in più punti, o comunque potrebbe raggiungerlo tramite diverse rotte, pertanto la presenza di più nodi fisici su più AS moltiplica i possibili punti di accesso al servizio.
Mitigazione preventive contro questo tipo di Attacchi DDoS
Questo tipo di attacco non può essere gestito localmente. Di fatto, la problematica non è legata al servizio, ma alla connettività che a questo viene riservata.
È possibile mettere in campo soluzioni Anti-DDoS on premise oppure cloud, poiché è fondamentale individuare l’attacco il prima possibile sia rispetto alle tempistiche che all’effettiva distanza degli apparati di rilevamento dal servizio target (in termini di hop di rete).
Qualora possibile, è consigliabile installare i sistemi Anti-DDoS presso il sito del PoP (Point of Presence) come primo hop interno.
Mitigazioni contingenti
Qualora non fossero state attuate le azioni di mitigazione preventive, o nel caso in cui le stesse dovessero risultare inefficaci o insufficienti, è possibile limitare l’effetto degli attacchi accettando una certa percentuale di disservizio. Nel caso in cui il soggetto fosse in grado di richiedere intervento all’Internet Service Provider (ISP) è possibile richiedere il blocco del traffico proveniente da una subnet o da un AS accettando, quindi, di fare a meno di tutto il traffico (sia malevolo che lecito) proveniente dal segmento di rete identificato.
Questa operazione è critica; gli IP sorgenti potrebbero essere stati arbitrariamente scelti dall’attaccante proprio allo scopo di indurre il soggetto target ad impostare una regola di blocco per quel preciso IP/subnet provocando, di conseguenza, disservizi a partire da una specifica area geografica o subnet.
Sintesi
Per quanto detto risulta quindi di massima importanza implementare adeguati sistemi di Anti-DDoS al fine di impedire attacchi volumetrici (es. Content Delivery Network); laddove si debba agire con regole puntuali, la richiesta di blocco di IP/Subnet/AS deve essere ben ponderata, minimamente restrittiva e temporanea.
Attacco indiretto (DNS Reflection Flood)
Le stesse tecniche già descritte possono essere utilizzate in maniera inversa per generare traffico DNS verso una infrastruttura di rete target. Stante la descrizione delle tecniche di riflessione e amplificazione precedentemente descritte, un attaccante può decidere di inviare a un DNS ricorsivo delle query DNS in cui l’indirizzo IP sorgente è alterato inserendone uno di una rete target.
In questo modo l’attaccante può fare “pivoting” sul server DNS (che risulterà essere la sorgente del traffico visto dalla rete target). Gli effetti di questo attacco sono:
- presenza di traffico in ingresso sulla rete target proveniente da un server DNS ricorsivo lecito;
- traffico amplificato non riconducibile all’attaccante;
- amplificazione del traffico.
In questo particolare caso, l’attaccante può utilizzare più server DNS ricorsivi per cui il traffico potrebbe pervenire da più sorgenti.
Mitigazione
La mitigazione diretta di questo attacco ricalca quella dell’attacco frontale.
Richiedendo questo tipo di attacco, la presenza di server DNS ricorsivi esposti su internet, è importante evitare7 che i sistemi in esercizio possano essere effettivamente utilizzati contro sistemi terzi limitandone l’accesso ai soli utenti strettamente necessari.
ICMP Flood
Il protocollo ICMP, posto a Layer 3 della pila ISO/OSI è certamente utile alle attività tecniche di monitoraggio, ma espone a problemi simili a quelli citati per gli attacchi su protocollo DNS. Di fatto questo protocollo non è direttamente utilizzato dagli utenti e nella maggior parte dei casi potrebbe essere disabilitato.
Ogni pacchetto ICMP può avere un peso massimo di 65.515 byte: anche in questo caso sono attuabili tecniche di riflessione e gli attacchi possono comportare il crash del sistema operativo/firmware del dispositivo target.
Mitigazione
Laddove possibile è consigliabile disabilitare il protocollo ICMP sui router, host e altri dispositivi di rete.
Qualora non fosse possibile bloccare del tutto il protocollo ICMP si valuti comunque di limitare la velocità di trasmissione di tali messaggi, di elaborazione delle Echo Reply e la dimensione massima dei pacchetti.
Qualora il protocollo fosse necessario all’esercizio di funzioni interne, è possibile bloccare il protocollo direttamente sui firewall perimetrali (ove la tecnologia in uso lo permetta); in tal caso – in accordo con gli esperti di rete – si raccomanda di valutare in maniera approfondita la disattivazione del protocollo ICMPv6, in quanto potrebbe comportare disservizi.
IPSec Flood
Il protocollo Internet Key Exchange (IKE) fa parte della suite dei protocolli IPsec ed è utilizzato per lo scambio sicuro delle chiavi di sicurezza. Questo protocollo è incapsulato nel protocollo di trasporto UDP, pertanto potenzialmente vulnerabile alle tecniche di spoofing e riflessione.
I protocolli IKE sono diffusamente utilizzati ad esempio dai servizi VPN; un attaccante potrebbe generare pacchetti malformati e inondare servizi di questo tipo per fa sì che il sistema interessato esaurisca tutte le risorse disponibili, impedendogli di soddisfare le richieste legittime.
Mitigazione
L’implementazione del protocollo IKEv2 limita di per sé la possibilità che l’utilizzo improprio di questo protocollo possa provocare disservizio, ma è comunque auspicabile prendere delle precauzioni preventive.
Qualora fosse possibile è consigliato creare delle ACL sui firewall che permettano l’utilizzo del protocollo solo a partire da IP specifici (soluzione consigliata almeno nelle VPN site to site o dove gli utilizzatori del servizio possano essere chiaramente identificabili).
Le strategie di blocco delle comunicazioni illecite dipendono spesso dal servizio VPN utilizzato. Per tale motivo si raccomanda di configurare tali servizi applicando tutte le best practice di sicurezza descritte dai rispettivi vendor.
Attacchi a esaurimento di stato
Gli attacchi a esaurimento di stato, in letteratura noti con il nome di “State-Exhaustion Attacks”, hanno come obiettivo quello di “esaurire” lo spazio di memoria dedicato alla rappresentazione delle tabelle di stato o di comportare un rallentamento nella ricerca sulle stesse.
Attacchi a devices che implementano il protocollo TCP
Gli attacchi più noti sono quelli che prendono di mira le tabelle di stato del protocollo TCP. L’implementazione standard di questo protocollo prevede una tabella delle sessioni necessaria a tenere traccia dei valori SYN e ACK identificativi di una sessione. Questa tabella cresce al crescere del numero degli end-point connessi e viene liberata nei casi previsti dal protocollo (es reset e timeout). La tabella in questione è tipicamente rappresentata in RAM e ha a disposizione uno spazio limitato. Durante la normale operatività questa tabella prevede l’esecuzione di continue operazioni di lettura e scrittura con performance che dipendono in particolare dall’utilizzo delle risorse a disposizione.
Inoltrando richieste che obbligano il sistema target ad accedere intensivamente a tale tabella, un attaccante potrebbe degradarne le performance fino ad ottenere il blocco del servizio ad esempio a causa del riempimento dello spazio a disposizione.
Questi attacchi prevedono quali bersagli i device di rete, end-point e in generale i sistemi operativi che implementano lo stack TCP/IP almeno fino al layer 3 e possono essere combinati con la tecnica dello spoofing dell’IP sorgente in quanto agiscono in una fase del protocollo (il cosiddetto “3-way-handshake”) in cui le peculiarità tipiche del protocollo TCP8 non sono ancora supportate.
Questi tipi di attacco non richiedono ingenti volumi di traffico né capacità di banda eccessive per ottenere il disservizio voluto, in effetti la quantità di memoria a disposizione per rappresentare le tabelle oggetto di questo attacco risulta spesso piuttosto limitata.
SYN flood DDoS
Nello specifico l’attacco a esaurimento di stato TCP, noto con il nome “SYN flood DDoS”, interviene nella fase di “handshake” e consiste nell’inviare al dispositivo target pacchetti TCP SYN per l’apertura di connessioni che l’attaccante non finalizzerà. Il dispositivo target, in assenza di sistemi di mitigazione per questo attacco, inizia le procedure necessarie per l’instaurazione di una nuova connessione con l’IP richiedente; tra le varie attività è presente la scrittura di una riga sulla tabella delle sessioni semi-aperte e l’inoltro di un pacchetto TCP ACK all’IP indicato come sorgente della comunicazione.
Non finalizzando il processo di 3-way-handshake9, l’attaccante potrebbe ottenere il riempimento dello spazio dedicato alla tabella delle sessioni TCP.
Esistono altre tecniche di attacco basate su principi simili. Ad esempio l’attacco denominato “RST Flood” è basato sull’inoltro di pacchetti RST (che comportano il reset di una connessione). Questo attacco mira al consumo dei processi macchina necessari per la consultazione della tabella delle sessioni in quanto il dispositivo target sarà costretto ad analizzare tutta la tabella in cerca del record da rimuovere.
L’esecuzione combinata di un attacco SYN-Flood e RST Flood aumenta la probabilità di riuscita dell’attacco.
Mitigazione
La normale implementazione del protocollo TCP è vulnerabile a questo tipo di attacco e non sono in generale note attività che possano impedire impatti, se non l’utilizzo di sistemi Anti-DDoS.
È comunque possibile agire su alcuni parametri, quali:
- aumento della dimensione della tabella delle connessioni TCP semi-aperte (aumentando così il numero di connessioni necessarie a creare disservizio);
- utilizzo di SYN Cookie, qualora questi siano supportati dal device di rete e dai client (prevenendo il disservizio per gli host già connessi al momento dell’inizio dell’attacco);
- diminuzione dei tempi di timeout lato server (soluzione che permette di cancellare le sessioni malevole in meno tempo, ma che può generare disservizi).
Le soluzioni messe in campo dai fornitori di servizi Anti-DDoS consistono nell’anteporre ai server target dei device di rete che implementano versioni proprietarie del protocollo TCP e gestiscono la fase di “handshake” in maniera performante; la comunicazione tra l’host e il servizio finale avviene solo a valle della corretta conclusione di questa fase, pertanto l’eventuale sovraccarico malevolo ricade totalmente sui server dedicati che inoltrano verso i servizi finali le sole sessioni aperte correttamente.
Attacchi ai server DNS
Gli attacchi ad esaurimento di stato rivolti verso i server DNS, noti in letteratura come “NXDOMAIN Flooding” o semplicemente “DNS Query” sono concettualmente simili a quelli rivolti contro i device che implementano il protocollo TCP, ma si basano sul solo consumo delle risorse di calcolo necessarie per eseguire una ricerca nella tabella delle chiavi DNS o sul consumo di processi e banda necessaria a consultare il server autoritativo per la query DNS (in caso di servizi DNS ricorsivi).
Mitigazione
La mitigazione di tali attacchi in assenza di soluzioni Anti-DDoS risulta estremamente complessa. Ad ogni buon conto è possibile implementare alcune misure di configurazione capaci di ridurne parzialmente gli effetti, ad esempio:
- verificare l’aggiornamento della cache DNS lato server;
- implementare il rate-limiting delle risposte DNS;
- aumentare il TTL a valori opportuni per minimizzare l’accesso al database (quindi il full table scan);
- ridurre il timeout per le richieste ricorsive,
- monitorare i log delle richieste dei client al fine di identificare comportamenti malevoli.
Attacchi applicativi
Gli attacchi applicativi possono essere suddivisi in due macro-aree, quelli che prendono di mira l’applicazione software (ad esempio il sito web) e quelli che prendono di mira il container dell’applicazione (ad esempio il web server).
Gli attacchi DDoS rivolti verso l’applicazione software dipendono dal codice dello specifico prodotto e consistono nell’accesso intensivo a una risorsa che per essere generata richiede un notevole sforzo computazionale.
I primi sintomi di un attacco di questo genere sono l’aumento delle risorse utilizzate e il rallentamento nella fruizione del servizio, fino al totale blocco. Un esempio di questo tipo di attacchi è noto come “Wordpress XML RPC DDoS”.
Questo tipo di attacchi possono essere mitigati sviluppando software performante, installando le patch di sicurezza e frapponendo tra l’utenza e l’applicazione sistemi Web Application Firewall (WAF).
Gli attacchi DDoS rivolti verso i service container (ad esempio i web server) colpiscono le risorse di rete e di calcolo del servizio e del sistema operativo, comportano sintomi simili a quelli del caso precedente, ovvero rallentamento o blocco del sito.
Esistono diverse tipologie di attacchi DDoS applicativi e in generale tutti si basano sull’accesso anomalo al servizio. Gli attacchi noti come “Slowloris, Slow POST e Slow Read”10 si basano sull’inoltro di chiamate malformate o sul rallentamento volontario nell’accesso alle risorse esposte. Gli stessi attacchi possono essere anche di natura intensiva con l’utilizzo di chiamate lecite tramite botnet e software automatici.
Queste problematiche sono normalmente invisibili a livello software, in caso di Slow POST, ad esempio, il software applicativo (es. il codice PHP, Java, C#, Python, …) verrà invocato dal web server – ricevendo contestualmente tutti i dati contenuti nella POST – solo al termine del trasferimento degli stessi, pertanto l’attacco non sarà immediatamente identificabile.
Mitigazioni
Per individuare e mitigare gli effetti di attacchi applicativi è consigliabile l’utilizzo di sistemi IPS (Intrusion Prevention System) in grado di effettuare “deep packet inspection” (riconoscimento del protocollo applicativo). Diverse soluzioni IPS cloud based permettono inoltre di richiedere la risoluzione di un CAPTCHA11 per gli utenti che accedono ai servizi da specifiche posizioni geografiche.
Nel caso specifico di sistemi Web è possibile utilizzare Web Application Firewall (WAF), che in genere identificano e mitigano questi attacchi.
Le soluzioni IPS/WAF per poter essere efficaci devono godere di determinate proprietà:
- sufficiente banda e capacità di calcolo: esistono soluzioni on premise e on cloud. Entrambe le soluzioni hanno pro e contro relative a costi, performance e scalabilità;
- credenziali necessarie per effettuare il “deep packet inspection”. Nel caso di esempio relativo al servizio web, il WAF deve avere a disposizione il certificato SSL dei siti internet da monitorare affinché questo possa comprendere il traffico criptato e agire qualora necessario.
Oltre a queste soluzioni orientate alla mitigazione dell’attacco, possono essere preventivamente applicate misure di ottimizzazione del servizio. Nel caso di esempio relativo al mondo web è possibile utilizzare servizi professionali di Content Delivery Network (CDN) al fine di scaricare parte dell’attività del web server, come ad esempio la pubblicazione di contenuti statici, su sistemi decentralizzati e ottimizzati per compiere questo lavoro.
Esistono servizi CDN che integrano anche servizi WAF e Anti DDoS, fornendo una protezione di base piuttosto completa, ciononostante è anche possibile accedere gratuitamente a provider di CDN che forniscono il solo servizio di cache dei contenuti statici; quest’ultimi, pur non fornendo una protezione completa, risultano utili nell’assolvere parte del lavoro dei web server, i quali, a parità di carico e di hardware, risulterebbero dunque più performanti.
