mod_securityルール960015は、Googleやその他の優れたボットをキャッチし続けます。良いボットが捕まえられるのを防ぐために、仮想ホストには次のものがあります。
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"]
逆引きを行うのが適切な方法であることはわかっていますが、Webサイトの速度が低下し、少なくともある程度のセキュリティが必要ですが、現時点では、Googleなどをブロックするため960015を使用できません。同時に、何百もの悪いボットを捕まえたのは非常に便利なルールです。
誰かが実際に機能し、Googleや他の優れたボットがインデックスを作成できるようにする逆ルックアップを設定する方法を知っている場合は、ここに投稿してください。ただし、一部のセキュリティはセキュリティがないよりも優れているため、今すぐ機能させるための迅速で汚い解決策も探しています。
最初の免責事項:私は同様の製品である Bad Behavior の作成者であり、ModSecurityコアルールの一部はBadBehaviorから派生しています。
RFC 2616は、Acceptヘッダーがすべての要求に存在する必要があると述べています。これは絶対的な要件ではないため、このヘッダーを送信しない場合でも、ユーザーエージェントは条件付きで準拠しています(RFCで定義されています)。
Acceptヘッダーなしでリクエストを拒否する理由は、すべての通常のWebブラウザーがヘッダーを送信するのに対し、多くのボットは送信しないということです。ただし、実際には、何百万ものリクエストを確認した後、一部の「優れた」ボットはAcceptヘッダーも送信しません。したがって、このルールは完全ではなく、誤検知を生成します。
リクエストがPOSTリクエストでない限り、不正な動作はこれらをブロックしません。これにより、スパムが削減され、誤検知がほぼゼロになりますが、他のボットは通過します。私の経験では、これらの多くはとにかく他のルールに捕まりました。
あなたの状況では、私はこのルールを無効にします。それはあなたが思っているほどあなたを買っていない。必要に応じて、POSTリクエストにのみ適用されるように変更できます。
これは目的に合った変更されたルールで、現在48時間実行されています。グーグルなどは問題なく動作しますが、悪者はまだ捕まります。
これを問題の仮想ホストに追加します。
SecRule REQUEST_HEADERS:User-Agent "Google|Mail|Yandex" "phase:1,t:none,pass,nolog,ctl:ruleRemoveById=960015"
2015年の最新の状況での更新-詐欺師は目を覚まし、現在はほとんどがGoogleを装った偽のヘッダーを送信しており、さまざまなセキュリティ戦略が必要です。