¿Qué es un ataque TCP Invalid Packet? | Flags malformados, checksums malos y agotamiento de parser

Un ataque TCP Invalid Packet es una técnica de DDoS y evasión de Capa 4 que envía segmentos TCP que violan la propia especificación del protocolo —combinaciones de flags ilegales como SYN+FIN o SYN+RST, checksums corruptos, campos de header malformados, o paquetes sin ningún flag activado— para agotar los recursos de parsing y validación de paquetes en el objetivo, o para pasar desapercibido ante dispositivos de inspección que no manejan de forma consistente la entrada malformada.

Resumen rápido — RFC 793/RFC 9293 definen qué combinaciones de flags TCP son significativas; algunas combinaciones, como SYN y FIN activados simultáneamente, no tienen ninguna interpretación válida en el protocolo y nunca deberían ocurrir en tráfico legítimo. Un ataque TCP Invalid Packet genera deliberadamente estos segmentos malformados —pares de flags ilegales, checksums malos, mal uso de bits reservados, o paquetes “null” con flags en cero— a volumen. El objetivo es la denegación de servicio, al forzar a cada dispositivo en la ruta a gastar CPU validando y rechazando entrada malformada, o el reconocimiento/evasión, ya que distintos sistemas operativos y middleboxes manejan de forma inconsistente los paquetes malformados. La mitigación es comparativamente directa: aplica validación estricta de header y combinación de flags lo más pronto posible en el pipeline de procesamiento de paquetes y descarta cualquier cosa que falle las verificaciones de legalidad definidas por RFC.

Última actualización: 2026-08-08

Cómo funciona un ataque TCP Invalid Packet

TCP define seis flags de control principales: URG, ACK, PSH, RST, SYN, FIN. Solo ciertas combinaciones corresponden a un evento de protocolo significativo. SYN inicia una conexión; FIN cierra una de forma ordenada; RST aborta una. SYN y FIN activados juntos se contradicen a sí mismos —“abrir una conexión nueva” y “cerrar una conexión” en el mismo segmento— y no tienen ningún significado definido en la especificación.
Un atacante crea paquetes con combinaciones que la especificación no define como válidas: SYN+FIN, SYN+RST, todos los flags activados simultáneamente (paquetes “árbol de navidad” o Xmas), o ningún flag activado en absoluto (paquetes “null”).
Por separado, o en combinación, el atacante puede corromper el campo checksum TCP, hacer mal uso de los bits reservados del header, o truncar/malformar los campos de longitud de header para que el segmento no se parsee correctamente según las propias reglas de framing del protocolo.
Cada dispositivo en la ruta —motores de offload de la NIC, el stack TCP/IP del kernel, firewalls con estado, sensores IDS/IPS— debe parsear y evaluar el paquete contra las reglas del protocolo antes de decidir aceptarlo, rechazarlo, o marcarlo. La entrada malformada a menudo es más costosa de evaluar que la entrada bien formada, ya que las rutas de excepción y la lógica de validación corren antes de que el paquete pueda descartarse.
A volumen de inundación, este costo de validación se acumula en cada salto, y el manejo inconsistente entre dispositivos (un firewall podría descartar un paquete con el que un parser de capa de aplicación de otro modo tendría problemas) puede explotarse para construir técnicas de reconocimiento o evasión de IDS sobre la misma técnica central.
Históricamente, herramientas como Nmap usan exactamente estos patrones malformados (escaneos Null, FIN, y Xmas) para fingerprinting de SO y reconocimiento de reglas de firewall, porque distintas implementaciones de stack TCP/IP responden de forma diferente a entradas que la especificación no define, y la respuesta en sí filtra información.

Tráfico normal (solo combinaciones de flag legales):
Cliente ──SYN──▶ Servidor                  [válido: request de conexión]
Cliente ◀─SYN-ACK── Servidor               [válido: respuesta de conexión]
Cliente ──ACK──▶ Servidor                  [válido: completitud de handshake]
Cliente ──FIN,ACK──▶ Servidor              [válido: cierre ordenado]
Cliente ──RST──▶ Servidor                  [válido: abortar]

Ataque TCP Invalid Packet:
Bot ──SYN,FIN (combinación ilegal)──▶ Servidor     [contradictorio: abrir + cerrar]
Bot ──SYN,RST (combinación ilegal)──▶ Servidor     [contradictorio: abrir + abortar]
Bot ──URG,ACK,PSH,RST,SYN,FIN (todos los flags/"Xmas")──▶ Servidor   [no definido por la especificación]
Bot ──(sin flags activados/"null")──▶ Servidor             [no definido por la especificación]
Bot ──(flags válidos, checksum corrupto)──▶ Servidor [falla la verificación de integridad]
... [millones de paquetes malformados]

Resultado: cada capa de parsing/validación en la ruta gasta ciclos
        evaluando y rechazando paquetes que nunca debieron enviarse

¿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 (combinación legal, válida)	Cola de backlog SYN / memoria TCB	Opcional	No	SYN_RECV alto, baja tasa de completitud de handshake
TCP ACK Flood	Solo ACK (legal, pero sin coincidir con ninguna sesión)	Búsqueda de estado firewall/CPU	Opcional	No	Alto volumen de ACK en estado inválido
TCP SYN-ACK Flood (reflejado)	SYN-ACK (legal, no solicitado vía reflectores)	Ancho de banda/PPS entrante + inspección con estado	Requerido	No	SYN-ACK entrante sin SYN saliente coincidente
TCP Out-of-State Flood	Flags legales mezclados que violan las transiciones de estado esperadas	CPU y agitación de conntrack/firewall con estado	Opcional	No	Contadores de estado INVALID crecientes en múltiples tipos de flag
TCP Invalid Packet (este artículo)	Ilegal a nivel de protocolo: SYN+FIN, SYN+RST, todos-los-flags, sin-flags, o checksum malo	CPU de parser de paquetes / validación de header / inspección IDS-IPS	Opcional	No	Fallos de checksum, alertas de combinación de flags ilegal, logs de header malformado

La distinción clave con Out-of-State Flood: los paquetes fuera de estado son segmentos TCP individualmente legales (un ACK solitario, un FIN solitario) que simplemente son inconsistentes con el estado rastreado de una conexión específica; evaluarlos requiere contexto con estado. Los paquetes inválidos son ilegales por la propia especificación del protocolo, independientemente de cualquier estado rastreado; un paquete SYN+FIN es malformado sin importar si existe alguna conexión con esa tupla, así que a menudo puede identificarse y descartarse solo con inspección de header sin estado.

Variaciones del ataque

Inundación de escaneo Xmas. Los seis flags (URG, ACK, PSH, RST, SYN, FIN) activados simultáneamente. Originalmente una técnica de reconocimiento de Nmap para fingerprinting de SO y descubrimiento de reglas de firewall, a volumen se convierte en un vector de agotamiento de recursos, ya que algunos stacks legados y dispositivos de inspección manejan de forma ineficiente el caso de “todo activado”.

Inundación de escaneo Null. Paquetes sin ningún flag activado en absoluto. Como el escaneo Xmas, este patrón no está definido por la especificación y se usó históricamente para reconocimiento furtivo; a volumen de inundación fuerza a cada dispositivo receptor a ejecutar lógica de validación para entrada que no coincide con ningún patrón esperado.

Inundación de corrupción de checksum. Paquetes por lo demás bien formados con checksums TCP deliberadamente inválidos. Dependiendo de dónde ocurra la validación del checksum (offload de NIC, kernel, o aplicación), esto puede descartarse de forma económica o, en rutas de hardware/software mal configuradas u más antiguas, consumir más ciclos de lo esperado.

Manipulación de bits reservados y longitud de header. Fijar bits de header reservados o manipular el campo data offset para producir un header que no delimite claramente dónde terminan las opciones TCP y dónde comienza el payload, apuntando a parsers con verificación de límites menos rigurosa.

Señales de detección y telemetría

# Contadores TCP del kernel — los segmentos malformados incrementan contadores de error/descarte
nstat -az | grep -iE "invalid|csum|error"

# Contadores de error de checksum a nivel de interfaz (dependiente del driver/NIC)
ethtool -S eth0 | grep -i err

# Regla nftables para coincidir y contar explícitamente combinaciones de flag ilegales
nft add rule inet filter input tcp flags syn,fin / syn,fin counter drop
nft add rule inet filter input tcp flags syn,rst / syn,rst counter drop
nft add rule inet filter input tcp flags fin,syn,rst,psh,ack,urg / fin,syn,rst,psh,ack,urg counter drop
nft add rule inet filter input tcp flags == 0x0 counter drop

# Equivalentes de iptables (verificaciones de combinación ilegal)
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# La verificación de estado "INVALID" integrada de Netfilter con --tcp-flags como respaldo
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# Captura de paquetes para clasificación durante la investigación (usa muestreo a PPS alto)
tcpdump -ni eth0 'tcp[13] & 0x03 == 0x03' -c 1000

Indicador	Normal	Bajo ataque TCP Invalid Packet
Paquetes que coinciden con combinaciones de flag ilegales (SYN+FIN, SYN+RST, todos-los-flags, sin-flags)	Cero o cercano a cero (los stacks legítimos nunca generan esto)	Volumen sostenido y distinto de cero
Contadores de error de checksum TCP	Cercano a cero, aislado a corrupción de red real	Elevados, correlacionados con un patrón de origen específico
Alertas IDS/IPS de “paquete malformado” o “anomalía de protocolo”	Raras	Frecuentes, de alto volumen
Contador INVALID de conntrack	Cercano a cero	Elevado (muchos paquetes inválidos también fallan el rastreo de estado)
Tiempo de CPU en rutas de parsing/validación de paquetes	Línea base	Elevado, desproporcionado al volumen de tráfico real

Cualquier conteo distinto de cero de paquetes SYN+FIN, SYN+RST, todos-los-flags, o sin-flags en tráfico de producción es inherentemente sospechoso; los stacks TCP/IP legítimos nunca generan estas combinaciones, así que los umbrales de detección pueden ser más estrictos que para ataques construidos a partir de paquetes individualmente legales.

Técnicas de mitigación

Técnica	Cómo funciona	Efectividad
Reglas explícitas de descarte de combinación de flag ilegal	Coincide y descarta patrones SYN+FIN, SYN+RST, todos-los-flags, y sin-flags antes de cualquier procesamiento más profundo	Muy alta — estos patrones no tienen ningún uso legítimo
Validación de checksum en el salto más temprano	Rechaza paquetes que fallan la validación de checksum a nivel de NIC/kernel antes de que lleguen a la lógica de aplicación	Alta
Validación estricta de header/límites	Aplica el parsing de longitud de header y campo de opciones conforme a RFC; rechaza framing malformado	Alta
Terminación con estado en el edge/proxy	El origen solo recibe tráfico completamente validado y bien formado para sesiones que el edge completó	Muy alta
Detección de anomalías de protocolo IDS/IPS	Marca patrones malformados independientemente del volumen, útil para variantes de reconocimiento low-and-slow	Media-alta, depende de la vigencia del conjunto de reglas
Scrubbing upstream	Filtra inundaciones de paquetes malformados de alto volumen antes de que lleguen a tu red	Alta para ataques a gran escala

Errores comunes y correcciones

Error	Impacto	Corrección
Asumir que la verificación genérica de estado INVALID de conntrack lo captura todo	Algunos patrones malformados pueden clasificarse de forma diferente según la versión del kernel y la configuración de Netfilter	Agrega reglas explícitas de coincidencia de combinación de flag como respaldo, no solo la verificación INVALID genérica
Ignorar el tráfico de escaneo Xmas/Null de bajo volumen como “solo reconocimiento”	El reconocimiento a menudo precede a un ataque dirigido una vez que se mapean las reglas de firewall y el fingerprint del SO	Registra y alerta sobre cualquier tráfico de flag ilegal sin importar el volumen, no solo a escala de inundación
Depender del logging de capa de aplicación para capturar paquetes malformados	Los paquetes malformados típicamente se descartan antes de llegar a la aplicación, así que los logs de la app no muestran nada	Instrumenta la detección en la capa de firewall/kernel, no solo en la capa de aplicación
No validar los checksums lo suficientemente temprano en el pipeline	Los paquetes corruptos consumen ciclos más adelante en el stack antes de ser descartados	Valida los checksums en el punto más temprano posible (offload de NIC o kernel)
Tratar esto igual que Out-of-State Flood	Se pasa por alto que los paquetes inválidos a menudo pueden descartarse sin estado, sin búsquedas conntrack en absoluto	Aplica filtrado de combinación de flag sin estado antes de la inspección con estado, por eficiencia

Cómo implementarlo con Azion

La red distribuida de Azion puede filtrar tráfico TCP malformado antes de que llegue a la infraestructura de origen:

DDoS Protection está diseñado para detectar y ayudar a mitigar anomalías de Capa 3/4, incluyendo tráfico malformado y de combinación de flag ilegal, en el edge.
Network Shield aplica reglas de filtrado que pueden identificar y descartar paquetes que violan reglas de flag y header a nivel de protocolo.
Firewall soporta reglas personalizadas para validación y bloqueo a nivel de paquete.
WAAP combina protección de red y de capa de aplicación para equipos que necesitan cobertura más amplia.

Como Azion termina las conexiones TCP en el edge, el tráfico malformado y de flag ilegal dirigido a un origen detrás de Azion generalmente se filtra upstream en lugar de llegar 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 Invalid Packet? Es un ataque que envía segmentos TCP que violan la propia especificación del protocolo —combinaciones de flags ilegales como SYN+FIN o SYN+RST, todos los flags activados, ningún flag activado, o checksums corruptos— para agotar recursos de parsing de paquetes o evadir dispositivos de inspección que manejan de forma inconsistente la entrada malformada.

¿Por qué se activarían SYN y FIN en el mismo paquete? No lo harían, en tráfico legítimo. SYN señala “abrir una conexión nueva” y FIN señala “cerrar una conexión de forma ordenada”; la combinación se contradice a sí misma y no tiene significado definido en RFC 793/RFC 9293. Cualquier paquete SYN+FIN observado en tráfico de producción indica tráfico malformado o malicioso.

¿En qué se diferencia un ataque TCP Invalid Packet de un TCP Out-of-State Flood? Los paquetes fuera de estado son segmentos TCP individualmente legales (un ACK o FIN solitario) que son inconsistentes con el estado rastreado de una conexión específica, requiriendo contexto con estado para identificarlos. Los paquetes inválidos son ilegales a nivel de protocolo sin importar ningún estado rastreado; un paquete SYN+FIN es malformado sin importar si existe una conexión coincidente, así que a menudo puede descartarse solo con inspección de header sin estado.

¿Qué es un paquete árbol de navidad (Xmas)? Un paquete Xmas tiene los seis flags TCP (URG, ACK, PSH, RST, SYN, FIN) activados simultáneamente, nombrado por iluminarse como un árbol de navidad en los analizadores de paquetes. No está definido por la especificación TCP y se usó históricamente para fingerprinting de SO y reconocimiento de firewall vía herramientas como Nmap.

¿Qué es un escaneo Null y por qué es peligroso? Un escaneo Null envía paquetes TCP sin ningún flag activado en absoluto. Como el escaneo Xmas, esto es comportamiento no definido en la especificación, y distintos sistemas operativos responden de forma diferente a él, lo que le permite a un atacante hacer fingerprinting del SO o conjunto de reglas de firewall objetivo. A volumen, también fuerza overhead de validación en cada dispositivo receptor.

¿Un firewall puede descartar paquetes TCP inválidos sin inspección con estado? Sí, para la mayoría de las combinaciones de flag ilegales. Como los patrones SYN+FIN, SYN+RST, todos-los-flags, y sin-flags nunca son legítimos sin importar el estado de la conexión, pueden coincidirse y descartarse con reglas de header sin estado, lo que generalmente es más económico que pasarlos por evaluación conntrack con estado completa.

¿Un checksum TCP malo siempre significa un ataque? No necesariamente; errores de checksum ocasionales pueden resultar de corrupción de red real o hardware defectuoso. Un patrón sostenido y de alto volumen de fallos de checksum correlacionado con un origen o patrón de tráfico específico es la señal que distingue un ataque de una corrupción incidental.

¿Cómo se relaciona esto con técnicas de evasión de IDS/IPS? Distintas implementaciones de stack TCP/IP y dispositivos de inspección manejan los paquetes malformados de forma inconsistente. Los atacantes pueden explotar estas inconsistencias para crear tráfico que un dispositivo descarta pero otro procesa de forma diferente, potencialmente dejando pasar payloads maliciosos más allá de un punto de inspección que no rechaza el framing malformado de la misma forma que el stack del objetivo final lo hace.

¿Qué combinaciones de flag TCP siempre deberían bloquearse? SYN+FIN, SYN+RST, los seis flags activados simultáneamente, y ningún flag activado en absoluto no tienen ningún uso legítimo en tráfico TCP estándar y son seguros de bloquear sin condiciones en el firewall en prácticamente todos los entornos de producción.

¿Se requiere IP spoofing para un ataque TCP Invalid Packet? No. La técnica depende de malformar los flags, el checksum, o los campos de header del paquete en lugar de explotar un requisito de ruta de retorno, así que funciona con direcciones IP de origen falsificadas o reales.

Fuentes

IETF. “Transmission Control Protocol.” RFC 793. 1981.
IETF. “Transmission Control Protocol (TCP) Specification.” RFC 9293. 2022.
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