Este artículo es el tercero en una serie titulada «Cómo tomar el control de la infraestructura de red». El contenido de todos los artículos de la serie y los enlaces se pueden encontrar aquí.

No tiene sentido hablar de la eliminación completa de riesgos de seguridad. En principio, no podemos reducirlos a cero. También es importante entender que, al intentar hacer la red cada vez más segura, nuestras soluciones se vuelven cada vez más costosas. Es necesario encontrar un compromiso razonable para su red entre el precio, la complejidad y la seguridad.

Por supuesto, el diseño de la seguridad está orgánicamente integrado en la arquitectura general y las soluciones de seguridad utilizadas influyen en la escalabilidad, fiabilidad, gestionabilidad, … de la infraestructura de red, lo cual también debe ser considerado.

Sin embargo, debo recordar que ahora no estamos hablando de construir una red. De acuerdo con nuestras condiciones iniciales ya tenemos el diseño seleccionado, el equipo elegido y la infraestructura creada, y en esta etapa debemos, en la medida de lo posible, «vivir» y encontrar soluciones en el contexto del enfoque elegido previamente.

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

Auditoría de seguridad de red

Si en su organización se han implementado procesos ISO 27k, la auditoría de seguridad y los cambios en la red deben integrarse armoniosamente en los procesos generales dentro de este enfoque. Pero estas normas no se refieren específicamente a soluciones concretas, no a configuraciones, no a diseños… No hay consejos inequívocos, no hay normas que dicten en detalle cómo debe ser su red, en eso radica la complejidad y la belleza de esta tarea.

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

auditoría de configuración del equipo (hardening)
auditoría del diseño de seguridad
auditoría de accesos
auditoría de procesos

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

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. IMHO, es una buena demostración de la ley de Pareto (el 20 % de los esfuerzos da el 80 % de los resultados, mientras que el 80 % restante de los esfuerzos solo da el 20 % del resultado).

La esencia es que normalmente tenemos recomendaciones de proveedores sobre las «mejores prácticas» de seguridad al configurar el equipo. Esto se llama “hardening”.

También se puede encontrar un cuestionario (o elaborarlo uno mismo) basado en estas recomendaciones, que te ayudará a determinar qué tan bien la configuración de tu hardware se alinea con estas "mejores prácticas" y, según los resultados, realizar cambios en tu red. Esto te permitirá reducir significativamente los riesgos de seguridad de manera bastante fácil y prácticamente sin costos.

Algunos ejemplos para ciertos sistemas operativos de Cisco.
Fortalecimiento de la Configuración de Cisco IOS
Fortalecimiento de la Configuración de Cisco IOS-XR
Fortalecimiento de la Configuración de Cisco NX-OS
Lista de Verificación de Seguridad Baseline de Cisco
A partir de estos documentos, se puede crear una lista de requisitos de configuración para cada tipo de hardware. Por ejemplo, para el Cisco N7K VDC, estos requisitos podrían ser así.

De este modo, se pueden crear archivos de configuración para diferentes tipos de hardware activo en tu infraestructura de red. Luego, manualmente o utilizando automatización, puedes "cargar" estos archivos de configuración. Cómo automatizar este proceso se tratará en otra serie de artículos dedicados a la orquestación y automatización.

Auditoría del diseño de seguridad

Normalmente, en la red de una empresa (enterprise network), de alguna manera, están presentes los siguientes segmentos:

DC (Servicios públicos DMZ y centro de datos Intranet)
Acceso a Internet
VPN de acceso remoto
WAN edge
Sucursal
Campus (Oficina)
Core

Los nombres se tomaron de modelo: modelos, pero por supuesto no es necesario atenerse a esos nombres y a este modelo. Al final, es importante hablar de la esencia y no quedar atrapado en formalidades.

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

Analicemos cada uno de ellos por separado para identificar problemas que puedas enfrentar desde el punto de vista del diseño de seguridad. Por supuesto, reitero nuevamente que este artículo no pretende ser exhaustivo, alcanzar lo cual en este tema realmente profundo y multifacético es complicado (si es que es posible), pero refleja mi experiencia personal.

No existe una solución perfecta (al menos no en este momento). Siempre es un compromiso. Pero es importante que la decisión de aplicar un enfoque u otro se tome de manera consciente, entendiendo tanto sus ventajas como sus desventajas.

Centro de Datos

El segmento más crítico desde el punto de vista de la seguridad.
Y, como de costumbre, aquí tampoco hay una solución universal. Todo depende en gran medida de los requisitos de la red.

¿Se necesita un firewall?

Parece que la respuesta es obvia, pero no es tan sencilla como podría parecer. Y tu elección puede verse influenciada no solo por precio.

Ejemplo 1. Retrasos.
Si entre algunos segmentos de la red se requiere una baja latencia, lo cual es cierto, por ejemplo, en el caso de una bolsa de valores, entonces no podremos usar cortafuegos entre esos segmentos. Es difícil encontrar investigaciones sobre la latencia en cortafuegos, pero solo unos pocos modelos de conmutadores pueden proporcionar latencias de menos de 1 mksec, así que creo que si los microsegundos son importantes para ti, los cortafuegos no son la opción adecuada.

Ejemplo 2. Rendimiento.
El ancho de banda de los mejores conmutadores L3 suele ser significativamente superior al de los cortafuegos más eficientes. Por lo tanto, en el caso de tráfico de alta intensidad, probablemente tendrás que redirigir ese tráfico alrededor de los cortafuegos.

Ejemplo 3. Confiabilidad.
Los cortafuegos, especialmente los NGFW modernos (Next-Generation FW), son dispositivos complejos. Son significativamente más complejos que los conmutadores L3/L2. Ofrecen una gran cantidad de servicios y opciones de configuración, por lo que no es sorprendente que su fiabilidad sea considerablemente menor. Si la continuidad del servicio es crítica para la red, es posible que debas elegir entre lo que proporcionará mejor disponibilidad: la protección con un cortafuegos o la simplicidad de una red construida sobre conmutadores (o diversos tipos de fábricas) utilizando ACL comunes.

En los ejemplos mencionados anteriormente, seguramente (como es habitual) tendrás que encontrar un compromiso. Considera las siguientes soluciones:

si decides no usar cortafuegos dentro del centro de datos, debes pensar en cómo limitar al máximo los accesos por el perímetro. Por ejemplo, puedes abrir solo los puertos necesarios desde Internet (para el tráfico de clientes) y los accesos administrativos al centro de datos solo desde hosts de salto. En los hosts de salto, realiza toda la verificación necesaria (autenticación/autorización, antivirus, registro, ...)
puedes utilizar la segmentación lógica de la red del centro de datos en segmentos, similar al esquema descrito en PSEFABRIC ejemplo p002La configuración de enrutamiento debe estar diseñada de manera que el tráfico sensible a la latencia o de alta intensidad circule "dentro" de un solo segmento (en el caso de p002, del VRF) y no pase a través del firewall. Sin embargo, el tráfico entre diferentes segmentos seguirá pasando a través del firewall. También se puede utilizar el route leaking entre VRFs para evitar el redireccionamiento del tráfico a través del firewall.
También se puede usar el firewall en modo transparente y solo para aquellas VLAN donde estos factores (latencia/rendimiento) no son significativos. Pero es importante estudiar atentamente las limitaciones asociadas con el uso de este modo para cada proveedor.
Puede considerar aplicar una arquitectura de service chain. Esto permitirá dirigir solo el tráfico necesario a través del firewall. Teóricamente suena bien, pero nunca he visto esta solución en producción. Probatamos service chain para Cisco ACI/Juniper SRX/F5 LTM hace aproximadamente 3 años, pero en ese momento esta solución nos pareció "inmadura".

Nivel de protección

Ahora es necesario responder a la pregunta, qué herramientas desea aplicar para la filtración de tráfico. Aquí hay algunas de las capacidades que generalmente se encuentran en un NGFW (por ejemplo, aquí):

firewalling stateful (por defecto)
firewalling de aplicaciones
prevención de amenazas (antivirus, anti-spyware y vulnerabilidades)
filtrado de URL
filtrado de datos (filtrado de contenido)
bloqueo de archivos (bloqueo de tipos de archivos)
protección dos

Y tampoco es todo tan claro. Aparentemente, cuanto mayor es el nivel de protección, mejor. Pero también necesita considerar que

cuantas más de las funciones mencionadas del firewall use, naturalmente será más caro (licencias, módulos adicionales).
El uso de ciertos algoritmos puede reducir significativamente el ancho de banda del firewall y aumentar la latencia, véase por ejemplo aquí
Como cualquier solución compleja, el uso de métodos de protección complicados puede reducir la fiabilidad de su solución; por ejemplo, al utilizar firewall de aplicaciones, me he encontrado con el bloqueo de algunas aplicaciones que funcionan de manera bastante estándar (DNS, SMB).

Como siempre, debe encontrar la solución óptima para su red.

No se puede responder de manera definitiva a la pregunta de qué funciones de protección pueden ser necesarias. En primer lugar, porque depende de los datos que transmite o almacena y está intentando proteger. En segundo lugar, en realidad, a menudo la elección de los medios de protección es una cuestión de fe y confianza en el proveedor. No conoce los algoritmos, no sabe cuán efectivos son y no puede probarlos completamente.

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 el firewall, pero también usar protección antivirus (de otro fabricante) localmente en los hosts.

Segmentación

Se trata de la segmentación lógica de la red del centro de datos. Por ejemplo, dividir en VLAN y subredes también es segmentación lógica, pero no la consideraremos por su obviedad. Nos interesa la segmentación teniendo en cuenta entidades como zonas de seguridad FW, VRF (y sus análogos aplicables a diferentes proveedores), dispositivos lógicos (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Un ejemplo de tal segmentación lógica y un diseño actualmente demandado de centro de datos se presenta en p002 del proyecto PSEFABRIC.

Al definir las partes lógicas de su red, puede describir cómo se mueve el tráfico entre diferentes segmentos, en qué dispositivos se realizará la filtración y con qué herramientas.

Si su red carece de una clara división lógica y no se han formalizado las reglas para la aplicación de políticas de seguridad para diferentes flujos de datos, entonces significa que al abrir un acceso determinado deberá enfrentar esta tarea, y con alta probabilidad lo resolverá de manera diferente cada vez.

A menudo, la segmentación se basa únicamente en zonas de seguridad FW. Entonces, necesita responder las siguientes preguntas:

¿Qué zonas de seguridad necesita?
¿Qué nivel de protección desea aplicar a cada una de estas zonas?
¿Se permitirá el tráfico intra-zona por defecto?
Si no, ¿qué políticas de filtración de tráfico se aplicarán dentro de cada una de las zonas?
¿Qué políticas de filtración de tráfico se aplicarán para cada par de zonas (source/destination)?

TCAM

A menudo se presenta el problema de la insuficiencia de TCAM (Ternary Content Addressable Memory), tanto para el enrutamiento como para los accesos. IMHO, esta es una de las cuestiones más importantes al elegir hardware, por lo que se debe tratar este asunto con el debido cuidado.

Ejemplo 1. TCAM de tabla de reenvío.
Examinemos Palo Alto 7k firewall.
Vemos que el tamaño de la tabla de reenvío IPv4* = 32K
Este número de rutas es total para todos los VSYS.
Supongamos que, de acuerdo con su diseño, decidió utilizar 4 VSYS.
Cada uno de estos VSYS está conectado a dos PE de la nube MPLS mediante BGP, que utilizas como BB. De esta manera, 4 VSYS intercambian todas las rutas específicas entre sí y tienen una tabla de reenvío con conjuntos de rutas aproximadamente iguales (pero con NH diferentes). Como cada VSYS tiene 2 sesiones BGP (con la misma configuración), cada ruta obtenida a través de MPLS tiene 2 NH y, por consiguiente, 2 entradas 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 VLANs "extendidas" entre los centros de datos (por ejemplo, para vMotion), para resolver el problema de enrutamiento, debemos utilizar rutas de host. Pero esto significa que en 2 centros de datos tendremos no más de 4096 posibles hosts y, por supuesto, esto puede ser insuficiente.

Ejemplo 2. ACL TCAM.
Si planeas filtrar tráfico en conmutadores L3 (u otras soluciones que utilizan conmutadores L3, como Cisco ACI), al elegir el hardware debes prestar atención a la ACL TCAM.
Supongamos que deseas controlar los accesos en las interfaces SVI de Cisco Catalyst 4500. Entonces, como se puede ver en de este artículo, para controlar el tráfico saliente (así como el entrante) en las interfaces, solo puedes utilizar 4096 líneas de TCAM. Lo que, al utilizar TCAM3, te dará alrededor de 4000 ACE (líneas ACL).

En caso de que enfrentes el problema de insuficiencia de TCAM, primero, por supuesto, debes considerar la posibilidad de optimización. Así, en caso de un problema con el tamaño de la tabla de reenvío, debes considerar la posibilidad de agregar rutas. En el caso de un problema con el tamaño de TCAM para accesos, se debe hacer una auditoría de accesos, eliminar entradas obsoletas y superpuestas, así como, posiblemente, revisar el procedimiento de apertura de accesos (se analizará en detalle en el capítulo dedicado a la auditoría de accesos).

Alta Disponibilidad

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

A primera vista, la respuesta es obvia: utilizar HA. La razón por la que esta pregunta surge es que, desafortunadamente, los teóricos y los publicitarios afirman porcentajes de disponibilidad cercanos al 99,9%, pero en la práctica, esto no se traduce en una experiencia tan optimista. HA es un asunto lógicamente complejo, y hemos encontrado problemas y fallos, así como interrupciones del servicio en distintos equipos y con diferentes proveedores.

En caso de utilizar HA, obtendrás la posibilidad de apagar nodos individuales y cambiar entre ellos sin detener el servicio, lo cual es importante, por ejemplo, durante las actualizaciones. Sin embargo, existe una probabilidad no despreciable de que ambos nodos se dañen simultáneamente, además de que la siguiente actualización puede no ser tan fluida como promete el proveedor (este problema se puede evitar si tienes la capacidad de probar la actualización en equipos de laboratorio).

Si no utilizas HA, en términos de fallos dobles, tus riesgos son significativamente más bajos (ya que cuentas con 2 firewalls independientes), pero como las sesiones no están sincronizadas, cada vez que realices un cambio entre estos firewalls, perderás tráfico. Claro, puedes usar firewalls sin estado, pero entonces el sentido de usar un firewall se pierde en gran medida.

Por lo tanto, si como resultado de una auditoría has encontrado firewalls aislados y estás considerando incrementar la fiabilidad de tu red, entonces HA es, sin duda, una de las soluciones recomendadas. Sin embargo, debes tener en cuenta también las desventajas asociadas a este enfoque y, tal vez, otra solución sea más adecuada para tu red.

Facilidad de gestión

En esencia, HA también se relaciona con la gestión. En vez de configurar 2 cajas por separado y resolver el problema de la sincronización de configuraciones, las gestionas en gran medida como si tuvieras un único dispositivo.

Pero, quizás, tengas muchos centros de datos y muchos firewalls, entonces esta cuestión adquiere un nuevo nivel. Y la cuestión no es solo sobre la configuración, sino también sobre