Al giorno d’oggi l’attacco DDOS (Distributed Denial of Service) è uno dei maggiori problemi con cui le organizzazioni si scontrano.
E’ una tipologia di attacco molto difficile da affrontare, sia da parte delle  grandi aziende che da società con  un’infrastruttura ridotta.

La difficoltà maggiore che si riscontra quando si ha a che fare con un DDOS, è l’impossibilità da parte dei normali firewall a svolgere bene la loro funzione di filtro di protezione. La ragione di ciò sta nel fatto che il più delle volte le macchine coinvolte nell’attacco sono molte e provengono da aree geografiche diverse.

Quindi si tratta di un attacco multiplo e proveniente da diverse parti.

Il punto fondamentale è che il tipo di richiesta utilizzato per abbattere un servizio pare legittimo, ed è la grande quantità di richieste che manda in tilt il sistema. E’ qui che risiede la perfidia del DDOS!

Nel 2009 è stato rivelato dalla RSnake, uno strumento di attacco che ebbe largo successo nei forum e blog di settore. Questa tipologia di strumento non richiedeva larghezza di banda per lanciare l’attacco in quanto colpiva esclusivamente l’HTTP senza influire sugli altri servizi in esecuzione sul server.

Il nome attribuito a questo “tool” gli calza decisamente a pennello: “SLOWLORIS“, in quanto può portare in down un web server lentamente, consumandone tutte le connessioni.

Gli strumenti e metodi di un tradizionale attacco DDOS consumano le risorse del sistema aprendo troppe connessioni TCP e UDP al server.

Tuttavia Slowloris non è uno strumento di attacco TCP DOS, ma un http DOS .

Slowloris funziona effettuando parziali connessioni http all’host (la connessione TCP da parte di Slowloris durante l’attacco è una connessione TCP legittima), cercando di tenere costantemente attiva una sessione http, per un lungo periodo di tempo.

E’ risaputo che web server come Apache, lavorando su più thread, fa si che il server non sarà più disponibile per le nuove richieste quando le risorse si esauriranno, saturando il numero massimo di connessioni disponibili.

Quali sono i web server affetti da Slowloris?

  1. Apache (1.x & 2.x)
  2. Dhttpd
  3. Goahead web server

Web server basati su architetture come nginx non sono colpiti da Slowloris e questo sembra valere anche per IIS.

Come funziona un attacco Slowloris http DOS?

 

Una profonda conoscenza dei meccanismi di richiesta e risposta dell’http è fondamentale per comprendere questo strumento di attacco.

Apache e qualche altro server Web hanno un meccanismo di timeout. Un web server con Apache sfrutta questo timeout per completare una richiesta (se questa è incompleta).

Questo timeout di default ha una durata di 300 secondi, che può essere modificata, ed è molto utile se un sito ospita file pesanti o di grandi dimensioni attraverso http (perché mantiene una connessione http attiva di un cliente lenta senza interrompere il download).

Un altro aspetto da conoscere è che il “timer”  azzera il timeout ogni volta che il client invia un po’ di dati.

Provate ora ad immaginare la situazione in cui qualcuno volutamente mandi richieste http parziali azzerando il  timeout counter, inviando spesso dati incongruenti.

Una volta che tutte le connessioni sono esaurite dall’invio continuo di richieste parziali, Slowloris continua a mantenere la connessione attiva inviando richieste di dati e resettando il contatore timeout.

Riportiamo un esempio di richiesta GET completa:

1

Cosa sono le CRLF presenti nella richiesta sopra?

CRLF sta per CR (Carriage Return) e LF (Line Feed). Questo è un carattere non stampabile, utilizzato per indicare la fine della linea.

Ad esempio quando si scrive un normale file di testo CRFL viene posto alla fine di una riga quando si desidera andare a capo e iniziare una riga nuova.

Due caratteri CRLF messi insieme vengono utilizzati per indicare una riga vuota.

Nella richiesta GET mostrata sopra, ci sono due caratteri CRLF alla fine dell’intestazione “connessione” (che significa riga vuota). Nel protocollo HTTP, una riga vuota dopo l’header viene utilizzata per rappresentare il completamento dell’intestazione.

Slowloris sfrutta questa situazione nel suo attacco: non invia una riga vuota che indica la fine dell’intestazione http.

Alcuni web server danno priorità a questo tipo di richieste che sono complete nell’header, questo è il motivo per cui IIS non è influenzato da un attacco Slowloris.

Una richiesta incompleta inviata dallo script di Slowloris è quella che vedete sotto:

“GET /$rand HTTP/1.1\r\n”

. “Host: $sendhost\r\n”

. “User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n”

. “Content-Length: 42\r\n”;

In questo frammento di codice \ r \ n è usato per indicare il ritorno a capo e nuova riga in perl. Due consecutivi “\ r \ n \ r \ n”, dovrebbero indicare una riga vuota, che non c’è. Quindi questo è un header incompleto in HTTP.

Ecco come lo script perl di Slowloris agisce

Slowloris non è in grado di essere notato da IDS (sistema di rilevazione delle intrusioni), perché invia una richiesta valida al server web, quindi viene ignorato dal sistema IDS.

Ricordatevi che il principio di funzionamento di Slowloris è di consumare tutte le connessioni http disponibili sul server. Quindi se un sito web è ad alto traffico ci vorrà tempo perché Slowloris agisca, poiché bisognerà attendere che le connessioni HTTP  ritornino disponibili (perché altri client  sono serviti).

Un carattere particolare di Slowloris è che, nel momento in cui l’hacker blocca l’esecuzione dello script il sito torna nuovamente online, poiché le connessioni verranno automaticamente chiuse dopo l’intervallo di timeout.

Come prevenire e proteggersi da un attacco di Slowloris

1.Utilizzate un Hardware Load Balancer che accetti solo connessioni http complete.

Utilizzare un hardware load balancer con un profilo http configurato è il modo migliore per bloccare un attacco, questo perché il Load Balancer controlla il pacchetto ed inoltra al server web solo le richieste http complete.

Se si utilizza un BIG-IP Load Balancer basato su F5 vi consigliamo la lettura al link https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10260.html

Altri bilanciatori di carico, che riportiamo, possono essere utilizzati con il profilo http per mitigare un attacco:

– Citrix NetScaler

– Cisco CSS

2. Proteggete il vostro server web utilizzando IPtables limitando le connessioni da un host particolare.

Si può limitare il numero di connessioni con l’aiuto di iptables alla porta 80.

3. Configurare la direttiva timeout in Apache

Anche se questa non è affatto una buona soluzione, è ancora possibile aumentare la velocità con cui il vostro server web raccoglierà le connessioni inattive.

Si può semplicemente modificare la direttiva timout nel file di /etc/httpd/conf/httpd.conf.

Riducendolo ad un valore più basso renderà difficile l’attacco (anche se l’attacco può prendere il server, aumentando il numero di richieste).

Questa dunque non è propriamente una buona soluzione.

4. Modulo Apache mod_antiloris

Un’altra buona soluzione è un modulo di Apache chiamato come mod_antiloris. Questo modulo può essere installato utilizzando la procedura seguente:

[root@localhost ~]# wget http://sourceforge.net/projects/mod-antiloris/files/mod_antiloris-0.4.tar.bz2/download

[root@localhost ~]# tar -xvjf mod_antiloris-0.4.tar.bz2

mod_antiloris-0.4/

mod_antiloris-0.4/ChangeLog

mod_antiloris-0.4/mod_antiloris.c

[root@localhost ~]# cd mod_antiloris-0.4

[root@localhost mod_antiloris-0.4]# apxs -a -i -c mod_antiloris.c