Enfoques alternativos al uso de DMZ para asegurar la comunicación hacia y desde un servidor web externo fuera del firewall

7

Soy un desarrollador de software con poco conocimiento de seguridad de red y casi ningún conocimiento de la arquitectura de red actual para el entorno en el que trabajo. Si tuviera alguno, no querría divulgar ninguna información, ya que podría ser un riesgo de seguridad. . Actualmente, la política de la compañía evita cualquier comunicación del servidor fuera de nuestra red. A medida que cambian las necesidades, busco una forma de transmitir a la administración que exista un enfoque alternativo seguro y confiable que permita que un servidor web externo se comunique con un servidor interno y viceversa.

Supongo que la ruta de tener un servidor de la empresa en la DMZ era evitar los problemas de no tener acceso remoto y no ser gobernado por el equipo de la red de la empresa. El enfoque deseado es posiblemente utilizar un servicio de terceros, como a través de un servicio en la nube, y así obtener el control sobre nuestras propias implementaciones.

Un enfoque alternativo que fue sugerido por un par para tener un servidor en la DMZ fue permitir solo la comunicación con el protocolo HTTP, bloquear todos los puertos pero 80 (no estoy seguro si está en el servidor y / o firewall) y solo permitir GET y Verbos POST.

Por favor, ilumíneme con las posibilidades, inquietudes, efectos secundarios, sugerencias y enfoques alternativos para lograr la capacidad de permitir que un servidor externo se comunique internamente y viceversa que no involucre una DMZ. No utilice un enlace a un PDF de 500 páginas como respuesta, a menos que se proporcione como referencia con algún detalle.

Gracias de antemano!

    
pregunta Alban 12.07.2011 - 21:25
fuente

3 respuestas

6

La respuesta tradicional es una arquitectura de tres niveles: web, aplicación y datos. Su capa web está aislada y solo puede hablar con el servidor de aplicaciones con métodos limitados (por ejemplo, solo una pequeña cantidad de llamadas RPC disponibles). El servidor de aplicaciones se comunica con la capa de datos (base) y, por supuesto, puede hacer lo que sea con las ACL o los procedimientos almacenados para hacerlo más seguro. Por motivos de seguridad, una arquitectura de tres niveles es una buena solución cuando se hace correctamente .

La sugerencia de su compañero de que solo permitir el puerto 80 es una especie de mínimo asumido. Y la inclusión de los verbos en la lista blanca está bien, pero tenga en cuenta que la mayoría de los ataques que enfrentará operan por encima de esa capa y se dirigirán con bastante felicidad sobre GET / POST. Lo que lleva a la respuesta moderna: sistemas de prevención de intrusiones que vigilan todo el tráfico que pasa, detectan patrones maliciosos y actúan para interceptarlos.

La respuesta tradicional y la respuesta moderna conducen a la respuesta real: no puede configurar [un servidor web externo] que sea tan seguro, confiable y seguro como no tener uno en primer lugar. Hagas lo que hagas aumentará tu riesgo por un margen. Cómo lo hace cambiará qué tan grande es ese margen de riesgo. Ya sea que vaya con una arquitectura de tres niveles, IDS / IPS, supervisión y alertas de registro, etc. Usted y su administración deciden cómo mitigar el riesgo y lo llevan a un nivel aceptable.

Y, desafortunadamente, aprender a mitigar el riesgo de manera segura significa revisar los PDF de 500 páginas para aprender los trucos. Un sombrero para un gato, o un gato para un sombrero, pero nada para nada.

    
respondido por el gowenfawr 12.07.2011 - 21:53
fuente
3

Arquitecturas que puedes usar:

  • Para los datos que no están sujetos a cambios, puede usar un método de inserción para colocar el contenido en el sitio web mediante un método seguro y autenticado (vpn, https o ssh / sftp) en modo batch, durante la noche o bajo demanda. p.ej. Cargar el código actualizado en el sitio web, cargar la base de datos de precios, cargar los datos comerciales para acceder.
  • Para los datos que se pueden colocar en la DMZ, puede colocar los tres niveles (Servidor web, Servidor de aplicaciones y Servidor DB) en la DMZ y dejarlos allí. Si necesita los datos internamente, probablemente pueda convencerlos de que copien los db internamente o haga referencia a él desde su red interna.
  • Para los datos internos que se necesitan en tiempo real desde su sitio web, puede crear una interfaz mínima que pueda superar su departamento de Seguridad / Red. Algo así como una función de db mínima que está bien protegida, usa menos privilegios y es monitoreada, posiblemente utilizando una base de datos de bastión intermediaria o similar (piense en las bases de datos de Oracle conectadas por enlaces de bases de datos).

Otros problemas:

  • Si la comunicación se transmite a través de Internet, debe cifrar y autenticar (vpn, https o sftp / ssh).
  • Es posible que desee preguntar a los expertos en seguridad cómo integrar mejor los datos internos y externos; si no puede superarlos, inviértalos a encontrar una solución.
  • Trate de determinar las inquietudes que tiene su personal de seguridad, generalmente son válidas y he tratado de explicar cuáles podrían ser mis experiencias similares, pero tendrá que empezar a pensar en la forma en que se ven el mundo (un poco de una exploración en este sitio de intercambio de pila de seguridad le dará sugerencias).
respondido por el Andrew Russell 13.07.2011 - 13:13
fuente
1

Suposiciones: la interfaz entre su red interna y la red externa proporciona actualmente el nivel de seguridad deseado. El servidor externo es de baja seguridad y puede estar comprometido.

Objetivos: mantener el nivel actual de seguridad en la conexión entre las redes internas y externas. Agregue una nueva interfaz a la conexión sin configurar una DMZ.

Desafortunadamente, la respuesta depende de su arquitectura actual, pero intentaré adivinar lo que podría tener. Supongo que tiene un enrutador conectado a un solo servidor bastion (combo firewall, IDS, NAT, proxy, etc.) y que el otro lado del servidor bastion es su red interna. Desea preservar la seguridad existente de su configuración actual, por lo que creo que es prudente modificar la arquitectura lo menos posible.

Nota: este es un croquis, debe hacer un análisis y una planificación exhaustivos antes de implementar una solución.

Compre una nueva máquina capaz de soportar dos interfaces de Ethernet físicamente separadas. Lo que quiero decir es que si la placa base tiene Ethernet incorporada, entonces necesita una tarjeta PCI o PCI Express Ethernet. Si la placa base no tiene Ethernet integrada, entonces necesita dos tarjetas PCI o PCI Express Ethernet.

Si su host bastion puede admitir una nueva tarjeta Ethernet físicamente separada, obtenga una nueva para su servidor bastion.

Si tiene una nueva tarjeta Ethernet para su servidor bastion, conecte uno de los puertos Ethernet en la nueva máquina a la nueva tarjeta en el servidor bastion. De lo contrario, simplemente conecte la nueva máquina a cualquier puerto disponible en el servidor bastion.

Elija una máquina interna como su punto de contacto interno para la nueva máquina. Si es posible, instale una nueva tarjeta de Ethernet físicamente separada en el punto de contacto interno. Instale el software VPN en la nueva máquina y el punto de contacto interno. Configure el servidor bastion para que solo acepte paquetes entrantes (¿también necesita salientes?) Del tipo correcto de la dirección MAC de la nueva máquina. Si el servidor bastion tiene una nueva tarjeta Ethernet, configúrelo para que solo acepte paquetes de la nueva máquina en la nueva interfaz física. Configure el firewall en la máquina interna para que solo acepte paquetes VPN entrantes de la nueva máquina (si es posible, en la nueva interfaz Ethernet). Configure la nueva máquina para aceptar los paquetes apropiados de Internet. Conecte la otra interfaz Ethernet físicamente separada al enrutador que está conectado a Internet. Compruebe los registros de auditoría con regularidad, mantenga buenas copias de seguridad, etc.

Esto no es demasiado caro. Una PC (no tiene que ser a nivel de servidor), tres tarjetas Ethernet, algunos cables, algunos programas y mucha configuración. Lo bueno es que ahora tiene una máquina a la que tiene acceso físico, que está conectada a Internet y requiere cambios mínimos en la arquitectura de la red para poder acomodarla. La parte mala es que esto requerirá mucha configuración y, probablemente, cierta convicción enérgica de los propietarios del host Bastión y la máquina de contacto interna.

    
respondido por el this.josh 14.07.2011 - 02:05
fuente

Lea otras preguntas en las etiquetas