Servidor Linux respondendo ao ARP para IP desconhecido

Question

Eu tenho um servidor Linux em casa (OL 6.6, fwiw) executando alguns serviços internos. Eu notei esta manhã que ele está respondendo a solicitações ARP para um endereço que não vejo registro.

O IP não está configurado em nenhum arquivo /etc/sysconfig/network-scripts e não aparece em ip addr show .

Da minha estação de trabalho:

macbook:~ elliott$ arping -c1 192.168.50.108
ARPING 192.168.50.108
60 bytes from 00:24:81:05:c0:cb (192.168.50.108): index=0 time=1.854 msec

--- 192.168.50.108 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered (0 extra)
rtt min/avg/max/std-dev = 1.854/1.854/1.854/0.000 ms
macbook:~ elliott$ 

No servidor:

[elliott@server ~]$ ifconfig | grep -i 00:24:81:05:C0:CB
br0       Link encap:Ethernet  HWaddr 00:24:81:05:C0:CB  
br0:1     Link encap:Ethernet  HWaddr 00:24:81:05:C0:CB  
eth0      Link encap:Ethernet  HWaddr 00:24:81:05:C0:CB  
[elliott@server ~]$ 
[elliott@server ~]$ ip addr | grep 192.168.50.108
[elliott@server ~]$ 

Esse IP está no intervalo de DHCP do meu roteador, fwiw, e não responde a pings nem a solicitações TCP nos intervalos de porta normais ( nmap -T4 -Pn 192.168.50.108 ).

Eu tentei:

1. Encerrando o servidor para confirmar que as respostas ARP são interrompidas
2. Encerrar serviços, um por um e matando todos os processos desnecessários - que o IP não parar de responder até que eu desligar o computador (é também um dos primeiros IPs para vir até quando ligado)
3. Alterar o gateway padrão para apontar para uma caixa pi framboesa e capturar qualquer tráfego de rede com esse IP - não vi nenhum

Então, minhas perguntas são: a) como eu deveria estar preocupado? e b) o que posso / devo fazer para tentar rastrear isso?

Obrigado por qualquer ajuda!

    

Answer 1

A técnica que você descreve é chamada arp-proxying . Consiste em ter uma interface (NIC1) respondendo a arp queries no lugar de outra interface (NIC2), que não está na mesma rede física. O computador no qual o NIC1 reside cuidará do roteamento correto de pacotes destinados ao NIC2.

É, de certa forma, o contrário do spoofing ARP: no spoofing ARP, um PC com um endereço MAC diferente finge ter o endereço IP de outra pessoa, por exemplo, o gateway, para interceptar e analisar todo o tráfego da rede. Aqui, em vez disso, um PC com um determinado endereço IP finge que tem o endereço MAC de outra pessoa.

Arp-proxying é usado principalmente para conectar VMs quando a ponte é impossível, ou para conectar PCs físicos em um fio diferente e / ou AP; na verdade, com ip_forwarding = 1 em sysctl.conf você está permitindo o encaminhamento apenas de pacotes da Camada 3 OSI, enquanto o tráfego ARP absolutamente essencial pertence à Camada 2 OSI. Você mesmo configurou algo desse tipo, uma VM ou uma DMZ? Se não, então você pode começar a se preocupar.

O que você pode fazer para explorar mais a questão é:

1. verifique quais interfaces têm o proxy-arp habilitado; se você encontrar apenas um além de br0 , você terá estabelecido em qual NIC 192.168.50.108 se conecta;

2. estude a tabela de roteamento, para ver se uma rota alternativa para 192.168.50.108 foi estabelecida em qualquer lugar;

3. estude as interfaces do sistema, aliases ou virtuais, para ver se uma nova interface foi adicionada;

4. estude os processos em execução, para ver se um hipervisor está em execução (Xen, KVM, VMWare, VirtualBox, ....); Se o endereço pertencer a uma VM, você não precisa ver outras NICs virtuais em seu sistema, algumas delas (VirtualBox) geralmente as ocultam sem nenhuma razão maliciosa;

5. verifique se alguma conexão VPN / túnel-reverso está aberta do seu servidor para algum endereço remoto local ou (mais provável);

6. tente estabelecer se você tem um rootkit no seu servidor. rkhunter e chkrootkit são pacotes amplamente disponíveis, fazendo um trabalho decente. Não espere que eles encontrem rootkits de nível NSA, mas você não é um terrorista, certo?

Parece provável que, se você estiver lidando com uma intrusão, a pessoa tenha sido sábia o suficiente para configurar um firewall para descartar todos os pacotes (incluindo ICMP) que não pertençam a uma conexão ESTABLISHED, RELACIONADA, portanto, há pouco ou nenhuma chance de que você possa detectá-lo ... Mas, você pode detectar alguns de seus desmembramentos, se houver: procure por regras incomuns de iptables ou ebtables (na verdade, provavelmente você não deve ter ebtables configurados de forma alguma, então você terá ebtables trabalhando em seu servidor, sozinho, seria um grande desmoronamento). O tipo de regra que você deve procurar é a reescrita da fonte e / ou destino dos pacotes, mas em geral qualquer coisa que você não tenha colocado pode ser uma fonte razoável de preocupação.

Provavelmente, uma boa jogada seria habilitar o login sem senha via ssh, desabilitar o login com senha em seu servidor e qualquer outra fonte de acesso ao servidor (além do ssh, é claro), depois reinicializar o servidor sem nenhum cabo conectado. para ter certeza de que você expulsou o intruso. O login sem senha não pode ser facilmente contornado, nem mesmo conhecendo a contraparte pública de sua chave criptográfica.