Bunny.net: perché un attacco DDoS a volte è identico al traffico normale

Il blog di Bunny.net, a firma Dino Kukic con Rishi Raj Jain, pubblica oggi un'analisi che vale la pena leggere per chi deve decidere dove mettere i cordoli anti-DDoS: non tutti gli attacchi si vedono allo stesso modo, e il motivo non è la dimensione ma il livello dello stack a cui colpiscono.

A livello 3/4 (SYN flood, amplificazione DNS/NTP/memcached, pacchetti frammentati) il segnale è misurabile prima ancora che il codice applicativo giri: bit al secondo, pacchetti al secondo, handshake mai completati. Nessun client legittimo si comporta così, quindi il drop all'edge costa poco. A livello 7 il problema cambia natura: una GET su una pagina prodotto generata da un botnet e la stessa GET fatta da un cliente durante un lancio promozionale possono essere identiche sul filo. Per distinguerle serve decifrare il traffico, fare il parsing della richiesta e confrontarla con una baseline comportamentale — lavoro che costa CPU prima ancora di poter bloccare qualcosa.

L'articolo passa in rassegna quattro casi che mostrano la stessa cosa da angolazioni diverse.

Attacco	Anno	Vettore	Perché bypassava i filtri
Slowloris	2009	Connessioni aperte con header incompleti, inviati a goccia	Bassissima banda, sembra un client mobile lento
Mēris	2021	Router MikroTik compromessi (CVE-2018-14847)	Richieste HTTP complete e valide, 21,8 milioni al secondo contro Yandex
HTTP/2 Rapid Reset	2023	Apertura e reset immediato di stream (RST_STREAM)	Ogni pacchetto è conforme al protocollo
HTTP/2 CONTINUATION Flood	2024	Frame CONTINUATION senza END_HEADERS	La richiesta non si completa mai, niente finisce nei log

Sul caso Rapid Reset (CVE-2023-44487), disclosure coordinata tra Google, Cloudflare e AWS, AWS ha riportato un picco di 155 milioni di rps, mentre Cloudflare ha registrato 205 milioni di rps, con Google che ha sostenuto un picco di 398 milioni di richieste al secondo. Un botnet relativamente piccolo, qualche decina di migliaia di nodi secondo le stime riportate dai tre fornitori, è bastato per superare ogni record precedente perché lo stream veniva cancellato prima di saturare il limite di connessioni concorrenti.

Il caso più scomodo resta il CONTINUATION Flood: non c'è client lento da segnalare, non c'è frame malformato da intercettare, non c'è una richiesta completata da sottoporre a rate limiting. La contromisura indicata è impostare un tetto al numero di frame CONTINUATION per stream e alla dimensione totale degli header, chiudendo la connessione oltre soglia.

Per chi amministra reverse proxy e CDN la lezione pratica è la stessa di sempre: timeout di connessione e di header, limiti per IP, e soprattutto una baseline di cosa sia "normale" per il proprio servizio, perché un picco di traffico onesto e un attacco applicativo possono crescere con la stessa pendenza.