Español | English
rss facebook linkedin Twitter

Switches: los grandes olvidados (II) – Spanning Tree Protocol

En esta parte voy a explicar las vulnerabilidades del Spanning Tree Protocol, estas pueden ser explotadas por una herramienta programada por Alfredo Berrueta y David Barroso, dos grandes de S21sec.

 

En un gran entorno de red, donde existen varios switches gestionando diferentes segmentos de red, el protocolo Spanning Tree Protocol (a partir de ahora STP), es usado para evitar la creación de bucles de red a nivel 2 del modelo OSI.

Existen diferentes estándares de STP, el primero es el IEEE 802.1d, además tenemos 802.1q, 802.1w, 802.1s:

 

802.1d   es el estándar que define el STP inicialmente, define el método usado para evitar los caminos redundantes en una red de switches, además de asegurar la recuperación de la red si alguno de los mismos falla.

 

802.1q es una extensión del 802.1d pero añadiendo el término de redes locales virtuales (VLAN), este protocolo ya lo explicaremos en otro capítulo.

 

802.1w o (Rapid STP) RSTP es una revisión del 802.1d la cual aplica algunos cambios en el algoritmo para agilizarlo, así la recuperación tras un fallo es más rápida. En general mejora su rendimiento mientras se es compatible con los dispositivos que solo soportan el STP original.

 

802.1s o Múltiple STP (MSTP), mejora el 802.1q permitiendo a los bridges a gestionar múltiples spanning tres cada uno por grupo de VLAN, incrementado la escalabilidad.

 

Funcionamiento de STP

El objetivo es evitar bucles y recuperación ante fallos. Para cumplirlo el algoritmo crea un árbol de switches, la raíz es aquel switch con un ID más bajo, para identificarlo, todos los switches mandan a multicast las Bridge Protocol Data Units (BPDU), es un frame de nivel 2 en el cual va incluido el ID del switch (prioridad + MAC del dispositivo), cuando un switch recibe un BPDU con un ID menos que el suyo deja de enviar su BPDU, así solo el switch con el ID más bajo se mantendrá generando BPDUs y se convierte en el switch raíz. 

 

STP utiliza un sistema de costes para evitar los bucles, cada puerto es configurado con un coste, la mayoría de los switches configuran sus el coste de sus puertos en relación con la velocidad de los mismos.

 

Cada vez que un puerto recibe una BPDU el coste de ese puerto se incrementa con el coste que contiene la BPDU, el switch raíz envía BPDUs de coste cero. Evidentemente si se reciben más de una BPDU, las BPDUs de mayor coste se ponen en modo bloqueado.

 

Cada cierto tiempo, el switch raíz manda un BPDU. Cuando un switch recibe un BPDU con un ID mayor que el suyo propio, intenta convertirse en raíz mandando su BPDU. Cuando un bridge recibe una BPDU en el que el coste hasta la raíz es mayor que el coste que él mismo puede ofrecer por uno de sus puertos, intenta convertirse en puente designado para ese camino. Si el coste es el mismo, se compararían identificadores.

 

Existen también los denominados TCN BPDUs, son BPDUs que anuncian cambios en la topología, cuando son recibidos (después de un proceso de confirmaciones) los switches reducen el tiempo para actualizar sus tablas de forwarding.

 

Por cierto, y ya que no lo he dicho antes, este protocolo no implementa ningún sistema de autenticación ni protección, es además en claro…

 

Ataques al STP


Convertirse en bridge raíz

Este ataque es tan fácil como inyectar tramas BPDUs donde nos ponemos un ID más bajo que el del switch raíz, ósea la misma prioridad (por defecto el del raíz es 32768) y una MAC más baja, o directamente ID=0… Así nos convertiríamos en bridge raíz.

 

¿Hace falta que os diga más?, desde aquí podemos convertir nuestro sistema en un switch si tiene dos tarjetas de red (Yersinia te facilita la tarea), y desde esta posición podríamos realizar ataques MiTM sobre el tráfico que pasara por nuestro sistema.

 

DOS por inundación de configuration BPDUs y TCN BPDUs

Mandar múltiples (miles) configuration BPDUs por segundo hace que algunos dispositivos fallen al procesarlas e incrementen el uso de su CPU hasta un 99%. Además, cada vez que se manda un TCN BPDU, el bridge raíz debe contestar con un TC-ACK , y cada vez que esta confirmación es recibida, los switches deben reducir el tiempo para actualizar sus tablas de forwarding.

 

 

Soluciones

Root Guard

Cuando configuramos root guard, configuramos en que puertos puede estar el switch raíz y en cuales no, así si se recibe una BPDU con ID más bajo en uno de los puertos con root guard el mismo se pone en modo STP inestable y deja de transmitir paquetes.

 

BPDU-Guard

Este sistema permite a los administradores forzar la topología de arboles y mantenerla predecible, aquellos dispositivos que estén fuera de la topología configurada con BPDU-guard no podrán influir en la topología STP. La recepción de BPDUs fuera de este ámbito hace que BPDU guard deshabilite el puerto.

 

Hasta el próximo capitulo…

 

Leonardo Nve

S21sec Auditoría


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login