Verificar a cache de vizinhos ARP e NDP na Sophos Firewall

Se um dispositivo não estiver acessível apesar de ter o endereço IP correto, a causa não tem de ser imediatamente uma regra de firewall ou uma rota incorreta. Na rede local, a Sophos Firewall também precisa do endereço MAC correto do destino. Esta associação é guardada na cache de vizinhos.

Em Network > Neighbors (ARP–NDP) é possível verificar que endereço IP está atualmente associado a cada endereço MAC e interface. Primeiro, documenta-se a entrada existente e compara-se com a situação real da rede. Só quando a associação está desatualizada se limpa a cache afetada e se permite que seja aprendida novamente.

Os nomes e comandos deste procedimento correspondem ao SFOS 22.0. O diagnóstico começa no WebAdmin; a Device Console só é utilizada para as verificações adicionais expressamente descritas abaixo.

⚠️ Flush limpa a cache IPv4 ou IPv6 selecionada, não apenas uma linha. Numa firewall em produção, deve primeiro guardar-se a entrada atual, limitar o teste e evitar limpar a cache durante um pico de carga.

O que fazem ARP, NDP e a cache de vizinhos

O ARP associa um endereço IPv4 a um endereço MAC no segmento Layer 2 local. Trata-se de um dispositivo diretamente acessível, normalmente na mesma VLAN. No IPv6, o Neighbor Discovery Protocol (NDP) assume esta função através de ICMPv6. A firewall precisa desta informação antes de poder enviar um pacote por uma interface diretamente ligada para o vizinho seguinte.

Com IPv4, um dispositivo utiliza um pedido ARP para solicitar o endereço MAC correspondente a um endereço IP. A resposta fornece a associação com que a firewall atualiza a sua cache de vizinhos. As associações IP-MAC já aprendidas são reutilizadas para reduzir o tráfego de difusão; no caso do IPv6, o NDP efetua a resolução de vizinhos correspondente.

As entradas dinâmicas de vizinhos são aprendidas e atualizadas continuamente. O tempo limite predefinido documentado para os pedidos ARP e NDP é de 600 segundos (10 minutos). Isto não garante que cada entrada desapareça exatamente após 600 segundos: as caches persistem até serem esvaziadas automática ou manualmente. Depois disso, a firewall pode voltar a aprender as associações atuais. Uma entrada desatualizada pode surgir, por exemplo, após uma mudança de dispositivo, placa de rede ou VM. Um endereço IP atribuído em duplicado pode, por outro lado, fazer com que o endereço MAC visível mude repetidamente.

Em Neighbor cache entry timeout, pode alterar-se o intervalo de limpeza automática e aplicá-lo com Apply. Um valor mais curto força uma reaprendizagem mais frequente e não corrige endereços IP duplicados, VLAN incorretas nem associações estáticas desatualizadas. Antes da alteração, deve registar-se o valor inicial. Se o teste não trouxer benefícios, introduz-se novamente esse valor exato, clica-se em Apply e volta-se a testar o caminho de dados real.

Para automação XML: A referência XML para SFOS 22.0 e 23.0 descreve, em ARPConfiguration, o parâmetro ARPCacheEntryTimeOut como intervalo de limpeza da cache: valor predefinido documentado de 2 minutos, intervalo de 1–500; o exemplo indica Minutes. Estes são valores de referência, não uma prova de um valor atual em execução nem de que se trata do mesmo controlo referido na ajuda da interface para o tempo limite de 600 segundos dos pedidos ARP/NDP. Esta entidade ARP de IPv4 também não comprova a existência de uma configuração geral de todas as propriedades NDP de IPv6. Nenhum destes valores da documentação deve ser adotado como valor automático de reposição ou de ajuste: o valor de referência continua a ser o valor atual registado antes de qualquer alteração, que deve ser reposto exatamente ao reverter a alteração; depois, deve voltar a verificar-se o serviço original.

A cache de vizinhos abrange apenas vizinhos diretamente acessíveis no respetivo segmento Layer 2. Para um destino remoto, a firewall não guarda o endereço MAC do servidor de destino, mas sim o do router seguinte.

Não é o mesmo que Proxy ARP: nesse caso, a firewall responde numa interface, em nome de outro endereço de destino, ao respetivo pedido ARP IPv4. Este caso especial é tratado separadamente em Configurar e testar Proxy ARP na Sophos Firewall.

Identificar ARP flux em várias interfaces

O ARP flux pode ocorrer quando várias interfaces Ethernet físicas da Sophos Firewall estão ligadas ao mesmo meio de Layer 2 ou à mesma broadcast domain. A firewall pode então responder a um pedido ARP através das duas interfaces, fazendo com que o dispositivo que envia o pedido veja associações MAC variáveis ou inesperadas. Duas VLAN separadas, um LAG configurado incorretamente ou um endereço IP duplicado comum não constituem automaticamente ARP flux.

Uma captura de pacotes curta serve apenas para verificar o comportamento ARP: deve confirmar-se se o mesmo pedido chega às duas portas físicas e se ambas as interfaces da firewall respondem. A captura não mostra o valor configurado de arp-flux.

A Device Console está acessível pela consola local ou por SSH. Os pré-requisitos e o acesso SSH são explicados em Ligar à Sophos Firewall por SSH. Depois de iniciar sessão, seleciona-se Option 4: Device Console. Antes de qualquer alteração, executa-se a verificação prévia de referência do SFOS 22.0:

show arp-flux

Regista-se exatamente o valor devolvido, on ou off. A definição é global e não específica de uma interface. Só deve ser alterada temporariamente quando as duas interfaces partilham intencionalmente a mesma broadcast domain, a captura confirma o comportamento problemático e o valor atual requer uma alteração. Se tiver sido registado on, testa-se o modo de resposta específico da interface numa janela de manutenção com:

set arp-flux off

Com off, a firewall responde aos pedidos ARP através da interface Ethernet correspondente. Em seguida, verificam-se, nos dois caminhos, a acessibilidade, as entradas de vizinhos, o serviço original e o comportamento ARP com uma nova captura.

Depois do teste, independentemente do resultado, restaura-se exatamente o valor registado com show arp-flux. Se o valor inicial era on, executa-se:

set arp-flux on

Se o valor inicial era off, executa-se em alternativa:

set arp-flux off

Executa-se novamente show arp-flux para confirmar o valor restaurado e repetem-se os testes de caminho. A captura de pacotes serve apenas para verificar o comportamento resultante.

Se não houver prova de uma broadcast domain partilhada ou o problema permanecer inalterado com off, não se devem alterar outras definições ARP com base em suposições. A análise deve regressar às VLAN, bridges, LAG, tabela MAC do switch, cablagem e endereços IP duplicados.

Verificar primeiro a cache de vizinhos

1. Abrir Network > Neighbors (ARP–NDP).
2. Em Show, selecionar IPv4 neighbor cache ou IPv6 neighbor cache.
3. Procurar o endereço IP afetado.
4. Anotar o endereço IP, o endereço MAC e a interface.
5. Em Static neighbor table, excluir a existência de uma associação fixa, mas incorreta, para o mesmo endereço IP.
6. Comparar o endereço MAC com o dispositivo final, o hypervisor, o switch ou o router seguinte.

A interface é tão importante como o endereço MAC. Uma associação IP-MAC correta na porta errada aponta frequentemente para um problema de VLAN, bridge, LAG ou cablagem. O endereço MAC esperado pode ser consultado, por exemplo, nas informações de rede do dispositivo final, na tabela MAC do switch ou no router diretamente ligado. Se a entrada estiver completamente ausente, envia-se a partir da firewall um ping direcionado para o endereço IP afetado e volta-se depois a verificar a vista.

Para IPv4 e IPv6, as duas vistas de cache no WebAdmin são o ponto de verificação documentado. Mostram a interface além do endereço e evitam aplicar por engano uma observação IPv4 a um problema IPv6.

Limites da API XML: Get Dynamic Neighbour Entries permite ler e verificar entradas; Flush All Dynamic Entries elimina entradas dinâmicas da cache, não uma única entrada estática. A referência para SFOS 22.0 e 23.0 indica o parâmetro escalar opcional IPFamily com IPv4 e IPv6, mas sem valor predefinido. Não se pode deduzir se a sua omissão seleciona uma das duas famílias, ambas ou qualquer outro âmbito. Nenhuma das duas versões inclui um payload de pedido; a tabela de parâmetros não fornece, por isso, um pedido de operação executável. Para verificar e limpar a cache, utiliza-se o procedimento existente da GUI com seleção explícita da família IP. O aviso mantém-se: Flush limpa toda a cache selecionada.

Reaprender de forma controlada uma associação desatualizada

Limpar a cache é um passo de diagnóstico, não uma reparação permanente. Também não remove uma associação estática incorreta. Não existe um rollback direto para entradas dinâmicas eliminadas; a firewall volta a aprendê-las com novo tráfego. Se a mesma associação errada regressar, a causa continua presente na rede.

1. Documentar o endereço IP, o endereço MAC e a interface atuais.
2. Reproduzir o erro com um único ping ou uma tentativa de ligação.
3. Se houver suspeita de um endereço IP duplicado ou de manipulação, guardar primeiro o estado atual e um capture curto. Um flush imediato eliminaria este indício.
4. Em Show, selecionar a cache IPv4 ou IPv6 afetada.
5. Clicar em Flush. Esta ação limpa a cache selecionada.
6. Voltar a gerar tráfego direcionado a partir do dispositivo afetado.
7. Verificar que endereço MAC e interface foram aprendidos novamente.
8. Voltar a testar o serviço original com a mesma origem e o mesmo destino.

Para um teste controlado a partir da Device Console, podem ser enviados, por exemplo, quatro pacotes para um endereço de destino documentado:

ping 192.0.2.10 count 4
ping6 2001:db8:10::10 count 4

Os endereços são exemplos e devem ser substituídos pelo destino IPv4 ou IPv6 real. Um ping bem-sucedido confirma apenas a acessibilidade básica; depois disso, continua a ser necessário testar o serviço originalmente afetado.

Durante a reaprendizagem podem ocorrer breves atrasos. Reduzir muito o timeout de forma generalizada raramente é a melhor solução: a firewall terá de resolver os vizinhos com maior frequência, sem que isso corrija um endereço IP duplicado ou uma porta de switch incorreta.

Se, depois do flush, apenas um endereço IP público continuar sem mudar para o novo endereço MAC da firewall, a entrada desatualizada encontra-se provavelmente no fornecedor ou num router a montante. Existe um procedimento separado para Resolver problemas de ARP após uma migração da firewall.

Criar um vizinho estático apenas para associações fixas

Um vizinho estático associa permanentemente um endereço IP a um endereço MAC e a uma interface física. Só pode existir uma associação deste tipo por endereço IP. Quando recebe um pedido na porta em questão, a firewall verifica primeiro a tabela de vizinhos estáticos e, ao guardar, remove as referências dinâmicas para o mesmo endereço IP. Se não existir uma entrada estática, verifica as caches de vizinhos e acrescenta o endereço MAC, se necessário. Para um par IP-MAC associado estaticamente, a firewall não responde em nenhuma outra porta. Se mais tarde o endereço IP, o endereço MAC ou a porta deixarem de corresponder, a ligação pode falhar apesar de o dispositivo final estar configurado corretamente.

As entradas estáticas são, por isso, adequadas para sistemas estáveis, como um dispositivo de infraestrutura com ligação por cabo e endereço IP fixo. Normalmente, não são adequadas para clientes DHCP, dispositivos móveis, alterações de HA ou VM e portas de switch variáveis.

Em Network > Neighbors (ARP–NDP), apresentar a Static neighbor table e selecionar Add. Em seguida, definir os seguintes valores:

• IP version: selecionar IPv4 ou IPv6.
• IPv4/IPv6 address: introduzir o endereço fixo do dispositivo.
• MAC address: introduzir o endereço MAC real deste dispositivo.
• Interface: selecionar a interface física através da qual o vizinho está acessível.

Um exemplo documentado pode utilizar 192.0.2.10, 02:00:00:00:00:10 e Port1. Estes valores são placeholders e têm de ser totalmente substituídos pelo endereço IP, endereço MAC e porta reais.

Antes de guardar, regista-se se a opção Add as a trusted MAC address to prevent a spoofing attempt está selecionada. A opção adiciona a associação IP-MAC à lista de MAC fidedignos. Só deve ser ativada quando esta estratégia de proteção for utilizada de forma consciente, porque uma alteração posterior de VM, NIC ou porta pode surgir como um conflito legítimo. A interação das entradas MAC fidedignas com redes dinâmicas, DHCP e virtualização é explicada em Verificar Spoof Protection e DoS Settings na Sophos Firewall.

Com Save cria-se a associação e, em seguida, testa-se exatamente o dispositivo afetado. Ao reverter o teste, remove-se a nova entrada da Static neighbor table, gera-se tráfego direcionado e verifica-se a associação aprendida dinamicamente. Depois, abre-se Intrusion prevention > DoS & spoof protection > Spoof protection trusted MAC. Se permanecer uma entrada MAC fidedigna correspondente criada para este teste, remove-se separadamente; não se deve presumir que a eliminação do vizinho estático também a elimina. Deve ainda ficar documentado quem irá ajustar uma entrada mantida em caso de alteração de hardware, endereço IP ou porta. Uma associação estática sem esta responsabilidade transforma-se facilmente numa causa de erro invisível mais tarde.

Limites da API Add/Edit

A referência Add/Edit para vizinhos estáticos em SFOS 22.0 e 23.0 descreve um contrato de API próprio, distinto da entidade de timeout ARPConfiguration explicada acima. Exige neighname para a identidade do vizinho guardado ou selecionado, respetivamente; neighid, por outro lado, é opcional. Ambos devem ser distinguidos de IPAddress, MACAddress e Interface. Os valores de IP, MAC e porta física na GUI não fornecem essa identidade nem um pedido JSON ou XML executável. A referência descreve a operação como JSON, mas não apresenta um exemplo que esclareça com segurança o formato ou a correspondência da identidade; por isso, não se deve deduzir um identificador a partir dos valores da GUI.

As indicações relativas aos endereços também são contraditórias: o parâmetro obrigatório IPFamily permite IPv4 e IPv6, enquanto IPAddress é limitado ao tipo IPADDRESS, com um máximo de 15 caracteres e classes de endereços orientadas para IPv4. Isto não permite deduzir uma codificação IPv6 fiável, nem refuta o suporte de IPv6 no procedimento da GUI descrito acima. Para o parâmetro opcional AddAsATrustedMACAddress, a referência indica apenas Enable. Isto não comprova a existência de um valor Disable nem o efeito da omissão do parâmetro. A seleção de MAC fidedignos continua a ser uma decisão consciente, e qualquer entrada MAC fidedigna que permaneça é removida separadamente, conforme descrito acima. Enquanto a identidade, o formato do pedido e o esquema de endereços IPv6 não estiverem claros para a versão específica do SFOS, deve utilizar-se a GUI existente para criar ou editar entradas, em vez de um pedido de API baseado em suposições.

Delete Static ARP Entry é uma operação distinta: a referência para SFOS 22.0 e 23.0 exige IPAddress para identificar a entrada, não o contrato Add/Edit com neighname e neighid. A restrição ao tipo IPADDRESS, a um máximo de 15 caracteres e a classes de endereços orientadas para IPv4 não estabelece uma representação fiável para a eliminação IPv6. Nenhuma das duas versões inclui um exemplo de pedido de eliminação nem uma tabela de estados; não se deduzem um formato de pedido, um payload de eliminação ou um contrato de resultados. Em vez de adivinhar um pedido de eliminação da API, utiliza-se a GUI existente para selecionar e remover apenas a entrada estática guardada que se pretende eliminar. Continua a verificar-se e a remover-se separadamente qualquer entrada MAC fidedigna residual correspondente, conforme descrito acima; não se garante uma eliminação em cascata.

Verificar possíveis tentativas de neighbor poisoning

Uma associação estática define a combinação esperada de endereço IP, endereço MAC e interface. Se o mesmo endereço IP aparecer com outro endereço MAC, ou se a mesma combinação IP-MAC surgir noutra porta associada, a firewall trata a situação como possível manipulação e não atualiza a cache com a associação divergente.

Uma associação por endereço IP não significa que um endereço MAC só possa corresponder a um endereço IP. No exemplo de ARP para IPv4, tanto IP1 como IP2 estão associados a MAC1 e à porta A. Se cada endereço IP aparecer com MAC1 na porta A, não se trata de uma tentativa de neighbor poisoning. O importante é que cada combinação IP-MAC-porta corresponda à sua própria associação estática.

No mesmo exemplo, IP3 com MAC1 e sem uma entrada ARP estática para IP3 também não é classificado como uma tentativa de neighbor poisoning. Assim, a partilha do endereço MAC, por si só, não cria um conflito com as associações de IP1 ou IP2. Estes exemplos explicam a verificação de associações ARP estáticas; não constituem uma aprovação geral da segurança do tráfego.

Em Network > Neighbors (ARP–NDP), pode ativar-se Log possible neighbor poisoning attempts e guardar com Apply. Antes de um teste de duração limitada, regista-se se a caixa de seleção está marcada e restaura-se esse estado visível no final. A opção ajuda no diagnóstico, mas não significa que todas as divergências devam ser imediatamente consideradas um ataque. Um endereço IP duplicado, um adaptador de rede substituído, uma VM movida ou uma mudança de porta também podem provocar um conflito.

Os pacotes ARP IPv4 rejeitados podem ser apresentados na Device Console durante um teste curto:

drop-packet-capture 'arp'

Se existirem muitas interfaces, a saída pode ser limitada a uma porta física:

drop-packet-capture interface Port1 'arp'

Port1 é um exemplo e deve ser substituído pela interface afetada. Em seguida, reproduz-se o erro uma vez e termina-se a saída contínua com Ctrl+C. O filtro mostra apenas pacotes ARP rejeitados e não constitui um arquivo de logs permanente. Para NDP IPv6 ou uma análise geral de pacotes, utiliza-se Packet Capture no WebAdmin, limitando de forma direcionada a origem, o destino, o protocolo e a interface.

Interpretar sintomas típicos

• Após a substituição de um dispositivo ou NIC, o destino continua inacessível: comparar o valor MAC antigo com o que foi aprendido novamente, limpar a cache de forma controlada e voltar a testar.
• O endereço MAC muda repetidamente: verificar se existe um endereço IP duplicado, uma lease DHCP, um clone de VM ou um comportamento de HA. Uma entrada estática apenas ocultaria o conflito real.
• A associação aparece na interface errada: verificar VLAN, bridge, LAG, porta do switch e cablagem.
• Um dispositivo com associação estática deixa de funcionar após uma alteração: comparar o endereço IP, o endereço MAC e a porta física com a associação e ajustar ou remover conscientemente a entrada.
• Apenas o IPv6 é afetado: verificar IPv6 neighbor cache, Router Advertisements, VLAN e o caminho ICMPv6. Um comando ARP IPv4 não fornece qualquer prova neste caso.
• Os pacotes chegam à firewall, mas o serviço continua sem funcionar: verificar separadamente a regra de firewall, NAT, routing e o caminho de retorno. A cache de vizinhos comprova apenas a entrega Layer 2 local.

Verificação final

• Endereço IP afetado, endereço MAC esperado e interface documentados.
• Cache IPv4 ou IPv6 verificada antes de uma alteração.
• Se necessário, foi limpa exatamente a cache selecionada e gerado tráfego direcionado.
• Associação aprendida novamente comparada com o dispositivo final, switch, hypervisor ou router.
• Associação estática utilizada apenas com uma combinação IP-MAC-porta permanentemente estável.
• Aviso de poisoning distinguido de um endereço IP duplicado, uma substituição de dispositivo e alterações de rede.
• Serviço original novamente testado após a verificação de Layer 2.

FAQ