Skip to content

More mod_security

After I wrote my piece about mod_security, the people at Packt Pub­lish­ing offered me a copy of their book Mod­Se­cur­ity 2.5, with the pro­viso that I review it. This soun­ded like a reas­on­able idea to me.

Over­all, I would recom­mend the book to people who are run­ning Apache and need to know more about rel­at­ively simple ways to add secur­ity to their web sites. The book motiv­ates the use of mod_security and con­vinced me that any­one host­ing a web site should have it installed, ready to deal with any prob­lems you encounter. The book goes through com­mon scen­arios and what mod_security can do to deal with them, includ­ing recent events such as an attack on Twit­ter in April 2009. All the examples are explained clearly, and the rule con­fig­ur­a­tions will look famil­iar if you’ve had some prac­tice writ­ing either Rewrit­eEn­gine dir­ect­ives or httpd.conf vhost con­fig­ur­a­tions. It also shows how to send alert emails or count the num­ber of times a file has been down­loaded, which I thought were nice additions.

As is the case with any secur­ity sys­tems, there are lay­ers upon lay­ers of things you can do, and the book includes quite a few that I think are overkill unless you sus­pect you’re being tar­geted for some reason (such as fin­an­cial or con­tro­ver­sial sites). If you do have one of those sites, the chapter on block­ing com­mon attacks alone could save a lot of pain. Many of the com­mon attacks are covered (SQL injec­tion, XSS, etc.), along with ways to com­bat them.

The book includes instruc­tions on installing a couple of GUI tools to help mon­itor incid­ents; I didn’t have time to install all of these given the OpenSolaris/Linux dif­fer­ences and it’s less import­ant for me given the fact I’m not run­ning sites that are likely to be attacked (my high-bandwidth sites are on com­mer­cial host­ing). If you’re run­ning import­ant web sites, you’d prob­ably want to set up these tools to work prop­erly to save hunt­ing through log files yourself.

I tested a few things out on the OpenSol­aris box in the base­ment; get­ting it installed was a little dif­fer­ent to the book (which is writ­ten mostly assum­ing a Linux web stack).

mod_security is installed with 2009.06 ver­sion of the OpenSol­aris web stack, but not act­ive. To activ­ate: pfexec cp /etc/apache2/2.2/samples-conf.d/security2.conf /etc/apache2/2.2/conf.d/security2.conf. Restart the server with svcadm restart apache22 and check that mod_security is installed by see­ing if the logs are avail­able under /var/apache2/2.2/logs. You can also check if the mod­ule is loaded by cre­at­ing and execut­ing a phpinfo file.

{ 1 } Comments

  1. Tim Post | Mar 17, 2010 at 8:15 am | Permalink

    The people at gotroot.com pub­lish a very com­pre­hens­ive list of rules in (close to) real time for the extremely para­noid, or a delayed list at no charge. mod_sec plus bad beha­vior keeps things pretty quiet on our xen farm, full of Word­Press blogs. Take care to go through them prior to using them, many of them really don’t apply to typ­ical Word­Press sites.

    I also love lynx, in fact I don’t use it just as a usab­il­ity checker, I often browse with it. As far as I know, it handles all of the required head­ers that plu­gins like bad beha­vior check.

    People who want to do bad things are usu­ally going to use curl or some­thing else and mas­quer­ade per­fectly as a mod­ern browser.

    The mod_sec + bad beha­vior 1–2 combo works really, really well when you add Word­Press to an exist­ing (mostly static) site and bring those pages into the WP loop. Typ­ic­ally, whatever your mod_sec rules don’t catch, bad beha­vior does and you have the con­veni­ence of review­ing the logs from the WP admin interface.

    Just be care­ful with Bad Behavior’s black­list option, it can be a little over zeal­ous :)

Post a Comment

Your email is never published nor shared. Required fields are marked *