【実務・中級編】ブルートフォース攻撃とパスワードスプレー攻撃の検知と防御 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

「パスワードは8文字以上で」と教えるだけでは足りない――攻撃者の視点から見る認証設計の盲点

やあ、現場で戦うエンジニアのみんな。今日は「認証」という、セキュリティの最前線で最も泥臭く、かつ最も裏をかかれやすい領域について話そう。

多くのシステムが導入している「アカウントロックアウト」や「レートリミット」。これら、実は攻撃者から見れば「ただの通過儀礼」か「DoSの踏み台」に過ぎないことを知っているか？今日は、教科書に載っている防御策の裏側で、攻撃者が実際に何を考え、どう動いているのかを解説し、現場で使える「本当に防げる実装」を共有する。

—

1. 攻撃者の論理：なぜ「ロックアウト」は破られるのか

教科書的には「3回失敗したらアカウントをロックする」のが正義とされる。だが、攻撃者はその裏をかく。

パスワードスプレー攻撃（Password Spraying）

無差別なブルートフォース攻撃は、すぐにログに残り、IP制限で弾かれる。だから攻撃者は「パスワードスプレー」を使う。「Summer2024!」のような推測しやすいパスワードを、数千人のIDに対して「1回ずつ」試すんだ。これなら、どのアカウントもロックアウトされず、WAFの閾値にも引っかからない。静かに、しかし確実に突破口を探す。

アカウントロックアウトの悪用（DoS攻撃）

逆に、ロックアウトポリシーを厳しくしすぎるとどうなるか？攻撃者は適当なIDに対して適当なパスワードを連打するだけで、正規ユーザーのログインを強制的に阻害できる。これが「認証機能を使ったDoS攻撃」だ。

—

2. ログ監視の「正しい」着眼点

「ログイン失敗ログを監視しています」という報告をよく受けるが、大抵の場合、それは「事後報告」だ。本当に見るべきは、以下のメタデータである。

同一IPからの異なるIDへのログイン試行: パスワードスプレーの兆候。
同一IDに対する異なるIPからのログイン試行: クレデンシャルスタッフィング（リスト型攻撃）の兆候。
「成功」した後の「短時間での大量アクセス」: アカウント乗っ取り後のデータ流出・不正操作の開始合図。

—

3. 実践：セキュアな認証実装と防御設定

ここからは、明日から現場で使える具体的な実装例だ。

WAF/Nginxでのレートリミット（設定例）

アプリケーション層に負荷をかける前に、Webサーバー側で「IP単位のバースト制御」を行う。

# nginx.conf: ログインパスへのアクセスを厳格に制限
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;

server {
    location /api/v1/login {
        # 1分間に5回以上のリクエストを拒否
        limit_req zone=login_limit burst=5 nodelay;
        proxy_pass http://backend;
    }
}

PHPによるセキュアなログインロジック（概念実装）

単にロックするのではなく、「指数バックオフ」を取り入れる。失敗回数が増えるごとに、レスポンスまでの待機時間を意図的に増やす手法だ。

<?php
// ログイン失敗時の待機時間生成（指数バックオフ）
function get_delay_time($fail_count) {
    // 失敗回数に応じて 1秒, 2秒, 4秒...と待機時間を延ばす
    return min(pow(2, $fail_count), 60); 
}

$fail_count = get_user_fail_count($username);
if ($fail_count > 3) {
    sleep(get_delay_time($fail_count - 3));
}

if (!password_verify($password, $user_hash)) {
    increment_fail_count($username);
    // 「IDまたはパスワードが違います」とだけ返し、詳細を教えない
    echo json_encode(['error' => '認証に失敗しました']);
    exit;
}
?>

多要素認証(MFA)の強制

今の時代、パスワードだけで守ろうとするのは無防備な裸と同じだ。「ログインパスワード + TOTP（時間ベースワンタイムパスワード）」を必須にしろ。

もしIDaaS（Auth0, Firebase Auth, AWS Cognito等）を使っているなら、独自実装は今すぐやめて、マネージドサービスのMFA機能を有効にすること。それが最も安上がりで、最も堅牢な防御だ。

—

4. 最後に：エンジニアが持つべき「疑心」

私がインシデントハンドリングで必ず最初に聞くのは、「ログはどこまで詳細に残っているか？」だ。

User-Agent は記録されているか？
X-Forwarded-For ヘッダーを信頼しすぎていないか？（IP詐称の可能性）
認証成功時の Session ID は適切に再生成されているか？（セッション固定攻撃対策）

セキュリティは「設定して終わり」の静的な壁ではない。攻撃者が進化する以上、我々もログという名の「脈拍」を監視し続けなければならない。

もし君たちのシステムで、まだ「ログイン成功のみ」しかログを見ていないなら、今すぐ認証失敗ログの集計基盤を構築してくれ。攻撃者は君たちが寝ている間に、静かにドアをノックしているはずだから。

何か具体的な実装の相談があればいつでも言ってくれ。現場からは以上だ。