Anything new to report here ?

Hey lmacken,

I have been really busy at work but next week I will create a template for everyone to review.

I am a little busy at the moment to produce a policy file.

Draft 0.1 for mod_security policy
rules.conf

this rules.conf file does very little. All it does is prevent users from seeing any defaced websites.

I think it would make more sense to run with SecRuleEngine DetectionOnly and a larger set of rules.

Hello everyone,

I've tried to create a rules-set based on default that reduce false positives:

http://athmane.fedorapeople.org/mod_sec-fi/

mod_security.conf: main config
mod_security.rules.conf: rules definitions
modsec_rules_test.sh: small shell script to test some rules.

Forgot to mention that I worked with:[[BR]]

mod_security-2.5.12-1.el5[[BR]]
httpd-2.2.3-45.el5.centos.1[[BR]]

AFAIK, there's two scenarios of deployment:[[BR]]

1. Deploy rules on each Apache httpd server.[[BR]]
2. Deploy rules in a new one (or two for redundancy) Apache httpd server reverse proxy (with mod_proxy) and pass request to other servers.[[BR]]

I forgot to remove meeting keyword, since we've already discussed about it

I can't fine any more recent info about this then the meeting of 09-06-2011 (http://meetbot.fedoraproject.org/fedora-meeting/2011-06-09/infrastructure.2011-06-09-19.00.log.txt).

Has there been any progress on this?

I think the question here was: What advantages does this give us? I guess it allows us to mitigate security bugs before there is a fix in packages?

Would someone care to make a case that this is needed? If not, I am inclined to just close it for now until there is some reasoning for it.

IIRC, we've raised the following points:

• Deploying mod_security will add a huge amount of time debugging false positives with our applications
• We should mitigate 0-day vuls in application layer.
• The generic free mod_security core rules (ASLv2.0) are very basic which can increase the number of false positives
• Application specific rules are not free.
• mod_security logs (audit and debug) are usually very big which may disturb our logging infrastructure.

Anyway, I'll be happy to help if we still interested in this (I'm the current maintainer mod_security and its core rules in fedora and epel)

Yeah, I am inclined to say lets skip it for now... until we come up with a more compelling use case, or the yummy vs trouble ratio changes a lot more to the yummy side. ;)