¿Qué es un ataque TCP SYN-ACK Flood? | Backscatter de SYN-ACK reflejado explicado

Un TCP SYN-ACK Flood reflejado es una técnica DDoS en la que un atacante falsifica la dirección IP de una víctima como origen de paquetes TCP SYN enviados a un gran número de servidores de terceros, causando que esos servidores no involucrados envíen sus respuestas SYN-ACK a la víctima en lugar de al atacante. La víctima recibe una inundación de paquetes SYN-ACK no solicitados que nunca pidió, consumiendo ancho de banda entrante y forzando a los dispositivos con estado a clasificar tráfico que no coincide con ninguna conexión local.

Resumen rápido — El atacante nunca contacta a la víctima directamente. Envía paquetes SYN con la IP falsificada de la víctima como origen a muchos servidores públicos no involucrados (“reflectores”). Cada reflector, creyendo que recibió un request de conexión legítimo, responde con un SYN-ACK, pero lo envía a la dirección falsificada, es decir, a la red de la víctima. La víctima queda enterrada bajo un volumen de paquetes SYN-ACK de IP que nunca contactó, ninguno de los cuales corresponde a ninguna conexión que iniciara. A diferencia del SYN Flood clásico, que agota la cola de conexiones, el SYN-ACK Flood reflejado principalmente agota el ancho de banda entrante y la capacidad de inspección con estado. La mitigación depende de descartar los SYN-ACK que no coincidan con un SYN saliente que la víctima realmente envió, más filtrado anti-spoofing del lado del proveedor (BCP38/uRPF) para reducir el pool de reflectores que los atacantes pueden abusar.

Última actualización: 2026-08-08

Cómo funciona un TCP SYN-ACK Flood reflejado

El atacante selecciona una gran lista de servidores TCP alcanzables en internet; estos se convierten en reflectores involuntarios. Cualquier servidor que responda a paquetes SYN en un puerto abierto califica.
El atacante envía un paquete TCP SYN al puerto abierto de cada reflector, pero fija la dirección IP de origen a la IP de la víctima en lugar de la propia.
Cada reflector procesa el SYN como un request de conexión normal, asigna una entrada de conexión semi-abierta, y responde con un SYN-ACK, dirigido al origen falsificado, que es la víctima.
La víctima recibe un SYN-ACK para una conexión que nunca inició. Su stack TCP o firewall no encuentra ningún SYN saliente coincidente en su tabla de estado y clasifica el paquete como no solicitado/fuera de estado.
Multiplicado a través de miles de reflectores y repetido a alta frecuencia, la víctima recibe un gran volumen de tráfico SYN-ACK entrante simultáneamente, ninguno del cual requirió que el atacante enviara tráfico directamente a la víctima.
Las propias conexiones semi-abiertas de los reflectores eventualmente hacen timeout en su extremo ya que la víctima falsificada nunca envía el ACK final, pero el daño a la víctima ocurre por el propio backscatter de SYN-ACK, no por el estado de cola interno de los reflectores.

Tráfico normal (la víctima inicia una conexión):
Víctima ──SYN──▶ Servidor remoto
Víctima ◀─SYN-ACK── Servidor remoto   [el SYN-ACK coincide con el propio SYN saliente de la Víctima]
Víctima ──ACK──▶ Servidor remoto      [Conexión establecida]

SYN-ACK Flood reflejado:
Atacante ──SYN (origen falsificado = IP de la Víctima)──▶ Reflector A
Atacante ──SYN (origen falsificado = IP de la Víctima)──▶ Reflector B
Atacante ──SYN (origen falsificado = IP de la Víctima)──▶ Reflector C
   ... [miles de reflectores, repetido continuamente]

Reflector A ──SYN-ACK──▶ Víctima   [la Víctima nunca envió este SYN]
Reflector B ──SYN-ACK──▶ Víctima   [la Víctima nunca envió este SYN]
Reflector C ──SYN-ACK──▶ Víctima   [la Víctima nunca envió este SYN]
   ... [la víctima recibe backscatter de SYN-ACK de cada reflector]

Resultado: el ancho de banda entrante y la capacidad de inspección con estado
        de la víctima se consumen por paquetes SYN-ACK que no coinciden con ninguna conexión local

¿Cuál ataque de flag TCP es este? Tabla comparativa

Ataque	Patrón de flag	Recurso objetivo	¿Requiere spoofing?	¿Requiere sesión establecida?	Señal de detección típica
SYN Flood	Solo SYN, enviado directamente a la víctima	Cola de backlog SYN / memoria TCB	Opcional	No	SYN_RECV alto, baja tasa de completitud de handshake
TCP ACK Flood	Solo ACK, enviado directamente a la víctima	Búsqueda de estado firewall/CPU	Opcional	No	Alto volumen de ACK en estado inválido
TCP SYN-ACK Flood reflejado (este artículo)	SYN-ACK, enviado por reflectores, llegando no solicitado	Ancho de banda/PPS entrante + inspección con estado en la víctima	Requerido — SYN falsificado enviado a reflectores de terceros	No	SYN-ACK entrante sin SYN saliente local correspondiente, de muchas IP de origen distintas (los reflectores)
TCP Out-of-State Flood	Flags mezclados que violan la transición esperada	CPU y agitación de conntrack/firewall con estado	Opcional	No	Contadores de estado INVALID crecientes
TCP Invalid Packet	Combinaciones de flags ilegales, checksums malos	CPU de parser de paquetes/IDS-IPS	Opcional	No	Fallos de checksum, alertas de flag ilegal

El rasgo definitorio del SYN-ACK Flood reflejado es que la víctima nunca ve un solo paquete controlado por el atacante; cada paquete que la víctima recibe viene de un servidor de terceros legítimo y no involucrado. Esto es fundamentalmente distinto de un SYN-ACK flood directo, en el que un atacante (o botnet) envía paquetes SYN-ACK directamente a la víctima sin ningún reflector involucrado; una variante directa principalmente estresa la lógica de clasificación fuera de estado de la víctima sin amplificar el volumen a través de terceros.

Variaciones del ataque

SYN-ACK flood directo (sin reflexión). Una botnet envía paquetes SYN-ACK directamente a la víctima, sin reflectores de terceros en la ruta. Esto carece de los beneficios de amplificación y atribución por IP spoofing de la variante reflejada pero es más simple de ejecutar ya que no depende de encontrar reflectores que respondan.

SYN-ACK Flood reflejado combinado con protocolos de amplificación. Los atacantes a veces corren SYN-ACK floods reflejados junto con amplificación basada en UDP (DNS, NTP) contra la misma víctima para estresar tanto el manejo de estado TCP como el ancho de banda bruto simultáneamente. Consulta Tipos de ataques DDoS para la categoría de amplificación.

Pools de reflectores rotativos. Las campañas sofisticadas rotan a través de grandes listas de reflectores para evitar que cualquier red de reflectores individual detecte y limite la tasa del tráfico SYN falsificado que inadvertidamente está retransmitiendo.

Señales de detección y telemetría

# Resumen de sockets — los SYN-ACK floods reflejados típicamente no mueven SYN_RECV
ss -s

# Contadores TCP — vigila anomalías en SYN-ACK recibidos sin SYN salientes coincidentes
nstat -az

# Conntrack: los paquetes SYN-ACK sin entrada NEW/ESTABLISHED coincidente se clasifican INVALID
conntrack -L | grep -i syn_recv
conntrack -S

# Regla nftables para contar/registrar SYN-ACK no solicitados
nft add rule inet filter input tcp flags syn,ack / syn,ack ct state invalid counter log prefix "unsolicited-synack "

# Equivalente de iptables
iptables -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate INVALID -j LOG --log-prefix "unsolicited-synack "

Indicador	Normal	Bajo SYN-ACK Flood reflejado
Volumen de SYN-ACK entrante	Proporcional a los SYN salientes enviados	Pico agudo, desproporcionado a cualquier actividad de SYN saliente
Diversidad de IP de origen de SYN-ACK entrantes	Pequeña, ligada a servidores que realmente contactaste	Muy alta — cientos o miles de IP de reflector distintas
Clasificación INVALID de conntrack para paquetes SYN-ACK	Cercana a cero	En aumento continuo
Conteo de estado SYN_RECV	Sin afectar	Sin afectar — este no es un ataque de agotamiento de cola
Correlación con el log de SYN saliente	Cada SYN-ACK entrante coincide con un SYN saliente reciente	La mayoría de los SYN-ACK entrantes no tienen ningún SYN saliente coincidente

El análisis de flujo (NetFlow/IPFIX/sFlow) es particularmente efectivo aquí: correlaciona el volumen de paquetes SYN-ACK entrantes contra el volumen de paquetes SYN salientes que tu propia red generó en la misma ventana. Un desequilibrio grande y sostenido es la firma más clara del backscatter de SYN-ACK reflejado.

Técnicas de mitigación

Técnica	Cómo funciona	Efectividad
Inspección con estado que descarta SYN-ACK no coincidente	Descarta cualquier SYN-ACK entrante que no corresponda a un SYN saliente rastreado localmente	Alta — apunta directamente al mecanismo del ataque
BCP38 / uRPF en el edge de red (del lado del proveedor)	Evita que las IP de origen falsificadas salgan de las redes en primer lugar, reduciendo el pool de reflectores usables a nivel de industria	Alta a largo plazo, pero depende de la adopción fuera de tu control
Scrubbing upstream / absorción de ancho de banda	Filtra el backscatter de SYN-ACK de alto volumen antes de que llegue a tu uplink	Alta para inundaciones de reflexión a gran escala
Rate limiting de SYN-ACK entrante por diversidad de origen	Marca y limita cuando el tráfico SYN-ACK llega de un número inusualmente grande de IP de origen nuevas y distintas	Media-alta
Terminación con estado en el edge/proxy	El origen solo recibe tráfico de sesiones que el propio edge completó; los SYN-ACK no solicitados se filtran upstream	Muy alta

Errores comunes y correcciones

Error	Impacto	Corrección
Confundir esto con un SYN Flood clásico	Se despliegan SYN Cookies pero abordan el recurso equivocado — este ataque no toca la cola de backlog SYN	Confirma si la anomalía es SYN entrante o SYN-ACK entrante antes de elegir la mitigación
Bloquear las IP de origen del tráfico SYN-ACK	Las IP de origen son servidores de terceros inocentes, no el atacante; bloquearlos puede romper servicios legítimos de los que dependes	Filtra con base en la discordancia de tabla de estado, no en la identidad de la IP de origen
Asumir que BCP38 da protección inmediata	BCP38 depende de la adopción por otras redes y proveedores, no solo la propia	Combina con filtrado local con estado; no trates a BCP38 como una defensa independiente completa
Sin correlación entre logs de SYN saliente y SYN-ACK entrante	El backscatter pasa desapercibido hasta que aparecen síntomas de ancho de banda o CPU	Instrumenta la correlación de flujo entre los volúmenes de SYN saliente y SYN-ACK entrante
Ignorar reportes de abuso de reflector	Tus propios servidores, si están mal configurados como reflectores abiertos, pueden usarse contra otras víctimas	Aplica la misma higiene anti-spoofing y rate limiting a los servicios orientados a salida

Cómo implementarlo con Azion

La red distribuida de Azion puede filtrar el tráfico SYN-ACK reflejado antes de que consuma el ancho de banda o la capacidad de procesamiento de tu origen:

DDoS Protection está diseñado para detectar volumen anómalo de SYN-ACK entrante y otros patrones de reflexión de Capa 3/4 en el edge, antes de que el tráfico llegue a tu origen.
Network Shield aplica reglas de filtrado que pueden descartar paquetes que no coincidan con ninguna conexión saliente rastreada.
Firewall permite reglas personalizadas para bloqueo basado en estado y tasa de tráfico no solicitado.
WAAP combina protección de red y de capa de aplicación para equipos que necesitan cobertura más amplia.

Como Azion puede terminar y rastrear el estado TCP en el edge, el backscatter de SYN-ACK no solicitado dirigido a un origen detrás de Azion generalmente se filtra antes de que llegue a la infraestructura de origen. La protección real depende de tu configuración específica; valida el comportamiento contra tu perfil de tráfico.

Recursos relacionados

Preguntas frecuentes

¿Qué es un ataque TCP SYN-ACK Flood reflejado? Es una técnica DDoS donde un atacante falsifica la dirección IP de una víctima en paquetes SYN enviados a muchos servidores de terceros. Esos servidores responden con paquetes SYN-ACK dirigidos a la IP falsificada —la víctima— inundándola con tráfico no solicitado que nunca pidió.

¿En qué se diferencia un SYN-ACK Flood reflejado de un SYN Flood? Un SYN Flood envía paquetes SYN directamente a la víctima, agotando su cola de conexiones con sesiones semi-abiertas. Un SYN-ACK Flood reflejado no envía tráfico directamente a la víctima; abusa de servidores de terceros como reflectores, y la víctima solo recibe sus respuestas SYN-ACK, que principalmente consumen ancho de banda y capacidad de inspección con estado en lugar de la cola de conexiones.

¿Un SYN-ACK Flood reflejado siempre requiere IP spoofing? Sí, por definición. El ataque depende de forjar la IP de la víctima como dirección de origen en los paquetes SYN enviados a los reflectores. Sin spoofing, los reflectores enviarían sus respuestas SYN-ACK de regreso al atacante en lugar de a la víctima.

¿Cuál es la diferencia entre un SYN-ACK flood reflejado y uno directo? Un SYN-ACK Flood reflejado usa servidores de terceros para generar el tráfico SYN-ACK que golpea a la víctima, requiriendo IP spoofing contra esos reflectores. Un SYN-ACK flood directo tiene una botnet o atacante enviando paquetes SYN-ACK directamente a la víctima sin ningún reflector involucrado, lo que es más simple pero no amplifica el volumen de la misma forma.

¿En qué se diferencia esto de un TCP ACK Flood? Un TCP ACK Flood envía paquetes solo-ACK directamente a la víctima para conexiones inexistentes, costando principalmente CPU en búsquedas de estado. Un SYN-ACK Flood reflejado envía paquetes SYN-ACK que se originan de servidores de terceros inocentes, no del atacante, y cuesta principalmente ancho de banda entrante y capacidad de inspección con estado en la víctima.

¿Las SYN Cookies pueden detener un SYN-ACK Flood reflejado? No. Las SYN Cookies protegen la propia cola de backlog SYN del objetivo contra el SYN Flood. Un SYN-ACK Flood reflejado no apunta a la cola SYN en absoluto; la víctima nunca envió un SYN para disparar la lógica de cookie en primer lugar, ya que está recibiendo SYN-ACK no solicitados, no requests SYN.

¿Cómo detecto el backscatter de SYN-ACK reflejado? Correlaciona el volumen de SYN saliente contra el volumen de SYN-ACK entrante usando datos de flujo (NetFlow/IPFIX/sFlow) o logs de conntrack. Un desequilibrio grande y sostenido —muchos más SYN-ACK entrantes que SYN salientes que realmente enviaste— combinado con alta diversidad de IP de origen en el tráfico SYN-ACK es la señal más clara.

¿Los servidores que envían el tráfico de flood SYN-ACK son maliciosos? No. Los reflectores típicamente son servidores legítimos y no involucrados que responden normalmente a lo que parece un request de conexión válido. Son participantes involuntarios; el acto malicioso es el SYN inicial con IP falsificada del atacante, no la respuesta del reflector.

¿BCP38 previene por completo los ataques SYN-ACK Flood reflejados? No. BCP38 (RFC 2827) filtra el tráfico falsificado que sale de una red, pero debe adoptarse ampliamente a través de internet para ser efectivo; la adopción de una sola organización no detiene a los atacantes de falsificar a través de redes que no lo han implementado. Reduce el pool de reflectores usables con el tiempo en lugar de eliminar la técnica de inmediato.

¿Mi propia infraestructura puede usarse como reflector en este tipo de ataque contra alguien más? Sí, si tus servidores responden a paquetes SYN de cualquier origen sin validación adicional, pueden ser abusados como reflectores contra una víctima de terceros. Aplicar la misma higiene anti-spoofing y rate limiting recomendada para la defensa también reduce esta exposición.

Fuentes

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

Únete a nuestra comunidad