It’s been talked about a lot on mailing lists and forums. Recommendations are often made to use nginx, lighttpd, or varnish in front of your web servers to protect Apache but little is said about why Apache is vulnerable to slowloris.
The problem with Apache lies with its architecture.
For the purpose of this discussion consider the two most commonly used multi-process modules (MPM,) prefork and worker. Prefork is process-based and worker is thread-based. Both use blocking, or synchronous I/O, to handle requests. When a connection is initiated to TCP port 80 on an Apache server a process or thread is allocated to handle the request. While this thread or process is handling the request, no other requests will be completed. The MPMs use the concepts of ServerLimit and MaxClients to configure the number of simultaneous requests a server will handle.
How does this make Apache vulnerable to slowloris?
Slowloris works by sending an HTTP request to a server without completing the request. For example, here are the headers from an example request sent to the server hosting this site:
HTTP/1.1 200 OK
Date: Sun, 07 Nov 2010 10:16:58 GMT
Server: Apache
X-Pingback: http://www.linux-advocacy.org/xmlrpc.php
Connection: close
Content-Type: text/html; charset=UTF-8Slowloris will continue adding headers to keep the connection up as long as possible. Apache quickly reaches its configured connection limit and legitimate traffic is denied. Lowering the network timeout does little to mitigate the attack. Slowloris attempts to determine the timeout value of the target server and adjusts the interval at which it sends headers accordingly. Even with a very short timeout a slowloris attack requires few resources to achieve success.
Why is this unique to Apache?
Web servers such as lighttpd use asynchronous I/O. It uses native event handlers at the operating system level to process network and file I/O. A network socket and a small pool of resources is allocated for each slowloris connection. It is only when a complete HTTP request is received that is is processed by the web server process. While the server is receiving a large number of connections from slowloris, legitimate traffic continues to be served.
Protecting Against Slowloris
Several techniques exist to mitigate slowloris, each with varying success rates. Third party modules such as mod_antiloris and mod_dos_evasive can limit the number of requests per ip address. These modules can block valid traffic if not configured properly, especially if the site being protected serves mostly static content. Firewalls can also limit connections but be wary of state table exhaustion. Some load balancers can be configured to pass along only the complete requests to the server although this may be cost prohibitive for a single server installation. Standing up a proxy in front of Apache such as haproxy, varnish, or nginx can also provide some measure of protection.
It may be necessary to utilize several methods to effectively mitigate slowloris. As with all security measures, thorough testing should be conducted prior to implementing any configuration in a production environment.
