I've just set up Apache modsecurity on a server, and in principle it works well, but I am getting rather a lot of false positives.
I'm using the OWASP ModSecurity Core Rule Set (CRS), essentially "out of the box".
I'm running in "self-contained" (traditional) mode rather than Collaborative (anomaly) mode:
SecDefaultAction "phase:1,deny,log"
SecDefaultAction "phase:2,deny,log"
Of particular concern is the SQL injection set. Double pipes (||) double angle brackets (>>) and a whole slew of other input will trigger the rule and cause the page to be blocked. Many of these could easily appear in legitimate user input.
Is there a graceful way to selectively allow common input that is not necessarily indicative of an injection attack through? I know I'm currently running out of the box, but surely blocking double pipes and angle brackets would be far too strict for almost every use case?
The very first thing to do is to switch to anomaly scoring rather than setting the default action to Deny, this will really cut down on the number of false +ves you get.
Second, switch to DetectionOnly mode and leave it running for a few days, you'll get an idea of what to address.
For each false positive consider:
- Modifying the application source
- Disabling that specific rule
- Disabling modsec for that argument, URL, &c. If you know there is protection in the application code.
The Ivan Ristic ModSecurity book is getting on a bit now but is the best resource for really getting down and tailoring modsec for the application that sits behind it, unfortunately it has a crap index so I recommend an electronic version that you can search.
It's a shame there are Sao many hidden tricks in modsec that you have to find one-by-one, by either looking at the source code, chancing upon a little text box in the book or through turning up the debug level to 5 and seeing what modsec was actually doing.