There are plenty of tutorials around on how to install and configure modsecurity So This tutorial is nothing new, but I decided to write it since, I had to install mod_security on Debian Wheezy to protect a Debian Linux server websites from being periodically infected with Viruses / XSS / Backdoored Javascripts and Trojan horses.
Everyone who used Debian stable distribution knows the packages included in it are usually about 2 years older than latest available. Situation with latest Debian stable Wheezy is same, but anyways even a bit outdated my experience so far is mod_security does a great job of protecting Apache sites …
1. Install libapache-mod-security and other libraries (not obligitory), but useful on most Apache + PHP servers
Run below commands to add xml and rest of useful Apache stuff:
apt-get install libxml2 libxml2-dev libxml2-utils apt-get install libaprutil1 libaprutil1-dev
Above commands will install a bunch of other dependency packages.
Next install mod-security deb. Run below command, to install and activate modsecurity. Note that installing libapache-mod-security will also automatically restart the Apache server.
apt-get install libapache-mod-security
Next to enable all functionality of modsecurity headers Apache module is required as well, activate it with:
a2enmod headers service apache2 restart
2. Make sure mod_security Apache config looks like
<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>
Important part of conf is "Include "/etc/modsecurity/*.conf"" line. /etc/modsecurity directory is main place to set up and configure modsecurity. This configuration file, combined with mod-security.load, do everything necessary to load the modsecurity into Apache server.
3.Enable and Load modsecurity default configuration rules:
So far, modsecurity is loaded into the apache server, but isn't stopping any attempts of hack scripts / Viruses / or automated tools to exploit Vulnerabilities in Web Applications. To make modsecurity start filtering requests, should activate modsecurity specific configuration and load some regular expression rules.
First to do is enable "recommended" modsecurity configuration file:
cd /etc/modsecurity mv modsecurity.conf-recommended modsecurity.conf
Default configuration from recommended conf enables modsecurity in an "examine only" mode. In order to make full use of the module, we have to make a few changes. With favorite text editor open modsecurity.conf (mine is vim)and make the following change:
SecRuleEngine On
This makes modsecurity to block requests based on its (pre-written) developer rules. Other settings in this file that are useful to know about are the debug controls, very useful, whether you have to debug problems with sites not properly opening due to server enabled mod_security.
#SecDebugLog /opt/modsecurity/var/log/debug.log
#SecDebugLogLevel 3
This controls how much information is stored in modsecurity's "audit log as well as keeps track of attacks launched to server. Default debug level of 3 is pretty much and stores "everything". This is dangerous as a huge logs are produces on busy servers.
SecAuditLogParts ABIJDEFHZ
4. Enable extra modsecurity prevention rules
Modsecurity works by using rules by pre-defined patterns used to recognize when your website/s is being probed or attacked. Once installed modsecurity base package as a dependency modsecurity-crs package is installed. modsecurity-crs contains addition free core rule set. Current Core rule from modsecurity.org are newer than version included with wheezy, thus rules lack a bit behind but this is only option whether using default debian bundled packge otherwise manual modsecurity recompile is required. We all know how bad it is to custom compile software on production machines, so custom compile experiments are really bad idea.
CRS (Core Rule Set) is installed in /usr/share/modsecurity-crs. This directory contains an "activated_rules" directory present also in /etc/modsecurity
Quickest way to activate rules is by symlinking from the actual config and rule files into the /etc/modsecurity config directory.
We'll be making links from the /usr/share/modsecurity location into /etc/modsecurity to activate some other useful modsec useful rules. First link main crs config file:
ln -s /usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf /etc/modsecurity/modsecurity_crs_10_setup.conf
This file provides some basic configuration directives for crs.
Futher on, link each rule file in the base_rules and optional_rules directories using 2 tiny bash loops.
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
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)
SecRule ARGS "MY_UNIQUE_TEST_STRING"\ "phase:1,log,deny,status:503"
Finally after all configuration rules are loaded to modsec, Usual Apache restart is required:
/etc/init.d/apache2 restart
Whether no fatal errors pop up and Apache starts normally, now modsecurity should be properly running.
5. Verify if modsecurity is set-up and kicking ass
To verify installation, open a browser and access some of hosted websites like this:
http://www.your-server-domain.com/?test=MY_UNIQUE_TEST_STRING
A sure sign that modsec works is 503 "Service Temporarily Unavailable" message from Apache. Alternatively examine server's modsec audit log file (default location in /var/log/apache2/modsec_audit.log) (grep the string MY_UNIQUE_TEST_STRING. You should see full transcript of the communication between your browser and server logged. Depending on amount of site traffic gets make sure to monitor size of file for some minutes to make sure it doesn't grow too big and it doesn't fill up quickly your HDD.
Well now all fine your Apache server security is better for sure and by God's grace you should not have to deal with hundreds of hours of sites recovery after a bunch of client's websites are hacked.
Feedback and comments are mostly welcome. Enjoy 😉
