WebTracker.one

ModSecurity is a web application firewall. I'll say up front that caution must be exercised with ModSecurity. Many of the OWASP rules interfere with scripts and break websites. Unless you use it sparingly and judiciously, you're better off without it. (Note: Instead of ModSecurity, the Fail2Ban hacker script I presented earlier can block a lot of bad actors without interfering with your website. See the weblog post on using Fail2Ban.)

Here is how to go about implementing ModSecurity for a Linux site running Apache.

Install the software:


Restart Apache:


Make new copies of the .conf file and the mapping file with usable names:


Pull up the ModSecurity configuration file for edit:


Make the following changes to the ModSecurity config file (the first change is to turn ModSecurity to on and the second change is to improve performance):


Enable the ModSecurity security2 module for the Apache web server:


Perform an Apache config test to make everything is OK:


Restart Apache:


Download the OWASP Core Rule Set to your home directory:


Unzip the file:


Look through the rules folder for those rules that interest you:


You don't want to use all the rules. They will break your website.

If you see a rule that you want to try, copy it to /etc/modsecurity:


The ModSecurity security2 module tells the system which rules to implement:


The module contains this line of code that shows the folder(s) containing the active rules:


The security2 module is saying that .conf rules in the /etc/modsecurity folder will be implemented. Active rules can be in any folder, as long as security2.conf module states the path. If rules reside in another directory that is not listed by security2, such as your home directory, these rules will not be implemented.

In my case, I'm only using the DOS Protection rule. I doubt that I use any more.

In case you want to know if ModSecurity is working, various sites have provided the following test. Go to your SSL config file. In my case:


Enter the following code before the VirtualHost close out line:


Perform an Apache config test to make everything is OK:


Restart Apache:


Go to your web browser and enter your site name with the following Get variable: In my case, webtracker.one/?testparam=test. If ModSecurity is working, you will receive a 403 error.

You can go back and delete the lines of code that you added to your SSL config file.

ModSecurity generates Apache audit log entries at the following location:


The logs record a series of events. Each event begins with an audit log header that shows the following information:

1. Timestamp
2. Unique transaction ID
3. Source IP address
4. Source port
5. Destination IP address
6. Destination port

Here is an example:


The mackerel.toolbar.netcraft.com originating at port 41180 from IP address 52.30.171.229 is connecting to my site at port 443.

The information following the audit log header varies per event. In the case of Netcraft, they generated an HTTP/1.1 400 Bad Request error.

Looking through the logs, I see several entries that were generated by myself due to coding errors. For instance, I saw this message:

As a quick note, ModSecurity blocked me from importing SQL files into the MySQL database. So I turned it off. As simple as this - sudo a2dismod security2.

That was the end of my experiment with ModSecurity.