Slowloris is a denial-of-service (DoS) tool that targets web servers. We have some suggestions about mitigation techniques and workarounds to protect your server. However, use caution if you implement any of these suggestions because they will likely have some unintended side effects.

The Slowloris author's web page offers an excellent description of how the tool works:

Slowloris holds connections open by sending partial HTTP requests. It continues to send subsequent headers at regular intervals to keep the sockets from closing. In this way webservers can be quickly tied up. In particular, servers that have threading will tend to be vulnerable, by virtue of the fact that they attempt to limit the amount of threading they'll allow.

We've generated a few packet capture files that show Slowloris in action. The web server being targeted is an Apache 2 (172.16.65.5) installation, a normal web browser is connecting from 172.16.65.4 and the Slowloris tool is running on 172.16.65.2. During the attack, Apache became unresponsive after a few seconds but recovered quickly once the attack was stopped.

We know that Slowloris works, and SANS reports that some attackers are already using a similar tool to attack web servers. As an administrator, we have some ideas about how you can stop an attack. Our mitigations below only apply to a limited number of deployed servers--ones that have relatively low volume and serve (usually) a small number of clients.

Before going further, it's important to figure out what device is actually affected by Slowloris. Although your routers shouldn't be affected (wrong network layer), reverse proxies, web application firewalls, and web servers might be.

After you've determined what components are affected, you'll probably want to look for something like Apache's TimeOut directive on an affected device. By lowering the TimeOut directive, Apache will more quickly discard the partial HTTP requests the Slowloris tool is sending. This change (slightly) increases the amount of bandwidth an attacker needs to sustain a DoS attack on the web server.

In addition to lowering the timeout for connections, Slowloris needs to use a different (although not sequential) source port for each connection. This makes each connection appear "new" to the web server and the operating system that it is running on. Below are some iptables rules using the recent module that demonstrate this concept. The rules allow ten new connections from a given IP every fifteen seconds and drop additional packets from the sending host that is over that limit.

View the packet capture file to see how well our mitigations worked.

Although the results look good, it's important to note that the TimeOut directive doesn't help that much, and these iptables rules will trigger an unacceptable amount of false positives on busy servers receiving connections from proxies and NAT gateways. The workarounds listed above might be applicable on low-volume but critical web servers. They might also be useful for servers under attack when the option of serving pages to some clients is better than serving pages to none.

Thanks to Robert Hansen of SecTheory and Jason McCormick of the Software Engineering Institute for providing technical advice.