Modsecurity: Excessive false positives

前端 未结 3 1375
刺人心
刺人心 2020-12-10 21:06

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 ModSecur

相关标签:
3条回答
  • 2020-12-10 21:42

    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
    
    0 讨论(0)
  • 2020-12-10 21:49

    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.

    0 讨论(0)
  • 2020-12-10 21:50

    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.

    0 讨论(0)
提交回复
热议问题