问题
I have just anebled Mod Security on our Centos5 server and we are now getting the following in the error_log:
[Thu Nov 12 16:20:19 2015] [error] [client 88.15.76.8] ModSecurity: Access denied with code 403 (phase 2). Pattern match "([\\\\~\\\\!\\\\@\\\\#\\\\$\\\\%\\\\^\\\\&\\\\*\\\\(\\\\)\\\\-\\\\+\\\\=\\\\{\\\\}\\\\[\\\\]\\\\|\\\\:\\\\;\\"\\\\'\\\\\\xc2\\xb4\\\\\\xe2\\x80\\x99\\\\\\xe2\\x80\\x98\\\\`\\\\<\\\\>].*){8,}" at REQUEST_COOKIES:_eventqueue. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "169"] [id "981172"] [rev "2.2.5"] [msg "Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded"] [data "}"] [hostname "www.mydomain.com"] [uri "/company/geodis-uk-limited/general-maintenance-assistant-1485.html"] [unique_id "UbGaGB-esj8AAAa98bEAAAAn"]
What is the best way to stop this happening?
回答1:
ModSecurity rules need tweaking and tuning for your particular site before they are useful. The OWASP Core Rule Set you have installed is very useful but will show false positives and block legitimate traffic for all but the very simplest sites.
So first of all you should run in DetectionOnly mode for a few months before turning on the full blocking. During that time you should regularly check your alerts and fine tune the rules to address any false positives. DetectionOnly mode is enabled by using the following command in your config (it's probably set to On at present rather than DetectionOnly):
SecRuleEngine DetectionOnly
Now to look at your specific failure. This is due to rule 981172 which blocks any request with 8 or more "special characters" as they are often classic examples of SQL injection attacks (or more specifically attempts to mask a SQL injection attack).
This rule has blocked on cookie _eventqueue. So first question is: do you recognise that cookie and does it regularly have more than 8 special characters in a row? Certain fields and cookies will break this rule even for legitimate traffic. For example the current rule excludes checking any cookies beginning with __utm, or _pk_ref (used by Analytics software) as they often flag incorrectly.
Assuming this is legitimate traffic, the easiest option is to turn off this rule for this field by adding this config:
SecRuleUpdateTargetById 981172 !ARGS:'_eventqueue'
Note this config must be in the config after the rule it is disabling. Other ways of expressing this rule may be required before the rule is defined. So I normally add a "0_exceptions_before.conf" file and a 9999_exceptions_after.conf" file and fill in the exceptions into these files.
Adding exceptions like this is a lot better than editing the actual rule itself in the modsecurity_crs_41_sql_injection_attacks.conf file, since this then allows you to upgrade the rules to the latest version easily while still keeping your exceptions in place.
Talking of upgrading I notice you are on version 2.2.5 of the core rule set and the latest version in the v2 series is 2.2.9 so you probably should upgrade to the latest version if starting out afresh. Version 3 of the CRS is now the preferred version but it changes quite a few things (including rule ids) so takes a bit to upgrade to it. You should move to that but maybe get used to 2.2.9 first since you’ve started on that.
ModSecurity can be quite complicated to get your head around initially. I can highly recommend the ModSecurity Handbook, written by the original author of ModSecurity. It was a little out of date but has just published a second edition which brings it up to date again. It helps explain the program and how and why you need to tune it. First chapter (on installation) is free if you want to try it out. That book also contains the reference manual which is also available online for free. Finally the mod-security-users e-mail group and owasp-modsecurity-core-rule-set e-mail group are good places to get help too as there's not a huge amount on StackOverflow on the subject.
来源：https://stackoverflow.com/questions/33676348/extra-sensitive-mod-security-rules-giving-403-forbidden-error