mod_security hasn't been updated in a while. This is my ebuild for 2.9.1 which I'm uploading for the use of anyone who wants to use it. I've used the 2.7.7 as a starting point. With reference to bug 518828, I've changed the following: 1) included the modsecurity.conf-recommended as the /etc/modsecurity/modsecurity.conf file 2) Increased the PCRE limits to 10,000 from 1,000 3) Added new configure options which _should_ work (not fully tested) with respect to Bug 605496, the files in /var/cache/modsecurity should persist across reboots, so unless there's another place to put the files, that seems the best place. Reproducible: Always
Created attachment 469754 [details] mod_security-2.9.1.ebuild
Created attachment 469756 [details] files/modsecurity-2.9.conf
I've the associated ebuild for modsecurity-crs, which I'll include in another bug.
I just committed mod_security-2.9.1 with a mixture of suggestions from here and bug 518828. Can you please give that a try to see if it at least works? Then we can work on polishing it up.
Hi. I've installed this on my test server, and this is my initial feedback. The ebuild doesn't install /etc/modsecurity/modsecurity.conf. I'm not sure if this is the best options as personally I'd expect the file to be in place for ease of setup. You'd have to move the copy of the recommended modsecurity.conf file out of the doc folder. The installed /etc/apache2/modules.d/79_mod_security.conf doesn't "Include /etc/modsecurity/modsecurity.conf " so the main config would be missing. Defining "SecDataDir" within /etc/apache2/modules.d/79_mod_security.conf might conflict with the value in the /usr/share/doc/mod_security-2.9.1/modsecurity.conf-recommended.bz2 if it isn't handled properly. Personally, I'd expect that value to be set in the main modsecurity.conf file rather than being overwritten. This is a personal choice though. Having geoip enabled as a USE vaiable, I'd expect the SecGeoLookupDb value to be set for me, rather than having to enable it in the file. I am not a writer of ebuilds, so I acknowledge that the observations I make may not have merit. :) Cheers, Graham.
(In reply to Graham E from comment #5) > > The ebuild doesn't install /etc/modsecurity/modsecurity.conf. I'm not sure > if this is the best options as personally I'd expect the file to be in place > for ease of setup. You'd have to move the copy of the recommended > modsecurity.conf file out of the doc folder. > > The installed /etc/apache2/modules.d/79_mod_security.conf doesn't "Include > /etc/modsecurity/modsecurity.conf " so the main config would be missing. > In Gentoo, 79_mod_security.conf *is* your main modsecurity configuration file -- there's no need to introduce the additional /etc/modsecurity/modsecurity.conf. The modsecurity docs only suggest an "Include" because they don't know anything about your Apache configuration; ours is already modular =) The question is then, why don't we include the recommended settings in 79_mod_security.conf by default? Well... There are a few things that we like to guarantee. The first is that the default configuration should be functional (i.e. not crash) for everyone. In that respect, the main contribution of our config file is to follow upstream's default and do nothing at all unless you tell it to. There are also a number of recommended settings that might not work out-of-the-box, like the ones that rely on the JSON parsing. Then there are others that use a lot of resources, or that set (possibly inappropriate) file/memory size limits. I think the safest thing for us to do is to leave these at their defaults, and let people configure them on their own if wanted. Many of the recommended settings are also present by default. If you check https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual then you'll find that many of the recommended settings are actually the default. You can get up and running by adding only SecRuleEngine DetectionOnly to your 79_mod_security.conf. Personally, I generally agree with the philosophy in https://www.feistyduck.com/library/modsecurity-handbook-free/online/ch03-configuration.html that it's better to read about the options and add them to your configuration one-at-a-time... > Defining "SecDataDir" within /etc/apache2/modules.d/79_mod_security.conf > might conflict with the value in the > /usr/share/doc/mod_security-2.9.1/modsecurity.conf-recommended.bz2 if it > isn't handled properly. Personally, I'd expect that value to be set in the > main modsecurity.conf file rather than being overwritten. This is a personal > choice though. ...The only exceptions to that are the settings where the defaults are wrong or insecure. SecDataDir is one such case: the default of /tmp is insecure, and we have a better place for it (under /var/lib/modsecurity, which we create with safer permissions). In that same vein, I've added SecTmpDir and SecUploadDir to our default configuration, because otherwise they also use /tmp and have the same problem. > Having geoip enabled as a USE vaiable, I'd expect the SecGeoLookupDb value > to be set for me, rather than having to enable it in the file. This actually doesn't work out-of-the-box. Installing geoip doesn't install the database, so to prevent mod_security from crashing, I think it's better to leave this up to the user like all of the other settings. Once you know which database you want and where it's located, you can configure it yourself and portage won't mess with it.
Hi. If the 79_mod_security.conf is the main configuration file, I would expect the default config file to be included within that file. Yes, all of the default options are normally untouched, but I'd expect all the options and a brief description to be contained within that file. I would expect that in any config file that was included would include standard options so I can easily scan over the options. Why would I be expected to add "SecRuleEngine DetectionOnly" to the config file to make it work out of the box, when this obviously isn't then the case. Remember that I have also to enable "-DSECURITY" within the apache config file to enable mod security -- I wouldn't then expect to have to read through other documentation to get it running. The first time I installed mod_security I enabled the SECURITY engine, restarted apache and as there were no errors, I expected it to work. Many months later I eventually discovered that the default config was not actually enabling mod_security, and I had to wade through a raft of documentation before I eventually had a functioning mod_security enable browser. This is hardly (to my mind) the best option. <Quote> ...that it's better to read about the options and add them to your configuration one-at-a-time... </Quote> I guess we'll have to disagree about this. I'd rather the options were in the default config file, with a brief description, then I can alter them one at a time. I can investigate further if required. I concur regarding the geoip, as I'd forgotten that the databases aren't installed by default. As long as the option is clear at the end of the install, and clearly documented in the config file what is needed to enable geoip. Cheers, Graham.
(In reply to Graham E from comment #7) > .... documentation before I eventually had a functioning mod_security enable > browser. Meant to say mod_security enabled web server. :(
Maybe we don't disagree so much after all. If all you want is to have the configuration options listed along with their descriptions in config file, then I agree that that would be really convenient. But, it does take a lot of manpower that we just don't have right now (mod_security is still unmaintained after my version bump). Essentially we would be copy/pasting the upstream config into ours. The problem is then that with every version bump, you have to check for new and obsolete changes to the config file upstream -- otherwise the one in Gentoo will get out of date and potentially create problems. We've been bit by this in the past; see e.g. bug #538822. It can still be done of course, but whoever is going to be doing the version bumps (the maintainer, usually) needs to know about it and be willing to put in the work. Since mod_security is unmaintained, I don't want to set something up that's going to discourage a future maintainer. And honestly, if I'm the one doing the bumps in the future, I don't want to have to dig through changelogs or diff output every time to update our config file. Since I don't use mod_security, my investment is low, sorry =) If someone picks this up in the future as a full-time maintainer, it would be appropriate to ask him or her to include the upstream config, and then leave the decision up to him or her.
