Un ataque IGMP flood es una técnica de denegación de servicio basada en protocolo que envía un alto volumen de mensajes Internet Group Management Protocol —típicamente reportes de membresía o requests de unión— para agotar las tablas de estado de grupo multicast y los recursos de CPU de los routers y switches en la ruta hacia un objetivo. A diferencia de las inundaciones volumétricas que saturan el ancho de banda, un IGMP flood apunta a la memoria finita que los dispositivos de red asignan para rastrear la membresía de grupo multicast.
Resumen rápido — IGMP (Internet Group Management Protocol) le permite a los hosts decirle a los routers y switches a qué grupos multicast quieren recibir tráfico. Un IGMP flood abusa de esto enviando grandes volúmenes de mensajes de unión o reporte de membresía, a menudo con direcciones de grupo falsificadas o aleatorizadas, forzando a los dispositivos a crear y rastrear grandes cantidades de entradas de estado multicast hasta que se agota la memoria o la CPU. Es un ataque de protocolo de Capa 3 más bien legado, con el mayor impacto contra routers y switches más antiguos con tablas de estado multicast pequeñas o configuraciones de IGMP snooping sin restricciones; el equipo de red moderno con rate limiting de IGMP y límites de grupo es en gran medida resistente, pero los entornos multicast mal configurados siguen expuestos.
Última actualización: 2026-08-08
Cómo funciona el ataque
IGMP (definido en RFC 3376 para la versión 3) es el protocolo que usan los hosts para unirse y dejar grupos de multicast IP. Cuando un host quiere recibir tráfico multicast para un grupo, envía un Reporte de Membresía IGMP; los routers y switches usan esto para construir y mantener estado de reenvío multicast, y los switches usan IGMP snooping para decidir qué puertos deberían recibir qué flujos multicast.
Operación IGMP normal:Host ──Reporte de Membresía IGMP (unirse al grupo 239.1.1.1)──▶ Router/SwitchRouter/Switch: crea una entrada de estado multicast para 239.1.1.1 en ese puerto
IGMP flood:Atacante ──Reporte IGMP (grupo 239.1.1.1)──▶ RouterAtacante ──Reporte IGMP (grupo 239.1.1.2)──▶ RouterAtacante ──Reporte IGMP (grupo 239.1.1.3)──▶ Router... [miles a millones de uniones de grupo distintas o falsificadas] │ ▼La tabla de estado multicast del router/switch se llena; se gasta CPUprocesando cada reporte; el reenvío multicast y unicast legítimo se degradaComo cada reporte IGMP puede solicitar un grupo multicast distinto, una inundación fuerza al dispositivo a asignar una nueva entrada de tabla de estado por grupo en lugar de reutilizar una existente, lo que agota la capacidad de tabla mucho más rápido de lo que lo haría repetir el mismo request. En los switches, esto también presiona las tablas de IGMP snooping, que mapean membresías de grupo a puertos físicos; una tabla de snooping saturada puede forzar al switch a inundar el tráfico multicast a todos los puertos, degradando la red más amplia además del propio servicio multicast.
Contexto histórico
Los ataques IGMP flood surgieron a medida que los despliegues multicast (usados para IPTV, videoconferencia, y distribución de datos de mercado financiero) se hicieron más comunes a principios/mediados de los años 2000, junto con un interés más amplio en los ataques de agotamiento de estado de protocolo tras la visibilidad de los SYN floods a finales de los años noventa. Las implementaciones tempranas de routers y switches a menudo usaban tablas de grupo multicast de tamaño fijo sin límites por origen o por puerto, haciéndolas fáciles de agotar con un volumen modesto de tráfico IGMP manipulado. Los proveedores agregaron posteriormente rate limiting de IGMP, aplicación de conteo máximo de grupos por puerto, y controles de snooping más estrictos como características estándar en el equipo de red de nivel empresarial.
IGMP Flood vs. Floods generales de protocolo
| Aspecto | IGMP Flood | Flood general de protocolo (ej. SYN Flood) |
|---|---|---|
| Recurso explotado | Tabla de estado de grupo multicast, CPU del switch | Tabla de estado de conexión, memoria del kernel |
| Capa de protocolo | Capa 3 (red/plano de control) | Capa 4 (transporte) |
| Objetivo típico | Routers, switches, redes con multicast habilitado | Cualquier host o middlebox que maneje TCP |
| Prevalencia hoy | Baja — mayormente relevante para redes intensivas en multicast | Todavía común a través de internet |
| Defensa principal | Rate limiting de IGMP, límites de conteo de grupo, controles de snooping | SYN cookies, rate limiting de conexión |
| Alcance de despliegue | Redes multicast empresariales, de ISP, y de IPTV | Cualquier infraestructura orientada a internet |
Por qué los sistemas modernos son en gran medida inmunes
Los routers y switches modernos implementan límites por puerto y por dispositivo en el número de grupos multicast que rastrearán, junto con rate limiting de consultas y reportes IGMP, lo que limita qué tan rápido un atacante puede crear nuevas entradas de estado. Las implementaciones de IGMP snooping en los switches empresariales actuales también validan las tasas de reporte y pueden descartar requests excesivos de un solo puerto u origen antes de que agoten la tabla de snooping.
El riesgo residual se concentra en:
- Switches legados o de nivel consumidor sin límites configurables de grupo multicast
- Infraestructura multicast de ISP e IPTV donde grandes cantidades de puertos orientados a suscriptores deben procesar tráfico IGMP real, haciendo más difícil ajustar el rate limiting sin afectar a los espectadores legítimos
- Redes empresariales mal configuradas que dejan los límites de consulta e IGMP snooping en valores por defecto permisivos
Detección y mitigación
- Rate limiting de IGMP — limita el número de mensajes IGMP procesados por segundo, por puerto o por origen, en routers y switches
- Límites de conteo de grupo multicast — aplica un número máximo de membresías de grupo multicast concurrentes por puerto para acotar el crecimiento de la tabla de estado
- Refuerzo de IGMP snooping — configura los switches para validar y limitar la tasa de actualizaciones de la tabla de snooping en lugar de aceptar uniones ilimitadas
- Control de acceso en interfaces con multicast habilitado — restringe qué interfaces o VLAN pueden enviar reportes IGMP, particularmente en segmentos no confiables u orientados al usuario
- Monitoreo de la utilización de la tabla de estado multicast — alerta sobre crecimiento inusual en los conteos de membresía de grupo o tasas de mensaje IGMP en relación con la línea base
Cómo implementarlo con Azion
El IGMP flood apunta a infraestructura de red específica de multicast en lugar de cargas de trabajo web y de API típicas orientadas a HTTP/HTTPS, así que la mitigación es principalmente una preocupación de diseño de red y configuración de router/switch para organizaciones que corren servicios multicast. Para aplicaciones y API orientadas a internet detrás de Azion, DDoS Protection y Network Shield pueden ayudar a filtrar tráfico de protocolo de Capa 3 anómalo y paquetes malformados antes de que lleguen a la infraestructura de origen, reduciendo la exposición a ataques de abuso de protocolo en general. Las reglas de Firewall se pueden usar para restringir qué protocolos y patrones de tráfico pueden llegar al origen, agregando una capa de política para entornos donde no se espera tráfico multicast.
Recursos relacionados
- ¿Qué es un ataque DDoS?
- Tipos de ataques DDoS
- ¿Qué es la protección y mitigación DDoS?
- ¿Qué es un ataque ICMP Flood?
- Azion DDoS Protection
Preguntas frecuentes
¿Qué es un ataque IGMP flood? Un IGMP flood envía un alto volumen de mensajes Internet Group Management Protocol, usualmente reportes de membresía para muchos grupos multicast distintos, para agotar las tablas de estado multicast y la CPU de los routers y switches en la ruta hacia un objetivo.
¿El IGMP flood sigue siendo una amenaza hoy? Es una amenaza de baja prevalencia hoy. El equipo de red empresarial moderno aplica rate limiting de IGMP y límites de conteo de grupo por puerto, dejando a los switches legados, las redes multicast mal configuradas, y los despliegues multicast de IPTV o ISP a gran escala como la principal exposición residual.
¿En qué se diferencia el IGMP flood de un ICMP flood? Un ICMP flood envía volúmenes de tráfico relacionado con ping para agotar el ancho de banda o la CPU en un host objetivo. Un IGMP flood en cambio apunta al estado de membresía de grupo multicast mantenido por routers y switches, una superficie de ataque más acotada y especializada ligada a redes con multicast habilitado.
¿Para qué se usa IGMP en operación normal? IGMP le permite a los hosts informar a los routers y switches locales a qué grupos de multicast IP quieren recibir tráfico, que es la base para entregar contenido multicast como IPTV, streams de video en vivo, y algunos feeds de datos de mercado financiero de forma eficiente solo a los receptores interesados.
¿El IGMP flood requiere IP spoofing? No. Como el ataque apunta a la capacidad de tabla de estado en lugar de depender de respuestas sin contestar, un atacante puede generar grandes volúmenes de requests de unión de grupo distintos desde direcciones de origen reales o falsificadas; el spoofing puede ayudar a ocultar el origen pero no se requiere para que la inundación sea efectiva.
¿Un firewall puede detener un IGMP flood? Un firewall o router con filtrado consciente de IGMP puede limitar la tasa o descartar mensajes IGMP excesivos por origen o por interfaz, lo cual es efectivo contra muchos IGMP floods. Es menos efectivo si la inundación se origina de muchos hosts distintos y de apariencia legítima a través de una red grande.
¿Qué tipo de dispositivos están más expuestos al IGMP flood? Los routers y switches legados o de nivel consumidor sin límites configurables de grupo multicast, junto con la infraestructura de ISP e IPTV que debe procesar grandes volúmenes de tráfico IGMP genuino de suscriptores, son las categorías de dispositivo más expuestas.
¿Cómo se defienden las redes multicast contra el IGMP flood sin bloquear a los espectadores legítimos? Los operadores típicamente fijan conteos máximos de grupo por puerto con base en el uso legítimo esperado, aplican límites de tasa de consulta y reporte de IGMP ajustados por encima de la demanda pico normal, y monitorean por crecimiento anómalo repentino en la membresía de grupo en lugar de bloquear IGMP por completo.
¿El IGMP flood afecta al tráfico unicast en la misma red? Sí, indirectamente. Si la tabla de snooping multicast de un switch se agota, algunos switches recurren a inundar el tráfico multicast a todos los puertos, consumiendo ancho de banda y CPU de switch adicionales que pueden degradar el tráfico unicast que comparte la misma infraestructura.
¿El IGMP flood se clasifica como un ataque volumétrico o de protocolo? Generalmente se clasifica como un ataque de protocolo (agotamiento de estado) en lugar de uno volumétrico, ya que su efecto principal es agotar la capacidad finita de tabla de estado y los recursos de procesamiento de los dispositivos de red en lugar de saturar el ancho de banda del enlace.
¿Qué RFC define IGMP? IGMPv3, la versión actual, se define en RFC 3376. Las versiones anteriores IGMPv1 e IGMPv2 se definen en RFC 1112 y RFC 2236 respectivamente.
Fuentes
- IETF. “Internet Group Management Protocol, Version 3.” RFC 3376. 2002.
- IETF. “Host Extensions for IP Multicasting.” RFC 1112. 1989.
- IETF. “Internet Group Management Protocol, Version 2.” RFC 2236. 1997.
- NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.