L’importanza della lezione degli attacchi dell’11 maggio 2022: il report del CSIRT

Un attacco è per sempre. Effettivamente, potremmo dire che c’è stato un prima e un dopo rispetto all’11 maggio 2022, per una serie di circostanze e per una serie di questioni. Innanzitutto, perché eravamo a due mesi e mezzo dallo scoppio di una guerra, quella in Ucraina, che ci era stata annunciata come una guerra ibrida, dove le armi più importanti sarebbero state quelle cyber. Poi, perché attacchi DDoS a infrastrutture istituzionali – come potevano essere i portali web del Senato e del ministero della Difesa – avevano assunto per la prima volta una vasta dimensione pubblica. Insomma, la questione degli hacker (con molti elementi di un immaginario collettivo che effettivamente non corrispondevano alla realtà) entrava per la prima volta nei notiziari nazionalpopolari italiani. Tuttavia, per gli addetti ai lavori – che erano immuni all’effetto romanzato che stava circondando l’azione di Killnet di quelle ore – la data dell’11 maggio 2022 è stata importante anche per diffondere una maggiore sensibilizzazione (e un vero e proprio modus operandi) per quanto riguarda gli attacchi DDoS portati avanti da hacktivisti filo-russi.

LEGGI ANCHE > Le azioni di mitigazione dell’ACN per prevenire i problemi degli attacchi DDoS alle banche

Report CSIRT 11 maggio 2022, la data che ha rappresentato un punto di svolta

Non è un caso che, anche in occasione della recentissima campagna DDoS contro i servizi digitali di alcune banche italiane, tra le azioni di mitigazione generali, l’ACN ha suggerito di fare riferimento proprio al report del CSIRT dell’11 maggio 2022. Nel documento è stata identificata la tipologia di attacco DDoS che era stato portato avanti in quell’occasione, ricordando – in ogni caso – che non aveva intaccato l’integrità e la confidenzialità delle informazioni e dei sistemi colpiti. La tecnica utilizzata sia più di un anno fa, sia oggi è stata quella dello Slow HTTP.

Per difendersi da questa tipologia di attacco, l’ACN ha messo a disposizione una serie di azioni che chiede di implementare:

• rifiutare le connessioni con metodi HTTP non supportati dall’URL;

• limitare l’intestazione e il corpo del messaggio a una lunghezza minima ragionevole. Per URL specifici, impostare limiti più severi e appropriati per ogni risorsa che accetta un body del messaggio;

• impostare un timeout di connessione assoluto, ove possibile, utilizzando le statistiche di connessione (ad es. un timeout leggermente maggiore della durata media delle connessioni dovrebbe soddisfare la maggior parte dei client legittimi);

• utilizzare un backlog di connessioni in sospeso. Esso consente al server di mantenere le connessioni che non è pronto ad accettare, bloccando di conseguenza un attacco Slow HTTP più ampio, oltre a dare agli utenti legittimi la possibilità di essere serviti sotto carico elevato. Se il server supporta un backlog, si consiglia di renderlo ragionevolmente grande in modo che il proprio server web possa gestire un attacco di lieve entità;

• definire la velocità minima dei dati in entrata e bloccare le connessioni che sono più lente della velocità impostata. Si evidenzia di fare attenzione a non impostare il valore minimo troppo basso per non bloccare le connessioni legittime;

• attivare gli strumenti di protezione da questa tipologia di attacco disponibili tramite dispositivi di sicurezza quali Web Application Firewall e Next Generation Firewall L7.

Nonostante sia passato più di un anno da quegli attacchi che impressionarono – più per il contesto, lo ripetiamo, che per gli effetti avuti sulle infrastrutture digitali italiane -, c’è ancora molta strada da fare nella prevenzione degli attacchi DDoS, come certificano anche i numerosi soggetti che, tra ieri e oggi, hanno riscontrato delle problematiche per il corretto funzionamento dei loro servizi. Il messaggio che deve passare è che conviene sempre investire in sistemi di difesa e che non è mai più “economico” subire un attacco.