O Ping of Death é um clássico da história da cibersegurança: um ataque que, na sua versão original dos anos 90, conseguia paralisar sistemas inteiros enviando um único pacote ICMP. Para perceber porque funcionava — e o que ainda nos ensina — é preciso descer ao nível dos protocolos de rede e olhar para a forma como diferentes camadas do modelo OSI tratam o tamanho dos pacotes.
Duas camadas, dois limites
Os pacotes ping têm origem na Camada 3 (Network layer) da pilha OSI — onde vive o protocolo IP e o ICMP que o ping usa. O pacote IP tem um campo de comprimento de 16 bits, o que define o tamanho máximo de um pacote na camada 3 em 65.535 bytes.
Na Camada 2 (Data Link layer), o tamanho máximo de uma frame é definido pelo MTU da rede — tipicamente cerca de 1.500 bytes em redes Ethernet padrão. Isto significa que um pacote grande vindo da camada 3 pode ter de ser fragmentado na camada 2 antes de ser entregue à camada física.
65.535
bytes — máximo IP (camada 3)
1.500
bytes — MTU típico Ethernet (camada 2)
~44
fragmentos para um pacote no limite máximo
Como funciona a fragmentação IP
Quando um pacote IP é maior do que o MTU do caminho, é partido em fragmentos. Cada fragmento viaja independentemente, transportando metadados que permitem ao destinatário reconstruir o pacote original:
- Identification — identificador comum a todos os fragmentos do mesmo pacote.
- Fragment Offset — posição (em unidades de 8 bytes) deste fragmento dentro do pacote original.
- More Fragments (MF) — flag que indica se ainda vêm mais fragmentos a seguir.
O destinatário guarda os fragmentos em memória e remonta o pacote original quando todos chegarem. Esta remontagem é a parte sensível — e é exatamente aqui que o Ping of Death entra em cena.
O ataque: ping fora dos limites
O Ping of Death é um ping em que o pacote ICMP é maior do que o MTU e que, por isso, precisa de ser fragmentado na camada 2. A questão é simples: um verdadeiro pacote ping nunca devia precisar de ser fragmentado.
Manipulando os campos de fragmentação — em particular o fragment offset e o tamanho dos fragmentos — o atacante constrói uma sequência que, depois de remontada pelo destinatário, ultrapassa o limite teórico de 65.535 bytes do pacote IP. A pilha de rede de muitos sistemas antigos não tinha verificação para este caso e, ao tentar montar o pacote em memória, gerava um buffer overflow no kernel — provocando crash, reboot ou comportamento errático.
Cenário Normal
Ping legítimo
Um echo request ICMP típico tem 64 a 84 bytes. Cabe folgadamente num MTU Ethernet de 1.500 bytes — não há fragmentação. O destinatário processa o pacote inteiro e responde com um echo reply.
Tamanho usual: 64 bytes · Fragmentos: 1
Sob Ataque
Ping of Death
Pacote ICMP forjado maior do que o MTU e com offsets que, ao remontar, ultrapassam os 65.535 bytes. O kernel da vítima escreve fora do buffer reservado e colapsa a pilha de rede.
Resultado: crash, reboot ou bloqueio da máquina.
Porque é que funcionou (e porque é que hoje quase não funciona)
O Ping of Death é, no fundo, um buffer overflow no kernel exposto através da pilha de rede. As implementações de TCP/IP do final dos anos 90 — em Windows 95/NT, Linux antigo, várias variantes de Unix, equipamento de rede e até impressoras — assumiam que um pacote IP nunca passaria os 65.535 bytes e dimensionavam os buffers de remontagem em conformidade. Quando a soma dos fragmentos excedia esse limite, o resultado era escrita fora dos limites e tudo o que daí decorre.
Hoje, sistemas operativos modernos validam corretamente os offsets e os tamanhos dos fragmentos antes de qualquer escrita; ainda assim, o conceito mantém-se relevante porque pertence a uma família mais alargada de ataques baseados em fragmentação: Teardrop, Bonk, Boink, Jolt2, e os ataques modernos a stacks IPv6 com cabeçalhos de extensão sobrepostos. Todos exploram a mesma ideia: fazer a vítima remontar algo que não devia ser possível remontar.
Mitigação
- Manter sistemas atualizados: a defesa principal contra Ping of Death e variantes é a correção que todas as pilhas TCP/IP modernas já trazem. Sistemas legados não atualizados continuam vulneráveis a esta família inteira.
- Filtrar fragmentos ICMP no perímetro: não há razão legítima para um echo request chegar fragmentado a um servidor exposto à Internet. Bloquear ou inspecionar pacotes ICMP fragmentados na firewall.
- Limitar o tamanho máximo de pacotes ICMP aceites pela firewall (ex.: rejeitar echo > 1.000 bytes em ambientes onde só se espera ping normal).
- Rate limiting de ICMP echo em routers e firewalls — útil contra esta classe e contra outros abusos de ICMP.
- Validação de fragmentação na firewall (DPI): firewalls modernas remontam fragmentos antes de inspecionar; rejeitam offsets sobrepostos, soma fora de limites e flags inconsistentes.
- IDS/IPS com assinaturas de fragmentação anómala (Suricata, Snort, Wazuh com regras personalizadas) para detetar tentativas remanescentes contra equipamento legado interno.
- Inventário de equipamento legado: impressoras, controladores industriais, NAS antigos e firmware esquecido continuam a ser alvos plausíveis — mapeá-los e segmentá-los é parte do trabalho.
Conclusão
O Ping of Death é uma lição sobre o que acontece quando uma camada confia, sem verificar, no que outra camada lhe entrega. A camada 3 promete que um pacote nunca passa de 65.535 bytes; a camada 2 fragmenta para caber no MTU; a remontagem pressupõe que tudo bate certo. Quebre essa pressuposição e a pilha inteira pode cair.
Para uma equipa defensiva, a tomada de consciência prática é dupla: um ping legítimo nunca precisa de ser fragmentado — qualquer fragmento ICMP a entrar na rede merece atenção; e a engenharia de proteção contra fragmentação maliciosa não acaba aqui — vive em IPv6, em túneis, em middleboxes e em todo o equipamento legado que ainda partilha a rede com sistemas modernos.