私のApacheサーバーはNAT変換でファイアウォールの背後にあります。私が抱えている問題は、ファイアウォールのアドレスではなく、実際に誰がリクエストを行っているかを確認したいということです。それを知ってうれしいです。ファイアウォールは機能していますが、トラフィックパターンを実際に確認するには、実際のIPアドレスを確認する必要があります。
[〜#〜] update [〜#〜]
ファイアウォールは、fwbuilderによって作成されたiptableルールを使用するCentOS5.2ボックスです。
iptablesはすべてのインターフェースでリクエストに応答し、Squidは内部向けのインターフェースでのみ実行されます。
私はこれをプロキシサーバーとロードバランサーで見ました。通常のケースでは、インバウンドトラフィックがプロキシを通過してWebサーバーに到達しますが、Webサーバーのデフォルトゲートウェイはプロキシ以外のものです。リバースNATを実行することにより、WebサーバーはクライアントのIPではなくプロキシのIPを取得します。プロキシへのルートがあるため(実際にはおそらく同じサブネット内にあるため)、常にクライアントにリターントラフィックを返すことができることが保証されます。
これに対する1つの修正は、プロキシがクライアントの実際のIPを含むカスタムHTTPヘッダーをWebサーバーが解析できるHTTP要求に挿入することです。 Apacheの場合、%{Custom-Header}
の代わりに%h
を使用するようにLogFormat
ステートメントを変更するという単純な問題になります。もちろん、これは、デバイスが実際にHTTPを認識し、任意のヘッダーをGET/POST/etcに挿入できるかどうかによって異なります。リクエスト。これはプロキシとロードバランサーに共通の機能ですが、ファイアウォールにはそれほど多くありません。さらに、デバイスがSSLターミネーションを実行していない限り、HTTPSリクエストには役立ちません。カイルが言ったように、私たちはあなたのファイアウォールについてもっと知る必要があります。
ミックスにイカがいる場合は、その情報を転送する目的で特別に実装されたX-Forwarded-Forヘッダーを探す必要があります。
このヘッダーは、両方が偽造される可能性があるため、少なくともOriginIPを使用するのと同じくらい安全ではないことに注意してください。
LogFormatを変更して%hを%{X-Forwarded-For} iに置き換え、構成を再ロードすることで、これが当てはまるかどうかをテストできます。
NATこの場合は、宛先アドレスのみNATであるため、クライアントは同じ送信元アドレス(パブリックIP)を保持します)で最も一般的だと思います。ですから、ファイアウォールについてもっと知る必要があると思います。
したがって、たとえば:
Client: 12.12.12.12
Public Website Address: 11.11.11.11
Private Web Server ip: 10.0.0.2
Client --> Your Firewall --> Web Server
Client Packet:
Src IP:12.12.12.12
Dst IP:11.11.11.11
NAT Firewall:
Takes client Packet, changes Dst from 11.11.11.11 to 10.0.0.2.
Make entry in table to remember this mapping
Web Server (When Client Packet Arrives):
Src:12.12.12.12
Dst: 10.0.0.2
Reply Packet from Web Server:
Src: 10.0.0.2
Dst: 12.12.12.12
NAT Firewall:
Takes Reply Packet, changes Src to 11.11.11.11 after looking at mapping
Client (When Packet Arives):
Src: 11.11.11.11
Dst: 12.12.12.12
クライアントもNATの背後にいる可能性がありますが、それはこの目的のためにそれをより混乱させるだけです。
あなたがそれをどのように説明しているかから、この「ファイアウォール」はリバースプロキシのように見えます。
NATは通常、着信接続ではなく発信接続に適用されます。プライベートネットワーク内のコンピューターが外部への接続を開くと、リモートサーバーはその接続がファイアウォールのパブリックIPアドレスからのものであると見なします。ただし、リモートコンピューターが(ファイアウォールのポート転送を介して)内部サーバーの1つへの接続を開くと、その接続は、発信元の実際のパブリックIPアドレスからのものであると見なされます。あなたが説明しているのは、NATファイアウォールではなく、リバースプロキシの典型的な動作です。
そのファイアウォールで実行され、着信HTTP(S)接続をインターセプトするリバースプロキシ(SQUIDなど)がないことを確認しますか? SQUIDは透過プロキシとしても機能するため、その知識がなくてもSQUIDが存在する可能性があります。これは、内部Webサイトを公開するときのISAサーバーの標準的な動作でもあります。ポートフォワーディングを実行していると思っていても、実際にはWebサーバーをリバースプロキシしています。 。
ログにローカルIPが表示されている場合は、その横にあるユーザーエージェントも確認してください。 「PageSpeed」の場合、これらのリクエストのローカルIPを表示するには[〜#〜] ok [〜#〜]である必要があります。