私はウェブサイトを開発していて、人々が私のデータをスクレイピングすることに敏感です。1 ページまたは 2 ページをスクレイピングすることについては心配していません。数千ページをスクレイピングすることについては、そのデータの集合体の方が小さなパーセンテージよりもはるかに価値があるため、より懸念しています。
単一の IP アドレスからの大量のトラフィックに基づいてユーザーをブロックする戦略を想像することはできますが、Tor ネットワークは多くの回路をセットアップします。つまり、単一のユーザーのトラフィックが時間の経過とともに異なる IP アドレスから来ているように見えます。
Firefox 拡張機能を使用してVidaliaをインストールしたときに、google.com からキャプチャが表示されたので、Tor トラフィックを検出できることはわかっています。
では、どうすればそのようなリクエストを検出できますか?
(私の Web サイトは ASP.NET MVC 2 ですが、ここで使用されるアプローチは言語に依存しないと思います)
私はウェブサイトを開発しており、人々が私のデータをスクレイピングすることに敏感です
気にしないで。それがウェブ上にあり、誰かがそれを欲しがっている場合、彼らがそれを手に入れるのを止めることは不可能です. 制限を設ければ加えるほど、正当なユーザーのユーザー エクスペリエンスを台無しにするリスクが高まります。また、コードの保守が難しくなります。
将来の回答が提案するアイデアへの対策を投稿します。
Tor Exit Nodesのリストに対して IP アドレスを確認できます。あなたのサイトのスクレイピングに興味を持っている人にとって、これは速度を落とすことにはならないことを私は知っています。Tor は遅すぎるため、ほとんどのスクレイパーはそれを考慮しません。簡単にスキャンしたり、リストを購入したりできる、何万ものオープン プロキシ サーバーがあります。プロキシサーバーは、リクエストの上限に達した場合にスレッド化またはローテーションできるため、優れています。
Google は tor ユーザーに悪用されており、ほとんどの出口ノードは Google のブラック リストに載っているため、キャプチャを取得しています。
完全に明確にさせてください: 誰かがあなたのサイトをスクレイピングするのを防ぐためにできることは何もありません.
tor ネットワーク コンポーネントの設計により、受信者は、リクエスタが元の送信元なのか、単に中継されたリクエストなのかを判断できません。
Google で見られた動作は、おそらく別のセキュリティ対策が原因でした。Google は、ログインしているユーザーが IP を変更したかどうかを検出し、万が一の場合に備えてキャプチャを提示して、有害な傍受を防ぎ、認証されたユーザーが実際に IP を変更した場合 (ISP への再ログオンなどによって) セッションの継続を許可します。
断固として技術に精通したユーザーが Web サイトをスクレイピングするのを防ぐことは「不可能」であることに焦点を当てることは、あまりにも重要なことだと思います。@Drew Noakes は、この Web サイトには、総合すると何らかの「価値」を持つ情報が含まれていると述べています。Web サイトに、制約のない匿名ユーザーが簡単にアクセスできる集計データがある場合、はい、スクレイピングを防止することは「不可能」に近い可能性があります。
解決すべき問題は、ユーザーが集計データをスクレイピングするのを防ぐ方法ではなく、パブリック アクセスから集計データを削除するためにどのようなアプローチを使用できるかということです。これにより、「不可能」を行う必要なくスクレーパーのターゲットを排除し、廃棄を防ぎます。
集計データは、企業独自の情報と同様に扱う必要があります。一般に、会社の専有情報は、匿名ユーザーが集計または生の形式で公開することはできません。貴重なデータの取得を防ぐための解決策は、データへのアクセスを制限および制限することであり、ユーザーに提示されたときにデータが破棄されるのを防ぐことではないと私は主張します.
1] ユーザー アカウント/アクセス – 特定の期間内にすべてのデータにアクセスすることはできません (データ/ドメイン固有)。ユーザーは自分に関連するデータにアクセスできる必要がありますが、質問から明らかなように、すべての集計データを照会する正当な目的を持つユーザーはいません。サイトの詳細を知らずに、正当なユーザーが一定期間内にデータの小さなサブセットしか必要としないのではないかと思います。通常のユーザーのニーズを大幅に超えるリクエストは、ブロックするか、代わりに調整する必要があります。これにより、スクレイピングに非常に時間がかかり、破棄されたデータが古くなる可能性があります。
2] 運用チームは、大規模な分散システムや複雑なシステムが正常であることを確認するために、メトリックを監視することがよくあります。残念なことに、散発的または断続的な問題の原因を特定することは非常に難しくなり、通常の運用変動とは対照的に、問題があることを特定することさえ困難になることがよくあります。運用チームは多くの場合、多くのメトリックから取得した統計分析された履歴データを処理し、それらを現在の値と比較して、システムの稼働時間、負荷、CPU 使用率など、システムの正常性の重大な偏差を特定するのに役立てます。
同様に、標準よりも大幅に多い量のデータを求めるユーザーからの要求は、データを廃棄している可能性が高い個人を特定するのに役立ちます。このようなアプローチは自動化することもできますし、さらに拡張して、廃棄を示すパターンを複数のアカウントから探すこともできます。ユーザー 1 が 10% をスクレイピングし、ユーザー 2 が次の 10% をスクレイピングし、ユーザー 3 が次の 10% をスクレイピングする、など。複数のアカウント
3] エンドユーザーが生の集計データに直接アクセスできるようにしないでください。ここでは詳細が重要ですが、簡単に言えば、データはバックエンド サーバーに存在し、ドメイン固有の API を使用して取得する必要があります。繰り返しますが、生データを提供するだけでなく、データのサブセットに対するユーザー要求に応答していると想定しています。たとえば、あるデータが特定の地域の詳細な人口統計である場合、正当なエンド ユーザーはそのデータのサブセットのみに関心があります。たとえば、エンド ユーザーは、両親と一緒に集合住宅に住んでいる 10 代の子供がいる世帯の住所や、特定の市や郡のデータを知りたい場合があります。このような要求では、集約データを処理して、エンド ユーザーが関心を持つ結果のデータ セットを生成する必要があります。入力クエリの多数の潜在的な順列から取得されたすべての結果データセットをスクレイピングし、集計データ全体を再構築することは非常に困難です。スクレイパーは、リクエスト数/時間、結果のデータセットの合計データサイズ、およびその他の潜在的なマーカーを考慮して、Web サイトのセキュリティによっても制約されます。ドメイン固有の知識を組み込んだ十分に開発された API は、API がその目的を果たすのに十分なほど包括的でありながら、大量の生データ ダンプを返すほど一般的になりすぎないようにするために重要です。結果のデータセットの合計データサイズ、およびその他の潜在的なマーカー。ドメイン固有の知識を組み込んだ十分に開発された API は、API がその目的を果たすのに十分なほど包括的でありながら、大量の生データ ダンプを返すほど一般的になりすぎないようにするために重要です。結果のデータセットの合計データサイズ、およびその他の潜在的なマーカー。ドメイン固有の知識を組み込んだ十分に開発された API は、API がその目的を果たすのに十分なほど包括的でありながら、大量の生データ ダンプを返すほど一般的になりすぎないようにするために重要です。
サイトへのユーザー アカウントの組み込み、ユーザーの使用ベースラインの確立、典型的な使用パターンから大幅に逸脱したユーザーの特定と制限 (またはその他の緩和アプローチ)、および処理済み/消化済みの結果を要求するためのインターフェイスの作成セット (生の集計データに対して) は、データを盗もうとする悪意のある個人にとって非常に複雑になります。Web サイトのデータのスクラップを防ぐことは不可能かもしれませんが、「不可能」とは、スクレイパーが集計データに容易にアクセスできることを前提としています。見えないものを削ることはできません。したがって、集計データが生の未処理のテキスト (図書館の電子書籍など) でない限り、エンド ユーザーは生の集計データにアクセスできません。図書館の電子書籍の例でも、