総当たり攻撃から保護する方法
総当たり攻撃に対する防御策をどのように適切に実装しますか？ Xの試行後に誰かがログインを試み、それらをブロックしようとした回数を保存するのが最善ですか？そして、「誰か」はどのように識別されますか？セッションで？ IP？
アカウントのロックアウトは1つのオプションで、ログインがx回失敗した後、アカウントが永続的にまたは一定期間ロックされます。ここでの問題は、攻撃者がパスワードを推測しようとした場合のサービス拒否のリスクと、アカウントのリセットの管理オーバーヘッド（自動リセットが利用できない場合）です。
別のオプションは、CAPTCHAをログインプロセスに導入することです。これは、自動化された攻撃を制限し、アカウントのロックアウトによるサービス拒否を阻止することを目的としています。それに関する問題は、アクセシビリティ要件と自動化されたCAPTCHAクラッキングである可能性があります。私が見たところでは、一部のCAPTCHAは他のソフトウェアよりもソフトウェアのクラックが簡単です。
3番目のオプションは、ログインプロセスに漸進的な遅延を導入することです。これにより、間違ったログが記録されるたびにプロセスが遅くなります。これは実際のユーザーへの影響は限定的ですが、ブルートフォースの自動化をはるかに困難にします。
攻撃を行っている「誰か」を特定することに関する質問の2番目の部分に関しては、攻撃の内容によって異なります。 1人のユーザーを攻撃しているだけの場合、ユーザー名は識別子であり、アクションはそのアカウントに関連付けられています。広範囲のユーザーに対してブルートフォーシングを行う場合、ソースIP（おそらくブラウザーエージェントと組み合わせる）はオプションです。それは完璧ではありません（例えば、ボットネットの使用、エージェントのなりすまし）が、おそらくあなたが続けなければならない唯一の情報です。
ブルートフォースを否定する答えは、多数の試行を拒否することです。ここで、試行回数はキースペースとリスクの受け入れによって定義されます。
それぞれの状況で異なる解決策が考えられます。
肉のスペース
- ドアはブルートフォースによる損傷に対して強化されています。
- ドアに衝突することは、警察に警告する機会によって軽減されます。
- キーには約5つの変数しかありませんが、各キーを1つ持つにはリソースが必要です（ブルートフォースではない他の方法でロックを攻撃する方が簡単です）。
コンピュータ
- ブルートフォース攻撃を自動化するには、何らかの方法でレート制限を行う必要があります。レート制限を使用すると、一定の時間にわたる試行の上限を確実に知ることができます。
- 監視：ブルートフォースの試行を特定のレート（おそらく500 /日）に制限できる場合、監視とアラートにより、何が起こっているのかを詳しく調べるように通知できます。特定のレベルの許容できないリスクに達するには、何回の試行が必要ですか？
- 大きなキースペース：複雑なパスワード要件があると、パスワードを特定の確率で見つけるために必要な試行回数が大幅に増える可能性があります。
- 2要素認証：この場合、パスワードの総当たりでは不十分です
すべてのソリューションには、人生の他のすべてと同様にトレードオフがあります。
- レート制限：正当なユーザーにDoSを実行できますが、最初に攻撃が広範である場合は効果的ではありません。2回試行する前に、アカウントごとに1回試行します。
- IPによるレート制限：分散攻撃の場合は効果的ではありません
- パスワードの複雑さ：通常、ユーザビリティのトレードオフです。つまり、ユーザーはパスワードを書き留めます-総当たりの脅威よりもセキュリティを大幅に低下させます
- 2つの要因：高価と見なされる可能性があり、トークンを失う可能性があります
重要なことは、「誰か」をどのように識別するかです。
IPアドレスでそれを行うことはできません-多くのユーザーが同じクライアントアドレスを持っているように見える可能性があります（これは、IPV4アドレス不足の問題が継続することでさらに頻繁になるでしょう）。
1人のユーザーが複数のクライアントアドレスから接続しているように見える場合があります。 Torを介してAOLの負荷分散プロキシを使用するか、それほど正当ではありません。
それ以外のものはクライアントから提供されるデータです。そのため、クライアントは設定したCookie、ユーザーエージェント文字列などを変更する可能性があります。
唯一の実用的なアプローチは、要求にヒューリスティックスコアリングを適用して、以前の試行と照合しようとすることですが、高度な攻撃と正当なユーザーを区別することは依然として不可能です。
クライアントがサイトをブルートフォースで攻撃しようとしていると見なすスコアのしきい値を設定します（-20など）。
セッションCookie（ユーザー名/パスワードの入力を求めるページで設定されているnotである）が参照する現在の有効なセッションを要求することが開始です-Cookieに認証の詳細が表示されていない場合は、別のリダイレクトにリダイレクトしますCookieをドロップし、スコア-10、および（たとえば）スコア2でセッションをクライアントIPアドレスに初期化するページ。同じアドレスから複数の有効なユーザーが表示されるようになると、動的スコアリングメカニズムを使用できます。同様に、ユーザーエージェントとユーザー名による動的スコアリングを維持できます。
存在しないユーザーにcookie + authが提示される場合は、セッションに-5、クライアントアドレスに-1、ユーザー名に-5のスコアを追加します。
Cookie + authに無効なパスワードが提示された場合、セッションに-3、クライアントアドレスに-1、ユーザー名に-4のスコアを追加します。
Cookie + auth + valid passwordがクライアントアドレスのスコアから+4、ユーザー名に+3、ユーザーエージェントに+2を追加する場合。
注意：クライアントアドレス/ユーザーエージェント/ユーザー名に対して保持されているスコアが回復するように減衰を設定する必要もあります。たとえば、+ 2 /時間
スコアがしきい値を超えるとどうなるかを考える必要があります。誰かがあなたのサイトへのアクセスをブロックするためのメカニズムを提供しましたか？
特定のユーザー名のスコアが高いアクセスをブロックしている場合は、そのアカウントの登録ユーザーにリセットURLを記載したメールを送信して、ユーザー名の保留スコアをリセットし、ユーザーエージェントの保留スコアを削減できるようにします/住所。
私が提案するように、あなたはウェブアプリケーションでログイン/パスワードを総当たりにすることを意味します。
誰も手動で総当たり攻撃を行うことはありません。したがって、これが認証を試みる人間であることに疑いがある場合は、たとえば、3-dの失敗したログイン試行からCaptchaを見せてください。さらに、ログイン試行の間にタイムアウトを設定できますが、これは異なるIPからの分散型攻撃には機能しません。次に、ブルートフォーシングには2つのタイプがあります。ブラインドフォース、ランダムなログイン/パスワードの試行、および一部のユーザーに対する攻撃です。前回の攻撃では、しばらくの間アカウントをブロックしたり、メールでユーザーに通知するなどの機能を実装することが効果的です。特にサイトが人気がある場合、盲目的なブルートフォースの緩和策を実装するのは難しい場合があります。この場合、IP /国/ブラウザ/その他のようなユーザー情報を追跡でき、これの組み合わせを理解することで、これが有効なユーザーであるかどうかを推測できます。これの補遺として、ユーザーはログインに成功したらCookieを保存し、後で確認するために、長持ちするCookieを試すことができます。
Webアプリケーションタイプのソリューションがなければ、Apacheのmod_evasiveのようなサーバーレベルのソリューションを実装することが可能です。または、特にそのような目的のために、独自のWebサーバーモジュールを作成することもできます。
確かに、ブルートフォース攻撃の緩和策を強化する方法は他にもたくさんありますが、多くの場合、ノイズが多く、役に立たず、厄介です。 KISSを使用してください。
以前のログインとログイン試行の長いIPを保存します。
Nが失敗した後、キャプチャに対してそれらを置きます。
履歴にログインが成功せず、試行回数が多いアドレスをすばやくブロックします。
同時送信元アドレスまたは非人道的な速度/スタミナラピッド試行があるアドレスをすばやくブロックします。
また、これらの回答はいずれも、攻撃者が1つのパスワードを使用してすべてのアカウントに対してそれを試行するブルートフォースの方法、通常のプロセスの逆転、および一般に保護されていないものを考慮に入れていません。
もちろん、同じパスワードで異なるアカウントに対して複数の試行を監視するプロセスを持つこともできますが、そのIPをブロックするのと同じように、単一のアドレスからのものであってもブロックするのは非常に難しいですか？それは有効なユーザーでも使用できますか、またはそのパスワードでログインを削除しますか？そのパスワードで有効なユーザーをロックアウトするリスクがありますか？
そしてもちろん、攻撃者がこのようなことを分散ネットワークから実行したり、長い時間枠で実行したりする場合、どのようにしてインシデントを攻撃プロファイルに関連付けますか？
一般的な業界メカニズムにはロックアウトが含まれます
- 直接試行時（3以上、通常20未満）
- 漸進的な遅延
- 分散された総当たり攻撃のように見えるインシデントをブロックする統計ツール
まず、処理するシナリオ/攻撃を理解することは理にかなっています。
- 有効なユーザーが誤って間違ったパスワードを入力しました
- 有効なユーザーは実際にパスワードを忘れました-考えられることなら何でも手動で試してみてください
- 攻撃者が手動で他人のパスワードを推測しようとしている
- 攻撃者は自動化ツールを使用して、特定のユーザーのパスワードを総当たりする
- 攻撃者は自動化ツールを使用して、可能なすべてのユーザーのパスワードを総当たり攻撃します（つまり、幅優先検索）。
- 攻撃者は特定のユーザーがサイトにアクセスするのをブロックしたい
- 攻撃者はほとんどのユーザーがサイトにアクセスするのをブロックしたい
- 攻撃者は、管理者によるサイトへのアクセスをブロックしたい
- 攻撃者は、多くの手動作業を作成するか、他の方法で組織に多くのコストをかけたいと考えています。
（参照してください。それほど単純ではありません...）そして、これらの各部分には異なるソリューションがあります...
- ユーザー名のリストを公開しないでください。簡単にしないでください...これには、ログインを拒否するときに、ユーザー名が有効かどうかを明らかにしないことが含まれます。
- 強力なパスワードポリシーが必要-長くて複雑。
- 「パスワードを忘れた」メカニズムを簡単かつ目立たせます。 （もちろん、それも安全であることを確認してください）。
- ログイン要求が失敗するたびに、これをデータベースに記録します。ユーザー名、IPアドレス、時間などを必ず記入してください。
- 特定のユーザー名に対して多数の失敗したリクエストを受け取った場合は、データベース内のそのユーザーを短時間ロックされているものとしてマークします。また、これが同じセッションにある場合は、「パスワードを忘れた」機能を使用するようにユーザーに勧めます。
- 失敗したリクエストの数は？ 状況による 。要するに、サイトにとって意味のあるものは何でも、正確な数は重要ではありません。
- ユーザーをどのくらいの期間ロックする必要がありますか？短い間隔。数学的には、強力なパスワードポリシーを持っている限り、それはそれほど重要ではありません。現実的には、数分という非常に短い間隔で開始し、それが続く場合は徐々に長くします。例えば。 5回の失敗の後、5分間ロックします。さらに3回の不正な試行の後、15をロックします。さらに2つ後、30をロックします。等.
- ユーザーアカウントを永続的にロックしないでください。これはアカウントDoSにつながります。また、サポート担当者に多くの時間と費用がかかる可能性もあります。
- 以前のポイントにもかかわらず、サイトが非常に非常に敏感な場合、たとえばバンキングアプリの場合は、さらに通知があるまで永続的にロックすることを検討してください。顧客に彼の支店に来てもらいます。
- データベースのロックは、ユーザー名で行う必要があります。 sessionIdによってでなく、Webサーバーセッションではありません。
- 異なるユーザー名で多くの失敗したリクエストを受け取ったが、同じIPアドレスからの場合-上記のように、より長い猶予と短い間隔で増分ロックを実装します。
- パスワードを忘れた場合に加えて、「ユーザー名を忘れた場合」機能を提供します。
- 管理者アカウントは、猶予期間を短くし、間隔を長くして、永久にロックアウトしないようにする必要があります。
- いずれにしても、ユーザーまたはIPをロックするときに、管理者にアラートを送信します。ただし、繰り返しロックするためではありません。管理者の受信トレイをあふれさせたくありません。ただし、継続する場合は、数回後に警告レベルを上げてください。
- CAPTCHAは使用しないでください。ユーザーのパスワードにアクセスすることの価値に関して、最小限の難しさはささいなことです。 （それを回避する方法はたくさんあります。CAPTCHAは基本的に 実装に関係なく壊れています ）。
- もちろん、@ rox0rが述べたように、多要素認証が適している場合があります。
- 別の方法として、「適応認証」と呼ばれるものがあります。ユーザーがログインに失敗した場合は、追加情報（事前登録されているもの）を尋ねます。追加のリスク要因（場所、通常とは異なる時間パターンなど）に応じて、認証を成功させるために必要な情報をエスカレーションします。たとえば、RSAのAdaptiveAuthentication製品がこれを行います。
ビジネスWebサイトの場合は、証明書とパスワード認証を使用します。有効な証明書がないと、パスワードを推測することはできません。証明書の代わりにRSA SecurIDなどを使用することもできます。