リバースプロキシが正しいクライアントIPを送信しているか確認する方法

クライアントのIP転送を検証するには、既知の外部ソースとすべてのプロキシヘッダーおよびバックエンドの最終解析アドレスを比較します。

リバースプロキシはクライアント接続を終了するため、バックエンドは通常プロキシのソケットアドレスを認識しますが、プロキシが信頼できるリクエストメタデータを渡す場合は例外です。テストでは、直接のピアアドレスとForwarded、X-Forwarded-For、X-Real-IPを区別し、すべての信頼できるホップを記録し、インターネットクライアントがログ、レート制限、アクセス制御に使用される値を偽装できないことを証明する必要があります。

ホーム外部から既知のクライアントIPテストを作成する

モバイルデータや他の外部ネットワークのデバイスを使用し、リクエスト直前にその公開IPv4またはIPv6アドレスを記録します。公開リバースプロキシを通じてユニークなパス、クエリ値、またはタイムスタンプを送信します。

MDNはX-Forwarded-Forを、プロキシ接続を跨いで元のクライアントアドレスを保持する事実上のヘッダーとして説明しています。

そのリクエストに対してエッジプロキシログ、中間プロキシログ、バックエンドアプリケーションログを収集します。既知のソースと相関するタイムスタンプがなければ、複数の同時ユーザーによりヘッダーチェーンが曖昧になる可能性があります。

ソケットピアとすべての転送ヘッダーを記録する

バックエンドでは、直接のTCPピアアドレスをForwarded、X-Forwarded-For、X-Real-IP、およびCDN固有のクライアントヘッダーとは別にログに記録します。最初のテスト中に生の値を上書きしないでください。

「実際の」クライアントIP処理の実用的な分析では、精度はプロキシがヘッダーをどのように設定または追加し、以前の値が偽装可能かどうかに依存すると警告しています。プロキシ信頼モデル全体は実際のネットワーク構成と一致しなければなりません。

バックエンドのソケットピアは直近の信頼できるプロキシと等しく、選択されたクライアントアドレスは外部テストデバイスと等しいべきです。バックエンドがプロキシアドレスのみをログに記録する場合、ヘッダーの作成または解析が欠落しています。

各プロキシがヘッダーをどのように追加または置換するかを検証する

CDNやトンネルからエッジプロキシ、内部プロキシ、アプリケーションまでのすべてのホップを検査します。各ホップが既存のリストに追加するのか、信頼できない入力を置換するのか、ヘッダーを変更せずに渡すのかを記録します。

Sling Academyは、NGINXがX-Real-IPを直近の接続から設定し、proxy_add_x_forwarded_forでチェーンを追加できることを説明しています。

最初の信頼できるエッジを設定してクライアント提供の転送ヘッダーを削除または置換し、その後制御された内部ホップでアドレスを追加します。信頼するプロキシの数を定義せずに左端または右端の値を盲目的に受け入れないでください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

バックエンドを既知のプロキシアドレスのみを信頼するように設定する

アプリケーションまたはウェブサーバーの信頼できるプロキシリストを正確なリバースプロキシアドレスまたは制御されたサブネットに設定します。通常のLANやインターネットクライアントからの直接接続が信頼できるヘッダーソースとして扱われないことを確認してください。

Ip2Geoの説明では、アプリケーション接続はロードバランサーまたはリバースプロキシから発生し、元のIPを安全に解析するには信頼ホップルールが必要であり、任意の入力を受け入れてはいけないと述べています。

コンテナ、オーバーレイネットワーク、CDNの影響でプロキシアドレスが変わる場合は、サポートされる範囲を文書化し、意図的に更新してください。プロキシが現在プライベートアドレスを使用しているからといってすべてのプライベートアドレスを信頼しないでください。

偽装ヘッダーテストを実行する

外部テストデバイスから、実際のプロキシを通じて接続しながら偽造したX-Forwarded-ForまたはForwarded値を送信します。生の受信ヘッダー、正規化されたプロキシヘッダー、バックエンドで選択されたクライアントアドレスを比較します。

正しい結果は、信頼できるエッジが信頼できない入力を置換または安全に追加し、バックエンドが文書化された信頼ホップ数に基づいてアドレスを選択することです。偽造されたアドレスが認証や許可リストに使用されてはなりません。

そのポートが到達可能であれば、LANセグメントからの直接バックエンドテストを繰り返します。バックエンドは信頼できない直接クライアントからの転送ヘッダーを無視し、実際のソケットピアを記録するべきです。

IPv4、IPv6、およびマルチプロキシ経路を検証する

IPv4およびIPv6、通常の公開ホスト名、ならびに本番環境で使用されるCDN、トンネル、または二次プロキシを通じてテストを繰り返します。ログが有効なアドレス形式を保持し、チェーンを切り詰めていないことを確認します。

ZimaSpaceのリバースプロキシリクエストの識別ガイドは、正しい転送値がログ以外の理由で重要である背景を提供します。

既知のソースが解析されたクライアントIPと一致し、信頼できるプロキシが生のチェーンで可視のままであり、偽装試行が失敗し、セキュリティ制御が正規化された値を一貫して使用している場合にのみプロキシは検証されます。CDN、トンネル、または別のプロキシホップを追加した後に再確認してください。