Web Application Firewall (WAF) で CNAME 統合を使用すると、オリジンサーバーが受信するリクエストの送信元 IP アドレスは、クライアントのリアル IP ではなく、最終ホップのプロキシの IP アドレスになります。WAF は、クライアントのリアル IP をサーバーに渡すために、X-Forwarded-For HTTP リクエストヘッダーを追加します。このトピックでは、バックエンド Web サーバーがこのヘッダーからクライアント IP を抽出し、ロギングとセキュリティ監査を正しく機能させるための設定方法について説明します。
仕組み
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 の back-to-origin IP 範囲の取得
Web Application Firewall コンソールにログインします。上部メニューで、お使いの WAF インスタンスのリソースグループとリージョン ([中国本土]または[中国本土外]) を選択します。次に、 をクリックし、後で設定するためにすべての WAF の back-to-origin 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が含まれている場合、モジュールはインストールされています。「Nginx が WAF の back-to-origin IP 範囲を信頼するように設定する」に進んでください。出力が返されない場合、現在の 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
Nginx が WAF の back-to-origin IP 範囲を信頼するように設定する
-
メイン設定ファイル
nginx.conf(デフォルトの場所:/etc/nginx/nginx.conf) を編集し、http {}ブロックに次の内容を追加します。http { # WAF から送信されたリクエストの X-Forwarded-For ヘッダーを信頼します。 # 次のプレースホルダーを、コンソールから取得した WAF の back-to-origin IP 範囲に置き換えます。 # すべての IP 範囲を追加する必要があります。いずれかが欠けていると、一部のリクエストではクライアントのリアル IP の代わりに WAF の IP がログに記録されることがあります。 set_real_ip_from <ip_range1>; set_real_ip_from <ip_range2>; ... set_real_ip_from <ip_rangex>; # Nginx に、X-Forwarded-For ヘッダーからクライアントのリアル IP を取得するよう指示します。 real_ip_header X-Forwarded-For; } Nginx の設定をリロードします:
nginx -t && nginx -s reload
設定の確認
Web サイトにアクセスします。
http://your-domain.com/を WAF に接続されているドメイン名に置き換えます。curl http://your-domain.com/Nginx のアクセスログを表示します。クライアントのリアル IP アドレスが表示されるはずです。
tail -f /var/log/nginx/access.log
IIS 7 の設定 (IIS 7 以降に適用)
WAF がリバースプロキシとして機能する場合、デフォルトの IIS ログの c-ip フィールドには、クライアントのリアル IP の代わりに WAF の back-to-origin IP が記録されます。IIS の W3C カスタムログフィールド機能を使用して、X-Forwarded-For リクエストヘッダーをログに書き込み、監査やトラブルシューティングに役立てることができます。
IIS マネージャーを開きます。左側の [接続] ツリーで、サーバーノードを展開し、対象の Web サイト (例:
Default Web Site) を選択します。-
右側の [機能ビュー] ペインで、[ログ記録] アイコンをダブルクリックします。
[ログ ファイル] セクションで、[形式] が [W3C] (デフォルト値) に設定されていることを確認します。異なる形式が選択されている場合は、W3C に変更します。
[ログ ファイル] セクションで、[フィールドの選択...] をクリックします。
表示されるダイアログボックスの下部で、[フィールドの追加...] をクリックします。
[カスタム フィールドの追加] ダイアログボックスで、次の情報を入力し、[OK] をクリックします。
パラメーター
説明
フィールド名
X-FORWARDED-FORと入力しますソースの種類
要求ヘッダーを選択しますソース
X-Forwarded-Forと入力します[OK] をクリックしてカスタムフィールドを保存します。
[OK] をもう一度クリックしてログ記録フィールドのウィンドウを閉じ、[操作] ペインで [適用] をクリックして変更を保存します。
IIS を再起動して変更を有効にします。
Web サイトにアクセスして設定を確認し、アクセスログ (デフォルトパス:
C:\inetpub\logs\LogFiles\W3SVC1\) を表示します。クライアントのリアル IP アドレスが表示されるはずです。
Apache の設定
Apache 2.4 以降には remoteip_module (mod_remoteip.so) が含まれており、これを使用してクライアントのリアル IP アドレスを取得できます。
Alibaba Cloud Linux / CentOS / RHEL
Apache のメイン設定ファイルを編集します。
sudo vim /etc/httpd/conf/httpd.conf-
ファイルの末尾に次の内容を追加します。
# mod_remoteip を有効化します。 LoadModule remoteip_module modules/mod_remoteip.so # クライアントのリアル IP が X-Forwarded-For ヘッダーで渡されることを指定します。 RemoteIPHeader X-Forwarded-For # WAF の back-to-origin IP 範囲を信頼できるプロキシとして追加します。 # これらを実際の IP 範囲に置き換えてください。 RemoteIPTrustedProxy 100.xx.xx.0/10 RemoteIPTrustedProxy 11.xx.xx.0/13 RemoteIPTrustedProxy 112.xx.xx.0/16 -
設定ファイルのログ形式セクションに移動し、
%hを%aに変更します。%aはmod_remoteipによって特定される接続のリモート IP アドレス (クライアントのリアル IP アドレス) を表し、%hは元の接続 IP アドレス (WAF ノードの IP アドレス) です。変更後の設定例を以下に示します。<IfModule log_config_module> # # The following directives define some format nicknames for use with # a CustomLog directive (see below). # LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%a %l %u %t \"%r\" %>s %b" common <IfModule logio_module> # You need to enable mod_logio.c to use %I and %O LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio </IfModule> # # The location and format of the access logfile (Common Logfile Format). # If you do not define any access logfiles within a <VirtualHost> # container, they will be logged here. Contrariwise, if you *do* # define per-<VirtualHost> access logfiles, transactions will be # logged therein and *not* in this file. # #CustomLog "logs/access_log" common # # If you prefer a logfile with access, agent, and referer information # (Combined Logfile Format) you can use the following directive. # CustomLog "logs/access_log" combined </IfModule> Apache を再起動して変更を有効にします。
sudo systemctl restart httpdWeb サイトにアクセスして設定を確認し、アクセスログを表示します。クライアントのリアル IP アドレスが表示されるはずです。
tail -f /var/log/httpd/access_log
Ubuntu / Debian
remoteipモジュールを有効にします。sudo a2enmod remoteipApache のメイン設定ファイルを編集します。
sudo vim /etc/apache2/apache2.conf-
ファイルの末尾に次の内容を追加します。
# クライアントのリアル IP が X-Forwarded-For ヘッダーで渡されることを指定します。 RemoteIPHeader X-Forwarded-For # WAF の back-to-origin IP 範囲を信頼できるプロキシとして追加します。 # これらを実際の IP 範囲に置き換えてください。 RemoteIPTrustedProxy 100.xx.xx.0/10 RemoteIPTrustedProxy 11.xx.xx.0/13 RemoteIPTrustedProxy 112.xx.xx.0/16 -
設定ファイルのログ形式セクションに移動し、
%hを%aに変更します。%aはmod_remoteipによって特定されるクライアントのリアル IP アドレスを表し、%hは元の接続 IP アドレス (WAF ノードの IP アドレス) を表します。変更後の設定例を以下に示します。# LogFormat "%v:%p %a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%a %l %u %t \"%r\" %>s %O" common LogFormat "%{Referer}i -> %U" referer LogFormat "%{User-agent}i" agent Apache を再起動して変更を有効にします。
sudo systemctl restart apache2Web サイトにアクセスして設定を確認し、アクセスログを表示します。クライアントのリアル 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 tomcatWeb サイトにアクセスして設定を確認し、アクセスログを表示します。クライアントのリアル 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-configurationdataフィールドに次の設定項目を追加します:compute-full-forwarded-for: "true" forwarded-for-header: "X-Forwarded-For" use-forwarded-headers: "true"保存して終了します。設定は Pod を再起動しなくても自動的に有効になります。
設定が完了すると、Ingress Controller は
X-Forwarded-Forの最初の IP アドレスをクライアントのリアル IP アドレスとして識別し、リクエストを転送する際にこの値を保持します。
高度な最適化:カスタムヘッダーを使用したリアル IP アドレスの受け渡し
複雑なネットワークアーキテクチャでは、標準の X-Forwarded-For (XFF) ヘッダーに依存すると、スプーフィングや複数のプロキシ層にまたがる IP アドレスの混同などのリスクが伴います。カスタム HTTP ヘッダーを使用してクライアントのリアル IP アドレスを渡すことで、セキュリティと制御を向上させることができます。
次の例は、カスタムヘッダーを使用してクライアントのリアル IP を取得する方法を示しています。
CDN の設定
デフォルトでは、CDN は back-to-origin リクエストに
Ali-Cdn-Real-IpHTTP リクエストヘッダーを付与します。これは、クライアントが CDN ノードに接続したときのリアル IP アドレスを示します。カスタム back-to-origin リクエストヘッダーの追加機能を使用して、この IP アドレスを WAF に渡すことができます。次の表は、CDN コンソールの設定例を示しています。パラメーター
例
[実行内容]
追加
[要求ヘッダー]
カスタム back-to-origin リクエストヘッダー
[カスタム要求ヘッダー名]
カスタム名を入力します。例:
TrueIP[要求ヘッダー値]
$http_Ali_Cdn_Real_Ip[重複の許可]
許可しない
ルール条件
使用しない
WAF の設定
WAF コンソールで次の 2 つの設定を完了します:
[WAF の前にレイヤー 7 プロキシがあるかどうか (Anti-DDoS Proxy や CDN など)]:このオプションを有効にすると、WAF がクライアントのリアル IP アドレスを正しく識別します。
[トラフィックマークの有効化]:このオプションを有効にすると、オリジンサーバーがクライアントのリアル IP アドレスを取得できるようになります。
これらのオプションの設定方法の詳細については、「クライアントのリアル IPに関する情報」をご参照ください。
パラメーター
例
[WAF の前にレイヤー 7 プロキシがあるかどうか (Anti-DDoS Proxy や CDN など)]
[はい] を選択し、次に 【推奨】偽装 XFF を回避するために、指定したヘッダの最初の IP アドレスをクライアント送信元 IP アドレスとする を選択します。CDN 設定で指定した[カスタム要求ヘッダー名] (例:
TrueIP) を入力します。[トラフィックマークの有効化]
リアル送信元 IP アドレス を選択し、CDN 設定で指定した[カスタム要求ヘッダー名] (例:
TrueIP) を入力します。-
オリジンサーバーの設定
Nginx を例にとります。メイン設定ファイル
nginx.confを編集し、http {}ブロックに次の内容を追加します。詳細については、「Nginx の設定」をご参照ください。http { # WAF の back-to-origin IP アドレスからのリクエストヘッダーを信頼します。 # 次のプレースホルダーを、コンソールから取得した WAF の back-to-origin IP 範囲に置き換えます。 # すべての IP 範囲を追加する必要があります。いずれかが欠けていると、一部のリクエストではクライアントのリアル IP の代わりに WAF の IP がログに記録されることがあります。 set_real_ip_from <ip_range1>; set_real_ip_from <ip_range2>; ... set_real_ip_from <ip_rangex>; # Nginx に、この例ではカスタムヘッダー TrueIP からリアル IP を取得するよう指示します。 real_ip_header TrueIP; }オリジンサーバーのセキュリティグループを設定して、WAF の back-to-origin IP 範囲からのトラフィックのみを許可することを推奨します。これにより、WAF のみがオリジンサーバーと通信できるようになり、攻撃者が WAF をバイパスしてオリジンサーバーのパブリック IP アドレスに直接アクセスするのを防ぎます。
よくある質問
オリジンサーバーでの実際の IP アドレス設定 (本トピックで説明) と、WAF コンソールの WAF の前にレイヤー 7 プロキシがあるかどうか (Anti-DDoS Proxy や CDN など) オプションとの違いは何ですか。
オリジンサーバーでのリアル IP アドレス設定 (このトピックで説明)
目的:CNAME 統合を使用してドメインを WAF に接続した後、この設定により、オリジンサーバー (Nginx など) がそのアクセスログ (
access.logなど) に、WAF の back-to-origin 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 リクエストヘッダーを使用して、back-to-origin リクエストを送信する際にクライアントのリアル IP アドレスを渡すようにします。その後、オリジンサーバーはこのカスタムヘッダーのみを解析します。このリクエストヘッダーは信頼できるミドルウェア (WAF など) によって挿入され、クライアントが直接制御することはできないため、スプーフィングを効果的に防ぐことができます。