arp table filling up

Question

Eu tenho um sistema CentOS 5 que serve como um conector VPN IPSec entre minha rede e algumas redes remotas. Ultimamente, esse problema ocorre uma ou duas vezes ao dia, quando seu cache ARP é preenchido.

A rede local em que esse cara está é 10.51.0.0/16 e o IPSec conecta-o a 10.53.0.0/16 e 10.54.0.0/16 . Possui 2 interfaces, eth0 conectado à internet e eth1 que está conectado à rede local com ip 10.51.1.15 .

O cache do ARP é preenchido com endereços como 10.51.119.x e parece continuar preenchendo-o completamente. Eu corri o tcpdump enquanto estava acontecendo e vi solicitações ARP para todos esses endereços inexistentes originados do ip local10.51.1.15, então é quase como se alguém estivesse fazendo uma varredura de rede, mas como descobrir de onde é originado? É improvável que realmente venha da própria caixa, ninguém deveria estar executando varreduras como essa, mas ela pode estar vindo das redes IPSec? Como faço para descobrir de onde vem?

Problema resolvido: foi o antivírus Kaspersky que fez a descoberta do sistema em nossa rede.

    

Answer 1

Para o scanner ganhar alguma coisa (além de criar um ataque DOS) ele precisa receber os pacotes. Se a varredura parecer originar de uma sub-rede conectada localmente, ela não poderá estar em qualquer lugar em uma rota entre a origem e a origem, porque não há nada entre a caixa CentOS e a 10.51.1.15.

Você poderia:

1. Execute tcpdump com -e header. Isso informará o endereço MAC do originador da verificação.
2. Ping 10.51.1.15 em vários momentos e veja, se o arp artry corresponder aos cabeçalhos da camada de enlace contidos no tcpdump.
3. Se você tiver um switch gerenciado, poderá fazer logon e ver de onde vêm os quadros. Isso informará o soquete, no qual o scanner está conectado. Esse método funcionará também se o scanner realmente quiser apenas inundar seu cache ARP.

É improvável que a varredura tenha origem fora da rede 10.51.0.0/16. As regras típicas do firewall descartam pacotes que afirmam ter origem em uma rede conectada localmente que passa pela interface errada. Então, talvez você tenha regras de firewall atípicas;).

Não tenho certeza se a sua pergunta foi correta, mas se 10.51.1.15 é o IP da caixa CentOS, então, em vez de tcpdump -e , as ideias acima não fazem sentido. Se os pacotes parecem originar da caixa local, então tem pacotes para entregar a esses endereços. Nesse caso, você pode configurar as regras do iptables que registram os pacotes para endereços inválidos da rede 10.51.0.0/16. Por endereços inválidos, quero dizer endereços que não foram atribuídos a nenhum host. Se algo está tentando acessá-los, provavelmente não há razão legítima para isso. Essa regra de registro (com a regra de limite correspondente para evitar o preenchimento de log) informará a origem desse pacote - se ele for de uma caixa local ou de qualquer uma das redes remotas.

Se os pacotes parecem ter origem na própria caixa CentOS, você também pode dar uma olhada em ps output durante uma verificação suspeita e compará-la a ps da saída salva quando não há varredura. Talvez você encontre algumas respostas óbvias.

    

Answer 2

Eu achei essa postagem incrivelmente útil na depuração de uma situação semelhante. A recomendação feita lá é para fazer o seguinte:

tcpdump -l -n arp | egrep 'arp who-has' | head -100 | awk '{ print $NF }' |sort | uniq -c | sort -n

Isso lhe dará o ip que fez o maior número de pedidos "quem tem" dos últimos 100. Isso deve fornecer o que você precisa saber para encontrar o sistema ofensivo.

    

Answer 3

Não tenho certeza se isso se aplica, mas tive o mesmo problema exato em um roteador Cisco e o problema era que na rota padrão eu tinha o nome da interface especificado em vez do endereço IP. A tabela ARP iria encher até que aleijasse o roteador. Assim que eu especifiquei um IP, ele foi esclarecido. Talvez completamente não relacionado, mas você nunca sabe.

ip route 0.0.0.0 0.0.0.0 FastEthernet0/1 <-wrong e ip route 0.0.0.0 0.0.0.0 192.1668.99.254 <-right