不正なロボットに対処するための戦術

規制上の理由で、インデックスに登録されない、または自動的に検索されないサイトがあります。これは、すべてのロボットを遠ざけ、サイトをスパイダーで防ぐ必要があることを意味します。

明らかに、最初からすべてを許可しないrobots.txtファイルがあります。ただし、robots.txtファイルの監視は、正常に動作するロボットだけが行うことです。最近、動作の悪いロボットにいくつかの問題がありました。いくつかのユーザーエージェントを禁止するようにApacheを構成しましたが、それを回避するのは非常に簡単です。

それで、問題は、ロボットのような動作を検出して応答するように（おそらくいくつかのモジュールをインストールすることによって）Apacheを構成するいくつかの方法がありますか？他のアイデアは？

現時点で私ができることは、ログの手動検査に基づいてIPアドレスを禁止することだけであり、これは単に実行可能な長期戦略ではありません。

隠しページにリンクして、訪問したときにボットのユーザーエージェントとIPアドレスをキャプチャし、それらの一方または両方を.htaccessファイルに追加して永続的にブロックすることができます。自動化されているため、メンテナンスのために何もする必要はありません。

Project HoneypotのIPブラックリストとインターフェースするApacheモジュールを使用することにより、他の人々が悪いIPを特定するのに行った仕事に便乗することができます。これを大規模に実行している場合、ハニーポットを実行することを提案するのはおそらく礼儀正しいでしょう。

Gisle Hannemyr がコメントで述べたように、これを行う最善の方法は、すべてのユーザーのログインを要求し、ログインしていないユーザーに制限されたコンテンツを提供しないことです。

何らかの理由でログインを要求できない場合でも、いくつかのフォールバックを使用できます（免責事項：どちらも部分的または完全に私の責任です）：

1. OWASP ModSecurityはコアルールセットは、ボットは、（例えばそのUser-Agent文字列を偽造）ブラウザとして自分自身を偽装するための措置を講じている場合でも、自動化を検出するように設計ルールの数が含まれています。VPS、専用サーバーなどのサーバーを完全に制御している場合は、これらのルールをModSecurityで使用できます。

   このルールセットには、さまざまな不適切なアクティビティを停止するための他のルールも含まれています。あなたがそれを見ていないなら、あなたは間違いなくそうするべきです。

2. サーバーを完全に制御していない場合（つまり、共有Webホスティングを使用している場合）、ホストで独自のModSecurityルールの使用が許可されていない場合は、アプリケーションレベルで、独自のBadなどを試すことができます。行動。私はこのプロジェクトを2005年に開始し、ブログのスパムや、ユーザーに関係するようなコンテンツスクレイパーと戦っています。PHPベースのWebサイトに追加できます。

   また、Bad Behaviorのルールの多くはModSecurityコアルールセットに組み込まれているため、これらのルールを有効にしておけば、両方を実行するのはかなり冗長になります。これらのルールは、不正な動作に起因するものとしてコアルールセットで注釈が付けられています。