How to Mitigate Slowloris DDoS Attacks on Apache?

Slowloris is a highly targeted Distributed Denial of Service (DDoS) attack that allows a single machine to take down an Apache web server by opening multiple connections and keeping them open as long as possible. By sending partial HTTP requests and holding the connections concurrent, it quickly exhausts the server’s maximum concurrent connection pool, rendering it unresponsive to legitimate traffic. This article explores how Slowloris operates and provides actionable configuration steps, module implementations, and best practices to protect your Apache server from being overwhelmed.

Understanding the Slowloris Threat

Unlike traditional volumetric DDoS attacks that attempt to flood a server’s bandwidth, Slowloris utilizes a low-and-slow approach. It initiates standard TCP connections but never completes the HTTP request headers. Because Apache’s default behavior is to keep the connection open while waiting for the rest of the data, its connection threads quickly become saturated.

Implementation of mod_reqtimeout

The most effective native method to combat Slowloris in modern Apache environments is using the mod_reqtimeout module. This module allows you to set explicit timeouts and minimum data rates for receiving request headers and body data. If a client takes too long, Apache automatically drops the connection.

To configure this, ensure the module is enabled and add the following directives to your Apache configuration file (usually httpd.conf or apache2.conf):

<IfModule mod_reqtimeout.c>
    RequestReadTimeout header=10-20,MinRate=500 body=20,MinRate=500
</IfModule>

In this configuration:

• header=10-20,MinRate=500: Apache waits 10 seconds for the request headers. If the client sends data continuously at a minimum rate of 500 bytes per second, the timeout can extend up to a maximum of 20 seconds.
• body=20,MinRate=500: Apache applies a similar logic to the request body, allowing a maximum of 20 seconds as long as the 500 bytes per second threshold is met.

Utilizing mod_evasive for Rate Limiting

Another powerful tool is mod_evasive, an Apache module designed to provide evasive action in the event of an HTTP DoS/DDoS attack or brute force attack. It maintains an internal dynamic table of IP addresses and blocks anyone who requests the same page too many times or makes too many concurrent requests.

Once installed, you can customize its behavior within your configuration:

<IfModule mod_evasive24.c>
    DOSHashTableSize    3097
    DOSPageCount        2
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10
</IfModule>

This configuration blocks an IP address for 10 seconds if it requests the same page more than twice a second, or more than 50 total resources on the site within one second.

Tuning Core Apache Directives

You can also adjust core Apache directives to limit the resources a single attacker can consume. While these settings do not stop a sophisticated attack on their own, they significantly increase your server’s resilience when paired with other tools.

• KeepAlive: Ensure KeepAlive is enabled, but lower the KeepAliveTimeout. By reducing this value from the default 5 seconds down to 2 or 3 seconds, you force Apache to close idle connections much faster.
• MaxRequestWorkers: Ensure your MaxRequestWorkers (formerly MaxClients) directive is tuned according to your server’s available RAM. This prevents the server from swapping to disk if it experiences a sudden spike in connection attempts.

Deploying a Reverse Proxy

If application-level tweaks are not enough, placing a reverse proxy or a specialized load balancer in front of your Apache server provides an excellent layer of defense. Software like Nginx or HAProxy handles connections differently than Apache’s process-per-connection model.

Nginx uses an asynchronous, event-driven architecture that can handle tens of thousands of concurrent connections effortlessly. It completely buffers incoming HTTP requests before passing them to the backend Apache server. Because a Slowloris attack never completes the request headers, the malicious connection is terminated at the Nginx layer, ensuring your Apache server never even sees the attack traffic.