目次
やの後ろにあるNGINXで、利用者のを復元したい。しかしX-Forwarded-Forをそのまま信用すると、外部から指定されたアドレスでや記録を行う構成になり得ます。対策の中心はヘッダー名の指定ではなく、その値を渡してよい直前のを限定することです。
本記事は2026年10月27日に確認したNGINX公式ドキュメントに基づく恒久対策の実践解説です。特定の新規脆弱性の速報ではありません。対象はの転送ヘッダーで接続元を復元する構成で、PROXY protocolを使う構成は別途設計が必要です。以下は仮想の設定例であり、実環境での動作検証を済ませたという意味ではありません。
スポンサーリンク
誰がIPアドレスの値を決められるか
X-Forwarded-Forは通信を転送した経路の情報を運ぶHTTPヘッダーです。文字列が存在するだけでは、そこに書かれたIPアドレスが実際の利用者であるとは証明できません。利用者が自分でヘッダーを付けて送れることを出発点に、どの装置が上書きまたは追記するかを確認します。
例えば管理画面を特定IPだけへ公開している場合、判定対象が利用者の指定できるヘッダーなら、許可IPを名乗られる危険があります。でもキーが偽装可能なら制限の回避につながり、監査ログでは別の利用者のアドレスを記録させられるおそれがあります。影響はその値を何の判断に使うかで変わります。
まず、利用者からCDN、負荷分散装置、NGINX、アプリまでの接続順を書き出します。各区間について、実際の接続元と転送ヘッダーの生成担当を記録してください。管理画面の表示名や構成図の製品名だけでは、ネットワーク上の送信元範囲やヘッダー処理の方式までは分かりません。
realipモジュールの三つの指定を分ける
NGINX公式のrealipモジュール資料は、指定したヘッダーの値でクライアントアドレスと任意のポートを変更する機能を説明しています。標準でされるモジュールではないため、導入前に実行中のNGINXで利用できることを確認します。
set_real_ip_fromは、正しい置換用アドレスを送ると信頼する接続元を指定します。real_ip_headerは復元に利用するヘッダーを指定し、既定値はX-Real-IPです。real_ip_recursiveは再帰的な探索の有無で、既定値はoffです。ヘッダー名をX-Forwarded-Forへ変えるだけでは、この三つの役割を設計したことにはなりません。
公式仕様では、元の接続元が信頼対象と一致するとき、再帰探索が無効ならヘッダー内の最後のアドレスへ置換します。有効なら最後の信頼されていないアドレスへ置換します。したがってonを万能な安全設定として扱わず、どの中継アドレスを信頼するかと一緒に評価する必要があります。
スポンサーリンク
信頼範囲を必要なプロキシだけに限定する
次の例は、NGINXの直前に管理下のプロキシ192.0.2.10だけがある仮想構成です。このアドレスは説明用であり、そのまま本番へ貼り付ける値ではありません。実際には提供元が公開する送信元範囲、専用サブネット、構成上の接続経路などから値を決定します。
set_real_ip_from 192.0.2.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;これらの指定はhttp、server、locationの各コンテキストで利用できます。どこへ置くかで適用範囲が変わるため、対象の仮想ホストだけでなく設定の継承や既存の共通設定も調べます。設定ファイル一つの差分だけを見ず、実際に読み込まれる設定全体をレビューしてください。
全インターネットを信頼する0.0.0.0/0や::/0を、動作確認のために入れたままにしてはいけません。同様に、社内やのプライベート範囲全体を無条件に信頼すると、その範囲内の別サービスからヘッダーを送れる条件が残ります。必要な送信元へ絞れる理由を構成表に残します。
NGINXに到達できる経路自体も制限します。CDN経由だけを想定しているのにオリジンへ直接接続できるなら、CDN側で実施した制御を通らない要求が届き得ます。信頼設定とネットワーク制限は別の対策です。ヘッダーを信用しない直アクセスでも、到達できることが業務要件に合うかを判断してください。
多段プロキシでは右側からの判定を確認する
CDNと負荷分散装置を経由する場合、直前の接続元だけを登録すると、復元結果が利用者ではなく途中の装置になることがあります。反対に、広すぎる信頼範囲は本来止めるべき位置を通過させます。再帰探索を有効にした結果を、想定するヘッダー列と実際の接続元の組み合わせで確認します。
ヘッダーの左端を常に利用者とみなす独自処理は避けます。入口で外部由来の列を捨てて新しく作るのか、既存列へ接続元を追記するのかで意味が変わるためです。管理するプロキシで列を正規化する場合も、CDN提供元が保証する方式と矛盾しないようにします。
アプリ側にも信頼プロキシ設定があるなら、NGINXとアプリのどちらで最終的な利用者IPを確定するかを決めます。NGINXが復元した値と、アプリが独自に解析した値が異なれば、ログとアクセス制御の判断が食い違います。二重に解析する必要がある場合は、双方の入力と信頼範囲を別々に検証してください。
スポンサーリンク
元の接続元と復元結果を両方記録する
realipモジュールの$realip_remote_addrは元のクライアントアドレスを保持します。復元後の$remote_addrと併記すれば、どの装置から届いた要求をどの利用者として扱ったかを追跡できます。X-Forwarded-Forの生の値も調査材料になりますが、これは信頼済みの結論とは区別して保存します。
NGINX公式のログモジュール資料には、log_formatで向けのを指定する方法があります。ヘッダーをログに含める際は改行や引用符などの処理を含め、集約先が壊れずに読める形式を選びます。ログの文字列をそのまま運用コマンドへ渡す処理も避けてください。
生のヘッダー列には複数のアドレスが含まれるため、保管期間と閲覧権限を決めます。障害調査のために一時的に記録を増やす場合は、終了日と削除方法も設定します。アプリの利用者IDや要求の識別子と対応づけられれば、IPアドレス一つだけで利用者を断定する調査を減らせます。
偽装しても判断が変わらないことを試す
本サイトの提案する試験は、所有または管理する検証環境で、正常な経路とヘッダー偽装時の結果を比較する方法です。試験用のヘッダーには実在する第三者のIPではなく説明用アドレスを使い、通常の利用者と接続を混同しない記録を残します。攻撃通信を外部サービスへ送る必要はありません。
第一に、通常のCDN経由アクセスで元の接続元が想定するプロキシ、復元結果が試験端末のアドレスになることを確認します。第二に、利用者側でX-Forwarded-Forに任意の値を付けても、最終的な復元結果や許可判断を自由に変更できないことを確認します。応答コードに加えてNGINXとアプリ双方のログを照合します。
第三に、オリジンへの直アクセスを試験できる管理下の端末から確認します。設計上禁止ならネットワーク層で届かないことが合格条件です。直アクセスを許可する構成なら、偽のヘッダーで許可IPを名乗れず、その接続自体の送信元として扱われることを確認します。監視やの例外経路も含めます。
第四に、複数段の信頼プロキシ、IPv6、ヘッダーがない要求についても結果を確認します。IPv4だけで成功した試験はIPv6経路の保証にはなりません。ログに期待どおりのIPが出た一例だけで完了せず、信頼していない接続元が値を変えられないという拒否側の結果を残してください。
変更を反映する前後の確認と切り戻し
変更前に有効な設定とビルド情報を保存し、nginx -tで構文を検査します。モジュールが利用できない場合や指定場所が不適切な場合は、その段階で解決します。構文検査が成功してもネットワーク経路や信頼範囲の正しさまで証明されるわけではないため、検証環境で前述の比較を続けます。
本番反映後は、アクセス拒否の増加だけでなく、全利用者が同じIPへ集約されていないかも確認します。後者はレート制限が通常利用者まで巻き込む原因になります。管理画面、、監視、ヘルスチェックなど経路別に確認し、異常時には保存した設定へ戻せるようにします。
CDNの送信元範囲変更やロードバランサー追加は、信頼境界の変更です。担当者の手作業で古い範囲が残ることを防ぐため、変更通知を受け取る窓口と反映手順を決めます。自動取得する場合も、取得失敗で全範囲許可へ切り替えるような処理にはせず、差分をレビューして反映します。
この対策はIPアドレスの復元を安全に扱うためのもので、認証や利用者単位のの代わりにはなりません。共有回線やNATでは複数の利用者が同じIPになるため、管理操作にはアカウントのと権限確認を組み合わせます。IP制限は補助的な境界として、その前提と限界を運用手順へ明記してください。
試験記録には、接続元、送ったヘッダー列、期待した復元結果、実際の復元結果、アプリの判定を一組で残します。例えば信頼プロキシの直前に別の中継を追加したときも、この組を再実行すれば以前の前提を引き継げるか判断できます。ヘッダー内のアドレスを見ただけで合否を決めず、受信した接続元が信頼対象だったかまで確認することが重要です。
許可した管理端末で成功することと、許可していない端末が許可IPを名乗っても拒否されることを対で試します。後者が成功してしまう場合は公開範囲を戻し、信頼対象の広さと入口でのヘッダー処理を先に調べます。復元結果だけを修正する応急処置を重ねず、どの境界で値を確定する設計だったかへ戻って原因を切り分けます。
参考資料
スポンサーリンク
関連記事
要求の区切り方に関する装置間の問題は、リバースプロキシの解釈差を防ぐHTTPリクエストスマグリング対策で解説しています。IP復元とは別の境界として確認してください。
