¿Qué es un ataque TCP RESET Flood?

Un TCP RESET flood (o RST flood) es un ataque basado en protocolo que envía grandes volúmenes de segmentos TCP con el flag RST (reset) activado hacia un objetivo, ya sea para agotar recursos de seguimiento de conexión en un sistema objetivo o, cuando se dirige a una sesión activa específica con un número de secuencia válido, para terminar abruptamente esa sesión por completo. A diferencia de FIN, RST cierra una conexión de inmediato sin un handshake de cierre, lo que lo hace útil para los atacantes tanto como técnica de volumen de denegación de servicio como técnica de precisión de terminación de sesión.

Resumen rápido — Los paquetes TCP RST terminan una conexión de inmediato, sin el intercambio de múltiples pasos requerido por FIN. Un RESET flood explota esto de dos formas distintas: como técnica volumétrica de denegación de servicio que fuerza a los dispositivos con estado a procesar y rastrear grandes cantidades de paquetes RST contra conexiones inexistentes o específicas, y como técnica de secuestro de sesión que inyecta un solo RST falsificado con la secuencia correcta en una sesión activa para terminarla. La primera forma presiona la CPU y las tablas de conexión; la segunda interrumpe sesiones específicas como peerings BGP o conexiones de API de larga duración. La mitigación incluye validación de número de secuencia, filtrado de RST con estado, rate limiting, y terminación TCP basada en edge.

Última actualización: 2026-08-08

Cómo funciona un TCP RESET Flood

El rol de RST en la máquina de estados TCP

El flag RST, definido en RFC 793 y RFC 9293, señala una terminación de conexión abrupta y no negociada. A diferencia de la secuencia de cierre basada en FIN, que requiere que ambos lados intercambien FIN y ACK, un solo RST válido derriba una conexión de inmediato al recibirlo:

Uso normal de RST (legítimo):
Cliente → Servidor: SYN a un puerto cerrado
Servidor → Cliente: RST (no hay listener en este puerto)
[No se crea ninguna conexión]

Uso normal de RST (condición de error):
Una conexión establecida encuentra una violación de protocolo o cierre abrupto
Un lado → Otro lado: RST
[La conexión se destruye de inmediato en ambos extremos]

Un RST se considera válido por el stack receptor si su número de secuencia cae dentro de la ventana de recepción actual de esa conexión (o, en algunas implementaciones conservadoras, coincide exactamente). Esta verificación de validación es el punto de apalancamiento que ambas formas de ataque a continuación intentan explotar o evadir.

Forma 1: RST flood como técnica de denegación de servicio

Un atacante envía un flujo continuo de paquetes RST, típicamente con direcciones IP de origen falsificadas, hacia un objetivo:

Tráfico normal:
Cliente ──RST──▶ Servidor   [El servidor busca la conexión coincidente, termina si es válida]

RST flood (forma DoS):
Bot (IP falsificada: 198.51.100.10) ──RST──▶ Servidor  [búsqueda de estado: sin coincidencia]
Bot (IP falsificada: 198.51.100.11) ──RST──▶ Servidor  [búsqueda de estado: sin coincidencia]
Bot (IP falsificada: 198.51.100.12) ──RST──▶ Servidor  [búsqueda de estado: sin coincidencia]
... [millones más por segundo]

Resultado: la CPU gastada en búsquedas sube; las entradas de tabla de
        conntrack/firewall se agitan; cualquier RST que sí coincida
        con una sesión real la termina de inmediato

Cada paquete RST, coincida o no, fuerza una búsqueda de estado de conexión en el stack receptor o en cualquier firewall inline con estado. A suficiente volumen, esto consume CPU y presiona las tablas de seguimiento de conexión de la misma forma que los floods de ACK o FIN, pero con el riesgo adicional de que cualquier paquete que sí coincida con una conexión activa de bajo tráfico la termine instantáneamente y sin posibilidad de recuperación ordenada a nivel de transporte.

Forma 2: RST flood como secuestro de sesión / terminación dirigida

Un uso más quirúrgico de RST no depende del volumen en absoluto. Si un atacante puede determinar o predecir la tupla de cuatro elementos (IP de origen, puerto de origen, IP de destino, puerto de destino) y un número de secuencia válido para una sesión TCP activa, un solo paquete RST falsificado puede terminar esa conexión específica:

Inyección de RST dirigida:
El atacante observa o predice: la tupla de 4 + el número de secuencia dentro
de la ventana de la Sesión X
Atacante ──RST (falsificado como endpoint de la Sesión X)──▶ Objetivo
[El stack del objetivo valida que el número de secuencia cae en la ventana de recepción]
[La Sesión X termina de inmediato]

Esta técnica tiene un historial documentado contra sesiones predecibles y de larga duración, como las sesiones de peering BGP entre routers, donde los endpoints, puertos, y rangos aproximados de número de secuencia son más factibles de inferir que para conexiones de vida corta arbitrarias. También se ha usado históricamente para censura a nivel de red e interrupción de conexión, donde un dispositivo on-path o en la red inyecta paquetes RST para cortar flujos TCP específicos sin bloquear a nivel de IP.

La diferencia clave con la Forma 1: el RST de secuestro de sesión no requiere alto volumen de paquetes. Un solo paquete correctamente secuenciado es suficiente, lo que significa que la detección basada solo en volumen no lo capturará.

TCP RESET Flood vs. Floods relacionados basados en flags

Señales de detección y telemetría

Detectar las dos formas requiere enfoques distintos: monitoreo basado en volumen para la forma DoS, y monitoreo de integridad de sesión para la forma de secuestro.

# Resumen de sockets y conexiones
ss -ti

# Contadores TCP — busca contadores elevados relacionados con reset
nstat -az | grep -i "reset\|rst\|tcpabort"

# Estado y crecimiento de la tabla conntrack de Netfilter
conntrack -L -p tcp | grep -c ESTABLISHED
cat /proc/sys/net/netfilter/nf_conntrack_count

# Contadores de iptables en reglas que rastrean RST sin estado coincidente previo
iptables -L -v -n

# Ventana de captura corta para inspeccionar la proporción del flag RST contra el tráfico TCP total
tcpdump -i eth0 -c 20000 'tcp[tcpflags] & tcp-rst != 0' -nn

# Para detección de secuestro de sesión: monitorea caídas de sesión inesperadas correlacionadas
# con logs de aplicación/BGP en lugar de volumen de paquetes

Técnicas de mitigación

TCP-AO (TCP Authentication Option, RFC 5925) y su predecesor, la opción de firma TCP MD5, son específicamente relevantes para proteger sesiones de larga duración y alto valor como los peerings BGP contra la inyección de RST dirigida, ya que hacen computacionalmente inviable que un atacante forje un RST válido sin el secreto compartido.

Errores comunes

Cómo implementarlo con Azion

Azion gestiona el estado de sesión TCP en el edge de red, lo que aborda ambas formas de RST flood de manera distinta:

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

Para la inyección de RST estilo secuestro de sesión contra sesiones específicas de alto valor como los peerings BGP entre tu propia infraestructura y proveedores upstream, la autenticación de sesión (TCP-AO o TCP MD5) es un control implementado en la capa de enrutamiento en lugar de en el edge de Azion, y debería evaluarse como una medida complementaria junto con las defensas DDoS basadas en edge.

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 RESET flood? Un TCP RESET flood envía grandes volúmenes de segmentos TCP con el flag RST activado hacia un objetivo. Existe en dos formas: una técnica de denegación de servicio volumétrica que presiona las tablas de conexión y la CPU, y una técnica de secuestro de sesión dirigida que usa un solo RST correctamente secuenciado para terminar una conexión activa específica.

¿En qué se diferencia un RESET flood de un FIN flood? FIN inicia un cierre ordenado de múltiples pasos que ambos lados deben confirmar. RST fuerza una terminación inmediata y unilateral sin ningún handshake de cierre. Un RESET flood en su forma DoS agita las tablas de conexión de forma similar a un FIN flood, pero cualquier paquete RST que coincida con una sesión real la termina instantáneamente en lugar de comenzar un cierre ordenado.

¿Un solo paquete RST realmente puede terminar una conexión activa? Sí, si el número de secuencia del paquete cae dentro de la ventana actual del stack receptor para esa conexión y la tupla de cuatro elementos (IP de origen, puerto de origen, IP de destino, puerto de destino) coincide. Esta es la base de la forma de secuestro de sesión de RST flood y no requiere alto volumen de paquetes.

¿Por qué las sesiones BGP son específicamente vulnerables a la inyección de RST? Los peerings BGP son de larga duración y usan direcciones IP y puertos predecibles, a menudo públicamente conocidos, lo que reduce el espacio de adivinanza para un atacante que intenta forjar un RST válido. Las opciones TCP-AO y firma TCP MD5 existen específicamente para autenticar estas sesiones y prevenir la inyección de RST no autenticada.

¿Cómo se diferencia un RESET flood de un SYN flood? El SYN flood agota la memoria del kernel durante el establecimiento de conexión creando conexiones semi-abiertas. El RESET flood en su forma DoS agota la CPU y la capacidad de tabla de conexión a través de búsquedas de estado repetidas, y en su forma de secuestro termina por completo una conexión existente específica en lugar de agotar un pool de recursos.

¿El IP spoofing importa de forma diferente para las dos formas de RST flood? Sí. En la forma DoS, el spoofing ayuda a distribuir el ataque a través de muchos orígenes aparentes y evita el bloqueo directo basado en IP. En la forma de secuestro, el spoofing es esencial porque el RST debe parecer originarse de uno de los dos endpoints legítimos de la sesión objetivo.

¿El rate limiting puede detener una inyección de RST de secuestro de sesión? No. El rate limiting está diseñado para capturar tráfico de alto volumen de un origen. Una inyección de RST de secuestro de sesión puede tener éxito con un solo paquete bien formado, así que requiere validación de número de secuencia y, para sesiones críticas, autenticación criptográfica en lugar de controles basados en tasa.

¿Qué es TCP-AO y cómo se relaciona con la defensa contra RST flood? TCP-AO (TCP Authentication Option), definido en RFC 5925, autentica criptográficamente los segmentos TCP usando una clave compartida, reemplazando la opción de firma TCP MD5 más antigua. Evita que un atacante sin la clave compartida forje un RST válido (o cualquier otro segmento) para una sesión protegida, abordando directamente la forma de secuestro de sesión de RST flood.

¿La forma DoS de RST flood es más peligrosa que la forma de secuestro? Son peligrosas de formas distintas. La forma DoS puede degradar o interrumpir el servicio de forma amplia al agotar infraestructura compartida como las tablas de estado de firewall. La forma de secuestro no causa agotamiento de recursos amplio pero puede cortar de forma silenciosa y repetida conexiones específicas de alto valor, lo cual puede ser más difícil de detectar y atribuir.

¿Cómo ayuda la terminación TCP basada en edge contra los RST floods? Para la forma DoS, una red distribuida que termina y gestiona las sesiones TCP absorbe la carga de búsqueda y agitación de tabla antes de que llegue al origen. La forma de secuestro apunta a sesiones específicas entre dos endpoints conocidos y generalmente se aborda a través de autenticación de sesión en la capa de enrutamiento o aplicación en lugar de a través del scrubbing de tráfico en el edge.

Fuentes:

• IETF. “Transmission Control Protocol.” RFC 793. 1981.
• IETF. “Transmission Control Protocol (TCP).” RFC 9293. 2022.
• IETF. “The TCP Authentication Option.” RFC 5925. 2010.
• IETF. “Defending Against Sequence Number Attacks.” RFC 6528. 2012.
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.
• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”