Securing Apache Web Servers against Slowloris Denial of Service

In the landscape of Denial of Service (DoS) attacks, the most visible threats are volumetric: UDP floods or ICMP sweeps designed to saturate network bandwidth. These attacks are "loud," easily detectable by NetFlow analysis, and often mitigated at the edge by scrubbing centers. However, a more insidious class of attack exists: the "low and slow" attack.

The Slowloris attack is the quintessential low-and-slow threat. It does not attempt to overwhelm your bandwidth; instead, it targets the finite connection resources of the web server itself. For an Apache administrator, understanding and mitigating Slowloris is not merely an optimization task-it is a fundamental requirement for maintaining availability.

The Anatomy of a Slowloris Attack

To understand Slowloris, one must understand the mechanics of the HTTP protocol and the process-based architecture of traditional Apache Multi-Processing Modules (MPMs).

An HTTP request is technically complete only when the server receives a specific termination sequence: a double CRLF (`\r\n\r\n`). This sequence signals the end of the HTTP headers. Slowloris exploits this by initiating a legitimate TCP connection and sending partial HTTP headers. The attacker then periodically sends small, non-terminating fragments of the header (e.g., `X-Keep-Alive: 1\r\n`) just frequently enough to prevent the server from timing out the connection.

The Mechanism of Exhaustion

The vulnerability is most acute in Apache configurations utilizing the `mod_prefork` MPM. In `mod_prefork`, every incoming connection is assigned to a dedicated process. These processes are heavy and finite.

When a Slowloris attacker opens hundreds or thousands of these "partial" connections, each one occupies a worker process. Because the attacker is sending data-even if it is only one byte every few seconds-the server perceives the connection as active. Eventually, the `MaxRequestWorkers` limit is reached. At this point, the server can no longer accept new, legitimate connections. To the outside world, the server appears up (the TCP port is open), but it is effectively dead (the application layer is unresponsive).

Unlike volumetric attacks, Slowloris requires negligible bandwidth. A single laptop on a standard home connection can take down a high-capacity enterprise server by simply maintaining a few thousand idle-but-active sockets.

Mitigation Strategy 1: Implementing `mod_reqtimeout`

The most direct and effective native defense within the Apache ecosystem is the `mod_reqtimeout` module. This module allows administrators to set strict limits on how long a client can take to send HTTP headers and bodies, and at what minimum data rate.

Instead of a global `Timeout` directive-which is often too blunt an instrument-`mod_requeutime` allows for granular control.

Practical Configuration

To implement this, you should modify your Apache configuration (typically within the `Global` context or specific `VirtualHost` blocks). A robust configuration looks like this:

```apache

<IfModule mod_reqtimeout.c>

The first value (20) is the initial timeout in seconds.

The second value (40) is the maximum timeout if the rate drops.

The 'minrate=500' ensures the client must send at least 500 bytes/sec.

RequestReadTimeout header=20-40,minrate=500 body=20,minrate=500

</IfModule>

```

Breakdown of the directive:

• `header=20-40`: The server will wait 20 seconds for the headers to arrive. If the headers are arriving, the server will extend that wait up to a maximum of 40 seconds, provided the `minrate` is met.
• `minrate=500`: This is the critical "anti-slow" component. If the incoming data rate drops below 500 bytes per second, the timer begins to expire aggressively.
• `body=20,minrate=500`: This applies similar logic to the HTTP request body (relevant for POST requests), ensuring that even if the headers are sent, the payload cannot be trickled in indefinitely.

Mitigation Strategy 2: Architectural Buffering via Reverse Proxy

While tuning Apache is essential, the most resilient architectural pattern is to avoid exposing the Apache origin server directly to the public internet. By placing an event-driven reverse proxy, such as Nginx or HAProxy, in front of Apache, you create a "buffer" layer.

N

Conclusion

As shown across "The Anatomy of a Slowloris Attack", "Mitigation Strategy 1: Implementing `mod_reqtimeout`", "Mitigation Strategy 2: Architectural Buffering via Reverse Proxy", a secure implementation for securing apache web servers against slowloris denial of service depends on execution discipline as much as design.

The practical hardening path is to enforce admission-policy enforcement plus workload isolation and network policy controls, certificate lifecycle governance with strict chain/revocation checks, and protocol-aware normalization, rate controls, and malformed-traffic handling. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track detection precision under peak traffic and adversarial packet patterns and mean time to detect, triage, and contain high-risk events, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.