Como uso o Linux para encontrar endereços IP não utilizados na minha rede?

Eu tenho acesso a dois computadores (A e B) em uma rede. Ambos têm um endereço IP estático com uma máscara de sub-rede 255.255.255.128 ( verifiquei se um servidor DHCP não estava sendo usado). Quero configurar vários endereços IP na mesma máquina e, portanto, quero saber o que todos os endereços IP já estão sendo usados ​​na sub-rede.

Em uma pergunta anterior , tentei o nmap -sP -PR 172.16.128.*comando, mas sou cético quanto ao resultado, pois o mesmo comando fornece resultados diferentes nos meus dois computadores (A e B). Em A, os shows de resultado, uma lista de endereços IP 8 que são (supostamente) já está sendo usado, incluindo o de A e B .

Nmap done: 256 IP addresses (8 hosts up) scanned in 1.23 seconds

Mas em B, o resultado é diferente, ou seja,

Nmap done: 256 IP addresses (0 hosts up) scanned in 0.00 seconds

O resultado em B nem mostra o seu próprio endereço IP, bem como o endereço IP de A!

O que exatamente estou fazendo de errado aqui? Existe alguma maneira infalível no Red Hat Linux (RHEL) de descobrir todos os endereços IP em uso na sub-rede da qual meu computador faz parte?

RHEL: 6.5
Nmap version: 5.51

Qualquer dispositivo bem comportado em uma LAN Ethernet é livre para ignorar quase todo o tráfego, portanto, PINGs, varreduras de portas e similares não são confiáveis. Os dispositivos não são, no entanto, livres para ignorar solicitações de ARP . Como você especifica que está digitalizando uma rede local, acho que o método menos frágil de fazer o que você deseja é tentar conectar-se a um endereço remoto e procurar no meu cache ARP.

Aqui está um dispositivo simples, sem filtro (ou seja, um que não está configurado para ignorar algumas classes de tráfego IP):

[me@risby tmp]$ ping -c 1 -W 1 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=0.351 ms
[...]
[me@risby tmp]$ arp -a -n|grep -w 192.168.3.1
? (192.168.3.1) at b8:27:eb:05:f5:71 [ether] on p1p1

Aqui está um dispositivo de filtragem (um configurado com uma única linha iptablespara ignorar todo o tráfego):

[me@risby tmp]$ ping -c 1 -W 1 192.168.3.31
[...]
1 packets transmitted, 0 received, 100% packet loss, time 0ms
[me@risby tmp]$ arp -a -n|grep -w 192.168.3.31
? (192.168.3.31) at b8:27:eb:02:e4:46 [ether] on p1p1

Aqui está um dispositivo que está acabando; observe a falta de um endereço MAC:

[me@risby tmp]$ ping -c 1 -W 1 192.168.3.241
[...]
1 packets transmitted, 0 received, 100% packet loss, time 0ms
[me@risby tmp]$ arp -a -n|grep -w 192.168.3.241
? (192.168.3.241) at <incomplete> on p1p1

Esse método não é infalível - ele perde os dispositivos que estão desligados, por um lado -, mas é o método menos terrível que eu já tentei.

Edit : Eric Duminil, sim, ele só funciona em uma rede local; veja o parágrafo um.

Vishal, os métodos são funcionalmente idênticos. Observe o texto citado na resposta de Leo sobre nmap:

Quando um usuário privilegiado tenta verificar os alvos em uma rede Ethernet local, as solicitações de ARP são usadas, a menos que tenha --send-ipsido especificado.

Seu método envolve menos digitação. O meu pode ser feito sem privilégios e pode lhe dar uma melhor compreensão do que realmente está acontecendo. Mas a mesma coisa é feita no fio nos dois casos.

Como um dispositivo não pode ignorar solicitações de ARP, eu gosto de usar uma ferramenta chamada arp-scan. Está disponível na maioria dos repositórios.

Quando você executa o comando com o --localnetswitch, ele fornece uma visão geral de toda a sua rede interna.

sudo arp-scan --localnet

Dá-me uma lista de todos os endereços IP e MAC da minha rede. Também é possível especificar um intervalo de rede para digitalizar.

sudo arp-scan 172.16.128.0/25

Se você tiver várias interfaces de rede configuradas, poderá especificar a que deseja usar com o switch -I.

sudo arp-scan -I eth0 172.16.128.0/25

Mais informações sobre possíveis opções podem ser encontradas em https://linux.die.net/man/1/arp-scan ou executando man arp-scan.

Não sei qual versão do nmap você está executando no seu Red Hat 6.5, mas para lançamentos recentes, da maneira correta (e mais rápida), acho que seria:

nmap -sn -n 172.16.128.0/25

Isso listará todos os hosts da sua rede (portanto, você pode usar qualquer outro IP dessa sub-rede, pois deve estar disponível).

Edite e observe: A sub-rede mencionada é 255.255.255.128, mas você mostra a saída como varredura de 254 hosts. A menos que esteja faltando alguma coisa, essa deve ser uma máscara / 25 e 126 hosts disponíveis. Se você deseja escanear um / 24, altere o comando acima para consultar todos os 254 hosts.

No livro nmap, -sPé descontinuado e substituído por -sn:

-sn (sem varredura de porta)

Essa opção informa ao Nmap para não fazer uma varredura de porta após a descoberta do host e imprimir apenas os hosts disponíveis que responderam aos testes de descoberta do host. Isso geralmente é conhecido como "verificação de ping", mas você também pode solicitar que os scripts de traceroute e host NSE sejam executados. Por padrão, esse é um passo mais intrusivo que a varredura de lista e geralmente pode ser usado para os mesmos fins. Permite o reconhecimento leve de uma rede alvo sem atrair muita atenção. Saber quantos hosts estão ativos é mais valioso para os invasores do que a lista fornecida pela verificação de lista de cada IP e nome de host.

Os administradores de sistemas geralmente acham essa opção valiosa também. Ele pode ser facilmente usado para contar as máquinas disponíveis em uma rede ou monitorar a disponibilidade do servidor. Isso geralmente é chamado de varredura de ping e é mais confiável do que executar ping no endereço de transmissão porque muitos hosts não respondem às consultas de transmissão.

A descoberta de host padrão feita com -sn consiste em uma solicitação de eco ICMP, TCP SYN na porta 443, TCP ACK na porta 80 e uma solicitação de carimbo de data / hora do ICMP por padrão. Quando executado por um usuário sem privilégios, apenas pacotes SYN são enviados (usando uma chamada de conexão) para as portas 80 e 443 no destino. Quando um usuário privilegiado tenta varrer alvos em uma rede Ethernet local, as solicitações de ARP são usadas, a menos que --send-ip tenha sido especificado. A opção -sn pode ser combinada com qualquer um dos tipos de análise de descoberta (as opções -P *, excluindo -Pn) para maior flexibilidade. Se alguma dessas opções de tipo e número de porta for utilizada, as análises padrão serão substituídas. Quando firewalls rígidos existem entre o host de origem executando o Nmap e a rede de destino, é recomendável usar essas técnicas avançadas.

Nas versões anteriores do Nmap, -sn era conhecido como -sP.

O -nobjetivo é evitar a resolução de DNS dos clientes (agiliza a verificação):

-n (sem resolução DNS)

Diz ao Nmap para nunca reverter a resolução de DNS nos endereços IP ativos que encontrar. Como o DNS pode ser lento, mesmo com o resolvedor de stub paralelo do Nmap, essa opção pode reduzir o tempo de varredura.

Você pode usar outras combinações para aprofundar a verificação ou os serviços, mas isso deve ser suficiente para o que você está procurando, a menos que os hosts estejam se mascarando ou descartando tudo.

Fonte: https://nmap.org/book/man-host-discovery.html

Parte 1 - fping

Essa ferramenta faz o ping de tudo na faixa de rede especificada e mostra aqueles que respondem via ICMP.

root@thionite:~# fping -a -g 10.28.1.0/24
10.28.1.1
10.28.1.2
10.28.1.3
10.28.1.4
10.28.1.5
10.28.1.12.....

Parte 2 - arp

Desde que o fping falou com tudo na LAN, isso fez com que uma entrada fosse adicionada à tabela ARP do sistema. Leia-o em alguns minutos, porque a tabela arp libera entradas antigas.

root@thionite:~# arp -a | grep -v incomplete
? (10.28.1.1) at 00:0d:b9:35:29:c4 [ether] on eth0
? (10.28.1.2) at 68:05:ca:10:53:5f [ether] on eth0
? (10.28.1.3) at d2:f1:6e:54:05:22 [ether] on eth0
? (10.28.1.4) at 00:1a:4d:26:85:ee [ether] on eth0
? (10.28.1.5) at 6e:a6:e5:78:da:ca [ether] on eth0
? (10.28.1.12) at 3c:4a:92:76:85:d8 [ether] on eth0

Observe também que a tabela ARP tem um tamanho máximo e o kernel despeja entradas antigas e de baixo uso.

Coloque tudo junto com

 fping -a -g 10.28.1.0/24 && arp -a | grep -v incomplete > arp.txt

depois navegue em arp.txt como desejar.

IPv6

Não assuma que o IPv4 é sua única opção. Muitos sistemas operacionais modernos lidam perfeitamente com o IPv6, mesmo que seu ISP não forneça conectividade V6.

Pode até haver dispositivos acessíveis apenas pelo IPv6 ou até outros protocolos.

Há vários endereços multicast úteis documentados em https://en.wikipedia.org/wiki/Multicast_address#IPv6 Mas o mais interessante para você é ff02 :: 1

root@thionite:~# ping6 -I eth0 ff02::1
PING ff02::1(ff02::1) from fe80::4261:86ff:fec4:cbaa%eth0 eth0: 56 data bytes
64 bytes from fe80::4261:86ff:fec4:cbaa%eth0: icmp_seq=1 ttl=64 time=0.047 ms
64 bytes from fe80::21a:4dff:fe26:85ee%eth0: icmp_seq=1 ttl=64 time=0.215 ms (DUP!)
64 bytes from fe80::6a05:caff:fe10:535f%eth0: icmp_seq=1 ttl=64 time=0.233 ms (DUP!)
64 bytes from fe80::226:55ff:feda:299c%eth0: icmp_seq=1 ttl=64 time=0.334 ms (DUP!)
64 bytes from fe80::20d:b9ff:fe35:29c4%eth0: icmp_seq=1 ttl=64 time=0.501 ms (DUP!)
64 bytes from fe80::21e:c2ff:fe13:36bf%eth0: icmp_seq=1 ttl=64 time=0.512 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:85d8%eth0: icmp_seq=1 ttl=1 time=0.518 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:8506%eth0: icmp_seq=1 ttl=1 time=0.757 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:e550%eth0: icmp_seq=1 ttl=1 time=0.772 ms (DUP!)
64 bytes from fe80::60cc:69ff:fe4f:7db0%eth0: icmp_seq=1 ttl=64 time=0.992 ms (DUP!)
64 bytes from fe80::90e4:77ff:fe32:3232%eth0: icmp_seq=1 ttl=64 time=1.00 ms (DUP!)
64 bytes from fe80::90e4:77ff:fe30:3030%eth0: icmp_seq=1 ttl=64 time=1.24 ms (DUP!)
64 bytes from fe80::90e4:77ff:fe31:3131%eth0: icmp_seq=1 ttl=64 time=1.34 ms (DUP!)
64 bytes from fe80::6ca6:e5ff:fe78:daca%eth0: icmp_seq=1 ttl=64 time=2.35 ms (DUP!)
64 bytes from fe80::b639:d6ff:feab:1000%eth0: icmp_seq=1 ttl=64 time=7.04 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:85d8%eth0: icmp_seq=1 ttl=1 time=8.02 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:8506%eth0: icmp_seq=1 ttl=1 time=8.03 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:e550%eth0: icmp_seq=1 ttl=1 time=8.06 ms (DUP!)
64 bytes from fe80::212:12ff:fef7:8044%eth0: icmp_seq=1 ttl=64 time=8.24 ms (DUP!)
64 bytes from fe80::8edc:d4ff:fef2:67e0%eth0: icmp_seq=1 ttl=64 time=18.3 ms (DUP!)
64 bytes from fe80::21e:c2ff:fea9:6d71%eth0: icmp_seq=1 ttl=64 time=295 ms (DUP!)
...repeats

Uma resposta ruim é executar ping no endereço de transmissão com

root@thionite:~# ping -b 10.28.255.255
WARNING: pinging broadcast address
PING 10.28.255.255 (10.28.255.255) 56(84) bytes of data.
64 bytes from 10.28.2.7: icmp_seq=1 ttl=64 time=0.220 ms
64 bytes from 10.28.3.12: icmp_seq=1 ttl=255 time=0.594 ms (DUP!)
64 bytes from 10.28.9.4: icmp_seq=1 ttl=64 time=1.03 ms (DUP!)
64 bytes from 10.28.1.151: icmp_seq=1 ttl=255 time=1.04 ms (DUP!)
64 bytes from 10.28.3.13: icmp_seq=1 ttl=255 time=2.22 ms (DUP!)
64 bytes from 10.28.3.11: icmp_seq=1 ttl=255 time=2.43 ms (DUP!)

Existem ~ 50 endereços IP nessa rede com uma máscara de rede / 16 e apenas sete responderam. Portanto, essa não é uma boa solução.

Além da resposta do MadHatter, existe uma ferramenta que faz a pesquisa arp sem tentar enviar primeiro um pacote de rede: arping .

Parece haver duas implementações:

• arping (versão de Thomas Habets) .
• arping (versão iputils)

Para o seu propósito, eu apenas pegaria o pacote da sua distribuição Linux, pois as diferenças provavelmente estão apenas nos detalhes.

Quando os dinossauros vagavam pela terra, proto-nerds usavam arpwatch

O arpwatch é uma ferramenta de software para monitorar o tráfego do Protocolo de resolução de endereços em uma rede de computadores. [1] Ele gera um log do emparelhamento observado de endereços IP com endereços MAC junto com um carimbo de data e hora quando o emparelhamento apareceu na rede. Ele também tem a opção de enviar um email para um administrador quando um emparelhamento é alterado ou adicionado.

página de manual do arpwatch

Entre no seu (s) switch (s) e emita show mac-address ou comandos semelhantes (dependendo da marca e modelo). Isso fornecerá todos os endereços MAC dos dispositivos ativos (exceto a própria opção). Se algum desses MACs não ocorrer entre os MACs encontrados com qualquer um dos métodos ping ou outros nas outras respostas, convém investigar melhor qual dispositivo é esse. Talvez isso não importe porque ele nem fala IP ou pertence a uma VLAN diferente, mas pelo menos você pode obter uma visão geral se suas outras sondas são precisas.