DDoS
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
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_METHODS POST,PUT,OPTIONS,CONNECT
MS_WhiteList /etc/spamhaus.wl
MS_CacheSize 256
</IfModule>
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:
SecRequestBodyLimit SecRequestBodyNoFilesLimit
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
</IfModule>
inside the <VirtualHost> section.
For a particular directory:
<Directory "/var/www/wp-admin">
<IfModule security2_module>
SecRuleEngine Off
</IfModule>
</Directory>
Further Reading
Official modsecurity documentation https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual.