¿Por qué utilizar datos de flujo para el monitoreo?

En el punto en el que nos encontramos en la curva creciente de la evolución tecnológica y, en consecuencia, de las amenazas digitales, crece con la misma intensidad la necesidad de visibilidad en relación con los datos que atraviesan las infraestructuras de diversos tipos de organizaciones. La demanda de esta visibilidad puede tropezar con varios aspectos técnicos, que van desde la necesidad de buenas estrategias de posicionamiento de los equipos de captura hasta la necesidad de grandes cantidades de hardware para el almacenamiento y procesamiento de los datos capturados. Otro punto al que hay que prestar atención es el valor que tienen los datos capturados, es decir, es importante saber si lo que se está almacenando aporta realmente la visibilidad y la capacidad de supervisión deseadas.

A partir de estas ideas, surgen naturalmente algunas preguntas, y en los círculos de debate de los Blue Teamers, las preguntas que siempre están presentes son: ¿qué debo captar? ¿Capturar todo el tráfico durante menos tiempo (debido a las limitaciones del hardware)? ¿Capturar sólo los metadatos y realizar correlaciones con los registros disponibles?. Un buen tópico que respondería estas preguntas sería: hay que trabajar con equilibrio, porque ambos enfoques aportan visibilidad y tienen ventajas e inconvenientes.

En un principio se puede pensar que el escenario ideal es tener el tráfico completamente capturado para dar soporte a las actividades de respuesta a incidentes, caza de amenazas, SOC, CSIRT, etc., ya que a través de la captura completa es posible reconstruir la comunicación entre cliente y servidor y tener una visión real de lo sucedido, pero, aunque esto pueda parecer realmente el mejor de los mundos para las investigaciones, el histórico disponible no irá más allá de unos pocos días o semanas, debido a la gran cantidad de recursos necesarios. Esto se convierte en un problema cuando necesitamos investigar algo que ocurrió en un periodo anterior a la capacidad histórica, sin tener en cuenta los problemas que pueden surgir al tratar con tráfico cifrado. Una alternativa equilibrada es obtener metadatos de este tráfico integrados con logs, que pueden cubrir buena parte de la organización en cuanto a estadísticas sobre las conexiones realizadas entre usuarios de la infraestructura.

En este contexto, el objetivo de este artículo es discutir la segunda opción mencionada en el párrafo anterior, que es un enfoque interesante para la captura completa del tráfico y es capaz de ofrecer una buena visibilidad sobre temas como: quién se comunica con quién, cuándo se produjo esta comunicación, durante cuánto tiempo y con qué frecuencia. Se trata de capturar flujos de datos, exportarlos y crear métricas de monitorización basadas en esos flujos, a través de protocolos como el que Cisco denominó originalmente NetFlow, y que posteriormente fue "traducido" a una versión opensource que se denominó IPFIX. Este tipo de enfoque puede ser muy beneficioso para la supervisión continua de una organización, ya que permite mantener una trazabilidad histórica mucho mayor de las comunicaciones, simplemente porque requiere menos recursos de almacenamiento en comparación con la captura completa del tráfico.

Este es el primero de una serie de 2 posts sobre este tema. En él definiremos algunos conceptos y reflexionaremos sobre estrategias de vigilancia y, en otro momento, abordaremos herramientas, técnicas y demostraciones prácticas.

¿Qué es Netflow/Dataflow/Flow?

Buscando la información directamente de la fuente, el RFC 7011 de 2013 que especifica el protocolo IPFIX, define el flujo de datos, o simplemente flujo, como lo siguiente: "un conjunto de paquetes IP que pasan a través de un punto de observación dentro de la red durante un cierto intervalo de tiempo, teniendo todos los paquetes pertenecientes a un flujo particular un conjunto de propiedades en común."

Las propiedades de los flujos, también llamadas flow-keys son cada uno de los campos que: (i) pertenecen a la propia cabecera del paquete; (ii) son propiedades del paquete, como el tamaño en bytes; (iii) se derivan de la actividad de Manejo de Paquetes, como el Número de Sistema Autónomo (ASN).

En resumen, cada flujo es un conjunto de paquetes agregados, es decir, los paquetes no se consideran individualmente, como en un enfoque de captura completa. Es como si las secuencias de paquetes tuvieran una especie de firma que se utiliza para unir los distintos elementos de una comunicación en un único flujo. Los flujos contienen valiosos metadatos sobre las comunicaciones y deben ser exportados por algún equipo por el que pasa el tráfico, denominado "exportador" (normalmente cortafuegos, conmutadores y enrutadores), y recopilados para su posterior análisis.

También de acuerdo con la RFC, la recopilación de este flujo sirve tanto como para fines administrativos como para cualquier otro, como los mencionados al principio de esta publicación, por ejemplo: la visibilidad, pero también la resolución de problemas, la detección de amenazas, la supervisión del rendimiento y, en consecuencia, ¡la Seguridad!

Metadatos

Como se ha mencionado anteriormente, un exportador de flujos identifica un flujo como un conjunto de paquetes con características comunes pertenecientes a una comunicación determinada. Estas características contenidas en los paquetes son al menos: puerto de la interfaz de entrada, direcciones IP de origen y destino, puertos de origen y destino, protocolo y tipo de servicio. Curiosamente, estos también pueden considerarse como los principales atributos de la comunicación que serán útiles para análisis posteriores, recordando siempre que se trata de metadatos, es decir: el contenido de los paquetes no está disponible. Hablaremos de ello más adelante.

Exportar

Los procesos de captura y análisis de flujos dependen básicamente de 3 componentes: un equipo "exportador"; un equipo "recolector"; y, por último, un equipo/software analizador de flujos.

Un flujo se exporta cuando cumple ciertos requisitos: (i) el flujo se vuelve inactivo, es decir, no se recibe ningún paquete nuevo relacionado con este flujo hasta que alcanza el tiempo de espera (que es configurable); (ii) el flujo sigue procesando paquetes, pero alcanza el tiempo de espera establecido; (iii) algo en la comunicación indica que se ha terminado, por ejemplo, banderas TCP de tipo FIN o RST.

Después, los flujos se transmiten al colector, que suele ser un equipo centralizador de varios exportadores. Esta transmisión se realiza normalmente a través de UDP, pero los equipos más modernos son capaces de transmitir a través de TCP para añadir cierto control, lo que puede traer algún impacto en relación con el rendimiento del dispositivo.

El recopilador también almacena estos flujos para su posterior análisis mediante software, analizador dedicado, SIEM, etc. Al final de la exportación, lo que tenemos que analizar son los conjuntos de metadatos de la comunicación, que suelen incluir: direcciones y puertos de origen y destino (cuando se trata de comunicaciones TCP o UDP), tipo de servicio, marcas de tiempo de inicio y fin de la comunicación, información sobre las interfaces de entrada y salida del dispositivo, banderas TCP y protocolo encapsulado (tipo de datos que se transmiten, si son TCP o UDP), información sobre protocolos de enrutamiento como BGP (siguiente salto, AS de origen, AS de destino...). La siguiente tabla muestra los campos presentes en la cabecera del protocolo netflow V5.

¿Por qué son útiles los datos de flujo?

Los datos de flujo son un aliado importante porque muestran, a bajo coste, un resumen estadístico de las comunicaciones que pasan por los exportadores. Por eso es necesaria una buena estrategia para elegir buenas posiciones de exportación, es decir, seleccionar los equipos con mayor potencial de visibilidad (cortafuegos, conmutadores, routers). Dependiendo de la herramienta elegida para realizar el análisis, (y hay varias, tanto de código abierto como comerciales) es posible ver cosas como

  • Estadísticas de tráfico divididas por aplicación; protocolo; dominio; IP de origen y destino y puerto;
  • Resumen estadístico (Top N) de direcciones, comunicaciones e incluso Sistemas Autónomos (AS);
  • Resumen estadístico de la información descrita anteriormente con enriquecimiento por herramientas de análisis de flujo¸ o por SIEM, como Geolocalización y otras

Este tipo de información ayuda a comprender cuestiones sobre la infraestructura de la organización. Es posible averiguar si se están ejecutando aplicaciones prohibidas; encontrar cuellos de botella o equipos que funcionan mal; descubrir anomalías de consumo excesivo o exagerado de ancho de banda por parte de algunos equipos; entender conexiones extrañas a direcciones de países con altos índices de ciberataques, así como AS con mala reputación; comunicación con servidores de comando y control, entre otras cosas.

De nuevo: los datos de flujo no agregan el contenido de las comunicaciones. Teniendo esto en cuenta, un analista que sólo disponga de esta información deberá asociar siempre algunos factores para obtener inteligencia a partir de este tipo de metadatos. La misma observación se aplica a los datos cifrados, incluso cuando el tráfico se captura por completo. Esta asociación de factores puede hacerse pensando:

  1.  Sobre la direccionalidad del tráfico - saber cuál debe ser la dirección típica de la conversación entre cliente y servidor, por ejemplo: ¿es legítimo que un servidor X en la red DMZ acceda a cualquier servicio en Internet en el puerto 1234?
  2.  Sobre el tráfico esperado asociado al protocolo implicado en la comunicación - conociendo bien cómo funcionan determinados protocolos, es posible hacerse una idea de si el tráfico debería tener una duración mayor o menor, una cantidad de datos mayor o menor, y a partir de ahí encontrar anomalías;
  3.  En el análisis basado en el tiempo: para identificar picos de tráfico que puedan indicar transferencias de archivos, o comunicaciones extrañas que puedan referirse a respuestas a comandos;

Asociando estos factores es posible crear líneas de base de monitorización para, a través de las estadísticas puestas a disposición por los flujos, saber, por ejemplo, si una conexión SSH (generalmente puerto 22/tcp) que dura demasiado poco, o si una conexión HTTP (puerto 80/tcp) que dura demasiado tiempo, son accesos legítimos o posibles ataques. La tabla siguiente muestra ejemplos de observaciones que pueden hacerse asociando los factores descritos.


Los datos de flujo también pueden ser una buena alternativa para el tráfico cifrado, cuando la organización no dispone de inspección TLS/SSL: esto resulta útil porque, si no existe la capacidad de inspeccionar el tráfico cifrado, una captura completa de este tipo de tráfico se convierte en un enorme desperdicio de recursos, sobre todo si hablamos de almacenamiento.

Estrategias de captura


En el marco anterior, hay varios lugares donde se pueden recoger datos. Sinceramente, cualquier punto de agregación de la red es un gran candidato para capturar los flujos completos o sólo los flujos. Lo primero que hay que tener en cuenta es que existen distintos niveles de criticidad y valor de los datos.

Comprendiendose, junto con los volúmenes de datos producidos en cada segmento, la organización puede planificar una solución de captura.

Como sugerencia, los posibles puntos de agregación en el escenario anterior se diferencian por colores.

  • En color verde, puntos de exportación de flujos;
  • En rojo, los puntos en los que puede ser necesaria la captura total,
  • En Amarillo, puntos que contienen mucha información y son candidatos a la exportación de flujos, pero con menor prioridad.

Si aún se encuentra en la fase de planificación de la captura de datos, o si tiene previsto realizar una reestructuración del proyecto de captura en su infraestructura, los pasos siguientes pueden dar una idea de lo que debe hacer. 1: Identificar los datos críticos

Captar todo el tráfico no es ni mucho menos una estrategia barata para la mayoría de las organizaciones (si puede permitírselo, ¡siéntase un privilegiado!). El primer paso que podemos dar es identificar cuáles son los datos más críticos de la organización para definir la mejor estrategia de visibilidad de esos datos. Para esos datos y los activos que los almacenan o en los que viajan, es probable que necesite una captura completa.

2: Conozca su red

Parece obvio, pero hay que decirlo: muchas organizaciones no tienen ni siquiera un conocimiento de alto nivel de sus sistemas y equipos (por ejemplo, S.O. e IP de todos los activos). Una buena estrategia podría ser empezar por trazar las rutas de los datos críticos a Internet y a los sistemas de escritorio de los administradores que controlan esos datos.

3: Identificar cuellos de botella y puntos críticos de la red

Si conoce bien la red, podrá identificar los puntos en los que confluyen varias subredes o VLAN y plantearse el nivel óptimo de captura de datos. A continuación, identifique las redes críticas que operan switches y routers y verifique sus capacidades de captura. Estos dispositivos están entre el usuario y los datos e Internet (si los sistemas pueden conectarse a Internet).

4: Identificar los centros de gravedad críticos

Encontrar en el entorno lugares con altas concentraciones de un determinado objeto: ¡datos críticos! Al definir estos centros, la organización reflexiona sobre lo que es realmente importante en términos de protección. Sin embargo, los centros de gravedad críticos incluyen cosas diferentes, según el tipo de empresa.

He aquí algunos ejemplos:

  • Repositorios de código fuente (empresas de software)
  • Sistemas contables (sector financiero y empresas que cotizan en bolsa)
  • Sistemas de administradores de sistemas (suelen contener planos, contraseñas, diagramas y software)
  • Aplicaciones web desarrolladas internamente utilizando credenciales (AD, LDAP)
  • Servidores DNS

5: Planificar los exportadores de flujos y los puntos de captura total

En lugares con gran volumen de tráfico, como las pasarelas de Internet, es más interesante captar los flujos de datos. En los cuellos de botella de datos críticos y en los dispositivos de red críticos, puede ser interesante aplicar ambos enfoques: tanto los flujos como la captura completa.

6: Verificar el cumplimiento de los requisitos

Los datos de flujo pueden ayudar a cumplir los requisitos de conformidad de los registros, sin embargo es necesario comprobar con la norma si son suficientes y en qué puntos se pueden utilizar estos metadatos para cumplir algún requisito.

Conclusión

A pesar de todas las ventajas, la captura de flujos no es una bala de plata y no resolverá todos los problemas de supervisión de la organización, además de traer consigo algunos inconvenientes, como:

  • Se requieren análisis y asociaciones para averiguar los usuarios implicados en ese tráfico para poder identificar a los equipos;
  • Los NATs pueden hacer que la captura sea inconsistente, ya que el flujo se registra en el exportador, por lo que es necesario tenerlo en cuenta a la hora de configurarlo;
  • No es posible ver el contenido de la comunicación a través de los flujos.

En este sentido, siempre es importante equilibrar, variar los planteamientos y considerar las distintas posibilidades para mejorar la seguridad y la gestión en general. Los datos de flujo son uno más de los grandes aliados para la protección de las infraestructuras.

Terminando el razonamiento, los flujos son potentes para monitorizar cualquier red y proporcionan una gran visibilidad de la infraestructura a bajo coste, precisamente porque la mayoría de las organizaciones ya disponen de activos capaces de exportarlos, tanto en entornos predominantemente on-premise como en entornos cloud o híbridos: proveedores como AWS y GCP ponen los datos de flujo a disposición del cliente. A menudo, lo que falta es simplemente habilitar la exportación de los flujos y apuntar a un colector/analizador. En caso de que la organización no disponga de recopiladores/analizadores, crear un marco para el análisis es relativamente sencillo y barato. Rara vez es necesario comprar hardware adicional.