Este artículo es el tercero de una serie de artículos "Cómo tomar el control de su infraestructura de red". Se pueden encontrar los contenidos de todos los artículos de la serie y los enlaces. .
No tiene sentido hablar de eliminar por completo los riesgos de seguridad. En principio, no podemos reducirlos a cero. También debemos comprender que a medida que nos esforzamos por hacer que la red sea cada vez más segura, nuestras soluciones son cada vez más caras. Necesita encontrar un equilibrio entre costo, complejidad y seguridad que tenga sentido para su red.
Por supuesto, el diseño de seguridad está integrado orgánicamente en la arquitectura general y las soluciones de seguridad utilizadas afectan a la escalabilidad, fiabilidad, manejabilidad,... de la infraestructura de red, lo que también debe tenerse en cuenta.
Pero déjame recordarte que ahora no estamos hablando de crear una red. De acuerdo con nuestro Ya hemos elegido el diseño, seleccionado el equipo y creado la infraestructura, y en esta etapa, si es posible, deberíamos “vivir” y encontrar soluciones en el contexto del enfoque previamente elegido.
Nuestra tarea ahora es identificar los riesgos asociados con la seguridad a nivel de red y reducirlos a un nivel razonable.
Auditoría de seguridad de la red
Si su organización ha implementado procesos ISO 27k, entonces las auditorías de seguridad y los cambios de red deberían encajar perfectamente en los procesos generales dentro de este enfoque. Pero estos estándares todavía no se refieren a soluciones específicas, ni a configuración, ni a diseño... No hay consejos claros, ni estándares que dicten en detalle cómo debería ser su red, esta es la complejidad y la belleza de esta tarea.
Destacaría varias posibles auditorías de seguridad de la red:
- auditoría de configuración de equipos (endurecimiento)
- auditoría de diseño de seguridad
- auditoría de acceso
- auditoría de proceso
Auditoría de configuración de equipos (endurecimiento)
Parece que en la mayoría de los casos este es 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 produce el 80% del resultado y el 80% restante del esfuerzo produce solo el 20% del resultado).
La conclusión es que normalmente recibimos recomendaciones de los proveedores sobre las “mejores prácticas” de seguridad al configurar el equipo. Esto se llama "endurecimiento".
A menudo también puedes encontrar un cuestionario (o crear uno tú mismo) basado en estas recomendaciones, que te ayudará a determinar qué tan bien la configuración de tu equipo cumple con estas “mejores prácticas” y, de acuerdo con el resultado, realizar cambios en tu red. . Esto le permitirá reducir significativamente los riesgos de seguridad con bastante facilidad y prácticamente sin coste alguno.
Varios ejemplos para algunos sistemas operativos de Cisco.
A partir de 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í .
De esta forma, se pueden crear archivos de configuración para diferentes tipos de equipos activos en su infraestructura de red. A continuación, manualmente o mediante la automatización, puede "cargar" estos archivos de configuración. Cómo automatizar este proceso se discutirá en detalle en otra serie de artículos sobre orquestación y automatización.
Auditoría de diseño de seguridad
Normalmente, una red empresarial contiene los siguientes segmentos de una forma u otra:
- DC (Servicios públicos DMZ y centro de datos de Intranet)
- acceso a Internet
- VPN de acceso remoto
- Borde WAN
- Rama
- Campus (Oficina)
- Core
Títulos tomados de modelo, pero no es necesario, por supuesto, vincularse precisamente a estos nombres y a este modelo. Aún así, quiero hablar de la esencia y no atascarme en formalidades.
Para cada uno de estos segmentos, los requisitos de seguridad, los riesgos y, en consecuencia, las soluciones serán diferentes.
Veamos cada uno de ellos por separado para conocer los problemas que puede encontrar desde el punto de vista del diseño de seguridad. Por supuesto, vuelvo a repetir que de ninguna manera este artículo pretende ser completo, lo cual no es fácil (si no imposible) de lograr en este tema verdaderamente profundo y multifacético, pero refleja mi experiencia personal.
No existe una solución perfecta (al menos no todavía). Siempre es un compromiso. Pero es importante que la decisión de utilizar un enfoque u otro se tome conscientemente, comprendiendo tanto sus ventajas como sus desventajas.
Data Center
El segmento más crítico desde el punto de vista de la seguridad.
Y, como siempre, tampoco aquí existe una solución universal. Todo depende en gran medida de los requisitos de la red.
¿Es necesario un firewall o no?
Parecería que la respuesta es obvia, pero no todo está tan claro como podría parecer. Y su elección puede verse influenciada no solo precio.
Ejemplo 1. Retrasos.
Si una baja latencia es un requisito esencial entre algunos segmentos de la red, como ocurre, por ejemplo, en el caso de un intercambio, entonces no podremos utilizar firewalls entre estos segmentos. Es difícil encontrar estudios sobre la latencia en los firewalls, pero pocos modelos de conmutadores pueden proporcionar una latencia menor o del orden de 1 mkseg, por lo que creo que si los microsegundos son importantes para usted, entonces los firewalls no son para usted.
Ejemplo 2. Rendimiento
El rendimiento de los conmutadores L3 superiores suele ser un orden de magnitud mayor que el rendimiento de los firewalls más potentes. Por lo tanto, en el caso de tráfico de alta intensidad, lo más probable es que también deba permitir que este tráfico eluda los cortafuegos.
Ejemplo 3. Confiabilidad.
Los cortafuegos, especialmente los NGFW (FW de próxima generación) modernos, son dispositivos complejos. Son mucho más complejos que los interruptores L3/L2. Proporcionan una gran cantidad de servicios y opciones de configuración, por lo que no es de extrañar que su fiabilidad sea mucho menor. Si la continuidad del servicio es fundamental para la red, entonces es posible que deba elegir qué conducirá a una mejor disponibilidad: la seguridad con un firewall o la simplicidad de una red construida sobre conmutadores (o varios tipos de estructuras) que utilizan ACL regulares.
En el caso de los ejemplos anteriores, lo más probable es que (como siempre) tenga que llegar a un acuerdo. Busque las siguientes soluciones:
- Si decide no utilizar firewalls dentro del centro de datos, debe pensar en cómo limitar al máximo el acceso alrededor del perímetro. Por ejemplo, puede abrir solo los puertos necesarios desde Internet (para el tráfico del cliente) y el acceso administrativo al centro de datos solo desde hosts de salto. En los hosts de salto, realice todas las comprobaciones necesarias (autenticación/autorización, antivirus, registro,...)
- puede utilizar una partición lógica de la red del centro de datos en segmentos, similar al esquema descrito en PSEFABRIC . En este caso, el enrutamiento debe configurarse de tal manera que el tráfico sensible al retraso o de alta intensidad vaya "dentro" de un segmento (en el caso de p002, VRF) y no atraviese el firewall. El tráfico entre diferentes segmentos seguirá atravesando el firewall. También puede utilizar la fuga de rutas entre VRF para evitar redirigir el tráfico a través del firewall.
- También puedes utilizar un firewall en modo transparente y sólo para aquellas VLAN donde estos factores (latencia/rendimiento) no sean significativos. Pero es necesario estudiar detenidamente las restricciones asociadas con el uso de este mod para cada proveedor.
- es posible que desee considerar el uso de una arquitectura de cadena de servicios. Esto permitirá que sólo el tráfico necesario pase a través del firewall. Se ve bien en teoría, pero nunca he visto esta solución en producción. Probamos la cadena de servicios para Cisco ACI/Juniper SRX/F5 LTM hace aproximadamente 3 años, pero en ese momento esta solución nos parecía "tosca".
Nivel de protección
Ahora debe responder 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, ):
- firewall con estado (predeterminado)
- firewall de aplicaciones
- prevención de amenazas (antivirus, antispyware y vulnerabilidad)
- Filtrado de URL
- filtrado de datos (filtrado de contenidos)
- bloqueo de archivos (bloqueo de tipos de archivos)
- dos protecciones
Y tampoco todo está claro. Parecería que cuanto mayor sea el nivel de protección, mejor. Pero también hay que considerar que
- Cuantas más funciones de firewall utilices, más caro te resultará (licencias, módulos adicionales)
- el uso de algunos algoritmos puede reducir significativamente el rendimiento del firewall y también aumentar los retrasos; consulte, por ejemplo
- como 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 que funcionan bastante estándar (dns, smb)
Como siempre, necesita encontrar la mejor solución para su red.
Es imposible responder definitivamente a la pregunta de qué funciones de protección pueden ser necesarias. En primer lugar, porque por supuesto depende de los datos que estés transmitiendo o almacenando y tratando de proteger. En segundo lugar, en realidad, a menudo la elección de las herramientas de seguridad es una cuestión de fe y confianza en el proveedor. No conoce los algoritmos, no sabe qué tan efectivos son y no puede probarlos por completo.
Por tanto, en segmentos críticos, una buena solución puede ser utilizar ofertas de diferentes empresas. Por ejemplo, puede habilitar el antivirus en el firewall, pero también usar protección antivirus (de otro fabricante) localmente en los hosts.
Segmentación
Estamos hablando de la segmentación lógica de la red del centro de datos. Por ejemplo, la partición en VLAN y subredes también es una segmentación lógica, pero no la consideraremos debido a su obviedad. Interesante segmentación teniendo en cuenta entidades tales como 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, ...), ...
En .
Una vez definidas las partes lógicas de su red, puede describir cómo se mueve 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 tal o cual acceso, se ve obligado a resolver este problema, y con una alta probabilidad Lo solucionará cada vez de forma diferente.
A menudo, la segmentación se basa únicamente en zonas de seguridad de FW. Entonces necesitas responder las siguientes preguntas:
- ¿Qué zonas de seguridad necesitas?
- ¿Qué nivel de protección desea aplicar a cada una de estas zonas?
- ¿Se permitirá el tráfico intrazona de forma predeterminada?
- 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
Un problema común es la insuficiencia de TCAM (Ternary Content Addressable Memory), tanto para el enrutamiento como para los accesos. En mi humilde opinión, esta es una de las cuestiones más importantes a la hora de elegir el equipo, por lo que es necesario tratar este problema con el grado de cuidado adecuado.
Ejemplo 1. Tabla de reenvío TCAM.
Consideremos cortafuegos
Vemos que el tamaño de la tabla de reenvío IPv4* = 32K
Además, este número de rutas es común para todos los VSYS.Supongamos que según tu diseño decides utilizar 4 VSYS.
Cada uno de estos VSYS está conectado vía BGP a dos MPLS PE de la nube que utilizas 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 entradas NH y, en consecuencia, 2 FIB en la tabla de reenvío. Si asumimos que este es el único firewall 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 más de 32K/(4 * 2) = 4K.Ahora, si asumimos que tenemos 2 centros de datos (con el mismo diseño), y queremos usar VLAN “estiradas” entre centros de datos (por ejemplo, para vMotion), entonces para resolver el problema de enrutamiento, debemos 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 conmutadores L3 (u otras soluciones que utilizan conmutadores L3, por ejemplo, Cisco ACI), al elegir el equipo debe prestar atención a la ACL de TCAM.
Suponga que desea controlar el acceso a las interfaces SVI de Cisco Catalyst 4500. Luego, como se puede ver en , para controlar el tráfico saliente (y entrante) en las interfaces, solo puede utilizar 4096 líneas TCAM. Lo cual al usar TCAM3 te dará alrededor de 4000 mil ACE (líneas ACL).
Si se enfrenta al problema de una TCAM insuficiente, primero, por supuesto, debe considerar la posibilidad de optimización. Entonces, en caso de un problema con el tamaño de la tabla de reenvío, es necesario considerar la posibilidad de agregar rutas. En caso de un problema con el tamaño de TCAM para los accesos, audite los accesos, elimine los registros obsoletos y superpuestos, y posiblemente revise el procedimiento para abrir accesos (se discutirá en detalle en el capítulo sobre auditoría de accesos).
Alta disponibilidad
La pregunta es: ¿debería usar HA para firewalls o instalar dos cajas independientes “en paralelo” y, si una de ellas falla, enrutar el tráfico a través de la segunda?
Parecería que la respuesta es obvia: utilice HA. La razón por la que todavía surge esta pregunta es que, lamentablemente, el 99% teórico y publicitario y varios porcentajes decimales de accesibilidad en la práctica resultan estar lejos de ser tan halagüeños. Lógicamente, HA es algo bastante complejo, y en diferentes equipos y con diferentes proveedores (no hubo excepciones), detectamos problemas, errores y detenciones del servicio.
Si usa HA, tendrá la oportunidad de desactivar nodos individuales, cambiar entre ellos sin detener el servicio, lo cual es importante, por ejemplo, al realizar actualizaciones, pero al mismo tiempo tiene una probabilidad lejos de cero de que ambos nodos se romperá al mismo tiempo, y también que la próxima actualización no se realizará tan bien como promete el proveedor (este problema se puede evitar si tiene la oportunidad de probar la actualización en equipos de laboratorio).
Si no utiliza HA, desde el punto de vista del doble fallo, sus riesgos son mucho menores (ya que tiene 2 firewalls independientes), pero como... Las sesiones no están sincronizadas, cada vez que cambie entre estos firewalls perderá tráfico. Por supuesto, puede utilizar un cortafuegos sin estado, pero entonces se pierde en gran medida el sentido de utilizar un cortafuegos.
Por lo tanto, si como resultado de la auditoría descubrió firewalls solitarios y está pensando en aumentar la confiabilidad de su red, entonces HA, por supuesto, es una de las soluciones recomendadas, pero también debe tener en cuenta las desventajas asociadas. Con este enfoque y, quizás, específicamente para su red, otra solución sería más adecuada.
Manejabilidad
En principio, HA también tiene que ver con la controlabilidad. En lugar de configurar 2 cajas por separado y lidiar con el problema de mantener las configuraciones sincronizadas, las administras como si tuvieras un solo dispositivo.
Pero tal vez tenga muchos centros de datos y muchos firewalls, entonces esta pregunta surge a un nuevo nivel. Y la pregunta no es sólo sobre la configuración, sino también sobre
- configuraciones de respaldo
- actualizaciones
- actualizaciones
- supervisión
- Inicio sesión
Y todo esto se puede solucionar mediante sistemas de gestión centralizados.
Entonces, por ejemplo, si está utilizando firewalls de Palo Alto, entonces es tal solución.
Esta historia continuará.
Fuente: habr.com