Cómo verificar que un proxy inverso está enviando la IP correcta del cliente

Verifique el reenvío de IP del cliente comparando una fuente externa conocida con cada encabezado de proxy y la dirección final analizada del backend.

Un proxy inverso termina la conexión del cliente, por lo que el backend normalmente ve la dirección del socket del proxy a menos que el proxy pase metadatos de solicitud confiables. La prueba debe distinguir la dirección del par directo de Forwarded, X-Forwarded-For y X-Real-IP, documentar cada salto confiable y demostrar que un cliente de internet no puede falsificar el valor usado para registros, límites de tasa o control de acceso.

Crear una Prueba de IP de Cliente Conocida Desde Fuera del Hogar

Use un dispositivo con datos móviles u otra red externa y registre su dirección pública IPv4 o IPv6 inmediatamente antes de la solicitud. Envíe una ruta única, un valor de consulta o una marca de tiempo a través del proxy inverso público.

MDN describe X-Forwarded-For como un encabezado de facto para preservar la dirección del cliente originario a través de conexiones proxy.

Recoja el registro del proxy de borde, cualquier registro de proxy intermedio y el registro de la aplicación backend para esa solicitud. Sin una fuente conocida y una marca de tiempo correlacionada, múltiples usuarios concurrentes pueden hacer que la cadena de encabezados sea ambigua.

Registrar el Par de Socket y Cada Encabezado Reenviado

En el backend, registre la dirección TCP directa del par por separado de Forwarded, X-Forwarded-For, X-Real-IP y cualquier encabezado de cliente específico de CDN. No sobrescriba los valores en bruto durante la primera prueba.

Un análisis práctico del manejo de la IP “real” del cliente advierte que la precisión depende de cómo el proxy establece o agrega encabezados y si los valores anteriores pueden ser falsificados. El modelo completo de confianza del proxy debe coincidir con la arquitectura real de la red.

El par de socket del backend debe ser igual al proxy confiable inmediato, mientras que la dirección de cliente seleccionada debe ser igual al dispositivo de prueba externo. Si el backend solo registra la dirección del proxy, falta la creación o el análisis del encabezado.

Verificar Cómo Cada Proxy Añade o Reemplaza el Encabezado

Inspeccione cada salto desde CDN o túnel hasta proxy de borde, proxy interno y aplicación. Registre si cada salto agrega a una lista existente, reemplaza la entrada no confiable o pasa el encabezado sin cambios.

Sling Academy explica que NGINX puede establecer X-Real-IP desde la conexión inmediata y agregar una cadena con proxy_add_x_forwarded_for.

Configure el primer borde confiable para eliminar o reemplazar encabezados de reenvío suministrados por el cliente, luego agregue direcciones en saltos internos controlados. Evite aceptar ciegamente el valor más a la izquierda o a la derecha sin definir cuántos proxies son confiables.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Configurar el Backend para Confiar Solo en Direcciones de Proxy Conocidas

Establezca la lista de proxies confiables de la aplicación o servidor web a las direcciones exactas del proxy inverso o subredes controladas. Confirme que las conexiones directas desde clientes LAN u ordinarios de internet no se traten como fuentes confiables de encabezados.

La explicación de Ip2Geo señala que la conexión de la aplicación se origina desde el balanceador de carga o proxy inverso y que analizar la IP original de forma segura requiere una regla de salto confiable en lugar de aceptar entradas arbitrarias.

Si la dirección del proxy cambia debido a contenedores, redes superpuestas o un CDN, documente el rango soportado y actualícelo deliberadamente. No confíe en todas las direcciones privadas solo porque el proxy actualmente use una.

Ejecutar una Prueba de Encabezado Falsificado

Desde el dispositivo de prueba externo, envíe un valor falsificado de X-Forwarded-For o Forwarded mientras se conecta a través del proxy real. Compare el encabezado entrante en bruto, el encabezado proxy normalizado y la dirección de cliente seleccionada por el backend.

El resultado correcto es que el borde confiable reemplace o agregue de forma segura a la entrada no confiable y que el backend seleccione la dirección basada en el conteo de saltos confiables documentado. Una dirección falsificada no debe convertirse en el valor usado para autenticación o listas blancas.

Repita una prueba directa al backend desde un segmento LAN si ese puerto es accesible. El backend debe ignorar encabezados reenviados de un cliente directo no confiable y registrar el par de socket real.

Validar IPv4, IPv6 y Rutas Multi-Proxy

Repita la prueba a través de IPv4 e IPv6, mediante el nombre de host público normal y a través de cualquier CDN, túnel o proxy secundario usado en producción. Confirme que los registros preserven formatos de dirección válidos y no trunquen la cadena.

La guía de ZimaSpace sobre identidad de solicitud de proxy inverso proporciona el contexto para entender por qué los valores reenviados correctos importan más allá del registro.

El proxy se verifica solo cuando la fuente conocida coincide con la IP de cliente analizada, los proxies confiables permanecen visibles en la cadena en bruto, los intentos de falsificación fallan y los controles de seguridad usan el valor normalizado de forma consistente. Revise nuevamente después de agregar un CDN, túnel u otro salto de proxy.