问题
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?
回答1:
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.
😄
回答2:
Kully has some good points, and I definitely recommend the ModSecurity Handbook too. I would say switching to anomaly mode does take some getting used to and takes an extra effort in monitoring in my opinion so personally I prefer to run in blocking mode and to turn off noisy rules.
You really do need to run in DetectionOnly mode and tune the CRS rules before they become useful and this does take time. It was several months of iterations before I felt comfortable enough to switch it on to blocking mode.
The SQL Injection rules in particular are very prone to over alerting.
Below are some of the CRS v2 common rules you may wish to switch off or tweak - especially in traditional alerting mode:
#Lots of browsers don't send accept header so disable rule 960015 which blocks that:
SecRuleRemoveById 960015
#ModSecurity does not handle gzip files and falsely alerts code leakage for such binary files so disable this rule
SecRuleRemoveById 970903
#Range header is set by some Android devices so ignore that rule
SecRuleRemoveById 958291
#We allow Google Tag Manager which uses small iframe so disable the rules that disallow small iframes:
SecRuleRemoveById 981000
SecRuleRemoveById 981001
#These produce many false positives as checking for things like lots of spaces and ' characters (valid in names and addresses). So disable.
SecRuleRemoveById 950109
SecRuleRemoveById 950901
SecRuleRemoveById 960024
SecRuleRemoveById 973338
SecRuleRemoveById 981172
SecRuleRemoveById 981173
SecRuleRemoveById 981231
SecRuleRemoveById 981242
SecRuleRemoveById 981243
SecRuleRemoveById 981245
SecRuleRemoveById 981246
SecRuleRemoveById 981248
SecRuleRemoveById 981257
SecRuleRemoveById 981260
SecRuleRemoveById 981318
SecRuleRemoveById 981319
SecRuleRemoveById 981320
#Allow Search argument (q) to include SQL words:
SecRuleUpdateTargetById 959071 !ARGS:'q'
SecRuleUpdateTargetById 959072 !ARGS:'q'
SecRuleUpdateTargetById 981247 !ARGS:'q'
#Passwords can (and arguable should!) contain special chars
SecRuleUpdateTargetById 950010 !ARGS:'/[pP](ass)?word/'
SecRuleUpdateTargetById 981240 !ARGS:'/[pP](ass)?word/'
#Email address can contain some SQL injection phrases
SecRuleUpdateTargetById 981241 !ARGS:'/[eE](-)?mail/'
#Remove checking of rules which checks for http calls in arguments will have URLs in them
SecRuleUpdateTargetById 950007 !ARGS:'utm_referrer'
SecRuleUpdateTargetById 950120 !ARGS:'utm_referrer'
SecRuleUpdateTargetById 973304 !ARGS:'utm_referrer'
SecRuleUpdateTargetById 981241 !ARGS:'utm_referrer'
SecRuleUpdateTargetById 981256 !ARGS:'utm_referrer'
CRS v3 went through a rule id renumbering, and some rules were removed, so the v3 equivalents of the above are given below:
#Lots of browsers don't send accept header so disable rule 920300 which blocks that:
SecRuleRemoveById 920300
#These produce many false positives as checking for things like lots of spaces and ' characters (valid in names and addresses). So disable.
SecRuleRemoveById 920230
SecRuleRemoveById 942130
SecRuleRemoveById 942460
SecRuleRemoveById 941140
SecRuleRemoveById 942420
SecRuleRemoveById 942430
SecRuleRemoveById 942440
SecRuleRemoveById 942330
SecRuleRemoveById 942370
SecRuleRemoveById 942260
SecRuleRemoveById 942340
SecRuleRemoveById 942210
SecRuleRemoveById 942200
SecRuleRemoveById 942450
SecRuleRemoveById 942110
SecRuleRemoveById 942120
SecRuleRemoveById 942140
#Allow Search argument (q) to include SQL words:
SecRuleUpdateTargetById 942390 !ARGS:'q'
SecRuleUpdateTargetById 942400 !ARGS:'q'
SecRuleUpdateTargetById 942360 !ARGS:'q'
#Passwords can (and arguable should!) contain special chars
SecRuleUpdateTargetById 942300 !ARGS:'/[pP](ass)?word/'
#Email address can contain some SQL injection phrases
SecRuleUpdateTargetById 942230 !ARGS:'/[eE](-)?mail/'
#Remove checking of rules which checks for http calls in arguments will have URLs in them
SecRuleUpdateTargetById 931130 !ARGS:'utm_referrer'
SecRuleUpdateTargetById 942230 !ARGS:'utm_referrer'
SecRuleUpdateTargetById 942250 !ARGS:'utm_referrer'
Of course turning off these rules completely (like I've done in first half of above code snippet) will reduce the effectiveness of ModSecurity so you need to decide if this is right for your website.
Turning off the rules for particular arguments (like I've done in second half of above code snippet) is usually preferred, but again only you can decide if those arguments don't require the protection the rule gives.
回答3:
here is what we are using from below (https://stackoverflow.com/a/34027786/1008215) for our wordpress modsec config.
SecRuleRemoveById 950109
SecRuleRemoveById 950120
SecRuleRemoveById 950901
SecRuleRemoveById 960008
SecRuleRemoveById 960015
SecRuleRemoveById 973338
SecRuleRemoveById 981242
SecRuleRemoveById 981243
SecRuleRemoveById 981245
SecRuleRemoveById 981246
SecRuleRemoveById 981248
SecRuleRemoveById 981257
SecRuleRemoveById 981319
SecRuleRemoveById 981320
来源：https://stackoverflow.com/questions/33989273/modsecurity-excessive-false-positives