¿Qué es un ataque de connection flood? | Agotamiento de límites de conexiones establecidas

Un ataque de connection flood es una técnica de denegación de servicio que abre y mantiene un número muy grande de conexiones TCP o de capa de aplicación completamente establecidas hacia un objetivo, agotando la capacidad finita de conexiones concurrentes o de tabla de sesiones de load balancers, firewalls o servidores de aplicación, en lugar de explotar una debilidad específica del handshake de un protocolo. Una vez que se alcanza el límite de conexiones, los clientes legítimos nuevos son rechazados aunque el tráfico de ataque en sí pueda parecer completamente válido.

Resumen rápido — Los connection floods completan el handshake TCP completo (y a menudo también el de TLS y aplicación) en cada conexión, y luego mantienen las conexiones abiertas —inactivas o con actividad mínima— hasta que se agota el techo de conexiones concurrentes del objetivo. Esto difiere fundamentalmente de un SYN flood, que nunca completa el handshake y en cambio agota una cola de conexiones semi-abiertas. Los connection floods apuntan a las tablas de sesión de tamaño fijo de los firewalls, a los límites tipo max_connections de los load balancers, y a los pools de workers/threads de los servidores de aplicación. La mitigación combina límites de conexión por IP, recolección más rápida de conexiones inactivas, escalado horizontal de capacidad, y terminación de conexiones en la capa edge que absorbe la concurrencia antes de que llegue al origen.

Última actualización: 2026-08-08

Por qué “completamente establecida” es la distinción clave

Cada pieza de infraestructura que procesa tráfico TCP (firewalls, load balancers, proxies reversos y servidores de aplicación) mantiene alguna forma de tabla de conexión o sesión: una estructura de datos finita que rastrea el estado de cada conexión activa de la que tiene conocimiento. Esa tabla tiene un techo de capacidad fijo, ya sea expresado como el máximo de sesiones concurrentes de un firewall, la configuración max_connections de un load balancer, o el tamaño del pool de threads o workers de un servidor de aplicación.

La característica definitoria de un ataque de connection flood es que no intenta explotar un handshake incompleto o malformado. En cambio, completa el handshake normalmente —el handshake de tres vías de TCP, y a menudo el handshake TLS e incluso un request válido a nivel de aplicación— y luego simplemente mantiene un número muy grande de estas conexiones, con apariencia completamente legítima, abiertas de forma simultánea. El tráfico de ataque pasa cualquier verificación que solo valide la corrección del protocolo; el compromiso es puramente de escala y concurrencia.

Secuencia de connection flood (por conexión, repetida a escala masiva):

Atacante → Objetivo: TCP SYN
Objetivo → Atacante: TCP SYN-ACK
Atacante → Objetivo: TCP ACK                    ← el handshake se completa por completo
[La conexión entra en estado ESTABLISHED, ocupa una entrada en la tabla de sesión]
Atacante: envía datos mínimos o ninguno adicional, o emite keepalives ocasionales
[La conexión permanece ESTABLISHED indefinidamente, o hasta un timeout de inactividad]

Se repite en miles a millones de conexiones de origen
(a menudo vía botnet, para distribuir IP de origen y conteo de conexiones)

Resultado: se alcanza el techo de tabla de sesión / conteo de conexiones
Objetivo: rechaza nuevas conexiones o mantiene una cola de backlog llena,
          porque ya no puede rastrear sesiones legítimas adicionales

Connection Flood vs. SYN Flood

Los connection floods y los SYN floods a menudo se confunden porque ambos agotan una tabla finita al abrir muchas conexiones, pero el estado en el que cada ataque deja esas conexiones —y por lo tanto la defensa requerida— es fundamentalmente distinto.

En la práctica, un SYN flood ataca la puerta principal antes de que dejen entrar a nadie; un connection flood deja entrar a todos por la puerta principal y luego nunca se va, hasta que ya no hay lugar para nadie más. Consulta ¿Qué es un ataque SYN Flood? para el mecanismo del handshake semi-abierto en detalle.

Los connection floods también difieren de los ataques low-and-slow como Slowloris: Slowloris deliberadamente mantiene las conexiones en un estado incompleto a nivel de aplicación (headers parciales) para ocupar un thread de forma económica, mientras que las conexiones de un connection flood típicamente son completas y válidas también a nivel de aplicación; el ataque se apoya en el conteo bruto de conexiones en lugar de la ambigüedad a nivel de protocolo.

Qué componentes de infraestructura se agotan

Los connection floods pueden apuntar al techo de conexiones en varias capas distintas de la pila, y el cuello de botella específico determina qué mitigación es relevante.

Un connection flood dirigido a un load balancer puede agotar su techo de conexiones global sin nunca poner una carga significativa en los servidores de aplicación detrás de él. Por el contrario, una inundación que pasa el load balancer todavía puede agotar el pool mucho más pequeño de un servidor de aplicación tipo thread-por-conexión aunque el propio load balancer tenga bastante margen; por eso la capacidad debe evaluarse en cada capa, no solo en la que enfrenta internet.

Señales de detección y telemetría

Los connection floods son visibles principalmente a través de métricas de conteo de conexiones y concurrencia, más que por tráfico malformado o contenido de request inusual.

# Total de conexiones ESTABLISHED — compara contra la línea base histórica
ss -o state established | wc -l

# Conexiones concurrentes agrupadas por IP de origen — un flood desde una botnet
# modesta a menudo muestra un puñado de IP de origen con conteos de conexión
# desproporcionadamente altos cada una
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Uso de descriptores de archivo para el proceso que sirve
lsof -p <pid> | wc -l

# Load balancer / proxy reverso: conexiones actuales vs. máximo configurado
nginx -T | grep worker_connections

La combinación de alto conteo de conexiones concurrentes con throughput de request desproporcionadamente bajo es la firma más clara de un connection flood, distinguiéndolo de un aumento de tráfico legítimo donde el conteo de conexiones y el volumen de requests suben juntos.

Técnicas de mitigación

1. Límites de conexión concurrente por IP

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 50;
limit_conn_status 429;

Limitar cuántas conexiones concurrentes puede mantener un solo origen restringe directamente cuánto de la tabla de conexiones puede consumir un atacante (o nodo de botnet comprometido), sin afectar necesariamente a usuarios normales que rara vez mantienen docenas de conexiones simultáneas abiertas.

2. Timeouts agresivos de conexión inactiva

keepalive_timeout 15s;

# Kernel de Linux: reduce el tiempo antes de que una conexión TCP inactiva se
# considere muerta y sus recursos se reclamen
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 4

Timeouts de inactividad más cortos reducen cuánto tiempo pueden ocupar espacio en la tabla las conexiones de un atacante sin enviar tráfico significativo, forzándolo a enviar datos reales (elevando su costo y visibilidad) o a reconectarse (lo cual los límites por IP pueden entonces atrapar).

3. Capacidad horizontal y dimensionamiento de la tabla de conexiones

Aumentar el techo de conexiones —tablas de estado de firewall más grandes, max_connections más alto en los load balancers, más workers de servidor de aplicación o una arquitectura orientada a eventos— eleva la barra que el atacante debe superar, aunque es una respuesta de escalado más que una solución estructural, ya que una botnet suficientemente grande todavía puede superar cualquier aumento de capacidad fijo.

4. Distinguir floods inactivos de concurrencia legítima con reglas conductuales

Un WAF o control a nivel de aplicación puede marcar conexiones que permanecen abiertas significativamente más tiempo que la mediana para un endpoint dado, o que muestran actividad de request cercana a cero en relación con su duración de conexión, y aplicar límites o desafíos más estrictos a ese subconjunto en lugar de a todo el tráfico.

5. Terminar conexiones en una capa edge distribuida

Colocar una red distribuida frente al origen significa que la concurrencia bruta de un connection flood se absorbe a través de muchas ubicaciones edge y una gran capacidad de conexión agregada, en lugar de concentrarse contra la tabla de sesión finita de un único origen. Solo las conexiones que el edge reenvía —típicamente un conjunto mucho más pequeño y filtrado— llegan al propio pool de conexiones del origen.

Errores comunes

Cómo implementarlo con Azion

La red edge de Azion termina las conexiones antes del origen, lo que cambia dónde aterriza realmente la concurrencia bruta de un connection flood.

• Firewall puede aplicar límites de conexión concurrente por IP y agregados antes de que el tráfico llegue a la infraestructura de origen
• Network Shield puede ayudar a filtrar y limitar la tasa de intentos de conexión a nivel de red, dependiendo de las Network Lists y reglas configuradas
• DDoS Protection brinda detección siempre activa orientada a patrones de agotamiento basados en conexión, incluyendo connection floods concurrentes a gran escala
• Load Balancer puede ayudar a distribuir las conexiones aceptadas y proteger el propio pool de conexiones del origen de enfrentar directamente la concurrencia de ataque
• WAAP combina estos controles para equipos que quieren WAF, protección DDoS y defensas relacionadas en capas

Como la red distribuida de Azion tiene una capacidad de conexión agregada sustancialmente mayor que un origen único típico, y reenvía al origen solo el tráfico que pasa el filtrado del lado del edge, la concurrencia de un connection flood generalmente se absorbe a través del edge en lugar de concentrarse contra la tabla de sesión del origen.

Recursos relacionados

• ¿Qué es un ataque SYN Flood?
• Ataques Low and Slow
• ¿Qué es un ataque DDoS?
• ¿Qué es un ataque HTTP Flood?
• Azion DDoS Protection
• Azion Network Shield

Preguntas frecuentes

¿Qué es un ataque de connection flood? Un ataque de connection flood abre y mantiene un número muy grande de conexiones completamente establecidas hacia un objetivo, agotando la capacidad finita de conexiones concurrentes de firewalls, load balancers o servidores de aplicación. A diferencia de los ataques que explotan un handshake incompleto, cada conexión en un connection flood típicamente es válida y está completamente establecida.

¿En qué se diferencia un connection flood de un SYN flood? Un SYN flood nunca completa el handshake TCP; deja las conexiones en un estado semi-abierto para agotar una cola de backlog, y a menudo se mitiga con SYN cookies. Un connection flood completa por completo el handshake y mantiene conexiones reales y establecidas abiertas para agotar la tabla de sesión o el pool de conexiones. Las SYN cookies y las defensas de estado semi-abierto no tienen efecto sobre un connection flood porque el handshake ya terminó.

¿Un connection flood requiere IP spoofing? Generalmente no. Como las conexiones deben estar completamente establecidas para consumir espacio en la tabla de sesión en este ataque, el origen típicamente necesita completar un handshake real, algo que las IP de origen falsificadas no pueden hacer de forma confiable. Los connection floods se ejecutan más comúnmente vía botnets usando direcciones IP reales y distintas.

¿Qué componentes de infraestructura puede agotar un connection flood? Cualquier componente que mantenga una tabla de conexión o sesión finita: firewalls con estado, load balancers con un max_connections configurado, proxies reversos limitados por ajustes como worker_connections, servidores de aplicación tipo thread-por-conexión, e incluso los límites de descriptores de archivo del sistema operativo.

¿Cómo se detecta un connection flood en curso? Busca un conteo sostenido y elevado de conexiones ESTABLISHED que sea desproporcionado respecto al throughput real de requests, a menudo concentrado en un subconjunto de IP de origen que mantienen cada una una cantidad inusualmente alta de conexiones concurrentes. Herramientas como ss -o state established y desgloses de conexión por IP son los comandos de diagnóstico principales.

¿El rate limiting de requests por segundo puede detener un connection flood? No directamente. El rate limiting de requests limita cuántos requests puede enviar un origen, pero las conexiones de un connection flood pueden enviar pocos o ningún request en absoluto; el apalancamiento del ataque está en mantener la conexión abierta en sí, no en el volumen de requests que fluyen a través de ella. Los límites de conexión concurrente (por IP y en agregado) son el control más directamente aplicable.

¿Las conexiones inactivas sin ningún dato siguen contando contra los límites de conexión? Sí. La mayoría de las tablas de conexión y sesión cuentan cualquier conexión establecida sin importar el nivel de actividad. Una conexión inactiva sin flujo de datos sigue ocupando una entrada de tabla hasta que se cierra o un timeout de inactividad reclama sus recursos, que es exactamente la mecánica en la que se apoya un connection flood.

¿Aumentar max_connections o el tamaño de la tabla de conexiones es una solución efectiva? Eleva la barra que un atacante necesita superar, y puede ayudar contra inundaciones de menor escala, pero es un aumento de capacidad más que una defensa estructural. Una botnet suficientemente grande todavía puede superar la mayoría de los aumentos de capacidad de un solo origen, así que el ajuste de capacidad debería combinarse con limitación por origen y absorción en el edge en lugar de usarse solo.

¿Un connection flood puede ocurrir sobre TLS/HTTPS? Sí, y puede ser más intensivo en recursos para el objetivo que un connection flood en texto plano, porque cada conexión también puede involucrar un handshake TLS y un estado de sesión negociado, lo que en sí consume CPU y memoria más allá de la entrada base de la tabla de sesión TCP.

¿Cómo se relaciona un connection flood con los ataques low-and-slow como Slowloris? Ambos agotan un recurso finito del servidor manteniendo muchas conexiones abiertas, pero un connection flood típicamente depende del conteo bruto de conexiones con la capa de aplicación a menudo comportándose con normalidad, mientras que Slowloris específicamente mantiene las conexiones en un estado incompleto a nivel de aplicación (headers HTTP parciales) para ocupar un thread con incluso menos conexiones. Consulta Ataques Low and Slow para la categoría más amplia a la que pertenecen estas técnicas.

¿Cuál es la forma más rápida de distinguir un connection flood de un pico de tráfico legítimo? Compara el crecimiento del conteo de conexiones contra el crecimiento del throughput de requests. En un pico legítimo, ambos suben juntos a medida que los usuarios reales hacen requests. En un connection flood, el conteo de conexiones sube abruptamente mientras el throughput de requests se mantiene plano o crece mucho más lento, porque la mayoría de las conexiones están inactivas o casi inactivas.

Fuentes

• IETF. “Transmission Control Protocol.” RFC 793.
• IETF. “Requirements for Internet Hosts — Communication Layers.” RFC 1122 (manejo de estado de conexión).
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.
• CISA. “Understanding Denial-of-Service Attacks.”
• nginx. “Module ngx_http_limit_conn_module.” Documentación oficial.