Home Comunidade Eventos YouTube Networks Desafios // produtos Academy News CTI | CVE Contato

06 - Type 8 - Echo Request

video explicativo
Video explicativoEspaco reservado para o video desta anotação — adicione video: https://youtu.be/... no frontmatter da nota.

ICMP Type 8 - Echo Request (Solicitação de Eco)

A mensagem ICMP Type 8 (Echo Request) é a solicitação ativa utilizada para iniciar um teste de conectividade. É a primeira metade do mecanismo conhecido popularmente como Ping. Enquanto o Type 0 é a resposta, o Type 8 é a pergunta.

Esta mensagem é enviada por um host (origem) para um host ou roteador (destino) com o objetivo de verificar se o destino está ativo, acessível e se o caminho de rede entre os dois pontos é viável. O termo "Echo" (Eco) refere-se à expectativa de que o receptor envie de volta exatamente os mesmos dados que recebeu, criando um ciclo de solicitação e resposta.

1. Contexto Técnico e RFCs

Atributo Valor
RFC de definição RFC 792 (1981), atualizado pela RFC 4884 e RFC 8335
Camada 3 (Rede) — ICMP é parte integrante do IP
Protocolo IP 1 (campo Protocol do IPv4)
Type 8 (Echo Request)
Resposta esperada Type 0 (Echo Reply)
Porta ICMP não usa portas (é protocolo L3)

O ICMP é definido como parte integral do IP (RFC 792): todo host IPv4 deve implementá-lo. O IPv6 tem equivalente próprio, o ICMPv6 (RFC 4443), com Type 128 (Echo Request) e Type 129 (Echo Reply).

2. Função e Propósito

A função primária do Echo Request é a verificação de alcance (reachability). Em uma rede de comutação de pacotes não confiável como o IP, não existe nenhum mecanismo padrão que indique se um destino está online até que se tente enviar dados para ele.

  • Interrogação Ativa: Ao contrário de mensagens de erro ICMP (que são reativas), o Echo Request é gerado proativamente por um usuário ou script administrativo (via comando ping).
  • Teste de Vitalidade: Se o destino estiver online e configurado para responder, ele processará a solicitação. Se o destino estiver offline, desconectado, ou se houver um firewall bloqueando o tráfego, a solicitação falhará (timeout) ou resultará em um erro (Destination Unreachable).
  • Medição de Latência: Como o remetente registra o timestamp exato do envio e o receptor devolve os mesmos dados, o RTT (Round-Trip Time) pode ser calculado com precisão milimétrica.

3. Estrutura Detalhada do Cabeçalho ICMP

A mensagem Echo Request possui uma estrutura simples, mas contém campos essenciais para permitir que o remetente identifique corretamente a resposta entre o tráfego de rede.

Offset Campo Tamanho Função
0 Type 8 bits Valor fixo 8. Identifica como Echo Request
1 Code 8 bits Valor fixo 0. Reservado para Echo Request
2-3 Checksum 16 bits Soma de verificação do ICMP (complemento de um)
4-5 Identifier 16 bits ID arbitrário escolhido pelo remetente
6-7 Sequence Number 16 bits Contador incremental por requisição
8+ Data Variável Carga útil (padding, timestamp, etc.)

Detalhamento dos Campos

  • Identifier (Identificador): Um valor arbitrário escolhido pelo remetente. Em sistemas Unix/Linux, este campo geralmente é preenchido com o PID (Process ID) do processo que está executando o comando ping. Isso permite que o sistema operacional roteie a resposta de volta para o processo correto caso haja múltiplos pings rodando simultaneamente. Em Windows, é usado um valor fixo (0x0100 por padrão).
  • Sequence Number (Número de Sequência): Um contador incremental que começa em 0 (ou 1) e aumenta em 1 para cada novo Echo Request enviado. Permite que o remetente monitore a perda de pacotes e a ordem de chegada. Se o remetente enviou as sequências 1, 2 e 3, mas recebeu respostas para 1 e 3 apenas, ele sabe que o pacote 2 foi perdido.
  • Data (Dados Variáveis): Uma carga útil arbitrária inserida pelo remetente. Geralmente é um conjunto de caracteres ASCII (ex: abcdefghijklmnopqrstuvwabcdefghij) ou dados de timestamp. O receptor deve devolver esses mesmos dados no Echo Reply. Isso permite calcular o RTT com precisão, pois o remetente sabe exatamente o que foi enviado.

Dump Hexadecimal de um Echo Request

08 00          ← Type=8, Code=0
4d 5a          ← Checksum (0x4D5A)
00 01          ← Identifier (PID 1)
00 01          ← Sequence Number (1)
61 62 63 64    ← Data ("abcd...")
65 66 67 68    ← Data ("efgh...")
69 6a 6b 6c    ← Data ("ijkl...")
...

4. O Processo de Geração e Envio

Quando um usuário digita ping 192.168.1.1, ocorre o seguinte fluxo técnico:

  1. Criação do Socket: A aplicação ping cria um socket especial (geralmente um socket RAW SOCK_RAW com protocolo IPPROTO_ICMP, ou um socket ICMP específico SOCK_DGRAM com IPPROTO_ICMP em sistemas Linux modernos). Em Linux, requer privilégios de root (ou a capability CAP_NET_RAW).
  2. Construção do Pacote: O Kernel constrói o cabeçalho ICMP Type 8, insere o PID no Identifier, o número atual no Sequence Number e preenche o campo Data com o padding necessário (geralmente o tamanho é configurável: 32 bytes padrão no Windows, 56 bytes padrão no Linux).
  3. Encapsulamento IP: O pacote ICMP é passado para a Camada de Rede, que o encapsula em um datagrama IP. O campo Protocol do IP é definido como 1.
  4. Resolução ARP/NDP: Se o destino está na mesma rede local, o host precisa resolver o MAC do destino via ARP (IPv4) ou NDP (IPv6).
  5. Transmissão: O pacote é enviado pela interface de rede para o gateway padrão (ou diretamente ao destino, se local).

Exemplo Prático

$ ping -c 4 -s 100 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 100(128) bytes of data.
108 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.421 ms
108 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.389 ms
108 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.401 ms
108 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.415 ms

--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.389/0.406/0.421/0.022 ms

5. Comportamento no Destino

Ao receber um datagrama IP contendo um ICMP Type 8:

  • Validação: O destino verifica o checksum do ICMP. Se inválido, descarta silenciosamente.
  • Processamento do Kernel: O sistema operacional do destino (não uma aplicação de usuário) reconhece o Echo Request e o processa nativamente. Isso é uma das características singulares do ICMP: ele não passa pela Camada de Transporte nem atinge aplicações.
  • Geração da Resposta: O kernel inverte os endereços IP de origem e destino, cria um novo cabeçalho ICMP Type 0 (Echo Reply), copia o Identifier e Sequence Number recebidos, e devolve os mesmos Data inalterados.
  • Envio: O pacote é roteado de volta para a origem. Se a origem não for alcançável, o destino envia um ICMP Type 3 (Destination Unreachable).

6. Variações e Flags do Comando Ping

Flag Efeito Exemplo
-c N Envia apenas N pacotes ping -c 5 8.8.8.8
-i T Intervalo T segundos ping -i 2 8.8.8.8 (flood precisa root)
-s N Tamanho do payload ping -s 1500 8.8.8.8
-t N TTL inicial ping -t 1 8.8.8.8 (1º salto)
-W T Timeout (segundos) ping -W 1 8.8.8.8
-f Flood (100 pacotes/s) ping -f 8.8.8.8 (requer root)
-4 / -6 Força IPv4/IPv6 ping -6 ipv6.google.com

7. Segurança e Bloqueio

Apesar de sua utilidade diagnóstica, o ICMP Type 8 é frequentemente alvo de restrições de segurança.

  • Revelação de Topologia: Se um atacante enviar Echo Requests para uma rede e receber respostas, ele mapeia quais hosts estão ativos (reconhecimento de rede, etapa inicial de ataques).
  • Amplificação (Smurf Attack): Um ataque histórico (anos 1990) onde o atacante enviava Echo Requests com o endereço IP da vítima como origem para um endereço de broadcast. Todos os hosts na rede respondiam à vítima simultaneamente, sobrecarregando-a. Mitigado por RFC 2644 (roteadores não encaminham broadcast para rede externa) e por proteção Smurf em SOs modernos.
  • Ping of Death (Histórico): Envio de Echo Request com payload malformado maior que 65535 bytes (após fragmentação) que causava buffer overflow em stacks IP antigos (Windows 95). Resolvido em patches de 1997.
  • ICMP Tunneling: Ferramentas como ptunnel e icmptunnel encapsulam tráfego TCP arbitrário dentro de Echo Request/Reply, contornando firewalls que só permitem ICMP.
  • Bloqueio em Firewalls: Por esses motivos, muitos firewalls de borda (especialmente em servidores públicos expostos à internet) são configurados para descartar silenciosamente (Drop) pacotes ICMP Type 8. Isso faz com que servidores web, por exemplo, pareçam "mortos" para um comando ping padrão, embora estejam servindo páginas web normalmente (HTTP porta 80).

Exemplo de Regra iptables para Limitar Ping

# Permitir ping mas limitar a 1 pacote/segundo com burst de 5
iptables -A INPUT -p icmp --icmp-type echo-request \
    -m limit --limit 1/s --limit-burst 5 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

8. Diagnóstico Prático Avançado

Mapeamento de Caminho (Ping com TTL Variável)

Embora o traceroute seja mais eficiente para esse propósito, é possível mapear rota manualmente:

for i in 1 2 3 4 5; do
    ping -c 1 -t $i 8.8.8.8 | grep -E "From|bytes from"
done

Diferenciação de Falhas

Sintoma Diagnóstico Provável
Request timeout Firewall dropou pacote OU host offline
Destination Host Unreachable Roteador não tem rota para o destino
Destination Net Unreachable Sem rota para a rede do destino
TTL expired in transit Loop de roteamento ou rota muito longa
Resposta de IP diferente do destino NAT mal configurado ou roteamento assimétrico

9. Conclusão

O ICMP Type 8 (Echo Request) é a ferramenta de diagnóstico de redes mais ubíqua e essencial do arsenal de qualquer engenheiro de redes ou administrador de sistemas. Apesar de sua aparente simplicidade, ele é o mecanismo fundamental que permite verificar conectividade, latência e perda de pacotes em qualquer rede IP. Contudo, é importante lembrar que a ausência de um Echo Reply em resposta a um Echo Request não é prova definitiva de que o host está offline; pode ser apenas evidência de uma política de segurança filtrando o tráfego ICMP. Por isso, em diagnósticos avançados, deve-se sempre combinar ping com traceroute, tcpdump, telnet/nc (testes TCP em portas específicas) e curl para validar acessibilidade em múltiplas camadas.