私は答えを受け入れましたが、悲しいことに、私たちは最初の最悪のシナリオである、誰もががらくたを購入しようとするCAPTCHAに留まっていると思います。簡単な説明：キャッシング/ Webファームではヒットを追跡することができません。回避策（キャッシュされていないWebビーコンの送信、統合テーブルへの書き込みなど）により、ボットよりもサイトの速度が低下します。高レベルで役立つCiscoなどの高価なハードウェアが存在する可能性がありますが、すべてをキャプチャすることが代替手段である場合、コストを正当化することは困難です。後でもっと詳しく説明し、将来の検索者のためにこれを整理します（コミュニティウィキなので他の人も試してみてください）。

状況

これは、woot.comでのバッグの売り上げについてです。私は、Wottの子会社であるWoot Workshopの社長です。Wootの子会社であり、デザイン、製品の説明、ポッドキャスト、ブログの投稿、フォーラムのモデレートを行っています。私はCSS / HTMLを使用しており、他のテクノロジーにほとんど慣れていません。私は開発者と緊密に連携し、ここでのすべての答え（および私たちが持っている他の多くのアイデア）について話し合いました。

ユーザビリティは私の仕事の大部分を占めており、サイトをエキサイティングで楽しいものにすることは残りのほとんどです。ここで、以下の3つの目標が導き出されます。CAPTCHAはユーザビリティを損ない、ボットは私たちのがらくたの売上から楽しさと興奮を盗みます。

ボットは、ランダムクラップセールのために、フロントページを数十回、2番目のスクリーンスクレイピング（および/またはRSSのスキャン）で叩いています。彼らがそれを見た瞬間、それはプログラムの第2ステージをトリガーし、ログインし、I oneをクリックしてフォームに記入し、がらくたを購入します。

評価

lc：この方法を使用するstackoverflowおよびその他のサイトでは、試行されたタスクがそれを必要とするため、ほとんどの場合、認証（ログイン）ユーザーを処理します。

Wootでは、匿名の（ログに記録されていない）ユーザーがホームページを表示できます。つまり、スラミングボットは認証されない（そしてIPアドレスを除いて本質的に追跡できない）可能性があります。

したがって、IPのスキャンに戻ります。これは、a）クラウドネットワーキングとスパムボットゾンビのこの時代ではほとんど役に立たないこと、b）1つのIPアドレスから来るビジネスの数を考えると、あまりにも多くの無実をキャッチしていることです（非静的IP ISPおよびこれを追跡しようとする潜在的なパフォーマンスヒット）。

ああ、そして人々に電話をかけてもらうのは、最悪のシナリオです。彼らにあなたを呼んでもらえますか？

BradC：Ned Batchelderのメソッドは見た目はかっこいいですが、サイトのネットワーク用に構築されたボットを打ち負かすためにかなりしっかりと設計されています。私たちの問題は、ボットが私たちのサイトを打ち負かすために特別に構築されていることです。これらのメソッドの一部は、スクリプト作成者がボットを進化させてハニーポットを無視し、フォームIDの代わりに近くのラベル名をスクリーンスクレイピングし、JavaScript対応のブラウザコントロールを使用するまで、短時間動作する可能性があります。

lc：「もちろん、誇大広告がマーケティングスキームの一部でない限り」はい、そうです。アイテムがいつ出現するのかという驚きと、なんとかアイテムを手に入れられた場合の興奮は、実際に得られるがらくたと同じかそれ以上に重要です。先着/先着順を排除するものは、がらくたを「勝つ」ことのスリルに有害です。

novatrust：そして、私は、新しいボット支配者を歓迎します。実際にRSSフィードを提供して、サードパーティのアプリがサイトをスキャンして製品情報を取得できるようにしますが、メインサイトのHTMLの前にはできません。私がそれを正しく解釈している場合、あなたのソリューションは、目標1を完全に犠牲にし、ボットががらくたのほとんどを購入するという事実を辞任することによって、目標2（パフォーマンスの問題）を助けます。あなたの最後の段落の悲観論は私には正確だと感じているので、私はあなたの回答に賛成票を投じました。ここには特効薬はないようです。

残りの応答は一般にIP追跡に依存しますが、これもやはり（ボットネット/ゾンビ/クラウドネットワーキングでは）役に立たないと思われ、有害（同じIP宛先から来た多くの無実を捕まえる）のようです。

他のアプローチ/アイデア？私の開発者は「CAPTCHAをやってみよう」と言い続けますが、私たちががらくたを欲している実際の人間すべてにとって、それほど邪魔にならない方法があることを望んでいます。

元の質問

知覚価値が非常に高く、非常に限られた量の何かを安く販売しているとしましょう。このアイテムをいつ販売するかは、正確にはわかりません。100万人を超える人々が、あなたが何を売っているかを定期的に訪れます。

プログラムでスクリプト作成者やボットが[a]そのアイテムをいつ販売するかを把握し、[b]それらが最初に購入したことを確認します。これには2つの理由があります。

1. あなたのサイトは非人間によって非難され、すべての人のすべてを遅くしています。
2. スクリプト作成者は最終的に製品を「勝ち取り」、常連客に騙されたと感じさせます。

一見明白な解決策は、ユーザーが注文する前にジャンプするためのいくつかのフープを作成することですが、これには少なくとも3つの問題があります。

• CAPTCHAを解読したり、猫を選んだり、数学の問題を解いたりする必要があるため、ユーザーエクスペリエンスは人間にとってはうんざりです。
• 知覚された利益が十分に高く、群集が十分に大きい場合、一部のグループは微調整を回避し、軍拡競争につながります。（これは、微調整がより簡単であるほど特に当てはまります。非表示の「コメント」フォーム、フォーム要素の再配置、それらの誤ったラベル付け、非表示の「ゴッチャ」テキストはすべて一度機能し、この特定のフォームをターゲットに戦うために変更する必要があります。）
• スクリプト作成者が微調整を「解決」できない場合でも、フロントページを非難したり、スクリプト作成者が手動で注文を完了するようにアラームを鳴らしたりすることはできません。彼らが[a]を解くことで利点を得たとしても、注文ページに到達する最初の人間になるので、彼らはおそらく[b]を勝ち取るでしょう。さらに、1。が引き続き発生し、サーバーエラーが発生し、全員のパフォーマンスが低下します。

別の解決策は、頻繁にヒットするIPを監視するか、ファイアウォールからIPをブロックするか、またはその他の方法で注文できないようにすることです。これは2.を解決して[b]を防ぐことができますが、IPのスキャンによるパフォーマンスヒットは巨大であり、スクリプト作成者が単独で引き起こしているよりも1.のようなより多くの問題を引き起こす可能性があります。さらに、クラウドネットワーキングとスパムボットゾンビの可能性があるため、IPチェックはほとんど役に立ちません。

3番目のアイデアは、注文フォームをしばらく（たとえば、0.5秒）ロードすることを強制することで、迅速な注文の進行を遅くする可能性がありますが、やはり、スクリプト作成者は、実際のユーザー。

ゴール

1. 非スクリプトの人間にアイテムを販売します。
2. ボットによって減速されない速度でサイトを実行し続けます。
3. 「通常の」ユーザーが人間であることを証明するために完了するタスクを煩わせないでください。

CAPTCHAでSOのようなものを実装するのはどうですか？

サイトを正常に使用している場合は、おそらく表示されません。同じページを頻繁に再読み込みしたり、連続したコメントをすばやく投稿したり、アラームをトリガーする何かをしたりする場合は、人間であることを証明してください。あなたの場合、これはおそらく同じページの一定の再読み込み、ページ上のすべてのリンクをすばやくたどる、または注文フォームに入力するのが速すぎて人間にはできないでしょう。

連続してx回（たとえば、2または3）チェックに失敗した場合は、そのIPにタイムアウトまたはその他の同様の方法を提供します。次に、タイムアウトの最後に、それらを再度チェックにダンプします。

未登録のユーザーがサイトにアクセスしているため、続行するのはIPのみです。各ブラウザにセッションを発行し、必要に応じてそのように追跡できます。そしてもちろん、あまりにも多くのセッションが連続して（再）作成されている場合（ボットがCookieを削除し続ける場合に備えて）、人間によるチェックをスローします。

罪のない人をあまりにも多く捕まえる限り、ヒューマンチェックページに免責事項を表示することができます。「このページは、同じ場所からサイトを閲覧している匿名ユーザーが多すぎる場合にも表示されることがあります。この。" （表現を適切に調整してください。）

さらに、X人が1つのIPから同時に同じページをロードする確率はどれくらいですか？それらが高い場合は、ボットアラームに別のトリガーメカニズムが必要な場合があります。

編集：別のオプションは、それらが何度も失敗し、製品の需要に自信がある場合、それらをブロックし、個人的にブロックを削除するように電話するようにすることです。

人々に電話をかけることはお粗末なことのように思えますが、それはコンピュータの後ろに人間がいることを確認します。重要なのは、それがボットでない限りほとんど発生しないはずの条件（たとえば、連続して複数回チェックに失敗する）の場合にのみ、ブロックを配置することです。それからそれは人間の相互作用を強制します-電話を取ること。

彼らに私を呼ばせたというコメントに応えて、明らかにそのトレードオフがここにあります。ユーザーが売りに出されたときにユーザーが2回の電話を受け付けるようにするのに十分心配していますか？製品が人間のユーザーに届くのをとても心配しているのなら、私はこの決定をしなければなりません。おそらく、プロセスの私の時間の（少し）を犠牲にします。

ボットがあなたのサイトに優位に立つことを許可しないと決心しているように思われるので、私は電話が良い選択肢であると信じています。私はあなたの製品から利益を上げないので、これらの電話を受けることに興味がありません。その利益の一部を共有していただけませんか。これはあなたの製品なので、どれだけ気にかけて実装するかを決める必要があります。

ブロックを解放する他の方法はそれほど効果的ではありません：タイムアウト（ただし、リンスリピート後にサイトを再び攻撃します）、長いタイムアウト（本当に人間が製品を購入しようとしていた場合）それらはSOLであり、チェックに失敗したために罰せられます）、電子メール（ボットによって簡単に行われます）、ファックス（同じ）、またはカタツムリのメール（時間がかかりすぎます）。

もちろん、代わりに、タイムアウトが発生するたびにIPごとにタイムアウト期間を増やすこともできます。ただあなたが本当の人間を不注意で罰しないことを確認してください。

ボットに高額なもの（12mmウィングナット：20ドル）を購入させる方法を考え出す必要があります。スクリプトライターがゲームに参加していると判断する前に、ボットの数を確認します。

利益を使用して、より多くのサーバーを購入し、帯域幅に支払います。

私の解決策は、ボットとスクリプトに約10分の遅延を設けることで、画面のスクレイピングを無意味にすることです。

ここに私がそれをする方法があります：

• リピーターを記録して特定します。

すべてのヒットですべてのIPアドレスを記録する必要はありません。20ヒットごとに1つだけを追跡します。繰り返し犯人はまだランダム化された時折追跡に表示されます。

• 約10分前からページのキャッシュを保持します。

• リピーター/ボットがサイトにヒットした場合、10分の古いキャッシュページを提供します。

古いサイトを取得していることはすぐにはわかりません。彼らはそれとすべてをこすることができますが、「実在の人々」は10分の有利なスタートを切るので、彼らはもはやレースに勝つことはありません。

利点：

• CAPTCHAのようなユーザーの手間や問題はありません。
• サーバー側で完全に実装されています。（Javascript / Flashに依存しない）
• 古いキャッシュページを提供する方が、ライブページよりもパフォーマンスに負荷がかかりません。この方法でサーバーの負荷を実際に減らすことができます！

欠点

• 一部のIPアドレスの追跡が必要
• 古いページのキャッシュを保持および維持する必要があります。

どう思いますか？

見てみましょうここで定義さBatchelderことで、この記事を。彼の記事はスパムボットの阻止に関するものですが、同じ手法がサイトに簡単に適用できる可能性があります。

自分自身をボットとして停止させるのではなく、投稿を成功させるのを困難にしたり、誤ってボットとして自分を識別させたりして、ボットを停止させることができます。これにより、人々の負担がなくなり、コメントフォームには目に見えるスパム対策がありません。

このテクニックは、このサイトでスパムボットを防ぐ方法です。できます。ここで説明する方法は、内容をまったく調べません。

他のいくつかのアイデア：

• 製品の販売時に人々が購読できる公式の自動通知メカニズム（RSSフィード？Twitter？）を作成します。これにより、スクリプトを作成する必要がなくなります。
• 新しいアイテムが発売される直前に難読化手法を変更します。そのため、スクリプト作成者が軍拡競争をエスカレートできたとしても、彼らは常に1日遅れています。

編集：完全に明確にするために、上記のNedの記事では、BOTがフォームを通過して注文を送信できないようにすることで、アイテムの自動購入を防ぐ方法について説明しています。彼のテクニックは、ボットがホームページをスクリーンスクレイピングして、キャロットのBandoleerがいつ売りに出されるかを判断するのを防ぐのに役立ちません。それが本当に可能かどうかはわかりません。

ネッドの戦略の有効性に関するコメントについて：はい、彼はハニーポットについて話し合っていますが、それが彼の最強の戦略だとは思いません。スピナーに関する彼の議論は、私が彼の記事に言及した最初の理由です。申し訳ありませんが、元の投稿ではそれを明確にしていませんでした。

スピナーは、いくつかの目的で使用される非表示のフィールドです。改ざんやリプレイを防止するいくつかの値をハッシュし、フィールド名を不明瞭にするために使用されます。スピナーは次のMD5ハッシュです。

• タイムスタンプ、
• クライアントのIPアドレス
• コメントされているブログエントリのエントリID、および
• 秘密。

WOOT.comでそれを実装する方法は次のとおりです。

新しいアイテムが発売されるたびにハッシュの一部として使用される「秘密」の値を変更します。これは、誰かがアイテムを自動購入するBOTを設計する場合、次のアイテムが発売されるまでしか機能しないことを意味します!!

誰かがボットをすばやく再構築できたとしても、他のすべての実際のユーザーはすでにBOCを購入しているので、問題は解決されます！

彼は説明し、他の戦略は、することです変更（、再び新しいアイテムが売り出されるときにそれを変更）随時ハニーポットの技術を：

• CSSクラス（もちろんランダム化）を使用して、フィールドまたは包含要素をdisplay：noneに設定します。
• ページの背景と同じ（または非常に似ている）フィールドに色を付けます。
• 配置を使用して、フィールドをページの表示領域外に移動します。
• 含まれているハニーポットフィールドを表示するには要素を小さすぎます。
• フィールドを表示したままにしますが、配置を使用してフィールドを覆い隠し要素で覆います。
• JavaScriptを使用してこれらの変更のいずれかを実行します。ボットには完全なJavascriptエンジンが必要です。
• ハニーポットは他のフィールドと同じように表示したままにしますが、ハニーポットには何も入力しないように伝えます。

私の全体的な考えは、新しいアイテムが発売されるたびにフォームのデザインを変更することだと思います。または、少なくとも、新しいBOCが発売されたら変更します。

何回、月に数回ですか？

この回答を受け入れる場合、次の回答の期限をお知らせください。:)

Q：スクリプト作成者が1秒間に数百回サイトを非難するのをどのように阻止しますか？
A：ありません。防ぐ方法はありません外部エージェントによるこの動作。

膨大な数のテクノロジーを使用して、着信要求を分析し、ヒューリスティックに人間と人間ではない人物を特定しようとすることができますが、失敗します。結局、すぐにではないにしても。

唯一の実行可能な長期的な解決策は、ゲームを変えることです、サイトをボットに適さないようにするか、スクリプト作成者にとって魅力がなくなるようことです。

どうやってやるの？まあ、それは別の質問です！;-)

...

OK、いくつかのオプションが上記で与えられました（そして拒否されました）。私はあなたのサイトを1度しか見たことがありませんが、人々は画像のテキストを読むことができ、ボットはこれを簡単に行うことができないため、アナウンスを画像に変更します。CAPTCHAではなく、単なる画像-

• ページが要求されたときに画像（もちろんキャッシュ）を生成する
• 画像のソース名を同じにしておくと、ゲームに影響が出ません。
• ほとんどの場合、画像には通常のテキストが含まれ、インラインHTMLページの一部として表示されるように配置されます
• ゲームが「オン」のとき、画像はお知らせのテキストに変わります
• アナウンステキストにより、手動で入力する必要があるURLやコードが明らかになります、賞品を獲得するためにする。必要に応じてコードをキャプチャしますが、おそらく必要ではありません。
• セキュリティを強化するために、コードはリクエスト/ IP /エージェント専用に生成されたワンタイムトークンにすることができます。これにより、リクエストを繰り返すと異なるコードが生成されます。または、オンデマンド生成の負担が大きすぎる場合は、一連のランダムコード（ワンタイムパッド）を事前に生成できます。

これに応答している実際の人々のタイムトライアルを実行し、この時間の半分よりも早く（たとえば、エラーが発生しました。申し訳ありません。もう一度やり直してください））応答を無視してください。このイベントは、少なくとも1つのボットがコード/ゲームを見つけたという開発者へのアラートもトリガーするはずです。そのため、コード/ゲームを変更します。

とにかく、スクリプト作成者の時間を無駄にするために、ボットがトリガーしなくても、ゲームを定期的に変更し続けます。最終的には、スクリプト作成者はゲームに飽き飽きして別の場所に行く必要があります... ;-)

最後の提案：メインページのリクエストが来たら、キューに入れる、別のプロセスで順番にリクエストに応答します（これを行うには、Webサーバーをハッキング/拡張する必要があるかもしれませんが、価値がある）。最初の要求がキューにあるときに同じIP /エージェントからの別の要求が着信した場合は、それを無視してください。これにより、ボットから負荷が自動的に排除されます。

編集：画像の使用以外の別のオプションは、javascriptを使用して購入/非購入のテキストを入力することです。ボットがJavaScriptを解釈することはめったにないため、Javascriptは表示されません。

これがどれほど実現可能かわかりません：...攻撃を続けてください。

ボットがスキャンしているデータを把握します。あなたががらくたを売っていないとき彼らが探しているデータを彼らに与えなさい。人間のユーザーを煩わせたり混乱させたりしない方法でこれを行ってください。ボットがフェーズ2をトリガーすると、ログインしてフォームに入力し、BOCの代わりに$ 100ルームバスを購入します。もちろん、これはボットが特に堅牢ではないことを前提としています。

別のアイデアは、bag o crapセール期間中にランダムな値下げを実装することです。$ 20の価値しかないことを明確に述べると、だれが$ 150でランダムバッグを購入するでしょうか。熱狂的なボットしかいない。しかし、9分後は35ドルです。17分後は9ドルです。または何でも。

確かに、ゾンビの王は反応することができます。ポイントは、彼らの過ちを彼らにとって非常にコストのかかるものにすることです（そして彼らにあなたに彼らと戦うためのお金を払わせる）。

これはすべて、100％の推奨ではない可能性があるボットの領主を怒らせたいと想定しているためです。

したがって、問題は実際にあるようです。ボットは「bag 'o crap」を望んでいます。これは、認識された価格が高く、認識された値が高いためです。あなたは時々このアイテムを提供し、ボットが潜んでいて、それが利用可能かどうかを確認してから、彼らはアイテムを購入します。

ボットの所有者が利益を上げている（または利益を上げている可能性がある）ように見えるので、トリックは、これを奨励することによって彼らにとって不利益になるようにすることです、がらくたを購入彼らをする彼らです。

まず、いつも「bag 'o crap」を提供します。

第二に、がらくたは通常がらくたであることを確認してください。

第三に、がらくたを頻繁に回転させます。

シンプルですね

あなたは永続的な「なぜ私たちのがらくたは時々がらくたなのですか？」オファーの横にあるリンクをクリックして、何が起こっているのかを人間に説明します。

がらくたがあり、がらくたが自動的に購入されるとボットが見ると、受信者はつまようじの破損に対して10ドルを支払ったことにひどく動揺します。そして、空のゴミ袋。そして、靴の底の汚れ。

彼らが比較的短期間でこのがらくたを十分に購入した場合（そして、あなたがこれをしている理由を説明する大きな免責事項があちこちにある）、彼らはあなたの "バッグ 'oがらくた。がらくたを十分な頻度で回転させると、人間による介入（がらくたががらくたでないことを確認するためのチェック）でも失敗する可能性があります。おそらく、ボットはローテーションに入れられているものに気づき、あまりにも短時間購入しないでしょうが、それは人間ががらくたを購入しないことを意味します。

一体、あなたの常連客はとても面白くて、これを大きなマーケティングの勝利に変えることができるかもしれません。「がらくた」コイがどれだけ売られているかを投稿し始める。人々はボットがいかに激しく噛まれたかを見るために戻ってきます。

更新： 不平を言う人がいる前に、数回電話を受けるかもしれないと思います。あなたはそれを完全に止めることはできないと思います。ただし、これによりボットが停止した場合は、いつでも停止して後で再起動できます。

1. 非スクリプトの人間にアイテムを販売します。

2. ボットによって減速されない速度でサイトを実行し続けます。

3. 「通常の」ユーザーが人間であることを証明するために完了するタスクを煩わせないでください。

あなたはおそらくこれを聞きたくないでしょうが、＃1と＃3は相互に排他的です。

まあ、あなたもボットであることを誰も知らない。人が何かをすることを要求せずに、接続の反対側に人がいるかどうかを判別するプログラム的な方法はありません。CAPTCHAが発明されたのは、スクリプト/ボットがWeb上で何かを行うのを防ぐことが、そのためです。これは、多くの労力を費やしていない新しい問題ではないようです。CAPTCHAのように実際のユーザーにわずらわされることのない、より良い方法があれば、誰もがすでにそれを使用しています。

ボットを注文ページに近づけないようにしたい場合は、良いCAPTCHAがそれを行う唯一の方法であるという事実に直面する必要があると思います。ランダムながらくたへの需要が十分に高く、人々がそれを手に入れるためにこれらの長さに進んで進んでいれば、正当なユーザーはCAPTCHAによって延期されることはありません。

Wootがこの問題に対処するために使用する方法は、ゲームを変えることです-文字通り。彼らが並外れて望ましい商品を提示するとき、彼らはそれを注文するためにユーザーにビデオゲームをプレイさせる。

ボットとの戦闘に成功するだけでなく（自動プレーヤーを回避するためにゲームに簡単な変更を加えることができるほか、セールごとに新しいゲームを提供することもできます）、減速しながら目的のアイテムを「獲得」した印象をユーザーに与えます注文プロセス。

それでもすぐに完売しますが、解決策は良いと思います。問題を再評価し、パラメータを変更することで、厳密な技術的解決策が存在しなかった戦略が成功しました。

ビジネスモデル全体は、「先着順」に基づいています。ラジオ局がしたことはできません（最初の発信者が勝者になることはなく、5番目、20番目、または13番目の発信者が勝者になります）。これは主な機能と一致しません。

いいえ、実際のユーザーの注文エクスペリエンスを変更せずにこれを行う方法はありません。

これらの戦術をすべて実装するとします。これが重要であると判断した場合、100人のユーザーに協力してもらい、100台のコンピューターで動作するソフトウェアを構築し、1秒に20回（各ユーザーのアクセス間隔5秒/ cookie /アカウント/ IPアドレス）。

次の2つの段階があります。

1. フロントページを見る
2. ご注文

キャプチャブロッキング＃1を設定することはできません。これは実際の顧客を失うことになります（「何ですか？最新のwootを表示するたびにキャプチャを解決する必要があります!!？」）。

したがって、私の小さなグループが時間を合わせて監視し、1秒あたり約20のチェックを取得します。最初に変更を確認した人は、他のすべてに（自動的に）警告し、フロントページをもう一度ロードし、注文リンクをたどって、トランザクションを実行します（ captchaを実装して、すべてのwootoff / bocに対して変更しない限り、これも自動的に行われる可能性があります。

あなたは＃2の前にキャプチャを置くことができます、そしてあなたがそれをするのが嫌いな間、それはボットがトップページを見ても、実際のユーザーが製品を手に入れていることを確認する唯一の方法かもしれません。

しかし、CAPTCHAを使用しても、100の私の小さなバンドには、重要な最初の発動機の利点があります。そして、私たちが人間ではないことを確認する方法はありません。アクセスの計時を開始すると、ジッターが追加されるだけです。どのコンピューターを更新するかをランダムに選択できるため、アクセスの順序は常に変化しますが、それでも人間のように十分に見えます。

まず、シンプルなボットを削除します

要求を監視し、誰かが明らかな愚かなことをしている場合は、同じIPで1秒に1回以上更新してから、速度を落とすための戦術を採用する（パケットをドロップする、拒否する、500エラーを返すなど）、適応型ファイアウォールが必要です。 ）。

これにより、トラフィックが大幅に減少し、ボットユーザーが採用する戦術が変更されます。

次に、サーバーを非常に高速にします。

あなたは本当にこれを聞きたくありません...しかし...

私が必要としているのは、完全にカスタムソリューションであるということです。

TCP / IPスタックをいじる必要はありませんが、ユーザー接続を関連付け、さまざまな攻撃に適切に対応することを目的として構築された、非常に高速なカスタムサーバーを開発する必要がある場合があります。

Apache、lighthttpdなどはすべて柔軟であることには優れていますが、単一目的のWebサイトを実行していて、現在のサーバーが実行できる以上のことを両方実行できる必要があります（トラフィックの処理とボットの適切な対戦の両方で）。 ）。

カスタムサーバー上でほぼ静的なWebページ（30秒ごとに更新など）を提供することで、要求とトラフィックの10倍の数を処理できるだけではありません（サーバーが要求を取得して読み取る以外に何も実行していないため）メモリからTCP / IPバッファへのページ）ですが、ボットの速度低下に役立つ可能性があるメトリックへのアクセスも提供します。たとえば、IPアドレスを関連付けることで、IPごとに1秒あたり複数の接続をブロックできます。人間はそれより速く進むことはできず、同じNATされたIPアドレスを使用している人々でさえブロックされることはまれです。あなたは遅いブロックをしたいでしょう-セッションを正式に終了する前に、接続を1秒間そのままにしておきます。これはファイアウォールにフィードして、特に悪質な犯罪者に長期間のブロックを与えることができます。

しかし、実際には、ボットが人間によって1つの目的のためにカスタムビルドされている場合、ボットと人間を区別する方法はありません。ボットは単に人間の代理です。

結論

結局のところ、人間とコンピュータを区別して、トップページを見ることはできません。注文ステップでボットを停止することはできますが、ボットユーザーはまだ最初の発動機に有利であり、管理する負荷が非常に大きくなります。

シンプルなボットにブロックを追加できます。これにより、バーが上がり、邪魔される人が少なくなります。それで十分かもしれません。

しかし、基本的なモデルを変更しなければ、運はありません。できる最善のことは、単純なケースを処理し、サーバーを非常に高速な通常のユーザーに気付かれないようにし、数百万のボットがあっても、必要なだけ多くの通常のユーザーがそれらを取得できるように多くのアイテムを販売することです。 。

ハニーポットを設定し、ユーザーアカウントをボットユーザーとしてマークすることを検討することもできますが、これには大きなコミュニティの反発があります。

「まあ、これをどうするのか...」と思うたびに、適切なボット戦略でいつでもそれに対抗できます。

フロントページをキャプチャページにして注文ページに移動した場合でも（「このアイテムの注文ボタンは青色で、ピンクの輝きがあり、このページのどこかにあります」）、ボットはページ上のすべてのリンクを開き、どちらかを使用します。注文ページに戻ります。これは勝つ方法ではありません。

サーバーを高速にして、注文ページにreCaptcha（簡単にだまされることはないが、おそらくアプリケーションには遅すぎる）を入れ、モデルを少し変更する方法を考えます。通常のユーザーはボットユーザーと同じくらいのチャンスがあります。

-アダム

免責事項：この回答はプログラミングとはまったく関係ありません。ただし、そもそもスクリプトの理由を攻撃しようとします。

もう1つのアイデアは、本当に販売する数量が限られている場合は、先着順の方法から変更してみませんか？もちろん、誇大広告があなたのマーケティング計画の一部でない限り。

他の多くのオプションがあり、他の人がいくつかの異なるものを考えることができると私は確信しています：

• 注文キュー（プレオーダーシステム）-一部のスクリプトはまだキューの先頭に来る可能性がありますが、情報を手動で入力する方がおそらく高速です。

• ラッフルシステム（1つを注文しようとするすべての人がシステムに入力されます）-このようにして、スクリプトを持っている人は持っていない人と同じチャンスを持っています。

• ラッシュプライオリティキュー-認識された価値が本当に高い場合、人々はより多くを支払う用意があります。注文キューを実装しますが、人々はより多くを支払ってキューの上位に配置できます。

• オークション（クレジットはデビッドシュミットに寄付され、コメントは私自身のものです）-人々はスクリプトを使用して土壇場で狙い撃ちすることができますが、価格構造を変更するだけでなく、他の人と戦うことを期待しています。また、特定の期間の入札数を制限したり、認証コードを事前に電話で知らせたりすることもできます。

ナチスが彼らのコミュニケーションがどれほど安全であると考えていようとも、同盟国はしばしば彼らのメッセージを壊しました。ボットがサイトを使用するのをどのように阻止しようとしても、ボットの所有者はそれを回避する方法を考え出します。それがあなたをナチスにしてしまうならすみません:-)

別の考え方が必要だと思います

• ボットによるサイトの使用を停止しないでください
• すぐに機能する修正に行くのではなく、長いゲームをする

あなたのサイトのクライアントが人間であるかボットであるかは問題ではなく、どちらも顧客にお金を払っているだけであるという考え方に入る。しかし、一方は他方よりも不公平な利点があります。ソーシャルライフ（隠者）があまりない一部のユーザーは、ボットと同じようにサイトの他のユーザーに迷惑をかけることがあります。

オファーを公開した時間と、アカウントがオファーを購入した時間を記録します。

これにより、クライアントが商品を購入するまでの時間を記録できます。

オファーを公開する時刻を変更します。

たとえば、その日のあいまいな時間（真夜中？）から始まる3時間のウィンドウがあるとします。ボットと隠者だけが常に数時間以内に注文を受けるために3時間ページを更新します。ウィンドウのサイズのみで、基準時間を変更しないでください。

時間が経つと画像が現れます。

01：公開から数秒以内に、どのアカウントが定期的に製品を購入しているかを確認できます。ボットである可能性を示唆しています。

02：オファーに使用された時間帯も確認できます。この時間帯が1時間の場合、一部の早期購入者は人間になります。ただし、人間が4時間リフレッシュすることはめったにありません。ウィンドウの継続時間に関係なく、経過時間が発行/購入間で非常に一貫している場合、それはボットです。小さなウィンドウでは公開/購入時間が短く、大きなウィンドウでは長くなる場合、それは隠者です！

これで、ボットによるサイトの使用を停止する代わりに、ボットによって確実に使用されているアカウント、および隠者によって使用されている可能性が高いアカウントを通知するのに十分な情報が得られます。その情報をどのように処理するかはあなた次第ですが、確かにそれを使用して、人生を送る人々にとってサイトをより公正にすることができます。

ボットアカウントを禁止することは無意味だと思います。ヒトラーに電話して「Uボートの位置をありがとう！」どういうわけか、アカウントの所有者が気付かない方法で情報を使用する必要があります。私が何かを夢見ることができるかどうか見てみましょう.....

キュー内の注文を処理します。

顧客が注文すると、すぐに確認メールが届き、注文がキューに入れられ、処理が完了すると通知されます。アマゾンでの注文/発送でこのようなことを経験しましたが、まったく気になりません。注文が発送されたというメールがすぐに届く限り、すぐに注文が発送されたというメールを受け取ってもかまいません。アマゾンは私が本が欲しいのを知っています。あなたの場合、それはのメールです

1. 注文が行われ、キューに入れられました。
2. ご注文は処理されました。
3. あなたの注文品は発送されています。

ユーザーは、彼らが公正な待ち行列にいると思います。疑いを喚起しないように、通常のユーザーもキューを体験できるように、キューを1時間ごとに処理します。ボットおよび隠者アカウントからの注文は、「人間の平均注文時間+ x時間」のキューに入った後にのみ処理します。ボットを人間に効果的に削減します。

私はAPIを使用して価格情報を公開すると言います。これは直感的でない解決策ですが、状況を制御できるようにします。APIにいくつかの制限を追加して、APIの機能をWebサイトよりも少し低くします。

注文についても同じことができます。希望する効果が得られるまで、APIの機能やパフォーマンスに小さな変更を加えることができます。

IPチェックを無効にするプロキシとボットネットがあります。非常に優れたキャプチャ読み取りスクリプトがあります。インドには、低価格でキャプチャを倒す労働者のチームさえ存在します。あなたが思いつくことができるどんな解決策も合理的に敗北する可能性があります。Ned Batchelderのソリューションでさえ、ボットネットまたはプロキシリストと組み合わせたWebBrowserコントロールまたは他のシミュレートされたブラウザーを使用することにより、過去のステップを踏むことができます。

現在、F5の最新世代のBigIPロードバランサーを使用しています。BigIPには高度なトラフィック管理機能があり、単一のIPの背後にある一連のソースの中からでも、使用頻度とパターンに基づいてスクレーパーとボットを識別できます。次に、これらを抑制し、代替コンテンツを提供するか、単にヘッダーまたはCookieでタグ付けして、アプリケーションコードでそれらを識別できるようにします。

まず、ここで何をする必要があるかを要約します。私は元の質問を言い換えているだけだと思いますが、これを100％まっすぐにすることが重要です。なぜなら、4つのうち2つまたは3つを正しくする多くの素晴らしい提案があるからです。すべての要件をカバーする多面的なアプローチ。

要件1：「ボット攻撃」を取り除く：

フロントページの急速な「スラミング」は、サイトのパフォーマンスを低下させており、問題の中心にあります。「スラミング」は、単一IPボットと、おそらくボットネットの両方から発生します。私達は両方を取り除きたいです。

要件2：ユーザーエクスペリエンスをいじらないでください。

人間のオペレーターに電話をかける、CAPTCHAの束を解くなどの厄介な検証手順を実装することで、ボットの状況をかなり効果的に修正できますが、それは、すべての罪のない飛行機の乗客に、ほんのわずかなチャンスのためにクレイジーなセキュリティフープを飛び越えさせるようなものです。非常に愚かなテロリストを捕まえること。待ってください-実際にそれを行います。しかし、woot.comでそれができないかどうか見てみましょう。

要件3：「軍拡競争」を回避する：

あなたが言うように、あなたはスパムボットの武器競争に巻き込まれたくありません。したがって、隠された、またはごちゃ混ぜになったフォームフィールド、数学の質問などの単純な微調整は、自明に自動検出および回避できる本質的に不明瞭な手段であるため、使用できません。

要件4：「アラーム」ボットを阻止する：

これが要件の中で最も難しい場合があります。人間による検証を効果的に行うことができたとしても、ボットはあなたのフロントページをポーリングし、新しいオファーがあったときにスクリプト作成者に警告することができます。これらのボットも実行不可能にしたいと考えています。これは最初の要件のより強力なバージョンです。これは、ボットがパフォーマンスを損なう速射要求を発行できないだけでなく、勝つためにスクリプトをスクリプトに送信するために十分な繰り返し要求を発行することさえできないためです。オファー。

では、4つの要件をすべて満たすことができるかどうかを確認しましょう。まず、先に述べたように、トリックを実行する手段は1つもありません。あなたはそれを達成するためにいくつかのトリックを組み合わせる必要があります、そしてあなたは2つの煩わしさを飲み込む必要があります：

1. 少数のユーザーがフープをジャンプする必要があります
2. 少数のユーザーは特別オファーを受け取ることができなくなります

これらは煩わしいことだと思いますが、「小さい」数を十分に小さくできる場合は、プラスがマイナスを上回ることに同意してください。

最初の対策：ユーザーベースのスロットル：

これは非常に簡単で、きっとあなたはすでにそうしていると思います。ユーザーがログインしていて、毎秒600回（または何か）リフレッシュし続けると、応答を停止し、冷却するように指示します。実際、おそらくそれよりもはるかに早く彼の要求を抑制しますが、あなたはそのアイデアを得ます。このように、ログインしたボットは、サイトのポーリングを開始するとすぐに禁止または抑制されます。これは簡単な部分です。認証されていないボットは私たちの本当の問題です。

2番目の対策：ほぼすべての人が示唆しているように、何らかの形のIPスロットリング：

ありませんあなたがする必要がありますどのような問題ではいくつかの「ボットスラミング」を阻止するためにスロットルベースのIPを。認証されていない（ログインしていない）訪問者が特別オファーを取得できるようにすることが重要であるように思われるため、最初はIPしか持っておらず、完全ではありませんが、シングルIPボットに対しては機能します。ボットネットは別の獣ですが、私はそれらに戻ります。とりあえず、簡単なスロットルを実行して、高速の単一IPボットを倒します。

他のすべての処理の前にIPチェックを実行し、スロットルロジックにプロキシサーバーを使用し、memcachedルックアップ最適化ツリー構造にIPを格納する場合、パフォーマンスへの影響は無視できます。

3番目の対策：キャッシュされた応答でスロットルをクローキングする：

高速な単一IPボットが抑制されているため、低速の単一IPボットに対処する必要があります。スロットリングが妨げるよりも少し離れてリクエストを間隔を空けて「レーダーの下を飛ぶ」ように特別に調整されたボット。

遅いシングルIPボットをすぐに役に立たないようにするには、abellekyが提案する戦略を使用するだけです。過去24時間以内に発見されたすべてのIPに、10分前のキャッシュページを提供します。このように、すべてのIPは1日/時間/週（選択した期間に応じて）ごとに1つの「チャンス」を取得し、勝たないことを除いて、「リロード」を押すだけの実際のユーザーに目に見える不快感はありません。オファー。

この対策の優れている点は、ボットネットに由来しない限り、「アラームボット」も阻止することです。

（私はあなたが実際のユーザーが何度もリフレッシュすることを許可されているならおそらくそれを好むだろうことを知っていますが、CAPTCHAまたは類似のものなしでリクエストスパミングボットからリフレッシュスパミング人間を区別する方法はありません）

4番目の測定：reCAPTCHA：

CAPTCHAはユーザーエクスペリエンスを損なうので、避けてください。ただし、_one_の状況では、彼らはあなたの親友になることができます。ボットを阻止するために非常に制限的なシステムを設計した場合、それは-その制限のために-いくつかの誤検知もキャッチします。次に、最後の手段として提供される CAPTCHAは、スロットリングに巻き込まれた実際のユーザーが（したがって、煩わしいDoS状況を回避して）スリップすることを可能にします。

もちろん、スイートスポットは、すべてのボットがあなたのネットに巻き込まれることですが、CAPTCHAに煩わされる実際のユーザーはごくわずかです。

10分、古いキャッシュされたページを提供するときにも、代替手段を提供する場合は、オプションで、CAPTCHA検証「フロントページリフレッシャー」、そして人間は本当にさわやか維持したいが、まだ古いキャッシュされたページを得ることなく行うことができますただし、更新ごとにCAPTCHAを解決する必要があります。それは厄介ですが、チャンスを改善するためにシステムをゲームしていることを知っているために寛容になりがちで、改善されたチャンスが無料にならないという、ハードなユーザーのためのオプションの1つです。

5番目の測定：おとりのがらくた：

クリストファー・マハンは私がむしろ好きだという考えを持っていましたが、私はそれに対して別の考えを置きました。新しいオファーを準備するたびに、20ドルの12mmウィングナットのように、人間が選択しない他の2つの「オファー」も準備します。オファーが最初のページに表示されたら、3つの「オファー」すべてを同じ画像に配置します。番号は各オファーに対応しています。ユーザー/ボットが実際にアイテムを注文するとき、彼らは希望するオファー（ラジオボタン）を選択する必要があります。ほとんどのボットは単に推測しているだけなので、3つのうち2つのケースでは、ボットは価値のないものを購入します。ジャンク。

当然、これは「アラームボット」には対応しておらず、正しいアイテムを選択できるボットを誰かが作成できる可能性があります（スリム）。ただし、誤ってジャンクを購入するリスクがあるため、スクリプト作成者は完全に自動化されたボットから完全に転向するはずです。

6番目の対策：ボットネットスロットリング：

[削除済み]

わかりました............夜のほとんどをこれについて考え、さまざまなアプローチを試みました...グローバルな遅延...クッキーベースのトークン..キューに入れられたサービング... 「ストレンジャースロットリング」....そして、それは機能しません。そうではありません。回答をまだ受け入れていない主な理由は、分散型/ゾンビネット/ボットネット攻撃を阻止する方法を誰も提案していなかったことに気付きました。別のスレッドで認証のためのボットネット問題を解読したと思いますでので、あなたの問題にも大きな期待がありました。しかし、私のアプローチはこれに変換されません。通過できるのはIPだけであり、十分に大きなボットネットは、IPアドレスに基づく分析では明らかになりません。

だからあなたはそれを持っています：私の6番目の測定は無意味です。何もない。ジップ。ボットネットは、通常のIPスロットルに巻き込ま小さなおよび/または十分に高速でない限り、私は表示されませんどのようにCAPTHAsとして明示的に人間の検証を伴わないボットネットに対する効果的な対策を。申し訳ありませんが、上記の5つの方法を組み合わせることは最善の策だと思います。そして、おそらくabelenkyの10分のキャッシュトリックだけでうまくいくでしょう。

一種の「CAPTCHAゲーム」のように、人間の操作を必要とする遅延を導入するのはどうですか。たとえば、30秒間に市松模様のボールを破裂させ、ソリッドボールの破裂を回避する（色覚異常の問題を回避する）小さなFlashゲームの場合があります。ゲームには乱数シードが与えられ、ゲームがサーバーに送信するのは、クリックされたポイントの座標とタイムスタンプ、および使用されたシードです。

サーバーで、そのシードを使用してゲームメカニクスをシミュレートし、クリックで実際にボールが爆発したかどうかを確認します。もしそうなら、彼らは人間であるだけでなく、彼ら自身を検証するために30秒かかりました。それらにセッションIDを与えます。

そのセッションIDに好きなようにさせますが、リクエストが多すぎると、もう一度プレイしないと続行できません。

他にもいくつかの/より良い解決策がすでに投稿されていますが、完全を期すために、これについて言及したいと思いました。

あなたの主な懸念がパフォーマンスの低下であり、あなたが本当のハンマリングを見ているなら場合は、実際にはDoS攻撃に対処しているため、それに応じて対処する必要があります。1つの一般的なアプローチは、1秒あたりの接続数/分などの後、ファイアウォール内のIPからパケットを単にドロップすることです。たとえば、標準のLinuxファイアウォールであるiptablesには、標準の操作マッチング関数「hashlimit」があり、これを使用して、時間単位ごとの接続要求をIPアドレスに関連付けることができます。

この質問はおそらく最後のSOポッドキャストで言及されている次のSO派生物に適していると思われますが、まだ始まっていないので、答えても大丈夫だと思います:)

編集：
novatrustによって指摘されたように、実際には顧客にIPを割り当てていないISPがまだ存在するため、そのようなISPのスクリプト顧客は事実上、そのISPからのすべての顧客を無効にします。

ボットを罰するためにターピット（ウィキペディアの記事）を実装するアプリケーションの前のApacheサーバーにリバースプロキシを記述します。過去数秒間に接続されたIPアドレスのリストを管理するだけです。単一のIPアドレスからのリクエストのバーストを検出し、それらのリクエストを指数関数的に遅延させてから応答します。

もちろん、NATされたネットワーク接続上にいる場合、複数の人間が同じIPアドレスから来る可能性がありますが、ボットが妨害される一方で、人間が2mSから4mS（または400mS）の応答時間を気にすることはほとんどありません。遅延の増加がかなり速くなります。

1. 彼らがあなたの帯域幅を消費しないようにRSSフィードを提供してください。
2. 購入するとき は、探しているものに応じて、45秒程度のランダムな時間を全員にランダムに待機させます。正確にあなたのタイミングの制約は何ですか？
3. 全員が1分間で自分の名前を描いてから抽選し、ランダムに人を選びます。これが最も公正な方法だと思います。
4. アカウントを監視し（セッションに数回含めて保存しますか？）、人間の速度のしきい値を下回っているように見えるアカウントに遅延を追加します。これにより、少なくともボットは速度を落として人間と競合するようにプログラムされます。

まず第一に、定義上、ボットを正当なユーザーから分離することもできる一方で、ステートレス、つまり真に匿名のトランザクションをサポートすることは不可能です。

真新しいスパンキングビジターの最初のページヒットにいくらかの費用を課すことができるという前提を受け入れることができれば、私には可能な解決策があると思います。わかりやすい名前がないため、このソリューションを大まかに「DMVへの訪問」と呼びます。

毎日別の新車を販売する自動車販売店があり、日によってはエキゾチックなスポーツカーをそれぞれ5ドル（上限3）と5ドルの目的地料金で購入できるとします。

問題は、販売店では、販売店に行き、販売されている車を確認する前に、有効な運転免許証を提示する必要があることです。また、購入するには有効な運転免許証が必要です。

そのため、この自動車ディーラーへの初めての訪問者（彼をボブと呼びましょう）は入国を拒否され、運転免許証を取得するためにDMVオフィス（便利なすぐ隣にあります）に紹介されます。

有効な運転免許を持つ他の訪問者は、彼の運転免許を提示した後、許可されます。一日中歩き回り、セールスマンをからかい、パンフレットを手に入れ、無料のコーヒーとクッキーを空にして自分の迷惑をかける人は、最終的には却下されます。

さて、免許なしでボブに戻ってください-彼がしなければならないことは、DMVへの訪問を一度耐えることだけです。その後、彼は誤って自分の財布を家に置き忘れたり、ライセンスが破棄されたり取り消されたりしない限り、好きなときにいつでもディーラーに行って車を購入できます。

この世界の運転免許証を偽造することはほとんど不可能です。

DMVにアクセスするには、最初に「ここから開始」キューにあるアプリケーションフォームを取得する必要があります。ボブは完成したアプリケーションをウィンドウ＃1に持ち込む必要があります。そこでは、多くの非常に公務員の最初の人が彼のアプリケーションを受け取り、それを処理し、すべてが順調であれば、ウィンドウのアプリケーションにスタンプを押して、次のウィンドウに送ります。そして、ボブはウィンドウからウィンドウへと進み、アプリケーションの各ステップが完了するのを待って、最後に最後まで行き、運転免許証を受け取ります。

DMVを「短絡」しようとしても意味がありません。フォームに3つずつ正しく入力されていない場合、またはいずれかのウィンドウで間違った回答があった場合、アプリケーションは破棄され、不幸な顧客は最初に戻されます。

興味深いことに、オフィスがどれほど満員であるか空いているかに関係なく、連続する各ウィンドウでサービスを受けるには、ほぼ同じ時間がかかります。あなたが唯一の列にいるときでさえ、職員は黄色い線の後ろに1分待ってから「次へ」と発声するのを好むようです。

しかし、DMVでは状況はそれほどひどくありません。ライセンスを取得するためのすべての待機と処理が行われている間、DMVロビーにいる間は、自動車販売店の非常に楽しくて有益なインフォマーシャルを見ることができます。実際、インフォメリックは、ライセンスの取得に費やす時間をカバーするのに十分なだけ長く実行されます。

もう少し技術的な説明：

冒頭で述べたように、ボットから人間を分離できるようにするために、クライアントとサーバーの関係に何らかのステートフル性が必要になります。匿名の（認証されていない）人間の訪問者に過度の不利益を与えない方法でそれを実行したい。

このアプローチでは、おそらくAJAX-yクライアント側の処理が必要です。wootの真新しいスパンキングビジターには、「Welcome New User！」が与えられます。（適切なサーバー側のスロットルにより）完全にロードするのに数秒かかるテキストとグラフィックスの完全なページ。これが発生している間（そして訪問者はおそらくウェルカムページを読むのに忙しい）、彼の識別トークンはゆっくりと組み立てられています。

議論のために、トークン（別名「運転免許証」）が20のチャンクで構成されているとしましょう。連続する各チャンクを取得するには、クライアント側のコードが有効なリクエストをサーバーに送信する必要があります。サーバーには意図的な遅延が組み込まれています（たとえば、 200ミリ秒）、次のチャンクを送信する前に、次のチャンク要求（つまり、あるDMVウィンドウから次のDMVウィンドウに移動するために必要なスタンプ）に必要な「スタンプ」を送信します。 chunk-challenge-response-chunk-challenge-response -...- chunk-challenge-response-completionプロセス。

このプロセスの最後に、訪問者はトークンを取得します。これにより、訪問者は製品の説明ページに移動し、次に購入ページに移動できます。トークンは各訪問者に固有のIDであり、彼の活動を抑制するために使用できます。

サーバー側では、有効なトークンを持つクライアントからのページビューのみを受け入れます。または、全員が最終的にページを表示できることが重要な場合は、有効なトークンがないリクエストに時間ペナルティを課します。

さて、これが正当な人間の訪問者にとって比較的優しいものであるように、トークン発行プロセスをバックグラウンドで比較的非侵入的に実行させます。したがって、意図的にわずかに速度が低下する面白いコピーとグラフィックスを含むウェルカムページの必要性。

このアプローチは、既存のトークンを使用するか、最小のセットアップ時間をかけて新しいトークンを取得するようにボットのスロットルダウンを強制します。もちろん、これは偽の訪問者の分散ネットワークを使用した高度な攻撃に対してはあまり役に立ちません。

キャプチャを使用しても、ボットを完全に防ぐことはできません。ただし、ボットを作成して維持するのが面倒になるため、その数を減らすことができます。特に、ボットを毎日更新するように強制することで、ほとんどの人が興味を失うことになります。

ボットの作成を困難にするいくつかのアイデアを次に示します。

• JavaScript関数を実行する必要があります。JavaScriptを使用すると、ボットを作成するのがはるかに困難になります。JavaScriptを実行していない場合でも、実際のJavaScript以外のユーザー（最小）を許可するためにキャプチャを必要とする場合があります。

• フォームに入力するとき（再びJavaScriptを介して）、キーストロークの時間を計ります。人間に似ていない場合は拒否してください。ボットでの人間の入力を模倣するのは苦痛です。

• コードを記述して、フィールドIDを毎日新しいランダムな値で更新します。これにより、ボットを毎日更新しなければならず、これは面倒です。

• フィールドを毎日並べ替えるコードを作成します（明らかに、ユーザーにとってランダムではない何らかの方法で）。彼らがフィールドオーダーに依存している場合、これは彼らをつまずかせ、再び彼らのボットコードに毎日のメンテナンスを強制します。

• さらに進んで、Flashコンテンツを使用することもできます。フラッシュは完全にボットを書くのに苦痛です。

一般的に、それらを防ぐのではなく、より効果的にするという考え方を始めた場合、おそらく目的の目標を達成できます。

未登録ユーザー向けのすべての製品発表に5分の遅延を付けます。カジュアルなユーザーはこれに実際には気づかず、非カジュアルなユーザーはとにかく登録されます。

着信IPのチェックからの大きな負担はないと思います。それどころか、5分ごとにHTTPアクセスログを分析するクライアントのプロジェクトを実行しました（リアルタイムであった可能性もありますが、完全に理解できなかった何らかの理由で彼はそれを望んでいませんでした）。正当な検索エンジン（google、yahooなど）に属していることが確認できない限り、過剰な数のリクエストを生成するIPアドレスからの接続をブロックするファイアウォールルールを作成します。

このクライアントはWebホスティングサービスを実行し、合計800〜900のドメインを処理する3つのサーバーでこのアプリケーションを実行しています。ピークアクティビティは毎秒1000ヒットの範囲であり、パフォーマンスの問題はこれまでありませんでした。ファイアウォールは、ブラックリストに登録されたアドレスからパケットをドロップするのに非常に効率的です。

そして、はい、確かにこのスキームを打ち負かすDDOSテクノロジーが存在しますが、彼はそれが現実の世界で起こるのを見ていません。逆に、サーバーの負荷が大幅に軽減されたと彼は言います。

私のアプローチは、非技術的な解決策に焦点を当てることです（そうしないと、失う競争に参加するか、少なくとも多くの時間とお金を費やすことになります）。私は請求/発送の部分に焦点を当てます-同じアドレスへの複数の配送を見つけるか、単一の支払い方法への複数の請求によってボットを見つけることができます。数週間にわたってアイテム間でこれを行うこともできるため、ユーザーが前のアイテムを取得した場合（本当に非常に速く応答することにより）、今度は何らかの「ハンディキャップ」が割り当てられる可能性があります。

これは、幸運にして羊毛を購入する人々の輪を広げるという副作用（有益だと思いますが、私はあなたの場合には間違っているかもしれません）をもたらすでしょう。

ほとんどの純粋に技術的なソリューションはすでに提供されています。したがって、問題の別の見方を提案します。

私が理解しているように、ボットはあなたが売っているバッグを本当に購入しようとする人々によってセットアップされています。問題は -

1. ボットを操作しない他の人々は、買う機会に値し、あなたは限られた量のバッグを提供しています。
2. 人間をサイトに引き付け、バッグを販売するだけです。

ボットを回避しようとする代わりに、潜在的なバッグ購入者が電子メールまたはSMSアップデートさえも購読できるようにして、販売が行われるときに通知を受け取ることができます。さらに、1〜2分でスタートを切ることもできます（販売が開始され、ランダムに生成され、メール/ SMSで送信される特別なURL）。

これらのバイヤーがサイト内にあるものを購入しようとするとき、サイドバナーや何にでも好きなように表示できます。ボットを実行している人は、単に通知サービスに登録することを好みます。

ボットランナーは、通知でボットを実行して、購入をより迅速に完了する場合があります。それに対するいくつかの解決策は、ワンクリック購入を提供することができます。

ちなみに、ユーザーは登録されていないとのことですが、これらのバッグを購入するのはランダムな購入者ではなく、販売を楽しみにしている人のようです。そのため、彼らはバッグを「獲得」しようとする際に有利になるように登録することをいとわないかもしれません。

本質的に私が提案しているのは、問題を技術的な問題ではなく、社会的な問題として試してみることです。

アサフ

毎分多くのリクエストを行うユーザーエージェントを時間ブロックします。たとえば、ページを5秒ごとに正確に10分間リクエストするユーザーがいる場合、そのユーザーはおそらくユーザーではありません...しかし、これを正しく行うのは難しいかもしれません。

彼らがアラートをトリガーする場合、すべてのリクエストをできるだけ少ないDB-IOで静的ページにリダイレクトし、メッセージがX分以内に許可されることを通知します。

これをページのリクエストにのみ適用し、メディア（js、画像など）のすべてのリクエストを無視することをお勧めします。

DoSを防ぐと、@ davebugが上で概説した目標の＃2を打ち負かすでしょう。

スクリプト作成者は、人間が注文フォームを通過するよりもまだ速い過剰な制限のすぐ下でスケートをする何かを書くことができると思います。

よし、スパマーは「がらくたの泥沼」オークションに勝つために一般の人々と競っているのか？次のオークションを文字通り「がらくたの袋」にしてみませんか？スパマーは後背位でいっぱいのバッグにかなりのお金を払うようになり、私たちは皆それらを笑います。

ここで重要なことは、サーバーから負荷を取り除くようにシステムを変更し、ゲームをしていることをボットロードに知らせずに、ボットががらくたを勝ち取らないようにすることです。あなたの側でいくつかの処理なしでこれを行う方法はないと思います。

つまり、ホームページにヒットを記録します。誰かがページにヒットするたびに、その接続は最後のヒットと比較され、速すぎる場合は、オファーなしのバージョンのページが送信されます。これは、ホームページのキャッシュバージョンを提供するサーバーにボット（速すぎるヒット）を送信するある種の負荷分散メカニズムによって実行できます。実際の人は良いサーバーに送られます。これにより、メインサーバーの負荷が減り、ボットはまだページが正しく提供されているとボットに思わせます。

申し出が何らかの形で断られることができればさらに良い。その後、偽のサーバー上でオファーを出すことはできますが、ボットがフォームに記入したときに「申し訳ありません、あなたは十分に速くありませんでした」と言う:)そして、彼らは間違いなく彼らがまだゲームにいると思います。

注文を出すスクリプト作成者がいることをどうやって知っていますか？

問題の核心は、正当なユーザーからスクリプト作成者を分離できないため、ブロックできないということです。では、スクリプト作成者がいることをどのようにして知っているのでしょうか。

この質問に答える方法がある場合は、スクリプト作成者のフィルタリングに使用できる一連の特性があります。

問題を頭に入れましょう。実際の人に購入してもらいたいものを購入するボットがあります。実際の人に購入してほしくないものをボットが購入する本当のチャンスを作ってみませんか。

スクレイピングボットが実際の状況であると考える非表示のHTMLがランダムに発生する可能性がありますが、実際の人には見えません（そして、実際の人にはブラインドが含まれているので、スクリーンリーダーなども考慮してください）。これは非常に高価なものを購入するために移動します（または実際の購入はしませんが、バンリストに置くための支払いの詳細を取得します）。

ボットが「購入する」ではなく「ユーザーに警告する」に切り替わったとしても、十分な誤報を得ることができれば、人々にとって十分に価値のないものにすることができるかもしれません（全員ではないかもしれませんが、詐欺行為のいくつかの削減はまったく気にしない方がいいです。