Profundización en qué es un Forward Proxy

Comúnmente utilizamos NGINX o Apache como balanceadores de carga y servidores proxy inversos, incluso cuando el tráfico de la red externa se redirige a través de este software para llegar a los servicios reales dentro de la red interna. Aunque existe un proxy inverso, también existe un proxy directo. Profundicemos en sus funcionalidades.

Del Modelo OSI a los Servidores Proxy

Al acceder a servicios de internet, normalmente empleamos el protocolo HTTP, que opera en la capa 7 del modelo OSI. Componentes familiares de este protocolo, como nombres de host, rutas y parámetros de consulta, forman parte de esta capa. El protocolo HTTP se basa en los protocolos TCP o UDP, que funcionan en la capa 4 del modelo OSI, y los conceptos de puertos utilizados durante el acceso a servicios existen dentro de estos protocolos. Además, tanto TCP como UDP se basan en el Protocolo de Internet (IP), que opera en la capa 3 del modelo OSI, donde las direcciones IP sirven como los "números de casa" de internet.

Cuando se utiliza una red IP para acceder a internet, el protocolo IP es responsable de direccionar el objetivo, encapsular paquetes de datos según reglas y reenviarlos desde la dirección de origen a la dirección de destino dentro de la red IP. Por ejemplo, el tráfico de red viaja desde la red local de un visitante a través del dispositivo de puerta de enlace proporcionado por el ISP, conectándose a la red del ISP antes de acceder a los servicios de un proveedor de recursos.

En este punto, utilizamos una puerta de enlace para acceder a internet. Al hablar de servidores proxy, podemos hacer una analogía con la red IP. Los servidores proxy actúan como puertas de enlace, cerrando la brecha para ayudar a los clientes a acceder a servicios. Básicamente, operan entre las capas 4 y 7 del modelo OSI, y de hecho, caen bajo la capa 5 del modelo OSI.

Propósitos de los Servidores Proxy

Los servidores proxy se emplean típicamente para los siguientes propósitos:

1. Salida Centralizada para el Acceso a la Red Interna

Las empresas suelen tener ciertos requisitos de seguridad de la información, como el control de acceso y el registro de tráfico. Con la prevalencia del tráfico cifrado como HTTPS, ocultar el tráfico de red bajo contraseñas dificulta su registro y auditoría en el límite de la red, aumentando el riesgo de fugas. La existencia de un servidor proxy sirve como una salida unificada de tráfico, actuando como intermediario para manejar tareas de auditoría de tráfico.

Además de los propósitos orientados a humanos, los servicios proxy también pueden servir como una salida para servicios programáticos que acceden a la red externa. Por ejemplo, cuando un proveedor de servicios ofrece funcionalidad de webhook, necesita canalizar el tráfico a través de una salida fija, utilizando una única dirección IP fija o un rango de direcciones IP fijas. Esto facilita que el receptor de las llamadas webhook las incluya correctamente en la lista blanca del firewall. No hacerlo expone a ambas partes de las llamadas webhook a posibles riesgos de seguridad.

2. Ocultar la Identidad del Visitante

A veces, los usuarios de internet pueden desear ocultar su identidad, como su dirección IP. En tales casos, entran en juego los servidores proxy transparentes. El cliente se conecta inicialmente al servidor proxy, especificando la dirección real del servicio al que desea conectarse, y luego accede al servicio objetivo a través del servidor proxy utilizando el protocolo HTTPS. La presencia del servidor proxy asegura que la identidad del cliente permanezca oculta, mientras que el uso de un protocolo cifrado garantiza que el servidor proxy no pueda robar datos durante este proceso.

Proxy Basado en HTTP

En los servidores proxy, normalmente encontramos proxies HTTP basados en HTTP y el protocolo binario SOCKS 4/5. Realizan funciones similares pero con diferentes métodos de implementación. Centrémonos en los proxies basados en HTTP.

En las primeras etapas de la implementación del protocolo, el tráfico en HTTP era principalmente texto plano. Esta transparencia permitía que los servidores proxy en medio del cliente y el servicio pudieran analizar fácilmente las URL y las cargas útiles de las solicitudes. A través de la resolución DNS y procesos similares, el proxy podía conectarse al servicio utilizando su propia dirección de red, ocultando así al cliente.

Un ejemplo de tal llamada es el siguiente:

GET http://example.com/resource HTTP/1.1
Proxy-Authorization: Basic encoded-credentials

El servidor proxy entiende la dirección a la que el cliente intenta acceder y envía una solicitud al servicio para obtener una respuesta, que luego se devuelve al cliente.

HTTP/1.1 200 OK
Content-Type: text/html
...
body blahblah
...

Esto representa la forma más simple de implementación de un servidor proxy HTTP. Sin embargo, observamos desventajas: el servidor proxy maneja el tráfico del cliente en texto plano, lo que representa un riesgo potencial de seguridad, ya que podría registrar el tráfico del usuario durante el reenvío. Por lo tanto, es necesario considerar métodos de cifrado para garantizar la seguridad.

Funcionamiento Complejo del Tráfico HTTPS y los Servidores Proxy

Con el aumento de la proporción de tráfico HTTPS cifrado dentro de todo el tráfico HTTP, los servidores proxy deben adaptarse a este escenario.

Sin embargo, surge un desafío: el tráfico enviado por el cliente al proveedor de servicios ahora está cifrado. El servidor proxy no puede entender qué recurso está accediendo el cliente a través del descifrado. Esto se debe a que el tráfico está protegido por un mecanismo de negociación de claves basado en algoritmos de cifrado asimétrico entre el cliente y el proveedor de servicios, y el tráfico cifrado posterior utiliza claves simétricas que no pueden ser obtenidas por un intermediario durante la comunicación. El propósito fundamental de TLS es prevenir la posibilidad de ataques de intermediario.

Entonces, ¿cómo funciona el servidor proxy en este caso?

Esto es más complejo en comparación con el método anterior de análisis de solicitudes en texto plano. El protocolo HTTP introdujo un método de solicitud dedicado CONNECT. El cliente utiliza este método para enviar una solicitud inicial al servidor proxy:

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: Basic encoded-credentials

El cliente envía una solicitud CONNECT al servidor proxy, incluyendo el dominio o la dirección IP y el puerto al que el cliente desea conectarse. Al recibir la solicitud, el servidor proxy establece una conexión TCP con el servicio objetivo y almacena el mapeo de puertos entre el cliente y el servicio. Posteriormente, el cliente puede enviar la solicitud correcta al servidor proxy, que reenviará el tráfico al servicio tal cual, sin intentar analizar los datos. Por lo tanto, la comunicación cifrada de HTTPS es confiable.

Este mecanismo, en comparación con los proxies HTTP de texto plano, es más versátil. Una vez que la primera solicitud HTTP informa al servidor proxy de la información para establecer una conexión, esencialmente se convierte en un canal proxy transparente. Puede facilitar la comunicación tanto para HTTPS como para tráfico binario TCP (como SSH) a través del servidor proxy.