Attacco DoS al Senato. Come proteggersi dai slow Http Attack

Molti si sono chiesti come mai l’infrastruttura IT del Senato abbia collassato con un attacco di denial of service (DoS). Non erano presenti sistemi Anti DDoS?

Come questo articolo cercheremo di fare chiarezza su cosa sono gli “slow HTTP Attack”, quale tool è stato utilizzato dal collettivo KillNet/Legion Russia per eseguire l’attacco e come proteggersi da queste insidiose minacce.

Il sistema utilizzato per l’attacco 

Gli attacchi effettuati da Killnet/Legion Russia, hanno utilizzato un tool, gratuitamente scaricabile online che si chiama Blood, che avevamo anticipato qualche articolo fa, proprio mentre l’attacco contro il Senato della repubblica italiana si stava consumando.

Blood risulta scaricabile in rete al suo indirizzo GitHub e consente diverse funzionalità di lavoro, sia a livello 4 del modello Osi (sui protocolli TCP/UDP), ma anche a livello 7, ovvero a livello applicativo, come si vede nelle istruzioni operative.

  [Layer 7]
 - cfb     | Bypass CF attack
 - pxcfb   | Bypass CF attack with proxy
 - cfpro   | Bypass CF UAM, CAPTCHA, BFM, etc,, with request
 - cfsoc   | Bypass CF UAM, CAPTCHA, BFM, etc,, with socket
 - pxsky   | Bypass Google Project Shield, Vshield, DDoS Guard Free, CF NoSec With Proxy
 - sky     | Sky method without proxy
 - get     | Get  Request Attack
 - post    | Post Request Attack
 - head    | Head Request Attack
 - soc     | Socket Attack
 - pxraw   | Proxy Request Attack
 - pxsoc   | Proxy Socket Attack
 -bypass   | Bypass Google Project Shield, Vshield
 -stellar  | HTTPS Sky method without proxies
- hulk     | Hulk DoS tool
- pxraw    | Proxy Request Attack
- pxslow   | Proxy Slowloris attack
 
  [Layer 4]
  -udp     | UDP Attack
  -tcp     | TCP Attack
  -mine    | Minecraft Dos attack 
  -vse     | Send Valve Source Engine Protocol
  
  [Tools]

 - .proxy  | Get VALID proxies into proxy.txt 
 - .proxies| Get ALL proxies into proxy.txt
 - dns     | Classic DNS Lookup
 - geoip   | Geo IP Address Lookup
 - Subnet  | Subnet IP Address Lookup
 Also u can take proxy from https://checkerproxy.net/getAllProxy (push on your data)

Per chiarezza, l’Open Systems Interconnection model (modello OSI) è un modello concettuale che descrive lo standard universale delle comunicazione di un sistema informatico, senza soffermarsi sulla tecnologia sottostante e alle suite di protocolli specifici.

Ma proprio a livello 7 Killnet e Legion Russia hanno operato, fornendo dei parametri a Blood, per generare quelli che vengono chiamati “slow http attack”.

Cos’è uno “slow Http Attack”

Gli attacchi “HTTP lenti” (in italiano), sono attacchi denial-of-service (DoS) dove l’attaccante invia le richieste HTTP a pezzi, molto lentamente, una alla volta ad un server Web. 

Se una richiesta HTTP non è completa, o se la velocità di trasferimento è molto bassa, il server mantiene le sue risorse occupate in attesa che arrivino il resto dei dati. 

Ma quando il pool di connessioni simultanee del server raggiunge il massimo delle allocazioni, il server collassa su se stesso generando un DoS. 

Gli attacchi HTTP lenti sono facili da eseguire perché richiedono risorse minime da parte dell’attaccante e questo fa comprendere come l'”asimmetria” tra chi attacca e chi difende le infrastrutture, sempre di più si sta acutizzando.

Come proteggersi dagli “slow HTTP Attack”

Per proteggere il tuo server Web da attacchi HTTP lenti, si consiglia quanto segue:

• Rifiutare/eliminare connessioni con metodi HTTP (verbi) non supportati dall’URL;
• Limitare l’intestazione e il corpo del messaggio a una lunghezza minima ragionevole. Imposta limiti specifici dell’URL più severi e appropriati per ogni risorsa;
• Impostare un timeout di connessione assoluto, qualora risulti possibile. Ovviamente, se il timeout è troppo breve, rischi di far cadere le connessioni legittime e se è troppo lungo, non ottieni alcuna protezione da questo genere di attacchi. Impostare un valore di timeout basato sulle statistiche sulla lunghezza della connessione, ad esempio un timeout leggermente maggiore della durata mediana delle connessioni dovrebbe soddisfare la maggior parte dei client legittimi;
• 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 HTTP lento più grande, oltre a dare agli utenti legittimi la possibilità di essere serviti sotto un carico di richieste elevato. Tuttavia, richieste non soddisfatte e quindi un backup di grandi dimensioni può prolungare anche l’attacco, poiché esegue il backlog di tutte le richieste di connessione indipendentemente dal fatto che siano legittime o meno;
• 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 le connessioni legittime:
• Seguire le ulteriori raccomandazioni specifiche del server.

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 queste direttive. 

Pertanto, utilizzare questi parametri insieme alle direttive 

• LimitRequestFields;
• LimitRequestFieldSize;
• LimitRequestBody;
• LimitRequestLine:
• LimitXMLRequestBody.

a seconda dei casi. 

Ad esempio, è improbabile che la tua app Web richieda un’intestazione di 8190 byte, pertanto sono necessarie delle prove per inserire il parametro più corretto alle esigenze del traffico del server web.

Impostate anche valori di direttiva TimeOut e KeepAliveTimeOut ragionevoli. Il valore predefinito di 300 secondi per TimeOut è eccessivo per la maggior parte delle situazioni.

Il valore predefinito di ListenBackLog di 511 potrebbe essere aumentato, il che è utile quando il server non è in grado di accettare connessioni abbastanza veloci.

Aumentate la direttiva MaxRequestWorkers per consentire al server di gestire il numero massimo di connessioni simultanee.

Regolate anche la direttiva AcceptFilter, che è supportata su FreeBSD e Linux, e abilitate le ottimizzazioni specifiche del sistema operativo per un socket di ascolto in base al tipo di protocollo. Ad esempio, il filtro httpready Accept memorizza nel buffer intere richieste HTTP a livello di kernel.

Sono disponibili numerosi moduli Apache per ridurre al minimo la minaccia di attacchi HTTP lenti. Ad esempio, la direttiva RequestReadTimeout di mod_reqtimeout aiuta a controllare le connessioni lente impostando il timeout e la velocità dati minima per la ricezione delle richieste.

Raccomandiamo anche di passare Apache2 nella modalità MPM evento sperimentale, ove disponibile. 

Questa modalità utilizza un thread dedicato per gestire i socket in ascolto e tutti i socket che si trovano in uno stato Keep Alive, il che significa che le connessioni incomplete utilizzano meno risorse durante il polling.

Nginx

Limita i verbi accettati controllando la variabile $request_method.

Imposta client_max_body_size con un valore ragionevolmente piccolo, client_body_buffer_size, client_header_buffer_size, large_client_header_buffers aumentatelo se necessario.

Impostate client_body_timeout, client_header_timeout su valori ragionevolmente bassi.

Prendete in considerazione l’utilizzo di HttpLimitReqModule e HttpLimitZoneModule per limitare il numero di richieste o il numero di connessioni simultanee per una determinata sessione o, in casi speciale, con lo stesso indirizzo.

Configurate worker_processes e worker_connections in base al numero di CPU/core, disponibili. La formula è

max_clients = worker_processes * worker_connections

IIS 6

Impostate le proprietà connectionTimeout, HeaderWaitTimeout e MaxConnections in Metabase per ridurre al minimo l’impatto degli attacchi HTTP lenti.

Lavorare con Metabase può essere complicato, quindi raccomandiamo Microsoft Working with the Metabase Reference Guide.

IIS 7

Limitare gli attributi della richiesta avviene tramite l’elemento <RequestLimits>, in particolare gli attributi maxAllowedContentLength, maxQueryString e maxUrl.

Impostate <headerLimits> per configurare il tipo e la dimensione dell’intestazione che il tuo server web accetterà.

Ottimizzate gli attributi connectionTimeout, headerWaitTimeout e minBytesPerSecond degli elementi <limits> e <WebLimits> per ridurre al minimo l’impatto degli attacchi HTTP lenti.

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.

Redazione

La Redazione di Red Hot Cyber fornisce aggiornamenti quotidiani su bug, data breach e minacce globali. Ogni contenuto è validato dalla nostra community di esperti come Pietro Melillo, Massimiliano Brolli, Sandro Sana, Olivia Terragni e Stefano Gazzella. Grazie alla sinergia con i nostri Partner leader nel settore (tra cui Accenture, CrowdStrike, Trend Micro e Fortinet), trasformiamo la complessità tecnica in consapevolezza collettiva, garantendo un'informazione accurata basata sull'analisi di fonti primarie e su una rigorosa peer-review tecnica.