Tráfico broadcast


Uno de los fenómenos que puede afectar al rendimiento de nuestra red son las tormentas de tráfico, bien sea de unicast, multicast o broadcast, siendo estas últimas especialmente “peligrosas” a nivel de capa 2 de nuestro tan querido modelo de referencia OSI. Por supuesto hablamos de EUI-48 e IPv4.

Una trama dirigida a la dirección broadcast tendrá como MAC de destino ff:ff:ff:ff:ff:ff. Cuándo un switch recibe una de ellas por uno de sus puertos, éste la replicará por los restantes para que la reciban todos los equipos de la red. Obviamente si tenemos diseñada nuestra LAN mediante VLANs, el tráfico broadcast sólo será propagado dentro de la VLAN donde se genere dicho tráfico. Luego cada equipo la procesará, y en función de las capas superiores la descartará o seguirá su curso.

Así como el protocolo IP tiene un campo TTL, Time to Live, que se decrementa cada vez que un paquete pasa por un dispositivo de capa 3 y al llegar a 0 se descarta , una trama no  tiene uno similar en caso de pasar por equipos de capa 2. Así, en caso de producirse un bucle en la red las tramas no sólo podrán estar circulando indefinidamente sino además, en caso de ser broadcast , cada switch realizará una copia que difundirá por cada uno de sus puertos. Esto desencadenará un bajo, o nulo, rendimiento de la red y un consumo de recursos hardware en cada uno de los equipos. Afortunadamente tenemos protocolos de la talla de Spanning Tree Protocol, tanto en versiones estándar como propietarias, que evitan que se generen bucles de red en capa 2 para construir escenarios de alta disponibilidad.

Son muchos los protocolos que generan tráfico de esta índole, siendo algunos muy cercanos ARP, para averiguar la dirección MAC de destino de un equipo dentro de una misma red, o DHCP para que un equipo pueda descubrir un servidor que le proporcione una IP, máscara de red, Gateway, DNSs, etc.

Por tanto, bien por un mal diseño de red, un equipo que genere tráfico broadcast por un mal funcionamiento, un malware, un atacante nos lo meta para llevar a cabo una Denegación de Servicio, o lo que sea, podemos llegar a tener algún problemilla.

Para ver sus efectos tomaré un switch Cisco WS-C2960-24TC-L y a la vez que genero un conjunto de paquetes, voy a consultar la carga que sufre la CPU y veremos lo que pasa. El escenario es el siguiente:

Comenzaremos por realizar lanzar una serie de ARP replies con un generador de paquetes para ver una respuesta unicast. Para ello utilizaremos la aplicación Mausezahn que soporta una serie de protocolos que seguro nos van a venir bien para el futuro.

root@bt:/# mz eth0 –t arp –c 0 “reply,  senderip=192.168.10.11, targetmac=00:11:11:11:11:11, targetip=192.168.10.10”

Aquí podemos ver como en un segundo se han emitido un total de 63876 tramas. Si ahora vemos en el switch el consumo de recursos de la CPu veremos que apenas consume como máximo un 11%.

Sin embargo si realizamos un arp request para hallar la MAC del equipo A,

root@bt:/# mz eth0 –t arp –c 0 “request,  senderip=192.168.10.11, targetmac=ff:ff:ff:ff:ff:ff, targetip=192.168.10.10”

Vemos que mandamos 15063 tramas en un segundo, esto es un 77 % menos que en el primer caso .

Y sin embrago el consumo de recursos de CPU aumenta ligeramente… ¡del entorno del 80%!

Como podemos ver el efecto del tráfico broadcast en la electrónica tiene sus efectos negativos, repercutiendo en los procesos de conmutación de otros equipos. Aparte, tenemos que tener en cuenta que todo el tráfico broadcast será propagado a otros switches con lo que también consumirán recursos a equipos a los que no estamos directamente conectados…

Para evitarnos esta situación los switches Cisco, al menos los que dispongan de ella, tienen la posibilidad de configurar en los puertos un control sobre tráfico unicast, multicast y broadcast, denominado storm-control. El funcionamiento es sencillo. Se establece un umbral máximo de tráfico, en nuestro caso broadcast. El switch supervisará la cantidad de tráfico entrante en períodos de 200ms y lo comparará con el umbral determinado. Todo lo que exceda, lo eliminará, por lo que la CPU no lo procesará, y por tanto no consumirá recursos. Hay que tener en cuenta que la decisión de suprimir ese exceso de tráfico se tomará para el siguiente intervalo de 200ms, no el mismo intervalo en el que fue detectado.

Así que ahora lo que vamos a hacer es configurar esta característica en el switch y veremos de nuevo el comportamiento.

Para empezaremos generando tráfico DHCP mediante la herramienta Yersinia pero a diferencia de los otros post en los que la he utilizado esta vez vamos a utilizar el modo “daemon” y lanzaremos un DoS lanzando DHCP request.

Para ello:

root@bt:/# yersinia -D
root@bt:/# telnet 127.0.0.1 12000

Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is ‘^]’.
Welcome to yersinia version 0.7.1.
Copyright 2004-2005 Slay & Tomac.

login: root
password: “root” (sin las comillas)

MOTD: Waiting for my Musical Fidelity A5 power amplifier… 🙂

yersinia> enable
Password: “tomac” (sin las comillas)
yersinia# set dhcp interface eth0
yersinia# run dhcp 1
yersinia#

¡Como podemos ver la CPU del switch se pone casi al 100% !

Pues ahora, configurar el switch para que el tráfico broadcast ocupe como máximo el 50% del tráfico:

PRUEBAS01#conf t
PRUEBAS01(config)#interface fastEthernet 0/23
PRUEBAS01(config-if)#storm-control broadcast level 50.00

Y entonces vemos cómo el consumo de recursos desciende hasta cerca del 30 % previo mensaje en la consola,

Cómo podemos comprobar esta medida puede prevenir algunos ataques mediante el envío de tráfico broadcast a la red, sea cual sea el origen, malware, atacante, malfuncionamiento de una aplicación, etc.

En fin no está de mal configurar esta útil característica que nos puede ayudar a prevenir ciertas incómodas situaciones. Además si lo configuramos para ello podremos incluso en caso de activarse el filtrado, deshabilitar el puerto o mandar un trap a alguna estación de monitorización. En resumen otra cosa más a tener en cuenta…

Seguiremos informando…

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s