Stop Slowloris Attacks: Practical Prevention Measures That Work
Slowloris attacks exploit connection timeouts rather than bandwidth, meaning standard rate limiting often fails to stop the resource exhaustion at the application layer.
Prevent Slowloris by configuring web servers to enforce strict request timeouts and limit concurrent connections per IP address. Use reverse proxies to absorb incomplete requests before they reach your application. Monitor for half-open connections and block persistent low-bandwidth streams.
The Mechanism of Resource Exhaustion
Slowloris is a denial-of-service attack that targets web servers by opening many connections to the target and keeping them open as long as possible. Unlike volumetric attacks that flood the network with traffic, this method uses minimal bandwidth. The attacker sends partial HTTP requests and then sends small amounts of data at very slow intervals. This prevents the server from timing out the connection while also preventing the request from completing.
The server must allocate memory and processing power to maintain each open connection. If the attacker opens enough connections, the server reaches its maximum connection limit. Legitimate users are then refused service because no new connections can be accepted. This is a classic resource exhaustion scenario where the cost of holding a connection exceeds the cost of processing a valid request.
Why Bandwidth Monitoring Fails
Most network monitoring tools focus on bandwidth usage and packet volume. These tools look for sudden spikes in data transfer that indicate a flood attack. Slowloris operates below these detection thresholds. An attacker might send only a few bytes per second per connection. To a monitoring system, this looks like normal, low-volume traffic.
Imagine a highway where every lane is blocked by a single car moving at one mile per hour. The total volume of cars is low, but the throughput is zero. This is the core difficulty in detecting Slowloris. You cannot rely on traffic volume alerts. You must monitor connection states and duration. This requires looking at the application layer rather than just the network layer.
The Role of Reverse Proxies
A reverse proxy sits between your web server and the internet. It accepts incoming requests and forwards them to the backend server. This layer is critical for defense because it can inspect and manage connections before they reach your application. The proxy can enforce stricter timeouts than the backend server.
If a connection is incomplete after a short period, the proxy can terminate it. This protects the backend server from having to manage slow, hanging connections. The proxy absorbs the resource cost of the attack. This separation of duties allows the application to focus on processing valid requests. It also simplifies configuration because you centralize security policies at the edge.
Configuring Connection Timeouts
The most direct defense is to reduce the time a server waits for a complete request. Web servers have settings that control how long they keep a connection open while waiting for data. Reducing this timeout forces the server to close incomplete connections quickly. This releases the resources for legitimate users.
You must balance this with user experience. If the timeout is too short, legitimate users on slow networks may be disconnected. However, a timeout of ten to thirty seconds is usually sufficient for standard web interactions. This setting applies to the entire request lifecycle. It ensures that no single connection can hold resources indefinitely.
Limiting Concurrent Connections
Another effective measure is to limit the number of simultaneous connections from a single IP address. A normal user typically opens a few connections to load a page. An attacker opens hundreds or thousands. By capping the number of connections per IP, you mitigate the impact of a single source.
This requires careful tuning to avoid blocking legitimate users. Some users share a single IP address, such as those behind a corporate firewall or in a large household. Setting the limit too low can cause false positives. You must monitor the impact and adjust the threshold based on your specific traffic patterns. This measure reduces the blast radius of any single attacker.
What Does Not Work
Relying solely on bandwidth-based intrusion detection systems is ineffective. These systems look for high-volume traffic anomalies. Slowloris generates low-volume traffic. Additionally, simple firewall rules that block specific ports do not stop this attack. The attack uses standard HTTP or HTTPS ports. Blocking these ports would stop all legitimate web traffic.
Practical Prevention Priority
The following table ranks measures by the amount of risk they remove. Focus on the top items first.
| Measure | Effort | What it stops |
|---|---|---|
| Reduce request timeouts | Low | Incomplete requests holding resources |
| Limit connections per IP | Medium | Single-source connection flooding |
| Use reverse proxy | High | Direct application layer exposure |
| Monitor connection states | Medium | Detection of abnormal connection duration |
Implementing these measures creates a layered defense. No single measure is perfect, but together they significantly reduce the attack surface. This approach aligns with shift-left security principles by addressing vulnerabilities early in the request processing chain.
Closing Checklist
Use this checklist to verify your defenses. These steps provide immediate risk reduction.
- Verify web server timeout settings are set to a reasonable duration.
- Configure connection limits per IP address to prevent single-source flooding.
- Enable logging for connection duration to detect anomalous behavior.
These actions do not require new hardware or complex software changes. They rely on standard configuration options available in most web servers. Regular review of these settings ensures they remain effective as your traffic patterns change.
Key takeaways
- Connection timeout settings are the most effective defense against slow HTTP request attacks.
- Reverse proxies can filter malformed or incomplete requests before they consume application resources.
- Standard bandwidth monitoring fails to detect Slowloris because it consumes very little data volume.
Slowloris attacks exploit connection limits rather than bandwidth, requiring timeout and connection-based defenses rather than volume-based filtering. Implement strict request timeouts and per-IP connection limits immediately to reduce your exposure.
Frequently asked questions
Can a CDN stop a Slowloris attack?
Content delivery networks can mitigate Slowloris by absorbing connections at the edge and enforcing strict timeouts before traffic reaches your origin server.
How do I detect a Slowloris attack in progress?
Look for a high number of half-open connections or connections that remain open for unusually long periods with minimal data transfer.
Is HTTPS more vulnerable to Slowloris than HTTP?
HTTPS is equally vulnerable because the attack targets the connection state, not the encryption. The server still allocates resources for each open TLS handshake.
Should I block all slow connections?
No, blocking all slow connections may disrupt legitimate users on poor networks. Instead, use progressive timeouts and connection limits to balance security and usability.
How this guide was produced: written by the BlueTeam Herald editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
