O que acontece se duas máquinas responderem a uma requisição ARP “who is”?

2

Estou apenas recentemente aprendendo sobre as nuances da rede, mas se um usuário mal-intencionado responder a um ARP "quem é" quando não deveria, o que acontece?

    
por cabbagebot 07.03.2012 / 01:48

2 respostas

4

Depende do ouvinte, mas normalmente a resposta mais recente ganha (geralmente no nível do comutador, não apenas no nível do computador). Portanto, os pacotes para esse endereço IP são roteados em algo que parece muito aleatório para um ou outro dos servidores de destino.

Isso geralmente acaba mal, mas apenas porque o estado, como conexões TCP, não é transportável. Se ambas as máquinas implementaram o mesmo serviço UDP, talvez você nem perceba.

    
por 07.03.2012 / 01:50
3

Uma das minhas experiências com problemas de arp em geral foi com alguns clientes de nossos serviços de servidor que definiram endereços IP estáticos em servidores em intervalos de DHCP. O resultado final para o usuário era que os serviços alternavam intermitentemente entre os alvos conflitantes para cada nova solicitação (aproximadamente 50% de conexões estabelecidas para cada servidor, com o erro "errado" de 404).

Eu diria que isso ocorre porque a conexão TCP em andamento não dependia de arp durante as conexões ESTABLISHED, apenas ao iniciar. (mas eu não sou nenhum corpo da rede então não me cite; -)

No entanto, minha experiência com a tecnologia ARP spoofing de ataque é diferente, porque o invasor realmente quer parecer o host correto, mesmo no estado conflitante.

Assim, para conseguir que o host mal-intencionado envie uma série contínua de pacotes, o objetivo é garantir que, em determinado momento, o dispositivo de destino receba a resposta mais recentemente do invasor em vez do host genuíno.

Quando isso acontece, a maioria dos pacotes arp são do atacante, portanto, a maioria das conexões TCP dos clientes se conecta ao host mal-intencionado. (algo como 95% para o atacante e 5% para o host original)

Isto é obviamente fácil de detectar pelo IDS, porque todo o tráfego arp não é consistente com os parâmetros e níveis normais.

Na situação com os problemas de IP duplo errados, o gateway vê pacotes como este;

host1 (arp) - > ip set para host1
host2 (arp) - > ip set para host2
host1 (arp) - > ip set para host1
host2 (arp) - > ip set para host2
host1 (arp) - > ip set para host1

no entanto, com os ataques maliciosos, é mais assim:

host1 (arp) - > ip set para host1
atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - host1 (arp) - > ip set to host1 ** < - ** não aqui embora
atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - atacante (arp) - > ip set to attacker < - atacante é man-in-the-middle aqui - ...

    
por 07.03.2012 / 02:26

Tags