Slowloris attack

What is a Slowloris attack?

Slowloris is a common name for an application-layer denial-of-service (DoS) cyberattack that targets thread-based web servers. The Slowloris attack works by using up the entire connection pool on the target web server. Another name for this type of attack is a slow HTTP DoS attack.

The name Slowloris comes from the name of a proof-of-concept attack tool originally created by Robert RSnake Hansen in 2009, while slow loris itself is the general name for a group of nocturnal primates from Southeast Asia that are known for moving extremely slowly. This attack technique has been used in many real-world attacks. For example, it was used by Iranian hacktivists to attack Iranian government sites after the 2009 presidential election.

How does a Slowloris DDoS attack happen?

There are two basic types of web server software, differing in the way they handle HTTP connections: thread-based servers (e.g. Apache, Microsoft IIS, dhttpd) and event-based servers (e.g. Nginx, lighttpd). Thread-based servers are designed to handle a smaller number of connections than event-based servers. For example, the default number of concurrent connections for an Apache installation is only 150, compared to 512 for Nginx.

A web server considers a connection open until it has received all the HTTP headers and the entire body for a request, or until the connection times out. The default timeout for an Apache connection is 300 seconds (for Nginx, it’s only 60 seconds). At default settings, this means an attacker only has to generate 150 open connections in Apache at roughly the same time to leave the server unable to accept any other legitimate requests for at least 5 minutes.

As a result, all it takes to perform a DoS attack against a thread-based web server with a default configuration and no additional protection modules is to initiate a sufficient number of incoming requests. If the requests (usually unfinished HTTP GET connections) arrive not from a single computer but from several sources, as with a botnet, this becomes a distributed denial-of-service (DDoS) attack.

What is a slow HTTP POST attack?

The slow HTTP POST DDoS/DoS attack is a variation of the Slowloris attack that uses POST rather than GET requests and is much harder to mitigate. In a slow HTTP POST attack, the attacker keeps all the malicious connections alive to prevent them from timing out:

• In a slow HTTP GET attack, the attacker doesn’t send any further data after opening an HTTP GET connection but simply waits for a timeout.
• In a slow HTTP POST attack, the attacker declares a large amount of data to be sent in each HTTP POST request and then sends it very slowly.

The slow HTTP POST attack and the tool used to conduct it are often called R U Dead Yet or the R.U.D.Y. attack, named after the original attack tool developed later.

How to detect Slowloris attacks?

A slow HTTP DoS attack may not be detected by intrusion detection systems (IDS) because it does not contain any malformed requests. Each HTTP request will seem legitimate to the IDS, even if it’s not closed.

The only effective way to spot a Slowloris attack is to monitor HTTP connection patterns to spot large numbers of connection attempts, long connection durations, unusually high numbers of partial HTTP requests, high server resource utilization, and other server anomalies related to bandwidth or capacity.

Note that while experimental checks were developed in the past to determine if a server is vulnerable to Slowloris attacks, the success of a real-life attack also depends on other factors, such as the server configuration and connection quality, making any checks unreliable and prone to false positives. Load testing is the only realistic way to find out if your web server can resist slow HTTP attacks, so this is not considered a typical web vulnerability but rather a configuration issue.

How to mitigate Slowloris attacks in the Apache HTTP server?

The Apache HTTP server is the most common target of slow HTTP DoS attacks. Listed below are three popular and easily implemented mitigations for slow HTTP DoS attacks (both Slowloris and R.U.D.Y.) against Apache servers. You can implement one or several of these methods and potentially combine them with other mitigation techniques, such as load balancers, reverse proxies, rate limiting, etc.

Also note that the Slowloris attack is an application-layer rather than network-layer type of DDoS attack. One example of network-layer attacks are SYN flood attacks, where an attacker sends malicious TCP SYN segments during a TCP three-way handshake. DDoS protection methods implemented at the network level to protect against such threats (commonly offered by cloud or DNS providers) are ineffective against slow HTTP DoS attacks.

Using the mod_reqtimeout module

Apache HTTP Server versions 2.2.15 and higher have a mod_reqtimeout module. You can use this to set timeouts for receiving the HTTP request header and body from a client. If a client fails to send header or body data within the configured time, the server replies with a 408 REQUEST TIMEOUT error.

Example configuration:

<IfModule mod_reqtimeout.c>  
  RequestReadTimeout header=20-40,MinRate=500 body=20-40,MinRate=500
</IfModule>

In this configuration:

• After opening the connection, the client has 20 seconds to start sending header data.
• The client must send header data at a transfer rate of at least 500 bytes per second.
• The client may send header data for a maximum of 40 seconds.
• The same values apply to the request body after the headers are sent.

Using the mod_qos module

The mod_qos module is a separate extension for the Apache HTTP Server, not included with the official Apache distribution. You can use it to assign different priorities to different HTTP requests.

Example configuration to protect against slow HTTP DoS:

<IfModule mod_qos.c>
  # maximum number of different client IP addresses
  QS_ClientEntries 100000
  # maximum number of connections per IP
  QS_SrvMaxConnPerIP 50
  # maximum number of active TCP connections
  MaxClients 256
  # number of occupied TCP connections to disable keep-alive
  QS_SrvMaxConnClose 180
  # minimum request/response speed
  QS_SrvMinDataRate 150 1200
</IfModule>

In this configuration:

• The module tracks up to 100,000 connections and limits requests to a maximum of 256 connections in total, with no more than 50 connections per IP.
• The module assumes that the maximum number of viable connections is 180. When this number is reached, the module disables HTTP Keep-Alive.
• The client must send information at a minimum data rate of 150 bytes per second per connection. If the maximum number of connections is reached (180), the required transfer rate increases up to 1200 bytes per second.

Using the mod_security module

The mod_security module is a separate web application firewall (WAF), not included with the official Apache distribution.

Example configuration to protect against slow HTTP DoS:

SecRule RESPONSE_STATUS "@streq 408" "phase:5,t:none,nolog,pass, 
  setvar:ip.slow_dos_counter=+1, expirevar:ip.slow_dos_counter=60, id:'1234123456'"
 
SecRule IP:SLOW_DOS_COUNTER "@gt 5" "phase:1,t:none,log,drop, 
  msg:'Client Connection Dropped due to high number of slow DoS alerts', id:'1234123457'"

In this configuration:

• The WAF records all cases when the Apache HTTP server responds with a 408 status code (for example, as a result of a mod_reqtimeout configuration).
• If the WAF records more than 5 such responses for one IP in 60 seconds, it drops all requests from that IP for the next 5 minutes.

Frequently asked questions

Written by: Tomasz Andrzej Nidecki, reviewed by: Benjamin Daniel Mussler