Securing Apache against HTTP DoS and/or Brute Force attacks

There are some native Apache directives that can be configured to help mitigate the effects of a Denial of Service (DoS) attack. The directives included Timeout, KeepAlive, and KeepAliveTimeout.


One way of attacking web servers is to try and exhaust the target systems resources by opening multiple connections and then never closing them. The more connections the server has open at once, the more resources are tied up holding details of those connections, which can lead to increased load and eventually to the server running out of resources.

The TimeOut directive tells the server how long to wait to receive a GET request, the amount of time between receipt of TCP packets on a POST or PUT request, or the amount of time between ACKs on transmissions of TCP packets in responses. Basically, this is the total time it takes to receive and respond to an http request.

In order to prevent a DoS attack from shutting down our web server, we need to change the default setting of 300 (which is 5 minutes) to something more reasonable such as 60 (which is 1 minute). You may even adjust this setting to be lower than 60. Think about this for a minute.

How many individual graphics files do you think there are in the average web page? Last check on the home page showed approximately 58 graphics files (gif and jpg) being referenced. Now imagine if your web browser had to create a brand-new connection for every one of those files. The overhead associated with initializing the HTTP connection would increase the time to fully load a web page significantly. This is where the concept of KeepAlives and “pipelining” web requests came from. The idea is simple: to allow multiple requests from the same client to utilize the same established HTTP connection. This efficient use of this capability dramatically decreases the amount of time it takes to fully download and display a web page. It is for this reason that the KeepAlive directive should be turned on.

Much in the same way that the Timeout directive limited the amount of time that the established HTTP connection would be valid, the KeepAliveTimeout directive will expire a socket after the designated amount of time. The difference between the Timeout and the KeepAliveTimeout directives is that the timeout setting designates the amount of time that the entire connection will be open and the KeepAliveTimeout directive states how long the server will wait for a subsequent request from the client. This means that the KeepAliveTimeout setting should always be less then the timeout setting. The default setting for KeepAliveTimeout is 15 seconds, which is reasonable; however, you could lower this just a bit if desired.

While these directives help with the performance of Apache and will lessen the impact of a DoS attack, there is another third-party module that is extremely effective.

mod_evasive is an evasive maneuvers module for Apache whose purpose is to react to HTTP DoS and/or Brute Force attacks. It was developed by Jonathan Zdziarski.

An additional capability of the module is that it is also able to execute system commands when DoS attacks are identified. This provides an interface to send attacking IP addresses to other security applications such as local host-based firewalls to block the offending IP address.

Installing mod_evasive on Centos 5.3:

( you can find lots of documents that explains how to install mod_evasive on other distributions )
# rpm -Uvh
# yum install mod_evasive

Configuring  mod_evasive :

/etc/httpd/conf.d/mod_evasive.conf is main configuration file for mod_evasive :

LoadModule evasive20_module modules/

<IfModule mod_evasive20.c>
 DOSHashTableSize    3097
 DOSPageCount        5
 DOSSiteCount        100
 DOSPageInterval     1
 DOSSiteInterval     1
 DOSBlockingPeriod   10
 #DOSSystemCommand    "su - someuser -c '/sbin/... %s ...'"
 DOSLogDir           "/var/lock/mod_evasive"


We will now discuss each of the mod_evasive directives. Most of this information is taken directly from the README file of mod_evasive, so proper credit should be given to the developer of this module.


This directive specifies the number of top-level nodes for each apache child process’s hash table. Increasing this number will provide faster performance by decreasing the number of iterations required to get to the record, but consume more memory for table space. You should increase this if you have a busy web server.


This is the threshold for the number of requests for the same page (or URI) per page interval. Once the threshold for that interval has been exceeded, the IP address of the client will be added to the blocking list.


This is the threshold for the total number of requests for any object by the same client on the same listener per site interval. Once the threshold for that interval has been exceeded, the IP address of the client will be added to the blocking list.


The interval for the page count threshold; defaults to 1 second intervals.


The interval for the site count threshold; defaults to 1 second intervals.


The blocking period is the amount of time (in seconds) that a client will be blocked for if they are added to the blocking list. During this time, all subsequent requests from the client will result in a 403 (Forbidden) and the timer being reset (e.g., another 10 seconds). Because the timer is reset for every subsequent request, it is not necessary to have a long blocking period; in the event of a DoS attack, this timer will keep getting reset.


If this value is set, an email will be sent to the address specified whenever an IP address becomes blacklisted. A locking mechanism using /var/lock/mod_evasive prevents continuous emails from being sent.
Note: Requires /bin/mail (provided by mailx)


If this value is set, the system command specified will be executed whenever an IP address becomes blacklisted. This is designed to enable system calls to ip filter or other tools. Use %s to denote the IP address of the blacklisted IP.


Choose an alternative temp directory. By default, “/tmp” will be used for the locking mechanism, which opens some security issues if your system is open to shell users. refer to =>


IP addresses of trusted clients can be whitelisted to ensure they are never denied. The purpose of whitelisting is to protect software, scripts, local searchbots, or other automated tools from being denied for requesting large amounts of data from the server. Whitelisting should not be used to add customer lists or anything of the sort, as this will open the server to abuse. This module is very difficult to trigger without performing some type of malicious attack, and for that reason, it is more appropriate to allow the module to decide on its own whether or not an individual customer should be blocked.
To whitelist an address (or range), add an entry to the Apache configuration in the following fashion:

DOSWhitelist    127.0.0.*
Wildcards can be used on up to the last three octets if necessary. Multiple DOSWhitelist commands may be used in the configuration.


mod_evasive comes with a PERL script called Without editing the file, if you execute it, it will send a total of 100 requests for incrementing URLs (based on 0-100) to the localhost address on port 80.

# small script to test mod_evasive's effectiveness
use IO::Socket;
use strict;

for(0..100) {
 my($SOCKET) = new IO::Socket::INET( Proto   => "tcp",
 PeerAddr=> "");

 if (! defined $SOCKET) { die $!; }
 print $SOCKET "GET /?$_ HTTP/1.0\n\n";
 $response = <$SOCKET>;
 print $response;

If you run the script, you should see output similar to the following:

# ./

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 200 OK

HTTP/1.1 403 Forbidden

HTTP/1.1 403 Forbidden

HTTP/1.1 403 Forbidden

HTTP/1.1 403 Forbidden

HTTP/1.1 403 Forbidden


5 thoughts on “Securing Apache against HTTP DoS and/or Brute Force attacks

  1. Mod_evasive is indeed a good module to prevent attacks and protect from hackers who wanna have some fun with our websites.
    I do have a question though, if installed (and using the default settings), could this module ban google when it is indexing the site?
    Google usually has it’s own algos for deciding how fast it crawls the website, can mod_evasive be harmfull in any way to google and other legitimate indexing bots?

  2. I think by inspecting Web Server log files you can find out your answer .
    to be honest i didn’t used it for long time , so i just recommend you to check your log files and if mod_evasive blocks google crawlers , then add it to white list .
    i also recommend you to check iptables connlimit and recent modules .

  3. Hi Nasser,
    Thank you for answering me; I’ll monitor my logs then to see if google bots get banned. I’m also gonna check the modules you recommend.

  4. Hi Nasser,
    I just wanted to let you know that I’ve been running mod_evasive for a week now.
    Google’s bot visits me daily continuously on a few seconds interval.
    So far mod_evasive did not blocked google’s bot, so all is ok.

  5. my mod_dosevasice doesn’t seem to log anything. I tried the and nothing gets logged even though it returns an 403 error and neither do I get any email notifications.
    I didn’t have an /bin/mail but I symlinked /usr/bin/mail to that location, still nothing :-(
    the log folder is owned by www-data so it should be writeable by the webserver
    any ideas?

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s