Vincere la botconomics per proteggere i datacenter

Dario Colombo -

9 Dicembre 2010

Gli attacchi Ddos (Distributed denial of service) sono fra le peggiori minacce all’operatività di un’azienda. Con Marco Gioanola, Consulting Engineer di Arbor Networks, puntiamo a comprenderne la fenomenologia e a trovare soluzioni.

L’ultima edizione disponibile del Worldwide Infrastructure Security Report rilasciato da Arbor Networks, quella del 2009 (la nuova edizione uscirà prossimamente) evidenzia due dati: la dimensione del maggiore attacco Ddos rilevato nel periodo è stata di 49 Gigabit al secondo; è aumentata la frequenza e la durata degli attacchi minori: globalmente viene stato registrato un attacco di almeno 1 Gigabit/s ogni 26 minuti, e la gran parte di questi ha una durata superiore alle 8 ore. Gli attacchi di dimensione inferiore al Gigabit sono ormai routine.

Affrontiamo la questione Ddos con Marco Gioanola, Consulting Engineer di Arbor Networks Emea Italia.

Come e perché gli attacchi Ddos attentano alla sicurezza dei data center?

Sicurezza significa protezione dei dati e disponibilità delle risorse, e gli attacchi Dsos rappresentano una minaccia potenzialmente distruttiva verso i datacenter. Si stima che a livello globale siano milioni i pc infetti facenti parte di botnet pronte a obbedire ai comandi dei server di controllo per sferrare attacchi verso le destinazioni prescelte. È dal 2007 che Arbor sottolinea i rischi della cosiddetta botconomic: per poche centinaia di dollari, nei canali underground è possibile affittare una botnet per eseguire attacchi Dsos a comando.

Chi deve decidere e con quale tempistica le azioni per limitare gli attacchi?

È importante che in ogni datacenter esista un processo di rilevamento, reazione e, se possibile, prevenzione degli attacchi. Questo processo deve coinvolgere figure specialistiche preposte alla gestione degli eventi di sicurezza, ma anche i responsabili dell’infrastruttura di rete, i server administrator, e l’utente finale. È importante che siano definite chiaramente, tra gestore del datacenter e utente, le modalità con cui gli attacchi vengono rilevati e mitigati: quali servizi stiamo proteggendo e come possiamo farlo al meglio? Qual è la criticità delle risorse sotto protezione? Meccanismi automatici di mitigation sono necessari, desiderabili o da escludere? È necessario o possibile intervenire in tempo reale in caso di ogni attività sospetta anche a rischio di inficiare una parte del traffico legittimo? Porsi questo tipo di domande permette di disegnare le modalità di protezione opportune per ogni utente.

Come si riverberano sugli utenti e su chi deve gestire i centri in termini di operazioni?

Un fattore che spesso non viene considerato dagli utenti è quello degli “effetti collaterali” di un Ddos: un attacco volumetrico diretto a un sito in particolare presente in un datacenter può facilmente impattare gli altri servizi ospitati nella stessa struttura. Per chi gestisce giornalmente un datacenter, invece, il Ddos è una situazione particolarmente stressante e di difficile gestione: senza gli strumenti adeguati, e’ spesso impossibile ottenere informazioni utili da parte degli apparati di rete, dai server sotto attacco e anche dagli apparati di sicurezza inline, tutti sopraffatti dal flooding di traffico.
In caso di attacchi particolarmente sofisticati, si verifica la situazione opposta, in cui l’utente si lamenta che il server è lento ma nessun dispositivo di sicurezza segnala malfunzioni. Questo comporta enormi perdite di tempo durante il troubleshooting e tentativi di mitigation alla cieca a base di riavvii degli apparati e di una costante rincorsa a bloccare attacchi in continuo cambiamento. Spesso addirittura non ci si rende nemmeno conto con certezza di aver subito un attacco, e quando il problema rientra lo si imputa a qualche generica malfunzione che raramente viene chiarita.

Quali applicazioni sono maggiormente inficiate dagli attacchi?

I servizi Web, ovviamente, e i server Dns sono le principali vittime. Le attività di e-commerce vengono colpite spesso a scopo d’estorsione o per mettere temporaneamente fuori gioco un concorrente scomodo. Si va dagli attacchi brute-force che mirano a congestionare la banda agli attacchi estremamente sofisticati che sfruttano le transazioni web stesse per congestionare gli application server. Per questo e’ necessario poter gestire sia alti volumi di traffico “spazzatura” che attacchi portati attraverso sessioni del tutto legittime da un punto di vista strettamente applicativo. Non va inoltre sottovalutata la minaccia degli attacchi di natura prettamente vandalica o con motivazioni sociali/politiche.
I Dns, poi, rappresentano uno dei meccanismi chiave del funzionamento delle reti Ip, ed è per questo che sono il bersaglio preferito nel caso in cui l’attaccante voglia infliggere danni su larga scala: se il Dns non è disponibile, tutti gli utenti risultano, fondamentalmente, offline.

Per garantire l’availability come va governata l’ampiezza di banda e con quali strumenti?

L’esperienza nel mondo degli Isp ha insegnato ad Arbor che, in caso di attacco Ddos, gli strumenti di protezione inline tradizionali come firewall e Ips e gli strumenti di controllo e supporto come Dpi e load balancers spesso si aggiungono alla superficie disponibile agli attaccanti piuttosto che collaborare alla mitigation della minaccia. Arbor ritiene che per garantire la disponibilità della banda sia necessaria una soluzione specifica anti-Ddos, complementare agli strumenti di sicurezza esistenti, che oltre a proteggere l’utente finale permetta a firewall e Ips di continuare a svolgere le proprie funzioni anche in situazioni critiche. La soluzione Arbor Peakflow Sp Tms è studiata espressamente per garantire le prestazioni necessarie alla gestione degli attacchi Ddos, in modalità chirurgica e on-demand: solo il flusso di traffico anomalo viene deviato verso il Tms, quando necessario.

Qual è la ratio degli investimenti da fare per dare continuità ai data center? Tecnica o economica?

L’esperienza ci mostra che non èpensabile dimensionare le risorse di un datacenter in termini di banda o capacità computazionale per coprire il “caso peggiore”: devono piuttosto essere previsti strumenti opportuni per gestire le situazioni di emergenza, che si tratti di un Ddos o di una flash crowd di utenti attratti da un’offerta speciale.
Ogni buon amministratore di datacenter esegue processi di risk assessment rispetto a un’ampia gamma di minacce alla disponibilità: incendi, blackout, eventi naturali, eccetera. Vengono valutati la criticità degli asset da proteggere, le minacce possibili, la probabilita’ di essere colpiti da un evento negativo, la consistenza economica dell’eventuale downtime, il rischio residuo accettabile, e in base a questi parametri vengono sottoscritte polizze di assicurazione, acquistati apparati ridondanti, irrobustita l’infrastruttura. Il Ddos non è diverso da tutto ciò. Il sito Web è un asset, la mancata presenza online genera danni economici diretti e di reputazione, e la frequenza degli attacchi è preoccupantemente alta. È per certi versi sorprendente vedere come (correttamente) nessuno metta in dubbio la necessità di dotarsi di assicurazioni contro eventi naturali piuttosto rari, mentre un evento relativamente comune come gli attacchi Ddos venga spesso ignorato.

Come si pianifica nel medio-lungo periodo la continuità operativa del data center? Quali sono i parametri di valutazione?

Per quanto riguarda la protezione dagli attacchi Ddos, è fondamentale dotarsi di strumenti che forniscano la visibilità necessaria a valutare il proprio uptime e a comprendere i meccanismi di evoluzione del traffico diretto al datacenter: quali clienti, quali servizi consumano le risorse di rete? Qual è il profilo tipico del traffico per una determinata applicazione? Siamo in grado di rilevare eventi sospetti come ad esempio flussi inconsueti di traffico verso determinate aree geografiche?
Arbor inoltre ritiene che sia fondamentale instaurare meccanismi di cooperazione, ad esempio tra chi gestisce il data center e l’Internet Service Provider, per contrastare la minaccia a tutti i livelli. È necessario disporre di canali di comunicazione con l’Isp per attivare meccanismi di protezione in the cloud quando necessario.