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

Question

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 de 255.255.255.128 (I verificado que um servidor DHCP não estava sendo usado). Eu quero configurar vários endereços IP para a mesma máquina e, portanto, eu quero saber o que todos os endereços IP já estão sendo usados na sub-rede.

De uma pergunta anterior , Eu tentei o comando nmap -sP -PR 172.16.128.* , mas sou cético quanto ao resultado, já que o mesmo comando fornece resultados diferentes nos meus dois computadores (A e B). Em A, o resultado mostra uma lista de 8 endereços IP que (supostamente) já estão sendo usados, 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 sequer mostra o seu próprio endereço IP, bem como o endereço IP de A!

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

RHEL: 6.5
Nmap version: 5.51

    

Answer 1

Qualquer dispositivo bem comportado em uma LAN Ethernet é livre para ignorar praticamente qualquer tráfego, portanto, PINGs, varreduras de porta e similares não são confiáveis. No entanto, os dispositivos não estão livres para ignorar solicitações ARP , afaik. Dado que você especifica que está varrendo uma rede local, eu acho que o método menos frágil de fazer o que você quer é tentar se conectar a um endereço remoto, então procure no meu cache ARP.

Aqui está um dispositivo simples, sem filtragem (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 de iptables para ignorar o tráfego all ):

[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á desativado; note 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

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

Editar : Eric Duminil, sim, 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 :

When a privileged user tries to scan targets on a local ethernet network, ARP requests are used unless --send-ip was specified.

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 em ambos os casos.

    

Answer 2

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

Quando você executar o comando com a opção --localnet , ele fornecerá uma visão geral de toda a sua rede interna.

sudo arp-scan --localnet

Fornece-me uma lista de todos os endereços IP e MAC na 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 aquela que deseja usar com a opção -I .

sudo arp-scan -I eth0 172.16.128.0/25

Mais informações sobre possíveis opções podem ser encontradas no link ou executando man arp-scan .

    

Answer 3

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

nmap -sn -n 172.16.128.0/25

Isto irá listar todos os hosts em sua rede (assim, você poderia usar qualquer outro IP daquela sub-rede como deveria estar disponível).

Editar e anotar: A sub-rede que você mencionou é 255.255.255.128, mas depois mostra a saída como varredura de 254 hosts. A menos que eu esteja sentindo falta de algo, isso deve ser uma máscara / 25 e 126 hosts disponíveis. Se você quiser digitalizar um / 24, altere o comando acima para consultar todos os 254 hosts.

Do livro nmap, -sP foi descontinuado e substituído por -sn :

-sn (No port scan)

This option tells Nmap not to do a port scan after host discovery, and only print out the available hosts that responded to the host discovery probes. This is often known as a “ping scan”, but you can also request that traceroute and NSE host scripts be run. This is by default one step more intrusive than the list scan, and can often be used for the same purposes. It allows light reconnaissance of a target network without attracting much attention. Knowing how many hosts are up is more valuable to attackers than the list provided by list scan of every single IP and host name.

Systems administrators often find this option valuable as well. It can easily be used to count available machines on a network or monitor server availability. This is often called a ping sweep, and is more reliable than pinging the broadcast address because many hosts do not reply to broadcast queries.

The default host discovery done with -sn consists of an ICMP echo request, TCP SYN to port 443, TCP ACK to port 80, and an ICMP timestamp request by default. When executed by an unprivileged user, only SYN packets are sent (using a connect call) to ports 80 and 443 on the target. When a privileged user tries to scan targets on a local ethernet network, ARP requests are used unless --send-ip was specified. The -sn option can be combined with any of the discovery probe types (the -P* options, excluding -Pn) for greater flexibility. If any of those probe type and port number options are used, the default probes are overridden. When strict firewalls are in place between the source host running Nmap and the target network, using those advanced techniques is recommended. Otherwise hosts could be missed when the firewall drops probes or their responses.

In previous releases of Nmap, -sn was known as -sP.

O -n é para evitar a resolução de DNS dos clientes (torna a verificação mais rápida):

-n (No DNS resolution)

Tells Nmap to never do reverse DNS resolution on the active IP addresses it finds. Since DNS can be slow even with Nmap's built-in parallel stub resolver, this option can slash scanning times.

Você pode usar outras combinações para aprofundar a varredura 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: link

    

Answer 4

Parte 1 - fping

Esta ferramenta pings tudo no intervalo de rede especificado 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

Como fping falou sobre tudo na LAN, isso fará com que uma entrada seja adicionada à tabela ARP do sistema. Leia-o dentro de 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 removerá 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 arp.txt como quiser.

    

Answer 5

IPv6

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

Pode até haver dispositivos que só podem ser acessados pelo IPv6 ou por outros protocolos.

Há vários endereços multicast úteis documentados em link Mas o 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

    

Answer 6

Uma resposta ruim é pingar o endereço de broadcast 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. Então, isso não é uma boa solução.

    

Answer 7

Além da resposta de MadHatter, existe uma ferramenta que faz a pesquisa de 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, já que as diferenças provavelmente estão apenas nos detalhes.

    

Answer 8

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

arpwatch is a computer software tool for monitoring Address Resolution Protocol traffic on a computer network.[1] It generates a log of observed pairing of IP addresses with MAC addresses along with a timestamp when the pairing appeared on the network. It also has the option of sending an email to an administrator when a pairing changes or is added.

página de manual do arpwatch

    

Answer 9

Faça login no (s) seu (s) switch (es) e emita show mac-address ou comandos semelhantes (dependendo da marca e modelo). Isto lhe dará todos os MAC-Adresses de dispositivos ativos (exceto que você mude a si mesmo). Se algum desses MACs não ocorrer entre os MACs encontrados com qualquer um dos métodos ping ou outros nas outras respostas, você poderá investigar melhor qual dispositivo é esse. Talvez isso não importe, porque nem sequer 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.