mod_security is a well known web application firewall for Apache that is easy to setup and provides a fair amount of protection from web malware and can even provide some protection from comment spam. The benefits of mod_security have been discussed over and over again and with the recent unforeseen problems with WordPress (In case you have not heard about it, if you have not upgraded your WordPress 2.1.1 installation, you need to do it NOW), mod_security would have provided a level of security if it was installed. Since I had to install mod_security on one of my servers, the steps are fresh in my mind and worth a post. All of the steps below are assuming that you have some sort of a LAMP installation over which you have complete control. If you are on a shared host on LAMP, you will have to ask your provider to install mod_security for you.
If you are running some version of Fedora greater than Core 2, mod_security installation might be as simple as invoking yum:
/usr/bin/yum install mod_security
/etc/init.d/httpd restart
For Debian and Ubuntu, you could do:
apt-get install libapache2-mod-security
a2enmod mod-security
/etc/init.d/apache2 force-reload
If per chance you are running a version of Fedora that does not have the mod_security package, you will need to download the source, compile the module, configure mod_security and restart Apache.
- Get the latest version of mod_security from http://www.modsecurity.org/download/modsecurity-apache_2.1.0.tar.gz
- Make sure you have httpd-devel installed with
/usr/bin/yum httpd-devel install - Follow the steps outlined here. The steps are very clear and should not be confusing. For the step that asks to configure mod_security, you can use a very basic config from here and copy the contents to /etc/httpd/conf.d/mod_security.conf More detailed rules can be found here.
- After Apache restarts, make sure you web application (and WordPress) are running as normal
If things break, removing the module is as simple as commenting out the line that activates mod_security in httpd.conf (search for mod_security in /etc/httpd/conf/httpd.conf) and restarting your Apache. There are lots of fun rules for comment spam mitigation, Google Hack Signatures and other tricks that you can add to mod_security. As with any high level application security, this adds overhead and there is a delicate balance between protection and paranoia. mod_security 2.1.0 has significant performance improvements over earlier versions.
Standard Disclaimer: This How To comes without any warranty or guarantee of any sort. Please take these steps at your own risk and do not modify or change anything you are not familiar or comfortable with. I will not be responsible if you break your server.
Ubuntu (6.06.1) has mod_security 1.8.7. This doesn’t appear to support the ‘fun rules’ you linked to at gotroot.com. 🙁
Hey, thanks for the tutorial Mark. I got my host to do the dirty work 😉 but it sure helps to know how to do it manually.
Thank you for the nice reading, i remember the old days with FreeBSD and the huge time it required to fulfill all those dependency needs to get a new mod_something installed.. Now Fedora makes it much easier.. Whoora 🙂
2 things, for freebsd updating or adding something properly in ports is amazingly simple
(cd to port directory, make install clean!)
for example
# cd /usr/ports/www/mod_security
# make install clean
And you are done. Stuff that isn’t included in ports can surely be a huge pain in the butt, (and i’ve been using freebsd since 3.x), but even given that I find *overall* freebsd much simpler to use than rpm’s. Debian is a whole different matter, its pretty well thought out.
One comment – it is important to mention that ModSecurity 2.X has a different Rules Language. One specific example – SecFilter and SecFilterSelective are now replaced with just SecRule (which has the same syntax as SecFilterSelective). This, however, means that you can not just “plug-n-play” previous rules. Some of the rules that you are referencing are for the older 1.X branch.
FYI – the 2.1.0 version now comes bundled with the Core Rules (http://www.modsecurity.org/pro.....index.html) which provide great protection for a wide variety of attacks.
I hope this info helps.
—
Ryan C. Barnett
ModSecurity Community Manager
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache
Ah, cool, does that mean I can plug-and-play a newer rule set in an older version just by renaming all occurrences of ‘SecRule’ with ‘SecFilterSelective’?
How about this for an answer – maybe… You most likely could back port SecRule rules to SecFilterSelective, however there are other variables that may affect them. There are new processing phases (request headers, request body, response headers, response body and logging) where you need to specify which phase the rule will run.
I will actually be creating a Migration from 1.X to 2.0 soon that will be posted on the ModSecurity website that will explain all of the differences between the two versions and provide tips for the migration process.
In the mean time, if you are contemplating migrating and aren’t sure exactly “why” you should upgrade, check out some of the docs on the http://www.modsecurity.org site. This link is for an interview that Ivan did for SecurityFocus on ModSecurity 2.0 and the new features – http://www.securityfocus.com/columnists/418. Also, I have some archived Webcast data under the training page that highlights Mod 2.0 – http://www.modsecurity.org/training/index.html.
Finally, I am hosting a live Webcast tomorrow called “Cool Rules” which will highlight some really interesting Mod rules that tackle complex web security issues such as –
– Inspecting Basic Auth Credentials
– Monitoring Form-based Authentication Failures
– Defending Web Services
– Proxy Failover Assistance
– Overview of Remo Tool (Rule Editor for ModSecurity)
If you are interested, you can get the Webcast registration info on the Mod training page (link above).
Cheers,
–
Ryan C. Barnett
ModSecurity Community Manager
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache
Yeah, I noticed REQUEST_BODY breaks when used in 1.8. I’m not interested in upgrading to ModSecurity 2.0 though, because 1.8 is supported by my distribution (Ubuntu) with security updates.
Besides, I can’t seem to find ModSecurity 2.0 packaged for Ubuntu, anyway.
It’s a shame the modsecurity.org site didn’t archive the 1.8 documentation. I’m feeling around blind here. 🙁
I strongly recommend that everyone puts mod_security in “detection only” mode for a week or two after installation, and for a day or so after any ruleset change — to work out all the false positives.
Need a little help. I am having trouble installing modsecurity 2.1.1 on my Debian machine. I installed using /usr/local/modsecurity/modsecurity-apache_2.1.1/apache2 apxs2 -n modsecurity -cia modsecurity.c which placed the modsecurity.so module in /etc/apache2/httpd.conf I placed the core ruleset in /etc/apache2/modsecurity But, when I try to start apache2 I get two syntax errors, one in apache2.conf which indicates: syntax errror on line 126 of /etc/apache2/apache2.conf: syntax error on line 6 of /etc/apache2/httpd.conf: Cannnot load /usr/lib/apache2/modules/modsecurity.so into server. /usr/lib/apache2/modules/modsecurity.so: undefined symbol msre_format_metadata
I had a previous install of modsecurity functioning but it became non-functional after I upgraded to etch and 2.6 kernel
Would like to get modsecurity functional again, hope someone can help. Thanks in advance
Got it.
I wish that debianuser would have explained what he did to get it working. 🙁