【入門編】認証バイパスを狙うブルートフォース攻撃とレート制限の実装 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは！新人エンジニアやセキュリティの勉強を始めたばかりの皆さん、日々の開発やインフラのお仕事、本当にお疲れ様です。

いきなりですが、皆さんのまわりにある「家の鍵」を思い浮かべてみてください。頑丈なドアに、しっかりとしたシリンダーキー。泥棒に入られないように、私たちは大切なお家を鍵で守っていますよね。

では、Webサイトやアプリの「ログイン画面」はどうでしょう？
画面の向こうにあるユーザー名とパスワードは、いわば「デジタル世界の家の鍵」です。もし、泥棒（攻撃者）が合鍵を何万本も用意して、夜通しガチャガチャと鍵穴を試し続けたらどうなるでしょうか？

今回は、この「合鍵をひたすら試してログインを突破しようとする攻撃（ブルートフォース攻撃）」と、それを防ぐための仕組みについて、身近な防犯にたとえながら優しく紐解いていきたいと思います。一歩ずつ、一緒に学んでいきましょう！

—

1. 泥棒の手口を知ろう：ブルートフォース攻撃の正体

私たちが普段何気なく使っているログイン画面ですが、裏側では常に悪意あるボット（自動化プログラム）が狙っています。

攻撃者は、よく使われるパスワードのリスト（辞書）や、考えられるすべての組み合わせをプログラムに読み込ませます。そして、人間の手では到底不可能なスピードで、1秒間に何十回、何百回とログインを試行します。これをブルートフォース攻撃（総当たり攻撃）や辞書攻撃と呼びます。

家の鍵にたとえると…

もし、あなたの家の鍵穴に、泥棒が専用の機械を取り付けて、考えられるすべての鍵の形を1秒間に100回のスピードでガシャガシャと差し込み続けたらどうなりますか？
いくら頑丈な鍵でも、いつかは偶然ピッタリ合うものがヒットしてしまいますよね。Webのログイン画面もこれと全く同じです。

対策を何もしていないログイン画面を放置することは、鍵穴に「いつでも自由にお試しください」と貼り紙をしているようなものなんです。

—

2. デジタル世界の防犯対策：レート制限とアカウントロック

では、この無限の試行錯誤を防ぐにはどうすればよいでしょうか？現実世界の警備や防犯システムを、そのままWebの世界に応用してみましょう。

① レート制限（Rate Limiting）：「一定回数失敗したら出入り禁止！」

お店の自動ドアやテーマパークの入場ゲートを想像してください。不正な動きをする人を見つけたら、一時的にゲートをロックしますよね。これと同じことをWebサーバー側で行うのがレート制限です。

例えば、「同じIPアドレスからのログイン失敗が5回続いたら、15分間アクセスを遮断する」といったルールを設けます。これにより、1秒間に何百回も試行するボットのスピードを完全に封じ込めることができます。

② アカウントロックアウト：「このお部屋の鍵は一時凍結します」

特定のユーザー名（アカウント）に対して、連続してパスワードを間違えた場合、そのアカウント自体を一時的にロックします。
攻撃者がどれだけIPアドレスを変えながら攻撃してきても、狙われた特定のアカウントを守ることができます。

③ CAPTCHA（キャプチャ）：「私はロボットではありません」

「歪んだ文字を入力する」や「信号機の画像を選ぶ」といったテストを見たことがありますよね。
人間には簡単にクリアできますが、プログラム（ボット）にとっては突破が非常に難しいため、自動化された大量の攻撃をスマートに弾くことができます。

—

3. 実装の現場から：PHPとNginxでレート制限をかけてみよう

「概念は分かったけれど、実際にどうやってコードや設定に書けばいいの？」という方のために、実務で使える簡単なサンプルをご紹介します。

バックエンドでのレート制限の実装例（PHP）

まずは、セッションや簡易的なキャッシュ（RedisやMemcachedなど）を使って、ログイン失敗回数をカウントするイメージを見てみましょう。

<?php
// ログイン処理のサンプルコード
session_start();

// ユーザーのIPアドレスを取得
$clientIp = $_SERVER['REMOTE_ADDR'];
$cacheKey = "login_fail_" . $clientIp;

// 簡易的な失敗回数の管理（実際にはRedisやDBを使用することを推奨します）
$maxAttempts = 5; // 許容する最大失敗回数
$lockoutTime = 900; // ロックアウト時間（秒：15分）

// 現在の失敗状況をチェック
$failData = $_SESSION[$cacheKey] ?? ['count' => 0, 'time' => time()];

// ロックアウト時間内かチェック
if ($failData['count'] >= $maxAttempts) {
    $remainingTime = ($failData['time'] + $lockoutTime) - time();
    if ($remainingTime > 0) {
        // まだロックアウト期間中の場合
        header('HTTP/1.1 429 Too Many Requests');
        echo "セキュリティ保護のため、ログイン試行回数が上限を超えました。" . ceil($remainingTime / 60) . "分後にお試しください。";
        exit;
    } else {
        // 時間が経過していたらリセット
        $failData = ['count' => 0, 'time' => time()];
    }
}

// ユーザーからの入力を受け取る（例）
$username = $_POST['username'] ?? '';
$password = $_POST['password'] ?? '';

// 認証処理（ダミー関数）
$isAuthenticated = myAuthFunction($username, $password);

if ($isAuthenticated) {
    // ログイン成功時は失敗カウンターをクリア
    unset($_SESSION[$cacheKey]);
    echo "ログイン成功！ようこそ！";
} else {
    // ログイン失敗時の処理
    $failData['count']++;
    $failData['time'] = time();
    $_SESSION[$cacheKey] = $failData;
    
    $remaining = $maxAttempts - $failData['count'];
    echo "ログインに失敗しました。あと {$remaining} 回間違えると一時的にロックされます。";
}

このように、サーバー側できちんと「何回間違えたか」を追跡し、閾値を超えたら HTTP/1.1 429 Too Many Requests などのステータスコードを返して処理を止めるのが基本のキになります。

インフラ側（Nginx）でのレート制限設定例

アプリのコードだけでなく、Webサーバー（Nginxなど）のレベルでもリクエストの頻度を制限しておくと、より鉄壁の守りになります。

# /etc/nginx/nginx.conf またはバーチャルホストの設定内
# 1秒あたり最大1つのリクエストを許可し、バースト（一時的な急増）は5つまで許容するゾーンを定義
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

server {
    listen 80;
    server_name example.com;

    location /login.php {
        # 定義したゾーンを適用。burstで急なアクセスを吸収し、nodelayで即座にエラーを返す
        limit_req zone=login_limit burst=5 nodelay;
        
        # 通常のPHP処理設定...
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

この設定を入れておけば、例えボットが毎秒何十回も /login.php にアクセスしてきても、Nginxの段階で「429 Request Too Many」を返し、アプリケーションサーバーの負荷を守ることができます。

—

4. ログ監視という「警備員」を忘れない

どんなに頑丈な鍵をつけても、泥棒が窓をこじ開けようとしている音に気づけなければ意味がありません。ここで重要になるのがログ監視です。

ログイン失敗のログが、特定のIPから異常な量出ていないか？
深夜帯に普段と違う国や地域からのアクセスが急増していないか？

こうした兆候をキャッチするために、Webサーバーのアクセスログやアプリケーションのエラーログを定期的に確認したり、SIEMツール（セキュリティ情報を一元管理する仕組み）を使ってアラートを飛ばす設定をしておきましょう。
「何か変なことが起きているぞ」とすぐに気づける体制を作ることが、インシデントを防ぐ最後の砦になります。

—

まとめ：一歩ずつ、安全なWebの世界を作ろう

今回は、認証バイパスを狙うブルートフォース攻撃と、それを防ぐためのレート制限やアカウントロックの仕組みについて解説しました。

1. ブルートフォース攻撃は、総当たりでデジタルな鍵を開けようとする手口。
2. レート制限やアカウントロックを実装して、攻撃のスピードと試行回数を物理的・論理的に制限する。
3. Webサーバーの設定（Nginxなど）やアプリケーションのロジックを組み合わせて多層防御を構築する。
4. ログ監視で異常にいち早く気づけるようにする。

セキュリティの対策に「これで100%完璧」というゴールはありませんが、今日ご紹介した基本的な仕組みを一つずつ丁寧に実装していくことで、あなたの作るWebサイトやアプリケーションは劇的に安全になります。

難しく考えず、「自分の大切な家を守る防犯対策」という感覚を大切にしながら、ぜひ日々の開発やインフラ構築に活かしてみてくださいね。一緒に安全なデジタル社会を作っていきましょう！