Análisis de tráfico en una red conmutada basada en un "backbone" ATM

Traffic Analysis in a Switched Network over an ATM Backbone

José Juan López Abellán

Resumen

Se presenta una solución para realizar análisis de tráfico en una red construida con conmutadores de accesoEthernet/FastEthernet conectados a un núcleo de conmutadores ATM, funcionando con LANE (LANEmulation), y routers IP. Dicha solución se basa en la utilización de Classical-IP en subredes de transiciónentre zonas a supervisar, cuyo tráfico se hace pasar a través de VCCs (Circuitos Virtuales) punto-multipunto,y sondas con interfaz ATM con software de dominio público.

Palabras Clave: Ethernet, ATM, Switch, Sniffing, VCC, Classical-IP, LANE.

Summary

A solution is presented to provide traffic analysis in a switched network with Ethernet/FastEthernet accessswitches connected to a backbone of ATM switches, working on LANE (LAN Emulation), and IP routers. Thissolution uses, Classical-IP on transition subnets connecting areas to be monitored, with traffic passingthrough point-multipoint VCCs, and sniffers with ATM network interface and public domain software.

Keywords: Ethernet, ATM, Switch, Sniffing, VCC, Classical-IP, LANE.

1.- El entorno y el problema

En un entorno de red basado en la tecnología Ethernet clásica de bus compartido, el análisis del tráfico de red se basa habitualmente en la utilización de sondas con interfaz Ethernet conectadas al bus. Dichas sondas, con su interfaz Ethernet funcionando en modo promiscuo, capturan el tráfico a analizar y constituyen la plataforma en la que se ejecutarán, de forma más o menos permanente, aplicaciones bien propietarias, bien de dominio público, las cuales permitirán realizar un análisis del tráfico capturado para su supervisión.

Una tarea a realizar puede ser la recopilación de datos para la elaboración de distintos tipos de estadísticas que pueden servir para saber, por ejemplo, cómo se distribuye el ancho de banda de entrada/salida a una zona de la red entre los distintos tipos de protocolos de nivel de aplicación o entre las distintas máquinas de la zona en sus accesos externos. De esa forma podríamos facturar en función del volumen de tráfico de un departamento o conocer los servidores web externos más accedidos, o saber simplemente qué servidores web existen en esa zona de red, cosa nada sencilla en organizaciones grandes de unas determinadas características. También será interesante la detección de determinados tipos de ataques hacia/desde una zona supervisada, utilizando alguno de los sistemas detectores de intrusiones existentes en la actualidad. Especial interés tiene detectar los ataques de negación de servicio que pueden afectar seriamente al normal funcionamiento de nuestra red. Todo ello, por supuesto, dentro del marco de la legalidad vigente en nuestro país, lo cual supondrá evitar el análisis o almacenamiento del contenido del campo de datos (payload) de los paquetes [1].

Si tenemos una red compleja, segmentada, con uno o varios routers basados en la tecnología Ethernet, es habitual hacer pasar por un bus ethernet (que a veces se conoce como "Drawbridge"), todo el tráfico entrante/saliente hacia/desde una determinada zona de red que queramos supervisar.

El tráfico supervisado puede corresponder al de un enlace externo WAN o al que exista entre dos zonas separadas de nuestra red. El tráfico interno a cada zona no suele ser capturado de forma permanente.

Combinando los sistemas de detección y análisis con los mecanismos que los routers o encaminadores establecen para control de acceso y control de congestión, disponemos de un entorno de gestión que podríamos definir como un "firewall" o cortafuegos virtual, cuya ventaja fundamental es que no introduce un elemento adicional intermediario en el acceso a la zona de red supervisada, origen de posibles problemas de pérdida de conexión o de degradación del rendimiento.

Esto evidentemente, será una filosofía aplicable a un entorno en el que prime la conectividad sobre la seguridad, es decir, en el que problemas con los dispositivos de análisis no deban afectar a la conectividad aunque momentáneamente estemos "ciegos" a lo que entra y sale de la zona de red supervisada.

Centrándonos en un entorno de este tipo, el problema empieza a surgir cuando la evolución tecnológica nos lleva a usar conmutadores en vez de concentradores, y a utilizar técnicas de banda ancha en el corazón de la red, así como en el acceso hacia/desde el exterior de la misma.

Es típico un escenario en el que el corazón de la red ("backbone") está constituido por una nube de conmutadores ATM interconectados, de los cuales cuelgan conmutadores de acceso, por ejemplo, FastEthernet/Ethernet, con uno o varios interfaces ATM para conectar al "backbone". Sobre todo ello es típico también utilizar LANE, y por supuesto TCP/IP, y routers con esta tecnología conectados igualmente a la nube ATM. Además, en nuestro caso, el proveedor habitual de conexión al mundo Internet nos proporciona un enlace ATM con un ancho de banda que puede crecer desde 4Mbps contratados en la actualidad a 34Mbps o 155Mbps si fuera necesario, sin realizar cambios en el hardware de los equipos conectados a los extremos del enlace.

En este entorno no existe un bus compartido ethernet del cual podamos extraer el tráfico que sea necesario analizar. Además hacer pasar tráfico entre zonas por un bus ethernet a 10 Mbps, puede constituir un serio cuello de botella. Hay que buscar mecanismos transparentes para poder analizar el tráfico hacia/desde zonas de la red que queramos supervisar, que permitan el análisis de flujos de tráfico que ocupen un mayor ancho de banda.

Distinguiremos entre conmutadores de backbone, reservando esta denominación para los conmutadores con puertos ATM (en nuestro caso a 155Mbps OC3c) que constituyen el corazón de la red interconectándose entre sí, y los conmutadores de acceso, los cuales poseen un puerto ATM (en nuestro caso a 155Mbps OC3c) para conectarse a alguno de los conmutadores de backbone y puertos Ethernet o FastEthernet para conexión de los usuarios de la red. En algún caso existen servidores centrales conectados directamente al backbone ATM, pero la función principal del mismo será interconectar entre sí los conmutadores de acceso.

Es fácil caer en la trampa de pensar que las utilidades de monitorización del tráfico de un conmutador de acceso, que permiten volcar el tráfico entrante/ saliente de uno o varios puertos sobre otro puerto en el que puede ser conectada una sonda, ofrecidas por los fabricantes, van a resolvernos el problema. Normalmente el uso de estas facilidades va a hacer que el rendimiento del conmutador caiga dramáticamente, afectando seriamente al servicio ofrecido, viéndose restringido su uso a momentos muy concretos.

Algunos conmutadores de acceso avanzados, que además incorporan facilidades de routing a nivel IP, también poseen utilidades similares, pero presentan el mismo problema. Por otra parte las implementaciones RMON típicas hasta la fecha son insuficientes para resolver en toda su amplitud la problemática planteada. Necesitamos mecanismos no intrusivos, transparentes, que puedan ser aplicados de forma permanente, y abiertos a la utilización de sondas no ligadas a un software propietario, en las que las herramientas de dominio público puedan solucionarnos gran parte de las necesidades de análisis sobre lo que está pasando por un punto de la red.

2.- La piedra angular de una posible solución

Sin embargo, en el corazón de la red, tenemos unos conmutadores de "backbone", en los que disponemos de mecanismos que a diferencia de los conmutadores de acceso, nos permiten replicar tráfico entrante o saliente de un puerto ATM 155Mbps en otro puerto de las mismas características sin que el rendimiento del equipo se vea afectado, con anchos de banda efectivos utilizados de esos 155Mbps bastante elevados. Nuestra experiencia nos dice que es así con flujos de unas decenas de megabits por segundo de ancho de banda replicados, en conmutadores ATM como los descritos. Si disponemos de una sonda con un interfaz de red ATM conectada al puerto donde se replica el tráfico a analizar habremos resuelto el problema.

El mecanismo básico que constituye la piedra angular de la solución es definir, en dichos conmutadores, canales virtuales permanentes (VCCs) punto-multipunto, con un punto de entrada y dos de salida. Para el tráfico entrante a la zona de la red a supervisar, definimos un VCC con entrada desde el dispositivo que nos dé el tráfico entrante, una salida hacia el dispositivo encargado de encaminar hacia esa zona dicho tráfico, y la otra salida hacia la sonda. Para el tráfico saliente desde esa zona, definimos otro VCC con entrada desde el dispositivo que encamina el tráfico saliente de la zona y salidas en el dispositivo que encamina hacia el resto de la red o hacia el acceso externo, y en la sonda. (Véase figura 3 para mayor claridad).

Normalmente en los extremos de cada VCC permanente como los descritos se conectarán dos routers IP mediante subinterfaces Classical-IP sobre PVCs con encapsu- lación IEEE 802.2 LLC/ SNAP, definidos en el interfaz ATM de cada router. En el punto de salida de cada VCC donde se replica el tráfico se conectará un subinterfaz Classical-IP sobre PVC definido en la sonda.

Hacia la sonda nos llega por dos VCCs diferentes, y por tanto por dos subinterfaces Classical-IP, el tráfico entrante y el saliente. Este detalle: la separación entre el tráfico entrante y saliente, supondrá una limitación a la hora de utilizar determinadas herramientas de dominio público, que será necesario "parchear" para tener en cuenta la circunstancia. Pero merece la pena el "inconveniente".

Veamos un ejemplo de configuración para VCCs punto-multipunto en un conmutador ASX de FORE: supongamos que desde un router IP remoto de nuestro proveedor, nos llega un PVC el cual conectamos a un conmutador ATM, en dicho conmutador tenemos, conectado a uno de sus puertos, nuestro router IP de acceso al exterior. Hemos pedido encapsulación LLC/SNAP en el enlace.

¿Y por qué no más VCCs? Si tenemos más puertos de los que nos gustaría obtener el tráfico entrante/saliente, podemos definir más VCCs como los mencionados y uno de los puntos de salida de cada VCC llevarlo siempre a la sonda. No tendremos más limitaciones que el número de subinterfaces que podremos asociar en la sonda a los distintos VCCs que llegan al interfaz del conmutador ATM donde está conectada, su capacidad de CPU, disco, ... y las limitaciones en cuanto a buffers que tengan las aplicaciones de análisis que montemos en la sonda sobre los drivers de los dispositivos asociados en la misma a cada VCC.

Si consideramos que una zona de nuestra red debe ser supervisada permanentemente en su acceso al resto de la red o al exterior, concentraremos el routing IP de las subredes asociadas a todas las LAN de esa zona en un router de zona, construyendo un drawbridge virtual adicional al del acceso externo global de nuestra red a través de un conmutador ATM que lo conecte a un router central que encaminará hacia/desde el resto de la red. Es en ese conmutador intermedio donde definiremos los VCCs punto-multipunto necesarios.

En los ejemplos que hemos insertado hemos supervisado el tráfico de la zona de red de aulas informáticas hacia/desde el resto de la red y el exterior.

3.- El esquema de routing

Si utilizamos LANE (LAN Emulation) sobre ATM, como base en nuestro entorno para definir las distintas redes locales virtuales, los VCCs asociados a las diferentes conexiones existentes entre puertos de los conmutadores ATM se crearán y borrarán dinámicamente.

Debemos aclarar que no vamos a incidir sobre estos VCCs: los VCCs punto-multipunto creados para replicar tráfico saliente y entrante de la zona a supervisar, constituirán "Drawbridges" virtuales, entre subinterfaces Classical-IP de routers, que mediante el uso de rutas estáticas, obligarán a que todo el tráfico entrante a la zona pase por el VCC entrante definido, y el saliente salga de la zona por el VCC saliente. Sólo las subredes de transición entre zonas, vía los "drawbridges" virtuales, usan Classical-IP, el resto de subredes usan LANE. El uso de rutas estáticas no es estrictamente necesario y su conveniencia o no dependerá de la topología de la red y de los tipos de routers implicados.

En la zona supervisada pueden incluirse varias subredes IP asociadas a otras tantas VLANs o redes virtuales emuladas.

En la figura 5 el router de acceso exterior también se utiliza para acceder hacia/desde el router de la zona supervisada, y a algunas otras subredes IP internas.

Las configuraciones siguientes corresponden al router IP de acceso externo y de subredes IP departamentales (un router CISCO en nuestro caso), y al router de acceso a las subredes de aulas informáticas (un PHUB7000 de FORE en nuestro caso). Ambos se conectan a través de un conmutador donde están definidos los VCCs que ya hemos ido viendo en los ejemplos anteriormente.

En la figura 6 se representan los subinterfaces IP de los routers como círculos. Los subinterfaces de las subredes emuladas con LANE, departamen-tales o de aulas, se agrupan en cada representación de su router como un solo círculo, diferenciándose los subinterfaces correspondientes a las subredes IP de transición exterior/nuestra-red y aulas/ departamentos. Para simplificar no se representa la sonda.

Los comandos de configuración aun siendo distintos presentan una analogía que los hace fácilmente comprensibles para quien esté familiarizado con uno de los dos entornos:

4.- La sonda

Como plataforma para la sonda utilizamos una estación Sun ULTRA 5 con Solaris 7 y una tarjeta ATM de Fore modelo SBA200E. Como ya dijimos se definen tantos dispositivos Classical-IP como flujos diferentes queramos analizar. Son los dispositivos "qaan" que el driver de Fore nos permite definir y utilizar.

Además podemos utilizar una tarjeta Ethernet o FastEthernet independiente para conectarnos en remoto a la sonda, reservando el interfaz ATM para tareas de captura de tráfico (ver figura 5).

Para configurar los interfaces Classical-IP sobre PVCs, Fore facilita con la instalación del driver de la tarjeta los comandos de configuración que aparecen en el siguiente ejemplo de configuración del interfaz qaa0:

Repitiendo esto para los otros qaas, cada uno con su pvc, llegaremos a las siguiente configuración:

5.- Vestir la sonda

Una de las cuestiones más importantes a la hora de utilizar aplicaciones de análisis de tráfico de dominio público es comprobar que su utilización no va a infringir la legislación vigente: deberemos ponerlas a funcionar con opciones activadas que impidan el examen o almacenamiento de la parte de datos o "payload" de los paquetes, garantizándonos que sólo vamos a examinar cabeceras de los mismos y que el derecho a la intimidad del individuo no va a ser vulnerado [1].

Aplicaciones interesantes de dominio público en el momento de redactar este artículo son: 1) NeTraMet: medidor de flujos [2].

Combinando procesos de captura NeTraMet con la utilidad de consola nm_rc del paquete, podemos generar ficheros de trazas con, por ejemplo, los 20 flujos más activos cada 10 minutos de forma permanente, con información como la hora, dirección origen y destino del flujo, volumen de información intercambiado, y puerto origen y destino. Estadísticas de tráfico por aplicaciones o subredes IP, son inmediatas a partir de esta información.

Cada proceso NeTraMet puede capturar el tráfico que llegue por la lista de interfaces que se le indique.

Ejemplo de procesos de captura (sondas NeTraMet):

la primera para el "drawbridge" virtual del acceso exterior de nuestra red, la segunda para el acceso hacia/desde la zona de aulas.

En paralelo ejecutamos dos consolas nm_rc asociadas a esas "sondas" NeTraMet:

Los ficheros de reglas se generan a partir de ficheros escritos en un lenguaje llamado "srl", para lo cual el paquete dispone de un compilador.

Un ejemplo de trazas obtenidas de los flujos entre las 8:30 y las 8:40:

2) Snort: detector automático de intrusiones [3].

Nos permitirá detectar automáticamente distintos tipos de ataques conocidos, o indicios de preparación de los mismos (examen de puertos a la busca de vulnerabilidades, intentos de acceso a routers del backbone, conexiones a puertos de troyanos conocidos, ...). Permite definir reglas cuyo cumplimiento en el tráfico analizado activará alarmas que serán registradas automáticamente.

Un extracto del fichero de alertas podría ser:

Existen herramientas adicionales al paquete que permiten el procesamiento de los ficheros de alertas que se generen.

3) tcpdump: analizador de tráfico para resolución de problemas [4]. Si requerimos de un análisis más profundo del tráfico, esta herramienta permite acceder a todos los campos de las cabeceras de los paquetes TCP, UDP, ICMP, IP, ARP, RARP, ...

4) urlsnarf [5]: pequeña herramienta del paquete "dsniff" que permite recopilar URLs accedidas, y tras procesarlas elaborar estadísticas acerca de servidores web accedidos ...

Además de éstas, existen multitud de herramientas de dominio público que nos permitirán procesar el tráfico a analizar con diferentes fines.

6.- Algunas cuestiones adicionales

¿Podemos tener la seguridad de que el 100% de los paquetes que entran o salen por los "drawbridges" virtuales van a ser monitorizados por las aplicaciones de la sonda? La respuesta a esta pregunta es difícil pues va a depender de muchos factores: Potencia de la máquina que actúa como sonda, CPU y memoria serán críticos, y si queremos guardar históricos también será necesario disco Volumen de tráfico que estemos analizando Aplicación de análisis y opciones con las que las tengamos corriendo Una vez conseguida una buena máquina, con suficiente memoria y disco para los volúmenes de tráfico que estemos manejando, según la aplicación y las opciones con las que arranquemos los demonios de captura analizaremos en cada caso el 100% de los paquetes o porcentajes bastante menores. Por ejemplo, la ejecución de tcpdump con o sin la opción de resolver direcciones IP en nombres de máquinas DNS, pondrá en evidencia la pérdida de paquetes en caso de que resolvamos direcciones IP en nombres DNS.

Sería necesario realizar un estudio más profundo y riguroso en este sentido. En nuestras estimaciones, para un flujo total mantenido en la sonda durante las horas diurnas, de aproximadamente 15 Mbps: NeTraMet analiza prácticamente el 100% de los flujos.

Snort realiza el chequeo de reglas en la misma proporción. Tcpdump y otros analizadores de este tipo dependiendo de las opciones pueden perder hasta un 80% de paquetes.

Urlsnarf sólo captura entre un 15% y un 20% de las URLs accedidas, pero si se ejecuta durante un tiempo suficiente puede, por ejemplo, detectar todos los servidores Web de nuestra organización.

8.- Referencias

[1] Ley Orgánica 10/1995, de 23 de noviembre, del Código Penal. En: Boletín Oficial del Estado n. 281/1995, de 24 de noviembre.

[2] Nevil Brownlee. NeTraMet. Consultado en: (http://www.auckland.ac.nz/net/NeTraMet/)

[3] Martin Roesch. snort. Consultado en: (http://snort.safenetworks.com/)

[4] Van Jacobson, Craig Leres and Steven McCanne. Tcpdump.

Consultado en: (ftp://ftp.ee.lbl.gov/tcpdump.tar.Z)

[5] Dug Song. urlsnarf (integrada en dsniff). Consultado en: (http://www.monkey.org/-dugsong)

También son útiles multitud de artículos técnicos y documentación que se puede encontrar en las siguientes direcciones:

(http://www.monkey.org),
(http://www.cisco.com),
(http://www.fore.com) ó (http://www.marconi.com),
(http://www.3com.com)

Nota final: Las direcciones IP de los ejemplos han sido cambiadas por motivos de seguridad.

Agradecimientos: A mis compañeros del Grupo de Redes del SdI de la UC3M por su ayuda diaria, y en especial a David Gutiérrez por ayudarme a hacer las figuras, a Francisco Cruz, que instaló los drivers de FORE en la primera sonda, y a Javier Melero por junto con los anteriores revisar este artículo.