Este artículo es el tercero de una serie de artículos titulados "Cómo tomar la infraestructura de red bajo su control". El contenido de todos los artículos de la serie y los enlaces se puede encontrar aquí .



No tiene sentido hablar sobre la eliminación completa de los riesgos de seguridad. En principio, no podemos reducirlos a cero. También debe comprender que a medida que nos esforzamos por hacer que la red sea cada vez más segura, nuestras soluciones se vuelven cada vez más caras. Debe encontrar un compromiso razonable para su red entre precio, complejidad y seguridad.

Por supuesto, el diseño de seguridad está integrado orgánicamente en la arquitectura general y las soluciones de seguridad utilizadas afectan la escalabilidad, la fiabilidad, la capacidad de gestión, ... la infraestructura de red, que también debe tenerse en cuenta.

Pero les recuerdo que ahora no estamos hablando de crear una red. De acuerdo con nuestras condiciones iniciales , ya elegimos un diseño, seleccionamos equipos y creamos una infraestructura, y en esta etapa deberíamos, si es posible, "vivir" y encontrar soluciones en el contexto del enfoque elegido anteriormente.

Nuestra tarea ahora es identificar los riesgos asociados con la seguridad a nivel de red y reducirlos a un valor razonable.

Auditoría de seguridad de red

Si su organización ha implementado procesos ISO 27k, las auditorías de seguridad y los cambios de red deben integrarse orgánicamente en los procesos generales como parte de este enfoque. Pero estos estándares todavía no se tratan de soluciones específicas, no se trata de configuración, no se trata de diseño ... No hay consejos definitivos, no hay estándares que dicten en detalle cuál debe ser su red, esta es la complejidad y belleza de esta tarea.

Destacaría varias posibles auditorías de seguridad de red:

• auditoría de configuración del equipo (endurecimiento)
• diseño de auditoria de seguridad
• auditoría de acceso
• auditoria de procesos

Auditoría de configuración de hardware (endurecimiento)

En la mayoría de los casos, este parece ser el mejor punto de partida para auditar y mejorar la seguridad de su red. En mi humilde opinión, esta es una buena demostración de la ley de Pareto (el 20% del esfuerzo da el 80% del resultado, y el 80% restante del esfuerzo es solo el 20% del resultado).

La conclusión es que generalmente tenemos recomendaciones de los proveedores con respecto a las "mejores prácticas" en seguridad al configurar el equipo. Esto se llama endurecimiento.

También puede encontrar un cuestionario (o componerlo usted mismo) basado en estas recomendaciones, que lo ayudará a determinar cómo su configuración de hardware coincide con estas "mejores prácticas" y realizar cambios en su red de acuerdo con el resultado. Esto le permitirá, con bastante facilidad, prácticamente sin costo, reducir significativamente los riesgos de seguridad.

Algunos ejemplos para algunos sistemas operativos Cisco.

Cisco IOS Configuration Hardening
Endurecimiento de la configuración de Cisco IOS-XR
Endurecimiento de la configuración de Cisco NX-OS
Lista de comprobación de seguridad básica de Cisco

En base a estos documentos, se puede crear una lista de requisitos de configuración para cada tipo de equipo. Por ejemplo, para un Cisco N7K VDC, estos requisitos podrían verse así.

Por lo tanto, se pueden crear archivos de configuración para diferentes tipos de equipos activos de su infraestructura de red. Además, manualmente o utilizando la automatización, puede "cargar" estos archivos de configuración. La forma de automatizar este proceso se discutirá en detalle en otra serie de artículos sobre orquestación y automatización.

Diseño de auditoria de seguridad

Por lo general, una red empresarial de una forma u otra contiene los siguientes segmentos:

• DC (DMZ de servicios públicos y centro de datos de Intranet)
• Acceso a internet
• VPN de acceso remoto
• Borde de Wan
• Rama
• Campus (oficina)
• Núcleo

Los nombres se toman del modelo Cisco SAFE , pero, por supuesto, no es necesario vincularlos con estos nombres y con este modelo. Aún así, quiero hablar sobre la esencia y no atascarme en formalidades.

Para cada uno de estos segmentos, los requisitos para el nivel de seguridad, los riesgos y, en consecuencia, las decisiones serán diferentes.

Consideraremos cada uno de ellos individualmente para los problemas que pueda encontrar en términos de diseño de seguridad. Por supuesto, repito nuevamente que de ninguna manera este artículo afirma ser completo, lo que en este tema realmente profundo y multifacético no es fácil de lograr (si es posible), sino que refleja mi experiencia personal.

No hay una solución perfecta (al menos por ahora). Siempre es un compromiso. Pero es importante que la decisión de aplicar este o aquel enfoque se tome conscientemente, con una comprensión de sus pros y sus contras.

Centro de datos

El segmento de seguridad más crítico.
Y, como siempre, tampoco existe una solución universal. Todo depende de los requisitos de la red.

¿Es necesario o no un firewall?

Parece que la respuesta es obvia, pero no todo es tan claro como podría parecer. Y su elección puede verse afectada no solo por el precio .

Ejemplo 1. Retrasos.

Si entre algunos segmentos de la red, la baja latencia es un requisito esencial, que, por ejemplo, es cierto en el caso de un intercambio, entonces entre estos segmentos no podremos usar firewalls. Es difícil encontrar estudios sobre los retrasos en los firewalls, pero solo unos pocos modelos de conmutadores pueden proporcionar retrasos de menos de 1 mkseg, por lo que creo que si los microsegundos son importantes para usted, los firewalls no lo son para usted.

Ejemplo 2. Rendimiento.

El ancho de banda de los principales conmutadores L3 suele ser un orden de magnitud mayor que el ancho de banda de los firewalls más productivos. Por lo tanto, en el caso del tráfico de alta intensidad, lo más probable es que también deba permitir que este tráfico evite los firewalls.

Ejemplo 3. Fiabilidad.

Los firewalls, especialmente los modernos NGFW (Next-Generation FW) son dispositivos complejos. Son significativamente más complejos que los interruptores L3 / L2. Proporcionan una gran cantidad de servicios y opciones de configuración, por lo que no es sorprendente que su confiabilidad sea mucho menor. Si la continuidad del servicio es crítica para la red, entonces puede que tenga que elegir lo que conducirá a una mejor disponibilidad: la seguridad del firewall o la simplicidad de una red integrada en conmutadores (o varios tipos de fábricas) que usan ACL comunes.

En el caso de los ejemplos anteriores, lo más probable (como de costumbre) tendrá que encontrar un compromiso. Mire hacia las siguientes soluciones:

• Si decide no usar firewalls dentro del centro de datos, debe considerar cómo limitar el acceso al perímetro tanto como sea posible. Por ejemplo, puede abrir solo los puertos necesarios desde Internet (para el tráfico de clientes) y el acceso administrativo al centro de datos solo desde hosts host. En los hosts de salto, realice todas las verificaciones necesarias (autenticación / autorización, antivirus, registro, ...)
• puede usar la partición lógica de la red del centro de datos en segmentos, similar al esquema descrito en el ejemplo PSEFABRIC p002 . Al mismo tiempo, el enrutamiento debe configurarse de modo que el tráfico sensible a demoras o tráfico de alta intensidad vaya "dentro" de un segmento (en el caso de p002, VRF-a) y no atraviese el firewall. El tráfico entre diferentes segmentos seguirá atravesando el firewall. También puede usar la ruta que se escapa entre los VRF para evitar redirigir el tráfico a través del firewall.
• También puede usar el firewall en modo transparente y solo para aquellas VLAN donde estos factores (retraso / rendimiento) no son significativos. Pero debe estudiar detenidamente las limitaciones asociadas con el uso de este mod para cada proveedor
• puede considerar aplicar una arquitectura de cadena de servicio. Esto le permitirá dirigir solo el tráfico necesario a través del firewall. Teóricamente se ve hermoso, pero nunca he visto esta solución en producción. Probamos la cadena de servicio para Cisco ACI / Juniper SRX / F5 LTM hace aproximadamente 3 años, pero en ese momento esta solución nos parecía "en bruto"

Nivel de protección

Ahora debe responder a la pregunta de qué herramientas desea utilizar para filtrar el tráfico. Estas son algunas de las características que generalmente están presentes en NGFW (por ejemplo, aquí ):

• firewall con estado (predeterminado)
• cortafuegos de aplicaciones
• prevención de amenazas (antivirus, anti-spyware y vulnerabilidad)
• Filtrado de URL
• filtrado de datos (filtrado de contenido)
• bloqueo de archivos (bloqueo de tipos de archivos)
• dos protección

Y tampoco todo está claro. Parece que cuanto mayor sea el nivel de protección, mejor. Pero también debes considerar que

• cuantas más de las funciones de cortafuegos anteriores use, naturalmente será más costoso (licencias, módulos adicionales)
• El uso de ciertos algoritmos puede reducir significativamente el rendimiento del firewall, así como aumentar los retrasos, ver por ejemplo aquí
• Al igual que cualquier solución compleja, el uso de métodos de protección complejos puede reducir la confiabilidad de su solución, por ejemplo, al usar el firewall de aplicaciones, encontré el bloqueo de algunas aplicaciones de trabajo bastante estándar (dns, smb)

Usted, como siempre, necesita encontrar la mejor solución para su red.

Es imposible responder inequívocamente a la pregunta de qué funciones de protección pueden ser necesarias. En primer lugar, porque, por supuesto, depende de los datos que transfiera o almacene y que esté tratando de proteger. En segundo lugar, en realidad, a menudo la elección de remedios es una cuestión de fe y confianza en el vendedor. No conoce los algoritmos, no sabe cuán efectivos son y no puede probarlos por completo.

Por lo tanto, en segmentos críticos, una buena solución puede ser utilizar ofertas de diferentes compañías. Por ejemplo, puede habilitar antivirus en un firewall, pero también usar protección antivirus (de otro fabricante) localmente en los hosts.

Segmentación

Esta es una segmentación lógica de la red del centro de datos. Por ejemplo, dividirse en VLAN y subredes también es una segmentación lógica, pero no lo consideraremos por su obviedad. La segmentación es interesante teniendo en cuenta entidades como las zonas de seguridad FW, VRF (y sus análogos en relación con varios proveedores), dispositivos lógicos (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Un ejemplo de dicha segmentación lógica y el diseño del centro de datos actualmente requerido se da en la p002 del proyecto PSEFABRIC .

Una vez definidas las partes lógicas de su red, puede describir mejor cómo fluye el tráfico entre los diferentes segmentos, en qué dispositivos se realizará el filtrado y por qué medios.

Si su red no tiene una partición lógica clara y las reglas para aplicar políticas de seguridad para diferentes flujos de datos no están formalizadas, esto significa que cuando abre este o aquel acceso, se ve obligado a resolver este problema, y ​​con una alta probabilidad lo resolverá cada vez. de diferentes maneras

A menudo, la segmentación se basa solo en zonas de seguridad FW. Luego debe responder las siguientes preguntas:

• que zonas de seguridad necesitas
• ¿Qué nivel de protección desea aplicar a cada una de estas zonas?
• si el tráfico dentro de la zona se permitirá por defecto
• si no, qué políticas de filtrado de tráfico se aplicarán dentro de cada zona
• qué políticas de filtrado de tráfico se aplicarán para cada par de zonas (origen / destino)

TCAM

A menudo existe el problema de insuficiente TCAM (memoria direccionable de contenido ternario), tanto para el enrutamiento como para los accesos. En mi humilde opinión, este es uno de los problemas más importantes al elegir el equipo, por lo que debe tratar este problema con el grado adecuado de precisión.

Ejemplo 1. Tabla de reenvío TCAM.

Veamos el firewall de Palo Alto 7k .
Vemos que el tamaño de la tabla de reenvío IPv4 * = 32K
Al mismo tiempo, este número de rutas es común para todos los VSYS.

Suponga que decide usar 4 VSYS de acuerdo con su diseño.
Cada uno de estos VSPS de BGPS está conectado a dos PE de nube MPLS que utiliza como BB. Por lo tanto, 4 VSYS intercambian todas las rutas específicas entre sí y tienen una tabla de reenvío con aproximadamente los mismos conjuntos de rutas (pero diferentes NH). Porque cada VSYS tiene 2 sesiones BGP (con la misma configuración), luego cada ruta recibida a través de MPLS tiene 2 NH y, en consecuencia, 2 entradas FIB en la tabla de reenvío. Si suponemos que este es el único cortafuegos en el centro de datos y debe conocer todas las rutas, esto significará que el número total de rutas en nuestro centro de datos no puede ser superior a 32K / (4 * 2) = 4K.

Ahora, si suponemos que tenemos 2 centros de datos (con el mismo diseño), y queremos usar VLAN "extendidas" entre centros de datos (por ejemplo, para vMotion), entonces para resolver el problema de enrutamiento, deberíamos usar rutas de host, pero esto significa que para 2 centros de datos no tendremos más de 4096 hosts posibles y, por supuesto, esto puede no ser suficiente.

Ejemplo 2. ACL TCAM.

Si planea filtrar el tráfico en los conmutadores L3 (u otras soluciones que utilizan conmutadores L3, por ejemplo, Cisco ACI), debe prestar atención a las ACL de TCAM al elegir el equipo.

Suponga que desea controlar el acceso en las interfaces SVI del Cisco Catalyst 4500. Luego, como puede ver en este artículo , puede usar solo 4096 líneas de TCAM para controlar el tráfico saliente (así como entrante) en las interfaces. Lo que al usar TCAM3 le dará aproximadamente 4000 mil ACE (líneas ACL).

Si se enfrenta al problema de TCAM insuficiente, entonces, primero que nada, por supuesto, debe considerar la posibilidad de optimización. Por lo tanto, en caso de un problema con el tamaño de la tabla de reenvío, debe considerar la posibilidad de agregar rutas. En el caso de un problema con el tamaño de TCAM para los accesos: auditoría de accesos, eliminación de registros obsoletos y superpuestos, así como, posiblemente, revisión del procedimiento para abrir accesos (se discutirá en detalle en el capítulo sobre auditoría de acceso).

Alta disponibilidad

La pregunta es si usar HA para firewalls o poner dos casillas independientes "en paralelo" y, en caso de que una de ellas falle, ¿enrutar el tráfico a través de la segunda?

Parece que la respuesta es obvia: use HA. Sin embargo, la razón por la que surge esta pregunta es que, desafortunadamente, la teoría y la publicidad 99 y unos pocos nueves después del punto decimal del porcentaje de accesibilidad en la práctica resultan ser mucho menos optimistas. HA es lógicamente algo bastante complicado, y en diferentes equipos, y con diferentes proveedores (no hubo excepciones), detectamos problemas, errores y el cierre del servicio.

En el caso de usar HA, podrá apagar nodos individuales, cambiar entre ellos sin detener el servicio, lo cual es importante, por ejemplo, al actualizar, pero tiene una probabilidad muy remota de que ambos nodos se rompan al mismo tiempo, y también que el siguiente La actualización no será tan fácil como promete el proveedor (este problema se puede evitar si tiene la oportunidad de probar la actualización en el equipo de laboratorio).

Si no usa HA, entonces, desde el punto de vista del doble daño, sus riesgos son mucho más bajos (ya que tiene 2 firewalls independientes), pero porque Como las sesiones no están sincronizadas, cada vez que se produce el cambio entre estos firewalls, perderá tráfico. Por supuesto, puede usar firewalls sin estado, pero luego se pierde en gran medida el significado de usar un firewall.

Por lo tanto, si como resultado de una auditoría encuentra firewalls solitarios y piensa en aumentar la confiabilidad de su red, entonces HA, por supuesto, es una de las soluciones recomendadas, pero debe tener en cuenta las desventajas asociadas con este enfoque y, tal vez, solo para su Otra solución sería más apropiada.

Manejabilidad

En principio, HA también se trata de manejabilidad. En lugar de configurar 2 cuadros individualmente y resolver el problema de sincronización de configuraciones, las administra de muchas maneras como si tuviera un dispositivo.

Pero quizás tenga muchos centros de datos y muchos firewalls, entonces esta pregunta se eleva a un nuevo nivel. Y la pregunta no es solo sobre la configuración, sino también sobre

• configuraciones de respaldo
• actualizaciones
• actualizaciones
• monitoreo
• registro

Y todo esto puede resolverse mediante sistemas de gestión centralizados.

Entonces, por ejemplo, si usa firewalls de Palo Alto, entonces Panorama es una solución.

Continuará