Mitigare gli attacchi low-and-slow ad applicazioni e API

This post is also available in: Inglese Francese Tedesco Portoghese, Brasile Spagnolo Russo

“Low-and-slow” può sembrare un argomento datato, ma è ancora molto rilevante e opportuno. Nel 2020, il 65% delle aziende ha subito attacchi low-and-slow, il 30% con cadenza mensile. Dedichiamo quindi a questo argomento quei cinque minuti che merita!

Quando un aggressore vuole far cadere un’applicazione, il metodo più semplice consiste nel lanciare grandi volumi di traffico verso la stessa e far cadere l’application server (Distributed Denial of Service o DDoS). Tuttavia, oggi ci sono molte tecnologie che possono rilevare e bloccare tali tentativi, mediante blocco IP o signature-based, quota management o soluzioni di mitigazione DDoS dedicate.

Nell’ultimo mese, oltre ai flood, abbiamo assistito al ritorno di un’altra tecnica vecchia ma ancora molto efficace: l’attacco low-and-slow. A fine di febbraio, Radware ha già rilevato un aumento del 20% negli attacchi low-and-slow contro i nostri clienti rispetto al quarto trimestre del 2020.

Un ripasso su low-and-slow

Anziché generare un burst improvviso di traffico, gli attacchi low-and-slow (noti anche come low-rate) volano sotto i radar. Essi mirano a far cadere un target in modo silenzioso, lasciando connessioni aperte sul target, creando un numero relativamente basso di connessioni in un determinato periodo di tempo e lasciando tali sessioni aperte il più a lungo possibile.  

I metodi più comuni consistono nell’inviare richieste HTTP parziali e piccoli pacchetti di dati o messaggi “keep alive” per impedire alla sessione di diventare inattiva o scadere. Questi vettori di attacco non sono soltanto difficili da bloccare ma anche da rilevare.

[Ti potrebbe interessare anche: How to Keep APIs Secure in an Interconnected World]

Per lanciare questi attacchi gli aggressori hanno a disposizione diversi strumenti, tra i quali SlowLoris, SlowPost, SlowHTTPTest, Tor’sHammer, R.U.Dead.Yet e LOIC.

Gli attacchi low-and-slow, che erano molto efficaci contro le applicazioni, stanno ora approfittando delle API, che sono meno sorvegliate rispetto alle applicazioni, facendosi strada verso il target. Data il volume ridotto – e ciò che potrebbe sembrare un tentativo legittimo di collegarsi alle risorse dell’applicazione o del server – si rende necessaria una diversa tecnologia di mitigazione. La fonte dovrebbe essere bloccata su base behavioral piuttosto che in base alla reputazione.

Blocco su base behavioral

La sincronizzazione tra componenti di rilevazione e mitigazione è uno dei motivi per i quali Radware è considerata leader di settore nella protezione DDoS: Gli algoritmi di apprendimento comportamentale monitorano e misurano i tempi di risposta della connessione TCP tanto del client quanto del server e si assicurano che la fonte interagisca con l’applicazione nel modo previsto. 

Questo metodo non comporta alcuna interazione con l’applicazione e non introduce alcun rischio per la stessa, in quanto la mitigazione ha luogo a livello di sessione. Pertanto, usando un unico meccanismo di segnalazione e flussi di lavoro automatizzati, i tentativi successivi saranno bloccati a livello di perimetro di rete, senza alcun impatto sull’applicazione.