Italia, continuano gli attacchi DDoS. Si sveglia il CSIRT: ecco cosa fare.

Tempo di lettura: 4 minuti.

Il sito della Polizia italiana risulta essere ancora offline dopo l’attacco DDoS di KillNet. Dopo un giorno di pathos nel mondo della cybersecurity il Computer Security Incident Response Team – Italia ha emanato un avviso dove mette in guardia dagli attacchi DDoS.

Anonymous attacca Killnet e vendica l’Italia: buttato giù il sito della Polizia di Mosca

KillNet ed il suo battaglione Legion ostile alla NATO. Intervista esclusiva agli hacker russi che hanno colpito l’Italia

Fa riflettere molto il fatto che la Russia non si sia mossa dagli attacchi hacker subiti dal collettivo Anonymous mentre, ancora una volta, un paese dell’Occidente emette avvisi per mettere in guardia dagli attacchi provenienti dall’ex regione sovietica.

“A seguito degli attacchi DDoS ai danni di soggetti nazionali e internazionali avvenuti a partire dall’11 maggio 2022, lo CSIRT ha intensificato il monitoraggio specifico della minaccia identificando attività di “probing” delle misure di protezione attive all’interno della constituency nazionale.

Tali attività, che al momento risultano di bassa intensità e che avrebbero avuto inizio almeno dalla data del 12 maggio u.s., potrebbero preludere a successive azioni di attacco DDoS con impatto sulla disponibilità dei servizi vittima.

In particolare le suddette attività sarebbero contraddistinte da:

• presenza di picchi di traffico UDP e TCP anomalo (in ogni caso superiore alla normale baseline di utilizzo delle risorse interessate);
• presenza di chiamate HTTP malformate (versione HTTP non valida, assenza del carattere CRLF);
• presenza di volumi anomali di chiamate provenienti da indirizzi IP appartenenti a servizi di anonimizzazione (rete Tor, proxy anonimi);
• presenza di chiamate riconducibili ad attacchi di tipo ICMP flood, SYN flood e TCP RST.

Azioni consigliate

In relazione a quanto rilevato, si raccomanda di innalzare il livello di monitoraggio delle anomalie nei servizi erogati della propria organizzazione in particolare se esposti su Internet e di attuare, oltre alle indicazioni già pubblicate da questo CSIRT, tutte le misure di prevenzione e mitigazione contro le principali tipologie di attacchi DDoS volumetrici (es. utilizzo di CDN, diversione del traffico), di frammentazione (es. packet/HTTP reconstruction), ad esaurimento di stato TCP e applicativo (es. hardening degli application server, utilizzo di Intelligent DDoS Mitigation System)“.

Casa fare per mitigare o eludere gli attacchi DDoS?

Azioni di mitigazione generali

Fermo restando l’opportunità di dotarsi di opportuni sistemi di protezione contro attacchi DDOS di tipo volumetrico, al fine di proteggere i propri sistemi da attacchi applicativi di tipo “Slow HTTP”, si consiglia di applicare le seguenti azioni di mitigazione:

• 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.

Azioni di mitigazione specifiche per prodotti

Di seguito si riportano le principali misure da adottare per prevenire e mitigare attacchi Slow HTTP ai danni dei principali web server al momento in utilizzo:

Apache

• l’uso delle direttive Limit e LimitExcept per eliminare le richieste con metodi non supportati dall’URL da solo non aiuta, perché Apache attende il completamento dell’intera richiesta prima di applicare tali direttive. Pertanto, utilizzare questi parametri insieme alle direttive LimitRequestFields, LimitRequestFieldSize, LimitRequestBody, LimitRequestLine, LimitXMLRequestBody a seconda dei casi. Ad esempio, è improbabile che l’app Web richieda un’intestazione di 8190 byte, una dimensione corporea illimitata o 100 intestazioni per richiesta, come la maggior parte delle configurazioni predefinite;
• impostare valori per le direttive TimeOut e KeepAliveTimeOut ragionevoli (ad es. il valore predefinito di 300 secondi per TimeOut è eccessivo per la maggior parte delle situazioni);
• aumentare il valore predefinito della direttiva ListenBackLog, utile quando il server non è in grado di accettare connessioni abbastanza veloci;
• aumentare la direttiva MaxRequestWorkers per consentire al server di gestire il numero massimo di connessioni simultanee;
• regolare la direttiva AcceptFilter, che è supportata su FreeBSD e Linux, e abilitare le ottimizzazioni specifiche del sistema operativo per un socket di ascolto in base al tipo di protocollo (ad es. il filtro httpready Accept memorizza nel buffer intere richieste HTTP a livello di kernel);
• prendere in considerazione l’utilizzo di moduli quali mod_reqtimeout per controllare aspetti quali timeout e minimum data rate per le richieste ricevute.

Nginx

• limitare i metodi accettati controllando la variabile $request_method;
• impostare in modo appropriato i parametri client_max_body_size, client_body_buffer_size, client_header_buffer_size, large_client_header_buffers;
• impostare i parametri client_body_timeout, client_header_timeout su valori ragionevolmente bassi.
• prendere in considerazione l’utilizzo di HttpLimitReqModule e HttpLimitZoneModule per limitare il numero di richieste o il numero di connessioni simultanee per una determinata sessione;
• configurare i worker_processes e worker_connections in base al numero di CPU/core, contenuto e carico. La formula da utilizzare è max_clients = worker_processes * worker_connections.

lighttpd

• limitare i metodi di richiesta utilizzando il campo $HTTP[“request-method”] nel file di configurazione per il modulo principale (disponibile dalla versione 1.4.19);
• usare il parametro server.max_request-size per limitare la dimensione dell’intera richiesta, incluse le intestazioni;
• impostare il parametro server.max-read-idle su un valore minimo ragionevole in modo che il server chiuda le connessioni lente.

IIS

• limitare gli attributi della richiesta attraverso l’utilizzo dell’elemento <RequestLimits>, in particolare gli attributi maxAllowedContentLength, maxQueryString e maxUrl;
• impostare l’elemento <headerLimits> per configurare il tipo e la dimensione dell’intestazione che il proprio server web può accettare;
• ottimizzare gli attributi connectionTimeout, headerWaitTimeout e minBytesPerSecond degli elementi <limits> e <WebLimits> per ridurre al minimo l’impatto degli attacchi Slow HTTP.