¿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

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

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

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

Errores comunes y correcciones

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

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

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