Ci si riferisce alla recente ondata di attacchi di tipo DDOS che ha investito, tra gli altri paesi, anche l’Italia a partire dallo scorso 11 maggio, nell’ultimo report di analisi e mitigazione dei rischi, pubblicato dal Computer Security Incident Response Team (CSIRT) italiano del Governo.
Un evento che ha dunque fatto salire ancora di più l’allerta cyber del nostro paese, coinvolgendo su larga scala anche i media, arrivando dunque fino all’interesse dell’opinione pubblica. Ciò che questi attacchi rivolti all’Italia hanno in comune con tutto lo sciame al quale stiamo assistendo da parte di gruppi pro Russia o pro Ucraina, è la tipologia. La metodica più largamente utilizzata, per portare avanti un’offensiva, in maniera relativamente facile (senza sofisticatezza tecnica), sembra infatti essere l’attacco DDOS.
Sempre l’attacco DDOS è dunque il responsabile che ha reso indisponibili per alcune ore l’11 maggio, i siti istituzionali italiani almeno di Senato, Ministero della Difesa, ACI e Istituto Superiore di Sanità.
Attacco cyber dalla Russia all’Italia: down siti Senato, Difesa, perché è evento grave
Indice degli argomenti
L’attacco DDOS utilizzato contro l’Italia
Nello specifico il CSIRT ha analizzato i retroscena di questi attacchi, identificando si sia trattato di attacchi Slow HTTP, una particolare tipologia di Denial of Service. Gli attacchi slow HTTP sono attacchi denial-of-service (DoS) in cui l’attaccante invia le richieste HTTP a pezzi lentamente, una alla volta a un server Web. La loro caratteristica di essere adoperare risorse minime da parte dell’attaccante, ne fa una tipologia di attacco semplice da mettere in atto, eseguibile appunto senza grandi investimenti infrastrutturali.
Questa facilità nell’esecuzione li rende estremamente diffusi nella maggior parte dei gruppi che si stanno “prestando alle armi” in questo periodo di incertezza geopolitica internazionali. La lentezza nell’invio delle richieste HTTP al server web preso di mira, fa sì che il server rimanga in ascolto, senza poter chiudere la connessione mantenendo perciò le risorse impegnate, finché non arrivano tutti i dati della richiesta. In base ai tempi di timeout impostati sul server, alla capienza della memoria che la macchina dedica ai processi del server web e al numero di connessioni simultanee supportate, un superamento di questi parametri, con questa metodica, genera un attacco: il risultato è che il server web non riesce più a ricevere richieste (neppure legittime, quindi non appositamente lente), rivelandosi dunque indisponibile, finché non cessa il flusso di richieste slow e i processi di elaborazione delle richiesta raggiungono nuovamente una situazione standard (regolarità di richieste-risposte).
Polizia di Stato, giù il sito: hacker filo-russi all’attacco dell’Italia
Azioni di mitigazione utili, generali e specifiche
Lo stesso bollettino CSIRT consiglia inoltre le azioni suggerite da Qualys (nota società di sicurezza informatica che almeno da una decina d’anni fornisce sicurezza cloud ad enti e aziende), come le buone pratiche da mettere in atto, al fine di proteggere la propria infrastruttura da attacchi di questa natura.
Qualys infatti raccomanda delle pratiche generali, che dovrebbero essere già note e applicate:
- Rifiutare connessioni con metodi HTTP non supportati dall’URL.
- Limitare l’intestazione e il corpo del messaggio a una lunghezza minima ragionevole. Imposta limiti specifici dell’URL più severi appropriati per ogni risorsa che accetta un corpo del messaggio.
- Impostare un timeout di connessione assoluto, se possibile. Ovviamente, se il timeout è troppo breve, si rischia di eliminare le connessioni lente legittime; e se è troppo lungo, non si filtrerà nessuna connessione, rinunciando quindi ad ogni protezione dagli attacchi. Bisognerebbe dunque tener conto di un valore di timeout, ad esempio leggermente maggiore della durata media delle connessioni.
- Il backlog di connessioni in sospeso consente al server di mantenere le connessioni che non è pronto ad accettare, e questo gli consente di resistere a un attacco slow HTTP più ampio, oltre a dare agli utenti legittimi la possibilità di essere serviti anche sotto carico elevato. Se il server supporta un backlog, è consigliato renderlo ragionevolmente grande in modo che il tuo server HTTP possa gestire un piccolo attacco.
- Definisci la velocità minima dei dati in entrata ed elimina le connessioni che sono più lente di quella velocità. Bisogna fare attenzione a non impostare il minimo troppo basso, o si rischia di far cadere, anche in questo caso, le connessioni legittime.
Per quanto riguarda invece le azioni da intraprendere in maniera specifica in base al server sul quale la nostra infrastruttura è basata, vengono sottolineati i casi che abbiamo riassunto nella seguente tabella:
| Apache | Nginx | Lighttpd | Internet Information Services (Microsoft) |
| 1) 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 queste direttive. Pertanto, utilizzare questi parametri insieme alle direttive LimitRequestFields, LimitRequestFieldSize, LimitRequestBody, LimitRequestLine, LimitXMLRequestBody. | 1) Personalizzare la variabile $request_method per limitare i metodi HTTP accettati. | 1) Limitare i metodi di richiesta utilizzando la direttiva $HTTP[“request-method”] nel file di configurazione. | 1) Si possono limitare gli attributi della richiesta tramite l’elemento <RequestLimits>, in particolare i valori di maxAllowedContentLength, maxQueryString e maxUrl. |
| 2) Il valore predefinito di 300 secondi per TimeOut e KeepAliveTimeOut è eccessivo per la maggior parte delle situazioni. Adattare valori più ragionevoli in base alle statistiche. | 2) Impostare con un valore ragionevolmente piccolo large_client_header_buffers, client_body_buffer_size, client_header_buffer_size e client_max_body_size. | 2) Utilizzare server.max_request-size per limitare la dimensione dell’intera richiesta, intestazioni incluse. | 2) Impostare l’elemento <headerLimits> per configurare il tipo e la dimensione dell’intestazione che il server web accetterà. |
| 3) Il valore di 511 per ListenBackLog dovrebbe essere aumentato, il che è utile quando il server non è in grado di accettare connessioni abbastanza veloci. | 3) Impostare client_body_timeout, client_header_timeout su valori ragionevolmente bassi. | 3) Impostare server.max-read-idle con un valore minimo ragionevolmente basso in modo che il server chiuda le connessioni lente. | 3) Ottimizzare gli attributi connectionTimeout, headerWaitTimeout e minBytesPerSecond degli elementi <limit> e <WebLimits> per ridurre al minimo l’impatto degli attacchi slow HTTP. |
| 4) Aumentare il valore di MaxRequestWorkers per consentire al server di gestire il numero massimo di connessioni simultanee. | 4) Considerare l’utilizzo di HttpLimitReqModule e HttpLimitZoneModule per limitare il numero di richieste o il numero di connessioni simultanee per una determinata sessione. | ||
| 5) Regolare AcceptFilter, che è supportata su FreeBSD e Linux, e abilita ottimizzazioni specifiche del sistema operativo per un socket di ascolto in base al tipo di protocollo. | 5) Configurare worker_processes e worker_connections in base a: numero di CPU/core, contenuto e carico. | ||
| 6) RequestReadTimeout del modulo mod_reqtimeout aiuta a controllare le connessioni lente impostando il timeout e la velocità dati minima per la ricezione delle richieste. |
Gli strumenti disponibili in aiuto per la protezione
Come appena specificato, queste sono azioni di mitigazione basilari, già note e considerate da tempo buone pratiche per una corretta sicurezza informatica di una infrastruttura (in questo caso specifico server web). Va detto infatti che tali azioni andrebbero accompagnate da una buona implementazione di altri livelli di protezione come il reverse-proxy. Installare infatti un server (proxy) che si trova di fronte a uno o più server Web, intercettando le richieste dei client. Viene definito reverse-proxy, proprio perché sta davanti al server Web e non al client come più spesso accade.
Come funziona un reverse-proxy
Questa struttura fa sì che le richieste provenienti dal client non giungano direttamente sul server Web, ma “atterrino” su questo altro server (il proxy) che avrà una sicurezza più stringente e più risorse per respingere un attacco informatico, come avviene nel CDN (Content Delivery Network). Una soluzione di questo tipo, nella maggioranza dei casi, risolve anche il problema (anch’esso da affrontare) del fornirsi di bilanciatori del carico software basati su eventi, bilanciatori del carico hardware per eseguire l’associazione ritardata e sistemi di rilevamento/prevenzione delle intrusioni per eliminare le connessioni con schemi sospetti.
Un reverse-proxy dunque, è un server che si trova di fronte ai server Web e inoltra le richieste dei client (ad es. browser Web) ai giusti server Web, dopo averle filtrate e se del caso, protette. Soluzioni di questo tipo, implementate dalle strutture strategiche, aumentano, insieme a tutte le altre buone pratiche presenti nell’ultimo bollettino CSIRT, la resilienza delle infrastrutture che vogliamo proteggere da attacchi DDoS e Slow HTTP.
