[解決済み] 分散ブルートフォースへの最適な対策は？

質問

まず、背景を少し説明します。私がCodeIgniterに認証システムを実装していることは周知の事実で、今のところ私は（いわば）勝利を収めています。しかし、私はかなり非自明な課題(ほとんどの認証ライブラリが完全に見逃しているものですが、私はそれを適切に処理することにこだわります)にぶつかりました：どのようにインテリジェントに 大規模、分散、可変ユーザー名ブルートフォース攻撃 .

いつものトリックをすべて知っています。

1. IP/ホストごとの失敗した試行回数を制限する と犯罪者のアクセスを拒否する (例: Fail2Ban) - これはもう機能しない ボットネットがより賢くなったため
2. 上記を組み合わせて ブラックリストと組み合わせることで、既知の「悪い」IP/ホスト (例: DenyHosts) - これはボットネットが #1 に引っかかることを当てにしています。 に該当するボットネットに依存するもので、ますますそうではなくなってきています。
3. IP/ホストホワイトリスト 従来の認証との組み合わせ (悲しいかな、動的な IP ユーザーと、ほとんどの Web サイトの高い解約率では役に立ちません)
4. を設定する。 サイト全体の制限 を設定し、その後何分間/何時間かの間、すべてのログイン試行をスロットリング (停止) します (DoS 攻撃がボットネットの子供の遊びになってしまうという問題があります)。
5. 必須 デジタル署名 (公開鍵証明書) または RSA ハードウェア トークンを、ログイン/パスワード オプションなしですべてのユーザーに提供すること (間違いなく強固なソリューションですが、閉鎖的で専用サービスの場合にのみ実用的です)。
6. 強制 超強力なパスワード スキーム (例: >25 nonsense characters with symbols - again, too impractical for casual users)
7. そして最後に CAPTCHAs (ほとんどの場合うまくいくかもしれませんが、ユーザーにとっては迷惑なもので、また は事実上無意味です。 に対して 決意のある、機知に富んだ攻撃者 )

さて、これらは理論的に実行可能なアイデアにすぎません。以下のようなものがあります。 たくさん には、(例えば些細な DoS 攻撃に対して) サイトを大きく開放してしまうような、くだらないアイデアがたくさんあります。私が欲しいのは、より良いものです。そして、より良いものというのは、つまり

• DoS 攻撃やブルートフォース攻撃に対して安全 (+) でなければならず、また、少しばかり狡猾なボットがレーダーの下で活動を続けることを可能にするような新しい脆弱性を導入してはならない。

• 自動化されていなければなりません。各ログインを確認したり、疑わしい活動を監視したりするために人間のオペレーターが必要な場合、現実のシナリオではうまくいきません。

• 主流の Web 用途として実現可能でなければならない (すなわち、高い解約率、高いボリューム、および非プログラマが実行できるオープンな登録)

• カジュアルなユーザーがイライラしたり不満を感じたりするほど、ユーザー エクスペリエンスを阻害してはならない（そして潜在的にサイトを放棄する）。

• 子猫が登場することはできません。 本当に本当に安全で 子猫

(+) 安全」というのは、少なくとも偏執狂的なユーザーが自分のパスワードを秘密にしておくのと同じくらい安全であるという意味です。

では - 聞かせてください! あなたならどうする？ ? 私が言及していないベストプラクティスをご存知でしょうか（ああ、あると言ってください）？私は自分自身のアイデア (3 と 4 のアイデアを組み合わせたもの) を持っていることを認めますが、自分を困らせる前に真の専門家に話してもらうことにします ;-)

どのように解決するのですか？

元の投稿にある 3 と 4 の方法を組み合わせて、一種の「ファジー」または動的なホワイトリストにし、そして - これがトリックです -。 ホワイトリストに載っていない IP をブロックせず、地獄に落ちるまでスロットリングすること .

なお、このメジャーは だけ この非常に特殊なタイプの攻撃を阻止するためのものであることに注意してください。実際には、もちろん、認証に対する他のベストプラクティスのアプローチと組み合わせて機能します。固定ユーザー名スロットリング、IPごとのスロットリング、コードによる強力なパスワードポリシー、スロットルなしのクッキーログイン、保存前にすべてのパスワード同等物のハッシュ化、セキュリティ質問を使用しない、などです。

攻撃シナリオの想定

攻撃者が可変のユーザー名をターゲットにしている場合、私たちのユーザー名による絞り込みは機能しません。攻撃者がボットネットを使用しているか、大規模な IP 範囲にアクセスしている場合、私たちの IP スロットリングは無力になります。攻撃者がユーザーリストを事前に入手している場合（通常、オープンな登録制のウェブサービスでは可能）、「ユーザーが見つかりません」というエラーの数に基づいて進行中の攻撃を検出することはできません。また、システム全体 (すべてのユーザー名、すべての IP) を制限するスロットルを強制する場合、そのような攻撃は、攻撃の期間とスロットル期間中、サイト全体を DoS してしまいます。

ですから、私たちは何か他のことをする必要があるのです。

対策の第一弾：ホワイトリスト化

私たちがかなり確信できることは、攻撃者は、私たちの数千人のユーザー (+) の IP アドレスを検出し、動的に偽装することはできないということです。そのため ホワイトリスト が実現可能なのです。言い換えると、各ユーザーについて、そのユーザーが以前 (最近) ログインした (ハッシュ化された) IP のリストを保存します。

したがって、ホワイトリスト方式は、ロックされた「フロントドア」として機能し、ユーザーはログインするために、認識された「良い」IP の 1 つから接続されなければなりません。この「正面玄関」に対するブルート フォース攻撃は、事実上不可能です (+)。

(+) 攻撃者がサーバー、すべてのユーザーのボックス、または接続自体を「所有」していない限り、そのようなケースでは、もはや「認証」の問題ではなく、本物のフランチャイズ規模のプラグの破損の状況が発生します。

対策の第 2 部: システム全体のスロットリング 認識されないIPの

ユーザーが頻繁にコンピュータを切り替えたり、動的なIPアドレスから接続するようなオープン登録のWebサービスでホワイトリストを機能させるためには、認識されていないIPから接続するユーザーに対して「猫のドア」を開いておく必要があります。ボットネットが立ち往生し、正当なユーザーが迷惑を被るようなドアを設計することがコツです。 を可能な限り少なくすることです。 .

私のスキームでは、これを実現するために 非常に