ARP Request/Reply

Quando um dispositivo precisa se comunicar com outro numa rede local (ou até mesmo na internet) uma informação que sabemos ser essencial para isso acontecer corretamente é o endereço IP, ele é o identificador único do dispositivo dentro da rede.

Mas ter o endereço IP não é suficiente para garantir que o tráfego seja encaminhado para o destino, diversos processos, protocolos e serviços precisam trabalhar em conjunto para isso (comunicação) acontecer, um desses processos é o computador local saber qual o endereço MAC do destino.

Quando um equipamento de rede (placas, módulos, adaptadores, etc) são produzidos, um identificador único conhecido como endereço MAC (MAC address) é atribuído ao equipamento, esse endereço também é referenciado como ‘burned-in MAC address’ ou ‘physical MAC address’.

O endereço MAC é um valor hexadecimal de 48 bits (ou 6 bytes). Utilizando a camada OSI como referência, o endereço MAC está situado na camada de ‘Enlace’ (camada 2).

Exemplo de formato de endereço MAC

Conforme mencionado, quando um dispositivo precisa se comunicar com outro na mesma rede, além do endereço IP, ele precisa saber qual dispositivo na rede responde a esse endereço, para isso, o sistema operacional (Windows, Linux, MacOS, etc) cria uma tabela que vincula IP vs endereço MAC, essa tabela é chamada ‘arp cache’ ou ‘tabela arp’.

No Windows é possível verificar as entradas dessa tabela através do comando ‘arp -a’ (cmd).

No exemplo acima, o endereço IP 192.168.1.1 possui o endereço MAC 30:85:A9:6C:2B:B0, também é possível verificar que o dispositivo aprendeu esse endereço de forma dinâmica, para isso o dispositivo faz uso do protocolo ARP (address resolution protocol).

A animação abaixo mostra de forma simples como isso acontece.

Note que o frame é gerado com o MAC address do originador, mas a máquina local não sabe qual o MAC address do destino (ainda), por esse motivo ele precisa alcançar todos os possíveis dispositivos na rede, isso é possível ao utilizar o endereço de broadcast ‘FF: FF: FF: FF: FF: FF’ como destino, isso garante que o frame seja recebido por todos os hosts da rede, sendo que quem não é o IP destino requisitado apenas descarta o frame.

Como sempre, temos um exemplo desse processo através de uma captura do Wireshark.

Podemos ver abaixo uma requisição sendo enviada pela IP ‘192.168.1.64’ para o endereço de broadcast de camada 2 ‘FF: FF: FF: FF: FF: FF’, fazendo uma query na rede de qual é o MAC address do IP 192.168.1.117. Note que essa mensagem é um ‘ARP request’, isso pode ser verificado no código da mensagem também apresentado abaixo.

O endereço IP ‘192.168.1.117’ ao receber o frame responde diretamente ao solicitante (note o MAC address destino). Note também que o código da mensagem agora é ‘Reply’ (arp reply).

A partir desse momento, ambos hosts atualizam sua tabela/cache arp e são capazes de se comunicarem diretamente entre si sem ficar fazendo ‘arp requests’ frequentes.

É bom mencionar que essa tabela/cache é temporária, o sistema operacional a limpa depois de certo período, quando isso acontece e os dispositivos precisam comunicar entre si novamente, o processo de ‘arp-request/arp-reply’ precisa ser repetido.

Existem algumas outras formas de um dispositivo possuir o endereço MAC de um IP na sua tabela arp, uma delas é criar a entrada manualmente, os sistemas operacionais permitem isso. Abaixo temos um exemplo de entradas estáticas.

É importante mencionar que a entrada estática tem valor local, logo, se o destino não possuir uma entrada estática para a origem, o processo de arp-request/arp-reply precisa acontecer.

Uma outra forma do computador local aprender sobre endereços MAC é receber anúncios chamado ‘Gratuitous Arp’, nessas mensagens um dispositivo de rede anuncia seu IP e MAC para a rede, ao receber essas mensagens os equipamentos incluem a entrada em sua tabela arp, mesmo que não tenha feito nenhuma requisição (por isso do nome ‘Gratuitous Arp’).

Por natureza o protocol ARP é inseguro, ele recebe a informação e considera que ela foi originada de uma fonte confiável, porém alguns ataques fazem proveito dessa fragilidade do protocolo para interceptar tráfego, esse tipo de ataque é conhecido como Man-in-the-Middle, em um outro artigo vou abordar sobre esse ataque e formas de mitiga-lo.