Un ataque Ping of Death es una técnica de denegación de servicio legada que envía una solicitud de eco ICMP fragmentada y de tamaño excesivo, superando el máximo de 65,535 bytes del protocolo IP, causando un desbordamiento de buffer cuando el objetivo reensambla los fragmentos. Documentado por primera vez en 1996, colapsaba o reiniciaba los stacks TCP/IP vulnerables de esa era; los sistemas operativos modernos ya corrigieron esta falla, aunque los dispositivos embebidos y legados siguen en riesgo residual.
Resumen rápido — Ping of Death abusa de la fragmentación IP para entregar una solicitud de eco ICMP cuyo tamaño reensamblado excede el límite de 65,535 bytes definido por el protocolo IP (RFC 791). Las implementaciones de stack TCP/IP más antiguas asignaban buffers de reensamblado de tamaño fijo y no validaban la longitud total reconstruida antes de escribir en memoria, causando un desbordamiento de buffer que colapsaba, congelaba o reiniciaba al objetivo. Windows, macOS, Linux y la mayoría del equipo de red corrigieron esta falla a finales de los años noventa. El ataque persiste como categoría de riesgo solo para sistemas embebidos sin parchar, sistemas de control industrial y dispositivos IoT que corren stacks de red obsoletos.
Última actualización: 2026-08-08
Cómo funciona el ataque
Cada paquete IP tiene un tamaño máximo total de 65,535 bytes, incluyendo headers; un límite fijado por el campo Total Length de 16 bits en el header IP (RFC 791). Una sola solicitud de eco ICMP (“ping”) es mucho más pequeña que esto, así que un atacante no puede enviar directamente un paquete de tamaño excesivo. En cambio, el ataque se apoya en la fragmentación IP: el stack emisor (o una herramienta de creación manual de paquetes) divide el paquete ICMP en fragmentos, cada uno con un tamaño individual válido, pero con offsets de fragmento construidos de modo que el total reensamblado exceda los 65,535 bytes.
Solicitud de eco ICMP normal:Header IP (20 bytes) + Header ICMP (8 bytes) + Datos (≤ 65,507 bytes)Total ≤ 65,535 bytes (tamaño máximo de paquete IP)
Secuencia de fragmentos de Ping of Death:Fragmento 1: offset = 0, longitud = 65,000 [flag de más fragmentos activado]Fragmento 2: offset = 65,000, longitud = 1,000 [flag de último fragmento activado] │ ▼El buffer de reensamblado del objetivo recibe: 65,000 + 1,000 + headers = 65,536+ bytes → excede el límite de 65,535 bytes │ ▼Desbordamiento de buffer de reensamblado de tamaño fijo → colapso, congelamiento o reinicioEn los stacks vulnerables, la rutina de reensamblado asignaba un buffer dimensionado a la longitud máxima declarada del paquete y copiaba los datos de fragmentos entrantes en él sin validar que el offset final más la longitud se mantuvieran dentro de los límites. El resultado era un desbordamiento de buffer clásico: se sobrescribía memoria adyacente al buffer, corrompiendo estructuras de datos del kernel y típicamente colapsando el sistema operativo (la “pantalla azul de la muerte” en las versiones afectadas de Windows era un síntoma común).
Contexto histórico
Ping of Death se identificó y publicitó a finales de 1996, afectando rápidamente a una amplia gama de sistemas operativos y equipo de red, incluyendo versiones tempranas de Windows 95, Windows NT, classic Mac OS, varias variantes de UNIX, y routers e impresoras de múltiples proveedores. Como el exploit requería solo un paquete manipulado, enviable desde cualquier máquina con una herramienta de raw socket, se propagó rápidamente como ataque de prueba de concepto.
Los proveedores publicaron parches durante 1997, corrigiendo las rutinas de reensamblado para validar la longitud total del paquete antes de asignar o escribir en buffers. CERT/CC y otros centros de coordinación documentaron la vulnerabilidad y distribuyeron guías de mitigación en avisos de ese periodo. Para principios de los años 2000, Ping of Death se consideraba completamente resuelto en los sistemas operativos principales.
Ping of Death vs. ICMP Flood moderno
| Aspecto | Ping of Death (legado) | ICMP Flood (moderno) |
|---|---|---|
| Mecanismo | Un solo paquete fragmentado, de tamaño excesivo o malformado | Alto volumen de paquetes ICMP de tamaño normal |
| Debilidad explotada | Desbordamiento de buffer de reensamblado (corrupción de memoria) | Agotamiento de ancho de banda y CPU |
| Paquetes requeridos | Tan pocos como uno | Miles a millones por segundo |
| Efecto principal | Colapso, congelamiento o reinicio | Denegación de servicio por saturación de recursos |
| Exposición en sistemas modernos | Parchado desde finales de los años noventa | Todavía relevante; mitigado con rate limiting |
| Objetivos típicos hoy | Dispositivos embebidos/IoT/ICS sin parchar | Cualquier host o red orientada a internet |
Por qué los sistemas modernos son en gran medida inmunes
Los kernels de sistemas operativos modernos validan la longitud total del paquete reconstruido durante el reensamblado de fragmentos IP y rechazan o descartan conjuntos de fragmentos que excederían el límite de 65,535 bytes, per hardening que siguió a RFC 791 y la guía de reensamblado posterior (RFC 815). Los stacks de red de sistemas operativos estándar (Windows, Linux, sistemas derivados de BSD, macOS) han mantenido estas verificaciones por más de dos décadas, y la mayoría de los firewalls y sistemas de prevención de intrusiones también descartan secuencias de fragmentos malformadas antes de que lleguen al stack del host.
El riesgo residual permanece en tres categorías:
- Dispositivos embebidos e IoT que corren stacks TCP/IP mínimos u obsoletos que nunca se parchearon
- Sistemas de control industrial legados (ICS/SCADA) que corren sistemas operativos sin soporte durante ciclos de vida extendidos
- Implementaciones de stack de red personalizadas o de terceros (que se encuentran en algunos routers, impresoras y appliances) que reimplementan el manejo de fragmentación sin el mismo rigor de validación
Detección y mitigación
- Validación de paquetes a nivel de kernel — los stacks modernos rechazan conjuntos de fragmentos cuya longitud reensamblada exceda el máximo de IP; verifica que este comportamiento esté presente y sin modificar en sistemas legados o embebidos
- Límites de reensamblado de fragmentos IP — configura el tamaño máximo del buffer de reensamblado y el timeout en el firewall o host para descartar cadenas de fragmentos incompletas o de tamaño excesivo
- Reglas de firewall que descartan fragmentos malformados — filtra fragmentos con offsets inconsistentes o que producirían un tamaño total de paquete más allá de 65,535 bytes
- Rate limiting de ICMP — limita el volumen de solicitudes de eco ICMP por origen, lo que también mitiga los ICMP floods convencionales
- Gestión de parches para dispositivos embebidos e ICS — trata los stacks de red legados sin parchar como una exposición conocida y aíslalos detrás de segmentación de red donde el parcheo no sea viable
Cómo implementarlo con Azion
DDoS Protection de Azion inspecciona el tráfico en el edge de la red, filtrando paquetes ICMP malformados, de tamaño excesivo y fragmentados antes de que lleguen a la infraestructura de origen. Network Shield puede ayudar a aplicar límites de reensamblado de fragmentos y descartar paquetes que violen las restricciones de tamaño de protocolo en las capas 3 y 4. Las reglas de Firewall se pueden configurar para bloquear patrones de tráfico ICMP consistentes con intentos de exploit legados, agregando una capa de defensa basada en políticas para orígenes que todavía corran equipo de red legado o embebido detrás de Azion.
Recursos relacionados
- ¿Qué es un ataque DDoS?
- Tipos de ataques DDoS
- ¿Qué es la protección y mitigación DDoS?
- ¿Qué es un ataque ICMP Flood?
- Azion DDoS Protection
Preguntas frecuentes
¿Qué es un ataque Ping of Death? Un ataque Ping of Death envía una solicitud de eco ICMP fragmentada que se reensambla en un paquete más grande que el límite de 65,535 bytes del protocolo IP. Los sistemas vulnerables fallan al validar el tamaño reconstruido, causando un desbordamiento de buffer que colapsa, congela o reinicia al objetivo.
¿Ping of Death sigue siendo una amenaza hoy? Largamente no, para los sistemas operativos y equipo de red principales, que han sido parchados desde finales de los años noventa. Sigue siendo un riesgo real para sistemas embebidos sin parchar, dispositivos IoT, y sistemas de control industrial legados que corren stacks TCP/IP obsoletos.
¿En qué se diferencia Ping of Death de un ICMP flood moderno? Ping of Death explota un bug de manejo de memoria con un solo paquete malformado para colapsar directamente al objetivo. Un ICMP flood moderno envía altos volúmenes de paquetes ICMP normales para agotar el ancho de banda o CPU, sin requerir ningún defecto de software en el objetivo.
¿Por qué es significativo el número 65,535 bytes? El campo Total Length del header IP es de 16 bits, limitando cualquier paquete IP individual —incluyendo todos sus datos— a 65,535 bytes. Ping of Death construye fragmentos que se reensamblan más allá de este límite, un estado para el que el stack del objetivo nunca fue diseñado para manejar de forma segura.
¿Ping of Death puede lanzarse desde una sola máquina? Sí. Como explota una falla de software en lugar de depender del volumen, un solo paquete manipulado desde un origen podría colapsar un objetivo vulnerable, lo que es parte de por qué se propagó rápidamente como prueba de concepto en 1996-1997.
¿Qué sistemas operativos fueron afectados por Ping of Death? Windows 95 y Windows NT tempranos, classic Mac OS, varias variantes de UNIX, y equipo de red como routers e impresoras de múltiples proveedores fueron afectados antes de que se publicaran parches en 1997.
¿Cómo previenen los sistemas modernos Ping of Death? Los kernels modernos validan la longitud total del paquete reensamblado durante el reensamblado de fragmentos IP y descartan conjuntos de fragmentos que excederían el máximo de 65,535 bytes, previniendo el desbordamiento de buffer que hizo posible el exploit original.
¿Ping of Death solo usa ICMP? El exploit clásico usaba solicitudes de eco ICMP porque “ping” era una forma simple y universalmente disponible de disparar el reensamblado de fragmentos. El desbordamiento de buffer subyacente teóricamente podría aplicarse a cualquier payload IP fragmentado de tamaño excesivo, pero ICMP es lo que define el ataque con nombre propio.
¿Qué dispositivos siguen en riesgo de ataques estilo Ping of Death? Los dispositivos embebidos, productos IoT, y sistemas de control industrial legados que corren stacks TCP/IP mínimos o sin parchar son el riesgo residual principal, ya que puede que nunca hayan recibido las correcciones de validación de reensamblado aplicadas a los sistemas operativos principales.
¿Cómo se detecta Ping of Death en una red? La detección depende de identificar tráfico ICMP fragmentado con combinaciones de offset y longitud que se reensamblarían más allá de 65,535 bytes, o simplemente descartar cualquier cadena de fragmentos que exceda el tamaño máximo de paquete IP en el firewall antes de intentar el reensamblado.
¿Cuál es la relación entre Ping of Death y la fragmentación IP? Ping of Death es un exploit específico que abusa de la fragmentación IP —el mecanismo que divide paquetes grandes en piezas más pequeñas para su transmisión— como su método de entrega. Ataca un bug de reensamblado en lugar de explotar la fragmentación en sí como categoría.
¿Debería preocuparme todavía Ping of Death en un entorno cloud-native? El riesgo directo es mínimo, ya que los stacks de red de los proveedores de cloud y los load balancers están actualizados y parchados. La preocupación residual aplica principalmente a hardware legado on-premises, entornos ICS/OT, o flotas IoT que se conectan a servicios alojados en cloud.
Fuentes
- CERT|CC. Avisos que documentan la vulnerabilidad Ping of Death y parches de proveedores, mediados de los años noventa.
- IETF. “Internet Protocol.” RFC 791. 1981.
- IETF. “IP Datagram Reassembly Algorithms.” RFC 815. 1982.
- IETF. “Internet Control Message Protocol.” RFC 792. 1981.
- NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.