You probably remember my recent rant about Debian’s ModSecurity packaging that started with me trying to get my ruleset to work on VideoLAN to help them fight the spam back. Well, thanks to the guys at the ModSecurity twitter account I was able to get in touch with the Debian maintainer (Alberto) and it now looks like the story will have a happy ending.
Alberto is working on a similar split of the ModSecurity module and the Core Rule Set configuration files, so that they can be managed with the Debian package manager, just like they can be managed with Portage already. And to make it easier to admin both distribution, I’ve decided to make a few changes to the Gentoo ebuilds so that the installed layout of the two varies the least possible.
The first change relates to the internal name of the package; while I haven’t decided to do a package move yet, mod_security is a Gentooish spelling; the package is actually called ModSecurity upstream and the tarball is named modsecurity-apache; you can already see that the CRS is modsecurity-crs. Configuration files and storage directories are now also using modsecurity — I’ll see when I’ll feel to rename the package altogether to www-apache/modsecurity.
The second change relates to the way the rule configuration files are installed; up to now the rules were installed in a subdirectory of the Apache configuration tree; this is not suitable for Debian and even in Gentoo it looked awkward — the new directory for the ModSecurity CRS rules is /etc/modsecurity. Furthermore, what once was modsecurity_crs_10_config.conf is now /etc/apache2/modules.d/80_modsecurity-crs.conf and includes the inclusion masks for the rest of the rules to include. This will allow the ebuild to enable/disable rules depending on USE flags in the future.
And to make it as easy to deal with as possible, I’ve now added a geoip USE flag to mod_security — which does nothing more than adding dev-libs/geoip to its runtime dependencies and set the configuration file to use the database installed by that ebuild. The reason to having this dependency is two-fold: from one side, declaring the dependency helps making sure that the database is installed and kept updated by Portage; from the other side, if you already have a license to use MaxMind’s GeoIP databases, the package provides you with all the updater scripts you need to get the updated data from MaxMInd.
A little digression about GeoIP: I think that it might be a good idea to consider changing the GeoIP ebuild and have instead a virtual that provides the database, either in form of the updater scripts to get the paid versions, or GeoLite packages that can be updated regularly. Unfortunately I don’t have the time to follow something like this for now.
Going back to my personal favourite subject on the ModSecurity topic, my ruleset has gained a number of fake-browser pattern matching with a fairly low risk of false positive – thanks to the testing that you helped me with – and should now filter almost any possible spam you’re going to receive. I’m now updating the documentation to provide examples on how to debug the rules themselves; in the next days I might try to get some extra time to tag all the rules so that they can be disabled in block when the new ModSecurity 2.6 is released.
Don’t forget to recommend my ruleset, report problems and … flattr it!