LA DMZ En primer lugar hay que tener claro que la única idea de una DMZ es tener servidores que sean accesibles desde Internet y que físicamente estén instalados en nuestra red. El problema se genera cuando la compañía tiene servidores locales que deben ser accesibles desde Internet y el de redes o encargado de la infraestructura se comienza a preguntar cómo y donde los instalará. Veamos un ejemplo práctico de los casos típicos. Caso 1 – Servidores instalados fuera de la red Este es probablemente uno de los casos más típicos ya que no requiere muchos conocimientos ni tampoco se requiere invertir en dispositivos de seguridad. Muchas compañías optan por instalar sus servidores con una dirección IP pública directa en cada una de las máquinas para que sean visibles desde Internet. Así, del rango disponible, una IP se configura en el router que hará NAT en toda la red LAN y el resto de las IP disponibles se van asignando a los servidores.
Figura 1 – Servidores instalados fuera de la red Este modelo funciona bien sino fuese por un pequeño detalle: la seguridad. Naturalmente que queremos proteger los servidores de ataques, limitar los puertos o prevenir intentos de hacking. Para eso necesitamos un firewall, pero ¿donde lo instalamos acá? No tiene mucho sentido instalar un firewall de hardware en este modelo, ya que se complicaría todo. Por lo mismo, muchos optan por instalar firewalls locales de software en cada uno de los servidores (iptables en Linux, por ejemplo). Cuando hay dos o tres servidores no es problema, pero ¿qué pasa si tenemos 20, 30, 40, 50 o 200 servidores y hay que modificar un puerto para una aplicación, en todos ellos? Creo que pasarás unas divertidas 10 horas copiando y pegando comandos en todos los servidores. La istración de la seguridad se hace muy difícil al tener firewalls de software en cada servidor. Ventajas: Fácil configuración. No requiere implementar cortafuegos físico. Si un servidor sufre un ataque la red LAN no estará comprometida. Desventajas: Se requiere un firewall de software para cada servidor. Modelo no escalable. Muy difícil de istrar. Los firewalls de software consumen recursos importantes en los servidores.
La solución a este dilema es mantener la seguridad centralizada en un firewall físico, pero para eso debemos mover los servidores dentro de nuestra infraestructura. Caso 2 – Servidores instalados en la LAN También es común ver este caso. La idea de proteger los servidores con un dispositivo centralizado se puede hacer con el mismo router corporativo al hacerlo funcionar además como un firewall básico (por ejemplo cuando se agregan ACLs) o bien con un firewall profesional que también incluye la función de NAT.
Figura 2 – Servidores instalados dentro de la LAN En este caso tenemos un poco más de protección ya que nuestro router se encargará del trabajo de direccionamiento y seguridad. Cada servidor tendrá una IP local (172.23.201.x/24) y los s de la red interna podrán acceder a sus servicios directamente en esas direcciones IP. Para que los servidores sean vistos desde Internet, el router deberá crear una política de NAT estático para cada servidor mapeando una IP pública del rango 201.223.0.0/28. Con este modelo solucionamos el problema de la complejidad de la istración de seguridad ya que esta se realizaría solamente en un dispositivo centralizado, pero ponemos en riesgo toda la red local que debe ser privada y protegida de s internos ya que si un hacker logra vulnerar uno de los servidores, tendrá directo a la LAN. Ventajas: Facilidad de istración de seguridad. Movilidad de las direcciones IP públicas. Los s acceden a los servicios directamente. Desventajas: Un ataque a los servidores dejaría completamente vulnerable la red LAN interna. Se debe implementar un servidor DNS de doble vista para resolver las IP internas.
Caso 3 – Servidores en la DMZ La solución a los casos anteriores es la DMZ. Con ella creamos una interfaz nueva y una subred independiente, pero siempre interna, para poder controlar mejor el a los servidores.
Figura 3 – Servidores en una DMZ Aquí conviene instalar un firewall corporativo de hardware en vez de agregarle funciones de seguridad a un router estándar, ya que el primero es un dispositivo completamente diseñado y preparado para este tipo de tareas. La DMZ es una subred independiente, separada de la LAN y de Internet (que en el mundo de firewalls se conoce como “outside”). Al crear una DMZ se puede configurar el firewall para crear reglas específicas de seguridad y NAT que permitan el tráfico proveniente de Internet solamente hacia esa zona. El NAT estático estaría asociado entre las IP públicas y las IP asignadas a cada servidor en la DMZ. Así, si un hacker vulnera la seguridad de uno de los servidores, este no tendría a la red LAN corporativa. Para eso es clave entender como se deben crear las reglas de tráfico y como se deben definir los perfiles de seguridad entre las zonas outside, LAN (o inside) y DMZ.
Figura 4 – Flujo de tráfico usando DMZ La figura 4 es aclaratoria ya que podemos ver claramente cual es la idea detrás de una DMZ finalmente. El firewall se configura con las siguientes políticas básicas: Origen
Destino
Política
Outside
DMZ
Permitido
Outside
Inside
Denegado
DMZ
Outside
Permitido
DMZ
Inside
Denegado
Inside
Outside
Permitido
Inside
DMZ
Permitido
Así se tendrá una red mucho más segura y fácil de istrar, sin exponer la LAN a un ataque directo y centralizando las políticas en el cortafuegos. El concepto de DMZ es transversal en la industria y todos los fabricantes lo utilizan de manera similar, por lo que esta descripción se ajusta a todos ellos. Para ver la configuración en detalle de un firewall Cisco ASA (Adaptive Security Appliance) consulta nuestro artículo al respecto