最良の分散ブルートフォース対策は何ですか？
まず、少しの背景：CodeIgniterにauth + authシステムを実装していることは秘密ではありませんが、これまでのところ勝ち取っています（いわば）。しかし、私はかなり簡単な挑戦に遭遇しました（ほとんどの認証ライブラリが完全に見逃しているものですが、私はそれを適切に処理することを主張しています）：大規模、分散、可変ユーザー名の総当たり攻撃。
私はすべての通常のトリックを知っています：
- IP /ホストごとに失敗した試行回数を制限し、攻撃者のアクセスを拒否します（たとえば、Fail2Ban）-動作しなくなりました ボットネットがよりスマートになったため
- 上記を既知の「不良」IP /ホストのブラックリストと組み合わせて（例：DenyHosts）-＃1に該当するボットネットに依存 彼らはますますそうしません
- IP /ホストホワイトリストと従来の認証の組み合わせ（ほとんどのWebサイトで動的IPユーザーと高い解約率を使用するのは残念です）
- N分/時間内の失敗した試行回数にサイト全体の制限を設定し、その後のすべてのログイン試行を数分間抑制（中断）します/時間（DoS攻撃によりボットネットの子供の遊びになるという問題がある）
- 必須デジタル署名（公開鍵証明書）またはログイン/パスワードオプションなしのすべてのユーザー用のRSAハードウェアトークン（確かなソリューションですが、閉じた専用サービスにのみ実用的）
- 強制超強力なパスワードスキーム（例：記号付きの25を超えるナンセンス文字-これも、一般ユーザーには実用的ではありません）
- そして最後に、CAPTCHAs（ほとんどの場合は動作しますが、ユーザーにとっては迷惑であり、 virtually useless に対して 決定的で機知に富んだ攻撃者 ）
現在、これらは理論的に実行可能なアイデアにすぎません。 沢山のたくさんのゴミのアイデアがあり、サイトを大きく開いています（例えば、ささいなDoS攻撃へ）。私が欲しいのはもっと良いものです。そして、より良いことは、私が意味する：
DoSおよびブルートフォース攻撃に対して安全である必要があり、少し巧妙なボットがレーダーの下で動作し続ける可能性のある新しい脆弱性を導入しないでください
自動化する必要があります。人間のオペレーターが各ログインを確認したり、疑わしいアクティビティを監視したりする必要がある場合、実際のシナリオでは機能しません
主流のWebの使用に適している必要があります（つまり、プログラマー以外でも実行できる大量解約、大量、オープン登録）
カジュアルユーザーがイライラしたりイライラしたりする可能性がある（そしてサイトを放棄する可能性がある）まで、ユーザーエクスペリエンスを妨げることはできません。
本当に安全な子猫でない限り、子猫を巻き込むことはできません子猫
（+）「セキュア」とは、少なくとも偏執的なユーザーがパスワードを秘密にする能力と同じくらい安全であることを意味します
だから-それを聞いてみましょう！ あなたはどうしますか？私が言及していないベストプラクティスを知っていますか（ああ言ってください）。私は自分のアイデア（3と4のアイデアを組み合わせたもの）を持っていることは認めますが、恥ずかしがる前に真の専門家に話させます;-)
大丈夫、十分なストール;ここに私がこれまでに思いついたものがあります
（申し訳ありませんが、長い投稿が先にあります。勇敢で、友人であり、旅はそれだけの価値があるでしょう）
元の投稿の方法3と4を「ファジー」または動的ホワイトリストの一種に組み合わせて、そして-ここにトリックがあります-ホワイトリストに登録されていないIPをブロックせず、単に地獄に戻って絞る。
この手段は、この非常に特殊なタイプの攻撃を阻止するためのonlyであることに注意してください。もちろん、実際には、他のベストプラクティスの認証アプローチと組み合わせて機能します：固定ユーザー名の調整、IPごとの調整、コードで強化された強力なパスワードポリシー、未調整のCookieログイン、保存する前にすべての同等のパスワードをハッシュ、決してセキュリティの質問などを使用する.
攻撃シナリオに関する仮定
攻撃者が可変ユーザー名をターゲットにしている場合、ユーザー名調整は実行されません。攻撃者がボットネットを使用している場合、または広いIP範囲にアクセスしている場合、IPスロットリングは無力です。攻撃者がユーザーリストを事前にスクレイピングしている場合（通常はオープン登録Webサービスで可能）、「ユーザーが見つかりません」エラーの数に基づいて進行中の攻撃を検出できません。そして、システム全体（すべてのユーザー名、すべてのIP）で制限的なスロットリングを実施すると、そのような攻撃は、攻撃期間とスロットリング期間の間、サイト全体をDoSします。
だから私たちは何か他のことをする必要があります。
対策の最初の部分：ホワイトリスト
かなり確信できるのは、攻撃者が数千人のユーザーのIPアドレスを検出して動的にスプーフィングできないことです（+）。 whitelistingが可能になります。つまり、ユーザーごとに、ユーザーが以前に（最近）ログインした場所から（ハッシュされた）IPのリストを保存します。
したがって、ホワイトリスト登録スキームはロックされた「玄関」として機能し、ユーザーはログインするために、認識された「良い」IPの1つから接続する必要があります。この「正面玄関」に対するブルートフォース攻撃は、実質的に不可能です（+）。
（+）攻撃者がサーバー、すべてのユーザーのボックス、または接続自体のいずれかを「所有」していない限り-そして、その場合、「認証」の問題はなくなり、本物のフランチャイズサイズのプル-プラグFUBAR状況
対策の2番目の部分：システム全体の調整認識されないIPの
ユーザーが頻繁にコンピューターを切り替えたり、動的IPアドレスから接続したりするオープン登録Webサービスのホワイトリストを機能させるには、認識されないIPから接続するユーザーに対して「猫の扉」を開いたままにする必要があります。秘Theは、ボットネットが立ち往生するようにそのドアを設計することであり、したがって、正当なユーザーが煩わされる可能な限り少ない。
私のスキームでは、これはveryを設定することで達成されます。たとえば、未承認のIPによるログイン試行の最大失敗回数を3時間以上に制限します（より短い期間または長い期間サービスの種類）、およびその制限globalを作成します。すべてのユーザーアカウント用。
この方法を使用すると、低速（試行間の1〜2分）のブルートフォースが検出され、迅速かつ効果的に阻止されます。もちろん、本当に遅いブルートフォースはまだ気付かれずにいる可能性がありますが、速度が遅すぎると、ブルートフォース攻撃の本来の目的が無効になります。
このスロットルメカニズムで達成したいのは、最大制限に達すると、「猫のドア」がしばらく閉まりますが、通常の方法で接続している正当なユーザーには正面のドアが開いたままになることです。
- 認識されたIPの1つから接続することにより
- または、永続的なログインCookieを使用して（どこからでも）
攻撃中に影響を受ける唯一の正当なユーザー-つまり。調整がアクティブになっている間-不明な場所から、または動的IPでログインしている永続的なログインCookieを持たないユーザーです。これらのユーザーは、スロットリングが完了するまでログインできません（スロットリングにもかかわらず攻撃者がボットネットを実行し続けると、時間がかかる可能性があります）。
この小さなユーザーのサブセットが別の方法で封印された猫のドアを介して絞ることができるようにするには、ボットがまだ攻撃している間にも、CAPTCHAを使用した「バックアップ」ログインフォームを使用します。そのため、「申し訳ありませんが、現時点ではこのIPアドレスからログインできません」というメッセージを表示するときに、「安全なバックアップログイン-人間のみ（ボット：嘘なし）」。冗談はさておき、そのリンクをクリックすると、サイト全体の調整をバイパスするreCAPTCHA認証のログインフォームを提供します。そのように、彼らが人間であり、正しいログイン+パスワードを知っている（そしてCAPTCHAを読むことができる）場合、彼らは未知から接続していてもneverサービスを拒否されます自動ログインCookieを使用していないホスト。
ああ、ただ明確にするために：私はCAPTCHAを一般的に悪いと考えているので、「バックアップ」ログインオプションはonlyが表示されますスロットルがアクティブな間。
そのような持続的な攻撃が依然としてDoS攻撃の形態を構成することは否定できませんが、説明されたシステムが存在する場合、それはユーザーの小さなサブセット、つまり、 Cookieを「記憶」し、攻撃が発生しているときにログインし、通常のIPからログインしておらず、CAPTCHAを読み取れないユーザー。これらの基準のすべて、特にボットと本当に不運な障害者にノーと言うことができる人だけがボット攻撃中に追い出されます。
編集：実際、CAPTCHAに挑戦しているユーザーでさえ、「ロックダウン」中にパススルーする方法を考えました。または、バックアップCAPTCHAログインの補足として、ユーザーにメールを送信するためのユーザー固有のロックダウンコードを送信するオプションを提供します。このオプションを使用して、調整をバイパスできます。これは間違いなく私の「迷惑」のしきい値を超えていますが、それはユーザーのごく一部の最後の手段としてのみ使用されるため、それでもアカウントからロックアウトされることを打ち負かすので、許容されるでしょう。
（また、攻撃がここで説明した厄介な分散バージョンよりも洗練されていない場合、これのnoneが発生することに注意してください。攻撃が少数のIPまたは少数のユーザー名のみをヒットすると、はるかに早く阻止され、noサイト全体への影響）
ですから、それが適切であり、私が見逃したほど簡単な解決策はないと確信したら、それが私の認証ライブラリに実装する対策です。事実、セキュリティで間違ったことをするための非常に多くの微妙な方法があり、私は誤った仮定や絶望的に欠陥のあるロジックを作る以上ではありません。だから、すべてのフィードバック、批判と改善、微妙さなどを高く評価してください。
いくつかの簡単な手順：
特定の一般的なユーザー名をブラックリストに登録し、ハニーポットとして使用します。管理者、ゲストなど...これらの名前のアカウントを誰にも作成させないでください。そうすれば、誰かがログインしようとしても、すべきでないことをしていることがわかります。
サイトで真の力を持っている人は、安全なパスワードを持っていることを確認してください。管理者/モデレーターに、文字、数字、記号を組み合わせた長いパスワードを要求します。説明付きで、一般ユーザーからの簡単なパスワードを拒否します。
できる最も簡単なことの1つは、誰かが自分のアカウントにログインしようとしたことを人々に伝え、そうでない場合はインシデントを報告するためのリンクを与えることです。 「誰かが水曜日の午前4時20分にアカウントにログインしようとしました。そうでない場合はここをクリックしてください。」攻撃に関する統計情報を保持できます。不正アクセスが急増していることがわかった場合は、監視とセキュリティ対策を強化できます。
ブルートフォース攻撃のMOを適切に理解している場合、1つ以上のユーザー名が継続的に試行されます。
ここでまだ見たことがないと思う2つの提案があります：
- 私はいつも、すべてのユーザーが間違ってログインするたびに、標準的な慣行では短い遅延（1秒程度）があると考えていました。これはブルートフォースを抑止しますが、1秒の遅延が辞書攻撃をどれほど長く続けるかはわかりません。 （10,000語の辞書== 10,000秒==約3時間。うーん。十分ではありません。）
- サイト全体の速度を落とすのではなく、ユーザー名を絞らないようにしましょう。スロットルは、間違った試行ごとにますます厳しくなります（制限まで、実際のユーザーは引き続きログインできます）
Edit：ユーザー名スロットルに関するコメントへの応答：これは、攻撃のソースに関係なく、ユーザー名固有のスロットルです。
ユーザー名が調整されると、協調ユーザー名攻撃（マルチIP、IPごとの単一推測、同じユーザー名）でさえキャッチされます。タイムアウト中に攻撃者が別のユーザー/パスを自由に試すことができる場合でも、個々のユーザー名はスロットルによって保護されます。
攻撃者の観点からは、タイムアウト中に、100個のパスワードを初めて推測し、アカウントごとに1つの間違ったパスワードをすばやく発見できる可能性があります。同じ期間で50秒しか推測できない場合があります。
ユーザーアカウントの観点からは、推測が複数のソースから来ている場合でも、パスワードを破るのに同じ平均推測数が必要です。
攻撃者にとっては、せいぜい100アカウントを破壊するのは1アカウントと同じ努力になりますが、サイト全体でスロットリングを行っているわけではないので、スロットルを非常に素早く上げることができます。
追加の改良点：
- 複数のアカウントを推測しているIPを検出する-408 Request Timeout
- 同じアカウントを推測しているIPを検出します-多数（たとえば100）の推測の後、408要求タイムアウト。
UIのアイデア（このコンテキストでは適切ではない可能性があります）。これにより、上記も洗練されます。
- パスワード設定を制御している場合、ユーザーに パスワードの強度 を表示すると、より良いパスワードを選択するように促されます。
- ログインページを制御している場合は、単一のユーザー名の少数（10個など）の推測の後、CAPTCHAを提供します。
認証には3つの要素があります。
- ユーザー知っている何か（つまり、パスワード）
- ユーザーhas何か（つまり、キーフォブ）
- ユーザーis何か（つまり、網膜スキャン）
通常、ウェブサイトはポリシー＃1のみを実施します。ほとんどの銀行でさえ、ポリシー1のみを実施しています。代わりに、2要素認証に対する「他のことを知っている」アプローチに依存しています。 （IE：ユーザーは自分のパスワードと母親の旧姓を知っています。）可能であれば、認証の2番目の要素を追加する方法はそれほど難しくありません。
約256文字のランダム性を生成できる場合は、16 x 16のテーブルに構造化してから、セルA-14のテーブルに値を入力するようにユーザーに要求できます。ユーザーがサインアップまたはパスワードを変更したら、テーブルを提供し、印刷して保存するように伝えます。
このアプローチの難しさは、ユーザーが自分のパスワードを忘れた場合、標準の「この質問に答えて新しいパスワードを入力する」だけでは提供できないことです。これはブルートフォースに対しても脆弱です。また、メールも危険にさらされる可能性があるため、リセットして新しいメールを送信することはできません。 （Makeuseof.comとそれらの盗まれたドメインを参照してください。）
もう1つのアイデア（子猫を含む）は、BOAがSiteKeyと呼んでいるものです（名前の商標であると思われます）。簡単に言えば、登録時にユーザーに画像をアップロードしてもらい、ログインしようとすると、8個または15個（またはそれ以上）のランダムな画像から画像を選択するように依頼します。そのため、ユーザーが子猫の写真をアップロードした場合、理論的には、他のすべての子猫（または花など）の中から自分の写真を正確に知っているのはユーザーだけです。このアプローチが持つ唯一の真の脆弱性は、中間者攻撃です。
もう1つのアイデア（ただし子猫はありません）は、ユーザーがシステムにアクセスするIPを追跡し、彼らが持っているアドレスからログインするときに追加の認証（captcha、キティを選択、このテーブルからキーを選択）を実行することを要求することです前に。また、GMailと同様に、ユーザーが最近ログインした場所を表示できるようにします。
編集、新しいアイデア：
ログイン試行を検証する別の方法は、ユーザーがログインページからアクセスしたかどうかを確認することです。リファラーは簡単に偽装できるため、チェックできません。必要なのは、ユーザーがログインページを表示するときに_SESSION変数にキーを設定し、ログイン情報を送信するときにキーが存在することを確認することです。ボットがログインページから送信しない場合、ボットはログインできません。また、プロセスにjavascriptを使用して、cookieを設定するか、ロード後にフォームに情報を追加することにより、これを容易にすることができます。または、フォームを2つの異なる送信に分割できます（つまり、ユーザーはユーザー名を入力して送信し、新しいページでパスワードを入力して再度送信します）。
この場合のキーは、最も重要な側面です。それらを生成する一般的な方法は、ユーザーのデータ、IP、および送信時刻の組み合わせです。
この問題の費用便益分析を行ったかどうかを質問する必要があります。多数のパスワードを推測するのに十分なWebプレゼンスを持ち、IPごとに3〜5個のリクエストを送信する攻撃者から身を守ろうとしているようです（IPスロットリングを却下しているため）。この種の攻撃にはどれくらいの費用がかかりますか？保護しようとしているアカウントの価値よりも高価ですか？何個の巨大なボットネットがあなたが持っているものを望んでいますか？
答えは「いいえ」かもしれませんが、もしそうなら、何らかのセキュリティ専門家から助けを得ることを望みます。プログラミングスキル（およびStackOverflowスコア）は、セキュリティノウハウとは強く相関しません。
以前、非常によく似た質問に 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;
特定の時間内に失敗したログインのoverall数に基づいて、特定の遅延を決定します。これは、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が破壊される可能性があるため、予防が既に拡張されているため、予防を保証することはできません。代替ソリューションとして、おそらく「この動物に名前を付ける」の変形があり、代替として非常にうまく機能します。
Jensのスキームを擬似状態遷移図/ルールベースにまとめるには：
- ユーザー+パスワード->エントリ
- ユーザー+！password->拒否
- user + known_IP（user）->正面玄関、
// never throttle - user + unknown_IP（user）-> catflap
- （#denied> n）catflaps（site）経由-> catflaps（site）のスロットル
// slow the bots - catflap +スロットル+パスワード+ captcha->エントリ
// humans still welcome - catflap +スロットル+パスワード+！captcha->拒否
// a correct guess from a bot
観察：
- 正面ドアを絞らないでください。エルボニア州警察はあなたのコンピューターを家に持っていますが、尋問することはできません。ブルートフォースは、コンピューターから実行可能なアプローチです。
- 「パスワードを忘れましたか？」リンクをクリックすると、メールアカウントが攻撃対象になります。
これらの観察は、対抗しようとしている攻撃とは異なる種類の攻撃を対象としています。
低速分散ブルートフォース に対して防御しようとしているように見えます。あなたがそれについてできることはそんなに多くありません。 PKIを使用しており、パスワードログインは使用していません。これは役立ちますが、クライアントが時々ワークステーションにアクセスする場合、これはあまり当てはまりません。
免責事項：私は二要素会社で働いていますが、それを差し込むためにここにいるわけではありません。いくつかの観察結果があります。
Cookieは、XSSとブラウザの脆弱性によって盗まれる可能性があります。ユーザーは通常、ブラウザーを変更するか、Cookieをクリアします。
送信元IPアドレスは動的に可変であり、スプーフィング可能です。
Captchaは便利ですが、特定の人間を認証しません。
複数の方法をうまく組み合わせることができますが、良い味は確かに整然としています。
パスワードの複雑さは良好であり、パスワードに基づくものはすべて、十分なエントロピーを持つパスワードに決定的に依存します。私見、安全な物理的な場所に書き留められた強力なパスワードは、メモリ内の弱いパスワードよりも優れています。人々は、3つの異なるWebサイトのパスワードとして使用した場合に、犬の名前の有効なエントロピーを計算する方法を知っているよりも、紙の文書のセキュリティを評価する方法をよく知っています。ユーザーに、1回限りのパスコードでいっぱいの大きなページまたは小さなページを印刷できるようにすることを検討してください。
「高校のマスコットは何だったのか」などのセキュリティの質問は、ほとんどが「知っていること」のひどい形式です。それらのほとんどは、容易に推測できるか、パブリックドメインで完全に当てはまります。
既に説明したように、失敗したログイン試行の抑制は、ブルートフォース攻撃の防止とアカウントのDoSingの容易さの間のトレードオフです。積極的なロックアウトポリシーは、パスワードエントロピーに対する信頼の欠如を反映している場合があります。
個人的には、とにかくWebサイトでパスワードの有効期限を強制することの利点はありません。攻撃者は一度パスワードを取得すると、そのパスワードを変更し、できるだけ簡単にそのポリシーに準拠できます。おそらく1つの利点は、攻撃者がアカウントのパスワードを変更すると、ユーザーがより早く気付く可能性があることです。さらに良いのは、攻撃者がアクセスする前に何らかの方法でユーザーに通知された場合です。この点では、「最後のログイン以降にN回失敗した」などのメッセージが役立ちます。
最高のセキュリティは、最初の認証と比較して帯域外の認証の2番目の要素から得られます。あなたが言ったように、「あなたが持っているもの」のハードウェアトークンは素晴らしいですが、多くの（すべてではない）ディストリビューションに関連する実際の管理オーバーヘッドがあります。ウェブサイトに適した生体認証の「あなたが何か」ソリューションがわからない。一部の2要素ソリューションはopenidプロバイダーで動作し、一部にはPHP/Perl/Python SDKがあります。
通常のパスワードを入力する前にワンタイムパスワードを要求するのはどうですか？それは、メインパスワードを推測する多くの機会を得る前に誰かが攻撃していることを非常に明らかにするでしょうか？
ログイン失敗のグローバルカウント/レートを維持します-これは攻撃の指標です-攻撃中はログイン失敗についてより厳しくします。 IPをより迅速に禁止します。
私の最高の推奨事項は、単にユーザーに通知するアカウントへの不正なログイン試行を確認することです-ユーザーは、誰かがいるという証拠を提示された場合、パスワードの強度をより深刻に取る可能性があります実際にアカウントにアクセスしようとしています。
私が実際に弟のmyspaceアカウントにハッキングした人を捕まえたのは、彼らが私が設定したGmailアカウントにアクセスしようとし、「メールでパスワードをリセットする」機能を使用していたからです...
ユーザーパスワードの強度に基づいて調整することもできます。
ユーザーがパスワードを登録または変更すると、パスワードの強度評価、たとえば1〜10を計算します。
「パスワード」のようなものは1を採点しますが、「c6eqapRepe7et * Awr @ ch」は9または10を採点し、スコアが高いほどスロットルの開始に時間がかかります。
この質問をするときによく耳にする最初の答えは、ポートを変更することですが、それを忘れてIPv4を無効にするだけです。 IPv6ネットワークからのクライアントのみを許可する場合、単純なネットワークスキャンを求めなくなり、攻撃者はDNSルックアップに頼ります。 Apache（AAAA）/ Sendmail（MX-> AAAA）/ everybody（AAAA）に配布したものと同じアドレスで実行しないでください。ゾーンをxferdにできないことを確認してください。誰かがゾーンをダウンロードできるようになるまで待ってください。
ボットがサーバーに新しいホスト名を設定しているのを見つけたら、ホスト名の一部に意味不明なものを追加して、アドレスを変更します。古い名前を残し、**ボットネットのハニーポット名を設定して、タイムアウトします。
**リバース（PTR）レコード（ip6.arpa。の下）をテストして、レコードがVS/4にない/ 4にゼロで使用できるかどうかを確認します。 I.E.通常、ip6.arpaにはアドレスに〜32 "。"が含まれますが、最後のいくつかの行方不明を試してみると、レコードがあるネットワークブロックとないレコードが除外される可能性があります。さらに進めば、アドレス空間の大部分をスキップすることが可能になります。
最悪の場合、ユーザーはIPv6トンネルを設定する必要があります。VPNをDMZに接続する必要があるというわけではありません...なぜそれが最初の選択肢ではないのか疑問に思います。
また、Kerberosはクールですが、IMHO LDAPは打撃を与えます（NISPlusの技術的な問題は何ですか？SunはユーザーがLDAPを望んでいると判断したため、NIS +を削除しました）。 Kerberosは、LDAPまたはNISがなくても正常に機能し、ホストごとにユーザーを管理する必要があります。 Kerberosを使用すると、自動化されていなくても、使いやすいPKIが得られます。
ここで少し遅れましたが、私は難しいケースを想定して考えていました-攻撃者は、最も人気のある10,000のリストから選択されたランダムなIP、ランダムなユーザー名、ランダムなパスワードをたくさん使用します。
あなたができることの1つは、特にシステムに多くの間違ったパスワードの試行があるという点でシステムが攻撃を受けているようで、特にパスワードのエントロピーが低い場合、両親の名などの二次的な質問をすることです。攻撃者がパスワード「password1」を試行して100万のアカウントをヒットした場合、多くのアカウントが取得される可能性が高くなりますが、名前を正しく取得する確率は劇的に低下します。
フォールバックヒューマンメカニズムとしてCAPTCHAが含まれていたため、CAPTCHAの有効性に関する以前のStackOverflowの質問とスレッドを追加しています。
reCaptchaはクラック/ハッキング/ OCRされた/敗北/壊れましたか？
CAPTCHAを使用しても、調整やその他の提案による改善は制限されませんが、フォールバックとしてCAPTCHAを含む回答の数は、セキュリティを破ろうとしている人々が利用できる人間ベースの方法を考慮すべきだと思います。
完璧な答えがあるとは思いませんが、攻撃が感知された場合、ロボットを混乱させようとすることに基づいてアプローチする傾向があります。
私の心の一番上から：
別のログイン画面に切り替えます。複数のユーザー名とパスワードの空白があり、実際に表示されますが、正しい場所にあるのはそのうちの1つだけです。フィールド名は[〜＃〜] random [〜＃〜]-セッションキーがログイン画面とともに送信されると、サーバーはどのフィールドが何であるかを確認できます。成功または失敗した場合は破棄されるため、リプレイ攻撃を試みることはできません。パスワードを拒否すると、新しいセッションIDが取得されます。
間違ったフィールドのデータで送信されたフォームは、ロボットからのものであると想定されます。ログインは失敗し、期間が経過し、そのIPは調整されます。ランダムなフィールド名が正当なフィールド名と決して一致しないようにしてください。そうすれば、パスワードを覚えているものを使用しても、誤解を招くことはありません。
次に、別の種類のキャプチャについてはどうですか。人間に問題を引き起こさない一連の質問があります。ただし、それらは[〜＃〜] not [〜＃〜]ランダムです。攻撃が開始されると、全員に質問＃1が与えられます。 1時間後に質問＃1が破棄され、二度と使用されなくなり、全員が質問＃2を取得します。
質問は使い捨てであるため、攻撃者はデータベースをダウンロードしてロボットに入れるようにプローブすることはできません。彼は、1時間以内に新しい指示をボットネットに送信して、何でもできるようにしなければなりません。