La DMZ llega sin una definición adjunta. Una línea en una lista de comprobación de seguridad, una frase en el documento de endurecimiento de un proveedor, un requisito en una oferta de empleo junto a TLS y el mínimo privilegio.
Lo buscas y encuentras el diagrama de un cortafuegos con tres cables de red. Uno va a internet, otro a una fila de servidores, otro a una LAN de oficina. Lo que tú administras es un único servidor alquilado con una sola IP pública y ninguna interfaz de red de repuesto.
La primera imagen es una arquitectura DMZ de verdad. En un solo servidor puedes reproducir parte de su objetivo de seguridad: limitar lo que internet puede alcanzar. Lo que no puedes reproducir en ese mismo host es la frontera de red separada que hace que una DMZ sea una DMZ.
La versión corta
- Una DMZ separa los servicios que los desconocidos deben alcanzar del resto de lo que ejecutas.
- La cuestión nunca fue el cableado: era que un compromiso del lado público se detuviera ahí.
- Puedes configurar un cortafuegos y aun así no tener una DMZ.
- Un solo servidor con una única IP pública puede reducir la exposición con un proxy inverso, reglas de cortafuegos locales y escuchas privadas o en loopback, pero no crea un segmento DMZ separado.
- Esa versión comparte núcleo con aquello que protege, así que cuéntala como exposición reducida y no como aislamiento.
Lo que este artículo no cubre
El alcance aquí es el modelo mental, y tres temas adyacentes quedan deliberadamente fuera.
- Sin pasos de instalación. No hay configuración de proxy inverso, ni sintaxis de reglas de cortafuegos, ni recomendación sobre qué herramienta instalar.
- Sin configuración de routers domésticos. La opción "DMZ host" de un router de casa designa algo completamente distinto.
- Sin veredicto sobre zero trust. Si el perímetro de red sigue siendo el control principal adecuado es un debate real, y aquí no se zanja.
¿Qué es una DMZ y para qué sirve?
Una DMZ, o zona desmilitarizada, es un segmento de red situado entre la internet no confiable y una red interna. Alberga los servicios que deben ser accesibles públicamente, como los servidores web y de correo. Todo lo demás queda detrás de una segunda frontera, de modo que llegar al servicio público no equivale a llegar al resto.
La entrada del glosario de Mozilla sobre la DMZ resume la mitad operativa de eso en una sola cláusula: expone únicamente ciertos puntos finales definidos, mientras deniega el acceso a la red interna desde fuera. Ese es todo el objetivo de diseño, enunciado sin referencia a ningún equipo.
Los tipos de servicio que clásicamente viven ahí se deducen del objetivo. Servidores web, servidores de correo, servidores FTP, servidores VoIP: cosas a las que se supone que los desconocidos pueden conectarse. Los servidores de directorio, las bases de datos, los recursos compartidos, las aplicaciones internas y las interfaces administrativas no están en esa lista, porque nadie de fuera debería alcanzarlas.
Quédate con la propiedad, no con la imagen. Tres interfaces de red son una forma de crear una frontera de confianza separada. Los diseños en la nube y de un solo servidor pueden aplicar el mismo principio de control de exposición de otras maneras, pero solo los diseños con una zona perimetral distinta reproducen la DMZ en sí.
¿Cómo funciona la DMZ clásica de tres interfaces?
La DMZ clásica se construye de dos maneras. Un diseño de cortafuegos único da a un solo cortafuegos tres interfaces, una a internet, otra a la DMZ y otra a la red interna. Un diseño de doble cortafuegos sitúa la DMZ entre dos cortafuegos separados. Ambos aplican la misma regla. Internet llega a la DMZ. Internet nunca llega a la red interna.
El modelo de cortafuegos único (tres patas)
Un cortafuegos, tres interfaces de red. La primera mira a internet. La segunda mira a la DMZ, donde viven los servicios públicos. La tercera mira a la red interna. El cortafuegos permite el tráfico entrante desde internet hacia puertos concretos de la DMZ, permite un tráfico estrecho de la DMZ hacia lo interno cuando una aplicación lo exige, y deniega todo lo demás.
El nombre de esta forma es cortafuegos de tres patas. Cada paquete que cruza entre zonas pasa por un único aparato, lo que convierte a ese cortafuegos en un punto único de fallo para el tráfico entre zonas. Si cae, la conectividad y la aplicación de políticas se ven afectadas según el modo de fallo del cortafuegos y la redundancia que tengas dispuesta.
Pasé una década llevando las operaciones de red en un ISP, y lo que sorprendía a la gente de una interfaz DMZ era lo poco extraordinaria que resultaba. Un puerto ethernet corriente con una etiqueta de confianza distinta asignada en la configuración del cortafuegos. La arquitectura no estaba en el cobre. Estaba en el conjunto de reglas, y en que alguien había pensado con cuidado en qué dirección se permitía cada flujo.
El modelo de doble cortafuegos (espalda con espalda)
Dos cortafuegos en serie, con la DMZ entre ambos. El cortafuegos externo permite el tráfico de internet hacia la DMZ y nada más allá. El interno solo permite el tráfico concreto que una aplicación necesita, de la DMZ hacia lo interno. Un atacante que llega a la DMZ todavía tiene que cruzar la frontera de políticas del cortafuegos interno antes de alcanzar la red interna.
Dos cortafuegos te dan dos fronteras de políticas aplicadas por separado, pero también añaden configuración, parcheo y complejidad operativa. Un fallo o compromiso de la frontera externa no elimina automáticamente la interna, aunque la protección sigue dependiendo de cómo estén configurados y gestionados ambos cortafuegos.
¿Es una DMZ lo mismo que un cortafuegos?
No. Una DMZ es una red perimetral o un segmento de red separado. Un cortafuegos es un control habitual que se usa para regular el tráfico entre esa zona, internet y la red interna. Puedes configurar reglas de cortafuegos en una red plana sin crear una DMZ, así que la distinción es arquitectónica y no solo cuestión de configuración.
La confusión se entiende. El cortafuegos es el objeto al que te conectas, la cosa que tiene un archivo de configuración, un fabricante y un contrato de soporte, así que acaba quedándose con el nombre de aquello que produce. Nadie se conecta jamás a un segmento.
La consecuencia aparece en el peor momento posible. Da por hecho que tu servidor web público está comprometido, porque tarde o temprano lo estará. En una red plana el atacante ya tiene un punto de apoyo en una máquina que puede hablar con tu base de datos, tu servidor de ficheros y tus interfaces administrativas, y moverse entre ellos es simplemente usar un acceso que ya estaba permitido. Ese desplazamiento de lado se llama movimiento lateral, y es justo lo que la segunda frontera existe para detener. La DMZ no evita que el servidor web sea comprometido. Evita que un servidor web comprometido se convierta en acceso a todo lo demás.
Una aclaración mientras tienes el término delante: el ajuste "DMZ host" de un router doméstico o de pequeña oficina es otra función. Reenvía el tráfico entrante no solicitado a un único dispositivo interno, exponiéndolo directamente a internet; no crea una red DMZ separada y protegida.
¿Cómo aplicar los principios de la DMZ en un solo servidor?
Un solo servidor con una única IP pública puede reproducir parte del objetivo de control de exposición de una DMZ, sin reproducir su separación de red. Un proxy inverso puede convertirse en el único punto de entrada público, unas reglas de cortafuegos de entrada con denegación por defecto pueden bloquear el resto, y los servicios internos pueden escuchar en loopback o en una interfaz privada en lugar de en la dirección pública.
Empieza por la restricción que esta sección da por supuesta: un VPS, una interfaz pública y ningún dispositivo de cortafuegos aparte ni subred DMZ bajo tu control. En ese montaje no puedes reproducir la topología clásica de tres patas en el mismo host. Las reglas de cortafuegos locales, la elección de escucha de los servicios y un proxy inverso siguen pudiendo reducir la exposición, pero no crean la misma frontera de aislamiento.
Un proxy inverso puede ocupar la interfaz pública en los puertos 80 y 443 y convertirse en el único punto de entrada a nivel de aplicación para el tráfico web. Eso estrecha la superficie de ataque pública, pero no equivale a una interfaz DMZ separada, porque el proxy sigue compartiendo el host con los servicios que están detrás.
Las reglas de cortafuegos de entrada del host permiten esos dos puertos y descartan el resto. Cualquier otro servicio de la máquina puede estar corriendo y escuchando, pero nada de fuera puede iniciar una conexión hacia él. Esto aproxima la política de "solo los puertos previstos son alcanzables" en un único host; no crea una frontera separada con la red interna.
Los servidores de aplicaciones, las bases de datos y los paneles de administración no deberían escuchar en la dirección pública. Cuando el proxy corre en el mismo host, pueden escuchar en loopback; cuando corre en otro sitio de la red privada, pueden escuchar en una dirección privada. En cualquiera de los dos casos no hay ningún proceso escuchando por esos servicios en la interfaz pública, así que abrir una regla de entrada solo en esa interfaz no los expone.
El acceso administrativo pertenece al lado interno, no al lado DMZ. Mantener SSH y las interfaces de gestión fuera de la ruta pública, detrás de una VPN o de una red privada, impide las conexiones directas hacia ellos desde la internet pública.
¿Cómo se trasladan los conceptos de DMZ a las subredes de VPC y los grupos de seguridad?
El modelo clásico tiene una correspondencia conceptual bastante estrecha con las primitivas de red en la nube, pero no es uno a uno. Un segmento DMZ pasa a ser una subred pública. La red interna pasa a ser una subred privada sin ruta a una pasarela de internet. El conjunto de reglas del cortafuegos se reparte entre los grupos de seguridad, asociados a las interfaces de red de los recursos, y las listas de control de acceso de red, adjuntas a las subredes.
| Elemento clásico | Equivalente en la nube | Qué impone |
|---|---|---|
| Segmento DMZ | Subred pública | Aporta una ruta a internet; un recurso necesita además una dirección pública y reglas de seguridad que permitan el tráfico |
| Segmento de red interna | Subred privada | Sin ruta directa a la pasarela de internet, de modo que internet no puede iniciar conexiones directas por esa vía |
| Interfaz de cortafuegos entre zonas | Tabla de rutas + adjunción de una pasarela de internet | Adónde puede enrutarse el tráfico; el direccionamiento público y los controles de seguridad siguen determinando si un recurso es alcanzable |
| Conjunto de reglas de cortafuegos (por zona) | Listas de control de acceso de red | Reglas de permiso y denegación sin estado, evaluadas en el borde de la subred |
| Conjunto de reglas de cortafuegos (por host) | Grupos de seguridad | Reglas de permiso con estado, aplicadas a las interfaces de red de los recursos asociados |
| Servicio expuesto al público en la DMZ | Balanceador de carga o instancia proxy en la subred pública | El único punto de entrada por el que debe pasar el tráfico |
Los proveedores de nube usan ellos mismos ese vocabulario, lo que es buena prueba de que el término sigue vigente. El blog de redes de AWS describe una arquitectura DMZ en Amazon VPC que aísla los servicios expuestos al público de las redes internas, construida sobre VPC Block Public Access, un control a nivel de Región lanzado en noviembre de 2024.
Las subredes son la parte que sostiene toda esta correspondencia. Una subred pública es pública porque su tabla de rutas apunta a una pasarela de internet. Dado que las tablas de rutas deciden por dónde viajan los paquetes, la disposición de las subredes da forma a tu exposición antes que cualquier regla individual.
La correspondencia es imperfecta en un punto concreto. Una interfaz de cortafuegos imponía una frontera para todo un segmento; un grupo de seguridad, en cambio, se asocia a la interfaz de red de un recurso. Dos máquinas de la misma subred privada pueden llevar grupos de seguridad completamente distintos, así que la aplicación de las reglas cae en una granularidad más fina de la que jamás logró una interfaz física. Suele ser una mejora. También significa que el nombre de una subred te dice menos sobre qué es alcanzable de lo que solía decirte un diagrama de red.
Dónde se queda corta la versión de un solo servidor
En un solo host, el proceso expuesto al público y los servicios internos comparten núcleo y máquina. Los segmentos separados obligan al atacante a cruzar una frontera de red que un cortafuegos inspecciona; un solo host, no. El patrón de un servidor reduce la exposición. No reproduce la separación.
Si el proxy inverso se compromete de una forma que da al atacante ejecución de código, ese código ya se está ejecutando en la máquina donde corre tu base de datos. Escuchar en loopback no ayuda entonces, porque loopback es alcanzable desde el propio host. El aislamiento por contenedores o por usuarios puede elevar el esfuerzo necesario, pero los contenedores del mismo host siguen compartiendo su núcleo. En el modelo clásico, el siguiente paso del atacante era un paquete por un cable que algo inspeccionaba. Aquí es un socket local.
La consecuencia práctica es un umbral, no un veredicto. Cuando lo que hay detrás del proxy vale más que el esfuerzo de una segunda máquina, usa una segunda máquina y una red privada entre ambas. Nada de este artículo hay que reaprenderlo para eso, porque nada de esto trató nunca del hardware.
Construye sobre un VPS Linux con acceso root, NVMe y la potencia de AMD EPYC.
Ver planes LinuxEl perímetro ya no es el único lugar donde se puede aplicar una política de seguridad. La arquitectura zero trust elimina la confianza implícita basada en la ubicación de red, mientras que una conectividad privada construida con WireGuard o Tailscale puede reducir la exposición pública. Ninguno de los dos enfoques sustituye automáticamente a la segmentación ni a la autorización. Mi posición sobre la cuestión más estrecha es rotunda. Como modelo mental, separa lo que es alcanzable de lo que no lo es, y ten claro qué frontera contiene un compromiso. Esa pregunta sobrevive a todas las arquitecturas nombradas arriba, y por eso sigue mereciendo respuesta.
Preguntas frecuentes
¿Es una DMZ lo mismo que una VPN?
No. Resuelven problemas distintos. Una DMZ controla lo que pueden alcanzar los desconocidos no confiables, exponiendo un pequeño conjunto de servicios y nada más. Una VPN da a personas de confianza que están fuera un camino privado hacia dentro, autenticándolas en una red a la que de otro modo no llegarían. Muchas redes usan ambas cosas, y ninguna sustituye a la otra.
¿Es segura una DMZ?
Una DMZ no vuelve seguro a un servicio expuesto. Limita hasta dónde llega el compromiso de ese servicio. El servicio de cara al público sigue de cara al público, sigue expuesto a todo internet y sigue necesitando parcheo, supervisión y endurecimiento por sí mismo. La DMZ decide qué pasa después de que caiga, no si caerá.
¿Necesito una DMZ si solo tengo un servidor?
No en el sentido clásico, y de todos modos no podrías construir una en un solo host. La topología de tres interfaces necesita segmentos de red separados, y un servidor con una sola IP pública no tiene ninguno. Lo que sí puedes hacer es controlar la exposición: que un proxy inverso sea el único punto de entrada público, denegar por defecto el resto de los puertos entrantes y hacer que los servicios internos escuchen en loopback o en una dirección privada. Eso reduce lo que internet puede alcanzar, sin aislar el servicio público del resto del host. Cuando lo que hay detrás del proxy vale más que el coste de una segunda máquina, usa dos máquinas y una red privada entre ellas.
¿Por qué se le llama zona desmilitarizada?
El término está tomado del sentido militar de una zona de amortiguación entre dos fuerzas enfrentadas, donde ninguna manda del todo. El uso en redes conserva la metáfora: la DMZ no pertenece por entero ni al exterior no confiable ni al interior de confianza.
Debate
Comentarios
Inicia sesión para unirte al debate.