Denial of Service with Slowloris
The attack vector essentially works by initialising an HTTP request but never completes the request, causing the handling thread to wait for the end of the request. Slowloris uses multiple threads to rapidly exhaust the web servers available network resources. The attack is effective against several web server platforms, but most significant in terms of market share and install base is Apache 1.X and 2.X services.
The HTTP request currently generated by Slowloris is below, however before trying to use the info to create IDS signatures the packet contents could easily be modified to avoid overly specific signatures (and overally general signatures could generate high volume of false-positives)
GET / HTTP/1.1
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)
Highlighting the potential damage this technique could course, the Internet Storm Center has already posted two diaries discussing the attack since it’s release, the first introduces the tool and has some rudimentary low-level analysis of the attack vector. The second discusses potential mitigation techniques, unfortunately these are currently far from bulletproof at present.
Since it’s release I’ve tested the Slowloris script and, unfortunately, it’s been wholly effective everytime. Whilst the suggested mitigations can improve a web server’s resilience to the attack, as the point of the web-server is to provide services to the outside world it is near impossible to prevent a maliciuos attack of this nature without similarly impacting legitimate service provision. Unfortunately the maliciuos user has the up-hand in this battle, as the level of resources required to deny service is miniscule compared to the potential damage and resources required to avoid the threat.
Even against a server modified with some of the proposed mitigations, the attacker still only required a sustained traffic flow of appoximately 45Kbps, easily obtainable from even a single ADSL connection. This also means that the attack may be missed by some traditional techniques such as monitoring for unusual traffic levels. Especially as other servers on the server will be responsive, basically if you have issues with your web services I’d recommend checking current connections to the Apache service, for example:
#netstat -antp | grep :80
Best response I’ve found so far is re-active, basically get hit with the attack, find source IP and block at firewall (perimeter or host based), not ideal but, at least currently I haven’t seen this attack in the wild to justify modifying functional production servers to only mitigate against a potential attack when those modifications could deny legitimate services itself.
Life could be about to get interesting…
P.S. Twitter plug: whilst this attack vector could be significant, it was publically available 48hours before I noticed any reference in even information security focused mainstream media. However, I had a test environment demoing the script within 60 minutes of RSnake (@rsnake) publicising the link on Twitter.