← voltar pro blog
// segurança

ARP Poisoning na prática: interceptei todo o tráfego da rede em 3 comandos

por Luiz Silvério

ARP não tem autenticação. Isso não é bug, é o design original do protocolo, criado nos anos 80 quando a internet era uma rede acadêmica e ninguém pensava em atacante dentro da mesma LAN.

O problema é que esse protocolo dos anos 80 ainda roda em toda rede corporativa hoje. E o ataque que ele permite leva 3 comandos.

Tudo que está aqui é para execução em lab controlado. EVE-NG, máquinas virtuais, rede isolada. Fazer isso em rede de terceiros é crime.

Como ARP funciona (e onde está o problema)

Quando o seu notebook quer falar com o gateway 10.0.0.1, ele precisa do MAC address desse gateway. IP é camada 3. MAC é camada 2. O switch encaminha quadros por MAC, não por IP.

O notebook manda um ARP Request em broadcast: "quem tem o IP 10.0.0.1? Me diz seu MAC."

O gateway responde: "sou eu, meu MAC é aa:bb:cc:dd:ee:ff."

O notebook anota isso na ARP cache e começa a enviar os quadros para aquele MAC.

O problema: ARP não verifica se quem respondeu realmente tem aquele IP. Qualquer dispositivo na mesma rede pode mandar um ARP Reply não solicitado dizendo "o IP 10.0.0.1 é meu, meu MAC é 11:22:33:44:55:66". O notebook acredita. Atualiza a cache. Passa a mandar o tráfego pro atacante.

Isso se chama ARP Poisoning ou ARP Spoofing.

O lab: topologia no EVE-NG

[ PC-Vítima ]      [ PC-Atacante ]      [ Gateway ]
  10.0.0.10          10.0.0.20           10.0.0.1
      |                   |                  |
      +-------------------+------------------+
                     [ Switch ]
                      VLAN 10

Três nós conectados no mesmo switch. PC-Atacante é uma VM Kali Linux. PC-Vítima pode ser qualquer Linux ou Windows. Gateway é o roteador da rede.

O ataque: 3 comandos no Kali

Passo 1: habilitar IP forwarding

Sem isso, o Kali descarta os pacotes que chegam destinados a outros. O tráfego da vítima cai. O ataque fica visível porque a vítima perde conectividade.

root@kali:~# echo 1 > /proc/sys/net/ipv4/ip_forward

Com IP forwarding ativo, o Kali repassa os pacotes depois de lê-los. A vítima continua navegando. O atacante vê tudo.

Passo 2: envenenar o cache ARP da vítima

root@kali:~# arpspoof -i eth0 -t 10.0.0.10 10.0.0.1

Esse comando manda ARP Replies contínuos para 10.0.0.10 dizendo: "o IP 10.0.0.1 está no meu MAC". A vítima atualiza a cache e passa a mandar o tráfego destinado ao gateway para o Kali.

Passo 3: envenenar o cache ARP do gateway

root@kali:~# arpspoof -i eth0 -t 10.0.0.1 10.0.0.10

Agora o gateway também acha que a vítima está no MAC do Kali. O tráfego de volta também passa pelo atacante.

O Man-in-the-Middle está completo. Todo pacote entre a vítima e o gateway passa pelo Kali antes de chegar ao destino.

Verificando na vítima:

C:\> arp -a
Interface: 10.0.0.10
  10.0.0.1    11-22-33-44-55-66   dynamic   ← MAC do Kali, não do gateway
  10.0.0.20   11-22-33-44-55-66   dynamic   ← mesmo MAC

Os dois IPs apontando para o mesmo MAC. Cache envenenada.

Capturando o tráfego no Kali:

root@kali:~# tcpdump -i eth0 -n host 10.0.0.10
10.0.0.10.54231 > 10.0.0.1.80: HTTP GET /login HTTP/1.1
10.0.0.10.54231 > 10.0.0.1.80: POST /login user=admin&pass=senha123

Credenciais em texto claro capturadas. Isso funciona para qualquer protocolo sem criptografia: HTTP, FTP, Telnet, POP3.

▌ Note que: HTTPS protege o conteúdo mas não esconde o destino. Com ARP Poisoning ativo, o atacante ainda vê quais sites a vítima acessa, volumes de tráfego e pode tentar ataques de SSL stripping em sites mal configurados.

A defesa: Dynamic ARP Inspection no switch Cisco

DAI (Dynamic ARP Inspection) é o recurso do switch que valida cada ARP Reply antes de repassar. Ele cruza o MAC e o IP do ARP com a tabela de DHCP Snooping. Se não bater, o pacote é descartado.

Pré-requisito: habilitar DHCP Snooping

SW(config)# ip dhcp snooping
SW(config)# ip dhcp snooping vlan 10
SW(config)# no ip dhcp snooping information option

Habilitar DAI na VLAN

SW(config)# ip arp inspection vlan 10

Marcar a porta do gateway como trusted

Portas untrusted têm ARP validado. Portas trusted passam direto. A porta do gateway precisa ser trusted, senão o DAI bloqueia os ARPs legítimos do próprio gateway.

SW(config)# interface GigabitEthernet0/1
SW(config-if)# description Gateway
SW(config-if)# ip arp inspection trust

Portas dos hosts ficam untrusted por padrão. Nenhuma configuração adicional necessária.

Verificando

SW# show ip arp inspection vlan 10

Vlan  Configuration  Operation  ACL Match  Static ACL
----  -------------  ---------  ---------  ----------
  10  Enabled        Active

Vlan  Forwarded  Dropped  DHCP Drops  ACL Drops
----  ---------  -------  ----------  ---------
  10        847       12           0         12

12 pacotes dropados. São os ARP Replies do Kali sendo descartados pelo switch antes de chegar na vítima.

Com DAI ativo, o ataque dos 3 comandos não funciona. A cache ARP da vítima não é envenenada. O tráfego segue direto para o gateway.


ARP Poisoning é o ataque mais simples de executar numa LAN e o mais negligenciado em produção. DAI leva 3 linhas de configuração. A maioria das redes não tem nenhuma das duas coisas: nem o conhecimento do ataque, nem a defesa.