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

認証の要塞をいかにして守るか：ブルートフォースとパスワードスプレーの深層防御アーキテクチャ

ペネトレーションテスターとして数々の企業ネットワークやクラウド環境を監査していると、いまだに「認証」という最も原始的かつ強固であるべき門戸が、設計の甘さによっていとも簡単にこじ開けられる現場に直面する。

世間一般のセキュリティガイドラインを開けば、「複雑なパスワードを設定せよ」「アカウントロックアウトを有効にせよ」といった退屈な文言が並ぶ。しかし、実際のサイバー犯罪グループや国家支援型ハッカー集団は、そんな教科書的な防御を嘲笑うかのように、プロトコルの仕様の隙や、人間の心理的・運用的な盲点を突いてくる。

今回は、単なる表層的な対策のコピー＆ペーストではなく、攻撃者の思考プロセス（TTPs）を逆手に取り、インフラストラクチャの低レイヤからアプリケーション層、そしてログ監視に至るまで、いかにして堅牢な認証防衛ラインを構築すべきか、その実践的なアーキテクチャを解き明かしていく。

—

1. 攻撃者の視点：ブルートフォースとパスワードスプレーの境界線

まず、脅威の性質を正しく定義することから始めよう。防御側が混同しがちな「ブルートフォース（総当たり）」と「パスワードスプレー（Password Spraying）」は、検知と回避のロジックにおいて全く異なるアプローチを要求する。

ブルートフォース：力任せの暴力と、その自滅

単一のアカウント（例: admin や root）に対して、数千から数万の辞書パスワードを短時間で浴びせる古典的手法だ。
現代のシステムにおいて、この攻撃は非常に検知しやすい。なぜなら、単一のソースIPから同一ユーザーに対する大量の認証失敗（HTTP 401 Unauthorized またはカスタムエラー）が発生するためだ。単純な閾値ベースのレートリミットや、Fail2banのようなファイアウォール連携ツールで容易に鎮圧できる。

パスワードスプレー：検出を逃れる「低速かつ分散」の芸術

一方で、レッドチームが好んで使うのはパスワードスプレーだ。
彼らは「1つのアカウントを何度も試さない」。代わりに、企業内の全ユーザーリスト（OSINTで収集したもの）に対し、春闘の季節に一斉に配られるような「よくあるパスワード（例: Summer2023! や CompanyName123）」を1つだけ、時間を空けて試行する。

この攻撃の巧妙さは、以下の点にある：

  • アカウントロックアウトの回避: 試行間隔を十分に空ける（数分に1回など）ことで、標準的なロックアウトポリシー（例: 5回連続失敗でロック）の発動条件を巧妙に潜り抜ける。
  • IP分散（ボットネット/プロキシプール）: 攻撃元IPが固定されず、Residential Proxy（住宅用プロキシ）などを経由して世界中からリクエストが分散するため、IPアドレスベースのブロックが機能しない。

この脅威に対抗するためには、単純な「試行回数のカウント」ではなく、多次元的なコンテキストを評価する防御アーキテクチャが必要となる。

—

2. アーキテクチャによる根本防御：多層防御の実際

パスワードスプレーや高度なブルートフォースを無力化するには、認証基盤（IdP）およびアプリケーション層において、以下の3つの防壁を統合的に実装する必要がある。

A. 認証プロトコルとレートリミットの最適設計

アプリケーション層でのレートリミットは、単にIPアドレスを見るだけでは不十分だ。IPアドレスはNAT環境下では数百人のユーザーで共有されるため、正当なユーザーまで巻き込んでサービス拒否（DoS）状態に陥るリスクがある。

したがって、「IPアドレス」「ユーザー名（正規化後）」「デバイスフィンガープリント」の複合キーに基づいてレートを制限する。

以下は、APIゲートウェイやリバースプロキシ（NginxやEnvoyなど）の手前、あるいはカスタム認証ミドルウェアで実装すべきレートリミットの概念的なアルゴリズムを反映した疑似コード（Python / FastAPIベース）である。

from fastapi import FastAPI, HTTPException, Request
from redis import Redis
import time

app = FastAPI()
redis_client = Redis(host='localhost', port=6379, db=0)

# 設定パラメータ
MAX_ATTEMPTS = 5
WINDOW_SECONDS = 300  # 5分間
LOCKOUT_SECONDS = 900 # 15分間のペナルティ

@app.post("/api/v1/auth/login")
async def login(request: Request):
    data = await request.json()
    username = data.get("username", "").lower().strip()
    client_ip = request.client.host
    
    # 複合キーの生成（IPとユーザー名のハッシュ、または個別評価）
    ip_key = f"rate_limit:ip:{client_ip}"
    user_key = f"rate_limit_user:{username}"
    
    current_time = int(time.time())
    
    # 1. ユーザー単位の総当たり・スプレー検知
    user_attempts = redis_client.get(user_key)
    if user_attempts and int(user_attempts) >= MAX_ATTEMPTS:
        raise HTTPException(
            status_code=429, 
            detail="セキュリティ保護のため、このアカウントは一時的にロックされています。時間をおいて再試行してください。"
        )
    
    # 認証処理のシミュレーション
    is_authenticated = authenticate_user(username, data.get("password"))
    
    if not is_authenticated:
        # 失敗回数をインクリメントし、有効期限を設定
        pipe = redis_client.pipeline()
        pipe.incr(user_key, 1)
        pipe.expire(user_key, WINDOW_SECONDS)
        pipe.execute()
        
        # 攻撃者への情報漏洩を防ぐため、存在しないユーザーであっても「認証失敗」のレスポンスを均一にする
        raise HTTPException(status_code=401, detail="認証に失敗しました。")
    
    # 成功時はカウンターをクリア
    redis_client.delete(user_key)
    return {"status": "success", "message": "ログインに成功しました。"}

def authenticate_user(username: str, password: str) -> bool:
    # 実際のデータベース照合処理（パスワードはArgon2id等でハッシュ化されている前提）
    return False

B. パスワードポリシーのパラダイムシフト：「長さ」と「ブラックリスト」

複雑怪奇な文字種要件（大文字、小文字、数字、記号をすべて含める）は、ユーザーに付箋紙でのパスワード管理を強要するだけであり、セキュリティ上の実効性は低いことがNIST（米国標準技術研究所）のガイドライン等でも証明されている。

現代のアーキテクチャでは、以下のポリシーを強制すべきである。

  • 最小文字数の厳格化: 最低でも12文字以上（できれば16文字以上）。
  • 既知の侵害済みパスワードの排除: Have I Been PwnedなどのAPIや、ローカルに保持した数億件の漏洩パスワード辞書（Bloomフィルター等を使用）と突合せ、登録時に拒否する仕組み。
  • パスワードレスへの移行: FIDO2 / WebAuthn（パスキー）の導入が究極の解答である。公開鍵暗号方式をベースとするため、サーバー側でのパスワード漏洩やブルートフォース攻撃そのものが成立しなくなる。

C. 多要素認証（MFA）の強制と「疲労攻撃」への対策

MFAは強力だが、SMS認証やプッシュ通知型MFAは「MFA疲労攻撃（MFA Fatigue / ルーレット攻撃）」と呼ばれる手法で突破されるリスクがある。攻撃者が深夜に何度もプッシュ通知を送りつけ、ユーザーが誤って「承認」を押してしまうのを待つ手口だ。

これを防ぐためには、以下の実装が不可欠である。

  • 番号照合型MFA（Number Matching）: プッシュ通知の際に画面に表示されたランダムな数字を、ユーザーがログイン画面に入力させなければ承認できない仕組みにする。
  • FIDO2 / ハードウェアトークンの優先: フィッシング耐性の高い認証方式を強制する。

—

3. ログ監視と検知エンジニアリング：SIEMでのシグネチャ設計

インフラとアプリケーションで防ぎきれなかった攻撃を、いかにして「早期に」検知し、インシデントレスポンスにつなげるか。ここがSOC（セキュリティオペレーションセンター）やチーフホワイトハッカーの腕の見せ所だ。

単に「ログイン失敗ログをカウントする」だけでは、巧妙なパスワードスプレーはすり抜けていく。SplunkやElastic StackなどのSIEMを用い、以下のような高度な相関ルール（Correlation Rules）を構築する必要がある。

検知ルール例：分散型パスワードスプレーの検出（Elasticsearch EQLの概念）

「短時間に、多数の異なるユーザー名に対して、同一または少数のパスワードが試行されているか、あるいは同一IPから多種多様なアカウントへのログイン失敗が頻発しているか」を検知するクエリの概念。

{
  "query": {
    "bool": {
      "must": [
        { "match": { "event.category": "authentication" } },
        { "match": { "event.outcome": "failure" } }
      ],
      "filter": [
        {
          "range": {
            "@timestamp": {
              "gte": "now-10m"
            }
          }
        }
      ]
    }
  },
  "aggs": {
    "distinct_users_per_ip": {
      "terms": {
        "field": "source.ip",
        "size": 10
      },
      "aggs": {
        "unique_usernames": {
          "cardinality": {
            "field": "user.name"
          },
          "bucket_selector": {
            "buckets_path": {
              "unique_user_count": "unique_usernames"
            },
            "script": {
              "source": "params.unique_user_count > 15" // 10分間に15人以上の異なるユーザーを試行したIPを抽出
            }
          }
        }
      }
    }
  }
}

このような集計をリアルタイムで実行し、閾値を超えた瞬間に自動でSOAR（Security Orchestration, Automation, and Response）と連携して該当IPからのアクセスをWAF（Web Application Firewall）やクラウドのセキュリティグループで自動ブロックするフローを完成させる。これが実務で求められる「動的防御」の姿だ。

—

4. 結びにかえて：終わりなき攻防の先にあるもの

ブルートフォースやパスワードスプレーは、攻撃者にとって最も低コストで仕掛けられる「最初のノック」にすぎない。しかし、この最初のノックをいかにして痛いものにするか、あるいは完全に無効化するかによって、企業のセキュリティ成熟度は明確に分かれる。

テックリードやアーキテクトであるあなたが設計すべきは、「破られないシステム」ではない。「破ろうとした瞬間にその試みがコストに見合わないと攻撃者に悟らせ、即座に検知・封鎖できる自律的な防衛エコシステム」である。

プロトコルの仕様を深く理解し、ログの隅々に目を光らせ、常に攻撃者のワンステップ先を行くアーキテクチャを描き続けてほしい。脆弱な認証基盤に慈悲はない。守るべきものの価値に見合った、妥協なき設計を今すぐ実装せよ。

スポンサーリンク

コメント

タイトルとURLをコピーしました