Como Verificar se um Proxy Reverso Está a Enviar o IP Correto do Cliente

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

How to Verify a Reverse Proxy Is Sending the Correct Client IP

Verifique o encaminhamento do IP do cliente comparando uma fonte externa conhecida com cada cabeçalho de proxy e o endereço final analisado no backend.

Um proxy reverso termina a conexão do cliente, por isso o backend normalmente vê o endereço do socket do proxy, a menos que o proxy transmita metadados de pedido confiáveis. O teste deve distinguir o endereço do par direto dos cabeçalhos Forwarded, X-Forwarded-For e X-Real-IP, documentar cada salto confiável e provar que um cliente da internet não pode falsificar o valor usado para registos, limites de taxa ou controlo de acesso.

Crie um Teste de IP de Cliente Conhecido Fora de Casa

Use um dispositivo com dados móveis ou outra rede externa e registe o seu endereço público IPv4 ou IPv6 imediatamente antes do pedido. Envie um caminho único, valor de consulta ou carimbo de data/hora através do proxy reverso público.

A MDN descreve X-Forwarded-For como um cabeçalho de facto para preservar o endereço do cliente originário através das conexões de proxy.

Recolha o registo do proxy de borda, qualquer registo de proxy intermédio e o registo da aplicação backend para esse pedido. Sem uma fonte conhecida e um carimbo de data/hora correlacionado, múltiplos utilizadores concorrentes podem tornar a cadeia de cabeçalhos ambígua.

Registe o Par do Socket e Cada Cabeçalho Encaminhado

No backend, registe o endereço TCP direto do par separadamente dos cabeçalhos Forwarded, X-Forwarded-For, X-Real-IP e qualquer cabeçalho de cliente específico de CDN. Não sobrescreva os valores brutos durante o primeiro teste.

Uma análise prática do tratamento do IP “real” do cliente alerta que a precisão depende de como o proxy define ou acrescenta cabeçalhos e se valores anteriores podem ser falsificados. O modelo completo de confiança do proxy deve corresponder à arquitetura real da rede.

O par do socket no backend deve ser igual ao proxy confiável imediato, enquanto o endereço do cliente selecionado deve ser igual ao dispositivo de teste externo. Se o backend registar apenas o endereço do proxy, a criação ou análise do cabeçalho está em falta.

Verifique Como Cada Proxy Adiciona ou Substitui o Cabeçalho

Inspecione cada salto desde o CDN ou túnel até ao proxy de borda, proxy interno e aplicação. Registe se cada salto acrescenta a uma lista existente, substitui a entrada não confiável ou passa o cabeçalho sem alterações.

A Sling Academy explica que o NGINX pode definir X-Real-IP a partir da ligação imediata e acrescentar uma cadeia com proxy_add_x_forwarded_for.

Configure a primeira borda confiável para remover ou substituir cabeçalhos de encaminhamento fornecidos pelo cliente e depois acrescente endereços em saltos internos controlados. Evite aceitar cegamente o valor mais à esquerda ou mais à direita sem definir quantos proxies são confiáveis.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

Configure o Backend para Confiar Apenas em Endereços de Proxy Conhecidos

Defina a lista de proxies confiáveis da aplicação ou servidor web para os endereços exatos do proxy reverso ou sub-redes controladas. Confirme que ligações diretas de clientes comuns da LAN ou da internet não são tratadas como fontes confiáveis de cabeçalhos.

A explicação da Ip2Geo nota que a ligação da aplicação origina-se do balanceador de carga ou proxy reverso e que analisar o IP original com segurança requer uma regra de salto confiável em vez de aceitar entradas arbitrárias.

Se o endereço do proxy mudar devido a contentores, redes sobrepostas ou um CDN, documente o intervalo suportado e atualize-o deliberadamente. Não confie em todos os endereços privados apenas porque o proxy usa atualmente um.

Execute um Teste de Cabeçalho Falsificado

Do dispositivo de teste externo, envie um valor falsificado de X-Forwarded-For ou Forwarded enquanto se conecta através do proxy real. Compare o cabeçalho bruto recebido, o cabeçalho normalizado do proxy e o endereço do cliente selecionado pelo backend.

O resultado correto é que a borda confiável substitui ou acrescenta com segurança a entrada não confiável e o backend seleciona o endereço com base na contagem de saltos confiáveis documentada. Um endereço falsificado não deve tornar-se o valor usado para autenticação ou lista de permissões.

Repita um teste direto ao backend a partir de um segmento LAN se essa porta for acessível. O backend deve ignorar cabeçalhos encaminhados de um cliente direto não confiável e registar o par real do socket.

Valide IPv4, IPv6 e Caminhos Multi-Proxy

Repita o teste através de IPv4 e IPv6, pelo nome de host público normal e por qualquer CDN, túnel ou proxy secundário usado em produção. Confirme que os registos preservam formatos de endereço válidos e não truncam a cadeia.

O guia ZimaSpace para identidade do pedido de proxy reverso fornece o contexto envolvente para explicar por que os valores encaminhados corretos são importantes além do registo.

O proxy é verificado apenas quando a fonte conhecida corresponde ao IP do cliente analisado, os proxies confiáveis permanecem visíveis na cadeia bruta, as tentativas de falsificação falham e os controlos de segurança usam o valor normalizado de forma consistente. Refaça a verificação após adicionar um CDN, túnel ou outro salto de proxy.