Se c'è qualcuno che continua a stupirmi per la genialità, la competenza e la capacità di rendere reale ciò che attraversa gli strani percorsi della sua mente, quello è rsnake. Slowloris non è una scimmia come il nome può dare a pensare, ma un modo diverso di applicare un Denial of service.

Robert (snake) Hansen - Slowloris -> ha.ckers.org

(la traduzione è abbastanza libera, rispettando il concetto, segnalate eventuali errori di traduzione o concetti poco chiari)

In un articolo precedente ho parlato di come un Denial of service può essere usato per l'hacking e non solamente come gli altri script kiddy tool.
Un mese fa stavo riflettendo su un articolo di Jack Louis riguardante il sockstress tcp e ho capito che erano possibili altri attacchi indipendenti low bandwidth.
Dopodichè ho pensato a come funzionava Apache e mi sono immaginato che fosse possibile realizzare qualcosa di simile al SYN flood, ma in HTTP.
E' così che è nato Slowloris.
Alla base vi è il concetto di mantenere in vita una sessione http infinitamente o il più a lungo possibile e ripetere questo processo qualche centinaio di volte.
Così nei miei test, contro un Apache Server non protetto e solo, potete aspettarvi di riuscire a metterlo offline mediamente in poche migliaia di pacchetti o meno, per farlo ritornare in linea non appena uccidete il processo.
Slowloris ha anche possibilità di stealth, compreso un metodo per bypassare la protezione HTTPReady.

Perche è degno di attenzione?
I tipici attacchi di flooding richiedono tonnellate di pacchetti e finiscono con il risultato di negare il servizio ad altre applicazioni.
Creando un flood di richieste TCP certamente potete buttar giù un router o un web server, ma se la vostra attenzione è rivolta a un sito web, è più distruttivo di quanto necessario.
Slowloris fa questo senza trasmettere una sovrabbondanza di traffico HTTP o TCP, e lo fa senza aumentare il carico significativamente, o in qualunque altro modo dannoso.
(dando per scontato altre cose non legate ai processi HTTP - come un database per esempio).
Ciò sembra interessare soltanto determinati tipi di web server (generalmente quelli che usano thread, come Apache, ma non come IIS).
------------------------------------------------------------------
Da wikipedia (http://it.wikipedia.org/wiki/Processo_(informatica))
Il concetto di processo è associato a quello di thread (abbreviazione di thread of execution, filo dell'esecuzione), con cui si intende l'unità granulare in cui un processo può essere suddiviso, e che può essere eseguito in parallelo ad altri thread.
---------------------------------------------------------------------------------------------------------

Così ho contattato Apache una settimana fa, perché ero poco un interessato al fatto di non aver sentito molto, in giro, circa questo, tranne una conversazione con HD Moore circa un simile attacco che ha trovato usando un payload differente.
Mi aspettavo una risposta bonaria, visto chi stavo interpellando e lo snippet di codice che fornivo.
Ho previsto un pensiero buono con la risposta, data la loro dominanza e nel fatto che dessi loro una copia in anticipo del codice....

"DoS attacks by tying up TCP connections are expected." Please see:
http://httpd.apache.org/docs/trunk/misc/security_tips.html#dos

Regards, Joe"

...proprio così,...questa la risposta...
L'RTFM (Read The Fucking Manual) è una risposta perfettamente lecita in Internet ma è anche estremamente miope, perché quasi nessun server è configurato correttamente, o se lo sono, it’s as a side effect of needing load balancing or something upstream that happens to protect them.
Inoltre, se leggete quella pagina di Apache.org, in verità non riguarda affatto questo attacco.
E Joe, o ha perso l'orientamento o ha commesso qualche errore nel voler scrivere brevemente, perché questo non è un DOS TCP, è un DOS HTTP.
Se il vostro server usa UDP e io riscrivo Slowloris per comunicare in UDP potrebbe funzionare ugualmente.
Il migliore esempio di come questo differisce da un DOS TCP è il fatto che altri servizi indipendenti sono inalterati e voi potete ancora collegarvi a loro normalmente.
Il motivo per cui funziona è che il web server attenderà pazientemente bene oltre il ragionevole, permettendo che un attaccante consumi tutti i thread disponibili di cui ce n'è una quantità limitata.
Questo genera un problema al server, non al sistema operativo o alla rete che potrebbero invece essere la soluzione alla configurazione di default di Apache.
Questo è maggiormente evidenziato dal fatto che IIS non è vulnerabile a Slowloris, almeno nel suo stato attuale.
Anche quando Apache e IIS si trovano sulla stessa macchina fisicamente, Apache rimane vulnerabile, IIS no.
Questo mi porta a pensare che sia un difetto nell'architettura di default del web server Apache.
Ad essere onesti questo non è solamente un problema di Apache. Anche altri web server sono vulnerabili, solo che nessuno ha la "fetta di mercato" di Apache. (maggiori info alla pagina dedicata a Slowloris http://ha.ckers.org/slowloris/ ).
Ad ogni modo, spero che questo serva perchè la gente configuri al meglio il proprio web server.
Ed è così se questo è un comportamento "previsto" del server, ed offre una configurazione di default che può proteggere da questa tipologia d'attacco, invece di dovere saltare tra complicazioni.

Vi invito a provare il tool e a vedere come si comporta il vostro web server.
Il software è molto beta comunque, in modo da non permettere l'utilizzo contro qualche macchina di produzione. Non do garanzie circa la possibilità di fare qualche cosa fuori da un ambiente di laboratorio!

PRINCIPI DI FUNZIONAMENTO E FEATURES DI SLOWLORIS
Benvenuti in Slowloris, il "low bandwidth Http client" avido e velenoso.
Scritto da RSnake con l'aiuto di John Kinsella, e un poco di ispirazione di Robert E Lee.

UPDATE: Amit Klein mi ha linkato un post scritto da Adrian Ilarion Ciobanu scritto all'inizio del 2007 che descrive perfettamente questo attacco denial of service. E' stato anche descritto nel 2005 nel "Programming Model Attacks" sezione di Apache Security. Così benchè allora non fosse stato rilasciato nessun tool questi due meritano tecnicamente tutto il merito. Mi dispiace di non averli menzionati.
(n.d.r. Robert scrive questo dopo aver ricevuto molte critiche sull'effettiva attribuzione di questo paper; lui sostiene sia comunque il primo ad aver rilasciato un tool e ad aver messo in pratica tutte le teorie di quei paper. Adrian, contrariamente agli altri che non centravano nulla, non se l'è presa ed è intervenuto nei commenti alla fine dell'articolo trattato prima).
Considerando le ramificazioni di uno slow dos verso particolari servizi, invece di floddare le reti, emerge il concetto che è permesso ad una singola macchina di tirare giù altre macchine web server con minimi effetti sulla banda e sui servizi e porte indipendenti.
La situazione ideale per molti attacchi dos è dove tutti gli altri servizi rimangono intatti ma il webserver di per se è completamente inaccessibile. Slowloris è nato da questo concetto, ed è relativamente molto "nascosto" in confronto alla maggior parte dei tools esistenti.
Slowloris tiene aperto le connessioni inviando richieste HTTP parziali. Continua ad inviare headers susseguenti ad intervalli regolari per preservare dalla chiusura la connessione socket. In questo modo ci si può "legare" ai webservers velocemente.
In particolare, i server che hanno il "threading" tenderanno a essere vulnerabili, in virtù del fatto che essi tentano di limitare la quantità "threading" permessi.
Slowloris deve attendere che tutti i socket diventino disponibili prima di "consumarli" con successo, cosicché se è un website con alto traffico potrebbe volerci un momento al sito per liberare i socket.
Così potreste non essere in grado di vedere il sito dal vostro punto, mentre gli altri potrebbero vederlo fino a quando non vengano liberati i socket di cui si impossesserà Slowloris.
Questo perché altri utenti del sistema devono finire le loro richieste prima che i socket diventino disponibili da consumarsi per Slowloris.
Se altri rifanno partire i loro collegamenti in quel breve periodo di tempo essi saranno in grado ancora di vedere il sito.
E' un po' una situazione da gara, ma Slowloris vincerà sempre alla fine,... e più prima che poi.
Slowloris ha anche alcune caratteristiche nascoste incorporate.
In primo luogo, può essere modificato per trasmettere diverse intestazioni host, se il vostro obiettivo è un virtual host e i logs vengono salvati per ogni host.
Ma meglio ancora, mentre l'attacco è in corso, i logs non verranno scritti finchè non sarà terminata la richiesta; così potete mantenere giù un server per minuti senza che nessuno possa rendersi conto di quello che succede.
Naturalmente quando fermerete l'attacco o una volta terminata la sessione il file dei logs conterrà diverse centinaia di errori tipo 400.
Questo è inevitabile per com'è Slowloris oggi, anche se può essere possibile trasformarli in 200 messaggi ok, completando una richiesta valida, ma Slowloris tuttavia non lo fa.
HTTPReady è cresciuto rapidamente come soluzione possibile ad un attacco di Slowloris, perché non consente al server di lanciare nulla finchè non si è conclusa la richiesta.
Questo è vero solo per richieste HEAD e GET. Finchè darete a Slowloris la possibilità di switchare le richieste in POST l'uso di HTTPReady risulta essere una difesa inutile contro questo tipo di attacco.
Questo non è un DOS di TCP, perché quella che sta realmente attuando è una richiesta completa TCP, non parziale, anche se sta facendo richieste HTTP parziali.
E' l'equivalente di un SYN flood ma applicato all'http.
Un esempio della differenza è che se ci sono due web server che girano sulla stessa macchina, uno può essere dossato senza interessare l'altro web server.
Slowloris inoltre potrebbe funzionare teoricamente anche su altri protocolli come l'UDP, basterebbe modificare un po' il programma e che il server supportasse questa connessione.
Slowloris non è un flooder di GET request, solamente attua alcune centinaia di richieste ad intervalli regolari e a lungo termine, contrariamente alle decine di migliaia e continue di un flood.

Riferimenti
http://hackinthebox.org/
http://ha.ckers.org/blog/
http://ha.ckers.org/slowloris/