Mod Security

Mod Security

A couple of weeks ago talking with a friend that owns a hosting company, he mentioned Mod Security. My friend was interested in installing it in his webserver and was asking if I ever had tested it has an apache module.

I've never had used modsecurity, but had already heard of it. Before knowing about modsecurity I needed to do some filtering on a webserver and used Snort with a small set of rules and worked pretty well.

After talking with him I became really interested in trying out ModSecurity. But afterall, what is it? In it's webpage we can read the following:

ModSecurity is an open source intrusion detection and prevention engine for web applications (or a web application firewall). Operating as an Apache Web server module or standalone, the purpose of ModSecurity is to increase web application security, protecting web applications from known and unknown attacks.

In other words modsecurity is a firewall at the application level. It has a built in rule engine, where the administrator creates rule chains defining patterns to look for and actions to be taken. The patterns can be set to inspect the body, the GET method or POST, or all of them.

A really simple - and most of the times pointless - feature that modsecurity has, is obfuscate your server. You can tell modsecurity what you want to send in the server tag, instead of your actual server. I don't really believe in security by obscurity although this is one of those "cool" features that allows everyone to start runnning the "Matrix WebServer" with no effort at all.

I'm now using ModSecurity and I'm getting fond of it, you can build simple rules that stop possible SQL Injections, buffer overflows, or access to sensible files. Although, ModSecurity should not be used as the only defence against the attacks. Good programming pratices should still be used from the simplest Transaction Script written in PHP that accesses the database to a complex WebService and it's SOAP protocol.

ModSecurity is not only used to filter what's getting into the webserver (and webservices) but also what's getting out of it. You can prevent sensitive information of getting out, which comes in handy when somehow modsecurity did not protect the server nor the programmer protected the code and sensitive information is going out to the attacker. ModSecurity, if well configured, will detect and prevent the disclosure of such information.

The major problem in things like ModSecurity - or in snort - is answer the question what are we looking for?. An up to date and well formed ruleset is something that we should always maintain, another problem that might come up is the extension of the rulesets. The Regex Parser that Apache uses is not the fastest one - at least the one used in Apache 1.x - so we should also keep in mind the length of the rulesets.

There are special tags (<Location>) that can restrict rulesets for each location and that can also help a bit on controlling the amount of rules for each request.

There are positive aspects in modsecurity, but if you have a huge ruleset or somehow misconfigure it, it can come back and bite you in the ass. But in the end it's a really nice tool that helps you securing your server.

If you're interested in modsecurity you might want to check the following links:

• ModSecurity
• Security webservices with ModSecurity
• ModSecurity Rule Generator
• Rule Reposity