Início / Notas técnicas / Falsificação de ARP e falhas de aprendizagem

Falsificação de ARP, personificação de gateway e falhas de aprendizagem

Um host que não consegue alcançar seu gateway parece igual, seja alguém atacando a LAN ou não. Veja como distinguir rapidamente um ataque de ARP forjado ou em inundação de uma simples falha de aprendizagem, os comandos display que resolvem isso, e a configuração antifalsificação que fecha a brecha definitivamente.

Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026

Por que o mesmo sintoma tem duas causas muito diferentes

Um host que não consegue fazer Ping para seu gateway parece idêntico, seja alguém atacando a LAN ou não haja ninguém.

Nos roteadores Huawei AR, os problemas de ARP sempre chegam ao mesmo ponto de partida: uma tabela display arp que não parece certa — uma entrada Incomplete, um host que some repentinamente da rede, um gateway que parece ter mudado. O instinto é presumir um ataque. Com a mesma frequência é um limite de taxa configurado de forma agressiva demais, uma configuração de ARP fast-reply no dispositivo errado, ou uma topologia de Spanning Tree que ainda não convergiu — e tratar um simples erro de configuração como uma intrusão desperdiça tempo perseguindo um atacante que nunca existiu.

A seguir está a divisão na qual esta nota se baseia — tráfego ARP forjado ou em inundação versus uma falha de aprendizagem genuína — as verificações para cada um com os comandos exatos, a configuração antifalsificação que fecha o lado do ataque definitivamente, e respostas de perguntas frequentes de casos de campo reais.

Entenda a divisão antes de mexer em qualquer configuração

As falhas de ARP se dividem em exatamente duas famílias: algo está forjando ou inundando ativamente tráfego ARP, ou o ARP simplesmente nunca é aprendido.

Classificar primeiro o sintoma em uma dessas duas famílias indica qual metade desta nota realmente se aplica — e evita que você configure defesas antifalsificação contra um problema que nunca foi um ataque.

Os rótulos do diagrama permanecem em inglês para clareza técnica.

Cada ramo do lado do ataque segue o mesmo padrão de correção: identificar a fonte forjada e depois fechá-la com uma chave antiataque. Cada ramo do lado da falha de aprendizagem é um simples problema de configuração ou de link que não tem nada a ver com um intruso — ativar recursos antifalsificação não resolve nada nesse caso.

Percorrendo cada ramo

O mesmo primeiro comando, display arp, direciona você para um destes dois ramos — tudo depois disso depende de em qual família você realmente está.

Ramo A — Confirmar se realmente há um ataque

Uma entrada Incomplete não prova por si só um ataque — o que realmente indica isso é o contador de descarte do CPU-defend.

Execute display arp e procure entradas onde MAC ADDRESS mostra Incomplete — isso confirma falha de aprendizagem de ARP, mas é o ponto de partida compartilhado pelos dois ramos, não prova de ataque por si só.
Execute display cpu-defend statistics packet-type arp-request all (ou arp-reply) e observe o contador Dropped por alguns segundos. Se estiver subindo dezenas ou mais por segundo, o limitador de taxa CPCAR está descartando pacotes ARP mais rápido do que o tráfego normal jamais geraria — essa é uma assinatura de ataque, não um problema de capacidade.
Configure o rastreamento da fonte de ataque para identificar quem realmente está enviando: uma política cpu-defend com auto-defend enable, depois display auto-defend attack-source para ler diretamente o MAC e o IP de origem infratores.
Se o próprio endereço do gateway parecer errado, verifique display arp para o IP do gateway — TYPE deve mostrar I- (pertencente à interface) — depois confirme se arp anti-attack gateway-duplicate enable está configurado. Se o recurso já sinalizou um infrator, display arp anti-attack gateway-duplicate item mostra diretamente o IP, o MAC e a interface de origem do atacante registrado.

<HUAWEI> display arp
IP ADDRESS      MAC ADDRESS    EXP(M) TYPE/VLAN       INTERFACE
10.1.2.1        Incomplete     0      D               10GE0/0/1
// Incomplete = ARP request sent, no reply ever came back

<HUAWEI> display cpu-defend statistics packet-type arp-request all
PacketType    Total Passed   Total Dropped   Last Dropping Time
arp-request      226099         895000132   2022-05-20 11:29:22
// Dropped climbing fast across repeated samples -> attack signature

[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] auto-defend enable
[HUAWEI-cpu-defend-policy-policy1] auto-defend attack-packet sample 5
[HUAWEI-cpu-defend-policy-policy1] auto-defend threshold 30

<HUAWEI> display auto-defend attack-source slot 0
MacAddress       InterfaceName      Vlan:Outer/Inner      TOTAL
0000-0000-0001   10ge 0/0/1         193                   416
// the flagged MAC can include your own gateway or an uplink device -- verify before blacklisting

Ramo B — Confirmar se a aprendizagem teve alguma chance

Nenhum atacante em lugar nenhum — apenas um limite de taxa, um peer silencioso, ou uma topologia que ainda não terminou de convergir.

Execute display arp miss anti-attack rate-limit para ver a taxa de supressão de Miss configurada. Uma taxa configurada baixa demais — o exemplo de campo é arp miss anti-attack rate-limit maximum 16384, que em média permite apenas 0,1 mensagens Miss por segundo — restringe o tráfego ARP Miss legítimo no mesmo balde de descarte de um ataque, e parece idêntico a um até você ler esse valor.
No dispositivo peer, execute display arp fast-reply statistics a partir da visão diagnose várias vezes seguidas e observe se Received request e Sent reply realmente se movem. Se Received request nunca aumentar, a própria solicitação nunca chegou — um problema de link, VLAN ou encaminhamento a montante, não um problema de ARP de forma alguma. Se aumentar mas Sent reply não, o peer não está respondendo.
Execute display arp statistics e compare a contagem de entradas com o número real de usuários conectados. Uma contagem muito desproporcional em relação à base de usuários aponta para agitação provocada por Miss em vez de falha de aprendizagem — verifique se um único IP de origem está disparando ARP Miss repetidamente.
Se o Ping só tiver sucesso após um atraso, verifique se o STP ainda está habilitado com display stp — uma topologia que ainda não terminou de convergir bloqueia a troca de ARP junto com tudo o mais, e desabilitar o STP onde não é necessário (stp disable) é uma correção completamente diferente de qualquer coisa específica de ARP.

<HUAWEI> display cpu-defend statistics all
PacketType   Total Passed   Total Dropped   Last Dropping Time
arp-miss       135576021       1601690      2022-03-31 13:17:49
arp-request     39556247       2009617      2022-03-31 13:17:49

[HUAWEI] display this include-default | include arp miss anti-attack
arp miss anti-attack rate-limit maximum 16384
// ~0.1 Miss messages/sec allowed -- too low once real user count grows
[HUAWEI] undo arp miss anti-attack rate-limit

<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display arp fast-reply statistics
Slot   Received request   Sent reply
2      0                  0
// Received request stuck at 0 -> request never arrived, not an ARP fault

<HUAWEI> display stp
Protocol Status        :enabled
// STP not yet converged can look exactly like a learning failure
[HUAWEI] stp disable

6 causas raiz que aparecem repetidamente

Depois que os dois ramos acima indicarem em qual família você está, essas seis explicam a maior parte do que realmente está errado.

1. Endereço do gateway personificado via ARP gratuito

SINTOMATodo um segmento perde o acesso à internet de uma vez, e o endereço MAC associado ao IP do gateway de repente parece desconhecido.

CAUSAUm atacante no mesmo domínio de broadcast envia um ARP gratuito reivindicando o próprio IP do gateway. Os hosts que o aceitam sobrescrevem o MAC real do gateway pelo do atacante, e todo pacote destinado ao gateway vai para o atacante em vez disso.

SOLUÇÃOConfirme que o gateway realmente reside neste dispositivo com display arp / display ip routing-table para o IP do gateway, depois habilite arp anti-attack gateway-duplicate enable e arp gratuitous-arp send enable para que o dispositivo continue atualizando a entrada correta em seu próprio ritmo.

[Router] interface Vlanif10
[Router-Vlanif10] arp anti-attack gateway-duplicate enable
[Router-Vlanif10] arp gratuitous-arp send enable
<Router> display arp anti-attack gateway-duplicate item

2. A entrada ARP de um usuário legítimo é reescrita silenciosamente

SINTOMAA rede de um usuário específico cai sem qualquer problema de link ou roteamento, enquanto tudo o mais no mesmo segmento permanece normal.

CAUSAUm atacante forja pacotes ARP que parecem vir de outro host legítimo, sobrescrevendo a entrada real desse host no gateway com o endereço MAC do atacante.

SOLUÇÃOHabilite arp anti-attack entry-check na interface de acesso — send-ack revalida com uma troca real de ARP antes de aceitar uma alteração, fixed-mac trava o MAC uma vez aprendido. Limpe primeiro a entrada envenenada com reset arp interface antes de ativar o recurso.

<Router> display current-configuration | include arp anti-attack entry-check
<Router> reset arp interface GigabitEthernet0/0/1
[Router-GigabitEthernet0/0/1] arp anti-attack entry-check send-ack enable

3. Inundação de ARP / varredura IP empurra a carga de CPU além do limitador de taxa

SINTOMAO uso de CPU do dispositivo dispara, usuários normais não conseguem aprender ARP nem acessar a internet, e até mesmo gerenciar o próprio equipamento fica lento ou cai.

CAUSAUma inundação de pacotes ARP ou de destino inalcançável dispara a geração de ARP Miss e ARP-Request em uma escala para a qual o limitador CPCAR não foi dimensionado, então o tráfego ARP legítimo é descartado no mesmo balde que o tráfego de ataque.

SOLUÇÃOConfirme com display cpu-defend statistics packet-type arp-request all que Dropped está subindo rápido, depois rastreie a fonte com uma política auto-defend attack-source antes de colocar algo na lista negra — nunca antes de identificar, já que o próprio MAC do gateway pode aparecer na mesma tabela de fontes de ataque.

<HUAWEI> display arp
10.1.1.2   Incomplete   0   D   Vlanif20
// Incomplete entries under heavy CPU load -> check the drop counter next

[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] auto-defend enable
[HUAWEI-cpu-defend-policy-policy1] undo auto-defend protocol dhcp dhcpv6 dns icmp icmpv6 nd igmp mld tcp tcpv6 telnet
// keep only ARP under attack-source tracing for this case

4. Limite de taxa de ARP Miss configurado de forma agressiva demais

SINTOMAUm dispositivo de camada 2 fica entre os terminais e o gateway, e os hosts atrás dele não conseguem alcançar o gateway mesmo que nada no cabeamento pareça errado.

CAUSAarp miss anti-attack rate-limit foi configurado com um valor que fazia sentido em uma rede menor, mas restringe as mensagens Miss legítimas quando o número de usuários cresce — o exemplo de campo, maximum 16384, equivalia a aproximadamente uma mensagem Miss a cada dez segundos.

SOLUÇÃOCompare os contadores Dropped de arp-miss e arp-request de display cpu-defend statistics all com o número real de usuários, e aumente o limite ou remova-o se ele nunca foi dimensionado com base no tráfego real.

<HUAWEI> display cpu-defend statistics all
arp-miss     135576021   1601690   2022-03-31 13:17:49
[HUAWEI] display this | include arp miss anti-attack rate-limit
arp miss anti-attack rate-limit maximum 16384
[HUAWEI] undo arp miss anti-attack rate-limit

5. O peer nunca envia a resposta rápida

SINTOMAUm dispositivo mostra uma entrada correta para seu vizinho, mas o vizinho nunca aprende a entrada reversa — o tráfego funciona em uma direção e não na outra.

CAUSAO ARP fast-reply está habilitado por padrão, mas se o peer nunca receber a solicitação, ou recebê-la e simplesmente não responder, a entrada reversa nunca é gerada.

SOLUÇÃONo peer, observe display arp fast-reply statistics a partir da visão diagnose em várias amostras — Received request travado em zero significa que a solicitação nunca chegou; Received request se movendo mas Sent reply não se movendo significa que o próprio peer não está respondendo e precisa de investigação mais profunda.

<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display arp fast-reply statistics
Status: Enable
Slot   Received request   Sent reply
2      0                  0

6. A convergência do STP atrasa o ARP — não é uma falha de ARP de jeito nenhum

SINTOMAO Ping entre dois dispositivos falha no início e depois começa a funcionar pouco tempo depois, sem nenhuma mudança de configuração no meio.

CAUSAO Spanning Tree ainda não terminou de convergir neste segmento; as solicitações de ARP enviadas enquanto uma porta ainda está em estado blocking ou listening não passam até que a topologia se estabilize.

SOLUÇÃOVerifique display stp para Protocol Status: enabled, e se o STP não for realmente necessário neste segmento, desabilite-o com stp disable em vez de solucioná-lo como uma falha de ARP.

<HUAWEI> display stp
Protocol Status        :enabled
[HUAWEI] stp disable

Seis perguntas que surgem constantemente

Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.

Habilitar a antifalsificação de ARP em cada interface deixa algo mais lento?

Não de forma significativa em volumes de tráfego normais — a detecção de entry-check e gateway-duplicate apenas adiciona uma comparação com o estado existente em pacotes que já precisam ser processados. A escolha que realmente importa é o modo: fixed-all trava cada campo, então realocar um host para outra porta ou VLAN depois exige limpar a entrada manualmente, enquanto o modo send-ack revalida automaticamente.

display arp mostra entradas Incomplete — isso é sempre um ataque?

Não. Incomplete apenas significa que a solicitação ARP foi enviada e nenhuma resposta jamais voltou. Isso acontece em um ataque real, mas acontece com a mesma frequência por um host genuinamente inalcançável, uma resposta descartada por um limitador de taxa, ou um problema de link — verifique cpu-defend statistics e o status real do link antes de presumir um atacante.

O rastreamento de fonte de ataque sinalizou um endereço MAC — é seguro colocá-lo na lista negra imediatamente?

Primeiro verifique a que pertence esse MAC. A tabela de fontes de ataque registrada pode incluir o próprio MAC do gateway ou o de um dispositivo de rede de interconexão captado como tráfego legítimo ruidoso; colocá-los na lista negra derruba negócios reais em vez de deter um atacante.

Desabilitamos o STP e o problema intermitente de Ping desapareceu — o STP era realmente o "atacante"?

Não, e é exatamente essa a divisão sobre a qual trata esta nota. Nada estava forjando tráfego ARP; a topologia simplesmente não tinha terminado de convergir antes de o host tentar resolver seu gateway. Desabilitar o STP onde não é necessário é uma correção de camada de link, não antifalsificação, e nunca teria aparecido em nenhum dos contadores do lado do ataque.

gateway-duplicate e entry-check parecem fazer algo semelhante — precisamos dos dois?

Elas protegem alvos diferentes. gateway-duplicate protege especificamente o próprio endereço do gateway contra uma reivindicação forjada; entry-check protege as entradas de outros hosts legítimos de serem sobrescritas por um atacante não relacionado. Habilitar uma não cobre a outra.

Esses recursos antiataque de ARP podem funcionar junto com o controle de admissão 802.1X/NAC?

Sim, e elas resolvem problemas diferentes — o 802.1X controla quem tem permissão para entrar no segmento, enquanto a antifalsificação de ARP controla o que um dispositivo já admitido pode reivindicar sobre seu próprio endereço ou o de outro host uma vez conectado. Executar ambos é o design normal, não redundante, e é exatamente o que um modelo de acesso de confiança zero sobrepõe em conjunto.

Limites honestos desta nota

Limites honestos desta nota

Esta nota se baseia no modelo de classificação de falhas de ARP dos roteadores Huawei série AR e seu conjunto de recursos antiataque — gateway-duplicate, entry-check, limitação de taxa de ARP Miss, rastreamento de fonte de ataque — além dos casos de campo por trás deles. Outros fabricantes implementam proteções equivalentes sob nomes diferentes e com estados padrão distintos, então sempre verifique o que já está habilitado antes de presumir que um recurso "deveria" já estar capturando isso. Não cobre em profundidade implantações do tipo Dynamic ARP Inspection do lado do switch, nem o comportamento de proxy de ARP específico para wireless em APs/ACs.

Não tem certeza se é um atacante ou uma configuração?

Envie-nos a saída de display arp / display cpu-defend statistics e em qual ramo você está travado, e ajudamos você a interpretá-la.

WhatsApp com um engenheiro →