La red como sensor de seguridad

49

Por Javier Liendo, Technical Solutions Architect de Cisco México.

¿Qué sucedería si al recibir tu recibo telefónico a finales de mes descubrieras que de tu casa se originó una llamada a un país en el centro de Asia? Sería “raro” ¿No? ¿Se introdujeron a tu casa e hicieron la llamada mientras no estabas? ¿Alguien instaló un “diablito” (1) y de ahí llamó? ¿Fue un error de la compañía telefónica?

Así también mucho se puede saber de lo que ocurre con un individuo sólo por las llamadas que recibe o hace: ¿Por qué comenzó a hablar con un cardiólogo? ¿Por qué llama a su compañera o compañero de trabajo fuera de horario de oficina? ¿Por qué le está hablando a un terapeuta que se especializa en problemas de pareja? ¿Por qué habló a una aerolínea? ¿Por qué no ha llamado a su esposo o esposa en la última semana? ¿Por qué está hablando a la oficina de un abogado? ¿Por qué empezó a hablar con un notario público? ¿Por qué lo busca un negocio que se especializa en cobranzas?

No es necesario tener acceso al contenido de la llamada para poder obtener mucha información de una persona.

En general, cada producto tecnológico que usamos: nuestro navegador, nuestro celular, nuestro propio auto, deja una migaja electrónica que al que sabe observar le permite reconstruir con gran precisión cómo somos, lo que pensamos y lo que hacemos.

A este tipo de estudio se le conoce como “análisis de metadatos o análisis de comportamiento” y desde hace un par de años ha existido una gran polémica (2) sobre el uso que hacen de esta técnica algunos gobiernos con la intención de conocer lo que están haciendo, lo que a su juicio, consideran como grupos que atentan contra el status-quo.

Análisis de comportamiento y análisis de flujos

Este mismo tipo de análisis y de utilización de los metadatos se convierte en una herramienta de seguridad muy poderosa para el administrador de redes.

Cada paquete que transita por la red puede agruparse en lo que se conoce como “flujos” y al igual que las llamadas telefónicas, dependiendo de dónde se originan y hacia dónde se dirigen, se puede saber mucho si la red está actuando “normal” o si por el contrario, la existencia de estos flujos indican problemas de configuración o de seguridad.

La manera en que se pueden agrupar en flujos cada uno de los paquetes que transitan por una red y cómo estos flujos se reportan a una plataforma de recolección para análisis, está gobernado por un protocolo inventado por Cisco al que se le conoce como “netflow”.

En una de las versiones más utilizada (discutiblemente) de este protocolo, la versión cinco, los paquetes se agrupan por siete valores diferentes: protocolo de capa tres (proto), dirección IP origen (src), puerto origen (srcport), dirección IP destino (dst), puerto destino (dstport), el valor DSCP (dscp) del encabezado IP y la interface por la cual está ingresando el paquete (ifindex) al ruteador o switch.

Existe también información adicional que genera netflow a partir de estos campos: la hora en la que por primera vez se vio el flujo en el dispositivo, tamaño de los paquetes que componen el flujo, paquetes por segundo en el flujo entre otros muchos otros. A estos campos se les conoce también como los metadatos del flujo.

Todos los paquetes que tienen el mismo valor en los siete campos principales son considerados parte del mismo flujo.

A medida que estos paquetes transitan por la red, su información va siendo agregada, contabilizada y tabulada por cada uno de los switches y ruteadores que hayan sido configurados con netflow. Cada cierto intervalo de tiempo todos los ruteadores y switches habilitados con netflow van reportando los flujos que han “visto” a un “colector centralizado de flujos” desde donde el administrador de red puede analizar el comportamiento de la red.

La idea más importante detrás del análisis de flujo es que todo paquete tiene que transitar por la red. No hay forma en la que un paquete pueda llegar de un punto A a un punto B sin pasar por al menos un switch. Es un poco como caminar por la playa, no hay manera de caminar por la arena, sin dejar huella.

Si en cada switch y en cada ruteador de la infraestructura de red se configura netflow, el administrador de redes puede tener visibilidad completa de que flujos existen y por lo mismo conocer el comportamiento de su red. La red, como una sola unidad, se ha convertido en un gran sensor que le puede dar aviso y dejar registro de cada uno de las comunicaciones que existen entre cada una de las regiones de su red y entre cada uno de los dispositivos que componen su infraestructura.

“Una imagen vale más que mil palabras” dice el refrán y en este tenor a continuación se muestra un caso de análisis de flujos utilizando información generada por un stack de switches Cisco Catalyst 3850X en donde se configuró Netflow. Por la ubicación en la red de este stack, es el core de una red en producción, la visibilidad que se tiene al activar netflow es prácticamente sobre todos los paquetes que transitan la red.

Caso – El extraño caso de “¿Por qué hay tantos servidores DNS en mi organización?”

Los servicios de DNS que utiliza una organización son una parte fundamental para la operación estable y segura de una red. El que controla la resolución de nombres de dominio, en gran parte controla a donde se conectan los dispositivos de red. Por lo mismo es muy deseable conocer cómo está siendo utilizado este servicio en la red interna de una organización. Siempre es muy importante saber ¿Qué servicios DNS están utilizando los usuarios? ¿Están utilizando los servidores DNS que la organización provee? ¿Quién no los está usando?

Servidores DNS utilizados en los últimos cinco minutos-

En la figura anterior se puede observar que en los últimos cinco minutos (ventana de tiempo de las 21:50:15 a las 21:56:21) se han utilizado múltiples servidores DNS (más de diez) que no pertenecen a la organización, esto es, flujos udp y tcp puerto destino 53 que originan en las redes internas de usuarios 192.168.0.0/16 y 172.16.0.0/16 pero cuyo destino son redes externas.

Está información debiera ser la causa de muchas preguntas: ¿Por qué hay usuarios de la red interna utilizando estos servidores? ¿Quién administra estos servidores DNS? ¿Es un problema de configuración o es un problema de seguridad? ¿Por qué hay una proporción significativa de flujos DNS hacia la dirección IP 10.2.9.2 en relación a las demás direcciones IP? ¿Si este servidor no es administrado por el área de TI, quién lo hace?

En definitiva el administrador de esta red tiene muchas preguntas que responder.

Lo “interesante” es que este ejemplo, con todos estos problemas y situaciones anormales salió del análisis de un solo bloque de cinco minutos aproximadamente a la misma hora. Se deja como ejercicio para el lector deducir la cantidad de información y conocimiento que su red le puede proporcionar al administrador de redes cuando se extiende este tipo de análisis a períodos más largos dentro de su propio organización.

Muy poca de esta información hubiera podido haber sido generada por un firewall o sistema de detección de intrusos. Estas herramientas tienen una función muy importante y crucial en toda estrategia de seguridad, pero proveer de información para conocer cuál es el comportamiento de una red, sobre todo de la parte interna de una red, no es una de sus principales funciones.

Cisco en los últimos años ha introducido la capacidad de generar flujos utilizando netflow prácticamente en toda su línea de productos: switches, ruteadores, firewalls y controladores de redes inalámbricas. También ha ampliado su portafolio agregando a Stealthwatch como colector de flujos para el análisis de comportamiento con un enfoque en seguridad.

Si estás interesado en conocer más sobre cómo utilizar análisis de flujos para la detección de problemas de seguridad y utilizar a la totalidad de tu red como sensor de seguridad, por favor accede a la siguiente liga: http://www.cisco.com/c/en/us/solutions/enterprise-networks/enterprise-network-security/net-sensor.html