Secure Apache Server from DDoS, Slowloris, and DNS Injection Attacks


There is an Apache module that was created to prevent a DDoS attack, although it's probably not installed by default. Follow these steps to install the module.

Open the terminal window. Issue the command:

$ sudo apt-get -y install libapache2-mod-evasive

Run the following command:

$ sudo mkdir -p /var/log/apache2/evasive

Run the following command

$ sudo chown -R www-data:root /var/log/apache2/evasive

Open the /etc/apache2/mods-available/evasive.load file (using sudo and your favorite text editor) and append the following to the bottom of that file (this is one configuration per line):

DOSHashTableSize 2048
# Maximum number of requests for the same page
DOSPageCount 20
# Total number of requests for any object by the same client IP on the same listener
DOSSiteCount 300
# Interval for the page count threshold
DOSPageInterval 1.0
# Interval for the site count threshold
DOSSiteInterval 1.0
# Time that a client IP will be blocked for
DOSBlockingPeriod 10.0
DOSLogDir "/var/log/apache2/evasive"
DOSEmailNotify [email protected]

Save the file and restart Apache. Now be better protected from DDoS attacks.


Slowloris is software written by Robert Hansen that allows one machine to take down another machine's web server using minimal bandwidth. Apache has a module to help prevent such attacks. Here's how to get it working for you.

Run the following command:

$ sudo apt-get -y install libapache2-mod-qos

After the installation is complete, check the configuration in /etc/apache2/mods-available/qos.conf to make sure it perfectly fits your needs. After you tweak the module (if necessary), restart Apache and enjoy a Slowloris-free web server.

DNS Injection

Spam from web forms is not only prevalent, it's a fast-track method of getting your domain blacklisted by the likes of Spamhaus. To prevent DNS Injection attacks, which are attacks that can inject fake DNS names into your server's cache, you need to add another module to Apache. Follow these steps.

Run the following command:

$ sudo apt-get -y install libapache2-mod-spamhaus

After the installation completes, issue the command:

$ sudo touch /etc/spamhaus.wl

With the module installed, open the /etc/apache2/conf-available/security.conf file (using sudo and your favorite text editor) and append the following to the bottom of your configuration file:

<IfModule mod_spamhaus.c>
    MS_WhiteList /etc/spamhaus.wl 
    MS_CacheSize 256 

Save the security.conf file and restart Apache so the new module will take effect.

Installing mod_security

Mod security is a free Web Application Firewall (WAF) that works with Apache, Nginx and IIS. It supports a flexible rule engine to perform simple and complex operations and comes with a Core Rule Set (CRS) which has rules for SQL injection, cross site scripting, Trojans, bad user agents, session hijacking and a lot of other exploits. For Apache, it is an additional module which makes it easy to install and configure.

Modsecurity is available in the Debian/Ubuntu repository:

$ sudo apt-get install libapache2-modsecurity

Verify if the mod_security module was loaded.

$ sudo apachectl -M | grep --color security

You should see a module named security2_module (shared) which indicates that the module was loaded.

Modsecurity's installation includes a recommended configuration file which has to be renamed:

$ sudo mv /etc/modsecurity/modsecurity.conf{-recommended,}

Reload Apache

$ sudo service apache2 reload

You'll find a new log file for mod_security in the Apache log directory:

$ ls -l /var/log/apache2/modsec_audit.log
-rw-r----- 1 root root 0 Oct 19 08:08 /var/log/apache2/modsec_audit.log

Configuring mod_security
Out of the box, modsecurity doesn't do anything as it needs rules to work. The default configuration file is set to DetectionOnly which logs requests according to rule matches and doesn't block anything. This can be changed by editing the modsecurity.conf file:

$ sudo vim /etc/modsecurity/modsecurity.conf

Find this line

SecRuleEngine DetectionOnly

and change it to:

SecRuleEngine On

If you're trying this out on a production server, change this directive only after testing all your rules.

Another directive to modify is SecResponseBodyAccess. This configures whether response bodies are buffered (i.e. read by modsecurity). This is only neccessary if data leakage detection and protection is required. Therefore, leaving it On will use up droplet resources and also increase the logfile size.

Find this

SecResponseBodyAccess On

and change it to:

SecResponseBodyAccess Off

Now we'll limit the maximum data that can be posted to your web application. Two directives configure these:


The SecRequestBodyLimit directive specifies the maximum POST data size. If anything larger is sent by a client the server will respond with a 413 Request Entity Too Large error. If your web application doesn't have any file uploads this value can be greatly reduced.

The value mentioned in the configuration file is

SecRequestBodyLimit 13107200

which is 12.5MB.

Similar to this is the SecRequestBodyNoFilesLimit directive. The only difference is that this directive limits the size of POST data minus file uploads-- this value should be "as low as practical."

The value in the configuration file is

SecRequestBodyNoFilesLimit 131072

which is 128KB.

Along the lines of these directives is another one which affects server performance: SecRequestBodyInMemoryLimit. This directive is pretty much self-explanatory; it specifies how much of "request body" data (POSTed data) should be kept in the memory (RAM), anything more will be placed in the hard disk (just like swapping). Since droplets use SSDs, this is not much of an issue; however, this can be set a decent value if you have RAM to spare.

SecRequestBodyInMemoryLimit 131072

This is the value (128KB) specified in the configuration file.

Excluding Hosts and Directories
Sometimes it makes sense to exclude a particular directory or a domain name if it is running an application like phpMyAdmin as modsecurity and will block SQL queries. It is also better to exclude admin backends of CMS applications like WordPress.

To disable modsecurity for a complete VirtualHost place the following

<IfModule security2_module>
    SecRuleEngine Off

inside the <VirtualHost> section.

For a particular directory:

<Directory "/var/www/wp-admin">
    <IfModule security2_module>
        SecRuleEngine Off

Further Reading

Official modsecurity documentation

0.00 avg. rating (0% score) - 0 votes