¿Qué es un Mixed Flood (ataque DDoS multi-vector)?

Un mixed flood (o ataque DDoS multi-vector) es una técnica de denegación de servicio que combina dos o más vectores de ataque distintos —por ejemplo, un UDP flood volumétrico, un SYN flood a nivel de protocolo, y un HTTP flood a nivel de aplicación— lanzados de forma simultánea o secuencial contra el mismo objetivo. Como cada vector estresa una capa y recurso distinto (ancho de banda, tablas de conexión, cómputo de aplicación), combinarlos vence defensas ajustadas para detectar y mitigar solo un tipo de ataque a la vez, y obliga a los defensores a correlacionar señales entre capas en lugar de depender de un único umbral.

Resumen rápido — Los ataques DDoS multi-vector mezclan inundaciones volumétricas (UDP, ICMP, amplificación), inundaciones de agotamiento de protocolo/estado (SYN, FIN, RESET, ACK-PSH), y ataques de capa de aplicación (HTTP flood, Slowloris) en una campaña coordinada. Cada vector apunta a un recurso distinto, así que una defensa ajustada solo para detener un vector —scrubbing de ancho de banda, SYN cookies, o una regla de WAF— deja los demás sin mitigar, y la combinación a menudo causa más daño que la suma de los vectores ejecutados individualmente. La detección requiere correlacionar telemetría entre las capas de red, transporte y aplicación en lugar de confiar en cualquier umbral de un solo vector. La mitigación requiere una arquitectura de defensa en profundidad y en capas que abarque scrubbing, protección de estado de protocolo, y controles de capa de aplicación, idealmente aplicada en un edge de red distribuido antes de que el tráfico llegue al origen.

Última actualización: 2026-08-08

Cómo funciona un Mixed Flood

Por qué los atacantes combinan vectores

Un ataque de un solo vector es comparativamente fácil de defender una vez identificado: una inundación volumétrica se absorbe con capacidad de scrubbing, un SYN flood se neutraliza con SYN cookies, un HTTP flood se limita con una regla de rate-limiting de WAF. Combinar vectores cambia la economía de la defensa de tres formas:

1. Diversificación de recursos — el ancho de banda, las tablas de estado del kernel/firewall, y el cómputo de aplicación son cada uno finitos e independientemente agotables. Atacar los tres a la vez obliga al defensor a mantener capacidad de reserva en cada capa simultáneamente, no solo en la que tiene la carga visible más pesada.
2. Dilución de la detección — los equipos de seguridad y los sistemas automatizados a menudo priorizan primero el vector más visible o de mayor volumen. Un UDP flood grande puede atraer atención y esfuerzo de mitigación mientras un ataque de capa de aplicación de menor volumen y más difícil de detectar, contra un endpoint de login o checkout, procede por debajo.
3. Huecos de secuenciación de mitigación — algunas defensas son más efectivas cuando se aplican en un orden específico (por ejemplo, absorber el tráfico volumétrico antes de que el estado a nivel de protocolo tenga oportunidad de acumularse). Los atacantes que cambian la mezcla de vectores durante el curso de un ataque pueden forzar a los defensores a reajustar múltiples sistemas repetidamente.

Ejemplo de línea de tiempo de ataque multi-vector

Línea de tiempo de ataque DDoS multi-vector (ilustrativa):

T+0:00   Comienza el UDP Flood
         → paquetes UDP de puerto aleatorio saturan el ancho de banda entrante
         → Capa 3/4, apunta a la capacidad de red
         Ver: ¿Qué es un ataque UDP Flood?

T+0:05   Se agrega ICMP Flood
         → solicitudes de eco ICMP de alta tasa suman presión al ancho de banda
         → también consume CPU del router/firewall procesando ICMP
         Ver: ¿Qué es un ataque ICMP Flood?

T+0:10   Comienza SYN Flood concurrentemente
         → paquetes SYN falsificados apuntan a la tabla de conexiones TCP
         → explota capacidad liberada por el ajuste de absorción volumétrica
         Ver: ¿Qué es un ataque SYN Flood?

T+0:20   Los defensores mitigan el volumen de UDP/ICMP en el edge de red
         → las gráficas de ancho de banda se normalizan visiblemente
         → el SYN flood continúa, ahora menos visible en medio de una alerta "resuelta"

T+0:25   Se lanza HTTP Flood contra un endpoint de API específico
         → requests de bajo volumen y apariencia legítima
         → se mezcla con el tráfico residual, evade el alertamiento basado en volumen
         Ver: Tipos de ataques DDoS (ataques de capa de aplicación)

T+0:40   Se agrega TCP RESET Flood contra la tabla de conexiones del load balancer
         → agita el estado de conntrack mientras el HTTP flood continúa por debajo
         Ver: ¿Qué es un ataque TCP RESET Flood?

Resultado: ninguna defensa de una sola capa fue suficiente por sí sola; el
           impacto real y sostenido del ataque vino del vector menos
           monitoreado (HTTP flood) que persistió después de que "el DDoS"
           pareció mitigado

Esto es ilustrativo más que una plantilla fija; las campañas multi-vector reales varían ampliamente en secuenciación, selección de vector y duración, y algunas lanzan todos los vectores simultáneamente en lugar de por etapas.

Combinaciones multi-vector comunes

Detección: por qué fallan los umbrales de un solo vector

La detección tradicional de DDoS a menudo se construye alrededor de umbrales por vector: alertar si el tráfico UDP excede X Gbps, alertar si la tasa de SYN excede Y paquetes/segundo, alertar si la tasa de requests HTTP excede Z requests/segundo por endpoint. Los ataques multi-vector están específicamente estructurados para mantener cada vector individual por debajo, o solo brevemente por encima, de su propio umbral mientras el efecto combinado en la infraestructura compartida —enlaces de ancho de banda, CPU de firewall, tablas de conexión de load balancer, pools de threads del servidor de aplicación— excede la capacidad.

# Contadores de paquetes y bytes por protocolo (útil pero incompleto por sí solo)
nstat -az

# Resumen de estado TCP — correlacionar con el volumen de UDP/ICMP de la misma ventana
ss -s

# Estado de la tabla conntrack de Netfilter — recurso compartido entre protocolos
conntrack -L | wc -l
cat /proc/sys/net/netfilter/nf_conntrack_count

# Exportación NetFlow/sFlow para correlación entre protocolos a escala
# (ejemplo: análisis de flujo basado en nfcapd/nfdump)
nfdump -R /flows -o extended 'proto udp or proto icmp or proto tcp' \
  -s srcip/bytes -n 20

# Correlacionar registros de flujo entre protocolos dentro de la misma ventana de
# tiempo para detectar actividad de vector simultánea que ningún contador individual revela por sí solo

Una detección multi-vector efectiva depende de correlacionar telemetría entre la capa de red (NetFlow/sFlow, contadores de interfaz), la capa de transporte (tablas de estado TCP, conntrack), y la capa de aplicación (logs de WAF, tasa de requests por endpoint) dentro de la misma ventana de tiempo, en lugar de evaluar cada una de forma aislada.

Mitigación: defensa en profundidad

Por qué se requiere arquitectura en capas

Ninguna técnica de mitigación individual aborda cada vector en un mixed flood. El scrubbing y la distribución Anycast absorben el tráfico volumétrico pero no hacen nada por un request de capa de aplicación bien formado y de bajo volumen. Las SYN cookies neutralizan los SYN floods pero no tienen efecto sobre los floods de FIN, RESET o ACK-PSH, y mucho menos los HTTP floods. Una regla de rate-limiting de WAF protege endpoints específicos pero no puede absorber un UDP flood de varios gigabits. La mitigación efectiva requiere que cada capa ejecute su propia defensa apropiada concurrentemente:

Construir detección correlacionada multi-capa

Como la característica definitoria de un mixed flood es que ninguna capa individual de datos cuenta la historia completa, la arquitectura de detección debería:

1. Agregar telemetría de registros de flujo de red, contadores de estado de capa de transporte, y logs de aplicación en una vista de serie de tiempo común.
2. Rastrear el número de vectores anómalos concurrentes como su propia métrica: un aumento de uno a tres anomalías activas simultáneamente es en sí mismo una señal más fuerte que la magnitud de cualquier vector individual.
3. Evitar resolver alertas automáticamente en el momento en que se mitiga el vector más visible (usualmente el de mayor ancho de banda); verificar que las métricas de transporte y capa de aplicación también hayan regresado a la línea base.
4. Correlacionar la telemetría de DDoS con telemetría de seguridad más amplia (SIEM, EDR, logs de identidad), ya que las campañas DDoS multi-vector a veces se usan como distracción junto con otra actividad de intrusión.

Errores comunes

Cómo implementarlo con Azion

Los mixed floods requieren defensa en cada capa que tocan, idealmente aplicada antes de que el tráfico llegue al origen:

• DDoS Protection brinda detección y mitigación siempre activa y automatizada a través de vectores volumétricos y de protocolo en el edge de red distribuido de Azion.
• Network Shield aplica reglas programables a nivel de red usando listas basadas en IP, CIDR, ASN, y gestionadas por Azion para bloquear orígenes asociados con tráfico de inundación volumétrica y de protocolo.
• Firewall permite filtrado personalizado basado en reglas para anomalías de estado de conexión y basadas en tasa a través de tráfico TCP y UDP.
• WAF aborda el componente de capa de aplicación de una campaña mezclada, incluyendo HTTP floods y abuso de requests dirigido a endpoints.
• WAAP combina protecciones de red, protocolo y capa de aplicación en una sola postura, que es la arquitectura mejor adaptada para campañas mezcladas y multi-vector específicamente porque ningún módulo individual necesita cubrir todas las capas solo.

Como Azion termina las conexiones e inspecciona el tráfico a través de puntos de presencia distribuidos que abarcan las capas de red, transporte y aplicación, una campaña multi-vector se enfrenta con la defensa correspondiente en cada capa de forma concurrente, en lugar de requerir que un defensor una manualmente herramientas separadas volumétricas, de protocolo y de capa de aplicación.

Recursos relacionados

• ¿Qué es un ataque DDoS?
• Tipos de ataques DDoS
• ¿Qué es un ataque SYN Flood?
• ¿Qué es la protección y mitigación DDoS?
• ¿Qué es una botnet DDoS?
• Azion DDoS Protection

Preguntas frecuentes

¿Qué es un mixed flood o ataque DDoS multi-vector? Un mixed flood es una campaña DDoS que combina dos o más vectores de ataque distintos —como inundaciones volumétricas de UDP o ICMP, floods de protocolo como SYN o RESET, y HTTP floods de capa de aplicación— lanzados juntos o en secuencia contra un solo objetivo, para vencer defensas ajustadas para solo un vector a la vez.

¿Por qué los atacantes combinan vectores en lugar de usar una sola inundación grande? Combinar vectores diversifica los recursos bajo ataque (ancho de banda, tablas de conexión, cómputo de aplicación), diluye el foco de detección hacia el vector más visible, y puede explotar huecos en la secuenciación de la mitigación. A menudo logra un impacto más sostenido que una sola inundación más grande de un tipo.

¿En qué se diferencia un ataque multi-vector de un simple DDoS de alto volumen? Un ataque de un solo vector de alto volumen, incluso a gran escala, apunta a un tipo de recurso y se neutraliza una vez que ese recurso está protegido; por ejemplo, scrubbing de ancho de banda para un UDP flood grande. Un ataque multi-vector apunta a varios tipos de recursos simultáneamente, así que proteger uno no resuelve los demás.

¿Un ataque multi-vector puede incluir tanto floods TCP como UDP a la vez? Sí, esta es una de las combinaciones más comunes. Un UDP flood satura el ancho de banda mientras un flood concurrente de SYN, FIN, RESET o ACK-PSH apunta a las tablas de estado de conexión TCP, forzando a los defensores a atender tanto la capacidad de red como el agotamiento de estado de protocolo al mismo tiempo.

¿Por qué fallan los umbrales de detección de un solo vector contra mixed floods? Los umbrales típicamente se establecen por protocolo o por métrica —ancho de banda UDP, tasa de SYN, requests HTTP por segundo. Los ataques multi-vector están estructurados para que cada vector individual se mantenga cerca o por debajo de su propio umbral mientras su efecto combinado en la infraestructura compartida excede la capacidad, así que ningún umbral individual se activa de forma confiable.

¿Cómo difiere la detección correlacionada del monitoreo DDoS estándar? La detección correlacionada agrega datos de flujo de red, contadores de estado de capa de transporte, y logs de aplicación en una vista de serie de tiempo compartida y rastrea el número de vectores anómalos concurrentes como su propia señal, en lugar de evaluar cada protocolo o capa de forma independiente.

¿Mitigar el vector más grande en un mixed flood significa que el ataque terminó? No necesariamente. Los atacantes a veces dependen de que los defensores declaren victoria una vez que se absorbe el vector más visible y de mayor ancho de banda, mientras un vector de protocolo o capa de aplicación de menor volumen continúa causando daño. La mitigación completa requiere verificar que cada capa haya regresado a la línea base.

¿Cuál es la relación entre el DDoS multi-vector y las botnets DDoS? Las botnets brindan la infraestructura de origen distribuida que hace práctico lanzar múltiples vectores simultáneos a escala; distintos subconjuntos de dispositivos comprometidos pueden asignarse a distintos vectores (UDP flood desde un segmento, HTTP flood desde otro) bajo un comando y control coordinado.

¿Los ataques de amplificación pueden ser parte de una campaña multi-vector? Sí. Las técnicas de amplificación de DNS, NTP u otras se usan frecuentemente como el componente volumétrico de un ataque mezclado, combinadas con un flood a nivel de protocolo (como SYN flood) o un ataque de capa de aplicación dirigido a un endpoint específico.

¿Qué arquitectura defiende mejor contra ataques DDoS multi-vector? Una arquitectura de defensa en profundidad y en capas que aplique scrubbing volumétrico, protección de estado de protocolo (como SYN cookies y validación de flags con estado), y controles de capa de aplicación (WAF, rate limiting) de forma concurrente, idealmente en un edge de red distribuido que inspeccione el tráfico en todas las capas antes de que llegue al origen.

Fuentes:

• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.
• NIST. “Guide to DDoS Attacks.” SP 800-83.
• IETF. “Transmission Control Protocol (TCP).” RFC 9293. 2022.
• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP 38). 2000.