it-swarm-es.com

¿Al cortafuegos o no al cortafuegos?

Recientemente ha habido algunos discusión (para ser generoso) sobre los pros y los contras de tener un firewall implementado frente a los servidores. La desventaja es que es un punto de falla en caso de un DDoS. Microsoft ha estado hablando de eliminar el firewall independiente y, en cambio, basar la seguridad en PKI e IPsec, lo que significa que no puede hablar con el servidor si no tiene un certificado apropiado (no hay fuente para esto, fue una charla a la que asistí ).

Entonces , dado un escenario simplista en el que tienes, por ejemplo, un servidor web, un servidor de correo y un servidor de base de datos respaldando el servidor web, ¿cuál es el diseño de firewall/red de mejores prácticas actual, según usted? Soy muy consciente las implementaciones no son tan sencillas, pero creo que el ejemplo funciona lo suficientemente bien como para basar una discusión.

Soy también consciente de que las mejores prácticas teóricas tradicionales serían agregar tantas capas de defensa como sea posible, pero ¿es este el diseño que da como resultado la máxima disponibilidad, considerando todo?

(Suponga que los servidores están reforzados adecuadamente y no exponen ningún servicio que no deberían estar ejecutando, que los conmutadores no agregan nada a la ecuación de seguridad y que la administración está fuera de banda o desde la parte de la nube del dibujo. Lo que prefiera, ya que agrega sus propias complicaciones de cualquier manera ...)

Escenario # 1, enrutado simple

Un diseño claro, enrutado, sin cortafuegos. El enrutador Edge puede aplicar una ACL, alguna limitación de velocidad. El servidor de base de datos puede estar en direcciones privadas que no son enrutables desde Internet. Los hosts ejecutarían un firewall, como Windows integrado o iptables etc. El administrador que ejecuta los hosts debería considerar el entorno alrededor de los hosts hostiles.

Routed design

Escenario # 2, tradicional cortafuegos

El enrutador puede proporcionar o no cualquier funcionalidad anterior, simplemente reenviar paquetes. El firewall implementa la política completa y la segmentación. Los hosts pueden, opcionalmente, tener algún tipo de firewall, pero probablemente no. El administrador que ejecuta los hosts probablemente considerará el entorno seguro.

enter image description here

Escenario # 3, realmente nos gustan los firewalls

Como # 2, pero más segmentado.

enter image description here

Tradicionalmente he estado construyendo # 2 o # 1, y me inclino cada vez más hacia el # 1. Probablemente me atraiga la "simplicidad" del diseño y la "pureza" de querer que los anfitriones puedan sobrevivir en un entorno hostil. Soy consciente de que esto está en contraste con la defensa en profundidad. :)

23
Jakob Borg

Estoy seguro de que sabe que para muchas amenazas de seguridad y/o requisitos de cumplimiento existen controles de mitigación tanto basados ​​en la red como en el host.

Microsoft, siendo esencialmente una empresa orientada a Host, naturalmente estará del lado de las soluciones de seguridad basadas en Host. Y cuando se trata de personas y aplicaciones, uno tradicionalmente estaría del lado de una solución basada en Host. Pero los cortafuegos han cambiado. Los "firewalls de próxima generación", tal como los define Gartner, están diseñados específicamente para permitir a los usuarios y las aplicaciones, así como el control tradicional de políticas de IP, puertos y protocolos. (No siempre soy un fanático de Gartner, pero tienen razón en los NGFW). Por lo tanto, un NGFW que pueda controlar el acceso desde la Capa 3 a la Capa 7 será una mejor solución que un enfoque basado en Host que, por supuesto, es ciego a niveles más bajos de comunicaciones.

Mi estado natal, Massachusetts, aprobó una ley de privacidad muy estricta. Las organizaciones están colocando NGFW entre usuarios y servidores para cumplir con sus requisitos. Estos son algunos de los requisitos de la ley y cómo los cumple un NGFW:

  • Aislar datos privados: defina zonas de seguridad lógicas que le permiten aislar servidores que contienen datos privados.

  • Controle el acceso a datos privados basados ​​en aplicaciones: defina políticas para controlar qué aplicaciones pueden acceder a los servidores que contienen datos privados.

  • Controle qué usuarios tienen acceso a datos privados: integre el firewall con sus servidores LDAP para que pueda definir políticas para controlar qué grupos tienen acceso a datos privados.

  • Detectar y bloquear amenazas: este firewall también debe tener una capacidad de protección contra amenazas para monitorear el tráfico permitido y bloquear las amenazas detectadas.

Por cierto, dependiendo del firewall que esté utilizando, puede crear el escenario # 3 con un firewall físico.

Dicho esto, si el objetivo es proteger la información de identificación personal (PII), un NGFW por sí solo no es la respuesta completa. Primero debe encontrar dónde se encuentra la PII.

En segundo lugar, una vez que haya encontrado toda la PII, es posible que desee tomar medidas para consolidarla en la menor cantidad de servidores posible.

En tercer lugar, es posible que desee implementar controles para evitar que la PII "descanse" en las estaciones de trabajo del usuario final y se transmita de un usuario a otra persona.

Cuarto, es posible que desee agregar un control de acceso a la base de datos específico que monitoree el 100% de los accesos a la base de datos. Este debe ser un control basado en el host. No hay otra manera de asegurarse de que está monitoreando todo, incluyendo Vistas, Procedimientos almacenados y Disparadores.

8
Bill Frank

Mi experiencia es principalmente con grandes bancos globales, por lo que esto puede no ser apropiado para todos, pero el escenario típico para ellos es muy similar al # 3, excepto que está más segregado, por lo que hay múltiples DMZ, generalmente segregadas por función, perfil de riesgo, propietario del departamento u otros criterios.

Además, todo lo que se conecta a Internet se replica, por lo que tendría al menos dos conexiones, generalmente servicios MPLS de diferentes proveedores, con enrutadores de choque que se unen en un equilibrador de carga, con aceleración VPN inmediatamente dentro o fuera del equilibrador de carga dependiendo de la estructura .

El conjunto de firewall externo proporciona DMZ segregadas para servidores web, etc., con un firewall interno que proporciona protección para las bases de datos. En algunos casos hay una capa adicional, con servidores de aplicaciones, pero a medida que las aplicaciones se van incorporando cada vez más en el servidor web, estas desaparecen lentamente.

Se usaría un conjunto separado de conexiones, utilizando firewalls separados o servidores proxy inversos, para que los usuarios internos se conectaran hacia afuera, y otro conjunto de firewalls para la conectividad de acceso remoto.

Si tuviera que revisar un banco global que no tuviera al menos estos componentes, me preocuparía mucho por qué no se estaban ocupando adecuadamente, y una auditoría de TI tendría comentarios interesantes sobre por qué la empresa no pudo confiar en que el medio ambiente sea seguro.

7
Rory Alsop

El mayor problema que tengo con esa teoría (he escuchado argumentos similares) es que si eliminas el cortafuegos, aún puedes DoS los servidores de aplicaciones.

Sin embargo, una pregunta de seguimiento a esto es: ¿puede utilizar con éxito IPsec y PKI en servidores web con conexión a Internet?

También diría que al agregar medidas de defensa en profundidad, por definición, está aumentando la disponibilidad, pero solo para aquellos que deberían tenerlo si lo hace correctamente.

Dicho esto, soy parcial en el escenario # 2, pero no separo los servidores de Correo/Web y DB por conmutadores. Si hay otros servidores y clientes en la red, también agregaría un firewall entre ellos creando una DMZ. Después de eso, también recomendaría agregar firewalls y conmutadores redundantes.

5
Steve

Todos los sistemas operativos de servidor que he configurado en los últimos años tienen alguna facilidad para el firewall, y casi todos los enrutadores. Es obvio que es una buena idea configurar el acceso restringido en la caja. Y, por supuesto, una buena práctica para no ejecutar servicios innecesarios.

Sin embargo, hay cosas que podrían considerarse como las funciones de un firewall que no se pueden implementar fácilmente a este nivel (por ejemplo, filtrado AV). Pero, de nuevo, hay herramientas que se ejecutarán en el servidor a expensas de una CPU adicional, frente a los gastos de otro salto de red. Pero si está en el juego de ejecutar servicios que pueden verse comprometidos/necesitan mantener la disponibilidad, entonces ya debería estar ejecutando un clúster en lugar de un solo nodo.

En mi humilde opinión, el MS winsock.dll todavía expone una gran cantidad de complejidad en el exterior del firewall, pero este es probablemente un caso especial.

Existe un fuerte argumento para mantener un cuello de botella como protección contra un DOS, particularmente un DDOS: hace que la identificación y el bloqueo en tiempo real sean mucho más simples. No tiene que ser un SPOF.

En las organizaciones más grandes, a menudo se considera un beneficio tener y administrar la caja de seguridad independientemente de los servidores, en mi humilde opinión, esa es una premisa falsa, la seguridad debe ser dominante y en todas partes, hay muchas personas que desean venderle una caja mágica que hace sus sistemas son seguros, pero no ayudarán con la mayoría de los problemas a nivel de aplicación.

Si fuera yo el que configurara los servidores que usted describe (dejando de lado el hecho de que cada servidor parece ser un punto único de falla), no conectaría la base de datos a la misma red que el enrutador: ejecutaría 2 capas de red con el DB en el interior.

5
symcbean

Si le preocupa un solo punto de falla contra un DDoS, puede configurar varios firewalls en un sistema de carga equilibrada donde puede procesar el tráfico a la velocidad de la línea. Con este tipo de configuración, el único ataque DDoS que tendrá éxito es uno donde la línea entrante está saturada. En ese momento, si tiene un firewall o no, no importará.

Recomendaría la solución 2, ya que todavía permitirá la comunicación entre los hosts, incluso si hay un ataque DDoS en su lugar. En la solución 1, el tráfico no deseado todavía se está procesando a través del conmutador, posiblemente reduciendo la velocidad y agregando tráfico innecesario.

4
jhulst