Cybersecurity best practices and DDoS defence strategies
What is a slow attack?
As with the majority of DDoS attacks, the intention is to overwhelm the server resources to prevent genuine users from accessing the network, but slow HTTP attacks do so not by sending high volume bursts of traffic to achieve this. Instead, they take a different approach by sending a small number of connections but keeping them open long enough to prevent the server from timing out until they exhaust the target server’s resources. This approach allows slow attacks to fly under the radar of traditional DDoS defence mechanisms based on volume thresholds since they do not cause a spike in traffic which can be restricted by rate limits.
Slow HTTP attacks don’t require many resources to accomplish, aside from patience. Attacks can be successfully launched using a single computer and minimal bandwidth usage. Unlike the more hard-hitting attacks, a slow HTTP attack doesn’t always require the use of a botnet making it more accessible to cybercriminals.
There are a number of examples of this approach, usually named after the hacking tools which use them. One common example is Slowloris which keeps HTTP requests open by continually sending partial HTTP headers, but never actually completing the request.
Another well-known example is RUDY (R U Dead Yet?) which creates HTTP POST connections with the server but avoids sending any POST data for as long as possible while sending the data at a very slow rate, thereby drawing out the connection and preventing the server from accepting new connections.
Nexusguard Slow Rate Policy
Slow HTTP attacks are denial-of-service (DoS) attacks in which the attacker sends HTTP requests piece by piece at a slow pace to a web server. If an HTTP request is not complete, or if the transfer rate is very low, the server keeps its resources busy waiting for the rest of the data. The server’s concurrent connection pool eventually reaches its maximum, creating a DoS.
To mitigate slow HTTP attacks, Nexusguard’s Application Protection (AP) is reinforced by the addition of a Slow Rate Policy, composed of the following three operation modes:
1. Off: Policy is disabled
2. Monitor: Policy monitors for slow HTTP attempts and logs the requests if detected, but no blocking takes place.
3. Block: Policy blocks slow HTTP requests when detected
Nexusguard’s highly customizable Slow Rate Policy is applicable to both the HTTP header and HTTP body. The slow header rule allows customization of the header time out as well as the maximum number of slow connections, while the slow body rule allows customization of the HTTP body transfer rate and the maximum number of slow connections, ensuring web servers are never clogged by the impact of slow HTTP attacks.
To learn more about Nexusguard’s Slow Rate Policy, please read about our Application Protection.
Nexusguard’s highly customizable Slow Rate Policy allows customization of HTTP header and body parameters so that slow HTTP attacks never fly under the radar.