Actualmente tenemos nuestro servidor web en una DMZ. El servidor web no puede ver nada dentro de la red interna, pero la red interna puede ver el servidor web. ¿Qué tan seguro sería hacer un agujero en el firewall entre la DMZ y la red interna a un solo servidor web en la intranet? Estamos trabajando en algo que interactuará con varias de nuestras aplicaciones de back-office (que están todas en un servidor) y sería mucho más fácil hacer este proyecto si pudiéramos comunicarnos directamente con el servidor IBM i que contiene estos datos ( a través de servicios web).
Según tengo entendido (y no conozco las marcas), tenemos un firewall para la DMZ con una IP externa diferente de nuestra IP principal con otro firewall. Otro firewall está entre el servidor web y la intranet.
Entonces algo como:
Web Server <==== Firewall ===== Intranet
| |
| |
Firewall Firewall
| |
| |
Internet IP1 Internet IP2
Respuestas:
No hay nada de malo en crear mecanismos de acceso para que los hosts en la DMZ accedan a los hosts en la red protegida cuando sea necesario para lograr el resultado deseado. Quizás, no sea preferible hacerlo, pero a veces es la única forma de hacer el trabajo.
Las cosas clave a considerar son:
Limite el acceso a la regla de firewall más específica que pueda. Si es posible, nombre los hosts específicos involucrados en la regla junto con los protocolos específicos (puertos TCP y / o UDP) que se utilizarán. Básicamente, abra solo un agujero tan pequeño como lo necesite.
Asegúrese de registrar el acceso desde el host DMZ al host en la red protegida y, si es posible, analice esos registros de forma automatizada para detectar anomalías. Quiere saber cuándo sucede algo fuera de lo común.
Reconozca que está exponiendo un host interno, incluso si es de manera indirecta, a Internet. Esté al tanto de los parches y actualizaciones para el software que está exponiendo y el software del sistema operativo del host.
Considere la autenticación mutua entre el host DMZ y el host interno, si eso es factible con la arquitectura de su aplicación. Sería bueno saber que las solicitudes que llegan al host interno en realidad provienen del host DMZ. Si puede hacer esto o no, dependerá en gran medida de la arquitectura de su aplicación. Además, tenga en cuenta que alguien que "posee" el host DMZ podrá realizar solicitudes al host interno incluso si se produce la autenticación (ya que, efectivamente, será el host DMZ).
Si le preocupan los ataques DoS, considere usar la limitación de velocidad para evitar que el host DMZ agote los recursos del host interno.
Es posible que desee considerar el uso de un enfoque de "firewall" de capa 7, donde las solicitudes del host DMZ se pasan primero a un host interno de propósito especial que puede "desinfectar" las solicitudes, verificarlas y luego pasarlas a el host de fondo "real". Dado que está hablando de la interfaz con sus aplicaciones de back-office en su IBM iSeries, supongo que tiene una capacidad limitada para realizar comprobaciones de cordura contra las solicitudes entrantes en el iSeries.
Si aborda esto de una manera metódica y mantiene un sentido común al respecto, no hay razón para que no pueda hacer lo que está describiendo mientras mantiene el riesgo minimizado al mismo tiempo.
Francamente, el hecho de que tenga una DMZ que no tenga acceso ilimitado a la red protegida lo coloca a pasos agigantados más allá de muchas redes que he visto. Al parecer, para algunas personas, DMZ simplemente significa "otra interfaz en el firewall, posiblemente con algunas direcciones RFC 1918 diferentes, y básicamente acceso ilimitado a Internet y la red protegida". Intente mantener su DMZ lo más bloqueada posible mientras logra los objetivos comerciales y lo hará bien.
fuente
Obviamente hay algunos peligros, pero puedes hacerlo. Básicamente estás abriendo un agujero por el que alguien podría entrar, así que hazlo pequeño. Limítelo solo a los servidores en cada extremo y permita solo datos en los puertos elegidos. No es una mala idea usar la traducción de direcciones de puerto para usar solo puertos extraños. Aún así, la seguridad por oscuridad no es seguridad en absoluto. Asegúrese de que el servidor del otro lado tenga algún tipo de forma de verificar que la información que pasa por esa conexión sea realmente lo que parece ser ... o al menos tenga algún tipo de firewall contextual. Además, hay ciertos firewalls creados para este tipo de cosas ... Sé que Microsoft ISA hace lo mismo para los servidores OWA y Exchange.
fuente