1. Home
2. Next-Gen WAF

多くの場合、保護されているサーバーはロードバランサーやその他のプロキシの背後にあります。この場合、サーバーはこのロードバランサーもしくはプロキシの IP アドレスをリモート (クライアント) IPアドレスとして認識します。この一般的な問題を回避するため、ほとんどのロードバランサーやプロキシは、他のデバイスが使用できるようにリクエストに追加される HTTP ヘッダーに実際のリモート IP アドレスを記録する機能を提供しています。この目的で使用される最も一般的な HTTP ヘッダーは、X-Forwarded-For ヘッダーと X-Real-Ip ヘッダーです。デフォルトでは、エージェントは X-Forwarded-For HTTP ヘッダーが存在する場合、実際のリモートアドレスを取得します。ただし、環境によっては、エージェントを別のヘッダー (あるいはヘッダーなし) を使用するように設定する必要がある場合があります。この (または別の) HTTP ヘッダーは、実際のリモートアドレスにアクセスできるロードバランサーもしくはプロキシを設定することで追加する必要があります。ほとんどの場合、これは他のサービスでも一般的に必要とされているため、すでに実行されています。

すぐに使える状態で最高の互換性を実現するため、エージェントのデフォルトでは、X-Forwarded-For HTTP ヘッダーから実際のリモートアドレスを取得します。追加の設定なしで、エージェントはこの HTTP ヘッダーで指定されたリモートアドレスを使用します。通常は正しい結果が得られますが、異なるヘッダーを使用する環境や、実際のリモートアドレスを取得する別の方法を用いる環境では、この方法が機能しない場合があります。

制約と考慮事項

クライアント IP ヘッダーを操作する際は、次の制限と考慮事項に留意してください。

• エッジ WAF のデプロイは、代替クライアント IP ヘッダーをサポートしていません。

• 最大 10 種類のヘッダーを指定できます。

• ヘッダーは上から順に使用されます。つまり、リクエストに最初のヘッダーが存在しない場合、エージェントは2番目のヘッダーを確認し、リストされたヘッダーが検出されるまでこの処理を続けます。定義されたヘッダーが存在しない場合、あるいは値が IP アドレスでない場合、エージェントはソケットアドレスを使用します。

• コンソールで設定された代替クライアント IP ヘッダーが優先され、エージェントで直接設定された代替クライアント IP ヘッダーを上書きします。

• クライアント IP ヘッダーを WebSocket 検査に適用するには、エージェントで直接設定する必要があります。コンソールで設定されたクライアント IP ヘッダーは、WebSocket の検査には適用されません。

• Next-Gen WAF は、IPv6 アドレスの検出、タグ付け、ブロックリスト登録、許可リスト登録、フィルタリング、および国・DNS 検索を含む、IPv6 の完全なサポートを提供します。

コントロールパネルでの代替ヘッダーの設定

代替のクライアント IP ヘッダーを設定して、エージェントが実際のリモート IP アドレスをコンソールから直接取得できるようにできます。

コンソールで代替ヘッダーを削除する

コンソールで代替クライアント IP ヘッダーを直接削除することができます。

エージェント内で代替ヘッダーを直接設定する

以下の詳細に従って、エージェントで直接代替ヘッダーを設定することができます。

代替 HTTP ヘッダー

実際のリモートアドレスを渡すために別の HTTP ヘッダーを使用する環境の場合、そのヘッダーを使用するようにエージェントを設定する必要があります。代替ヘッダーは、client-ip-header エージェント設定オプションを使用して設定できます。たとえば、X-Real-IP ヘッダーを使用するようにエージェントを指定するには、/etc/sigsci/agent.conf ファイルに以下の行を追加します。

client-ip-header = "X-Real-Ip"

これはよくある問題なので、ほとんどのWeb サーバーは実際のリモートアドレスを解釈するための代替モジュールを提供しています。これらのどれかが使われると、リモートアドレスは正しくエージェントに渡され、エージェントがデフォルトの X-Forwarded-For ヘッダーを解釈できないようにしたいところです。これを行わないと、エージェントがリモートアドレスを誤って解釈する可能性があります。これを行うには、 client-ip-header オプションを空の値に設定する必要があります。

client-ip-header = " "

エージェントの設定が更新された場合、エージェントを再起動する必要があります。

X-Forwarded-For ヘッダー設定

エージェントはリクエストを受信すると、X-Forwarded-For (XFF) ヘッダーの左端の IP アドレスを読み取ります。

たとえば、受信したリクエストに以下のものが含まれているとします。

X_FORWARDED_FOR="127.0.0.1, 203.0.113.63"

エージェントは以下のように報告します。

127.0.0.1

上記の場合、真の IP アドレスが確実に識別されるように、代わりに XFF IP アドレスを右から左に読み取るようにエージェントを設定できます。エージェントが XFF IP アドレスを右から左に読み取るように設定するには、local-networks エージェント設定オプションを private に設定します。次に、エージェント設定ファイル (デフォルトでは /etc/sigsci/agent.conf) に次の行を追加します。

local-networks = "private"

local-networks オプションを private に設定することで、エージェントは XFF ヘッダー内の IP アドレスを右から左に読み取り、最初の非ローカル IP アドレスを選択するようになります。上記の例では、エージェントは次のように報告します。

203.0.113.63

さまざまな Web サーバーの代替手段

実際のリモートアドレスを解釈するための代替モジュールがいくつかあります。これらのいずれかを使用する場合は、上記のように、エージェントによるヘッダーの解釈を必ず無効にしてください。

NGINX - http_realip_module

NGINX に含まれている http_realip_module を使用すると、HTTP ヘッダーから実際の IP を抽出し、それを内部で使用できるようになります。これにより、設定可能な検証が実行され、なりすましのリスクが大幅に低くなります。さらに、このモジュールは、NGINX が適切な処理を実行するようにリモートアドレスをシームレスに置き換えます。

NGINX で http_realip_module を使用するには、そのモジュールがバイナリに組み込まれている必要があります。Fastly が提供するバイナリの場合、モジュールはすでに組み込まれています (ほとんどのベンダーが提供する NGINX バイナリにも当てはまります)。ただし、NGINX をソースからビルドしている場合は、NGINX を設定してこのモジュールを有効にする必要があります。

このモジュールに関する NGINX ドキュメントには、より詳しい情報が記載されています。

このモジュールの推奨設定は、set_real_ip_fromディレクティブをすべての信頼された (内部) アドレスまたはネットワークに設定し、real_ip_recursiveディレクティブを介して再帰を有効にすることです。例えば、ロードバランサーの IP が 192.0.2.54 で X-Forwarded-For ヘッダーを追加している場合は、NGINX の http または server ブロックのどちらかで次の設定を使用することができます。

set_real_ip_from  192.0.2.54;
real_ip_header    X-Forwarded-For;
real_ip_recursive on;

NGINX http_realip_module - プロキシプロトコル

NGINX のデプロイが、プロキシプロトコルを介して NGINX と通信するロードバランサーなどの背後に設定されている場合、real_ip_header は proxy_protocol パラメータから取得する必要があります。これは、http ブロックまたは server ブロックのいずれかで設定できます。

set_real_ip_from  192.0.2.54;
real_ip_header    proxy_protocol;

このタイプのデプロイに関する詳細な設定ガイダンスについては、NGINX ドキュメントをご覧ください。

Apache Web サーバー 2.4+ - mod_remoteip

Apache Web サーバー 2.4+ に含まれている mod_remoteip モジュールを使用すると、HTTP ヘッダーから実際の IP を抽出し、それを内部で使用できるようになります。これにより、設定可能な検証が実行され、なりすましのリスクが大幅に低くなります。さらに、このモジュールは、Web サーバーが適切な処理を実行するようにリモートアドレスをシームレスに置き換えます。

mod_remoteipを使用するには、モジュールをロードして設定する必要があります。

このモジュールに関する Apache ドキュメント には、より詳しい情報が記載されています。

このモジュールでは、RemoteIPHeader ディレクティブに、実際のクライアント IP アドレスを含む適切なヘッダー (X-Forwarded-For など) を設定することが推奨されます。これは、RemoteIPInternalProxy と併用できます。このコードは、有効な RemoteIPHeader 値 (ロードバランサーまたはリバースプロキシなど) を表示することを信頼できる1つ以上のアドレス (またはアドレスブロック) を追加します。

たとえば、ロードバランサーの IP アドレスが 192.0.2.54 で、X-Forwarded-For ヘッダーを追加している場合、Apache HTTP サーバーの設定 (通常は apache2.conf または httpd.conf) で以下を使用できます。

# Load the module (see also a2enmod command)
LoadModule remoteip_module mod_remoteip.so

# Configure
RemoteIPInternalProxy 192.0.2.54
RemoteIPHeader X-Forwarded-For

Debian/Ubuntu では、設定に直接 LoadModule ディレクティブを追加する代わりに、通常は a2enmod コマンドを使用して動的にモジュールを有効にします。例 :

$ sudo a2enmod remoteip

Apache Web サーバー 2.2 以前 - さまざまなソリューション

Apache Web サーバー 2.4 より前のバージョンでは、HTTP ヘッダーを解釈して実際のリモートアドレスを取得するためのモジュールが提供されていません。ただし、Apache Web サーバー 2.4+ 以降と同様に使用できるようになるサードパーティ製モジュールがいくつかあります。

以下は人気のあるサードパーティ製モジュールです。

• mod_realip2

• mod_rpaf

既知の問題

実際のクライアントの IP アドレスを管理する際は、以下の点にご注意ください。

Google Container Engine

Google Container Engine (GKE) で Kubernetes をダウングレードした場合、または Kubernetes v1.1 以上にアップグレードしていない場合は、実際のクライアント IP アドレスを取得できない可能性があります。取得できないときは、Kubernetes をアップグレードしてください。

Kubernetes v1.1 より前

v1.1 より前の Kubernetes を使用している場合、現時点でベータ版以外のロードバランサーのオプションはネットワークロードバランサーのみです。ネットワークロードバランサーは HTTPS ロードバランサーと異なり、X-Forwarded-For ヘッダーを追加しません。そのため、実際のリモートアドレスは取得できません。このサポートで追加が可能な HTTPS ロードバランサーは現在ベータ版で、Kubernetes v1.1 で利用可能になる予定です。

• Google Container Network ロードバランサー : https://cloud.google.com/container-engine/docs/load-balancer

• Google Container HTTP Load Balancer (ベータ版): https://cloud.google.com/container-engine/docs/tutorials/http-balancer

• Kubernetes Ingress ロードバランシング : https://kubernetes.io/docs/concepts/services-networking/ingress/#load-balancing

関連コンテンツ

• ヘッダーリンク

• Next-Gen WAF での API の使用