6.4. Identificación de Tormentas de Red con Wireshark

UF1794 | Diagnosticando el colapso de la red

graph TD subgraph Red_con_Bucle ["Red con Bucle Físico (Sin STP)"] SW1["Switch 1"] SW2["Switch 2"] PC["PC"] PC -- "Paquete Broadcast (ARP)" --> SW1 SW1 -- "Inunda todos los puertos" --> SW2 SW2 -- "Inunda todos los puertos" --> SW1 loop[Bucle Infinito] SW1 -- "Reenvía" --> loop SW2 -- "Reenvía" --> loop loop --> SW1 loop --> SW2 end subgraph Analisis_Wireshark ["Análisis en Wireshark"] Filtro["Filtro: eth.dst == ff:ff:ff:ff:ff:ff"] Resultado["Resultado:
Miles de paquetes ARP por segundo
Red saturada al 100%"] end Red_con_Bucle -->|"Captura de Tráfico"| Analisis_Wireshark style loop fill:#e74c3c,color:white style Filtro fill:#3498db,color:white

1. ¿Qué es una Tormenta de Red?

Una tormenta de red es uno de los fallos más catastróficos que pueden ocurrir en una red de Capa 2. Se produce cuando un paquete de difusión (broadcast o multicast) entra en una red con un bucle físico no gestionado (sin STP/MRP). El primer switch inunda el paquete por todos sus puertos. El segundo switch lo recibe y lo vuelve a inundar, devolviéndolo al primero, que lo vuelve a inundar. Este proceso se repite exponencialmente, y en menos de un segundo, la red se satura al 100% con copias del mismo paquete. Las CPUs de todos los dispositivos (PLCs, HMIs, switches) se colapsan intentando procesar este diluvio de datos inútiles, y la comunicación útil se detiene por completo.



2. Tormenta de Broadcast vs. Tormenta de Multicast

Para un técnico de UF1794, es crucial diferenciar el origen de la tormenta:

  • Tormenta de Broadcast: Es la más común. Es causada por paquetes enviados a la dirección MAC de difusión universal: ff:ff:ff:ff:ff:ff. El protocolo ARP es el principal culpable. Si un dispositivo busca una IP y la red tiene un bucle, su petición ARP puede tumbar la planta.
  • Tormenta de Multicast: Es más sutil y específica de entornos OT. El tráfico de E/S de EtherNet/IP, por defecto, utiliza direcciones multicast. Si los switches de la red no tienen activada y bien configurada la función IGMP Snooping, tratarán ese tráfico multicast como si fuera broadcast, inundándolo por todos los puertos y creando una tormenta si existe un bucle.


3. Detectando Tormentas con Filtros de Wireshark

El primer síntoma de una tormenta es que la captura de Wireshark se llena de miles de paquetes idénticos en un instante. Para confirmar la sospecha, usamos filtros de visualización:

  • Para tormentas de Broadcast: eth.dst == ff:ff:ff:ff:ff:ff. Este filtro te mostrará únicamente los paquetes enviados a la dirección de difusión. Si la lista se sigue llenando a una velocidad endiablada, has encontrado el problema. A menudo, se combina con arp (arp and eth.dst == ff:ff:ff:ff:ff:ff) para confirmar que es una tormenta ARP.
  • Para tormentas de Multicast: eth.dst[0] & 1. Este es un filtro de máscara de bits muy potente. Le dice a Wireshark que muestre cualquier trama cuyo primer bit del primer byte de la MAC de destino sea '1', que es la definición técnica de una dirección multicast.


4. Cuantificando el Daño: IO Graphs y Endpoints

Una vez aplicado el filtro, podemos usar las herramientas estadísticas de Wireshark para visualizar la magnitud del desastre:

  1. Gráficos de E/S (Statistics > IO Graph): Esta es la herramienta más visual. En el eje Y, selecciona "Packets/Tick" y en el eje X, ajusta el intervalo a 0.1 segundos. Una red sana puede tener 100-500 paquetes por segundo. Una red bajo una tormenta de broadcast mostrará un pico vertical y sostenido de decenas de miles de paquetes por segundo.
  2. Puntos Finales (Statistics > Endpoints): Abre la pestaña "Ethernet". Esta ventana te muestra una lista de todas las direcciones MAC que han enviado o recibido tráfico, y cuenta el número de paquetes para cada una. En una tormenta de broadcast, verás la dirección ff:ff:ff:ff:ff:ff en la parte superior de la lista con un contador de paquetes astronómico.

Estas herramientas no solo confirman la tormenta, sino que te permiten crear un informe técnico con datos objetivos para justificar la parada de la máquina y la corrección del bucle de red.

Ilustración conceptual de una tormenta de broadcast girando en un bucle entre dos switches, con un gráfico de tráfico saturado.
Figura 1: El electrocardiograma de una red muerta. Un gráfico de E/S (IO Graph) de Wireshark durante una tormenta de broadcast. La línea se dispara verticalmente a miles de paquetes por segundo y se mantiene, indicando que la red está completamente saturada y no puede procesar tráfico útil.
Fuente: Elaboración propia / Licencia: CC BY-NC 4.0.

📝 Evaluación Técnica: Diagnóstico de Tormentas

1. ¿Cuál es la causa raíz de una tormenta de broadcast en una red Ethernet de Capa 2?

2. Sospechas que hay una tormenta de broadcast en tu red. ¿Qué filtro de visualización de Wireshark es el más directo y eficaz para aislar y confirmar este tipo de tráfico?

3. En una red EtherNet/IP, ¿qué función de los switches gestionables es absolutamente crítica para prevenir las tormentas de multicast generadas por el tráfico de E/S?

🤖 Ejercicio Práctico 6: Detector de Tormentas con Scapy

Objetivo: Programar un sistema de alerta temprana que detecte una tormenta de broadcast en tiempo real.

Copia el siguiente *prompt* y pégalo en un modelo de IA (como ChatGPT, Gemini o Claude).

Actúa como un desarrollador de sistemas de detección de intrusiones (IDS) para redes OT. Escribe un script en Python que utilice la librería `scapy` para detectar una tormenta de broadcast. El script debe: 1. Inicializar un contador de paquetes y una marca de tiempo. 2. Definir una función de callback que se ejecute por cada paquete capturado. 3. Dentro de la función, comprobar si la dirección MAC de destino es la de broadcast (`ff:ff:ff:ff:ff:ff`). 4. Si es un paquete de broadcast, incrementar el contador. 5. Comprobar si ha pasado más de un segundo desde la última marca de tiempo. Si es así, verificar si el contador de paquetes de broadcast supera un umbral (ej. 1000 paquetes/segundo). 6. Si se supera el umbral, lanzar una alerta en mayúsculas: "¡¡¡ALERTA: TORMENTA DE BROADCAST DETECTADA!!!". 7. Reiniciar el contador y la marca de tiempo para el siguiente segundo. 8. Iniciar la captura con `sniff`. Comenta el código explicando cómo este simple script es la base de los sistemas de monitorización de red que protegen las plantas de producción.