2025年12月11日のLT会

Nginxの脆弱性とセキュリティ設定の落とし穴（LT会アーカイブ）

知っておくべきCVEと明日から直せる設定ミス

📅 アジェンダ

1. イントロダクション
   • Nginxの現状とセキュリティ評判
2. Part 1: 脆弱性の歴史 (CVE事例)
   • Nginx自体にバグはあるのか？
3. Part 2: 開発者が踏み抜く「設定ミス」
   • 実はこれが一番危ない
   • 具体的なコード例と修正案
4. 対策とまとめ

1. イントロダクション

Nginxは安全か？

• WebサーバーシェアNo.1（W3Techs等）...らしい
• 基本設計は堅牢: C10K問題解決のために生まれたイベント駆動アーキテクチャ
• Coreの脆弱性は少ない:
  • Apache httpdなどに比べると、Core由来の緊急脆弱性は比較的稀
  • 発見されてもパッチ提供は非常に迅速

しかし、「無敵」ではない
👉 サードパーティモジュールや、複雑な設定がリスクになる

2. Part 1: 脆弱性の歴史 (CVE事例)

有名なCVE事例

過去に話題になった脆弱性の傾向を知る

1. CVE-2013-2028 (Stack Buffer Overflow)

   • 古いが有名。Chunked Transfer Encodingの解析ミス
   • 任意コード実行の可能性があった（Version 1.3.9 - 1.4.0）

2. CVE-2019-9511 / 9513 (HTTP/2関連)

   • "Data Dribble", "Resource Loop"
   • DoS攻撃（CPU/メモリ枯渇）を引き起こす
   • プロトコル実装の複雑さに起因

最近の傾向：モジュール周り

Core機能よりも、追加機能や連携部分に脆弱性が見つかる傾向

• CVE-2022-41741 (ngx_http_mp4_module)

  • MP4モジュールのメモリ破壊脆弱性
  • 特別に細工されたmp4ファイルでworkerプロセスがクラッシュ/コード実行

• LDAP/PAM Auth モジュール

  • 認証連携部分での不具合など

教訓: 不要なモジュールは組み込まない（ビルドしない）のが最善

3. Part 2: 本当に怖い「設定ミス」

(Common Misconfigurations)

脆弱性の多くは、Nginxのバグではなく
私たちの nginx.conf にある

設定ミス ①: Alias Traversal

alias ディレクティブの末尾スラッシュの有無によるパストラバーサル

❌ 危険な設定

location /img {
    alias /var/www/images;
}

/img../ にアクセスすると、/var/www/ ディレクトリが見えてしまう可能性がある。
（/var/www/images/../ と解釈されるため）

設定ミス ①: Alias Traversal (修正版)

✅ 安全な設定

必ず location と alias の両方の末尾にスラッシュをつける、またはつけない（一致させる）。

location /img/ {
    alias /var/www/images/;
}

※ ディレクトリ階層を遡って意図しないファイルにアクセスするイメージ

設定ミス ②: add_header の継承ルール

セキュリティヘッダーを入れたつもりが入っていない？

⚠️ 仕様の落とし穴
add_header は、現在のブロックで定義されると、親ブロックの設定を継承しない。

server {
    add_header X-Frame-Options DENY; # 親ブロック

    location /api {
        add_header Content-Type application/json; # 子ブロック
        # ここでは X-Frame-Options が消える！
    }
}

設定ミス ②: add_header (対策)

✅ 対策
子ブロックでも必要なヘッダーを再定義するか、共通のincludeファイルを作成する。

location /api {
    add_header X-Frame-Options DENY; # 再定義
    add_header Content-Type application/json;
}

※ Nginxの「宣言的設定」の直感に反する挙動No.1と言われる

設定ミス ③: proxy_pass の末尾スラッシュ

バックエンドへのパス転送が変わってしまう問題

Case A: スラッシュなし

location /api {
    proxy_pass http://backend;
}

Request: /api/user ➡️ Backend: /api/user (そのまま)

Case B: スラッシュあり

location /api/ {
    proxy_pass http://backend/;
}

Request: /api/user ➡️ Backend: /user (apiが削られる)

意図しないパスへのアクセスにより、認証回避などが起きる場合がある。

設定ミス ④: Server Tokens

バージョン情報の漏洩は攻撃者へのヒントになる

❌ デフォルト
HTTPレスポンスヘッダー: Server: nginx/1.18.0
エラーページ: nginx/1.18.0 と表示される

✅ 修正 (nginx.conf)

http {
    server_tokens off;
}

これで Server: nginx だけになり、バージョンが隠蔽される。

4. 対策とまとめ

どうやって安全を保つか？

1. バージョン管理: 常にStable/Mainlineの最新版を追う
2. 最小権限の原則:
   • 不要なモジュールは入れない
   • workerプロセスは非特権ユーザーで動かす
3. 静的解析ツールの活用:
   • Gixy: Nginxの設定ミス検出ツール (Yandex製)
     $ gixy /etc/nginx/nginx.conf
   • Testconfig: nginx -t は構文チェックのみ。ロジックは見てくれない。

まとめ

• NginxのCore自体は堅牢だが、HTTP/2や周辺モジュールの脆弱性情報には注意が必要。
• 最大のリスクは 「人為的な設定ミス（Misconfiguration）」。
  • alias のトラバーサル
  • add_header の継承切れ
• proxy_pass のパス書き換え
• 「動けばヨシ」にせず、仕様を理解して設定しよう。

感想

Marpってスゲー

逸般の誤家庭になりたーーーーい！！！！

誤清聴ありがとうございました☆