¿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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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

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 "

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

Errores comunes y correcciones

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

• ¿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 un ataque TCP Out-of-State Flood?
• ¿Qué es un ataque TCP Invalid Packet?

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.”