Log do Apache mostrando o endereço do servidor NAT em vez do IP do solicitante real

Question

Meu servidor Apache está atrás de um firewall com uma tradução NAT. O problema que estou tendo é que eu quero ver quem está realmente fazendo a solicitação em vez do endereço do meu firewall. É bom saber que o firewall está funcionando, mas para realmente observar os padrões de tráfego, preciso ver o endereço IP do mundo real.

UPDATE

Firewall é uma caixa do CentOS 5.2 usando regras iptable criadas pelo fwbuilder.

O iptables responde a pedidos em todas as interfaces, o Squid está rodando apenas em interfaces internas.

    

Answer 1

Eu já vi isso com servidores proxy e balanceadores de carga. O caso usual é que o tráfego de entrada cruza o proxy para chegar ao servidor Web, mas o gateway padrão do servidor Web é algo diferente do proxy. Ao fazer o NAT reverso, o servidor Web obtém o IP do proxy em vez do do cliente. Como ele terá uma rota para o proxy (e, de fato, provavelmente está na mesma sub-rede), é garantido que sempre pode obter o retorno do tráfego de volta ao cliente.

Uma correção para isso é o proxy inserir um cabeçalho HTTP personalizado contendo o IP real do cliente na solicitação HTTP que o servidor Web pode analisar. Para o Apache, torna-se um problema simples de modificar sua instrução LogFormat para usar %{Custom-Header} em vez de %h . Claro, isso depende do fato de o seu dispositivo estar ciente do HTTP e ser capaz de inserir cabeçalhos arbitrários em GET / POST / etc. solicitações de. É um recurso comum para proxies e balanceadores de carga, mas não tanto para firewalls. Além disso, a menos que seu dispositivo esteja encerrando o SSL, ele não ajudará em solicitações HTTPS. Como Kyle disse, precisamos saber mais sobre o seu firewall.

    

Answer 2

Eu acho mais comum com NAT, neste caso, apenas para NAT o endereço de destino. Portanto, os clientes ainda terão o mesmo endereço de origem (o ip público). Então, acho que precisamos saber mais sobre o firewall.

Então, por exemplo:

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

As chances são de que o cliente também esteja por trás do NAT, mas isso só o torna mais confuso para esse propósito.

    

Answer 3

De como você está descrevendo, esse "firewall" parece muito mais com um proxy reverso.

O NAT geralmente é aplicado a conexões de saída, não a conexões recebidas. Quando um computador na rede privada abre uma conexão com o mundo externo, o servidor remoto vê a conexão como proveniente do endereço IP público do firewall; mas quando um computador remoto abre uma conexão com um de seus servidores internos (através de um encaminhamento de porta no firewall), ele vê a conexão como proveniente do endereço IP público real do qual está originando. O que você está descrevendo é o comportamento típico de um proxy reverso, não de um firewall NAT.

Tem certeza de que não há nenhum proxy reverso (como o SQUID) sendo executado nesse firewall e interceptando conexões HTTP (S) de entrada? O SQUID também pode atuar como um proxy transparente, por isso pode estar lá sem que você tenha conhecimento disso. Esse também seria o comportamento padrão do ISA Server quando você publica um site interno: mesmo se você acha que está apenas fazendo um encaminhamento de porta, na verdade você está fazendo um proxy reverso do servidor da Web.

    

Answer 4

Se você tem squid no mix, você deve procurar o cabeçalho X-Forwarded-For, que foi implementado especificamente para o propósito de passar essa informação adiante.

Note que este cabeçalho é pelo menos tão inseguro quanto usando o ip de origem, pois ambos podem ser falsificados.

Você pode testar se esse é o caso modificando seu LogFormat substituindo% h por% {X-Forwarded-For} ie recarregando sua configuração.