Come posso usare Linux per trovare indirizzi IP inutilizzati sulla mia rete?

Ho accesso a due computer (A e B) su una rete. Entrambi hanno un indirizzo IP statico con una subnet mask di 255.255.255.128 (ho verificato che non si utilizzava un server DHCP). Voglio configurare più indirizzi IP sulla stessa macchina e quindi voglio sapere quali sono tutti gli indirizzi IP già utilizzati nella sottorete.

Da una domanda precedente , ho provato il nmap -sP -PR 172.16.128.*comando, ma sono scettico sul suo risultato in quanto lo stesso comando dà risultati diversi sui miei due computer (A e B). Su A, gli spettacoli di risultato, un elenco di indirizzi IP che sono 8 (presumibilmente) già in uso, tra cui quella di A e B .

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

Ma su B, il risultato è diverso, cioè

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

Il risultato su B non mostra nemmeno il proprio indirizzo IP e l'indirizzo IP di A!

Che cosa sto facendo di sbagliato qui? Esiste un modo infallibile in Red Hat Linux (RHEL) per scoprire tutti gli indirizzi IP utilizzati nella sottorete di cui fa parte il mio computer?

RHEL: 6.5
Nmap version: 5.51

Qualsiasi dispositivo ben funzionante su una LAN Ethernet è libero di ignorare quasi tutto il traffico, quindi i PING, le scansioni delle porte e simili sono tutti inaffidabili. I dispositivi non sono, tuttavia, liberi di ignorare le richieste ARP , afaik. Dato che specifichi che stai eseguendo la scansione di una rete locale, trovo che il metodo meno fragile per fare ciò che desideri sia provare a connettersi a un indirizzo remoto, quindi cercare nella mia cache ARP.

Ecco un semplice dispositivo senza filtro (cioè uno che non è configurato per ignorare alcune classi di traffico 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

Ecco un dispositivo di filtraggio (uno configurato con una sola riga iptablesper ignorare tutto il traffico):

[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

Ecco un dispositivo che è appena giù; notare la mancanza di un indirizzo 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

Questo metodo non è infallibile - manca un dispositivo spento, per prima cosa - ma è il metodo meno terribile che abbia mai provato.

Modifica : Eric Duminil, sì, funziona solo su una rete locale; vedi il primo paragrafo.

Vishal, i metodi sono funzionalmente identici. Nota il testo citato nella risposta di Leo su nmap:

Quando un utente privilegiato tenta di eseguire la scansione di destinazioni su una rete Ethernet locale, le richieste ARP vengono utilizzate a meno che non sia --send-ipstato specificato.

Il suo metodo prevede una digitazione minore. Il mio può essere fatto senza privilegi e può darti una migliore comprensione di ciò che sta realmente accadendo. Ma la stessa cosa viene fatta sul filo in entrambi i casi.

Dato che un dispositivo non può ignorare le richieste ARP, mi piace usare uno strumento chiamato arp-scan. È disponibile nella maggior parte dei repository.

Quando si esegue il comando con lo --localnetswitch, verrà visualizzata una panoramica dell'intera rete interna.

sudo arp-scan --localnet

Mi dà un elenco di tutti gli indirizzi IP e MAC sulla mia rete. È anche possibile specificare un intervallo di rete da scansionare.

sudo arp-scan 172.16.128.0/25

Se sono configurate più interfacce di rete, è possibile specificare quella che si desidera utilizzare con lo switch -I.

sudo arp-scan -I eth0 172.16.128.0/25

Maggiori informazioni sui possibili switch sono disponibili su https://linux.die.net/man/1/arp-scan o eseguendo man arp-scan.

Non so quale versione di nmap stai utilizzando in Red Hat 6.5, ma per le versioni recenti, il modo corretto (e più veloce) penso che sarebbe:

nmap -sn -n 172.16.128.0/25

Questo elencherà tutti gli host della tua rete (quindi, potresti usare qualsiasi altro IP da quella sottorete come dovrebbe essere disponibile).

Modifica e nota: la sottorete che menzioni è 255.255.255.128, ma poi mostri l'output come scansione di 254 host. A meno che non mi manchi qualcosa, dovrebbe essere disponibile una maschera / 25 e 126 host. Se si desidera scansionare un / 24, modificare il comando sopra per interrogare tutti i 254 host.

Dal libro nmap, -sPè interrotto e sostituito da -sn:

-sn (nessuna scansione delle porte)

Questa opzione dice a Nmap di non eseguire una scansione delle porte dopo il rilevamento dell'host e di stampare solo gli host disponibili che hanno risposto alle sonde di rilevamento dell'host. Questo è spesso noto come "ping scan", ma è anche possibile richiedere l'esecuzione di script traceroute e host NSE. Questo è di default un passo più invadente della scansione dell'elenco e può spesso essere usato per gli stessi scopi. Consente una leggera ricognizione di una rete target senza attirare molta attenzione. Sapere quanti host sono attivi è più prezioso per gli aggressori rispetto all'elenco fornito dalla scansione dell'elenco di ogni singolo IP e nome host.

Anche gli amministratori di sistema ritengono utile questa opzione. Può essere facilmente utilizzato per contare le macchine disponibili su una rete o monitorare la disponibilità del server. Questo è spesso chiamato ping sweep ed è più affidabile del ping dell'indirizzo di trasmissione perché molti host non rispondono alle richieste di trasmissione.

Il rilevamento dell'host predefinito eseguito con -sn è costituito da una richiesta di eco ICMP, TCP SYN alla porta 443, TCP ACK alla porta 80 e una richiesta di data / ora ICMP per impostazione predefinita. Quando eseguito da un utente senza privilegi, solo i pacchetti SYN vengono inviati (usando una chiamata di connessione) alle porte 80 e 443 sulla destinazione. Quando un utente privilegiato tenta di eseguire la scansione di destinazioni su una rete Ethernet locale, vengono utilizzate le richieste ARP a meno che non sia stato specificato --send-ip. L'opzione -sn può essere combinata con qualsiasi tipo di sonda di rilevamento (le opzioni -P *, escluso -Pn) per una maggiore flessibilità. Se viene utilizzata una di queste opzioni del tipo di sonda e del numero di porta, le sonde predefinite vengono sostituite. Quando sono presenti firewall rigidi tra l'host di origine che esegue Nmap e la rete di destinazione, si consiglia di utilizzare tali tecniche avanzate.

Nelle versioni precedenti di Nmap, -sn era noto come -sP.

Il -nè quello di evitare la risoluzione DNS dei clienti (che rende la scansione più veloce):

-n (nessuna risoluzione DNS)

Indica a Nmap di non eseguire mai la risoluzione DNS inversa sugli indirizzi IP attivi che trova. Poiché il DNS può essere lento anche con il risolutore di stub parallelo incorporato di Nmap, questa opzione può ridurre i tempi di scansione.

Puoi utilizzare altre combinazioni per approfondire la scansione o i servizi, ma ciò dovrebbe bastare per quello che stai cercando, a meno che gli host non si mascherino o lascino cadere tutto.

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

Parte 1 - fping

Questo strumento esegue il ping di tutto nell'intervallo di rete specificato e mostra quelli che rispondono tramite 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

Dal momento che il fping ha parlato con qualsiasi cosa sulla LAN, ciò ha causato l'aggiunta di una voce alla tabella ARP del sistema. Leggilo tra un paio di minuti, perché la tabella arp scarica le vecchie voci.

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

Si noti inoltre che la tabella ARP ha una dimensione massima e che il kernel eliminerà le voci vecchie e di basso utilizzo.

Metti tutto insieme

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

quindi sfogliare arp.txt a tuo piacimento.

IPv6

Non dare per scontato che IPv4 sia l'unica opzione. Molti sistemi operativi moderni gestiscono bene IPv6, anche se il tuo ISP non fornisce connettività V6.

Potrebbero anche esserci dispositivi raggiungibili solo tramite IPv6 o addirittura altri protocolli.

Ci sono molti utili indirizzi multicast documentati in https://en.wikipedia.org/wiki/Multicast_address#IPv6 Ma quello interessante per te è 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

Una risposta scadente è il ping dell'indirizzo di trasmissione con

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!)

Ci sono ~ 50 indirizzi IP su quella rete con una maschera di rete / 16 e solo sette hanno risposto. Quindi questa non è una buona soluzione.

Oltre alla risposta di MadHatter, esiste uno strumento per la ricerca di arp senza provare a inviare prima un pacchetto di rete: arping .

Sembra che ci siano due implementazioni:

• arping (versione di Thomas Habets) .
• arping (versione iputils)

Per il tuo scopo prenderei semplicemente il pacchetto dalla tua distribuzione di Linux poiché le differenze sono probabilmente solo nei dettagli.

Ai tempi in cui i dinosauri vagavano per la terra, i proto-nerd usavano l' arpwatch

arpwatch è uno strumento software per il monitoraggio del traffico del protocollo di risoluzione dell'indirizzo su una rete di computer. [1] Genera un registro degli accoppiamenti osservati di indirizzi IP con indirizzi MAC insieme a un timestamp quando l'associazione appare sulla rete. Ha anche la possibilità di inviare un'e-mail a un amministratore quando un'associazione cambia o viene aggiunta.

Pagina man di arpwatch

Accedi ai tuoi switch e invia show mac-address o comandi simili (a seconda della marca e del modello). Questo ti darà tutti gli indirizzi MAC dei dispositivi attivi (tranne te stesso). Se uno di questi MAC non si verifica tra i MAC trovati con uno dei metodi ping o altri nelle altre risposte, è possibile che si desideri approfondire il dispositivo. Forse non importa perché non parla nemmeno IP o appartiene a una VLAN diversa, ma almeno puoi avere una panoramica se le altre tue sonde sono accurate.