HOWTO: Set up Modsecurity on Debian 7
Tags apache, modsecurity, security, server
There are many places online that explain how to install and perform initial set up for modsecurity on Apache. However, I haven't found anywhere that shows how to do it with the standard Debian packages and that respects the normal apt update process. The caveat here is that like a lot of standard Debian packages, the packages included in wheezy lag upstream by a few versions. This is obviously something to consider, especially when dealing with security related software. If you're like me, and prefer having all package maintenance bound up in apt, particularly on production servers, so it all happens automatically, this is the trade-off required by Debian. Throughout this article, I will assume you're running as root, just to save having to type "sudo" 82 times. Just realize that if you're running as a normal user, most of these commands require sudo.
1. Install and Activate the software:
Run the following commands to install the xml and other supporting libraries required:
On my server, the second command also installed a lot of extra dependencies.
You're ready to install modsecurity itself. Run the following command, and apt will install and activate modsecurity. Realize this will also restart your apache server.
In order to make full use of modsec, the "headers" apache module is required as well, so activate it now:
2. Examine Apache config:
Before we dive in to editing config files, lets first talk about how the configuration is organized by default in Debian. Many online tutorials instruct you at this point to edit the apache config file manually to activate, configure, and load modsecurity. We don't need to do this in our case, since Debian provides it's own apache control utilities and files which take care of it (a2enmod, specifically, in this case). If you inspect the default Debian provided config file at /etc/apache2/mods-enabled/mod-security.conf you'll see something like this:
The important part of this is the "Include "/etc/modsecurity/*.conf"" line. The /etc/modsecurity folder will be your primary place to set up and configure modsecurity. This configuration file, combined with mod-security.load, do everything required to pull the modsecurity module into your apache server. We don't need to hand-modify any of apache's configuration, which is nice.
3. Activate and Load modsecurity-specific configuration:
At this point, modsecurity is loaded into the apache server, but isn't doing anything. We want it to start filtering requests, so we need to activate the modsecurity-specific configuration and load some rules.
Now, the first step is to enable the "recommended" modsecurity configuration file:
By default, this file enables modsecurity in an "examine only" mode. In order to make full use of the module, we have to make a few changes. Use your favorite text editor to open modsecurity.conf and make the following change:
This allows modsecurity to block requests based on its rules, which we'll activate in a moment. Some other settings in this file that are useful to know about are the debug controls, if you're troubleshooting.
Also, this controls how much information is stored in modsecurity's "audit log." This tracks attacks being made on your server. By default, it stores everything, which can get huge quickly if you have even a moderately busy server.
4. Activate modsecurity rules:
Modsecurity does its work by using rules which define the patterns it uses to recognize when your website is being probed or attacked. When we installed the modsecurity base package, apt also helpfully installed the modsecurity-crs package, which contains the free core rule set. Ideally, we would want to go get the most recent version of these rules from modsecurity.org. However, because of the package lag inherent in Debian, we can't. Core rule sets newer than the version included with wheezy (ver 2.2.5-2) require at least version 2.7 of the modsecurity plugin, which isn't available in default wheezy. So, we can't really get the newest rules without having to manually recompile modsecurity. Since I like to keep my production servers as close to vanilla as possible and it's often not a great idea to compile software on a production machine, we'll continue with the default wheezy packages and file locations.
The crs (core rule set) is installed in /usr/share/modsecurity-crs by default. This directory contains an "activated_rules" directory which we won't be using since we already have a de-facto "activated rules" directory: /etc/modsecurity
The preferred method to activate rules is by symlinking from the actual config and rule files into the config directory. This allows the package manager to update the files as necessary, without requiring the administrator to manually copy or edit files after an update. Some other tutorials recommend copying the /usr/share/modsecurity directory into /etc/modsecurity, however this also requires manual action after an update, and it's not necessary with the symlink technique.
We'll be making links from the /usr/share/modsecurity location into /etc/modsecurity to activate our desired configuration. First, we link to the main crs config file:
This file provides some basic configuration directives for the crs.
Now, we'll link each rule file in the base_rules and optional_rules directories using some quick shell magic:
With that done, there's one more edit to check if modsecurity blocking works as expected. Open the /etc/modsecurity/modsecurity.conf file and add the following lines at the end (this is from the free, modsecurity pdf book, link provided below)
That's it. Run
Assuming it restarts cleanly, you're done!
To verify your installation, open a browser and attempt to access your site like this:
http://www.example.com/?test=MY_UNIQUE_TEST_STRING
You should see a 503 "Service Temporarily Unavailable" message from the server. You can also examine your servers modsec audit log file (default location /var/log/apache2/modsec_audit.log) and search for that string. You will find the full transcript of the communication between your browser and server. Depending on the amount of traffic your site receives, you should monitor the size of this file for a while after installing modsec and probably configure your log rotating utility to know about it and rotate the file periodically.
That's it. You've set up modsecurity on a standard Debian 7 in such a way that it will update automatically and work with apt updates.
Please feel free to ask questions or post mistakes in the comments.
Further reading:
Modsec Getting started Book:
https://www.feistyduck.com/books/mod...d-may-2012.pdf
Modsec Site:
http://www.modsecurity.org/
1. Install and Activate the software:
Run the following commands to install the xml and other supporting libraries required:
Code:
apt-get install libxml2 libxml2-dev libxml2-utils apt-get install libaprutil1 libaprutil1-dev
You're ready to install modsecurity itself. Run the following command, and apt will install and activate modsecurity. Realize this will also restart your apache server.
Code:
apt-get install libapache-mod-security
Code:
a2enmod headers service apache2 restart
Before we dive in to editing config files, lets first talk about how the configuration is organized by default in Debian. Many online tutorials instruct you at this point to edit the apache config file manually to activate, configure, and load modsecurity. We don't need to do this in our case, since Debian provides it's own apache control utilities and files which take care of it (a2enmod, specifically, in this case). If you inspect the default Debian provided config file at /etc/apache2/mods-enabled/mod-security.conf you'll see something like this:
Code:
<IfModule security2_module>
# Default Debian dir for modsecurity's persistent data
SecDataDir /var/cache/modsecurity
# Include all the *.conf files in /etc/modsecurity.
# Keeping your local configuration in that directory
# will allow for an easy upgrade of THIS file and
# make your life easier
Include "/etc/modsecurity/*.conf"
</IfModule>
3. Activate and Load modsecurity-specific configuration:
At this point, modsecurity is loaded into the apache server, but isn't doing anything. We want it to start filtering requests, so we need to activate the modsecurity-specific configuration and load some rules.
Now, the first step is to enable the "recommended" modsecurity configuration file:
Code:
cd /etc/modsecurity mv modsecurity.conf-recommended modsecurity.conf
Code:
SecRuleEngine On
Code:
#SecDebugLog /opt/modsecurity/var/log/debug.log #SecDebugLogLevel 3
Code:
SecAuditLogParts ABIJDEFHZ
4. Activate modsecurity rules:
Modsecurity does its work by using rules which define the patterns it uses to recognize when your website is being probed or attacked. When we installed the modsecurity base package, apt also helpfully installed the modsecurity-crs package, which contains the free core rule set. Ideally, we would want to go get the most recent version of these rules from modsecurity.org. However, because of the package lag inherent in Debian, we can't. Core rule sets newer than the version included with wheezy (ver 2.2.5-2) require at least version 2.7 of the modsecurity plugin, which isn't available in default wheezy. So, we can't really get the newest rules without having to manually recompile modsecurity. Since I like to keep my production servers as close to vanilla as possible and it's often not a great idea to compile software on a production machine, we'll continue with the default wheezy packages and file locations.
The crs (core rule set) is installed in /usr/share/modsecurity-crs by default. This directory contains an "activated_rules" directory which we won't be using since we already have a de-facto "activated rules" directory: /etc/modsecurity
The preferred method to activate rules is by symlinking from the actual config and rule files into the config directory. This allows the package manager to update the files as necessary, without requiring the administrator to manually copy or edit files after an update. Some other tutorials recommend copying the /usr/share/modsecurity directory into /etc/modsecurity, however this also requires manual action after an update, and it's not necessary with the symlink technique.
We'll be making links from the /usr/share/modsecurity location into /etc/modsecurity to activate our desired configuration. First, we link to the main crs config file:
Code:
ln -s /usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf /etc/modsecurity/modsecurity_crs_10_setup.conf
Now, we'll link each rule file in the base_rules and optional_rules directories using some quick shell magic:
Code:
cd /usr/share/modsecurity-crs/base_rules for f in * ; do sudo ln -s /usr/share/modsecurity-crs/base_rules/$f /etc/modsecurity/$f ; done cd /usr/share/modsecurity-crs/optional_rules for f in * ; do sudo ln -s /usr/share/modsecurity-crs/optional_rules/$f /etc/modsecurity/$f ; done
Code:
SecRule ARGS "MY_UNIQUE_TEST_STRING"\ "phase:1,log,deny,status:503"
Code:
sudo service apache2 restart
To verify your installation, open a browser and attempt to access your site like this:
http://www.example.com/?test=MY_UNIQUE_TEST_STRING
You should see a 503 "Service Temporarily Unavailable" message from the server. You can also examine your servers modsec audit log file (default location /var/log/apache2/modsec_audit.log) and search for that string. You will find the full transcript of the communication between your browser and server. Depending on the amount of traffic your site receives, you should monitor the size of this file for a while after installing modsec and probably configure your log rotating utility to know about it and rotate the file periodically.
That's it. You've set up modsecurity on a standard Debian 7 in such a way that it will update automatically and work with apt updates.
Please feel free to ask questions or post mistakes in the comments.
Further reading:
Modsec Getting started Book:
https://www.feistyduck.com/books/mod...d-may-2012.pdf
Modsec Site:
http://www.modsecurity.org/
Total Comments 0
