La resilienza di una rete di telecomunicazioni ad attacchi di tipo DDoS
Negli ultimi anni, gli attacchi Distribuited Denial of Service (DDoS) hanno guadagnato grande visibilità non solo sulle testate del settore ICT ma anche sui media generalisti in virtù della loro crescente numerosità e della rilevanza degli impatti che hanno comportato. Le motivazioni sono le più varie: portare a termine un’estorsione; attuare un diversivo atto a coprire altre attività illecite volte al furto di informazioni; attuare una protesta digitale (“hacktivism”); distorcere i processi competitivi impedendo a qualcuno di erogare i propri servizi online.
La parte numericamente più rilevante degli attacchi DDoS è costituita dagli attacchi volumetrici che hanno come obiettivo la saturazione delle risorse di connettività; i DDoS, però, possono anche puntare ad esaurire risorse diverse dalla banda disponibile come, ad esempio, il numero di sessioni contemporanee gestibili da un firewall o la memoria dedicata ai processi di comunicazione su un server che ospita un portale. Qualsiasi azienda che basi, anche solo in parte, il suo business su Internet è esposta a questa minaccia.
Un ISP per sua natura ha una rete “aperta” e “neutrale” che deve avere delle caratteristiche e delle contromisure in grado di fronteggiare un attacco di tipo DDoS verso le proprie infrastrutture (Data Center, DNS, router, etc…) o verso la rete di un proprio cliente. L’ISP è, nei fatti, il partner di elezione del cliente per la protezione da attacchi DDoS nella consapevolezza che, anche la migliore soluzione di network security da utilizzare on-premise (WAF, IPS, Firewall, etc…), nulla potrebbe contro un evento di dimensioni tali da saturare la capacità del suo accesso ad Internet.
Chiunque si occupi di Information Technology avrà dedicato attenzione ad eventi come l’attacco di Settembre 2016 da 620 Gbps verso il blog di Brian Krebs, noto esperto di sicurezza, o quello verso l’azienda francese di web hosting OVH, con un picco che ha superato 1 Tbps, nonché all’attacco dell’Ottobre 2016 verso Dyn, colosso nell’erogazione di servizi DNS, che ha comportato in tutti gli Stati Uniti orientali un degrado nella fruizione di Twitter, Amazon, Tumblr, Reddit, Spotify e Netflix. Nel 2018, poi, è arrivata la conferma della continua crescita del trend dei volumi degli attacchi DDoS con picchi mai raggiunti in passato: 1,35 Tbps verso Github, utilizzatissima piattaforma per lo sviluppo collaborativo di software e ben 1,7 Tbps osservati in un attacco avvenuto negli USA (grafico da https://www.arbornetworks.com/blog/asert/netscout-arbor-confirms-1-7-tbps-ddos-attack-terabit-attack-era-upon-us/).
Il SOC di TIM, nel corso del 2017 ha analizzato e gestito poco meno di 8000 attacchi; quello con il volume maggiore ha sfiorato i 160 Gbps. Il trend è in costante crescita con +19% nel 2016 rispetto al 2015 ed un +27% nel 2017 rispetto al 2016. La distribuzione degli attacchi volumi/durate è descritta in Figura. Il 2% degli attacchi hanno come target l’infrastruttura TIM mentre il 98% ha come target risorse IP dei clienti.
Attacchi con questi volumi vengono lanciati da chi è in grado di controllare una botnet, cioè un insieme di computer e dispositivi che sono stati “compromessi” attraverso la diffusione di malware o sfruttando vulnerabilità nei loro software; questi eserciti di macchine zombie arrivano a poter contare centinaia di migliaia o milioni di unità.
BOTNET E “REFLECTION&LIFICATION” ATTACK
Le botnet vengono efficacemente impiegate nella generazione di attacchi DDoS in più modalità; i bot possono produrre grandi volumi di traffico di specifiche tipologie diretti verso un target oppure possono essere sfruttati in modo diverso, facendo leva su due fattori: i meccanismi di reflection and amplification e l’applicazione solo parziale da parte degli ISP di politiche di anti-spoofing, cioè che impediscano ai loro clienti di generare traffico con un indirizzo IP sorgente che non è a loro assegnato.
L’effetto di reflection and amplification si ottiene grazie al comportamento di alcuni servizi, presenti su un grande numero di host (server, PC, modem/router, dispositivi IoT, etc..), non opportunamente configurati. C’è una continua ricerca, sia da parte di “white hat” che di “black hat”, di servizi che abbiano potenzialità di reflection and amplification. Negli ultimi anni ne sono stati identificati un discreto numero; tra questi possiamo ricordare Network Time Protocol (NTP), Character Generator Protocol (CharGEN) e Simple Service Discovery Protocol (SSDP), solo per citare alcuni dei più noti, fino ad arrivare al recente “Memcache” che garantisce fattori di amplificazione altissimi e che è prepotentemente balzato all’onore delle cronache perché utilizzato negli attacchi record del 2018.
Per lanciare un attacco DDoS i bot, tramite un meccanismo di controllo, vengono indotti a generare un traffico opportunamente forgiato e diretto verso gli host che espongono il servizio cha garantisce l’effetto di reflection and amplification. Questo traffico viene generato fingendo di essere il target, ovvero usando come indirizzo IP sorgente quello del target, comportamento consentito solo dove mancano misure di anti-spoofing. Tutto il traffico generato dalla botnet viene quindi riflesso ed amplificato verso il target, con il vantaggio ulteriore per l’attaccante di nascondere all’attaccato i reali IP della botnet.
L’avvento della Internet of Things (IoT) da questo punto di vista ha complicato lo scenario: ha incrementato ed incrementa con continuità in rete il numero di devices equipaggiati con software minimali, nei quali l’attenzione agli aspetti di sicurezza è ridotta al minimo; ciò facilità il compito di chi vuole comprometterli prendendone il controllo. Sono state infatti individuate botnet composte quasi completamente da dispositivi IoT: quella denominata Mirai, che è stata protagonista nell’attacco a Dyn, ne è l’esempio più noto.
La costruzione e la crescita di un vero e proprio business basato sulla capacità di lanciare attacchi DDoS, secondo il paradigma “DDoS as a Service”, rende disponibile questa arma a una platea di potenziali utilizzatori sempre più ampia, contribuendo alla crescita del numero degli attacchi oltre che aumentando la capacità dei “black hat” di investire risorse economiche nella ricerca di tecniche di attacco nuove e sempre più sofisticate.
LA GESTIONE DI UNA ATTACCO DI TIPO DDOS
Il macroprocesso di gestione di un attacco DDoS, è diviso in due fasi:
- Detection: si concretizza nella rilevazione di un attacco DDoS, e di anomalie di traffico in genere, che viene effettuata attraverso la correlazione di eventi generati da più strumenti; l’elemento centrale è una piattaforma che elabora informazioni sintetiche sul traffico prodotte dai nodi di rete. Questi descrittori arrivano al livello 4 dello stack ISO/OSI, senza quindi guardare al payload dei pacchetti, e vengono esportati con un certo passo di campionamento, pur restando assolutamente efficaci ai fini della rilevazione: l’introduzione di strumenti dedicati all’analisi di questi dati, e non della totalità del traffico, è stata la grande innovazione che, oramai più di 15 anni fa, ha consentito di venire incontro all’esigenza di monitorare in tempo reale, alla ricerca di DDoS, grandissime quantità di traffico.
- Reaction: prevede che, a seguito della rilevazione, vengono attivate le opportune contromisure volte a bloccare i flussi di traffico non leciti ed a contenere tutti gli impatti; le tecnologie di Intelligent DDoS Mitigation System (IDMS) che si occupano del traffic cleaning, ovvero di analizzare il traffico ed eliminare solo parte malevola, svolgono un ruolo principale e devono essere dimensionate in coerenza con i volumi degli attacchi a cui si ritiene di dover rispondere (tipicamente centinaia di Gbps).
In ragione della rapidità con cui si manifestano gli impatti c’è un impegno costante nella ricerca di soluzioni tecniche volte a rendere più rapida la rilevazione, diminuendo il mean time to detect (MTTD), e ad automatizzare la reazione e l’implementazione delle contromisure al fine di minimizzare il mean time to respond (MTTR), mantenendo un approccio conservativo per evitare di incorrere in falsi positivi.
Per l’impiego degli IDMS le soluzioni architetturali possibili sono differenti, ciascuna con pro e contro: l’ideale per gestire il traffico malevolo proveniente dall’esterno della rete dell’ISP sarebbe collocare le risorse di traffic cleaning in prossimità di tutti i possibili punti di ingresso. Questo però significa ‘frammentare’ la capacità di cleaning e aumentare i costi. In alternativa si individuano dei punti topologicamente appropriati nella rete dell’ISP per inserire delle scrubbing farm dove centralizzare tutta la capacità di cleaning, con il contro di dover trasportare il traffico di attacco dal punto di ingresso fino a questa infrastruttura; questo approccio è oggi quello più utilizzato. In base alla scelta fatta per il posizionamento degli IDMS vanno poi previste delle opportune configurazioni che consentano di realizzare al momento opportuno la traffic diversion, per portare tutto il traffico destinato al target verso le risorse di cleaning, e la traffic reinjection, per consegnare la parte lecita del traffico al target dell’attacco. La traffic diversion può essere realizzata sia mediante modifiche sul piano di routing, che agendo sui DNS che risolvono il nome logico del servizio da proteggere: questa modalità è tecnicamente più agile, ma la protezione così realizzata può essere bypassata in modo abbastanza semplice da azioni che puntino direttamente all’IP della risorsa target.
Non va trascurata, infine, l’esistenza di scenari nei quali soluzioni di traffic cleaning posizionate in prossimità del target, anche on customer premise e costantemente in line sul traffico, concorrono alla due fasi di detection e reaction, al fine di migliorare la reattività e la sensibilità della contromisura.
Un’azienda (e quindi anche un ISP) oggi ha anche la possibilità di stringere accordi commerciali per avere la collaborazione di player che operano a livello mondiale offrendo servizi di protezione network agnostic e con capacità di cleaning estremamente elevate e distribuite nel mondo. Nel caso dei servizi network agnostic va osservato che agiscono, dal punto di vista della traffic diversion basata sul routing, in maniera meno chirurgica (almeno una subnet /24 ossia 256 indirizzi IP) di quanto si possa fare localmente alla rete dell’ISP (dove si può modificare il routing per singolo indirizzo IP).
Allo scopo di contenere la minaccia rappresentata dai DDoS, si può delineare un approccio layered, su più livelli: un primo livello basato su una componente customer premise, in grado di gestire flussi di attacco che non superino in volume la capacità di banda del collegamento che vede il target, un secondo livello erogato dall’ISP che si occupi di attacchi gestibili con la cleaning capacity installata (dall’ISP), ed un terzo livello gestito tramite accordi con i player che offrono protezione network agnostic.
In considerazione dell’incremento della dimensione degli attacchi, nell’ambito di una ottimizzazione degli investimenti in soluzioni di protezione, una significativa novità è rappresentata dall’introduzione di BGP Flowspec. Questa funzionalità consente di utilizzare il protocollo BGP, solitamente destinato a trasportare informazioni sulla raggiungibilità delle subnet, per distribuire azioni applicabili a flussi di traffico identificabili specificando un rilevante numeri di parametri. I technology vendor, nonostante la prima specifica di BGP Flowspec risalga a quasi 10 anni fa (RFC5575, Agosto 2009), solo di recente hanno iniziato ad introdurre sui nodi di rete carrier class il supporto alle possibili azioni che mediante BGP Flowspec possono essere indicate. In questo scenario la fase di reaction, limitatamente ad alcune contromisure (es. rate limiting, drop del traffico), viene effettuata direttamente dagli apparati di rete, cosa che verrà ancora di più accelerata dall’evoluzione che alcuni dei vendor di tecnologia di rete (parliamo quindi di apparati la cui capacità si misura in decine di terabit al secondo) iniziano a proporre mediante hardware in grado di rendere disponibili una parte delle capacità proprie degli IDMS a bordo dei router. Un’evoluzione di questo tipo, in potenza, consentirà agli ISP di gestire direttamente sui nodi di frontiera della loro rete un gran numero di attacchi aprendo nuove possibilità, con un conseguente adeguamento delle soluzioni oggi impiegate a beneficio proprio e dei clienti.
La big picture tecnologica tratteggiata non può prescindere da competenze e processi, che sono componenti indispensabili nella gestione operativa della sicurezza. Solo l’acquisizione del know how ed un’analisi continua degli scenari di rischio portano all’implementazioni di contromisure puntuali ed efficaci. Un esempio in tal senso è il contenimento di attacchi di refletcion and amplification basati sul protocollo NTP, oggi realizzato grazie ad una azione di filtraggio implementata sui nodi di rete, mediante access-list (ACL), che è stata identificata a valle di un lavoro di analisi sul traffico di attacco.
A cura di: Giovanni Ciminari e Giuseppe Giannini
Da più di 10 anni Responsabile dell’Ingegneria delle Soluzioni di Sicurezza ICT in TIM. In questo ruolo, Giovanni Ciminari si è cimentato nella realizzazione di decine di progetti per la protezione di rete e IT e per garantire la compliance ai vari provvedimenti del settore. Grazie a questa esperienza ha contribuito alla realizzazione di iniziative di successo verso grandi clienti TIM; tra queste, nel 2015 ha guidato il progetto per l’implementazione della sicurezza informatica dell' Expo di Milano. Dopo la laurea in ingegneria elettronica ed alcune esperienze in ambito manufacturing, è entrato in Telecom Italia maturando competenze nell’ambito della gestione della Rete, prima di abbracciare le tematiche di ICT security. È certificato CISM e CSX.
L’Ing. Giuseppe Giannini lavora su temi legati alla network security nel gruppo Telecom Italia dal 2003; si occupa della definizione di soluzioni e progettazione di piattaforme per la sicurezza del backbone IP e della rete corporate di TIM, con un focus sugli attacchi DDoS e le anomalie di traffico. Ha maturato una ampia esperienza su architetture di rete fixed/mobile e sulla protezione di infrastrutture critiche; ha svolto attività di network security assessment presso consociate estere. È membro dell’ETNO CERT Task Force come DDOS Expert per TIM.
