¿Al firewall o no al firewall?

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, que es esencialmente una empresa orientada al host, naturalmente va a estar del lado de las soluciones de seguridad basadas en el 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", según lo define Gartner, están diseñados específicamente para permitir al usuario y la aplicación, así como el control tradicional de IP, puertos y políticas de protocolo. (No siempre soy un fanático de Gartner, pero tienen razón con los NGFW). Por lo tanto, un NGFW que pueda controlar el acceso desde la Capa 3 a la Capa 7 será una solución mejor que un enfoque basado en el 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 NGFWs 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ógica que le permiten aislar servidores que contienen datos privados.

• Controle el acceso a datos privados según las 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.

Habiendo 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 necesitas encontrar dónde se encuentra la PII.

Segundo, 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 "repose" en las estaciones de trabajo de los usuarios finales y se transmita de un usuario a otro.

Cuarto, es posible que desee agregar un control de acceso a la base de datos específico que supervise el 100% de los accesos a la base de datos. Este debe ser un control basado en host. No hay otra manera de asegurarse de que esté supervisando todo, incluidas las vistas, los procedimientos almacenados y los activadores.

Mi experiencia es principalmente con grandes bancos globales, por lo que puede que no sea apropiado para todos, pero el escenario típico para ellos es muy parecido al # 3, excepto que está más segregado, por lo que existen 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, normalmente servicios MPLS de diferentes proveedores, con enrutadores de choque que se unen a un equilibrador de carga, con aceleración de VPN inmediatamente dentro o fuera del equilibrador de carga Dependiendo de la estructura.

El conjunto de firewall externo luego proporciona DMZ segregados para servidores web, etc., con un firewall interno que brinda 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 integran cada vez más en el servidor web, estas desaparecen lentamente.

Un conjunto separado de conexiones, que utiliza firewalls o proxies inversos, se usaría para que los usuarios internos se conecten hacia afuera, y otro conjunto de firewalls para conectividad de acceso remoto.

Si tuviera que revisar un banco global que no tenía al menos estos componentes, me preocuparía mucho por qué no estaban cuidando adecuadamente y una auditoría de TI tendría comentarios interesantes sobre por qué el negocio No podía confiar en que el medio ambiente estuviera seguro.

El mayor problema que tengo con esa teoría (escuché argumentos similares) es que si elimina el firewall, aún puede hacer el servidor de aplicaciones.

Sin embargo, una pregunta de seguimiento es: ¿puede usar con éxito IPsec y PKI en los servidores web de Internet?

También argumentaría que al agregar medidas de defensa en profundidad, por definición, estás incrementando la disponibilidad, pero solo para aquellos que deberían tenerla si lo haces correctamente.

Dicho esto, soy parcial al escenario # 2, pero no separo los servidores de correo / web y DB por los switches. 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 switches redundantes.

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

Sin embargo, hay cosas que podrían considerarse como las funciones de un servidor de seguridad que no se pueden implementar fácilmente en este nivel (por ejemplo, filtrado AV). Pero nuevamente, hay herramientas que se ejecutarán en el servidor a expensas de una CPU adicional, en comparación con el gasto de otro salto de red. Pero si está en el juego de ejecutar servicios que pueden estar comprometidos o 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 aún 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, en particular 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 la caja de seguridad que se posee y se administra de manera independiente de los servidores. En mi humilde opinión es una premisa falsa: la seguridad debe ser generalizada y en todas partes: hay muchas personas que desean venderle una magia. cuadro que hace que sus sistemas sean seguros, pero no ayudarán con la mayoría de los problemas en el nivel de la aplicación.

Si fuera yo quien configurara los servidores que 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. 2 capas de red con la base de datos en el interior.

Si le preocupa un solo punto de falla contra un DDoS, puede configurar múltiples cortafuegos en un sistema con 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 en el que la línea entrante está saturada. En ese momento, no importa si tiene un firewall o no.

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