web - ログイン要求の洪水を防ぐ簡単な方法は?

Question

Web サイトでログインに POST フォームを使用している場合、悪意のあるクライアントが POST 要求で Web サーバーをフラッディングさせてユーザー アカウントをブルート フォースでクラックしようとするのを防ぐ迅速かつ簡単な方法は何ですか?

PHP/MySQL/アパッチ。

Answer 1

ブルート フォース クラッキングを防止することは、最初は思われるよりも難しいことです。解決策は、コントロールを組み合わせることです。単一のコントロールではマスタードをカットできません。そして、目標を思い出してください。ブルート フォース攻撃が無効になるか、またはそれを検出してアクションを実行できるようになるまで、ブルート フォース攻撃の速度を落とす必要があります。2 番目のオプションは、通常、最初のオプションよりも効果的です。

キャプチャを使用することもできますが (これは現在一般的な手法です)、多くの場合、キャプチャは自動的に読み取られます。コンピューターで読み取ることができない場合は、低賃金の労働者に支払うか、キャプチャを使用して人々の農場を取得できます。 「無料」のポルノを保護するため (両方の手法が使用されています)。

フォームで秘密の値を使用するという他の人のアドバイスは、実際には役に立ちません。攻撃者は、HTML を解析して秘密の値を見つけ、それを投稿に含めるだけです。これは自動化するのが非常に簡単なので、実際には良い防御策ではありません。ああ、値が簡単に予測可能であることが判明した場合 (PRNG が貧弱または壊れているか、悪いシードを使用している場合)、再び小川を上っています。

IP アドレスの追跡は問題ありませんが、NAT をサポートしていない場合に限ります。NAT を使用すると、有効なユーザーが重複しているように見えます。また、攻撃者は他のシステムになりすます可能性があることに注意してください。1 つの攻撃システムが他の IP アドレスを使用し、そのシステムへのトラフィックを傍受することさえできます (ARP ポイズニングは、これに適したメカニズムの 1 つです)。

一定時間内に失敗したタイムアウトの最大数を使用できます (1 時間以内に 3 回など)。これにより、攻撃者の速度は低下しますが、必ずしも停止するわけではありません。自動ロック解除を含めることもできますが、計算を行い、ロック解除時間が実際に役立つことを確認する必要があります。

指数バックオフは、もう 1 つの便利なメカニズムです。これは、セッション (攻撃者がサーバーに戻る必要がない) を IP アドレス (NAT との間で切断) またはアカウント (複数のアカウントにわたるブルート フォースを考慮していない) に関連付けることが可能である可能性があります。 .

他の防御策を有効にするには、強力なパスワードが必要です。パスワードが推測しやすい場合 (辞書に載っているか、短いか、複雑か)、攻撃は成功します。最小限のパスワード強度要件と、「不正なパスワード」辞書 (その辞書の一般的な文字置換と組み合わせて) を実装することをお勧めします。または、OATH、証明書ログイン、ハードウェア トークン (RSA の SecurID など) などのシステムを使用することもできます。

クライアントのパズルについて話し合ったのはバート・カリスキーだったと思います。基本的に、サーバーにとっては簡単でクライアントにとっては難しい課題をクライアントに与えます。クライアントは、パズルを解こうとして自身のリソースを浪費することで DoS を実行します。ここで難しいのは、パズルの適切な複雑さを決定することです。たとえば、大きな数を因数分解する場合などです。それが何であれ、可能な限り最も効率的なアルゴリズムを想定する必要があり、異なるマシン上の異なるブラウザーの異なるパフォーマンスを処理できなければならず (遅くなる可能性があります)、ブラウザー外での自動化された攻撃を遅くします (潜在的により速い)。あなたのJavaScript）。JavaScript でソリューションを実装する必要があると言いましたか?

しかし、まだ複数のアカウントにまたがる攻撃に悩まされています。IPアドレスを追跡できない限り、これに対してうまく機能する公に使用されているコントロールを知りません.

次に、ユーザー名を保護する必要があります。ユーザー名を知らない (ユーザー名がいつ有効かを示さないシステムを必要とする) 攻撃者は、ユーザー名を簡単に確認してパスワードを攻撃するのではなく、ユーザー名とパスワードの両方を知る必要があります。

また、エラー メッセージやサーバーのタイミングによって、有効なパスワードが (無効に) 表示されないように注意する必要があります。

また、エラー メッセージに対処するときは、パスワード回復メカニズムが何も提供しないことを確認してください。それ以外の点では優れたシステムであっても、パスワードの回復によってすべてが台無しになる可能性があります。

しかし、そうは言っても、攻撃は最終的にサーバーのパフォーマンスに依存しています。認証のために非常に遅いメカニズムを実装するだけかもしれません (有効な認証と無効な認証の両方で遅くする必要があります)。オンライン攻撃は、サーバーがリクエストを処理できる速度より速く進まないことが保証されています。

次に、ブルート フォース攻撃を検出する必要があるため、システムには適切な監査証跡が必要です。ただし、ログ メッセージを記録しすぎないように注意する必要があります。そうしないと、ディスク スペースをいっぱいにして、サーバーを簡単に操作できるようになります。syslog の「前のメッセージを 1000 回受信しました」というメッセージのようなものがよいでしょう。

すべての設計が完了したら、また実装が完了したら、システム全体とシステムのすべての機能を調べ、現在の設定とサーバーのパフォーマンスを考慮して数学的にモデル化し、攻撃者が (a) 単一のアカウント、および (b) 任意のアカウントをブルート フォースする (アカウント固有の制御を回避するための複数のアカウントにわたるブルート フォース) のにかかる平均時間。

Answer 2

1 つのアプローチは、各リクエストの IP アドレス (または IP アドレスの最初の 3 オクテット) を追跡し、より多くの IP からのリクエストへの応答にかなりの時間を追加する (またはドロップすることさえある) ことです。過去 y 分間で x 件のリクエストよりも多い。

これは、分散型攻撃に対しては効果がありません (または効果が低くなります)。

より強力な保護のために、一定期間、そのような IP へのアクセスを体系的に拒否することにより、問題のある IP (IP、または IP の最初の 3 オクテットで、過去 2 分間以内に 6 回以上の不正な試行を送信したもの) をブラックリストに登録することもできます。 15分と言います。

Answer 3

ログイン試行の送信元の IP がわかっている場合は、5 回の試行を許可し、その IP を 5 分間の「クールオフ」期間待機させることができます。5 分では短すぎると思われる場合は、より適した時間になるまで延長してください (必要に応じて 24 時間、またはそれ以上になることもあります)。ボットネットに多数の調整されたノードがある場合、これはうまく機能しない可能性があります。