Attacco DoS al Senato. Come proteggersi dai slow Http Attack

Redazione RHC : 16 Maggio 2022 06:43

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.

Cybersecurity Awareness per la tua azienda? Scopri BETTI RHC! Sei un'azienda innovativa, che crede nella diffusione di concetti attraverso metodi "non convenzionali"?  Red hot cyber ha sviluppato da diversi anni una Graphic Novel, l'unica nel suo genere nel mondo, che consente di formare i dipendenti sulla sicurezza informatica attraverso la lettura di un fumetto. Scopri di più sul corso a fumetti di Red Hot Cyber. Contattaci tramite WhatsApp al numero 375 593 1011 per richiedere ulteriori informazioni oppure alla casella di posta [email protected] Supporta Red Hot Cyber attraverso:  L'acquisto del fumetto sul Cybersecurity Awareness Ascoltando i nostri Podcast Seguendo RHC su WhatsApp Seguendo RHC su Telegram Scarica gratuitamente “Byte The Silence”, il fumetto sul Cyberbullismo di Red Hot Cyber Se ti piacciono le novità e gli articoli riportati su di Red Hot Cyber, iscriviti immediatamente alla newsletter settimanale per non perdere nessun articolo. La newsletter generalmente viene inviata ai nostri lettori ad inizio settimana, indicativamente di lunedì.

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.

Redazione
La redazione di Red Hot Cyber è composta da un insieme di persone fisiche e fonti anonime che collaborano attivamente fornendo informazioni in anteprima e news sulla sicurezza informatica e sull'informatica in generale.

Lista degli articoli