28

I've got access to two computers (A and B) on a network. Both have got a static IP address with a subnet mask of 255.255.255.128 (I checked that a DHCP server was not being used). I want to configure multiple IP addresses to the same machine and hence I want to know what all IP addresses are already being used in the subnet.

From an earlier question, I tried nmap -sP -PR 172.16.128.* command, but, I'm skeptical about its result as the same command gives different results on my two computers (A and B). On A, the result shows, a list of 8 IP addresses which are (supposedly) already being used, including that of A and B.

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

But on B, the result is different i.e.,

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

The result on B is not even showing its own IP address as well as the IP address of A!

What exactly am I doing wrong here? Is there any foolproof way in Red Hat Linux (RHEL) of discovering all IP addresses being used in the subnet of which my computer is a part of?

RHEL: 6.5
Nmap version: 5.51
Peter Mortensen
  • 2,319
  • 5
  • 23
  • 24
Vishal Sharma
  • 391
  • 1
  • 3
  • 8
  • 9
    Who manages the network? Do you have their permission to assign arbitrary IP addresses to your hosts? – Roger Lipscombe May 16 '18 at 10:18
  • 4
    Yes I have the permission. That's a good question. – Vishal Sharma May 16 '18 at 10:33
  • 11
    The only way to get a proper answer is to ask your network administrator. Anything you do risks being inaccurate because devices might be switched off, rebooting, unresponsive, etc. – Jon Bentley May 16 '18 at 11:20
  • 7
    To complete Roger's and Jon's comments, if IPs in your network are assigned manually and without a DHCP, there should be a register somewhere (let it be a database, an Excel sheet or an old paper directory) where every IP allocation is recorded and people managing the network must have and use this information. No technical solution will ensure that you're not unwillingly stealing another machine's IP (let it be a down server or a remote user laptop). If this register is lost or non-existing, a full inventory is necessary. – zakinster May 16 '18 at 15:55
  • You should quote the wildcarded IP addresses to ensure that your shell doesn't try to expand it as a possible filename. For example, `nmap -sP -PR '172.16.128.*'` – roaima May 18 '18 at 14:06
  • You don't actually *say* B has a 172.16.128.* address. One easy way for B to see zero hosts on that subnet is for B to not be on that subnet. – Eric Towers May 19 '18 at 17:30

9 Answers9

40

Any well-behaved device on an Ethernet LAN is free to ignore nearly any traffic, so PINGs, port scans, and the like are all unreliable. Devices are not, however, free to ignore ARP requests, afaik. Given that you specify you're scanning a local network, I find the least-fragile method of doing what you want is to try to connect to a remote address, then look in my ARP cache.

Here's a simple, non-filtering device (ie, one which isn't configured to ignore some classes of IP traffic):

[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

Here's a filtering device (one configured with a single line of iptables to ignore all traffic):

[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

Here's a device that's just down; note the lack of a MAC address:

[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

This method's not infallible - it misses devices that are turned off, for one thing - but it's the least-dreadful method I've yet tried.

Edit: Eric Duminil, yes, it only works on a local network; see paragraph one.

Vishal, the methods are functionally identical. Note the text quoted in Leo's answer about nmap:

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

His method involves less typing. Mine can be done without privilege, and may give you a better understanding of what's actually happening. But the same thing is done on the wire in both cases.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • 2
    This only works with devices in the same local network right? I tried it on a server of mine, ping requests are dropped somewhere inbetween and I cannot find any relevant line with `arp`. – Eric Duminil May 16 '18 at 08:47
  • Thanks for the response. I just wanted to know how does your method compare to that of @Leo? Is it better than that in some way(because otherwise it's easier to use just one command). – Vishal Sharma May 16 '18 at 08:55
  • 2
    @VishalSharma , EricDuminil : see edit above. – MadHatter May 16 '18 at 09:07
  • Just to be clear, does it mean that @Leo's method will be similar to yours only when used by a privileged user and hence when it's used by an underprivileged user, it's result will not be complete/incorrect? Also, by privileged user do you mean, a user having sudo access? – Vishal Sharma May 16 '18 at 09:21
  • 1
    @VishalSharma the first part of your comment is correct. *Privileged user* includes doing something under `sudo -u root` (often shortened to `sudo`), but also simply being logged in as root, or having done `/bin/su`, hence the umbrella term. – MadHatter May 16 '18 at 09:24
  • To me, though, that means you really can't find unused addresses... All you can say for sure is at that moment, these are the addrthat are currently responding (counting arp responses), which is not the same thing.... Proper documentation or configuration management can't be substituted. – lsd May 18 '18 at 02:41
  • @lsd I agree, but this isn't a perfect world, and sometimes (read: about every other month) I walk into a new client network which has grown organically, and it's my job to *write* that documentation, and sort things out. I have to start *somewhere*. – MadHatter May 18 '18 at 06:05
  • What about using arpping instead of sending a packet and then reading the arp table? – allo May 18 '18 at 08:31
  • @allo firstly, for the avoidance of doubt for others, it's `arping`, not `arpping`. Other than that, it seems entirely equivalent, so that would work just as well. You should write that up as an answer, I'd upvote it! – MadHatter May 18 '18 at 09:44
  • I added it as answer. – allo May 18 '18 at 10:09
20

Since a device cannot ignore ARP requests, I like to use a tool named arp-scan. It is available in most repositories.

When you run the command with the --localnet switch it will give you an overview of your entire internal network.

sudo arp-scan --localnet

Gives me a list of all IP -and MAC addresses on my network. It is also possible to specify a network range to scan.

sudo arp-scan 172.16.128.0/25

If you have multiple network interfaces configured you can specify the one you want to use with the switch -I.

sudo arp-scan -I eth0 172.16.128.0/25

More information about possible switches can be found at https://linux.die.net/man/1/arp-scan or by running man arp-scan.

Thorchy
  • 1,421
  • 13
  • 15
11

I don't know which version of nmap you are running in your Red Hat 6.5, but for recent releases, the correct (and faster) way I think it would be:

nmap -sn -n 172.16.128.0/25

This will list every host in your network (so, you could use any other IP from that subnet as it should be available).

Edit and note: The subnet you mention is 255.255.255.128, but then you show the output as scanning 254 hosts. Unless I'm missing something, that should be a /25 mask and 126 hosts available. If you want to scan a /24, change the command above to query all 254 hosts.

From the nmap book, -sP is discontinued and replaced by -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.

The -n is to avoid DNS resolution of the clients (makes the scan faster):

-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.

You can use other combinations to deepen the scan or services, but that should suffice for what you are looking for, unless the hosts are masking themselves or dropping everything.

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

Leo
  • 1,833
  • 8
  • 17
  • The output I've mentioned is of the command nmap -sP -PR 172.16.128.* that is why it scans 254 hosts. – Vishal Sharma May 16 '18 at 08:59
  • In my case, network ID is 172.16.128.128 therefore, I had to modify the command that you've suggested. I used nmap -sn -n 172.16.128.128/25. – Vishal Sharma May 16 '18 at 08:59
  • I'm not sure what you meant by network ID, but if your device has that address and you want all the 254 hosts scanned in your subnet, you should run `nmap -sn -n 172.16.128.1/24` instead (as I stated in the answer above, that will scan a 255.255.255.0 mask) – Leo May 17 '18 at 02:18
  • By network ID, I had meant, the string obtained by performing 'logical And' of IP_Address and subnet mask. – Vishal Sharma May 17 '18 at 02:29
  • I see. So, does the nmap command I posted answer your question? Are both devices listing the same addresses being used? – Leo May 17 '18 at 22:59
  • Yes it works. I just had to make a small change which I have mentioned above in my 2nd comment. – Vishal Sharma May 18 '18 at 00:36
8

Part 1 -- fping

This tool pings everything in the network range specified, and shows those that answer 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.....

Part 2 -- arp

Since fping talked with everything on the LAN, that will have caused an entry to be added to the system's ARP table. Read it out within a couple of minutes, because the arp table flushes old entries.

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

Also note that the ARP table has a maximum size and the kernel will evict old and low usage entries.

Put it all together with 

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

then browse arp.txt at your leisure.

Criggie
  • 2,219
  • 13
  • 25
5

IPv6

Don't assume that IPv4 is your only option. Many modern operating systems handle IPv6 just fine, even if your ISP doesn't provide V6 connectivity.

There may even be devices which are only reachable by IPv6, or even other protocols.

There's a bunch of handy multicast addresses documented in https://en.wikipedia.org/wiki/Multicast_address#IPv6 But the interesting one for you is 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
  • 2,219
  • 13
  • 25
4

In addition to MadHatter's answer, there is a tool does the arp lookup without trying to send a network packet first: arping.

There seem to be two implementations:

For your purpose I would just take the package from your linux distribution as the differences are probably only in the details.

allo
  • 1,524
  • 1
  • 19
  • 35
3

A poor answer is to ping the broadcast address with

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

There are ~50 IP addresses on that network with a /16 netmask and only seven responded. So this is not a good solution.

Peter Mortensen
  • 2,319
  • 5
  • 23
  • 24
Criggie
  • 2,219
  • 13
  • 25
  • 1
    Why different answer? You can edit post – d a i s y May 16 '18 at 11:07
  • 3
    @daisy because they're different answers. One monolithic answer might be good but gets held down by one part. Separate answers allow the up/down voting mechanism to work properly. This answer was really only for completeness, its not very useful in practice. – Criggie May 16 '18 at 20:22
  • 1
    The only thing that ping tests is whether or not a device is configured to respond to pings. – Rob Moir May 17 '18 at 12:42
  • @RobMoir true - the main point of this is that the broadcast address exists and that it was designed into IPv4. – Criggie May 18 '18 at 02:29
1

Back when dinosaurs roamed the earth, proto-nerds used 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.

arpwatch man page

RedGrittyBrick
  • 3,792
  • 1
  • 16
  • 21
0

Login to your switch(es) and issue show mac-address or similar commands (depending on make and model). This will give you all MAC-Adresses of active devices (except thee switch itself). If any of these MACs does not occur among the MACs found with any of the ping or other methods in the other answers, you may want to investigate further what device that is. Maybe it doesn't matter because it does not even speak IP or belongs to a different VLAN, but at least you can get an overview whether your other probes are accurate.

Hagen von Eitzen
  • 816
  • 3
  • 15
  • 41