¿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

Ataque	Flags usados	Volumen requerido	Efecto principal	Recurso típicamente agotado
TCP RESET Flood (forma DoS)	RST	Sí	Agitación de tabla de conexión, CPU, cualquier sesión coincidente muere	Entradas conntrack, CPU
TCP RESET Flood (forma secuestro de sesión)	RST	No (un solo paquete puede ser suficiente)	Terminación inmediata de una sesión específica objetivo	N/A — ataque de precisión, no agotamiento de recursos
TCP FIN Flood	FIN	Sí (forma DoS)	Agitación de cierre multi-estado	Entradas de tabla conntrack/sesión
TCP ACK-PSH Flood	ACK, PSH	Sí	Costo de CPU de búsqueda + manejo de buffer	CPU, buffers de aplicación
SYN Flood	SYN	Sí	Agotamiento de memoria de conexión semi-abierta	Tabla de conexión del kernel

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

Indicador	Tráfico normal	RST flood (forma DoS)	RST flood (forma secuestro de sesión)
Paquetes RST/segundo	Bajo, proporcional a la tasa de error	Aumento agudo y sostenido	Sin aumento significativo
Paquetes RST sin sesión coincidente	Cercano a cero	Alto y sostenido	No aplicable (un solo paquete válido)
Eventos de terminación de sesión inesperada	Raros	Correlacionados con alto volumen de RST	Aislados, no explicados por volumen de RST
Caídas de sesión BGP/de larga duración sin inestabilidad previa	Raras	Posibles como efecto secundario	Síntoma primario
Diversidad de IP de origen en tráfico RST	Consistente con la base real de clientes	Alta, a menudo falsificada	Uno o pocos, dirigidos con precisión

Técnicas de mitigación

Técnica	Cómo funciona	Efectividad
Validación de número de secuencia	Rechaza paquetes RST cuyo número de secuencia caiga fuera de la ventana de recepción actual	Alta contra la inyección de RST ciega y off-path
TCP MD5 / TCP-AO para sesiones críticas	Autentica criptográficamente los segmentos para sesiones de alto valor como los peerings BGP, definido en RFC 5925	Muy alta para protección de secuestro de sesión dirigido
Validación RST con estado	Descarta paquetes RST que no correspondan a una conexión rastreada y activa	Alta para la forma DoS de RST flood
Rate limiting por origen	Limita los paquetes RST por IP de origen por segundo	Media — limitada contra orígenes distribuidos y falsificados
Puertos de origen y números de secuencia aleatorizados	Aumenta la dificultad de adivinar la tupla de 4 y el número de secuencia dentro de ventana necesarios para el RST estilo secuestro	Alta como control sistémico
Terminación TCP en el edge	Termina y gestiona las sesiones TCP en una red distribuida antes de que el tráfico llegue al origen	Muy alta para la forma DoS

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

Error	Impacto	Enfoque correcto
Tratar todos los RST floods como ataques puramente volumétricos	La inyección de RST de secuestro de sesión no requiere volumen significativo y se pasa por alto con detección basada en umbrales	Monitorea terminaciones de sesión inesperadas de forma independiente de las anomalías de volumen de paquetes
No autenticar sesiones críticas de larga duración	Los peerings BGP y similares siguen expuestos a la inyección de RST de un solo paquete	Despliega TCP-AO o firma TCP MD5 para BGP y otras sesiones de alto valor
Depender solo del bloqueo por IP de origen	Los orígenes falsificados rotan constantemente en la forma DoS; la forma de secuestro puede usar un solo origen difícil de atribuir	Combina la validación de número de secuencia con rate limiting y autenticación de sesión
Ignorar la aleatorización débil de número de secuencia	Facilita la ejecución de ambas formas de RST flood	Verifica una aleatorización fuerte de número de secuencia inicial según RFC 6528
Asumir que el manejo de RST del firewall coincide con el comportamiento del servidor de origen	Los dispositivos intermedios pueden aceptar o rechazar RST de forma diferente, creando protección inconsistente	Valida el comportamiento de manejo de RST en cada dispositivo con estado de la ruta

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

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

Únete a nuestra comunidad