Tor 経由で匿名で送信された受信 HTTP リクエストを検出するにはどうすればよいですか?

Question

私はウェブサイトを開発しているのですが、人々が私のデータを画面からスクレイピングすることに敏感です。私は 1 ～ 2 ページのスクレイピングについては心配していません。データの集合体は、一部のデータよりもはるかに価値があるため、誰かが何千ページもスクレイピングすることの方が心配です。

単一の IP アドレスからの大量のトラフィックに基づいてユーザーをブロックする戦略は想像できますが、 Torネットワーク 多数の回線を設定することは、基本的に、単一のユーザーのトラフィックが時間の経過とともに異なる IP アドレスから送信されているように見えることを意味します。

インストールしたときと同様に Tor トラフィックを検出できることがわかりました ヴィダリア Firefox 拡張機能を使用すると、google.com からキャプチャが表示されました。

では、そのようなリクエストを検出するにはどうすればよいでしょうか?

(私の Web サイトは ASP.NET MVC 2 ですが、ここで使用されるアプローチは言語に依存しないと思います)

Answer 1

私はウェブサイトを開発していて、私のデータをスクレイピングする人々に敏感です

気にしないで。それがウェブ上にあり、誰かがそれを望んでいるなら、それは 無理だよ 彼らがそれを得るのを止めるために。制限が増えるほど、合法的なユーザーのユーザーエクスペリエンスを台無しにするリスクが高くなります。また、コードを維持するのが難しくなります。

将来の答えが提案するアイデアに対策を投稿します。

Answer 2

のリストに対してIPアドレスを確認できます TOR EXITノード. 。事実、これはあなたのサイトを削ることに興味がある人を遅くすることさえないことを知っています。 TORは遅すぎますが、ほとんどのスクレーパーはそれを考慮しません。何万ものオープンプロキシサーバーがあり、簡単にスキャンできるか、リストを購入できます。プロキシサーバーは、リクエストキャップがヒットした場合にスレッドまたは回転できるため、優れています。

GoogleはTORユーザーに虐待されており、出口ノードのほとんどはGoogle Blackリストに載っているため、Captchaを手に入れています。

私を完全に明確にさせてください： 誰かがあなたのサイトをこすらないようにするためにできることは何もありません。

Answer 3

TORネットワークコンポーネントの設計により、レシーバーがリクエスターが元のソースであるか、それが単なるリレーのリクエストであるかを確認することはできません。

Googleで見た動作は、おそらく別のセキュリティ尺度によって引き起こされました。 Googleは、ログインしたユーザーがIPの変更を変更するかどうかを検出し、有害な傍受を防止し、認証されたユーザーが実際にIPを変更した場合にセッションの継続を許可するためにCAPTCHAを提示します。

Answer 4

これが古いことは承知していますが、Google 検索からここにたどり着いたので、ここで質問の根本的な懸念に迫ろうと考えました。私は Web アプリケーションを開発していますが、他の人を悪用したり搾取したりすることもたくさんあります。私はおそらくあなたが遠ざけようとしている男です。

Tor トラフィックの検出は、実際にここで進みたいルートではありません。リクエスト ヘッダーを解析することで、かなりの量のオープン プロキシ サーバーを検出できますが、レート制限を突破するには、tor、匿名性の高いプロキシ、ソックス プロキシ、スパマーに直接販売されている安価な VPN、ボットネット、その他無数の方法があります。あなたも

主な懸念事項が DDoS の影響である場合は、心配する必要はありません。実際の DDoS 攻撃は、サーバーに負担をかける筋肉や脆弱性を攻撃します。サイトの種類に関係なく、スパイダーやエクスプロイトをスキャンする悪意のある人々からのヒットが殺到することになります。ただの事実です。実際、サーバー上のこの種のロジックはほとんど拡張性がなく、単一障害点となり、実際の DDoS 攻撃にさらされる可能性があります。

これは、エンド ユーザー (フレンドリーなボットを含む) にとって単一障害点になる可能性もあります。正規のユーザーまたは顧客がブロックされれば、カスタマー サービスの悪夢が待っています。また、間違ったクローラーがブロックされれば、検索トラフィックに別れを告げることになります。

誰かにデータを取得されたくない場合は、できることがいくつかあります。それがブログのコンテンツか何かの場合、私は通常、それについては気にしないか、フィードが必要な場合は概要のみの RSS フィードを用意するかのどちらかだと思います。スクレイピングされたブログ コンテンツの危険性は、記事の正確なコピーを取得し、そこにスパム リンクを貼り付けて、元の記事を検索結果から除外しながらランク付けすることが実際に非常に簡単であることです。同時に、RSS フィードを一括でスクレイピングできるようになると、あまりに簡単なので、人々は特定のサイトをターゲットにすることに労力を費やすことはなくなります。

あなたのサイトが動的なコンテンツを備えたサービスである場合は、まったく別の話になります。私は実際に、大量の構造化された独自データを「盗む」ためにこのようなサイトをたくさんスクレイピングしていますが、それをより困難にするオプションがあります。IP ごとにリクエストを制限できますが、プロキシを使用すると簡単に回避できます。実際の保護には、比較的単純な難読化が大いに役立ちます。Google の検索結果をスクレイピングしたり、YouTube からビデオをダウンロードしたりすると、リバース エンジニアリングすべきことがたくさんあることがわかります。私は両方ともやりますが、挑戦する人の99％は知識がないために失敗します。プロキシをスクレイピングして IP 制限を回避することはできますが、暗号化を破ることはありません。

たとえば、私が覚えている限り、Google の結果ページには、ページの読み込み時に DOM に挿入される難読化された JavaScript が含まれており、その後、ある種のトークンが設定されるため、それらを解析する必要があります。次に、それらのトークンを含む ajax リクエストがあり、難読化された JS または JSON を返し、結果を構築するためにデコードされます。開発者側でこれを行うのは難しくありませんが、潜在的な窃盗犯の大多数はこれに対処できません。できる人のほとんどは努力をしません。Google という本当に価値のあるサービスをラップするためにこれを行っていますが、他のほとんどのサービスについては、別のプロバイダーの簡単な成果に移るだけです。

これが、これに出会った人にとって役立つことを願っています。

Answer 5

決心した技術的に精通しているユーザーがウェブサイトをこすらないようにすることが「不可能」であることに焦点を当てていると思います。 @Drew Noakesは、Webサイトには集計で撮影されたときに何らかの「価値」があるという情報が含まれていると述べています。ウェブサイトに、制約のない匿名のユーザーが容易にアクセスできる集計データがある場合、はい、スクレイピングの防止は「不可能」に近づく可能性があります。

解決すべき問題は、ユーザーが集計データを削減するのを防ぐ方法ではなく、一般のアクセスから集約データを削除するためにアプローチを使用できることです。それにより、「不可能」を行う必要なく、スクレーパーのターゲットを排除し、廃棄を防ぎます。

集計データは、独自の企業情報のように扱う必要があります。一般的に独自の企業情報は、集計または生の形で匿名のユーザーに公開されていません。貴重なデータの取得を防ぐための解決策は、ユーザーに提示されたときにデータの廃棄を防ぐのではなく、データへのアクセスを制限し制限することであると主張します。

1]ユーザーアカウント/アクセス - 特定の期間内（データ/ドメイン固有）内にすべてのデータにアクセスできる必要はありません。ユーザーは自分に関連するデータにアクセスできる必要がありますが、明らかに質問から、すべての集計データを照会する正当な目的を持つユーザーはいません。サイトの詳細を知らずに、合法的なユーザーは、ある期間内にデータの小さなサブセットのみを必要とする場合があると思います。典型的なユーザーのニーズを大幅に超えることを要求することは、削り取ることを法外に時間をかけ、廃棄されたデータを潜在的に古くするために、典型的なユーザーのニーズをブロックするか、代わりにスロットルする必要があることを要求します。

2]運用チームは、多くの場合、メトリックを監視して、大規模な分散型および複雑なシステムが健康であることを確認します。残念ながら、散発的および断続的な問題の原因を特定することは非常に困難になり、通常の動作の変動とは対照的に問題があることを特定することさえ困難です。運用チームは、多くの多数のメトリックから取られた統計分析された履歴データを扱い、システムの健康の重要な逸脱を特定するために現在の値と比較することがよくあります。

同様に、標準よりも大幅に大きい金額のデータをユーザーから要求すると、データを廃棄している可能性のある個人を特定するのに役立ちます。このようなアプローチは自動化され、さらに拡張されて、廃棄を示すパターンを複数のアカウントに照らしてさらに拡張することもできます。ユーザー1は10％を削り、ユーザー2は次の10％を削り、ユーザー3は次の10％を削るなど...複数のアカウント

3]生のアグリゲートデータをエンドユーザーが直接アクセスできるようにしないでください。詳細はここで重要ですが、簡単に言えば、データはバックエンドサーバーに存在し、ドメイン固有のAPIを使用して取得する必要があります。繰り返しますが、私はあなたが生データを提供するだけでなく、データの一部のサブセットのユーザー要求に応答することを想定しています。たとえば、あなたが持っているデータが特定の地域の詳細な人口統計である場合、正当なエンドユーザーはそのデータのサブセットのみに関心があります。たとえば、エンドユーザーは、特定の都市または郡のマルチユニットハウジングまたはデータの両方の親と一緒に住むティーンエイジャーのある世帯の住所を知りたい場合があります。このようなリクエストでは、アグリゲートデータの処理が必要になり、エンドユーザーにとって興味深い結果データセットが生成されます。入力クエリの多数の潜在的な順列から取得されたすべての結果のデータセットをスクレイプし、集計データ全体を再構築することは非常に困難です。スクレーパーは、要求/時間の＃、結果データセットの総データサイズ、およびその他の潜在的なマーカーを考慮して、Webサイトのセキュリティによって制約されます。ドメイン固有の知識を組み込むよく開発されたAPIは、APIがその目的を果たすのに十分な包括的であることを保証するために重要ですが、大規模な生データダンプを返すために過度に一般的ではありません。

サイトへのユーザーアカウントの組み込み、ユーザー向けの使用ベースラインの確立、一般的な使用パターンから大幅に逸脱するユーザー（または他の緩和アプローチ）の識別とスロットリング、および処理/消化の結果を要求するためのインターフェイスの作成セット（vs raw gegregateデータ）は、データを盗むことを目的とした悪意のある個人に大きな複雑さを生み出します。ウェブサイトのデータの廃棄を防ぐことは不可能かもしれませんが、「不可能」は、スクレーパーが容易にアクセスできる集計データに基づいています。見えないものをこすらうことはできません。したがって、集計データが未処理のテキスト（ライブラリ電子書籍など）でない限り、エンドユーザーは生の集計データにアクセスできないはずです。図書館の電子書籍の例でも、多数の本を要求するなど、許容可能な使用パターンからの大幅な逸脱をブロックまたはスロットルする必要があります。

Answer 6

Tordnselを使用してTORユーザーを検出できます - https://www.torproject.org/projects/tordnsel.html.en.

このコマンドライン/ライブラリを使用することができます - https://github.com/assafmo/istorexit.