Acabamos de aprender sobre firewalls y DMZ y estoy luchando para entender cómo se implementan estos en realidad. La arquitectura que hemos aprendido fue algo como esto:
Supongamos que tenemos un sitio web de compras que permite a los usuarios registrar una cuenta para realizar compras en línea y también participar en el foro del sitio web.
En términos de seguridad, ¿qué activos deben colocarse en la DMZ y qué activos deben colocarse en la red interna?
Esto variará dependiendo de su situación específica, las políticas que está tratando de hacer cumplir y los requisitos de cumplimiento normativo.
En general, una aplicación web tiene un front-end y un back-end. El front-end es responsable de manejar el tráfico de usuarios, la visualización / presentación de datos y la autenticación. El back-end suele ser una base de datos de algún tipo que maneja la persistencia de la aplicación. También puede tener otros puntos de integración (por ejemplo, llamar a una API de envío o algo así).
Por favor, eche un vistazo a este enlace para obtener más información sobre Un patrón genérico de servidor web público. Idealmente, el tráfico no autenticado se trata lo más cerca posible del perímetro de la red. El tráfico externo nunca debe viajar más allá de la "DMZ" sin ser manejado por un proxy de filtrado o un servidor web. Por lo tanto, su solución debe tener un componente como ese en la DMZ. También es posible que desee crear otra zona, una que solo contenga el servidor de base de datos. Entonces tendría que pasar por otro servidor de seguridad para llegar a la red corporativa. De esta manera, si la base de datos estuviera comprometida, no comprometería otros sistemas en la red corporativa.
Comprenda que estas son solo generalizaciones, y dependiendo de la pila de tecnología presente, la solución puede cambiar.
Voy a responder tu pregunta a continuación, pero para ponerlo en contexto, lee primero lo siguiente:
El diagrama que estás usando es un patrón de los años noventa. Lo que puede ser mucho más fácil y seguro es simplemente usar un firewall con 3 o más interfaces. Esto también incluye la configuración de reglas de firewall y el filtrado del tráfico entre cualquiera de las dos interfaces. Un punto importante aquí es que no hay tráfico para ningún segmento que se ejecute a través de cualquier otro segmento:
3 interfaces:
+----DMZ
|
Internet---+ Firewall
|
+---- Intranet
Una versión un poco más compleja de esto puede parecerse a la siguiente:
4 interfaces:
+---- Intranet
|
Internet---+ Firewall+--- PCI Zone (Secured Subnet)
|
+---- DMZ
Dicho esto, la razón por la que la gente solía usar ese diseño era porque los firewalls originales eran muy caros y muchos solo venían con dos interfaces. También fue un diseño construido sobre tecnología de puente y proxies antiguos de hace mucho tiempo donde las personas simplemente estaban acostumbradas a tener solo dos interfaces con las que trabajar. Muchos de estos pasaron a las antiguas redes de IBM y, en algunos casos, también se utilizaron como puente entre Token-Ring o FDDI y Ethernet al mismo tiempo. Desde entonces los firewalls han evolucionado mucho.
Ahora que tiene una idea de cómo se ve un firewall con múltiples zonas seguras si tuviera que pensar en estar limitado por un hardware que solo admite dos interfaces Ethernet físicas (esto es antes de que existiera un estándar para VLANS, por lo que aún no se escucharon en ese momento) puede comprender por qué las personas construyeron el diseño que estaban viendo en su clase. En pocas palabras, en realidad era la única opción en el momento dado las restricciones de hardware. Nota: Esto no quiere decir que el diseño todavía no se use, pero la mayor parte de la industria ha pasado a diseños más segmentados que utilizan más interfaces físicas y virtuales. Un bit adicional de información que puede ser útil, si tiene una arquitectura de par redundante, necesitará interfaces redundantes que coincidan a través de ambos firewalls en cada zona segura (2 firewalls con 4 puertos para cada tipo de cosa).
En el diseño tradicional, los servidores de la DMZ son los que aceptan conexiones de Internet (fuera del mundo). La LAN tradicionalmente podía enviar paquetes al mundo exterior y recibir las respuestas a esas solicitudes, pero ninguna solicitud entrante del mundo exterior podía iniciarse para ingresar a la LAN. Parte de eso también fue tratar un problema de diseño que existía antes de que tuviéramos lo que se conoció como inspección de paquetes "con estado".
Explicación rápida de los cortafuegos con estado y sin estado:
Sin estado: Básicamente, solo los paquetes TCP bloqueados con el paquete ACK = 0 (Este es el primer paquete enviado en una secuencia TCP normal). Originalmente, este tipo de trabajo funcionó porque los servidores detrás del firewall no podían ensamblar un conjunto de paquetes y cerrarían la conexión una vez que se agotara el tiempo.
Con estado: se tuvo que crear con estado porque algunos atacantes inteligentes se dieron cuenta de que podían realizar ataques de Denegación de Servicio en los sistemas detrás de los cortafuegos sin estado llenando su memoria hasta que se bloquearon. Más tarde, las personas se dieron cuenta de que podían fragmentar los ataques en varios paquetes y las reglas de inspección del firewall no se activaban. Del mismo modo, también hubo un problema debido a lo que se conoce como ataques de paquete único, pero eso se produjo mucho más tarde.
El truco con Stateful es que el Firewall ahora tiene que tener más RAM, pero ahora puede mantener los paquetes hasta que estén lo suficientemente juntos y puedan ser analizados (para detectar los elementos fragmentados) y también eliminar el problema del ataque de un solo paquete del servidor. Básicamente, el Firewall ahora detiene todo, recopila y analiza el estado de la conexión de todos los paquetes, inspecciona TODOS los paquetes y al hacerlo, proporciona una protección adicional para el servidor.
Más tarde nos metimos en el proxy de aplicaciones, los firewalls de aplicaciones web y los firewalls de base de datos.
Nota: hay otros tipos de ataques de fragmentos que los que he mencionado y esta es una explicación muy clara de todas las tecnologías que acabo de mencionar, pero espero que sea suficiente para poner tu pregunta en perspectiva para que tenga más sentido. .
Finalmente, como CtrlDot gran parte de la respuesta depende de su escenario y uso específicos. Estas son respuestas generales de alto nivel.
Lea otras preguntas en las etiquetas firewalls network architecture