Uncategorized

Mod_security :: upgrading from 1.x to 2.x (part 1)

Portage has official made mod_security (http://www.modsecurity.org) 2.1.1 stable! This is great since the official releases of 2.x have been out for a long, long time. With this jump, there are some issues to contend with. Jumping from 1.x to 2.x releases involves some major configuration modification, but is aided with a conversion matrix document. Basically every rule and configuration option have changed with this release. I’ll be documenting my upgrade procedures in the next mod_security blog post. I want to verify that changes are working correctly first before posting.

For those that do not know what mod_security is or what mod_security can offer you, here is a rough interpretation of what mod_security does. Mod_security is basically a application firewall that sits in front of Apache requests. It analyzes every request to Apache and depending on rules (defined using regular expressions) certain handling can happen. You can block requests and present a 403 (or other error code), or you can let it pass but log the request. Mod_security has fantastic logging with it’s audit_log (now modsec_audit.log) where all payload and packet information is stored about the request.

Portage has official made mod_security (http://www.modsecurity.org) 2.1.1 stable! This is great since the official releases of 2.x have been out for a long, long time. With this jump, there are some issues to contend with. Jumping from 1.x to 2.x releases involves some major configuration modification, but is aided with a conversion matrix document. Basically every rule and configuration option have changed with this release. I’ll be documenting my upgrade procedures in the next mod_security blog post. I want to verify that changes are working correctly first before posting.

For those that do not know what mod_security is or what mod_security can offer you, here is a rough interpretation of what mod_security does. Mod_security is basically a application firewall that sits in front of Apache requests. It analyzes every request to Apache and depending on rules (defined using regular expressions) certain handling can happen. You can block requests and present a 403 (or other error code), or you can let it pass but log the request. Mod_security has fantastic logging with it’s audit_log (now modsec_audit.log) where all payload and packet information is stored about the request.

Along with providing rule handing, it also provides additional ‘hardening’ features. For example, you can change your ServerSignature, chroot the apache process and include upload file approver handling. Some will argue that it doesn’t offer complete protection and the rules can be bypassed (by modifying your request, etc). I agree, but to be able to provide additional layers of security is not a bad thing. What I find is great with mod_security is stopping automated script attacks and probes. Also, it’s great for managing comment/forum spam as well as CC/BCC header injection attacks. Additional rules can be created (custom) and some greatrule setss can be downloaded from GotRoot.com.

I believe using mod_security could be a great tool on your server… and it’s definitely worth checking it out. Current release (in portage) is net-www/mod_security-2.1.1