How slow HTTP can knock down a server

Slow HTTP are application layer Denial Of Service (DoS) attack and has the potential to knock down a server with limited resources. Because of the nature of the attack (slow speed and low volume), they are hard to detect and can cause equal damage as a high-volume DDoS. In this post, I’ll share my experience with these attacks

What are Slow HTTP attacks?

Slow HTTP attacks are a sneaky type of cyberattack where the attacker sends data to a server very slowly to keep the connection open as long as possible. Instead of overwhelming the server with a flood of traffic (like in traditional DDoS attacks), this method ties up server resources using fewer connections—but for a long time.

Because the server waits for the request to finish, it can end up with too many half-open connections and stop responding to real users. These attacks are hard to detect because they seem like normal traffic at first glance, just moving slowly.

Slow HTTP attacks rely on the fact that the HTTP protocol, by design, requires requests to be completely received by the server before they are processed. 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. If the server keeps too many resources busy, this creates a denial of service.

Types of Slow HTTP attacks

Slow HTTP attacks are primarily of three types.

1. Slow headers (a.k.a Slowloris) This attack works by opening a large number of connections with the web server and keeping them alive by slowing sending never ending headers. The server won’t close the connections as the request is not complete and it will eventually exhaust all the resources on the server, blocking the legitimate requests.
2. Slow body (a.k.a R-U-Dead-Yet) R-U-Dead-Yet works just like Slowloris, but instead of sending never ending headers, it sends never ending POST body, forcing the server to keep the connections open. When all the resources of the server are occupied, it is unable to serve the legitimate requests.
3. Slow read The above-mentioned attacks exploit a web server by sending slow requests, however, slow read exploit is based on reading responses from a server very slowly. It works by advertising a very low client receive buffer size, triggering a big response from the server, and taking up to minutes to read a single response. When multiple such connections are created concurrently, it can consume all the server resources and lead to DoS.

Nginx architecture

Nginx has a master process and a number of helper processes (including worker processes). Master process manages all the privileged operations whereas the worker processes do the actual work and handle the connections. Nginx’s architecture is fundamentally different from that of Apache’s. Apache spawns a blocking thread for every new connection, whereas Nginx is based on non-blocking event-driven architecture.

This architecture provides innate prevention against Slow HTTP attacks to some extent as the worker process is not blocked on IO. It can continue to serve other requests. However, it is not full proof and depends on the Nginx configuration options as well.

Some of the common configuration options provided by Nginx to prevent such attacks are:

• limit_req – to limit the rate of requests from one IP
• limit_conn - to limit the number of connections from one IP
• client_body_timeout - to close the connections with slow body
• client_header_timeout - to close the connections with slow headers
• send_timeout - If the client does not receive anything within this time, the connection is closed.

Best Practices for Nginx Hardening

Beyond the basic Nginx settings, there are a few extra steps you can take to protect your server from Slow HTTP and other attacks. Here’s a quick checklist of practical best practices:

• Use IP reputation services to block known malicious IPs before they reach your server.
• Rate-limit by User-Agent or URI patterns to catch bots or unusual behavior early.
• Enable fail2ban to automatically ban IPs with repeated suspicious activity.
• Use a Web Application Firewall (WAF) like ModSecurity to catch abnormal HTTP patterns.
• Keep Nginx updated to make sure you’re protected against known vulnerabilities.
• Log and monitor your traffic regularly—unusual patterns often signal an issue before it becomes a full-blown attack.

These measures, along with careful tuning of Nginx’s built-in limits, can significantly boost your server’s resilience.

Detection Techniques

Detecting Slow HTTP attacks can be tricky because the traffic often looks normal at first glance. However, there are simple signs you can watch for. For example, if your server has a large number of open connections that stay active for a long time but send very little data, that’s a red flag. These kinds of patterns usually don’t match normal user behavior.

You can use tools like Wireshark to inspect network traffic and spot suspiciously slow data transfers. Server logs are also helpful—look for IPs making lots of connections without completing them. Intrusion Detection Systems (IDS) like Snort or Suricata can be set up to alert you when these patterns appear. Setting thresholds for connection duration and data size can help catch slow attacks early.

Must Read

• Different kinds of HTTP requests
• 10 Different Types of Servers Used by Companies
• How to Set Up a Basic HTTP Server in Java?

Conclusion

Slow HTTP attacks can be as vicious as volumetric DDoS attacks, if not dealt properly. Moreover, there are a lot of moving parts in the Nginx configuration and we need to understand them properly before making random copy/paste changes. I also see one more fix to this problem by rejecting very low client-side receive buffer window sizes, but I’m yet to explore that path.