¿Qué es un ataque TCP ACK-PSH Flood?

Un TCP ACK-PSH flood es un ataque DDoS basado en protocolo que envía segmentos TCP con los flags ACK y PSH activados hacia un objetivo, forzando al stack receptor a tratar cada paquete como si portara datos listos para entrega inmediata a la aplicación. Como el flag PSH le indica al receptor que evite el buffering normal y empuje los datos directamente a la capa de aplicación, cada paquete cuesta más CPU y memoria de procesar que un ACK flood simple, incluso cuando el payload está vacío o la conexión no existe.

Resumen rápido — TCP ACK-PSH flood es una variante del ACK flood que agrega el flag PSH (push) a cada paquete. En una conexión real, PSH le indica al stack receptor que entregue los datos en buffer a la aplicación de inmediato en lugar de esperar a llenar un buffer. Cuando los atacantes fijan PSH en inundaciones de paquetes ACK —a menudo para conexiones que nunca existieron— el stack TCP del objetivo todavía realiza una búsqueda de estado de conexión y, en paquetes que parecen coincidir con un estado, trabajo adicional de manejo de buffer. Esto eleva el costo de procesamiento por paquete comparado con un ACK flood simple, presionando la CPU, las tablas de estado de firewall, y los buffers orientados a la aplicación. La mitigación se apoya en inspección con estado, rate limiting, y mover la terminación de TCP a una red edge distribuida.

Última actualización: 2026-08-08

Cómo funciona un TCP ACK-PSH Flood

Los flags ACK y PSH en el header TCP

Los segmentos TCP portan un conjunto de bits de control en el header, definidos originalmente en RFC 793 y consolidados en RFC 9293. Dos de ellos importan aquí:

• ACK (Acknowledgment): activado en casi cada segmento después de que se completa el handshake; confirma la recepción de datos hasta cierto número de secuencia.
• PSH (Push): le señala al stack TCP receptor que cualquier dato en buffer —incluyendo los datos en el segmento actual— debería entregarse a la aplicación de inmediato, en lugar de mantenerse hasta que el buffer de recepción se llene o un timer expire.

En tráfico legítimo, PSH se activa al final de un mensaje lógico (por ejemplo, el segmento final de un request HTTP) para que la aplicación receptora no espere más datos antes de actuar. Combinado con ACK, un segmento ACK-PSH dice: “confirmo tus datos, y aquí hay un payload que debes entregar a la aplicación ahora.”

Flags del header TCP (bits relevantes):
CWR ECE URG ACK PSH RST SYN FIN

Segmento de datos normal durante una sesión:
[ACK]           → confirma datos previos, no requiere flush de payload nuevo
[ACK, PSH]      → confirma datos previos Y hace flush del payload a la aplicación ahora

Por qué la combinación de flags aumenta el costo

Un ACK flood simple fuerza al receptor a buscar el estado de conexión de cada paquete y, en la mayoría de los casos, descartarlo como inválido cuando no existe una conexión coincidente. Un ACK-PSH flood agrega una segunda capa de trabajo:

1. El kernel realiza la misma búsqueda de estado de conexión que un ACK flood (conntrack, netfilter, o las propias tablas del stack TCP).
2. Si el segmento parece coincidir con una conexión establecida —números de secuencia falsificados o secuestrados, o ataques que se apoyan en sesiones reales— el flag PSH fuerza al stack a intentar una copia inmediata de cualquier payload al buffer de recepción de la aplicación y a despertar el proceso de la aplicación, en lugar de permitir que el kernel coalesce o retrase la entrega.
3. Incluso cuando la conexión no existe y el paquete se descarta, algunos middleboxes y firewalls con estado realizan inspección más profunda en combinaciones ACK+PSH porque es más probable que se clasifiquen como “portadoras de datos” y por lo tanto sujetas a reglas adicionales de logging o DPI.

Tráfico normal:
Cliente ──ACK,PSH(datos)──▶ Servidor   [El servidor entrega los datos a la app de inmediato]

Flood ACK-PSH:
Bot 1 (IP falsificada) ──ACK,PSH──▶ Servidor  [búsqueda de estado + intento de manejo de buffer]
Bot 2 (IP falsificada) ──ACK,PSH──▶ Servidor  [búsqueda de estado + intento de manejo de buffer]
Bot 3 (IP falsificada) ──ACK,PSH──▶ Servidor  [búsqueda de estado + intento de manejo de buffer]
... [millones más por segundo]

Resultado: la CPU gastada en búsquedas y rutas de manejo de buffer sube más
           rápido de lo que predeciría solo el conteo de paquetes; la carga
           de inspección de firewall/IDS aumenta

El efecto neto es la misma categoría de daño que un ACK flood: agotamiento de CPU en dispositivos con estado, agitación de tabla de conexión, y overhead de procesamiento en el origen, pero logrado con menos paquetes por unidad de daño, porque cada paquete fuerza más trabajo.

Por qué los atacantes usan payloads pequeños o vacíos

La mayoría del tráfico de ACK-PSH flood porta poco o ningún payload real. El propio flag PSH, no el tamaño del payload, es lo que fuerza el procesamiento inmediato; los atacantes no necesitan paquetes grandes para disparar este comportamiento, lo que mantiene el ataque eficiente en ancho de banda en relación con su impacto de procesamiento.

TCP ACK-PSH Flood vs. Floods relacionados basados en flags

Señales de detección y telemetría

Distinguir el tráfico ACK-PSH flood de sesiones legítimas de alto throughput requiere correlacionar la distribución de flags con el estado de conexión, no solo el volumen de paquetes.

# Resumen de sockets — observa el crecimiento en sockets sin una lectura de aplicación coincidente
ss -ti

# Contadores TCP — segmentos inválidos, resets generados para ACK no coincidentes
nstat -az | grep -i tcp

# Estado y tamaño de la tabla conntrack de Netfilter
conntrack -L | wc -l
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# Contadores de iptables en reglas que coinciden ACK+PSH sin SYN (patrón solo mid-sesión)
iptables -L -v -n --line-numbers

# Distribución de flags en captura de paquetes (solo ventana corta — ataques de PPS alto pueden sobrecargar la captura)
tcpdump -i eth0 -c 20000 'tcp' -nn | awk '{print $0}' | grep -c "P."

Técnicas de mitigación

Edge termination is the most durable defense: cuando una red distribuida completa el handshake TCP y gestiona el estado de sesión en nombre del origen, los paquetes ACK-PSH que no corresponden a una sesión real y validada en el edge nunca llegan en absoluto al stack del origen.

Errores comunes

Cómo implementarlo con Azion

Azion termina las conexiones TCP en el edge de red, lo que cambia dónde se absorbe el tráfico de ACK-PSH flood:

• DDoS Protection brinda detección y mitigación siempre activa para floods basados en protocolo, incluyendo patrones anómalos de ACK/PSH, antes de que el tráfico llegue al origen.
• Network Shield aplica reglas programables a nivel de red, incluyendo listas basadas en IP, CIDR y ASN, para bloquear orígenes asociados con tráfico de inundación.
• Firewall permite reglas personalizadas para filtrado de estado de conexión y basado en tasa en el edge.
• WAAP combina protecciones de red y de capa de aplicación para entornos que enfrentan ataques mezclados.

Como Azion completa y gestiona las sesiones TCP en puntos de presencia distribuidos, la infraestructura de origen solo está expuesta a conexiones ya validadas, reduciendo la superficie para floods de manipulación de flags como ACK-PSH.

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?
• Azion DDoS Protection

Preguntas frecuentes

¿Qué es un ataque TCP ACK-PSH flood? Un TCP ACK-PSH flood envía grandes volúmenes de segmentos TCP con ambos flags ACK y PSH activados hacia un objetivo, a menudo para conexiones que no existen. El flag PSH fuerza al stack receptor a intentar una entrega inmediata de buffer, aumentando el costo de procesamiento por paquete comparado con un ACK flood simple.

¿En qué se diferencia el ACK-PSH flood de un ACK flood simple? Un ACK flood simple solo fuerza una búsqueda de estado de conexión, típicamente barata por paquete. Agregar el flag PSH fuerza al stack receptor a también intentar un push inmediato de cualquier payload a la capa de aplicación, lo que aumenta el costo de CPU y manejo de buffer por paquete incluso a la misma tasa de paquetes.

¿Un ACK-PSH flood requiere un handshake TCP completado? No. La mayoría del tráfico de ACK-PSH flood apunta a conexiones que nunca se establecieron, dependiendo de que el receptor realice una búsqueda de estado y rechace el paquete. El ataque es más dañino cuando puede apoyarse en sesiones reales y activas, pero eso no es un requisito.

¿Cómo difiere el ACK-PSH flood del SYN flood? El SYN flood agota la memoria del kernel creando entradas de conexión semi-abiertas durante el handshake. El ACK-PSH flood apunta a paquetes enviados después de que ocurriría un handshake, agotando CPU en lógica de búsqueda de conexión y manejo de buffer en lugar de memoria en estado semi-abierto. Las SYN cookies, la defensa principal de SYN flood, no mitigan el ACK-PSH flood.

¿Cómo difiere el ACK-PSH flood del TCP FIN o RESET flood? Los floods FIN y RESET apuntan a la lógica de cierre de conexión y a la agitación de tabla conntrack/sesión simulando el cierre de conexión. El ACK-PSH flood simula entrega de datos mid-sesión. Ambas categorías fuerzan búsquedas de estado, pero los floods FIN y RESET específicamente estresan máquinas de estado de cierre, mientras que ACK-PSH estresa el procesamiento de la ruta de datos.

¿Las SYN cookies pueden detener un ACK-PSH flood? No. Las SYN cookies solo afectan el procesamiento en la etapa de handshake (SYN y SYN-ACK). Los ACK-PSH floods apuntan a segmentos que ocurren lógicamente después del handshake, así que evitan por completo la protección de SYN cookies.

¿Por qué los atacantes fijan el flag PSH si el payload está vacío? El propio flag PSH —no el tamaño del payload— dispara la ruta de código de entrega inmediata del stack receptor. Los atacantes obtienen el costo de procesamiento aumentado sin necesitar enviar paquetes grandes, manteniendo el ataque eficiente en ancho de banda.

¿Un firewall con estado puede bloquear un ACK-PSH flood? Sí, para ataques no falsificados y moderadamente distribuidos. Un firewall con estado puede descartar segmentos ACK/PSH que no coincidan con una conexión rastreada antes de que lleguen a la ruta de procesamiento más profunda. Para floods altamente distribuidos y falsificados, la propia tabla de estado del firewall puede convertirse en el cuello de botella, requiriendo mitigación upstream o basada en edge.

¿El ACK-PSH flood es un ataque volumétrico o de protocolo? Es un ataque de protocolo (agotamiento de estado) más que puramente volumétrico. Típicamente requiere mucho menos ancho de banda que un flood volumétrico para causar un impacto medible de CPU y procesamiento, porque el daño viene del costo de procesamiento por paquete en lugar del throughput bruto.

¿Qué telemetría identifica mejor un ACK-PSH flood en progreso? Las señales más confiables son una proporción creciente de paquetes ACK+PSH sin estado de conexión coincidente, crecimiento sostenido en el tamaño de la tabla conntrack, y tiempo de CPU elevado en la ruta de procesamiento de netfilter o del stack TCP en relación con el volumen general de paquetes, en lugar del ancho de banda total por sí solo.

¿La terminación en el edge elimina por completo el riesgo de ACK-PSH flood? La terminación en el edge reduce sustancialmente la exposición porque solo las sesiones validadas y gestionadas por el edge llegan al origen. No elimina la necesidad de rate limiting y detección de anomalías en el propio edge, ya que la infraestructura con estado de la propia red edge todavía debe procesar el tráfico de inundación.

Fuentes:

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