最善の分散ブルートフォース対策は何ですか？

最初に、少し背景：CodeIgniterのauth + authシステムを実装していることは秘密ではありません。今のところ（いわば）勝っています。しかし、私はかなり非自明な課題に遭遇しました（ほとんどの認証ライブラリが完全に見逃していることを1が、私はそれを適切に取り扱うことを主張）：でインテリジェントに対処する方法を、可変ユーザ名ブルートフォース攻撃大規模分散します、。

私はいつものトリックをすべて知っています：

1. IP /ホストごとの失敗した試行の数を制限し、攻撃者のアクセスを拒否する（例：Fail2Ban）- ボットネットがよりスマートに成長したため、これは機能しなくなりました
2. 上記と、既知の「悪い」IP /ホスト（例：DenyHosts）のブラックリストを組み合わせる-これは、ボットネットが＃1に落ちることに依存しており、ボットネットはますますそうではありません
3. 従来の認証と組み合わされたIP /ホストホワイトリスト（動的IPユーザーではほとんど役に立たず、ほとんどのWebサイトではチャーンが高くなります）
4. N分/時間内に失敗した試行の数にサイト全体の制限を設定し、その後のすべてのログイン試行を数分/時間の間スロットリング（一時停止）します（DoS攻撃によるボットネットの子の遊びになります）。
5. ログイン/パスワードオプションなしのすべてのユーザーに対する必須のデジタル署名（公開鍵証明書）またはRSAハードウェアトークン（確かなソリューションですが、閉鎖的で専用のサービスに対してのみ実用的です）
6. 強化された超強力なパスワードスキーム（例：記号を含む25を超える意味のない文字-繰り返しますが、カジュアルなユーザーには非現実的です）
7. そして最後に、CAPTCHA（ほとんどの場合機能する可能性がありますが、ユーザーにとっては迷惑であり、断固としたリソースのある攻撃者に対して事実上役に立たない）

さて、これらは理論的に実行可能なアイデアにすぎません。サイトを広く開放するようなごみのアイデアはたくさんあります（たとえば、些細なDoS攻撃に）。私が欲しいのはもっと良いものです。そしてもっといいことには、

• DoS攻撃やブルートフォース攻撃に対して安全（+）である必要があり、ややこっそりしたボットがレーダーの下で動作し続ける可能性がある新しい脆弱性を導入しない

• 自動化する必要があります。人間のオペレーターが各ログインを確認したり、不審なアクティビティを監視したりする必要がある場合、実際のシナリオでは機能しません

• 主流のWeb使用（つまり、プログラマー以外のユーザーが実行できる大量のチャーン、大量のオープンな登録）に適している必要があります。

• それは、カジュアルなユーザーがイライラしたりイライラしたりする（そして潜在的にサイトを放棄する）までユーザーエクスペリエンスを妨げることはできません。

• 本当に安全な子猫でなければ、子猫を巻き込むことはできません。

（+）「安全」とは、妄想的なユーザーがパスワードを秘密に保つ能力と同じくらい安全であることを意味します

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

よし、十分なストール。これが私がこれまでに思いついたことです

（申し訳ありませんが、長く投稿してください。勇気を出してください。

元の投稿の方法3と4を組み合わせて、ある種の「ファジー」または動的ホワイトリストにしてから、そしてここに秘訣があります。ホワイトリストに登録されていないIPをブロックせず、ただ地獄に戻ってから戻します。

この対策は、この非常に特殊なタイプの攻撃を阻止することのみを目的としています。もちろん、実際には、認証に対する他のベストプラクティスアプローチと組み合わせて機能します。固定ユーザー名のスロットル、IPごとのスロットル、コード強制の強力なパスワードポリシー、スロットルされていないCookieログイン、保存する前に同等のすべてのパスワードをハッシュします。秘密の質問などを使用する

攻撃シナリオに関する仮定

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

だから私たちは何か他のことをする必要があります。

対策の前半：ホワイトリスト

私たちがかなり確信で​​きることは、攻撃者が数千人のユーザー（+）のIPアドレスを検出して動的にスプーフィングできないことです。どの作るホワイトリスト可能。言い換えると、ユーザーごとに、ユーザーが以前に（最近）ログインした場所の（ハッシュされた）IPのリストが格納されます。

したがって、ホワイトリストスキームはロックされた「フロントドア」として機能し、ユーザーはログインするために、認識された「良い」IPの1つから接続する必要があります。この「玄関」へのブルートフォース攻撃は、実質的に不可能です（+）。

（+）攻撃者がサーバー、すべてのユーザーのボックス、または接続自体のいずれかを「所有」していない限り、そしてそのような場合、「認証」の問題はなくなり、本物のフランチャイズサイズのプル-プラグFUBARの状況

対策の2番目の部分：認識されないIPのシステム全体のスロットル

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

私のスキームでは、これは、承認されていないIPによる失敗したログイン試行の非常に制限された最大数を、たとえば3時間の期間に設定することによって達成されます（サービスのタイプによっては、より短いまたはより長い期間を使用する方が賢明な場合があります）。その制限をグローバルにする、すなわち。すべてのユーザーアカウント。

この方法を使用すると、遅い（試行の間隔は1〜2分）でも総当たりが検出され、すばやく効果的に阻止されます。もちろん、非常に遅いブルートフォースは気付かれないままになる可能性がありますが、速度が遅すぎるとブルートフォース攻撃の目的そのものが無効になります。

このスロットリングメカニズムで達成したいのは、最大制限に達した場合、「猫のドア」がしばらく閉まりますが、正規のユーザーが通常の方法で接続しているため、正面のドアは開いたままです。

• 認識されたIPの1つから接続する
• または、（どこからでも）永続的なログインCookieを使用する

攻撃中に影響を受ける唯一の正当なユーザー-すなわち。スロットルがアクティブ化されている間-不明な場所からログインしているか、動的IPを使用してログインしている永続的なログインCookieのないユーザーになります。これらのユーザーは、スロットリングがオフになるまでログインできません（攻撃者がボットネットをスロットリングし続けている場合、ボットネットの実行を継続すると、時間がかかる可能性があります）。

この小さなユーザーサブセットが他の方法で封印された猫のドアをすり抜けられるようにするには、ボットがまだそこに侵入しているときでも、CAPTCHAを使用した「バックアップ」ログインフォームを使用します。そのため、「申し訳ありませんが、現時点ではこのIPアドレスからログインできません」というメッセージが表示された場合は、「安全なバックアップログイン-HUMANS ONLY（bots：no嘘）」というリンクを含めます。冗談はさておき、そのリンクをクリックしたときに、サイト全体のスロットルをバイパスするreCAPTCHA認証のログインフォームを提供します。このようにして、人間であり、正しいログイン+パスワードを知っていて（CAPTCHAを読み取ることができれば）、未知のホストから接続していて、自動ログインCookieを使用していない場合でも、サービスが拒否されることはありません。

ああ、そして明確にするために：私はCAPTCHAは一般的に悪であると考えているので、「バックアップ」ログインオプションは、スロットルがアクティブな間のみ表示されます。

このような持続的な攻撃がDoS攻撃の一形態を構成することは否定できませんが、上記のシステムが適切に機能している場合、影響を受けるのは、ユーザーのごく一部、つまり、 「remember me」のCookieであり、攻撃の発生中にログインしていて、かつ通常のIPのいずれからもログインしておらず、CAPTCHAを読み取ることができない。これらの基準のすべてにノーと言える人、特にボットと本当に不運な障害者だけが、ボット攻撃中に背を向けられます。

編集：実際には、CAPTCHAに挑戦したユーザーでも「ロックダウン」中に通過させる方法を考えました：バックアップCAPTCHAログインの代わりに、または補足として、ユーザーにシングルユースのオプションを提供します、ユーザー固有のロックダウンコードがメールに送信され、スロットルをバイパスするために使用できます。これは間違いなく私の「煩わしさ」のしきい値を超えていますが、ごく一部のユーザーの最後の手段としてのみ使用されており、アカウントからロックアウトされないため、許容範囲内です。

（また、攻撃がここで説明した厄介な分散バージョンよりも洗練されていない場合、これは起こりません。攻撃が少数のIPから、または少数のユーザー名のみを攻撃する場合は、はるかに早く阻止されます。 、サイト全体に影響はありません）

ですから、それが適切であり、見逃していない簡単な解決策はないと確信できたら、それが私の認証ライブラリに実装する対策です。実際のところ、セキュリティの問題を解決するには微妙な方法が数多くあります。私は、誤った仮定や、どうしようもなく欠陥のあるロジックを行うことはしていません。ですので、フィードバック、批評、改善、微妙さなど、ありとあらゆるものを高く評価してください。

いくつかの簡単な手順：

特定の一般的なユーザー名をブラックリストに登録し、ハニーポットとして使用します。管理者、ゲストなど...これらの名前でアカウントを作成することを誰にも許可しないでください。そのため、誰かがあなたのアカウントにログインしようとした場合、それは誰かがしてはいけないことをしていることがわかります。

サイトで強力な権限を持っている人は、安全なパスワードを持っていることを確認してください。管理者/モデレーターに、文字、数字、記号を組み合わせた長いパスワードを要求する。説明を付けて、通常のユーザーからの単純明快なパスワードを拒否します。

あなたができる最も簡単なことの1つは、誰かが自分のアカウントにログインしようとしたときにそのことを人々に知らせ、彼らがそうでない場合はインシデントを報告するためのリンクを与えることです。「水曜日の午前4時20分に誰かがあなたのアカウントにログインしようとしました。これがあなたでなかった場合は、ここをクリックしてください。」のような単純なメッセージ 攻撃に関する統計情報を保持できます。不正アクセスが急増している場合は、監視とセキュリティ対策を強化できます。

ブルートフォース攻撃のMOを適切に理解していれば、1つ以上のユーザー名が継続的に試行されます。

ここではまだ見たことのない2つの提案があります。

• すべてのユーザーが間違ってログインするたびに、標準的な方法では少し（1秒程度）遅延することを常に考えていました。これはブルートフォースを阻止しますが、1秒の遅延が辞書攻撃をどれだけ長く維持できるかわかりません。（10,000語の辞書== 10,000秒==約3時間。うーん。十分ではありません。）
• サイト全体のスローダウンの代わりに、なぜユーザー名スロットルではありませんか。間違った試みが行われるたびに、スロットルはますます厳しくなります（限界まで、実際のユーザーがまだログインできるようになると思います）

編集：ユーザー名スロットルに関するコメントへの応答：これは、攻撃のソースに関係なく、ユーザー名固有のスロットルです。

ユーザー名が抑制されている場合、調整されたユーザー名攻撃（マルチIP、IPごとの単一の推測、同じユーザー名）でもキャッチされます。攻撃者がタイムアウト中に別のユーザー/パスを自由に試すことができる場合でも、個々のユーザー名はスロットルによって保護されています。

攻撃者の観点から見ると、タイムアウト中に最初に100個のパスワードを推測し、アカウントごとに1つの間違ったパスワードをすばやく発見できる可能性があります。同じ期間に50秒間しか推測できない場合があります。

ユーザーアカウントの観点から見ると、推測が複数のソースからのものであったとしても、パスワードを解読するのに同じ平均数の推測が必要です。

攻撃者にとって、せいぜい100アカウントを破るのは1アカウントを破るのと同じくらいの労力ですが、サイト全体でスロットルを行わないので、スロットルを非常に速く上げることができます。

追加の改良：

• 複数のアカウントを推測しているIPを検出-408 Request Timeout
• 同じアカウントを推測しているIPを検出-大量（たとえば100）の推測の後の408 Request Timeout。

UIのアイデア（このコンテキストには適さない可能性があります）。これにより、上記の内容も改良される場合があります。

• パスワード設定を制御している場合は、パスワードの強度をユーザーに示す、より良いを選択するように促します。
• ログインページを管理している場合は、1つのユーザー名を数回（たとえば10回）推測した後で、CAPTCHAを提供します。

認証には3つの要素があります。

1. ユーザーが何か（パスワードなど）を知っている
2. ユーザーが何か（つまり、キーフォブ）を持っている
3. ユーザーとは何か（網膜スキャンなど）

通常、ウェブサイトはポリシー＃1のみを適用します。ほとんどの銀行でもポリシー1のみを実施しています。代わりに、2要素認証への「他のことを知っている」アプローチに依存しています。（つまり、ユーザーは自分のパスワードと母親の旧姓を知っています。）可能であれば、認証の第2要素を追加する方法はそれほど難しくありません。

約256文字のランダム性を生成できる場合は、16×16のテーブルで構造化し、たとえばセルA-14のテーブルに値を入力するようユーザーに要求できます。ユーザーがサインアップするとき、またはパスワードを変更するときは、表を渡して、印刷して保存するように伝えます。

このアプローチの難しさは、ユーザーがパスワードを忘れたときに、標準の「この質問に答えて新しいパスワードを入力する」だけでは、ブルートフォースに対して脆弱であるためです。また、メールを危険にさらす可能性があるため、リセットして新しいメールを送信することはできません。（参照：Makeuseof.comおよび盗まれたドメイン。）

別のアイデア（子猫を含む）は、BOAがSiteKeyと呼んでいるものです（私は彼らがその名前を商標登録していると思います）。簡単に言うと、ユーザーが登録するときに画像をアップロードし、ユーザーがログインしようとしたときに、8個または15個（またはそれ以上）のランダムな画像から画像を選択するように依頼します。したがって、ユーザーが子猫の写真をアップロードした場合、理論的には他のすべての子猫（または花など）のうち自分の写真が正確にわかるのはユーザーだけです。このアプローチの唯一の真の脆弱性は、中間者攻撃です。

もう1つのアイデア（ただし、子猫ではありません）は、ユーザーがシステムにアクセスするときに使用するIPを追跡し、ユーザーが持っているアドレスからログインするときに、追加の認証（キャプチャ、キティを選択、このテーブルからキーを選択）を実行するように要求することです。前に。また、GMailと同様に、ユーザーは最近ログインした場所を表示できます。

編集、新しいアイデア：

ログイン試行を検証する別の方法は、ユーザーがログインページからアクセスしたかどうかを確認することです。リファラーは簡単に偽造される可能性があるため、確認することはできません。必要なのは、ユーザーがログインページを表示するときに_SESSION変数にキーを設定し、ログイン情報を送信するときにキーが存在することを確認することです。ログインページからボットが送信されない場合、ログインできません。また、JavaScriptを使用してCookieを設定するか、フォームが読み込まれた後にフォームに情報を追加することで、プロセスにJavaScriptを含めることで、これを容易にすることもできます。または、フォームを2つの異なる送信に分割できます（つまり、ユーザーはユーザー名を入力して送信し、新しいページでパスワードを入力して再度送信します）。

この場合の鍵は、最も重要な側面です。それらを生成する一般的な方法は、ユーザーのデータ、IP、および送信された時間の組み合わせです。

以前、PHPでユーザーのログイン試行を抑制する方法はありますかで非常によく似た質問に回答していました。ここでは提案されたソリューションを繰り返し説明します。実際のコードを見ると、多くの人が情報を提供し、役立つと思います。CAPTCHAバスターで現在使用されているアルゴリズムの精度が高まっているため、CAPTCHAを使用することが最善の解決策ではない可能性があることに注意してください。

スロットルを単一のIPまたはユーザー名にチェーンダウンしてDoS攻撃を単純に防ぐことはできません。地獄、あなたは本当にこの方法を使用して速射ログイン試行を防ぐことさえできません。

どうして？ なぜなら、スロットリングの試行を回避するために、攻撃は複数のIPおよびユーザーアカウントに及ぶ可能性があるためです。

理想的には、サイト全体で失敗したすべてのログイン試行を追跡し、それらをタイムスタンプに関連付ける必要があることを他の場所に投稿したことがあります。

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

基づいて一定の遅延を決定し、全体の時間の一定量のログイン失敗の数。これは、ユーザー数とパスワードをリコール（および入力）できる人数に基づいて時間failed_loginsとともに変化するため、テーブルから取得した統計データに基づいてください。

10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

ログイン試行が失敗するたびにテーブルにクエリを実行して、一定期間、たとえば15分間に失敗したログインの数を見つけます。

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

指定された期間の試行回数が制限を超えている場合は、スロットリングを強制するか、指定された期間の失敗した試行の数がしきい値を下回るまで、すべてのユーザーにキャプチャ（つまりreCaptcha）を使用するように強制します。

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

特定のしきい値でreCaptchaを使用すると、複数のフロントからの攻撃が最小限に抑えられ、通常のサイトユーザーが正当なログイン試行の失敗による大きな遅延を経験することがなくなります。CAPTCHAが破られる可能性があると既に拡大されているため、予防を保証することはできません。「この動物に名前を付ける」の代替案である代替ソリューションがあり、代替として非常にうまく機能する可能性があります。

この問題の費用便益分析を行ったかどうかを尋ねなければなりません。多数のパスワードを推測するのに十分なWebプレゼンスを持つ攻撃者から身を守ろうとしているように思われます（IPスロットルを却下したため）IPあたり3〜5のリクエストを送信します。その種類の攻撃は（大体）どれくらいの費用がかかりますか？保護しようとしているアカウントの価値よりも高価ですか？いくつの巨大なボットネットがあなたが持っているものを望んでいますか？

答えはノーかもしれませんが、そうであれば、何らかのセキュリティ専門家の助けを借りていると思います。プログラミングスキル（およびStackOverflowスコア）は、セキュリティノウハウと強く相関していません。

イェンスのスキームを擬似状態遷移図/ルールベースに要約するには：

1. ユーザー+パスワード->エントリ
2. ユーザー+！パスワード->拒否
3. user + known_IP（user）->正面玄関、 // never throttle
4. ユーザー+ unknown_IP（ユーザー）-> catflap
5. （#denied> n）catflaps（site）を介して->スロットルcatflaps（site） // slow the bots
6. catflap +スロットル+パスワード+キャプチャ->エントリ // humans still welcome
7. catflap +スロットル+パスワード+！captcha->拒否 // a correct guess from a bot

観察：

• 前面ドアを絞らないでください。エルボニアの警察はあなたのコンピュータをあなたの家に持っていますが、あなたを尋問することができません。ブルートフォースは、コンピュータから実行可能なアプローチです。
• 「パスワードをお忘れですか？」リンクすると、メールアカウントが攻撃面の一部になります。

これらの観察は、対抗しようとしている攻撃とは異なるタイプの攻撃をカバーしています。

ゆっくりと分散されたブルートフォースから防御しようとしているようです。それについてできることはそれほど多くありません。PKIを使用しており、パスワードログインはありません。それは役立ちますが、クライアントが時々ワークステーションに出会う可能性がある場合、これはあまり当てはまりません。

免責事項：私は2要素の会社で働いていますが、ここにプラグインするわけではありません。ここにいくつかの観察があります。

CookieはXSSおよびブラウザの脆弱性で盗まれる可能性があります。ユーザーは通常、ブラウザーを変更するか、Cookieをクリアします。

送信元IPアドレスは同時に動的に変化し、なりすましが可能です。

キャプチャは便利ですが、特定の人間を認証しません。

複数の方法をうまく組み合わせることができますが、味は確かに順調です。

パスワードの複雑さは良好です。パスワードに基づくものはすべて、十分なエントロピーを持つパスワードに決定的に依存します。私見、安全な物理的な場所に書き留められた強力なパスワードは、メモリ内の脆弱なパスワードよりも優れています。人々は、3つの異なるWebサイトのパスワードとして使用される犬の名前の有効なエントロピーを理解する方法よりも、紙のドキュメントのセキュリティを評価する方法をよく知っています。1回限りのパスコードでいっぱいの大きなページまたは小さなページをユーザーが印刷できるようにすることを検討してください。

「あなたの高校のマスコットは何でしたか」などのセキュリティの質問は、ほとんどが「知っていること」の別のひどい形であり、それらのほとんどはパブリックドメインで容易に推測または完全に推測できます。

お気づきのように、失敗したログイン試行の抑制は、ブルートフォース攻撃の防止とアカウントのDoS処理の容易さとの間のトレードオフです。積極的なロックアウトポリシーは、パスワードエントロピーに対する信頼の欠如を反映している可能性があります。

個人的には、とにかくWebサイトでパスワードの有効期限を強制することの利点はわかりません。攻撃者は一度パスワードを取得すると、そのパスワードを変更して、できるだけ簡単にそのポリシーに準拠できます。おそらく、1つの利点は、攻撃者がアカウントのパスワードを変更した場合、ユーザーがすぐに気付く可能性があることです。攻撃者がアクセス権を取得する前に、ユーザーに何らかの方法で通知が届いた場合はさらに良いでしょう。「前回のログイン以降、N回失敗した」などのメッセージは、この点で役立ちます。

最高のセキュリティは、第1の要因に比べて帯域外の認証の第2の要因からもたらされます。あなたが言ったように、「あなたが持っているもの」のハードウェアトークンは素晴らしいですが、多く（すべてではない）の配布に関連する実際の管理オーバーヘッドがあります。Webサイトに適した生体認証の「何か」のソリューションは知りません。一部の2要素ソリューションは、openidプロバイダーで機能します。一部のソリューションは、PHP / Perl / Python SDKを備えています。

私の最高の推奨事項は、アカウントへの不正なログイン試行についてユーザーに通知することを確認することです- 誰かが実際にアカウントにアクセスしようとしているという証拠が提示された場合、ユーザーはパスワードの強度をより真剣にとらえる可能性があります。

私が実際に兄のmyspaceアカウントにハッキングした人を見つけました。彼らが私のために設定したGmailアカウントに侵入しようとし、「メールでパスワードをリセットする」機能を使用したためです...受信トレイに移動しました。

1. 通常のパスワードを入力する前にワンタイムパスワードを要求するのはどうですか？これにより、メインのパスワードを推測する機会が多くなる前に誰かが攻撃していたことが非常に明白になりますか？

2. ログイン失敗のグローバルなカウント/レートを保持します-これは攻撃の指標です-攻撃中は、ログイン失敗についてより厳格になり、たとえばIPをより速く禁止します。

完璧な答えがあるとは思いませんが、攻撃が感知された場合にロボットを混乱させようとすることに基づいてそれにアプローチする傾向があります。

私の頭の外に：

別のログイン画面に切り替えます。実際には表示される複数のユーザー名とパスワードの空白がありますが、適切な場所にあるのはそのうちの1つだけです。フィールド名はランダムですです。ログイン画面とともにセッションキーが送信され、サーバーはどのフィールドが何であるかを確認できます。成功または失敗すると破棄され、リプレイ攻撃を試行できなくなります。パスワードを拒否すると、新しいセッションIDを取得します。

間違ったフィールドのデータを使用して送信されたフォームは、ロボットからのものであると想定されます。ログインは失敗し、期間が経過し、そのIPは抑制されます。ランダムなフィールド名が正当なフィールド名と一致しないことを確認してください。パスワードを覚えている何かを使用している誰かが誤解を招かないようにしてください。

次に、別の種類のキャプチャについて説明します。人間に問題を引き起こさない一連の質問があります。ただし、ランダムではありません。攻撃が始まると、全員に質問＃1が与えられます。1時間後、質問＃1は破棄され、二度と使用されず、全員が質問＃2を受け取ります。

質問の使い捨ての性質のため、攻撃者はデータベースをダウンロードしてロボットに配置するための調査を行うことができません。彼は、何かを実行するために1時間以内にボットネットに新しい指示を送信する必要があります。

何人かの人々がフォールバックヒューマンメカニズムとしてCAPTCHAを含めたので、CAPTCHAの有効性に関する以前のStackOverflowの質問とスレッドを追加します。

reCaptchaはクラック/ハッキング/ OCR /敗北/破壊されていますか？

CAPTCHAを使用しても、スロットルやその他の提案による改善は制限されませんが、CAPTCHAをフォールバックとして含む回答の数は、セキュリティを破ろうとしている人が利用できる人間ベースの方法を考慮する必要があると思います。

ユーザーのパスワードの強度に基づいてスロットルすることもできます。

ユーザーがパスワードを登録または変更するとき、パスワードの強度評価を計算します。たとえば、1〜10です。

「パスワード」のようなものは1をスコアリングしますが、「c6eqapRepe7et * Awr @ ch」は9または10をスコアリングする可能性があり、スコアが高いほどスロットルがキックするのに時間がかかります。

この質問をするときによく聞く最初の答えは、ポートを変更することですが、それを忘れてIPv4を無効にするだけです。IPv6ネットワークからのクライアントのみを許可する場合、単純なネットワークスキャンを祈る必要がなくなり、攻撃者はDNSルックアップに頼ります。あなたのApache（AAAA）/ Sendmail（MX-> AAAA）/みんなに与えたもの（AAAA）と同じアドレスで実行しないでください。ゾーンがxferdできないことを確認してください。誰かがゾーンをダウンロードできるようにするのを待っていますか？

ボットがサーバーセットアップの新しいホスト名を見つけた場合は、ホスト名に意味不明な文字を追加して、アドレスを変更します。ボットネットがタイムアウトするように、古い名前とセットアップ**ハニーポット名をそのままにします。

**（ip6.arpa。の下にある）リバース（PTR）レコードをテストして、それらが/ 4を持たない/ 4をゼロにするために使用できるかどうかを確認します。IE通常、ip6.arpaのアドレスには〜32 "。"が含まれますが、最後のいくつかを指定せずに試行すると、レコードがあるネットワークブロックと他のレコードがないネットワークブロックが除外される可能性があります。これをさらに進めると、アドレス空間の大部分をスキップすることが可能になります。

最悪の場合、ユーザーはIPv6トンネルをセットアップする必要がありますが、DMZにVPN接続する必要があるというわけではありません...なぜそれが最初のオプションではないのか不思議に思いますが。

また、Kerberosは優れていますが、IMHO LDAPが機能しません（技術的にNISPlusの何が問題になっていますか？ユーザーがLDAPを望んでいるとSunが判断したため、NIS +を削除しました）。KerberosはLDAPまたはNISがなくても正常に機能します。ホスト上のユーザーをホストごとに管理するだけです。Kerberosを使用すると、自動化されていなくても使いやすいPKIが得られます。

ここで少し遅れましたが、ハードケースを想定して私は考えていました-攻撃者はランダムIP、ランダムユーザー名、および最も人気のある10,000のリストから選択されたランダムパスワードを多数使用します。

あなたができることの1つは、特にシステムが攻撃を受けているように思われ、システムで誤ったパスワードが何度も試行され、特にパスワードが低いエントロピーである場合、親の名前などの二次的な質問をすることです。 。攻撃者がパスワード「password1」を試す100万のアカウントをヒットした場合、それらは多くを得る可能性が高いですが、名前を正しく取得する確率は、成功を劇的に減少させます。