¿Qué es un ataque de fragmentación IP? | Teardrop, fragmentos diminutos, y agotamiento de reensamblado

Un ataque de fragmentación IP es una técnica de Denegación de Servicio o evasión a nivel de red que abusa del mecanismo de fragmentación y reensamblado de paquetes del protocolo IP —manipulando offsets, tamaños, o secuenciación de fragmentos— para colapsar sistemas vulnerables, evadir la inspección de seguridad, o agotar la memoria y CPU que un objetivo reserva para reensamblar paquetes fragmentados.

Resumen rápido — IP permite que los paquetes grandes se dividan en fragmentos cuando exceden la Unidad Máxima de Transmisión (MTU) de una red, y el host receptor debe hacer buffer y reensamblar esos fragmentos usando los campos de offset y Más Fragmentos en el header IP. Los atacantes explotan esto enviando fragmentos malformados, superpuestos, o deliberadamente diminutos que ya sea colapsan código de reensamblado ingenuo (el ataque Teardrop clásico), deslizan payloads maliciosos más allá de firewalls que solo inspeccionan el primer fragmento, o inundan a un objetivo con conjuntos de fragmentos incompletos que consumen memoria de buffer de reensamblado hasta agotarla. La mitigación requiere validación estricta de fragmentos, aplicación de tamaño mínimo de fragmento, límites de timeout y memoria de reensamblado, y —donde la red lo permita— descartar el tráfico fragmentado por completo para protocolos que no lo requieren.

Última actualización: 2026-08-08

Los ataques de fragmentación IP están entre los exploits de red más antiguos documentados. El ataque Teardrop original, que colapsaba Windows 95, NT, y varios kernels de Linux a lo largo de mediados/finales de los años noventa enviando fragmentos superpuestos que corrompían los buffers de reensamblado, está documentado en un aviso CERT de 1997 (CA-1997-28) y impulsó gran parte del trabajo temprano de refuerzo en los stacks de red de sistemas operativos. Los kernels modernos son en gran medida inmunes a los bugs de colapso originales, pero el abuso de fragmentación persiste hoy en una forma distinta: evasión de firewall/IDS y agotamiento de recursos de reensamblado, ambos siguen siendo preocupaciones prácticas para infraestructura orientada a internet.

Los campos del header IP que hacen posible la fragmentación

La fragmentación está controlada enteramente por tres campos en el header IPv4, definidos en RFC 791:

Header IPv4 (campos relevantes, palabras de 32 bits):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Versión| IHL  |Tipo de Servicio|          Longitud Total          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identificación        |Flags|      Offset de Fragmento     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocolo   |         Checksum de Header        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Dirección de Origen                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Dirección de Destino                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Identificación:    16 bits — mismo valor a través de todos los fragmentos de un datagrama original
Flags:              3 bits — bit 1 = Don't Fragment (DF), bit 2 = More Fragments (MF)
Offset de Fragmento: 13 bits — offset de los datos de este fragmento, en unidades de 8 bytes,
                    desde el inicio del datagrama original sin fragmentar

Cómo usa el reensamblado estos campos: cuando un paquete excede el MTU del enlace de salida, un router o el host emisor lo divide en fragmentos. Cada fragmento porta el mismo valor de Identificación para que el receptor sepa qué fragmentos pertenecen juntos. Cada fragmento (excepto el último) fija el flag More Fragments (MF) a 1; el último fragmento fija MF a 0. El Offset de Fragmento, medido en unidades de 8 bytes, le dice al receptor dónde en el datagrama original pertenecen los datos de este fragmento. El host receptor hace buffer de los fragmentos a medida que llegan, indexados por dirección de origen/destino, protocolo, e Identificación, y reensambla el datagrama completo una vez que tiene una serie contigua de bytes desde el offset 0 hasta el fragmento con MF=0.

Datagrama original (3,000 bytes de payload) fragmentado para una ruta con MTU de 1,500 bytes:

Fragmento 1: Identificación=X, MF=1, Offset=0     (bytes 0-1479 del payload)
Fragmento 2: Identificación=X, MF=1, Offset=185   (unidad de offset = 8 bytes; 185*8=1480)
Fragmento 3: Identificación=X, MF=0, Offset=370   (370*8=2960; fragmento final, MF=0)

El receptor hace buffer de los tres bajo Identificación=X, verifica que no
haya huecos, reensambla el datagrama original de 3,000 bytes, y luego lo
entrega a la capa de transporte (TCP/UDP/ICMP) para su procesamiento posterior.

Cómo funcionan los ataques de fragmentación IP

Como el receptor confía en los valores de offset y MF que un emisor provee, nada en la especificación IP base evita que un emisor provea offsets que se superpongan, huecos que nunca se cierren, o fragmentos tan pequeños que porten casi ningún dato útil. Tres patrones de ataque distintos emergen de esta confianza:

1. Fragmentos superpuestos (estilo Teardrop). El atacante crea una secuencia de fragmentos cuyos offsets se superponen; por ejemplo, un segundo fragmento cuyo offset coloca sus datos parcialmente dentro del rango ya reclamado por el primer fragmento.

Superposición estilo Teardrop:

Fragmento A: Identificación=X, MF=1, Offset=0    (reclama bytes 0-1479)
Fragmento B: Identificación=X, MF=0, Offset=100  (reclama bytes 800-1579 — se superpone con A en 800-1479)

Código de reensamblado ingenuo (stacks de red de SO de mediados de los años noventa):
  calcula la longitud de copia del buffer como (fin del Fragmento B - inicio del Fragmento B)
  usando aritmética sin signo que se desborda cuando la superposición
  produce una longitud negativa, escribiendo fuera del buffer asignado

Resultado: kernel panic o colapso en sistemas vulnerables sin parchar

Los sistemas operativos modernos validan los límites de fragmento y rechazan o descartan de forma segura los fragmentos superpuestos, así que el bug original de colapso de Teardrop no es un riesgo práctico contra kernels actuales. La técnica persiste conceptualmente como forma de probar la robustez del reensamblado y, en algunos escenarios de evasión de IDS/firewall, para hacer que una secuencia de fragmentos se reensamble de forma distinta en un dispositivo de inspección que en el host final; permitiendo que un primer fragmento de apariencia benigna pase la inspección mientras un fragmento posterior y superpuesto sobrescribe silenciosamente la porción inspeccionada.

2. Ataques de fragmentos diminutos. El atacante fragmenta deliberadamente un paquete —a menudo justo al inicio de un segmento TCP— en fragmentos tan pequeños que el primer fragmento no contiene suficiente del header TCP (puerto de origen, puerto de destino, flags) para que un firewall o dispositivo de filtrado tome una decisión precisa.

Paquete TCP/IP normal (SYN, puerto destino 22, es decir, SSH):
[header IP][header TCP: puerto origen, puerto destino=22, flags=SYN][datos]

Ataque de fragmento diminuto:
Fragmento 1: [header IP][primeros 8 bytes del header TCP — solo puerto origen, sin flags/puerto destino visible]
Fragmento 2: [header IP][resto del header TCP incl. puerto destino=22, flags=SYN][datos]

Una regla de firewall que coincide "puerto destino 22, flag SYN" puede fallar
en coincidir con el Fragmento 1 (header incompleto) y puede no mantener y
re-inspeccionar correctamente después del reensamblado — dependiendo de la
implementación, esto puede permitir que el paquete fragmentado llegue a un
servicio que el firewall pretendía bloquear.

RFC 1858 y su seguimiento RFC 3128 documentan exactamente este patrón de evasión y especifican reglas de filtrado —rechazar cualquier fragmento cuyo offset sea 1 (indicando un fragmento que comienza en el byte 8, demasiado pequeño para contener un header TCP completo)— que los firewalls deberían implementar para cerrar el hueco.

3. Agotamiento de reensamblado de fragmentos (flood de fragmentos). En lugar de intentar evadir la inspección o colapsar al objetivo, el atacante simplemente envía grandes volúmenes de fragmentos que nunca completan un datagrama válido; por ejemplo, fragmentos con MF=1 que nunca son seguidos por un fragmento final correspondiente (MF=0) para ese valor de Identificación. Cada conjunto de fragmentos incompleto consume memoria en el buffer de reensamblado del objetivo hasta que expira el timeout de reensamblado (comúnmente 30-60 segundos, según las recomendaciones de RFC 791 y los valores por defecto específicos del SO). A suficiente volumen, el tráfico fragmentado legítimo nuevo no puede hacer buffer, y la propia cola de reensamblado se convierte en un objetivo de agotamiento de recursos, similar en espíritu a cómo un SYN Flood agota la tabla de conexión TCP, pero a nivel IP en lugar de a nivel de transporte.

Flood de fragmentos:

Bot 1 ──Fragmento (MF=1, Offset=0, ID=1001)──▶ Objetivo [en buffer, esperando más]
Bot 2 ──Fragmento (MF=1, Offset=0, ID=1002)──▶ Objetivo [en buffer, esperando más]
Bot 3 ──Fragmento (MF=1, Offset=0, ID=1003)──▶ Objetivo [en buffer, esperando más]
... [millones de conjuntos de fragmentos incompletos, nunca se envía el fragmento de cierre MF=0]

Resultado: la memoria del buffer de reensamblado se llena con conjuntos de
        fragmentos incompletos mantenidos hasta el timeout; los paquetes
        fragmentados legítimos no pueden hacer buffer; se gasta CPU
        gestionando la cola de reensamblado

Variantes de ataque de fragmentación IP comparadas

Fragmentación IP vs. Fragmentación TCP — Distinción crítica

Estos dos temas se confunden frecuentemente porque ambos involucran “dividir datos en piezas”, pero operan en capas distintas con mecanismos completamente diferentes:

En resumen: la fragmentación IP ocurre por debajo de TCP/UDP y es invisible para la capa de transporte; un solo segmento TCP puede dividirse en varios fragmentos IP sin que TCP lo sepa jamás. La fragmentación TCP (más precisamente llamada segmentación) ocurre dentro de TCP mismo, dividiendo el flujo de bytes de la aplicación en segmentos regidos por MSS, independientemente de si IP después también fragmenta esos segmentos. Un ataque puede explotar uno sin tocar el otro, y las técnicas de evasión sofisticadas a veces combinan ambos.

Señales de detección y telemetría

# Contadores de fragmentación y reensamblado IP a nivel de kernel
nstat -az | grep -iE "frag|reasm"
# Contadores clave: IpReasmReqds (intentos de reensamblado), IpReasmFails (reensamblados fallidos),
# IpReasmOKs (exitosos), IpFragCreates (fragmentos creados al enviar)

# Límites actuales de memoria de la cola de reensamblado (Linux)
sysctl net.ipv4.ipfrag_high_thresh
sysctl net.ipv4.ipfrag_low_thresh
sysctl net.ipv4.ipfrag_time

# Captura en vivo solo de tráfico fragmentado
tcpdump -i eth0 'ip[6:2] & 0x3fff != 0' -c 200
# Este filtro BPF coincide con paquetes donde el flag MF o un offset de
# fragmento distinto de cero está fijado — es decir, cualquier fragmento
# que no sea un datagrama completo y sin fragmentar

# Cuenta fragmentos por origen para detectar fuentes de inundación
tcpdump -i eth0 'ip[6:2] & 0x3fff != 0' -c 5000 -n | awk '{print $3}' | sort | uniq -c | sort -rn | head

# Contador de nftables para regla de coincidencia de fragmento
nft add rule inet filter input ip frag-off != 0 counter

Técnicas de mitigación

Errores comunes

Cómo implementarlo con Azion

La red distribuida de Azion puede ayudar a absorber y filtrar tráfico de fragmentación IP anómalo antes de que llegue a tu origen, dependiendo de los productos habilitados y cómo estén configurados:

• DDoS Protection brinda detección y mitigación siempre activa para anomalías volumétricas y de protocolo, incluyendo patrones de fragmentación anómalos, en el edge de red.
• Network Shield puede aplicar reglas a nivel de red para validar la estructura de fragmentos y descartar patrones de fragmentación malformados o evasivos antes de que lleguen a la infraestructura de aplicación.
• Firewall permite reglas personalizadas para filtrar tráfico fragmentado por protocolo, patrón de origen, o características de fragmento específicas de tu entorno.
• WAAP combina controles de red y de capa de aplicación cuando la evasión basada en fragmentación se combina con intentos de ataque a nivel de aplicación.

Como Azion termina e inspecciona el tráfico en el edge antes de que llegue a tu origen, el reensamblado de fragmentos para requests entrantes puede ocurrir en la infraestructura de Azion en lugar de exponer directamente los buffers de reensamblado de tu origen a secuencias de fragmentos controladas por el atacante, aunque el comportamiento específico depende de tus productos configurados y perfil de tráfico.

Recursos relacionados

• ¿Qué es un ataque DDoS?
• Tipos de ataques DDoS
• ¿Qué es la protección y mitigación DDoS?
• ¿Qué es un ataque de fragmentación TCP?
• ¿Qué es un ataque UDP Flood?
• Azion DDoS Protection
• Azion Network Shield

Preguntas frecuentes

¿Qué es un ataque de fragmentación IP? Un ataque de fragmentación IP abusa del mecanismo de fragmentación y reensamblado del protocolo IP —los campos de offset de fragmento, Identificación, y Más Fragmentos definidos en RFC 791— para colapsar código de reensamblado vulnerable, evadir firewalls que solo inspeccionan el primer fragmento, o agotar la memoria que un objetivo reserva para hacer buffer de conjuntos de fragmentos incompletos. Opera a nivel de red, por debajo de TCP y UDP.

¿Qué es el ataque Teardrop y sigue siendo una amenaza? Teardrop es un ataque de fragmentación IP de la era de los años noventa que envía fragmentos con offsets deliberadamente superpuestos, corrompiendo los cálculos de longitud de buffer en código de reensamblado vulnerable y colapsando el sistema operativo objetivo. Los kernels modernos validan los límites de fragmento y no son vulnerables al bug de colapso original, pero la técnica de fragmento superpuesto sigue siendo relevante para pruebas de evasión de firewall/IDS.

¿Qué es un ataque de fragmento diminuto? Un ataque de fragmento diminuto divide un paquete de modo que el primer fragmento es demasiado pequeño para contener un header de capa de transporte completo; por ejemplo, faltando el puerto de destino o los flags TCP, lo que puede causar que un firewall sin estado falle en evaluar y bloquear correctamente el paquete. RFC 1858 y RFC 3128 definen reglas de filtrado, como rechazar fragmentos con offset=1, específicamente para cerrar este hueco de evasión.

¿Cómo funciona un ataque de agotamiento de reensamblado de fragmentos? Un atacante envía un alto volumen de fragmentos que nunca completan un datagrama válido; por ejemplo, siempre fijando el flag Más Fragmentos sin nunca enviar el fragmento final para un valor de Identificación dado. Cada conjunto incompleto consume memoria de buffer de reensamblado hasta que expira un timeout, y a suficiente volumen esto agota la memoria o CPU dedicada al reensamblado de fragmentos, denegando el servicio al tráfico fragmentado legítimo.

¿Cuál es la diferencia entre la fragmentación IP y la fragmentación TCP? La fragmentación IP ocurre a nivel de red cuando un datagrama excede el MTU de un enlace, y es invisible para TCP; un solo segmento TCP puede dividirse en múltiples fragmentos IP sin que TCP lo sepa. La fragmentación TCP, más precisamente llamada segmentación, ocurre dentro de la propia capa TCP, dividiendo el flujo de bytes de la aplicación en segmentos con base en el Maximum Segment Size negociado, completamente independiente de si IP más adelante fragmenta esos segmentos.

¿Los firewalls pueden defenderse por completo contra los ataques de fragmentación inspeccionando cada fragmento individualmente? No. Inspeccionar los fragmentos individualmente es precisamente la debilidad que explotan los ataques de fragmento diminuto y superpuesto, ya que ningún fragmento individual puede contener suficiente información para tomar una decisión correcta. La defensa efectiva requiere que el firewall reensamble los fragmentos (o rastree el estado de fragmento) antes de aplicar reglas de filtrado de capa de transporte.

¿Por qué no puedo simplemente bloquear todo el tráfico IP fragmentado? Algún tráfico legítimo fragmenta legítimamente: respuestas DNSSEC grandes sobre UDP, ciertos protocolos de VPN y tunneling, y cualquier tráfico UDP que exceda el MTU de la ruta. Bloquear todos los fragmentos indiscriminadamente rompe estos casos de uso. Un mejor enfoque es aplicar políticas conscientes del protocolo que descarten la fragmentación solo para clases de tráfico donde no se espera.

¿Qué parámetros del kernel de Linux controlan el comportamiento de reensamblado IP? net.ipv4.ipfrag_high_thresh y net.ipv4.ipfrag_low_thresh controlan los umbrales de memoria en los que el kernel comienza y deja de desalojar conjuntos de fragmentos incompletos, y net.ipv4.ipfrag_time controla cuánto tiempo se mantiene un conjunto incompleto antes de hacer timeout. Ajustar estos de forma conservadora limita cuánta memoria puede consumir un flood de fragmentos antes de que el kernel comience a descartar conjuntos de fragmentos antiguos e incompletos.

¿Cómo detecto un ataque de fragmentación IP en progreso? Monitorea contadores del kernel como IpReasmReqds e IpReasmFails vía nstat -az por picos sostenidos y tasas de fallo en aumento, y usa un filtro BPF de tcpdump dirigido (ip[6:2] & 0x3fff != 0) para aislar el tráfico fragmentado para inspección más cercana. Una alta proporción de intentos de reensamblado a reensamblados exitosos, combinada con alta diversidad de IP de origen, es un indicador fuerte de un flood o intento de evasión activo.

¿IPv6 tiene las mismas vulnerabilidades de fragmentación que IPv4? IPv6 mueve la información de fragmentación a un header de extensión de Fragmento separado en lugar del header base, y los routers en la ruta ya no tienen permitido fragmentar paquetes; solo el host originador puede, usando Path MTU Discovery. Esto reduce parte de la superficie de ataque de fragmentación intermedia estilo IPv4, pero los hosts IPv6 todavía deben defenderse contra inundaciones de agotamiento de reensamblado y técnicas de evasión basadas en headers de extensión dirigidas a la misma lógica de reensamblado subyacente.

Fuentes

• IETF. “Internet Protocol.” RFC 791. 1981.
• IETF. “Security Considerations for IP Fragment Filtering.” RFC 1858. 1995.
• IETF. “Protection Against a Variant of the Tiny Fragment Attack.” RFC 3128. 2001.
• IETF. “IPv6 Fragment Header.” RFC 8200 (Especificación IPv6), Sección 4.5. 2017.
• CERT/CC. “CERT Advisory CA-1997-28: IP Denial-of-Service Attacks.” 1997.
• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.