Análisis de tráfico de red: del análisis paquete a paquete al análisis de flujos

Análisis de tráfico de red como base para la monitorización

La monitorización siempre se ha servido tanto de la administración de redes como del análisis de tráfico de red. Ambas disciplinas otorgan vías para obtener data que permite inferir información sobre el estado general de la plataforma.

Es fácil entender que frente a, por ejemplo, un problema de rendimiento de una aplicación, deseemos poder observar y evaluar el tráfico generado, y esto es justo lo que permite el análisis de tráfico de red.

Este primer impulso natural de observar el tráfico en realidad se ve justificado, ya que el análisis de tráfico ha probado ser útil para identificar problemas como errores de configuración, deterioro en rendimiento de servidores, problemas de latencia en algunos de los componentes de red y otras tantas condiciones de error.

---

---

Dos formas de hacer análisis de tráfico de red

Existen al menos dos formas de realizar análisis de tráfico de red: el análisis de paquetes y el análisis del flujo de tráfico de red.

En ambas técnicas, por supuesto, el objetivo es el mismo: obtener información sobre el tráfico de red que pueda ser presentada en una interfaz que facilite su evaluación.

Las diferencias entre una y otra forma se concentran en la metodología utilizada.

El análisis de paquetes otorga la posibilidad de evaluar el tráfico de red paquete a paquete, en tanto que el análisis de flujo pretende recabar metadata o información sobre el tráfico y a través de ella facilitar un análisis estadístico.

Tomemos el siguiente diagrama como guía para seguir adelante:

Descripción: Diagrama con la relación entre monitorización y el análisis de tráfico de red y la administración de redes.

Sobre el análisis de paquetes

En el análisis de paquetes se parte de la aplicación de técnicas de capturas, como la configuración de puertos SPAN (Switch Port Analyzer) o la instalación de equipos como TAPs (Terminal Network TAPs) para acceder al tráfico de red.

En realidad los dispositivos TAPs se desarrollaron para cubrir ciertas deficiencias que se presentan al momento de aplicar puertos SPAN, tales como la dependencia de los recursos de procesamiento del switch donde se configuran y la delicada relación entre la cantidad de tráfico que pretendemos capturar y la capacidad misma del puerto SPAN.

Al lector interesado en precisar las conveniencias de los puertos SPAN y los equipos TAPs de red le recomendamos el artículo publicado en este mismo blog donde se ahonda en la captura de paquetes utilizando TAPs de red.

Resuelto el tema de la captura se plantean dos temas de mucha importancia:

• El almacenaje del tráfico: el punto es si podemos hacer análisis en tiempo real o en tiempo diferido y el costo en almacenaje que el análisis supone.
• La selección de los paquetes que deseamos evaluar: para atender a esta cuestión las herramientas que implementan análisis de paquetes suelen ofrecer muchas facilidades que permiten escoger y seleccionar los paquetes que deseamos evaluar.

Las variables de escogencia suelen ser muchas, desde direcciones IP origen y destino hasta la presencia de cierta secuencia de bytes en los paquetes.

Otro punto importante de mencionar en cuanto al análisis de paquetes es el correspondiente al tratamiento que se le otorga a la porción de data de los paquetes.

El análisis tradicional de paquetes se mantiene en la revisión de los encabezados, dejando sin visualización la porción correspondiente a la data.

Este acercamiento tiene tres justificaciones:

• Con la evaluación de los encabezados es mucha la información que se puede inferir.
• Obviando la porción de data se mantienen a raya los costes de almacenamiento.
• La porción de data suele poseer información sensible para los usuarios y para la organización, por lo que su evaluación puede llevarnos a violentar normas de seguridad y protección de datos.

Sin embargo, por años el tráfico de Internet ha sido evaluado bajo los preceptos de una técnica conocida como inspección profunda de paquetes.

La inspección profunda de paquetes contempla la revisión y evaluación de los encabezados y de la porción de data de los paquetes.

Recientemente, su aplicación ha trascendido el ámbito del tráfico de Internet y ha pasado al tráfico empresarial, por supuesto con muchas controversias sobre los posibles riesgos para la privacidad de los datos.

Si el lector está interesado en conocer con mayor detalle las implicaciones de la inspección profunda de paquetes les recomendamos nuestro artículo sobre este tema, publicado hace pocos meses en este mismo blog.

Sobre el análisis de flujo de tráfico

El análisis de flujo de tráfico propone lo siguiente:

• Evaluar el tráfico de red en función de características comunes. Es decir, se parte de una abstracción -llamada “flujo de tráfico”- que corresponde a todo el tráfico que comparte ciertas características comunes y se mueve desde un host de red a otro.Por ejemplo, si consideramos todo el tráfico que pueden compartir una estación y un servidor, se considerará como flujo aquel tráfico que hace parte de una misma conversación o tiene el mismo objetivo.
• No se almacena el flujo como tal, solo la metadata. La idea es utilizar los dispositivos involucrados en el pase del tráfico de red para, sin almacenar los paquetes que conforman el flujo de tráfico, generar información sobre el flujo de tráfico o su metadata.

Esta metadata luego deberá ser almacenada y reprocesada para finalmente ser mostrada con la idea de permitir el análisis, sea cual sea: monitorización, seguridad, forense, facturación, etc.

El análisis de flujo de tráfico se ha sedimentado sobre la base de un grupo de protocolos que permiten implementar los procesos de generación, transporte, almacenaje y preprocesamiento de la metadata.

Es importante aclarar que estos protocolos no especifican cómo debe hacerse el análisis; eso lo dejan a las herramientas que utilizan la metadata para alcanzar sus objetivos.

Hay dos protocolos que representan dos aproximaciones distintas a la implementación del análisis de flujo de tráfico: NetFlow y sFlow.

NetFlow

NetFlow es un protocolo desarrollado por Cisco que se ha convertido en un estándar de facto para la implementación de análisis de flujo de tráfico IP. Además de Cisco, muchas empresas, tanto fabricantes de dispositivos de red como desarrolladoras de soluciones, incluyen soporte a este protocolo.

NetFlow introduce una arquitectura que tiene como componentes los siguientes:

Descripción: Arquitectura NetFlow

• Exportador: Son los encargados de recabar la metadata de los flujos de tráfico IP entrante y saliente de algún dispositivo de red.De hecho, los exportadores son piezas de software que están contenidas en dispositivos como switches y enrutadores.

  Los exportadores utilizan un repositorio llamado NetFlow caché para almacenar la información sobre los flujos que van capturando a medida que el tráfico entra y sale a través del dispositivo switch o enrutador.

• Colectores: Encargados de recibir la metadata de los exportadores, almacenarla y preprocesarla.
• Analizador: Este es el elemento encargado de permitir el análisis sobre la información contenida en los colectores.

En la práctica las funciones de colector y analizador regularmente son suplidas por las aplicaciones que utilizan NetFlow.

NetFlow ha evolucionado con el tiempo, desde la versión 5 hasta su versión 9; se han incluido protocolos como IPv6 o tecnologías como VLANs, MPLS y BGP.

Por otro lado, de la versión 9 de NetFlow se derivó otro protocolo conocido como IPFIX (IP Flow Information Export), que pretende regular la forma en que la información es enviada desde los Exportadores a los Colectores.

Son varias las mejoras que IPFIX introduce; por un lado tenemos el soporte a campos de longitud variable y la posibilidad de incluir data normalmente asociada con la administración de redes (SNMP y Syslog).

Al lector interesado en conocer un poco más acerca de las aplicaciones de NetFlow le recomendamos leer el artículo sobre NetFlow publicado en este mismo blog.

sFlow

A partir de NetFlow otras casas fabricantes han desarrollado su propio protocolo de análisis de flujo; en general todos siguen la misma arquitectura de Exportadores – Colectores – Analizadores y se mantienen en el entorno del tráfico IP.

A continuación presentamos una lista de los protocolos derivados de NetFlow:

	Protocolo	Casa Fabricante
	NetFlow	Cisco
	jFlow	Juniper
	rFlow	Ericcson
	NetStream	Huawei

Tal como decíamos arriba, la mayoría son aproximaciones a NetFlow sin demasiadas variaciones. Sin embargo, algo distinto pasa con el protocolo sFlow.

SFlow (Sampling Flow), que fue desarrollado por InMon Corporation y publicado en el RFC 3176, introduce un cambio digno de mención.

SFlow no trabaja con la abstracción de la que hemos hablado hasta ahora, los flujos, y se concentra en la actividad de recabar muestras.

Al utilizar sFlow se define el radio de muestreo ¨n¨; así pues, cada n paquetes el exportador sFlow tomará una muestra de los paquetes considerando todos los niveles, desde el 2 al 7, en el modelo OSI y todos los protocolos presentes, no solo IP.

De las muestras, sFlow se quedará con los bytes iniciales, agregará los contadores y pasará toda esta información a los colectores sFlow.

Así pues, estamos con NetFlow teniendo información sobre los flujos IP, considerando capa 3 y 4, en tanto que con SFlow tenemos muestras de cualquier protocolo considerando desde capa 2 a capa 7.

Esto nos lleva a considerar sFlow un protocolo más amplio y de menos consumo de recursos en los Exportadores, que escala bien pero que, estando basado en muestreo, puede dejar sin evaluación algún tráfico.

Dicho esto, el lector puede suponer correctamente que hay controversia. ¿Qué protocolo es mejor?

El lector interesado en esta controversia puede recurrir a este artículo publicado en comparitech y a este publicado en pcwdld para introducirse en el tema.

NetFlow y Pandora FMS

Pandora FMS, como herramienta de monitorización de propósitos generales, incluye la utilización de técnicas de análisis de tráfico de red.

De hecho, Pandora FMS incluye integración a equipos de captura de tráfico como los TAPs y además soporta NetFlow.

La integración con NetFlow se logra estableciendo el servidor Pandora FMS como un Colector y Analizador NetFlow. Esta integración supone la utilización de una herramienta de software libre llamada nfcap.

Una vez instalada la herramienta, el demonio se arrancará de forma automática y el esquema presentado por Pandora FMS ofrecerá entonces un esquema muy flexible de filtros que permitirá escoger con precisión el tráfico que se desea evaluar.

Al lector interesado en revisar un esquema de integración de Pandora FMS y NetFlow, utilizando un dispositivo Raspberry, le recomendamos revisar este interesante artículo.

Por supuesto, el soporte a NetFlow es solo una de las muchas facilidades que aporta Pandora FMS.

Si el lector está interesado en conocer mejor el alcance de Pandora FMS lo invitamos a entrar en este enlace:
https://pandorafms.com/es/monitorizacion-de-red/

Si quiere conocer mejor qué es lo que Pandora FMS puede ofrecerle, puede entrar aquí: https://pandorafms.com/es/

En el caso de contar con más de 100 dispositivos para monitorizar, el lector puede contactar con el equipo de Pandora FMS a través del siguiente formulario: https://pandorafms.com/es/contactar/

Además, recuerde que si sus necesidades de monitorización son más limitadas tiene a su disposición la versión OpenSource de Pandora FMS. Encuentre más información aquí: https://pandorafms.org/es/

No dude en enviar sus consultas. ¡El equipo de Pandora FMS estará encantado de atenderle!