HTTP ヘッダー経由でクライアントの実 IP アドレスを取得する - Web Application Firewall

CNAME 統合を使用して Web Application Firewall (WAF) を利用すると、オリジンサーバーは実際のクライアント IP アドレスではなく、最終ホッププロキシの IP アドレスを受け取ります。WAF は HTTP リクエストヘッダーに X-Forwarded-For フィールドを挿入し、実 IP アドレスを渡します。本トピックでは、このフィールドから実クライアント IP アドレスを抽出するよう各種バックエンド Web サーバーを構成し、ログレコードおよびセキュリティ監査が期待どおりに機能するようにする方法について説明します。

仕組み

CNAME 接続を使用してドメインを WAF に接続すると、クライアントからのリクエストはまず WAF を経由し、場合によっては CDN や Anti-DDoS Pro などの中間プロキシを通過した後、オリジンサーバーに到達します。この時点で、オリジンサーバーが受信する TCP 接続の送信元 IP アドレスは、実際のクライアント IP アドレスではなく、最終ホッププロキシの IP アドレスとなります。

WAF が HTTP リクエストを転送する際、自動的に X-Forwarded-For ヘッダーフィールドを追加します。このフィールドの初期値はクライアント IP アドレスです。リクエストがプロキシノードを通過するたびに、そのノードの IP アドレスが次の形式でフィールドの末尾に追加されます。

X-Forwarded-For: client IP, proxy 1 IP, proxy 2 IP, …

したがって、バックエンド Web サーバーを構成し、X-Forwarded-For ヘッダーから最も左側の IP アドレス（オリジナルのクライアント IP アドレス）を抽出する必要があります。以下のセクションでは、各プラットフォーム別の構成方法を説明します。

ステップ 1：WAF のオリジン向け IP 範囲を取得する

Web Application Firewall コンソールにログインします。上部ナビゲーションバーでご利用の WAF インスタンスのリソースグループおよびリージョン（中国本土 または 中国本土外）を選択します。次に、アクセス管理 > CNAME アクセス > WAF IP アドレス をクリックし、後続の構成のためにすべての WAF オリジン向け IP 範囲を記録します。

ステップ 2：オリジンサーバーを構成する

重要

オリジンサーバーを構成する前に、ECS スナップショットを作成するか設定ファイルをバックアップして環境をバックアップし、設定の損失を防止してください。

Nginx の構成

Nginx は http_realip_module モジュールを使用して X-Forwarded-For を解析します。以下の手順に従い、Nginx 設定を変更します。

`http_realip_module` のインストール状況を確認する

サーバーにログインし、次のコマンドを実行します。

nginx -V 2>&1 | grep -o with-http_realip_module

出力に with-http_realip_module が含まれる場合、モジュールはインストール済みです。WAF オリジン向け IP 範囲を信頼するよう Nginx を構成するに進んでください。
出力がない場合、現在の Nginx にはこのモジュールがコンパイルされていません。realip モジュールを追加するに進んでください。

説明

yum install nginx または apt install nginx を使用してインストールされたバージョンには、通常このモジュールが含まれています。カスタムコンパイル版や最小限のコンテナイメージには含まれていない可能性があります。

`realip` モジュールの追加（不足している場合のみ）

方法 1：システムのパッケージマネージャを使用して再インストールする

# Alibaba Cloud Linux / CentOS / RHEL
sudo yum reinstall nginx -y

# Ubuntu / Debian
sudo apt install --reinstall nginx-core nginx-full

方法 2：ソースコードからコンパイルする

依存関係をインストールします。

# Alibaba Cloud Linux / CentOS / RHEL
sudo yum install -y gcc pcre-devel zlib-devel openssl-devel

# Ubuntu / Debian
sudo apt update
sudo apt install -y build-essential libpcre3-dev zlib1g-dev libssl-dev

インストール済みの Nginx バージョンを確認します。

# バージョンを確認（対応するソースコードをダウンロードするために使用）
nginx -v

# 完全なコンパイル引数を確認
nginx -V 2>&1 | grep 'configure arguments' | sed 's/configure arguments: //'

出力を記録します（例：--prefix=/usr/local/nginx --with-http_ssl_module --with-http_v2_module）。

対応するバージョンの Nginx ソースコードをダウンロードします。バージョン番号は実際のものに置き換えてください。
```
cd /tmp
wget http://nginx.org/download/nginx-1.26.0.tar.gz
tar zxvf nginx-1.26.0.tar.gz
cd nginx-1.26.0
```
コンパイル引数を設定します。ステップ 2 で取得した元の引数をコピーし、末尾に --with-http_realip_module を追加します。
```
./configure \
  --prefix=/usr/local/nginx \
  --with-http_ssl_module \
  --with-http_v2_module \
  --with-http_realip_module
```

サービスをコンパイルおよびアップグレードします。

make
#  make 実行後、objs/ ディレクトリに新しい nginx バイナリファイルが生成されます。

#  古いバイナリをリネーム（バックアップとして保持）
sudo mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old

#  新しくコンパイルしたバージョンに置き換え
sudo cp objs/nginx /usr/local/nginx/sbin/nginx

# 現在のマスタープロセスの PID を取得
OLD_PID=$(pgrep -f 'nginx: master' | head -1)

# 新しいマスタープロセスを起動
sudo kill -USR2 $OLD_PID

# 新しいプロセスの起動を待機
sleep 2

# 古いプロセスを停止
sudo kill -QUIT $OLD_PID

WAF オリジン向け IP 範囲を信頼するよう Nginx を構成する

メイン設定ファイル nginx.conf（デフォルトの場所：/etc/nginx/nginx.conf）を編集し、http {} ブロック内に次の内容を追加します。

http {
  # WAF オリジン向け IP からの X-Forwarded-For ヘッダーを信頼
  # コンソールから取得した実際の WAF オリジン向け IP 範囲に置き換えてください。各範囲は別行に記述する必要があります。
  # すべての WAF オリジン向け範囲を含める必要があります。いずれかが欠落していると、ログに実クライアント IP ではなく WAF オリジン向け IP が表示される可能性があります。
  set_real_ip_from    <ip_range1>;    
  set_real_ip_from    <ip_range2>;   
  ...
  set_real_ip_from    <ip_rangex>;
  
  # 実 IP アドレスを抽出するための X-Forwarded-For ヘッダーを指定
  real_ip_header      X-Forwarded-For;
}

Nginx 設定を再読み込みします。
```
nginx -t && nginx -s reload
```

構成の検証

Web サイトにアクセスします。WAF に接続されているドメイン名に合わせて http://your-domain.com/ を置き換えてください。
```
curl http://your-domain.com/
```
Nginx アクセスログを確認します。実クライアント IP アドレスが表示されるはずです。
```
tail -f /var/log/nginx/access.log
```

IIS 7 の構成（IIS 7 以降に適用）

WAF がリバースプロキシとして動作する場合、デフォルトの IIS ログ内の c-ip フィールドには実際のクライアント IP ではなく WAF オリジン向け IP が記録されます。IIS の W3C カスタムログフィールド機能を使用して、X-Forwarded-For リクエストヘッダーをログに書き込むことで、監査およびトラブルシューティングが可能になります。

IIS マネージャーを開きます。左側の [接続] ツリーでサーバーノードを展開し、対象の Web サイト（例：Default Web Site）を選択します。
右側の [機能ビュー] ペインで、[ログ] アイコンをダブルクリックします。
[ログファイル] セクションで、[フォーマット] が [W3C]（デフォルト値）に設定されていることを確認します。他のフォーマットが選択されている場合は、W3C に変更します。
[ログファイル] セクションで、[フィールドの選択...] をクリックします。
表示されるダイアログボックスの下部で、[フィールドの追加...] をクリックします。
[カスタムフィールドの追加] ダイアログボックスで、次の情報を入力し、[OK] をクリックします。
パラメーター
説明
フィールド名
X-FORWARDED-FOR を入力
ソースタイプ
Request Header を選択
ソース
X-Forwarded-For を入力
カスタムフィールドを保存するには、[OK] をクリックします。
再度 [OK] をクリックしてログフィールドウィンドウを閉じ、[操作] ペインで [適用] をクリックして変更を保存します。
変更を有効にするために IIS を再起動します。
Web サイトにアクセスして構成を検証し、アクセスログ（デフォルトパス：C:\inetpub\logs\LogFiles\W3SVC1\）を確認します。実クライアント IP アドレスが表示されるはずです。

Apache の構成

Apache 2.4 以降には、実クライアント IP アドレスを取得できる remoteip_module（mod_remoteip.so）が含まれています。

Alibaba Cloud Linux / CentOS / RHEL

Apache のメイン設定ファイルを編集します。
```
sudo vim /etc/httpd/conf/httpd.conf
```

ファイルの末尾に次の内容を追加します。

# mod_remoteip を有効化
LoadModule remoteip_module modules/mod_remoteip.so

# WAF が実 IP アドレスを渡す際に使用するリクエストヘッダーを指定（WAF は X-Forwarded-For を使用）
RemoteIPHeader X-Forwarded-For

# WAF オリジン向け IP 範囲を設定。プレースホルダーを実際の Alibaba Cloud WAF オリジン向け IP 範囲に置き換える
RemoteIPTrustedProxy 100.xx.xx.0/10
RemoteIPTrustedProxy 11.xx.xx.0/13
RemoteIPTrustedProxy 112.xx.xx.0/16

設定ファイル内のログフォーマットセクションを見つけ、%h を %a に変更します。%a は接続のリモート IP アドレス（mod_remoteip によって補正された実クライアント IP アドレス）を表し、一方 %h は元の接続 IP アドレス（WAF ノード IP アドレス）を表します。下図は変更済みの例です。
変更を有効にするために Apache を再起動します。
```
sudo systemctl restart httpd
```
Web サイトにアクセスして構成を検証し、アクセスログを確認します。実クライアント IP アドレスが表示されるはずです。
```
tail -f /var/log/httpd/access_log
```

Ubuntu / Debian

remoteip モジュールを有効化します。
```
sudo a2enmod remoteip
```
Apache のメイン設定ファイルを編集します。
```
sudo vim /etc/apache2/apache2.conf
```

ファイルの末尾に次の内容を追加します。

# WAF が実 IP アドレスを渡す際に使用するリクエストヘッダーを指定（WAF は X-Forwarded-For を使用）
RemoteIPHeader X-Forwarded-For

# WAF オリジン向け IP 範囲を設定。プレースホルダーを実際の Alibaba Cloud WAF オリジン向け IP 範囲に置き換える
RemoteIPTrustedProxy 100.xx.xx.0/10
RemoteIPTrustedProxy 11.xx.xx.0/13
RemoteIPTrustedProxy 112.xx.xx.0/16

設定ファイル内のログフォーマットセクションを見つけ、%h を %a に変更します。%a は接続のリモート IP アドレス（mod_remoteip によって補正された実クライアント IP アドレス）を表し、一方 %h は元の接続 IP アドレス（WAF ノード IP アドレス）を表します。下図は変更済みの例です。
変更を有効にするために Apache を再起動します。
```
sudo systemctl restart apache2
```
Web サイトにアクセスして構成を検証し、アクセスログを確認します。実クライアント IP アドレスが表示されるはずです。
```
tail -f /var/log/apache2/access.log
```

Tomcat の構成

Tomcat は X-Forwarded-For 機能を有効化することで、実クライアント IP アドレスを取得できます。

Tomcat インストールディレクトリに移動し、tomcat/conf/server.xml 設定ファイルを開きます。

AccessLogValve ログ設定を次のように変更します。

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt"
pattern="%{X-FORWARDED-FOR}i %l %u %t %r %s %b %D %q %{User-Agent}i %T" resolveHosts="false"/>

Tomcat を再起動します。
```
sudo systemctl restart tomcat
```

Web サイトにアクセスして構成を検証し、アクセスログを確認します。実クライアント IP アドレスが表示されるはずです。

# 次のコマンドを実際の Tomcat インストールディレクトリパスおよび実際のログファイルに置き換えてください
tail -f /opt/tomcat/logs/localhost_access_log.2026-01-01.txt

Kubernetes クラスターの構成

Nginx Ingress Controller を使用する Kubernetes クラスターを WAF に接続すると、実クライアント IP アドレスは WAF によって X-Forwarded-For リクエストヘッダーに追加されます。デフォルトでは、Nginx Ingress Controller はこのフィールドを信頼しないため、ビジネスコンテナは実クライアント IP アドレスを取得できません。

以下の手順に従い、Nginx Ingress Controller を構成します。

Ingress Controller の ConfigMap を編集します。
```
kubectl -n kube-system edit cm nginx-configuration
```

data フィールドに次の設定項目を追加します。

compute-full-forwarded-for: "true"
forwarded-for-header: "X-Forwarded-For"
use-forwarded-headers: "true"

保存して終了します。ポッドを再起動することなく、設定が自動的に有効になります。
構成完了後、Ingress Controller は X-Forwarded-For の最初の IP アドレスを実クライアント IP アドレスとして識別し、リクエスト転送時にこの値を保持します。

高度な最適化：カスタムヘッダーを使用して実 IP アドレスを渡す

複雑なネットワークアーキテクチャでは、標準的な X-Forwarded-For（XFF）ヘッダーに依存すると、なりすましや複数のプロキシレイヤーによる IP 混乱といったリスクが生じます。セキュリティと制御を向上させるため、カスタム HTTP ヘッダーを使用して実クライアント IP アドレスを渡すことができます。

以下の例では、カスタムヘッダーを使用して実クライアント IP アドレスを取得する方法を示します。対応するネットワークアーキテクチャを下図に示します。

CDN の構成

デフォルトでは、CDN はオリジンリクエストに Ali-Cdn-Real-Ip HTTP リクエストヘッダーを付与し、CDN ノードへの接続時のクライアントの実 IP アドレスを示します。カスタムアウトバウンドリクエストヘッダーの追加を使用して、この IP アドレスを WAF に渡すことができます。次の表は CDN コンソールの構成例です。

パラメーター	例
実行内容	追加
要求ヘッダー	カスタムオリジンリクエストヘッダー
カスタム要求ヘッダー名	カスタム名を入力（例：`TrueIP`）
要求ヘッダー値	`$http_Ali_Cdn_Real_Ip`
重複の許可	許可しない
ルール条件	未使用

WAF の構成

WAF コンソールで次の 2 つの構成を完了します。

WAF の前にレイヤー 7 プロキシがあるかどうか (Anti-DDoS Proxy や CDN など)：このオプションを有効化して、WAF が実クライアント IP アドレスを正確に識別できるようにします。
トラフィックマークの有効化：このオプションを有効化して、オリジンサーバーが実クライアント IP アドレスを取得できるようにします。

これらのオプションの構成方法の詳細については、「実クライアント情報」をご参照ください。

パラメーター	例
WAF の前にレイヤー 7 プロキシがあるかどうか (Anti-DDoS Proxy や CDN など)	はいを選択し、次に【推奨】偽装 XFF を回避するために、指定したヘッダの最初の IP アドレスをクライアント送信元 IP アドレスとするを選択します。CDN 構成で指定したカスタム要求ヘッダー名（例：`TrueIP`）を入力します。
トラフィックマークの有効化	リアル送信元 IP アドレスを選択し、CDN 構成で指定したカスタム要求ヘッダー名（例：`TrueIP`）を入力します。

オリジンサーバーの構成

Nginx を例にとります。メイン設定ファイル nginx.conf を編集し、http {} ブロック内に次の内容を追加します。詳細については、「Nginx の構成」をご参照ください。

http {
  # WAF オリジン向け IP アドレスからのリクエストヘッダーを信頼
  # コンソールから取得した実際の WAF オリジン向け IP 範囲に置き換えてください。各範囲は別行に記述する必要があります。
  # すべての WAF オリジン向け範囲を含める必要があります。いずれかが欠落していると、ログに実クライアント IP ではなく WAF オリジン向け IP が表示される可能性があります。
  set_real_ip_from    <ip_range1>;    
  set_real_ip_from    <ip_range2>;   
  ...
  set_real_ip_from    <ip_rangex>;
  
  # 実 IP アドレスを抽出するカスタムリクエストヘッダーを指定。この例では TrueIP を使用
  real_ip_header      TrueIP;
}

オリジンサーバーのセキュリティグループを構成し、WAF オリジン向け IP 範囲からのトラフィックのみを許可することを推奨します。これにより、WAF のみがオリジンサーバーと通信でき、攻撃者が WAF をバイパスしてオリジンサーバーのパブリック IP アドレスに直接アクセスすることを防止できます。

よくある質問

本トピックで説明するオリジンサーバーでの実 IP アドレス構成と、WAF コンソールの WAF の前にレイヤー 7 プロキシがあるかどうか (Anti-DDoS Proxy や CDN など) オプションとの違いは何ですか？

本トピックで説明するオリジンサーバーでの実 IP アドレス構成
- 目的：CNAME 統合を使用してドメインを WAF に接続した後、この構成によりオリジンサーバー（Nginx など）がアクセスログ（access.log など）に WAF オリジン向け IP アドレスではなく実クライアント IP アドレスを記録できるようになります。
- 必須条件：オリジンサーバー上で実クライアント IP アドレスを表示または処理する必要がある場合にのみ必要です。
WAF コンソールの WAF の前面に Anti-DDoS Proxy や CDN などのレイヤー 7 プロキシが配置されていますか オプション
- 適用シナリオ：WAF の前面に他のレイヤー 7 プロキシ（CDN や Anti-DDoS Pro など）が配置されている場合。
- 目的：WAF が特定の HTTP リクエストヘッダー（Ali-Cdn-Real-Ip や X-Forwarded-For など）から実クライアント IP アドレスを抽出し、セキュリティレポートおよび攻撃の識別が実際の送信元 IP アドレスに基づいて行われるようにすること。
- 必須条件：WAF の前面にレイヤー 7 プロキシが配置されている場合にのみ必要です。フロントエンドプロキシが存在しない場合は、デフォルト値の いいえ のままにしてください。

X-Forwarded-For のなりすましとは何ですか？また、どのように防止すればよいですか？

X-Forwarded-For（XFF）のなりすまし とは、攻撃者が HTTP リクエスト内の X-Forwarded-For リクエストヘッダーを構築または改ざんし、偽のクライアント IP アドレスを注入することで、IP ベースのアクセスの制御、ログ監査、またはセキュリティポリシーを回避しようとする攻撃です。X-Forwarded-For は非標準のリクエストヘッダーであり、クライアントが任意に設定可能です。バックエンドサービスがこのフィールドを検証せずにそのまま信頼すると、セキュリティリスクが生じます。

例：XFF なりすまし攻撃コマンド
攻撃者は curl コマンドを使用して X-Forwarded-For ヘッダーを偽造し、IP アドレスを 1.2.3.4 に偽装できます。

curl -H "X-Forwarded-For: 1.2.3.4" https://example.com/

XFF のなりすましを防止するには、実 IP アドレスを渡すためにカスタムの信頼済みリクエストヘッダーを使用します。
CDN または WAF を構成し、オリジンサーバーへのリクエスト送信時に事前定義されたカスタム HTTP リクエストヘッダーを使用して実クライアント IP アドレスを渡すようにします。その後、オリジンサーバーはこのカスタムヘッダーのみを解析します。このリクエストヘッダーは信頼済みミドルウェア（WAF など）によって注入され、クライアントが直接制御できないため、なりすましを効果的に防止できます。