Project Shield: i retroscena di un attacco DDoS record

Ecco come Project Shield, sistema di mitigazione attacchi DDoS Google, ha gestito la delicata situazione del portale KrebsOnSecurity

 

Project Shield servizio di mitigazione attacchi DDoS

Chi ha seguito nelle ultime settimane le news di Hosting Talk ricorderà probabilmente l’articolo dedicato al malware Mirai ed al suo presunto co-creatore Paras Jha.

A documentare nel dettaglio tutte le informazioni riguardanti Mirai e le attività illecite annesse (richieste in denaro a vari provider statunitensi etc.) il giornalista investigativo Brian Krebs che, a causa della propria attività, si è creato negli anni numerosi nemici.

Ed è a Settembre 2016 che questi ultimi entrano in azione:  il portale curato da Brian, KrebsOnSecurity, subisce un attacco DDoS record (620Gbps), un “traguardo” superato solo un mese dopo dall’attacco DDoS al provider DNS DYN – ad oggi ancora ineguagliato. Entrambe le “azioni di disturbo”, come si scoprirà in seguito, sono state possibili anche grazie a Mirai ed a migliaia di dispositivi IoT bypassati e “convertiti forzatamente” alla causa.

Vista la portata non trascurabile dell’attacco, l’allora provider del servizio di mitigazione attacchi Akamai decide di fare un passo indietro, motivandolo in sintesi come uno sforzo eccessivo di risorse commisurato al guadagno (nullo, essendo offerto gratuitamente). Per alcuni giorni Krebs rimane quindi offline fino a quando Project Shield, servizio analogo a quello Akamai gestito da Google, non presta soccorso al giornalista.

Alcuni retroscena della vicenda sono stati rivelati proprio nel corso della manifestazione Enigma 2017 – dedicata al tema della sicurezza.

Valutazione del rischio

Krebs on Security: elenco degli attacchi DDoS subiti dopo il ritorno online

Schema che riassume gli attacchi gestiti nelle prime ore da Shield – fonte ArsTechnica

 

“Cosa succede se questa botnet manda offline google.com e perdiamo tutti i nostri guadagni?” è stata una delle domande più ricorrenti rivolte a Damian Menscher (Google Security Reliability Engineer). La scelta di offrire gratuitamente protezione a KrebsOnSecurity e fronteggiare l’attacco ha richiesto circa un’ora di valutazioni e confronto all’interno del team guidato dall’ingegnere.

“[Abbiamo concluso che se la botnet poteva mandarci offline, eravamo probabilmente tutti quanti a rischio. Non c’era niente che potesse impedirgli di attaccarci in un qualsiasi momento. Non avevamo quindi niente da perdere]” ricorda l’ingegnere in merito alla riunione menzionata.

Dopo aver risolto alcuni imprevisti burocratici legati alla richiesta del servizio, Shield si è dovuto confrontare con una serie di eterogenei attacchi. Una volta che KrebsOnSecurity è tornato online, afferma Menscher, sono passati infatti 14 minuti prima che gli hacker riprendessero la manovra di disturbo inviando 130 milioni di pacchetti syn (sincronizzazione) al secondo. L’attacco, come anticipato, si è strutturato in più fasi il cui culmine è stato raggiunto alla quarta ora di “assedio” con 450.000 query HTTP al secondo provenienti da 175.000 indirizzi IP differenti – inequivocabile prova del coinvolgimento di Mirai.

Nelle due settimane successive gli sforzi degli hacker non hanno più raggiunto la medesima intensità (per fortuna di Krebs!), prosegue Menscher, ma hanno messo in campo variegate tecniche di assalto, ricorrendo ad un WordPress Pingback attack (l’intento era di sommergere il server con migliaia di notifiche di menzione link) o ad un cache-bursting attack – entrambi termini coniati dal team.

Alcune conclusioni sull’attacco DDoS Mirai

Damian Menscher ha dichiarato che proteggere un piccolo sito come quello di Krebs è molto più complicato del previsto. Per fronteggiare centinaia di migliaia di query al secondo (su un sito in grado di gestirne una ventina) sono dovuti ricorrere ad alcuni espedienti (limitazione del traffico “cattivo” e utilizzo della cache per la gestione del traffico “buono”):

“Defending a small site is really hard. All of my experience at Google for years was defending a very large site. If we had an extra thousand queries going through to one of our services, it wasn’t a big deal. But Brian’s origin server could maybe handle around 20 queries per second. We saw attacks of up to 450,000 queries per second. How do you deal with that? It’s a little bit challenging.

One thing you can do is you can rate limit the bad traffic. So you have to identify the bad traffic and try to throttle that down. Another thing that helps a lot is you can serve good traffic from cache. This takes a lot of load off the origin server. It also gives you this benefit of even if the origin server is unhealthy, you still have its content cached so you can continue to serve users and there isn’t really a visible outage.”

E sorprendentemente l’ingegnere ha parlato anche di come a volte sia necessario correre dei rischi, anche in realtà come quella di Google in cui i downtime devono essere limitati (se possibile) ogni anno ad una manciata di minuti:

“I was trained as a physicist, and in physics we’re always trying to figure out how the world works. But you have to ask the right questions. You have to investigate things. You always have to be willing to question your assumptions. DDoS defense is very similar. You can’t just look at the attacks you’re getting. You have to be more proactive and try to attract more attacks and take some risks.”

Fonte

 

Facci sapere cosa ne pensi!

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *