额外敏感的 Mod 安全规则给出 403 禁止错误 [英] Extra sensitive Mod Security rules giving 403 forbidden error
问题描述
我刚刚在 Centos5 服务器上取消了 Mod Security，我们现在在 error_log 中得到以下信息:
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?
推荐答案
ModSecurity 规则需要针对您的特定站点进行调整和调整，然后才能发挥作用.您安装的 OWASP 核心规则集非常有用，但将显示误报并阻止除最简单站点之外的所有站点的合法流量.
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.
因此，在开启完全阻塞之前，首先您应该在 DetectionOnly 模式下运行几个月.在此期间，您应该定期检查警报并微调规则以解决任何误报.DetectionOnly 模式通过在您的配置中使用以下命令启用(目前可能设置为 On 而不是 DetectionOnly):
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
现在来看看你的具体失败.这是因为规则 981172 会阻止任何具有 8 个或更多特殊字符"的请求，因为它们通常是 SQL 注入攻击(或更具体地说，试图掩盖 SQL 注入攻击)的经典示例.
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).
此规则已阻止 cookie _eventqueue.所以第一个问题是:你认识那个 cookie 吗?它是否经常连续有 8 个以上的特殊字符?即使对于合法流量，某些字段和 cookie 也会破坏此规则.例如，当前规则不包括检查以 __utm 或 _pk_ref(由 Analytics 软件使用)开头的任何 cookie，因为它们经常标记不正确.
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'
注意这个配置必须在配置中在它禁用的规则之后.在定义规则之前，可能需要其他方式来表达此规则.所以我通常会添加一个0_exceptions_before.conf"文件和一个9999_exceptions_after.conf"文件，并将例外情况填入这些文件中.
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.
像这样添加例外比在 modsecurity_crs_41_sql_injection_attacks.conf 文件中编辑实际规则本身要好得多，因为这样您就可以轻松地将规则升级到最新版本，同时仍然保留例外.
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.
谈到升级，我注意到您使用的是核心规则集的 2.2.5 版本，而 v2 系列中的最新版本是 2.2.9，因此如果重新开始，您可能应该升级到最新版本.CRS 的第 3 版现在是首选版本，但它更改了很多内容(包括规则 ID)，因此升级到它需要一点时间.您应该转向那个，但也许在您开始使用 2.2.9 之后就先习惯了.
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 最初可能会非常复杂.我强烈推荐由 ModSecurity 的原作者编写的 ModSecurity 手册.它有点过时，但刚刚出版了第二版，使其再次更新.它有助于解释程序以及您需要调整它的方式和原因.如果您想尝试一下，第一章(关于安装)是免费的.该书还包含参考手册，也可免费在线获取.最后是 mod-security-users 电子邮件组和
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.
这篇关于额外敏感的 Mod 安全规则给出 403 禁止错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
