Denegación de servicio en la capa de enlace: caso y estudio

En muchas ocasiones he podido comprobar como importantes compañías gastaban inmensas cantidades de dinero en proteger sus servicios y a sus usuarios con Firewalls, Proxys, WAF, sistemas de IDS/IPS o Sistemas Antivirus.

Pero estas organizaciones descuidaban uno de los niveles OSI más importantes y al mismo tiempo más peligrosos.

Les presento un caso real y además reciente, de como de una forma trivial podemos dejar fuera de servicio la electrónica de red de acceso de una organización, aprovechándonos de una mala configuración de los protocolos de capa 2.

Situándonos en el escenario

Organización con gran número de dispositivos de conmutación, con gran número de bocas de red distribuidas, con enlaces redundantes  y corriendo Rapid Spanning Tree por Vlan (PVST) para la gestión de los mismos.

¿Qué pasaría si en una de estas bocas de red, muy accesible, nos colocan un pequeño Switch y crean un bucle (conectado un cable al mismo switch). ?

Resumiendo, dos opciones:

• Opción 1: Que nos enteremos y que NO afecte al servicio de acceso a red.
• Opción 2: Que nos enteremos, porque el acceso a red y servicios se ha degradado totalmente.

Efectivamente, lo que ocurrió fue la opción 2.

Causa de la degradación

Switch marca "SMC EZ 10/100 FS8" conectado en una boca de red, donde hay conectada una impresora. 

La impresora estaba conectada al Switch SMC.

El Switch tenía un bucle creado mediante un cable conectado a dos bocas del mismo Switch SMC.

Consecuencia: El bucle  había originado un comportamiento no deseado en la infraestructura de red,  provocando la degradación de la red de conmutación de la organización.

Aislando el problema

El objetivo era saber por qué teníamos gran parte de la electrónica de red de conmutación con un consumo de CPU próximo al 90-99%.

Algunos comandos (entorno Cisco) que nos serán de utilidad en esta fase y que lanzaremos sobre los equipos de conmutación:

• sh processes cpu
• sh platform health
• sh platform cpu packet statistics
• show int | include L2|line|broadcast
• sh spanning-tree summary 

En primer lugar inspeccionamos el Switch principal (Raíz) de la topología STP:

SWITCH-1#show process cpu sorted

CPU utilization for five seconds: 99%/0%; one minute: 99%; five minutes: 99%

 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process

  60  18529067772414577280          0 87.23% 87.25% 87.27%   0 Cat4k Mgmt LoPri

  59   1872485651550907609        120  8.06%  8.14%  8.18%   0 Cat4k Mgmt HiPri

 130   531021332 251741291       2109  1.11%  1.02%  1.01%   0 Spanning Tree   

  67     4762577 517956708          9  0.87%  0.82%  0.83%   0 Net Input       

 247    75702196 284781432        265  0.47%  0.25%  0.24%   0 SNMP ENGINE     

 123    935342912630865096          0  0.39%  0.32%  0.32%   0 IP Input        

 245    31245958 560690000         55  0.23%  0.09%  0.08%   0 IP SNMP         

 242    456475303968996231          0  0.23%  0.23%  0.23%   0 HSRP Common 

En este caso, el proceso que presenta alto consumo de CPU es Cat4k Mgmt LoPri.

Este proceso gestiona procesos en colas de menor prioridad, por lo que el consumo elevado de este proceso no afecta temporalmente al rendimiento general de la red, pero la degradación se palpa conforme el tiempo va pasando.

Continuamos buscando más información con el fin de aislar el problema:

SWITCH-1#sh platform health

SWITCH-1#show platform health

                     %CPU   %CPU    RunTimeMax   Priority  Average %CPU  Total

                     Target Actual Target Actual   Fg   Bg 5Sec Min Hour  CPU

K5CpuMan Review       30.00  82.19     30     27  100  500   92  84   35  110195:14

El proceso K5CpuMan lleva a cabo el reenvío de paquetes. Este tipo de proceso hace uso de las colas y de CPU. Un alto consumo de CPU en este proceso es causado por tráfico.

Revisamos los  interfaces que puedan estar generando excesivo tráfico para tratar de ver por donde esta llegando ese tráfico anómalo.

Para ello podemos habilitar el siguiente debug:

SWITCH-1#debug platform packet all count (podemos estar tranquilos, no va a cargar la red más de lo que ya esta).

Y a continuación revisamos las estadísticas:

Para ver que interfaces generan el tráfico:

SWITCH-1#show platform cpu packet statistics

Packets Received at CPU per Input Interface

Interface              Total           5 sec avg 1 min avg 5 min avg 1 hour avg

---------------------- --------------- --------- --------- --------- ----------

Te1/1                              207         0         0         0        207

Te1/2                                1         0         0         0          1

Te1/5                                8         0         0         0          8

Te1/6                               89       0 0   0      7  

Gi2/2                                9         0         0         0          9

Gi2/3                                9         0         0         0          9

Gi2/4                               77911         0         0        27      77911 ----> Extraño

Gi2/5                                4         0         0         0          4

Gi2/6                              154         0         0         0        154

Fa5/4                                3         0         0         0          3

Fa5/9                                1         0         0         0          1

Fa5/12                               2         0         0         0          2

Fa5/26                               1         0         0         0          1

Gi6/2                               24         0         0         0         24

Gi6/4                                5         0         0         0          5

Gi6/5                              218         0         0         0        218

Gi6/9                                1         0         0         0          1

Gi6/11                               2         0         0         0          2

Gi6/15                               4         0         0         0          4

Gi6/16                               8         0         0         0          8

Gi6/17                               1         0         0         0          1

Gi6/24                               4         0         0         0          4

Gi6/29                               1         0         0         0          1

Gi6/34                               1         0         0         0          1

Gi3/3                                1         0         0         0          1

Gi3/4                                7         0         0         0          7

Gi4/3                                8         0         0         0          8

Gi4/4                               17         0         0         0         17

Por lo tanto tenemos que el enlace Gi2/4 presenta un número de paquetes fuera de lo común.

Este enlace conecta con un Switch de agregación (SWITCH-2).

Accedemos a SWITCH-2 de agregación y verificamos algunos resultados:

SWITCH-2#show process cpu sorted

CPU utilization for five seconds: 99%/29%; one minute: 53%; five minutes: 21%

 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process 

 227    26850445 208406606        128 32.47% 17.74%  5.61%   0 Spanning Tree    

 207       28730      8910       3224 15.51%  7.80%  2.10%   0 SpanTree Helper

Aparentemente un proceso de STP está generando un tráfico anómalo, normalmente estos casos suelen ser debidos a bucles en la red no gestionados de forma correcta por STP.

Echamos un vistazo a posible tráfico broadcast/multicast en alguno de los interfaces:

SWITCH-2#show int | include L2|line|broadcast

GigabitEthernet1/0/14 is up, line protocol is up (connected) 

     Received 30519 broadcasts (30513 multicasts)

GigabitEthernet1/0/15 is up, line protocol is up (connected) 

     Received 85059 broadcasts (9571 multicasts)

GigabitEthernet1/0/16 is up, line protocol is up (connected) 

     Received 455336 broadcasts (250841 multicasts)

GigabitEthernet1/0/17 is up, line protocol is up (connected) 

     Received 31154766 broadcasts (21930539 multicasts)

GigabitEthernet1/0/18 is down, line protocol is down (notconnect) 

     Received 0 broadcasts (0 multicasts)

GigabitEthernet1/0/19 is up, line protocol is up (connected) 

     Received 2708 broadcasts (68 multicasts)

Podemos apreciar como el interface 1/0/17 presenta una cantidad desproporcional de tráfico broadcast/multicast.

La interfaz 1/0/17 es un puerto de usuario final, por lo tanto, cabe de esperar que en la toma de red hay algo conectado que está originando el problema.

Efectivamente, ahí teníamos el desaguisado, Switch SMC colgando de la boca y con un bucle.

Eliminando el bucle del Switch, el problema se solventó de inmediato.

Accediendo al Switch de acceso y revisando la configuración del puerto 1/0/17, podemos comprobar donde tenemos el problema:

SWITC-2#sh run interface gigabitEthernet 1/0/17

Building configuration...

Current configuration : 134 bytes

!

interface GigabitEthernet1/0/17

 description D1217

 switchport access vlan 236

 switchport mode access

 spanning-tree portfast

end

Un puerto de usuario final con portfast habilitado y el cual no está protegido de forma adecuada.

Port Fast es una característica destinada a reducir los tiempos de transición de estados en STP.
Permite pasar directamente a "forwanding" sin pasar por el resto de estados, lo que permite  al puerto estar operativo para transmitir prácticamente de forma inmediata.

Por otro lado, Port Fast impide el reenvio de tramas BPDU de tipo TCN.

Analizando el ataque

Vamos a analizar que ocurrió y que mejor que reproducir nosotros el ataque, utilizaremos Wireshark y los debugs de la electrónica de acceso.

Un poco de teoría primero.

Spanning-tree protocol (STP) IEEE 802.1 D

En redes conmutadas, donde se necesita disponibilidad a nivel de enlace se requiere de un mecanismo que evite la aparición de bucles en la red.

Ahí aparece el protocolo Spanning-Tree Protocol (STP).

A grandes rasgos, STP es un protocolo que permite evitar bucles en la capa 2 en una red conmutada, para ello dispone de un mecanismo de comunicación (Bridge Protocolo Data Units BPDU) que permite a los switches participantes intercambiar información.

Un bucle en el nivel 2 puede hacer que el uso de tráfico Broadcast/Multicast se intensifique de forma exponencial (las conocidas tormentas de broadcast), debido a que las tramas broadcast son restransmitidas por un Switch a través de todos sus puertos y de manera ininterrumpida (no existe campo de TTL).

Spanning-Tree basa su operativa en el intercambio de tramas multicast denominadas bridge protocol data units (BPDU) las cuales permiten crear y mantener una topología libre de bucles en todo momento.

Tenemos dos tipos de  BPDU:

• BPDU de configuración: Permiten calcular la topología de spanning-tree libre de bucles.
• TCN BPDU (Topology Change Notificaction): Permiten  anunciar cambios en la topología de la red.

En una topología ya convergente, las BPDUs son enviadas por el switch raíz de acuerdo al intervalo "hello" (2 segundos por defecto).

Los switches no raíz las reciben, procesan, modifican y las vuelven a propagar.

RSTP Rapid Spanning-Tree (802.1w)

Rapid STP es una variante del estándar original STP, cuyo objetivo principal es mejorar los tiempos de convergencia ante  cambios de topología de la red de conmutación.

Escenario simulado

Con esta básica introducción, nos montamos la siguiente maqueta: 

Conectamos un equipo con Wireshark al switch  SMC de tal forma que podamos capturar tráfico centrándonos sobre todo en tráfico STP.

Utilizaremos Wireshark para observar que nos llega cuando estamos conectados al Switch SMC.



Podemos en la captura tráfico STP que es enviado, a través del puerto 1/0/17 del Switch de acceso.

Si recordamos la teoría, podemos observar que la prioridad del Switch raíz es 4096.

Un dato interesante es que se está corriendo Rapid Spanning Tree Per Vlan, lo podemos ver en el campo info:

RST / 4096 / 236

• 236 es el id de VLAN
• RST Rappid Spanning Tree.

Examinando el contenido del paquete STP

Podemos ver los Flags de las BPDU, información del Root identifier (Switch Raíz de la topología) y del Bridge Identifier ( el Switch de acceso que nos está enviando esta información).

Para el atacante esta información ya es de interés, es decir, tenemos un puerto de red accesible, el cual está anunciado paquetes BPDU.

Echando un vistazo al SWITCH-2 de acceso:

CPU utilization for five seconds: 10%/0%; one minute: 8%; five minutes: 14%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
   4    63631515   2920229      21789  1.43%  0.70%  0.82%   0 Check heaps    
 124        3063      2134       1435  1.11%  0.38%  0.09%   1 SSH Process    
 227    27445063 211144839        129  0.63%  0.24%  1.93%   0 Spanning Tree  
  92    13534617    670038      20199  0.63%  0.21%  0.17%   0 HULC Tcam Memory
 160     4966914   1340110       3706  0.15%  0.06%  0.08%   0 HQM Stack Proces

Media de consumo de CPU entorno al 10-14%.

SWITCH-2#sh spanning-tree interface gigabitEthernet 1/0/17 detail
 Port 17 (GigabitEthernet1/0/17) of VLAN0236 is designated forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.17.
   Designated root has priority 4332, address 5475.d071.5000
   Designated bridge has priority 33004, address 001b.5388.df00
   Designated port id is 128.17, designated path cost 4
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   The port is in the portfast mode
   Link type is point-to-point by default
   BPDU: sent 928, received 0

• Puerto en modo forwarding.
• El número de BPDUs enviadas 928 y recibidas 0.

Tramas broadcast/multicast en la interfaz 1/0/17:

SWITCH-2#show int | include L2|line|broadcast

GigabitEthernet1/0/15 is up, line protocol is up (connected)
     Received 8 broadcasts (0 multicasts)
GigabitEthernet1/0/16 is up, line protocol is up (connected)
     Received 115 broadcasts (67 multicasts)
GigabitEthernet1/0/17 is up, line protocol is up (connected) 
     Received 20 broadcasts (10 multicasts)
GigabitEthernet1/0/18 is down, line protocol is down (notconnect)
     Received 0 broadcasts (0 multicasts)



Vamos a revisar ahora el Switch raíz:

CPU utilization for five seconds: 21%/0%; one minute: 22%; five minutes: 23%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
  59   8945109783006552387          0 11.11% 11.12% 11.21%   0 Cat4k Mgmt HiPri
  60  26049994133371194120          0  8.31%  8.31%  9.08%   0 Cat4k Mgmt LoPri
 130   618519052 281410288       2197  0.95%  1.05%  1.05%   0 Spanning Tree  
 123   1114350623121139203          0  0.23%  0.26%  0.28%   0 IP Input      
 242    53624052 318563339        168  0.15%  0.21%  0.22%   0 HSRP Common    


Interfaz gi2/4 enlace con SWITHC-2:

SWITCH-1#show int | include L2|line|broadcast
GigabitEthernet2/3 is up, line protocol is up (connected)
     Received 3 broadcasts (3 multicasts)
GigabitEthernet2/4 is up, line protocol is up (connected) 
     Received 100 broadcasts (95 multicasts)
GigabitEthernet2/5 is up, line protocol is up (connected)
     Received 249 broadcasts (234 multicasts)
GigabitEthernet2/6 is up, line protocol is up (connected)


Se observa un comportamiento, en general, normal.

Del lado del atacante, observando los paquetes STP recibidos en el puerto de acceso puede llevar a pensar varias cosas:

• El administrador de la red, corre RSTP por Vlan en su red de conmutación.
• Nuestro equipo está conectado en la VLAN 236.
• Si es un puerto de acceso y corre RSTP, posiblemente tendrá configurado portfast para mejorar la convergencia y posiblemente dispondrá de las medidas adecuadas para evitar bucles en su red.
• Mi equipo está recibiendo tramas BPDU en un puerto de acceso, puede que las medidas de seguridad de STP no estén correctamente implementadas.

Lanzando el ataque

Conectamos el Switch SMC no gestionado a la boca de red correspondiente con el puerto 1/0/17 y creamos un bucle manual en el switch SMC.


En Wireshark, observamos como el tráfico broadcast gracias al bucle se incrementa exponencialmente.

De la misma forma el tráfico multicast STP se incrementa exponencialmente.

Ahora vemos algo diferente en cuanto a STP: Estamos recibiendo tramas STP con root id  4096 y con root id 32768, pero las tramas BPDU no son de tipo TCN.


En el SWITCH-2 donde hemos conectado el Switch SMC y hemos hecho el bucle:


SWITCH-2# show spanning-tree interface gigabitEthernet 1/0/17 detail


 Port 17 (GigabitEthernet1/0/17) of VLAN0236 is backup blocking 
   Port path cost 19, Port priority 128, Port Identifier 128.17.
   Designated root has priority 33004, address 001b.5388.df00
   Designated bridge has priority 33004, address 001b.5388.df00
   Designated port id is 128.17, designated path cost 0
   Timers: message age 1, forward delay 0, hold 0
   Number of transitions to forwarding state: 5
   Link type is point-to-point by default
   BPDU: sent 2513973, received 489360


El estado del puerto ha cambiado de Forwarding a backup blocking, en cualquier caso, este estado sigue permitiendo el envío y recepción de BPDUs.

Observamos el tráfico capturado:

Basicamente estamos haciendo sudar al spanning-tree del SWITCH-2, la boca 1/0/17 está recibiendo las propias BPDUs que él propio Switch está enviado por ese puerto.

¿Por qué ocurre esto?

Porque hay un bucle creado intencionadamente en un Switch no gestionado, que cuelga de la boca 1/0/17, la cual está configurada además con PortFast.

Porftast no tiene estados intermedios, de bloqueo  a forwarding directamente, por lo que cualquier tráfico lo reenvía automáticamente.

Y es que un puerto con PortFast no espera que tengamos un switch conectado  y enviando BPDUs, indicativo de un posible bucle

Con esta situación el Switch SMC reenvía por todos sus puertos todas las tramas BPDUs y broadcast que le llegan y gracias al bucle el tráfico se intensifica, por lo que las BPDUs recibidas desde el Switch de acceso por el Switch SMC, esté último, las vuelve a reenviar por todos sus puertos y por lo tanto, las vuelve a recibir el Switch de Acceso (SWITCH-2) por la boca 1/0/17, lo que está provocando este comportamiento y dando lugar a una denegación de servicio en toda regla.

En SWITCH-2 observamos que la CPU se ha puesto al 99%:

CPU utilization for five seconds: 99%/29%; one minute: 53%; five minutes: 21%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
 227    26850445 208406606        128 32.47% 17.74%  5.61%   0 Spanning Tree  
 207       28730      8910       3224 15.51%  7.80%  2.10%   0 SpanTree Helper

Spanning-Tree de SWITCH-2 tiene que gestionar la cantidad masiva de BPDUs que le están entrando.


Gran cantidad de broadcast y multicast recibidos sobre la interfaz e incrementándose: 

SWITH-2#show int | include L2|line|broadcast

GigabitEthernet1/0/15 is up, line protocol is up (connected)
     Received 8 broadcasts (0 multicasts)
GigabitEthernet1/0/16 is up, line protocol is up (connected)
     Received 115 broadcasts (67 multicasts)
GigabitEthernet1/0/17 is up, line protocol is up (connected) 
     Received 16343195 broadcasts (9117785 multicasts)
GigabitEthernet1/0/18 is down, line protocol is down (notconnect)
     Received 0 broadcasts (0 multicasts)

En el SWITCH-1 (Switch raíz):

SWITCH-1#show process cpu sorted

CPU utilization for five seconds: 99%/0%; one minute: 99%; five minutes: 99%

 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process

  60  18529067772414577280          0 87.23% 87.25% 87.27%   0 Cat4k Mgmt LoPri

  59   1872485651550907609        120  8.06%  8.14%  8.18%   0 Cat4k Mgmt HiPri

Gran cantidad de Broadcast/Multicast en la interfaz de enlace con el SWITCH-2 e incrementándose:

SWITH-2#show int | include L2|line|broadcast

GigabitEthernet2/4 is up, line protocol is up (connected) 
     Received 65568 broadcasts (65368 multicasts)


GigabitEthernet2/3 is up, line protocol is up (connected)
     Received 3 broadcasts (3 multicasts)
GigabitEthernet2/4 is up, line protocol is up (connected) 
     Received 66620 broadcasts (66223 multicasts)
GigabitEthernet2/5 is up, line protocol is up (connected)
     Received 249 broadcasts (234 multicasts)



GigabitEthernet2/3 is up, line protocol is up (connected)
     Received 4 broadcasts (4 multicasts)
GigabitEthernet2/4 is up, line protocol is up (connected) 
     Received 67711 broadcasts (67064 multicasts)
GigabitEthernet2/5 is up, line protocol is up (connected)
     Received 362 broadcasts (333 multicasts)


Implementando mecanismos de seguridad en la capa de acceso


STP no implementa mecanismos de autentificación, por lo tanto, tras analizar la forma en la que hemos conseguido degradar la red, está claro que se deben implementar mecanismos de seguridad que impidan que los puertos de acceso envíen o al menos reciban tramas BPDU.


Existen diferentes mecanismos de seguridad que se pueden implementar en una topología STP.

En el caso que nos ocupa, hubiera bastado con añadir el comando "bpduguard enable"  a la configuración del puerto de acceso:

interface GigabitEthernet1/0/17

 description D1217

 switchport access vlan 236

 switchport mode access

 spanning-tree portfast
 spanning-tree bpduguard enable
end

bpduguard enable: impide la retransmisión de BPDUs.


Un puerto de acceso donde se conecta un equipo final de usuario nunca debería recibir BPDUs.

Si el puerto 1/0/17 recibe una BPDU, automáticamente el puerto entrará en un estado de "err-disabled".

Lo que deshabilita el tráfico y requiere la acción manual para volver a recuperar el estado del puerto.

La solución es puntual, para el caso presentado.

Podríamos mejorar la seguridad del puerto implementando port security:

interface GigabitEthernet1/0/17

 description D1217

 switchport access vlan 236

 switchport mode access

 spanning-tree portfast
 switchport port-security 
 switchport port-security mac-address aaaa:12aa:cccc (mac de equipo).
 spanning-tree bpduguard enable
end

Por otro lado, otra de las medidas de seguridad más interesantes en el nivel de acceso a tener en cuenta es el protocolo 802.1x, del cual hablaremos en otro capítulo.

Conclusiones

Es importante testear nuestra red en el nivel enlace: una fantástica herramienta para ello es Yersinia.

Y finalmente, como hemos visto, del mismo modo que una aplicación Web presenta puntos de entrada para el usuario, en general variables, que deben ser saneadas para evitar su compromiso, la capa de acceso es el punto de entrada de un usuario a la red, la cual de la misma forma debe asegurarse para evitar el compromiso de nuestras infraestructuras.