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

28

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
Vishal Sharma
fonte
9
Quem gerencia a rede? Você tem permissão para atribuir endereços IP arbitrários aos seus hosts?
Roger Lipscombe
4
Sim, eu tenho permissão. Esta é uma boa pergunta.
Vishal Sharma
11
A única maneira de obter uma resposta adequada é perguntar ao administrador da rede. Qualquer coisa que você faça arrisca a ser imprecisas porque os dispositivos pode ser desligado, reinicialização sem resposta, etc.
Jon Bentley
7
Para concluir os comentários de Roger e Jon, se os IPs na sua rede forem atribuídos manualmente e sem um DHCP, deve haver um registro em algum lugar (seja um banco de dados, uma planilha do Excel ou um diretório antigo) onde todas as alocações de IP são registradas e as pessoas o gerenciamento da rede deve ter e usar essas informações. Nenhuma solução técnica garantirá que você não esteja roubando involuntariamente o IP de outra máquina (seja um servidor inoperante ou um laptop de usuário remoto). Se esse registro for perdido ou inexistente, é necessário um inventário completo.
Zakinster
Você deve citar os endereços IP com caracteres curinga para garantir que seu shell não tente expandi-lo como um possível nome de arquivo. Por exemplo,nmap -sP -PR '172.16.128.*'
roaima

Respostas:

39

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.

MadHatter apoia Monica
fonte
2
Isso funciona apenas com dispositivos na mesma rede local, certo? Eu tentei em um servidor meu, as solicitações de ping são descartadas em algum lugar entre elas e não consigo encontrar nenhuma linha relevante arp.
Eric Duminil
Obrigado pela resposta. Eu só queria saber como o seu método se compara ao do @Leo? É melhor do que isso de alguma forma (porque, caso contrário, é mais fácil usar apenas um comando).
Vishal Sharma
2
@VishalSharma, EricDuminil: veja a edição acima.
MadHatter apoia Monica
Só para esclarecer, isso significa que o método @ Leo será semelhante ao seu somente quando usado por um usuário privilegiado e, portanto, quando for usado por um usuário desfavorecido, o resultado não será completo / incorreto? Além disso, por usuário privilegiado, você quer dizer um usuário com acesso ao sudo?
Vishal Sharma 16/05
1
@VishalSharma a primeira parte do seu comentário está correta. Usuário privilegiado inclui fazer algo sob sudo -u root(geralmente abreviado para sudo), mas também simplesmente estar logado como root ou ter feito /bin/su, daí o termo abrangente.
MadHatter apoia Monica
20

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.

Thorchy
fonte
Parece uma ferramenta promissora, mas não vem com o RHEL 6.5 (no meu caso pelo menos está ausente).
Vishal Sharma 16/05
@VishalSharma Isso é lamentável. Está disponível para o CentOS, então eu pensaria que ele também deveria estar disponível no RHEL.
Thorchy
4
Está no EPEL, os Pacotes Extra do Fedora para Enterprise Linux.
Mattdm 17/05/19
Não funciona se o LaBrea estiver em execução.
joshudson
@joshudson Tenho certeza de que é impossível para qualquer ferramenta / software procurar na rede endereços IP não utilizados quando o LaBrea estiver em execução.
Thorchy
11

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

Leo
fonte
A saída que eu mencionei é do comando nmap -sP -PR 172.16.128. * É por isso que verifica 254 hosts.
Vishal Sharma
No meu caso, o ID da rede é 172.16.128.128, portanto, tive que modificar o comando que você sugeriu. Eu usei o nmap -sn -n 172.16.128.128/25.
Vishal Sharma
Não sei ao certo o que você quis dizer com ID de rede, mas se o seu dispositivo tiver esse endereço e você desejar que todos os 254 hosts sejam verificados em sua sub-rede, você deve executar nmap -sn -n 172.16.128.1/24(em vez disso, como afirmei na resposta acima, isso verificará um 255.255. Máscara 255.0)
Leo
Por ID de rede, eu quis dizer, a string obtida executando 'And lógico' de Endereço_IP e máscara de sub-rede.
Vishal Sharma
Entendo. Então, o comando nmap que publiquei responde à sua pergunta? Os dois dispositivos listam os mesmos endereços em uso?
Leo
8

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.

Criggie
fonte
5

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.

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
Criggie
fonte
3

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.

Criggie
fonte
1
Por que resposta diferente? Você pode editar post
daisy
3
@daisy porque são respostas diferentes. Uma resposta monolítica pode ser boa, mas é retida por uma parte. Respostas separadas permitem que o mecanismo de votação para cima / para baixo funcione corretamente. Esta resposta foi realmente apenas por completude, não é muito útil na prática.
Criggie
1
A única coisa que o ping faz é se um dispositivo está ou não configurado para responder a pings.
Rob Moir
@RobMoir true - o ponto principal disso é que o endereço de transmissão existe e foi projetado no IPv4.
Criggie
3

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:

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.

todos
fonte
1

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

RedGrittyBrick
fonte
0

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.

Hagen von Eitzen
fonte