ネットワークの「背任行為」を見抜く：X-Forwarded-Forの真実と偽装の落とし穴
Webアプリケーションのインフラを設計していると、必ずぶち当たる壁がある。「クライアントの真のIPアドレスをどうやって特定するか」という問題だ。
ロードバランサー（LB）やリバースプロキシを介した通信において、Webサーバーのアクセスログに記録されるのは「LBのIP」だけ。これではユーザーの地理的属性やセキュリティ制限を正しく適用できない。そこで登場するのが、事実上の標準（de facto standard）である `X-Forwarded-For`（以下、XFF）ヘッダーだ。
しかし、このヘッダーを「魔法の杖」だと信じているなら、今すぐ考えを改めたほうがいい。今日は、ネットワークエンジニアの視点から、XFFの構造と、そこに潜む「偽装」という名の地雷について解説しよう。
—
1. XFFの正体：通信の「履歴書」
XFFは、HTTPリクエストが経由したプロキシサーバーやロードバランサーの連鎖を追跡するためのリストだ。構造は非常にシンプルで、カンマ区切りでIPアドレスが連ねられる。
X-Forwarded-For: <クライアントIP>, <プロキシ1のIP>, <プロキシ2のIP>
クライアントから最初のリクエストが発信されたとき、一番左端にクライアントのIPが書き込まれる。その後、リクエストがプロキシを通過するたびに、そのプロキシが自身のIPを右端に追加していく。つまり、一番左が「真の始点」であるというのが一般的な解釈だ。
通信フローのイメージ
1. User (1.1.1.1) → LB (2.2.2.2) → Web Server
2. Web Serverに届くヘッダー: `X-Forwarded-For: 1.1.1.1`
もし、さらに社内プロキシ（3.3.3.3）を通しているなら、`X-Forwarded-For: 1.1.1.1, 2.2.2.2` となるわけだ。
—
2. なぜ「偽装」が起こるのか？
ここからが本題だ。XFFはRFCで厳密に規定された仕様ではなく、あくまで「慣習」として普及したもの。そのため、クライアント自身がこのヘッダーを勝手に付与してリクエストを送ることを防ぐ手立てがない。
悪意あるユーザーが `curl` で以下のように叩いたらどうなるだろうか？
攻撃者が自身のIP（1.1.1.1）を隠し、金融機関のサーバー（10.0.0.5）になりすます例
curl -H “X-Forwarded-For: 10.0.0.5” https://victim-api.com/access-log
もし、あなたのWebサーバーやアプリケーションが、ヘッダーの「一番左」を疑いもせず信頼していたら、アクセス制限を簡単にバイパスされてしまう。これがXFF偽装の典型的なシナリオだ。
—
3. 実務で守るための「境界線」設計
インフラ運用において、XFFを安全に扱うための鉄則はただ一つ。「信頼できるプロキシ以外のXFFヘッダーは信用するな」だ。
Nginxでの正しい設定例
Nginxを使う場合、`real_ip` モジュールを使って、信頼できるLBからのIPのみを「本物のクライアントIP」として認識させるのが定石だ。
信頼できるロードバランサーのIP帯域を指定
set_real_ip_from 192.168.1.0/24;
ヘッダーからIPを抽出して$remote_addrを上書きする
real_ip_header X-Forwarded-For;
右から数えていくつ目のIPを信頼するか（通常は1）
real_ip_recursive on;
こうすることで、外部ユーザーが勝手に入力した `X-Forwarded-For` ヘッダーは無視され、LBが適切に付与したIPのみがサーバー側に引き継がれる。
—
4. 開発環境でのデバッグTips
API開発中にXFFをテストする際は、`Fetch API` を使った検証が手軽だ。ブラウザのコンソールから以下のように投げれば、サーバー側がどう処理しているか確認できる。
// 検証用リクエスト
fetch(‘https://api.example.com/debug’, {
headers: {
‘X-Forwarded-For’: ‘123.123.123.123’ // 偽装IPを注入してみる
}
}).then(res => res.json())
.then(console.log);
Python (requests) での検証も同様だ。
import requests
偽装ヘッダーを付与してリクエストを送る
headers = {‘X-Forwarded-For’: ‘8.8.8.8’}
response = requests.get(‘https://api.example.com/my-ip’, headers=headers)
print(f”サーバーの応答: {response.text}”)
—
最後に：ネットワークエンジニアとしての流儀
XFFに限らず、ネットワークの世界では「入り口のデータはすべて疑え」が正義だ。特にクラウド環境では、LBの背後に複数のプロキシが介在することも珍しくない。
- ログには「生のIP」と「XFF」の両方を残す：トラブルシューティングの際、どちらに嘘があるのかを照合できるようにしておくこと。
- アプリケーション層でIP制限をかけない：可能な限り、WAFやセキュリティグループ、Nginxの設定など、インフラ層でIPのフィルタリングを完結させる。
XFFは強力なツールだが、それは信頼できる境界線があって初めて成立するものだ。この仕組みを正しく理解し、堅牢なパイプラインを構築してほしい。現場からは以上だ。
コメント