Analizadores de Tráfico: ya tengo una captura, ¿y ahora qué?

Analizadores de Tráfico: ¿Qué hacen y cómo se usan?

Cuando nos encontramos ante un problema de rendimiento que llega a enfrentar a los responsables de las aplicaciones contra los responsables de la plataforma de redes, solemos pensar en lo útil que sería disponer de un analizador de tráfico que aclare el origen real del problema.

Ahora bien, muchas veces vemos a analistas de redes que luego de instalar la herramienta se siente abrumados por la cantidad de información que esta les ofrece.

Y no es para menos, ya que un analizador puede capturar una cantidad enorme de paquetes, mostrarnos sus encabezados, ofrecernos facilidades, hacer múltiples filtrados, pueden mostrarnos gráficas sobre los elementos más referenciados, estadísticas sobre tráfico total, cantidad de errores y un largo etcétera.

En ese punto es lógico preguntarse: “Y ahora, ¿qué debo hacer?”

La respuesta es: “Ahora toca hacer análisis de tráfico”. Y allí caemos en cuenta que los analizadores posibilitan el análisis, pero el análisis lo debemos hacer nosotros.

En este artículo les invitamos a revisar cómo funciona un analizador de tráfico, y cómo se pueden realizar las capturas para luego plantear una serie de estrategias para los siguientes pasos.

---

---

¿Qué hace un analizador de tráfico?

Los analizadores de tráfico pueden hacer muchas cosas. Entre ellas:

1. Capturar y almacenar tramas capa 2 y paquetes asociados con los niveles superiores. En este artículo utilizaremos el término paquete para referirnos tanto a tramas como a paquetes.
2. Permiten definir parámetros que regirán la captura de paquetes; por ejemplo, nos permiten capturar solo los paquetes que disponen de una misma dirección IP destino, una misma dirección MAC origen, un mismo protocolo, etc.
3. Permiten emprender una captura de datos cuando una condición dada se presenta. Por ejemplo, se comienza a capturar cuando se observan paquetes con una dirección MAC destino específica.
4. Identifican el protocolo asociado con cada paquete y llevan a cabo la decodificación de los encabezados del paquete en función de los protocolos correspondientes.
5. Ofrecen una interfaz por medio de la cual el analista de tráfico podrá visualizar y manipular los paquetes decodificados.
6. Presentan como errores aquellos paquetes con características inusuales: demasiado pequeños, demasiado grandes, con erróneos FCS (Frame check sequence) o CRC (cyclic redundance check), etc.
7. Generan estadísticas que extraen de los paquetes capturados. Por ejemplo, listado de los 10 equipos con más tráfico de red, listado de protocolos organizados por la cantidad de tráfico, listado de las conversaciones con mayor cantidad de tráfico identificando la dirección origen y la dirección destino, etc.
8. Ofrecen facilidades de búsqueda dentro de una captura de paquetes; podemos hacer búsquedas por dirección IP destino, por protocolo, por subprotocolo, por una secuencia de bytes específica, etc.

Aclarando el tema de la captura

En redes basadas en concentradores, el analizador se conectaba a través de una tarjeta de red que solo le permitía capturar los paquetes que estaban dirigidos a todos los equipos de la red o todos los equipos de un segmento, es decir, los paquetes Broadcast y Multicast.

¿Cómo podíamos capturar todos los paquetes que transitaban por el concentrador? Para ello, se desarrollaron tarjetas de red que podían trabajar en ¨modo promiscuo¨.

Ahora bien, esta solución no funcionaba si la red era implementada con un equipo switch.

El problema entonces se superó con la posibilidad de crear en los switches puertos espejo o SPAN, los cuales copian todos los paquetes que pasan por un puerto o grupo de puertos y los copian en otro puerto que se reservaba para el analizador de paquetes.

Los puertos SPAN son una solución interesante, pero tienen algunas desventajas:

• A nivel de rendimiento, significan una carga adicional de trabajo para los switches.
• A nivel operativo, pueden filtrar algunos paquetes con errores y no son pertinentes si en el punto donde deseamos capturar no se encuentra un switch o el switch no soporta la creación de puertos SPANs.

Otra opción la representan los equipos de hardware conocidos como TAPs (Terminal Access Point), que acceden al tráfico entre dos puntos de red y lo copian en un puerto donde se deberá integrar el analizador de tráfico.

Invitamos al lector interesado en el tema de los TAPs a revisar estos post

Aclarando el tema de la seguridad de datos

Cualquiera puede suponer que los analizadores de tráfico pueden mostrar la data del paquete y con ella información sensible del usuario y de la organización.

En este punto hay que aclarar que los analizadores de tráfico por lo general no suelen decodificar la parte del paquete que corresponde a la data, sino que decodifican solo los encabezados.

El lado oscuro de los analizadores

La tecnología asociada con los analizadores de tráfico puede ser utilizada por intrusos para detectar:

• • Vulnerabilidades de la plataforma que puedan explotar al perpetrar un ataque; cosas como un listado de aplicaciones y servicios, incluyendo sus versiones.

La forma de extraer información sensible de la empresa o privada de los usuarios; datos como perfil del usuario, credenciales, localización, páginas WEB visitadas, etc.

• Otros atacantes pueden obtener el tráfico a través de otros medios (aplicando alguna técnica de man-in-the-middle, haciendo espionaje sobre redes inalámbricas, aplicando scripting o con Proxys y VPN falsas) y luego utilizar analizadores de tráfico para extraer la información deseada.

Sobre la inspección profunda de paquetes

Los términos análisis de paquetes, análisis de tráfico y análisis de protocolos presentan sutiles diferencias entre los unos de los otros. Sin embargo, en la práctica estas diferencias terminan diluyéndose.

Ahora bien, el término “inspección profunda de paquetes” o “deep packet inspection” es un caso diferente y bien vale una breve aclaratoria.

Esta técnica se diferencia del análisis de tráfico en dos puntos cruciales:

• A diferencia de los que hacen los analizadores de tráfico, en una inspección profunda se contempla la decodificación de la porción de datos.
• En tanto que los analizadores de tráfico intentan no afectar o afectar de forma mínima el tráfico de la red, las herramientas que hacen inspección profunda de paquetes pretenden ejercer una acción sobre el tráfico.

Podemos pensar en las herramientas de inspección profunda como una mezcla entre un firewall y un analizador de tráfico.

Estrategias para hacer análisis de tráfico

En lo referente al análisis de tráfico hay dos formas de asumirlo; una de ellas es la verificación del estado general de la plataforma y la otra es el seguimiento a problemas específicos.

Aunque el lector puede encontrarlas obvias, las traemos a colación porque estas posturas han generado un debate entre los analistas de tráfico, llegándose incluso a una división.

Por un lado, están los que consideran que hacer revisión del estado general implica un gasto excesivo de recursos que no se ve compensado por los beneficios en términos de optimización de la plataforma.

Por otro lado, existe otro grupo que sí da importancia a este tipo de revisión y la promueve.

En lo personal soy de los que promueve la revisión del estado general porque creo en sus beneficios; de hecho, en este mismo blog publiqué un artículo sobre la optimización de las plataformas eliminando tráfico Broadcast, actividad que se puede y se debe realizar tengamos o no un problema de rendimiento.

El lector interesado puede leer dicho artículo siguiendo estos enlaces.

Igualmente, considero que debemos utilizar análisis de tráfico para solventar aquellos casos técnicos que son recurrentes, que enfrentan al grupo de aplicaciones con el grupo de plataforma o que implican riesgos de seguridad de datos.

Dejo al lector escoger bando, o no prestar atención a la división e integrar un buen analizador de tráfico en su maletín de herramientas para realizar tanto una cosa como la otra.

En todo caso, a continuación presentamos un listado de estrategias que pueden aplicar y que cubren ambas formas de trabajo:

• Revise su esquema de monitorización: si la plataforma en cuestión dispone de una plataforma de monitorización basada en una herramienta como Pandora FMS, la idea es integrar el análisis de tráfico a las actividades de monitorización, optimización y resolución de problemas.
  Tenga en cuenta que Pandora FMS dispone de un extenso grupo de facilidades como monitorización de red, monitorización de aplicaciones y, muy importante, todo un sistema de alarmas.

Para entender el alcance de estas facilidades les invitamos a revisar el siguiente enlace.

En todo caso, la integración podría ser así:

• • Los procesos de análisis de tráfico pueden ser motivados por una condición de error identificada por el sistema de monitorización.
    Todo el aprendizaje que sobre la plataforma se puede extraer del análisis de tráfico puede usarse para ajustar las configuraciones del esquema de monitorización.
  • Establezca los procedimientos de revisión del estado general y las actividades de auditoría: elimine todos los protocolos excedentes, minimice la cantidad de tráfico Broadcast y Multicast, evalúe las desviaciones, como errores físicos que generan tráfico excedente.

Incluya en sus actividades cotidianas todas las evaluaciones preventivas utilizando el analizador de tráfico, como estimar el tráfico que se generará sobre la red al incluir una nueva aplicación, por ejemplo.
Integre el análisis de tráfico en sus actividades regulares de auditoría de redes.

• Escoja los casos de soporte: es una obviedad decirlo, pero no todos los casos de soporte ameritan análisis de tráfico; por lo tanto, es necesario escoger bien.
  Le recomendamos aquellos que son recurrentes, que enfrentan al grupo de desarrollo con el grupo de plataforma, aquellos que giran alrededor del rendimiento global de la plataforma o el rendimiento particular de una aplicación o servicio.
• Evalúe los síntomas del problema dado: muchas veces, al escoger un problema y comenzar a evaluarlo, solemos toparnos con un grupo de síntomas o condiciones para los cuales, por lo general, es complicado obtener una causa común que los justifique.
  Para evitar la dispersión, le recomendamos escoger uno de los síntomas, en lo posible el principal, y concentrarse en la investigación asociada con ese único síntoma.
• Identifique el tráfico que desea evaluar: identificar los paquetes que deseamos evaluar puede convertirse en un reto, ya que:

 

1. Por precisas que sean nuestras capturas, por lo general traerán más tráfico del que nos interesa.
2. Muchos casos de error son difíciles de reproducir.

Para enfrentar este reto existen algunas técnicas para precisar el tráfico que interesa.
Una de ellas es instalar, en el equipo del usuario que sufre el síntoma que estamos evaluando, un script con un comando ping continuado a un servidor y pedirle al usuario que ejecute el comando durante el tiempo que presenta la falla.

• Así tendremos una marca del espectro de tráfico que debemos evaluar.

 

1. Igualar los relojes: un punto importante es igualar los relojes de todos los elementos que intervienen en la investigación que se esté haciendo. De esta manera podemos, por ejemplo, correlacionar el tráfico con entradas en los archivos logs de un servidor.
2. Conservar las capturas y documentar: es una buena costumbre documentar el proceso de análisis, sus resultados y las capturas clave, de manera que el caso pueda ser consultado en futuras investigaciones.

 

• Además, es interesante informar de sus hallazgos y las correcciones implementadas a los grupos relacionados y al grupo que administra la plataforma de monitorización, de manera que se pueda realizar una entonación de la misma en caso de que sea necesario.

 

Finalmente, deseamos invitarles a comentar sus experiencias con analizadores de tráfico dejando un comentario.