Tema 8
Publicar un servicio no significa abrir toda la red. NAT, PAT y port forwarding permiten traducir direcciones y puertos, pero deben combinarse con reglas estrictas, segmentación, monitoreo y hardening.
Muchas organizaciones necesitan que ciertos servicios sean accesibles desde internet, desde una sede remota, desde proveedores o desde usuarios externos. Ejemplos comunes son aplicaciones web, VPN, correo, DNS público, APIs o portales de clientes.
Para lograrlo se usan mecanismos como NAT, PAT y port forwarding. Estos mecanismos modifican direcciones o puertos para que una comunicación pueda llegar al destino correcto. Sin embargo, traducir una dirección no equivale a proteger el servicio.
En este tema veremos cómo funcionan estas técnicas y cómo usarlas de forma defensiva, evitando exposiciones innecesarias.
NAT significa Network Address Translation, o traducción de direcciones de red. Es una técnica que modifica direcciones IP en los paquetes cuando atraviesan un dispositivo, normalmente un firewall o router.
El uso más conocido de NAT es permitir que muchos equipos con direcciones privadas salgan a internet usando una o más direcciones públicas. También puede usarse para publicar servicios internos mediante una dirección pública.
NAT ayuda a resolver problemas de direccionamiento, pero no debe confundirse con una política de seguridad completa.
Las direcciones privadas se usan dentro de redes internas y no son enrutables directamente en internet. Las direcciones públicas son visibles y alcanzables desde internet si existen rutas y reglas que lo permitan.
| Tipo | Ejemplos | Uso común |
|---|---|---|
| Privada | 10.0.0.0/8 | Redes internas corporativas. |
| Privada | 172.16.0.0/12 | Servidores, usuarios, redes internas o laboratorio. |
| Privada | 192.168.0.0/16 | Redes pequeñas, hogares, oficinas y segmentos internos. |
| Pública | Asignada por ISP o proveedor cloud | Servicios accesibles desde internet o salida hacia internet. |
El NAT de origen modifica la dirección IP de origen. Se usa normalmente cuando equipos internos salen hacia internet y el firewall reemplaza sus direcciones privadas por una dirección pública.
Ejemplo:
Desde el punto de vista defensivo, conviene registrar estas traducciones para poder investigar qué equipo interno generó una conexión externa.
El NAT de destino modifica la dirección IP de destino. Se usa cuando una dirección pública representa un servicio ubicado en una red interna o DMZ.
Ejemplo:
Esta técnica permite publicar servicios, pero debe combinarse con reglas de acceso específicas. No se debe publicar más de lo necesario.
PAT significa Port Address Translation, o traducción de direcciones y puertos. También se lo conoce como NAT overload.
PAT permite que muchos equipos internos compartan una misma dirección pública diferenciando las conexiones por puertos. Es muy común para navegación de usuarios hacia internet.
Ejemplo simplificado:
| Equipo interno | Traducción pública | Destino |
|---|---|---|
| 10.10.20.15:51000 | 203.0.113.10:40001 | 198.51.100.50:443 |
| 10.10.20.16:51000 | 203.0.113.10:40002 | 198.51.100.50:443 |
El port forwarding, o reenvío de puertos, permite que una conexión recibida en una IP y puerto sea enviada a otra IP y puerto interno.
Ejemplo: publicar el puerto TCP 443 de una IP pública y reenviarlo al puerto TCP 443 de un servidor web en DMZ.
El port forwarding puede ser útil, pero también es una fuente frecuente de exposición peligrosa cuando se usa para publicar administración remota, bases de datos o servicios que deberían permanecer internos.
Publicar un servicio de forma segura implica mucho más que crear una traducción NAT. Debe existir una decisión defensiva completa.
Antes de publicar, conviene responder:
La exposición controlada consiste en publicar solo lo necesario, con límites claros y controles adicionales. No se trata de ocultar todo, sino de reducir el área visible y monitorear lo que queda expuesto.
| Decisión | Exposición débil | Exposición controlada |
|---|---|---|
| Aplicación web | Servidor interno publicado directamente. | Servicio en DMZ o detrás de reverse proxy y WAF. |
| Administración remota | RDP o SSH abierto a internet. | VPN, bastión, MFA y restricción por origen. |
| Base de datos | Puerto de base de datos publicado. | Acceso solo desde aplicación autorizada en red privada. |
| DNS | Resolver interno abierto a internet. | DNS público separado y resolutores internos restringidos. |
La DMZ es una zona adecuada para ubicar servicios que deben recibir conexiones desde redes externas. Su función principal es evitar que un servicio expuesto quede directamente dentro de la red interna más sensible.
Una publicación defensiva típica podría tener este flujo:
Un reverse proxy recibe solicitudes externas y las reenvía a servidores internos o de backend. Puede ayudar a centralizar certificados TLS, aplicar controles, ocultar servidores reales y distribuir carga.
Un balanceador de carga puede repartir tráfico entre varios servidores. En algunos casos también integra funciones de seguridad, terminación TLS, monitoreo de salud y reglas de aplicación.
Estos componentes no reemplazan el hardening ni las reglas de firewall, pero ayudan a publicar servicios con mayor control.
Hairpin NAT, también llamado NAT loopback, ocurre cuando un cliente interno accede a un servicio interno usando la dirección pública del servicio. El tráfico sale hacia el firewall y vuelve hacia adentro mediante la traducción.
Puede ser útil en ciertos diseños, pero también puede complicar logs, resolución de nombres y diagnóstico. Muchas veces conviene usar DNS interno para que los clientes internos resuelvan la dirección privada del servicio.
La decisión depende del entorno, pero debe documentarse para evitar confusiones durante incidentes.
Un error común es creer que, por usar NAT, un servicio queda protegido automáticamente. NAT puede ocultar direcciones internas, pero si existe una traducción y una regla permisiva, el servicio queda alcanzable.
Una publicación segura necesita al menos:
Cada servicio publicado aumenta la superficie de ataque. Esto no significa que nunca debamos publicar servicios, sino que cada publicación debe estar justificada y protegida.
Riesgos frecuentes:
Cuando hay NAT o PAT, los logs son fundamentales para entender qué ocurrió. En una investigación puede ser necesario saber qué equipo interno usó una dirección pública y un puerto en un momento específico.
Conviene registrar:
Supongamos que una empresa necesita publicar una aplicación web para clientes. Una configuración defensiva podría ser:
| Elemento | Decisión |
|---|---|
| IP pública | 203.0.113.20 |
| NAT de destino | 203.0.113.20:443 hacia reverse proxy en DMZ 172.16.50.10:443 |
| Regla de firewall | Permitir internet hacia DMZ solo por HTTPS. |
| Backend | Reverse proxy hacia servidores internos por puertos específicos. |
| Controles | WAF, IDS/IPS, hardening, parches y monitoreo de logs. |
| Bloqueo | Todo otro tráfico desde internet queda bloqueado. |
Un diseño riesgoso sería publicar varios puertos de un servidor interno directamente a internet: HTTPS, SSH, RDP, base de datos y panel de administración. Aunque funcione, expone demasiada superficie.
Problemas de ese enfoque:
NAT, PAT y port forwarding son herramientas necesarias para conectar redes y publicar servicios, pero deben usarse con criterio defensivo. La pregunta importante no es solo cómo hacer que una conexión funcione, sino cómo permitirla con el menor riesgo posible.
En el próximo tema estudiaremos segmentación defensiva: VLAN, zonas de seguridad, microsegmentación y Zero Trust. Allí veremos cómo dividir la infraestructura para limitar movimiento lateral y reducir el impacto de incidentes.