Denial of Service (DoS) are among the most common attacks on the web. There are many variants. One of them, which is particularly easy to exploit and inexpensive in terms of resources, deserves our attention: Slow HTTP attacks.
In this article, we will explain how a Slow HTTP attack works. We will also look at the main types of attack and the security best practices to prevent them.
How Does a Connection Pool Work?
To understand Slow HTTP, we first need to explain how a web server connection pool works.
When it is initialised, a threaded web server creates a pool of connections. Each connection remains inactive until a user, called a client, opens one via HTTP. At that point, a thread is assigned to the client to manage the data exchange. The connection remains active until one of three situations occurs: the client completes its operation, closes the connection or the connection expires for lack of activity.
The number of threads available is limited and depends on the number of cores in the server processor. It is possible to assign several threads per core, but this can slow down connections.
How a Slow HTTP Attack Works?
A server can only accept a limited number of simultaneous connections. Once this threshold is reached, it can no longer accept new connections, making it unavailable. This is precisely the objective of a Slow HTTP attack.
The idea is to occupy the connection pool for as long as possible. A classic approach is to generate a large number of connections to saturate the server, as in a classic DoS attack. However, there are more subtle and less resource-intensive methods: Slow HTTP attacks.
All Slow HTTP attacks are based on the same principle: establish a connection with the server and keep it open by sending or receiving data very slowly, without triggering a timeout.
In the following examples, we will see how to reproduce these attacks using the slowhttptest tool.
NB: Testing these attacks on unauthorised servers is illegal. Even if you have or have obtained the owner’s permission, be careful. Certain third-party services (reverse proxy, load balancer, hosting provider, etc.) may be affected and prohibit this type of test.
What are the Main Types of Slow HTTP attacks?
Slowloris HTTP attack
The simplest example involves a GET request. Its structure is as follows:
GET /index.php HTTP/1.1[CRLF]
Pragma: no-cache[CRLF]
Cache-Control: no-cache[CRLF]
Host: target.com[CRLF]
Connection: Keep-alive[CRLF]
Accept-Encoding: gzip,deflate[CRLF]
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:134.0) Gecko/20100101 Firefox/134.0 [CRLF]
Accept: */*[CRLF][CRLF]CRLF (Carriage Return Line Feed) tags indicate carriage returns. A GET request is considered complete when the server receives two consecutive [CRLF], indicating an empty line.
The attack is based on two principles:
- Slow down the sending of headers: As long as the connection remains active, the data is sent very slowly. For example, if the server drops the connection after 5 seconds of inactivity, one character is sent every 4.5 seconds.
- Never terminate the request: To prevent the server from processing the request, never send the final double [CRLF]. Instead, you continue to add dummy headers ad infinitum. Since the HTTP specifications allow unknown headers, all you have to do is invent new ones.
This attack, known as Slowloris, was popularised by the script of the same name, written by Robert ‘RSnake’ Hansen. Its name refers to the Slow Loris, a South-East Asian primate with a particularly slow metabolism.
The command for this attack is as follows:
slowhttptest -c 1000 -H -g -o my_header_stats -i 10 -r 200 -t GET -u https://target.com/index.php -x 24 -p 3R.U.D.Y attack
The R.U.D.Y (aRe-You-Dead-Yet) attack is based on the same principle as Slowloris, but this time targeting POST requests.
The attacker announces the sending of a large volume of data, as when submitting a form. It then transmits this data extremely slowly, bit by bit, while respecting the time limits to prevent the server from closing the connection by timeout.
The command for this attack is as follows:
slowhttptest -c 1000 -B -g -o my_body_stats -i 110 -r 200 -s 8192 -t FAKEVERB -u https://target.com/index.php -x 10 -p 3Slow read attack
Here, the attacker sends a valid request to which the server responds normally.
The attack takes place when the response is read: the client retrieves the data extremely slowly, sometimes one bit at a time. This technique is particularly effective against endpoints that return large volumes of data.
slowhttptest -c 1000 -X -r 1000 -w 10 -y 20 -n 5 -z 32 -u http://target.com/index.php -p 5 -l 350How to Prevent Slow HTTP Attacks?
The main challenge with Slow HTTP attacks, from a defensive point of view, is that they look like legitimate traffic. Distinguishing between a deliberately slow request and a slow connection due to a network problem can be complex.
Solutions therefore need to strike a balance between security and user experience. For example, imposing a strict 2 second delay to complete a connection considerably reduces the risk of attack, but may penalise users with a slow connection or poorly performing hardware.
It’s a balancing act. We need to analyse usage data and take account of user feedback to constantly adjust the parameters and guarantee both security and accessibility.
Limit the maximum number of connections per IP
This solution is very effective: if a client can only open a few connections, Slow HTTP attacks become impossible.
However, care must be taken. An overly strict restriction can penalise certain users, particularly those connected via a corporate VPN, where several people share the same IP address.
Reduce the maximum duration of a request
It simply involves cutting off connections that are not completed after a certain time.
This method is very effective, but must be applied with care. A limit that is too strict can affect the user experience, especially if the application has endpoints that generate large amounts of data or take a long time to respond.
Implement rate limiting
This involves limiting the speed at which connections are opened, rather than their total number per IP. For example, by prohibiting a client from opening more than 5 connections per second, Slow HTTP attacks become virtually impossible (in addition to the other measures). However, you need to remain vigilant: make sure that this does not block business needs that require several connections to be opened quickly.
Rate limiting is a best practice to adopt to protect your platform against various attacks, particularly brute force attacks.
It is important to note that these options are generally included in technologies for proxying, reverse proxying, load balancing and other similar services. However, this is not always the case, so check that they are available in your solution.
Conclusion
Slow HTTP attacks are effective, simple and inexpensive. They are often difficult to detect before it’s too late and can be devastating, rendering targeted services completely inaccessible.
Fortunately, protecting yourself against these attacks is relatively simple. All you need to do is configure certain server options correctly, which should already be done to ensure optimum management of the resources allocated.
Author: Renaud CAYOL – Pentester @Vaadata