☰

mod_security 960015 阻止 Google 和其他良好机器人

tag-icon • tag-icon apache-2.2 security mod-security
mod_security 960015 阻止 Google 和其他良好机器人

mod_security 规则 960015 不断捕获 Google 和其他好机器人。我在 vhost 中设置了以下内容，以防止捕获好机器人：

SecRule REQUEST_HEADERS:User-Agent "Mail.ru" log,allow
SecRule HTTP_USER_AGENT "Mail.RU_Bot" log,allow

Google 和 Yandex 也同样如此。

它 99％ 的时间都有效，但是由于一些非常奇怪的原因，其他时候也会失败，以下是 Mail.ru 机器人的日志示例：

成功：

217.69.134.79 - - [07/Mar/2014:10:17:13 +0400] "GET / HTTP/1.1" 200 189934 "-"
"Mozilla/5.0 (compatible; Linux x86_64; Mail.RU_Bot/Fast/2.0; 
+http://go.mail.ru/help/robots)"

[Fri Mar 07 10:17:13 2014] [error] [client 217.69.134.79] ModSecurity: Access 
allowed (phase 2). Pattern match "Mail" at REQUEST_HEADERS:User-Agent. 
[file "/etc/apache2/sites-enabled/xxx"] [line "28"] [hostname "xxx"] 
[uri "/"] [unique_id "UxlkaQp-d4EAABU9BSIAAAAV"]

但下一分钟它就失败了：

217.69.134.79 - - [08/Mar/2014:02:14:19 +0400] "GET / HTTP/1.1" 403 389 "-" "
Mozilla/5.0 (compatible; Linux x86_64; Mail.RU_Bot/2.0; +http://go.mail.ru/
help/robots)"

[Sat Mar 08 02:14:19 2014] [error] [client 217.69.134.79] ModSecurity: Access 
denied with code 403 (phase 2). Operator EQ matched 0 at REQUEST_HEADERS. 
[file "/usr/share/modsecurity-crs/activated_rules/
modsecurity_crs_21_protocol_anomalies.conf"] [line "47"] [id "960015"] 
[rev "2.2.5"] [msg "Request Missing an Accept Header"] [severity "CRITICAL"] 
[tag "PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] 
[tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "xxx"] [uri "/"] 
[unique_id "UxpEuwp-d4EAAEMnBFQAAAAE"]

我知道正确的方法是进行反向查找，但是它们会减慢网站速度，我希望至少有一些安全性，但目前无法使用 960015，因为它会阻止 Google 和其他网站。同时，这是一条非常有用的规则，可以捕获数百个恶意机器人。

如果有人知道如何设置反向查找，并真正发挥作用，让 Google 和其他优秀的机器人进行索引 - 欢迎您在此处发帖。不过，我现在也在寻找一种快速而粗糙的解决方案来让它发挥作用，因为有些安全性总比没有安全性好。

答案1

首先声明：我是不良行为，一款类似的产品，ModSecurity 的一些核心规则源自 Bad Behavior。

RFC 2616 规定，所有请求中都应包含 Accept 标头。请注意，这并不是绝对要求，因此即使用户代理未发送此标头，它仍是有条件合规的（如 RFC 中所定义）。

拒绝没有 Accept 标头的请求的理由是，所有常规 Web 浏览器都会发送标头，而许多机器人不会。但在实践中，在看到数百万个请求后，一些“好”机器人也不会发送 Accept 标头。因此，此规则并不完美，确实会产生误报。

除非请求是 POST 请求，否则 Bad Behavior 不会阻止这些请求。这可以减少垃圾邮件并将误报率降低到大约为零，但仍会通过其他机器人。根据我的经验，其中许多机器人无论如何都会被其他规则捕获。

在你的情况下，我只会禁用此规则。它并没有像你想象的那样给你带来好处。如果你愿意，你可以修改它，使其仅适用于 POST 请求。

答案2

这是一条符合目的的修改后的规则，现已运行了 48 小时，Google 和其他公司工作正常，而坏人仍然会被抓住，哇哦！

将其添加到有问题的虚拟主机：

SecRule REQUEST_HEADERS:User-Agent "Google|Mail|Yandex" "phase:1,t:none,pass,nolog,ctl:ruleRemoveById=960015"

2015 年更新了最新情况 - 诈骗者已经变得聪明了，现在大多发送假装是 Google 的虚假标头，需要不同的安全策略。

相关内容