HTTP, proxies y NAT

Casi todo el tráfico que te importa proteger es HTTP sobre TLS, y casi nunca va directo de punto a punto: entra por un proxy inverso y sale por un NAT. Entender esos dos intermediarios —qué reescriben y qué ocultan— es lo que explica por qué tu API “ve” la IP del balanceador en vez de la del usuario, y por qué una instancia en una subred privada puede llegar a Internet pero Internet no puede llegar a ella.

HTTP/HTTPS en un minuto#

HTTP es un protocolo de petición-respuesta de capa 7. Una petición lleva un método (GET, POST, PUT, DELETE…), una ruta, cabeceras y, a veces, un cuerpo. La respuesta trae un código de estado (2xx éxito, 3xx redirección, 4xx error del cliente, 5xx error del servidor) y sus propias cabeceras.

Dos propiedades tienen peso en seguridad:

HTTP no tiene estado. Cada petición es independiente; el servidor no recuerda la anterior. El “estado” de sesión se reconstruye con cookies o tokens (en Citas, un JWT de Cognito en la cabecera Authorization). Por eso proteger esas credenciales es proteger la sesión entera.
HTTPS es HTTP dentro de TLS. TLS cifra y autentica el canal, así que un observador en medio ve el host de destino y el tamaño/timing, pero no el contenido. Esto es bueno (confidencialidad) y a la vez complica la inspección: para filtrar por contenido hay que terminar TLS en algún punto de confianza.

Ese “punto donde se termina TLS” es, casi siempre, un proxy.

Forward proxy vs reverse proxy#

Un proxy es un intermediario, pero hay dos tipos según a quién representa:

	Forward proxy	Reverse proxy
Representa a	el cliente hacia Internet	el servidor hacia los clientes
Se pone delante de	los usuarios salientes	los backends entrantes
Para qué	control de egreso, filtrado de URLs, caché saliente	terminación TLS, balanceo, WAF, ocultar el backend
Quién lo ve	lo configura el cliente	es transparente para el cliente
En AWS	proxy de egreso, Network Firewall	CloudFront, ALB, API Gateway, WAF

La regla mnemotécnica: el forward proxy protege y controla a los que salen; el reverse proxy protege y expone a los que entran.

Proxy inverso y NAT en una VPC

Redes · Proxies y NAT

Paso 1 de 5La VPC

Dos subredes: la pública, con los recursos que miran a Internet, y la privada, donde vive la API. La privada no tiene ruta directa a Internet.

El reverse proxy delante de la API#

En una arquitectura como Citas, el usuario nunca habla con la API directamente. Llega a un reverse proxy —CloudFront con WAF, y detrás un ALB— que termina TLS, aplica reglas del WAF, puede cachear y reparte la carga. Solo entonces reenvía la petición a la API, que vive en subredes privadas y no es accesible desde Internet.

Esto tiene una consecuencia práctica constante: la API ve como IP de origen la del balanceador, no la del usuario. Para recuperar la IP real del cliente —para rate limiting, geobloqueo o logs— se usa la cabecera X-Forwarded-For, que el proxy añade.

NAT: cómo sale una subred privada#

Una subred privada no tiene ruta hacia la internet gateway; sus instancias usan IP privadas (10.0.3.15), que no son enrutables en Internet. Para que puedan iniciar conexiones salientes —actualizar paquetes, llamar a una API externa, a SES— su tráfico se dirige a un NAT gateway situado en una subred pública.

El NAT gateway hace SNAT (source NAT): reescribe la IP de origen privada por la IP pública elástica del gateway. La respuesta vuelve al NAT, que deshace la traducción y la entrega a la instancia correcta. La asimetría es la clave de seguridad: la instancia privada puede iniciar conexiones hacia fuera, pero nadie desde fuera puede iniciar una conexión hacia ella, porque no tiene una IP pública propia a la que dirigirse.

SNAT reescribe el origen: lo que hace el NAT gateway para la salida.
DNAT reescribe el destino: lo que hace un balanceador o un port forwarding para la entrada.

En los VPC Flow Logs, esta traducción es visible: srcaddr muestra la dirección tras el NAT, mientras que pkt-srcaddr conserva la IP privada original de la instancia. Comparar ambos campos te dice qué instancia concreta generó el tráfico que salió por el gateway.

Filtrado de egreso: el tráfico que se olvida#

Casi todos los equipos vigilan lo que entra y descuidan lo que sale. Pero el egreso es justo por donde se va la información en una brecha: exfiltración, command and control de malware, descarga de herramientas. Si tu subred privada “sale a todo por el 443”, un atacante que llegue a tu instancia tiene una autopista hacia su infraestructura.

Controlar el egreso significa permitir solo los destinos necesarios:

Vulnerable

Seguro

# El NAT gateway deja salir a cualquier destino.
# La instancia comprometida llama a su C2 sin fricción.
Ruta privada → NAT gateway → 0.0.0.0/0 : 443
# "sale a todo por HTTPS" = sin control de egreso

# AWS Network Firewall o un proxy de egreso
# permiten solo dominios/IPs concretos.
Ruta privada → Network Firewall → allowlist:
  *.amazonaws.com      (servicios AWS)
  api.stripe.com       (pago)
  DENY  resto          → registrado y alertado

En AWS, el egreso se filtra con AWS Network Firewall (por dominio o por regla L3/L4), con VPC endpoints (para que el tráfico a servicios de AWS ni siquiera pase por Internet) y, para el DNS, con el DNS Firewall que ya vimos. Un endpoint de S3 o de Secrets Manager mantiene ese tráfico dentro de la red de AWS, reduciendo a la vez superficie y coste de NAT.

Tu turno

Mapea la entrada y la salida de un servicio tuyo

Toma un servicio que gestiones y dibuja sus dos caminos, el de entrada y el de salida.

Entrada: ¿hay un reverse proxy (ALB, CloudFront, API Gateway)? ¿Dónde se termina TLS? ¿Usas la IP real del cliente de forma fiable?
Salida: ¿por dónde sale a Internet? ¿Está filtrado el egreso o “sale a todo”? Lista los destinos externos que de verdad necesita.
Si pudieras aplicar una allowlist de egreso mañana, ¿qué tres dominios tendrías que permitir y cuál es el que más te sorprendería ver?

Reto

Tu API en una subred privada necesita leer un secreto de Secrets Manager. ¿Por qué un VPC endpoint es mejor que salir por el NAT gateway?

▸Mostrar solución

Con un interface endpoint (PrivateLink) el tráfico a Secrets Manager nunca sale a Internet: viaja por la red privada de AWS hasta el servicio. Eso reduce la superficie (no dependes de la ruta de egreso ni del NAT), evita exponer ese tráfico a un posible filtrado o interceptación en el camino de salida, y además ahorra el coste de procesamiento del NAT gateway. El acceso se controla con la política del endpoint, no con reglas de salida genéricas.

Reto

¿Por qué un reverse proxy puede aplicar un WAF y un NAT gateway no?