web-dev-qa-db-ja.com

サーバーをブルートフォース攻撃から保護する方法は？

最も一般的なサイバー攻撃の1つはBruteforceです。この攻撃を保護するために利用できるメカニズムは何ですか。また、攻撃を軽減するために業界がこれらのメカニズムをどのように適用するか（ベストプラクティス）？

brute-forceserverdefensecredentials
5
Ihebhamad

ブルートフォース攻撃には2つの側面があります。 1つは一連のパスワード推測によって資格情報を回復する方法で、もう1つは大量の試行を開始してサービス拒否（DDoS）を作成する方法です。

1つのコントロールだけを実装するのは適切でない場合があるため、攻撃を緩和するために業界では組み合わせで複数のメカニズムが使用されています。

可能な緩和策は次のとおりです。

  • 継続的なログイン失敗に基づくアカウントのロックダウン
  • 複数のログイン失敗後の認証プロセスの一時停止の作成
  • ブロッキングIP –複数のアカウントに対して複数のログイン試行が開始された場合
  • 特権の高いユーザーが特定のIPからログインできるようにする
  • IPアドレスからの複数のユーザー名でのログイン試行
  • 一度に複数のIPを形成するアカウントへのログイン試行時にトラフィックを抑制/ブロックする
  • デバイスのCookieを使用して推測を遅くする（参照： https://www.owasp.org/index.php/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies ）
  • CAPTCHAを使用して自動攻撃を防止する
  • 2要素認証を使用して攻撃を防ぐ

さて、コントロールの組み合わせを使用することが重要である理由は、正当なユーザーが影響を受けたり、リソースへのアクセスを妨げられたりしないようにすることです。

たとえば、「複数回失敗した後のアカウントロックアウト」のみを実装した場合、攻撃者はこのコントロールを悪用し、一連のブルートフォース攻撃を送信するだけで、何千ものユーザーアカウントをロックアウトできます。その結果、これはDDoSであることが判明し、正当なユーザーはリソースへのアクセスに苦しむことになります。

したがって、ブルートフォース攻撃の影響を防ぐための要件のコンテキストに基づいて、上記のコントロールを組み合わせて使用​​することを常にお勧めします。

5
Sayan

ブルートフォース攻撃を防ぐには、次のアプローチを使用できます。

スリープを介してログイン試行を人為的にスローダウンします。

これは、PHP Webサイトでは幾分一般的でした。これに関する問題は、もちろん、Webサーバーでいくつかのリソースを消費することです。

キャプチャを使用

ログインがキャプチャを解決する必要があることを要求します.

レート制限

iPごとにレート制限を行うこともできますが、NATもあります。これにより、一部のエンドユーザーにとってこれはやや面倒です。さらに、他の種類のデバイスフィンガープリントを使用して、ブロックしないようにすることもできます。ユーザーが多すぎます。

二要素認証

電子メールでこれを行うこともできます。一部のエンドユーザーはこれを嫌います。ログインするにはメールを今すぐ確認する必要があるためです。

10回の試行後にアカウントをロックし、ユーザーに電子メールでアカウントのロックを解除するよう要求する

ある程度実現可能ですが、これは攻撃者が常にアカウントをロックアウトできることを意味します。

編集：また、フィッシングの可能性がいくつかあります（コメントに感謝）

ハッシュキャッシュ

本当に広く採用されることはありませんでした。基本的に、クライアントにハッシュを部分的に「クラック」するように要求します（最初のnビットを指定し、クライアントがそれらのnビットで始まるハッシュを持つ入力を見つけることを要求します）。これを任意に難しくすることができます（最近のコンピューターの1など）。

欠点：クライアントからより多くのCPUパワーが必要です。また、サーバーからのCPUパワーも消費するハッシュを確認する必要があります（ただし、クライアントからの場合よりもはるかに少ない）。

問題を外部委託

Facebook、グーグルなどを介してログインを使用してください。常にオプション...常に最良の選択とは限りません。

ユーザーがこれらのWebサイトにアクセスしたサイトに関する情報を漏らしてしまう可能性があるため、誰もがこれを気に入っているわけではありません。 （EUにいる場合もGDPRに準拠していない可能性がありますか？）

「人間」の検出

キャプチャ以外にも、ユーザーエージェントの確認、参照の確認、ブラウザがサポートする機能の確認など、人間とは別にボットに伝える他のアプローチがあります。しかし、とにかくすでにそうしている既存のキャプチャプロバイダを使用する方がおそらく簡単です。

Divを互いに積み重ねてCSSでスタイルを設定し、JSでそれらを変更して、適切な「ログイン」だけが表示され、他は表示されないようにするなど、これで本当に創造的になることができます。これは、ボットが伝えるのが難しいことを意味しますどの「ログイン」が正しいものか。ボットと人間を区別する方法を考え出すのは楽しいですが、繰り返しますが、既存のCAPTCHAサービスを使用する方が一般的に簡単です。

また、アクセシビリティを念頭に置いて...画像のみのCAPTCHAを使用すると、一部の人々は使用できなくなります。優れたCAPTCHAプロバイダーは、少なくともオーディオCAPTCHAも提供します。だから...あなた自身のCAPTCHAを作成しないでください。次に、スクリーンリーダーがあります。「人間を検出する」と干渉する可能性があります。 （うーん、そのような外部CAPTCHAプロバイダーの使用がGPDRに準拠しているかどうかわかりませんか？）

ネットワークレベルのスロットル

適切なインフラストラクチャがあれば、これを行うことができます。あなたがホスティングプロバイダーを持っている場合、彼らはとにかく（一般的なDoS保護として）あまりに多くのリクエストの後ですでにこれをしているかもしれません。

ハニーポッティング

誰かが実際にこれを行っているかどうかはわかりませんが、基本的にアカウントがブルートフォースされていることが確認されたら、ログイン試行の1つを成功させ、ログインが成功したことをボットに確信させる偽のWebサイトを提供します実際に成功。

3
mroman

ブルートフォースを無効にできる方法は多数あります。2要素認証、CAPTCHA、レート制限、そしてもちろん、pwの複雑さの要件はいくつかあります。

「何を使用すればよいか」という答えは、リスクモデルに基づいています。あなたがハックする時間と労力に値しない小さなサイトであるなら、レート制限や複雑さのルールは十分すぎるかもしれません。 Amazonのようなeコマースサイトで大量の機密データを使用している場合は、2FAの方が関連性が高いかもしれません。

最初に何を実行できるかを検討し、次にその中で、リソースとリスクレベルを考慮して何を実行するのが妥当かを検討する必要があります。

1
Angelo Schilling