マイニングを使用してWebSocketへのDDOS攻撃を防止：これは実行可能なソリューションですか？
私は次の方法が私のサーバーでddosを完全にそして完全に防ぐための良い方法であるかどうか考えています。私の考えは、DDOSを防ぐために、暗号通貨マイニングと同じメカニズム（ビットコイン、sha256またはその他のハッシュ）を使用することです。
注：暗号通貨自体をマイニングすることはお勧めしません。同じメカニズムを使用して Sybil attack を回避することをお勧めします。
アイデアが魅力的に見えるのはなぜですか？マイニングされたハッシュの作成はコストがかかりますが、検証は非常に簡単です。ハッシュの計算は1回だけです。
一言で言えば、マイニングとはどういう意味ですか？特定のデータチャンク（たとえば、セッションID、またはJWTトークン）があることを意味します。サーバー（パフォーマンスの高いNoSQLサーバー）に保存され、ユーザー（または暗号通貨のマイナー）は特定の基準に一致するハッシュを作成する必要があります。たとえば、SHA256を使用する場合は、難易度を、ハッシュから得られる256ビットの数値の先行ゼロの必要数として定義できます。より多くのゼロはそのハッシュを見つける確率をより困難にします。
どのように機能しますか？：ユーザーはセッショントークン（サーバーによって作成されます）を取得し、それを nonceと組み合わせます （数値は1回使用されます）、フロントエンドでハッシュを計算します（WASM、またはJavaScriptを使用）。ユーザーはSHA256をリバースエンジニアリングできないため、必要な困難を満たすハッシュを作成するnonceが見つかるまで、nonceを何度も何度も変更し続けることができます。
グラフは、ビットコインでブロックを見つける（正しいナンスを見つける）確率を示しています。ここでは、難易度を選択して10分にします。難易度を変更すると、この曲線がシフトし、その幅が比例して変更されます。
サーバーが検証するのにどのくらい時間がかかりますか？実質的にゼロです。ハッシュを1回計算し、それが特定の難易度に一致していることを確認し、ユーザーが匿名リクエストを行うことを許可します。これには、ユーザー名とパスワードによる認証は必要ありません。これはすべて匿名です。認証されたユーザーは、資格情報をシステムから禁止できるため、これを行う必要はありません。これはすべて匿名ユーザー（および場合によっては攻撃者）向けです。
結果：ユーザーは、サーバーにリクエストを送信する前に、この困難さでこのハッシュを計算する必要があります。ユーザーが成功すると、マイニングされた認証トークンをCookieに保存して、ユーザーが再利用できます。ユーザーが要求されたハッシュの提供に失敗した場合、ユーザーの接続要求は突然拒否され、sock-puppetsによるDDOS攻撃が防止されます。
[〜＃〜] asic [〜＃〜] 抵抗：計算できる専用のハードウェアがあるため、SHA256の使用は推奨されません非常に高速で、協調攻撃の可能性があります。 ScryptやArgon2などのハードウェアでは印刷が難しいハッシュがあります。
難易度の選択：難易度は静的にすることも（推奨しません）、または動的に変更してネットワークの負荷に応じて変更することもできます。高いネットワーク負荷が存在する場合、必要な難易度が高くなります。これは基本的にフィルターとして機能し、DDOS攻撃時にネットワークを保護します。ユーザーは通常、セッションを作成するために10秒間待つ必要がないため、ユーザーに影響を与えることはありません。負荷が非常に高い場合、ユーザーは高価なナンスを計算するか、後で戻ってくるかを選択できます。ホスティング会社は、時間の経過に伴う難易度チャートに基づいて、インフラストラクチャの拡張が必要かどうかを決定することもできます。
これは、WebSocketや同様のパブリックプロトコルでDDOSから保護するための適切な計画ですか？これを私のサーバーに実装したいと思います。
編集：明確にするために、これはあらゆる種類のDDOSにとって特効薬ではありません。しかし、これにより、ユーザーがサーバーの内部機能を操作できなくなり、サーバー機能を使用して帯域幅を使い果たすことが難しくなります。これが新しいか古いかについての要約よりも、なぜこれが機能するのか、機能しないのかを知りたいと思います。
TL; DR：これは一般的なDDOSに対するソリューションではありません。これは、非常にアプリケーション固有のDOSに対する保護になる可能性があります。
あなたのアイデアがすべてのマイニングのものを取り除くことは、本質的にクライアントがサーバーに接続していくつかの難しい解決タスクを取得し、後で戻ってこのタスクの簡単に検証できるソリューションを提示することを意味します。
このアプローチの問題は、クライアントが最初にサーバーに接続する必要があり、サーバーがクライアントにタスクで応答できる必要があることです。これは、上流のシステムまたはサーバーが処理できるより多くのトラフィックを送信するだけの最も一般的な帯域幅指向のDDOS攻撃からあなたのアイデアを保護できないことを意味します。また、サーバー自体のリソースを使い尽くそうとする単純なDDOS攻撃、つまり SYNフラッディング または Slowloris のようなものに対しても役立ちません。
実際には、処理の後の段階をターゲットとする攻撃、つまりアプリケーション固有の攻撃を防ぐことができます。しかし、それは実際にはこの分野での新しいアイデアではなく、本質的に単なる別の Proof of Work System であり、長年にわたって知られています。
したがって、ここではアプリケーションレイヤーのDDoS攻撃のみについて説明します。
あなたが提案するものは、 仕事の証明 である限り長く知られています。この一般的なアプローチをアプリケーション層のDDoS攻撃に対抗するために多くの試みが行われましたが、ほとんど成功しませんでした。
基本的に、疑わしいボットに対して導入する課題は単純で、カップルから数十秒で完了するのに十分短いか、非常に長い時間がかかります。
最初のケースでは、典型的なボットネットは何千ものマシンを制御していると考えられており、攻撃者はそれらのマシン上のすべての計算リソースを無料で取得します。それらすべてのマシンに約10秒間だけsomethingを強制的に計算させても、攻撃を防ぐことはできません。
他のシナリオでは、正当なユーザーがページが読み込まれるまで数分待つことはめったにないため、Webサイトなどのほとんどすべての顧客を失う可能性があります。実際、人気のあるWebサイトは現在、ページ読み込み時間のミリ秒を争っており、その目的のために多数の手法（CDN、0-RTTなど）を導入しています。したがって、正式にはサーバーが悪意のある要求で溢れることはありませんが、最終結果は実質的に同じになります。
一部の特定のアプリケーションでは、理論的には、あなたが考えているのと同様の手法を実装する理由がいくつかある可能性があります。しかし、任意のWebサイトの場合、残念ながら、うまく機能しません。