保護PHPハッシュアルゴリズム（ボットから））
まず第一に、私はこの暗号全体に不慣れです。これが私のシナリオです：
サーバーに最大20文字の文字列を送信するクライアントアプリがあります。次に、サーバーは名前が実際に文字制限と一致しているかどうかを確認し、名前、時間、IPをsqlite3データベースに記録します。
私の問題は、自分のサイトを破壊することに一生懸命に取り組んでいるトロールを持っていることです。まず、追加されたユーザー名には保護やフィルターがありませんでした。 charフィルターを追加しました。また、IPアドレスごとに1つの名前のみを受け入れるようにしました。これですべてうまくいきましたが、今度はgetリクエストを行う前に毎回新しいプロキシを取得するボットを作成しました。
サーバー側でできると思う限り変更しました。クライアント側のアプリケーションパッチをロールアウトする必要があると思います。また、このプロセスは、クライアントアプリが閉じられるまで1分に1回行われることに注意してください。
Getリクエストがボットではなくクライアントアプリからのものであることを確認する必要があります。この男は、正当にサイトのCheeriosを使用しようとしている私の/誰にでも腹を立てることにかなり地味です。
アイデア1：ランダムなトークンチェックを作成する。プロセス：クライアントアプリ（短縮されたアプリ）はハッシュされていないトークン要求を送信し、サーバーはランダムな文字列で応答します。クライアントアプリは文字列をハッシュし、ハッシュされた文字列とハッシュされていない文字列でサーバーに返信します。サーバーはハッシュされていないものに対してハッシュを行い、ハッシュされたハッシュと比較します。すべてが一致する場合は、データベースに名前を追加します。
それに関する問題はA）ハッシュされていない文字列が一定期間に2回以上使用されないことを確認する必要がありますが、DBに追加し、Cronまたは何かを使用して時々データベースを削除することができます。 B）アプリとサーバーの両方で、ハッシュアルゴリズムを完全に保護する必要があります。彼らがアルゴリズムを破壊した場合（またはそれが使用しているハッシュ方式を特定した場合）、それを考慮したボットを構築できます。
私はキャプチャのようなものを使用しますが、それはgetリクエストを定期的に送信する単なるバックグラウンドスレッドであり、ユーザーとの対話はまったくありません。
ヘルプやポインタは大歓迎です。これだけ多くのテキストを読んでくれたらありがとう...
できません。それは残念ですが、あなたはできません。クライアントとして実行されているもの（TPMに関与していない状況がほとんどない場合）は、誰かが十分にやる気があれば、完全に理解できます。誰かがそれを逆アセンブルし、エミュレートし、パッチを当てることができます。これについてあなたができることはほとんどありません。
必要なことは、クライアントの認証ではなく、ユーザーの認証です。 OAuth2/OpenID Connect/similarを見てください。アプリを使用する前に、GmailまたはFacebookでログインできるようにしてください。これがバックグラウンドプロセスである場合、APIキーを取得するために（oauth2などを使用して）Webサイトに登録することを許可します。そのapikeyは彼らに固有であり、あなたにそれらを識別します。したがって、虐待を見た場合は、相手のgmail/facebook /何にでも結び付けることができます。
これを実行できない場合は、まあ、それを難しくするだけで立ち往生しています。あなたが彼らがあなたのアプリを逆コンパイルしてあなたのハッシュアルゴリズムを手に入れるのに十分な動機付けではないことを願うことができますが、長い目で見ればそれは勝てるゲームではありません。
HashCash
作業証明をシステムに組み込むことができます。たとえば、HashCashなどを使用して、サーバーにメッセージを送信するために1秒のCPU時間を費やすようにユーザーに要求します。このシステムは、メッセージと一緒にナンスを送信するようにユーザーに要求するのと同じくらい簡単で、ノンスとメッセージが一緒にハッシュされると、5の0で終了します。トレードオフがあります。クライアントアプリが1％のCPUを使用する場合、対戦相手は通常のユーザーの100倍のメッセージを送信できますが、これは多すぎる可能性があります。クライアントが100％cpuを使用している場合、対戦相手は通常のレートのメッセージしか送信できませんが、実際のユーザーは不快になります。
したがって、完全なシステムは次のようになります。
クライアント：
現在と同じ方法でGETリクエストを生成しますが、Nonceと呼ばれる追加のフィールドがあります。 GETリクエストをハッシュし、それがxのゼロで終わるかどうかを確認します。 xのゼロで終わらない場合は、新しいノンスをランダムに選択して、再試行してください。ある場合は、サーバーに送信します。
サーバ：
ハッシュされたときに正しい数のゼロで終わるGETリクエストのみを受け入れます。また、過去5分間にタイムスタンプが付けられたGETリクエストのみを受け入れ、最近受け入れられたGETリクエストのテーブルを保持し、それをチェックして、各リクエストが一度だけ受け入れられるようにします。
レート制限、プレーンでシンプル。
サービスの重要性を判断する必要があります。アプリケーションが依存するサービスの場合は、セキュリティを実装する必要があります。これは、ユーザーがブラウザからログインして、ファイルをホームディレクトリに保存するという形を取る場合があります。次に、アプリはファイルからAPIキーを読み取り、そのすべてのリクエストに署名します。
それがより分析的なタイプのサービスである場合、選択肢はあまりありません。 Google Analyticsでもスパムデータが含まれます。スパムを完全に殺そうとする前に、まずスパムの量を減らすことに集中してください。 IPから1分あたり5件以上のリクエストを送信している場合は、一時的にブロックします。最初に5分間の禁止を設け、次に15分間とします。 IPが禁止されたら、それをログに記録し、その直前に作成された他のエントリにフラグを付けます。そうすれば、できるだけ多くのボットデータを除外できます。さらに進んでサイトをCloudflareなどのサービスの背後に置く場合は、APIを使用してIPアドレスをブロックし、禁止された後にリクエストがサーバーにヒットしないようにすることができます。
ただし、「トロールユーザー」が十分に大きなボットネットにアクセスできる場合でも、 大企業は影響を受けやすい
IPアドレスごとに1つの送信のみを受け入れることは、非常に効果的なソリューションではありません。IPアドレスは、静的に個人に関連付けられていません。デバイスのフィンガープリント（特に、evercookiesやASNなどの他のアプローチと組み合わせた場合）は、IPアドレスの背後にいる人物をより正確に示します。何がと同じ問題であるように見えるかについての議論があります here 。アプリにフィンガープリントを適用する方法は、ブラウザとはかなり異なります。
ただし、そこでの議論とこの質問で欠落しているのは、サービスの価値についての説明ではなく、1つだけを行うことが期待されている場合に複数のリクエストを送信する人々の影響です。このサイトを検討してください。誰でもアカウントにサインアップできますが、サービス全体に付加価値を与えることができることを証明しない限り、他の人々の投稿を変更する権利はありません。アクションには属性があり、全員が[不承認]を示し、コメントする機会を得ます。ウィキペディアにもコンテンツ管理に対する同様の、しかしより正式なアプローチがあります。 slolorisおよびdns増幅攻撃に対処する非常に効果的な方法は、他のユーザーに影響を与えることなく、追加の負荷を処理するだけの能力を備えていることです。このアプローチで可能なことには制限がありますが、ここで追加のストレージが唯一の影響である場合、容量を追加してもそれほど高価ではありません（ただし、選択したsqliteバックエンドによって制限されます）。
攻撃の特徴が、同じIPアドレスからの、または同じアカウントに関連する送信の割合が高い場合は、動作を自動的に検出し、異なる方法で処理することでサイトへの影響を減らすことができます。ハッシュして保存するのではなく、ランダムな値で応答するだけです。
この人物の活動がサイトとサービスの性質にどのように影響するかについてさらに情報を提供していただければ、より広範な戦略についてより具体的なアドバイスを提供できるでしょう。
私はあなたがコメントでIPが類似していると述べたことに気づきました。この場合は、彼が使用していると思われるIP範囲を禁止できます。
専任であれば、その範囲外のIPを使用できます。詐欺師が言ったように、最善の解決策は、Gmail、Facebook、SMSなどを使用してユーザーを認証することです。
HashCashで提案されたQuadmasterXLIIなど、クライアントに作業を要求することができます。クライアントがサーバーよりも大幅に多くの作業を行っていること、および悪意のないユーザーに要求された作業が受け入れられることを確認してください。
または、パッチの継続的な戦いと戦い、一歩先を行くことができます。これらは、私が試してみる順に表示されるオプションです。
一般的なヒント：クライアントに何を置いても、シミュレーションできます。
私はキャプチャのようなものを使用しますが、それは単にgetリクエストを定期的に送信する単なるバックグラウンドスレッドであり、ユーザーとの対話はまったくありません。
しかし、ウイルスを作成しているのでない限り、誰かが意図的にこれを設定します。その時点で、クライアントを登録し、プロセスの一部としてCAPTCHAを入力することができます。 （たとえば、各クライアントはサーバーからセッショントークンを取得し、CAPTCHAが正しく入力されたかどうかを格納するだけです。）
使用できるIPアドレスの数に制限はありません。 IPv4では、スパマーが使用するIPアドレスを禁止し、そのサブネットにフラグを立てる必要があります。 IPv6では禁止する必要があります/64sし、そのサブネットにフラグを立てます。
たとえば、80.100.131.150はあなたにスパムを送信していたので、そのアドレスとフラグを禁止します80.100.0.0/15（Linuxの場合whois 80.100.131.150 | grep ^routeが表示されます）。多くの場合、ホームIPアドレスは毎晩ローテーションされ、VPS所有者は（1つを選択するかランダムに）新しいアドレスを割り当てることができますが、ISPは有限数のサブネットを所有しています。このようにして、スパマーにIPアドレスを更新するためのアクションを強制します。IPアドレスが更新されても、フラグが立てられたサブネット内にいる可能性があります。
フラグのあるサブネットは、追加のCAPTCHAを取得します。登録時のCAPTCHAは1つではなく5つ（またはそのようなもの）。サブネットが2つまたは3つのフラグを収集したら、完全に禁止します。サブネットの不正使用アドレスをメールで送信した場合のボーナスポイント。
メールアドレスなど、これを使ってできる有限のリソースがあります。ユーザーがメールアドレスをアクティブ化するためのわずかな労力ですが、サブネットとメールドメイン（たとえば、mail.ru）の両方にフラグがあるため、20のCAPTCHAを入力する必要がある場合、スパマーは疲れます。
死傷者が出ることに注意してください。スパマーと同じISPを使用している人も（十分な数のフラグを収集すると）禁止されます。