4

nmap keeps showing different and wrong results whenever I perform a scan to see how many hosts are up on my subnet. See the following scan reports.

The first scan I made was not with super user privilege. The second scan was made to see if it makes any difference if I had super user privilege. The third scan I made was specific for a particular IP address(which was up during first 2 scans as well but was not reported by it). Any Idea?

papagolf@Sierra ~ % nmap -sn 192.168.1.1-255

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2016-10-31 18:50 IST
Nmap scan report for www.netis.cc (192.168.1.1)
Host is up (0.0048s latency).
Nmap scan report for 192.168.1.4
Host is up (0.00014s latency).
Nmap done: 255 IP addresses (2 hosts up) scanned in 19.31 seconds
papagolf@Sierra ~ % sudo nmap -sn 192.168.1.1-255
[sudo] password for papagolf: 

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2016-10-31 18:51 IST
Nmap scan report for 192.168.1.4
Host is up.
Nmap done: 255 IP addresses (1 host up) scanned in 26.98 seconds
papagolf@Sierra ~ % sudo nmap -sn 192.168.1.3    

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2016-10-31 18:52 IST
Nmap scan report for 192.168.1.3
Host is up (0.0030s latency).
MAC Address: B0:47:BF:AC:A6:C4 (Samsung Electronics)
Nmap done: 1 IP address (1 host up) scanned in 16.78 seconds

3 Answers 3

3

First of all, I don't think Nmap is showing "wrong" results to you. You are getting different results as expected, because you are doing different scans, even if you don't know that. Using Nmap is not like using a magic option combination that will give you straight away a definitive result. There exist different techniques because different devices in the network behave differently (routers, firewalls, different OS...), and also you might want to be more or less "invisible". Herein, the beauty of Nmap is its flexibility, that allows you to conduct many different scans to find what you need. Imagine it as a mapping tool that will give you X results with some options and Z results with some others. Then, it is your brain who should interpret them and come to conclusions. You only ran the basic command with all the default options, and there is much more to explore.


[1] You are doing only a ping scan, which by default will do the following:

  • Send an ICMP echo request
  • Send a TCP ACK packet to port 80

NOTE: Newer Nmap versions (I believe yours included) also send a TCP SYN packet to port 443 and an ICMP timestamp request.


[2] If you are in the same network (and you are a super user), which in your case means the computer running Nmap has an IP like 192.168.1.X, an ARP request will be used instead. If you use Wireshark you can see the ARP packet exchanges.


[3] Lastly, the default behaviour of [1] uses RAW packets for the ICMP echo and the TCP ACK, so when you use an unprivileged user then Nmap cannot use this technique. Instead, Nmap will send a TCP SYN packet to port 80, by using connect as your normal user applications will do.


If you understand how Nmap is working ([1], [2] and [3]) then you can see why you are getting different results.

In your first scan, both computers (192.168.1.1 and 192.168.1.4) accepted the TCP connection. This used to be a very noisy scan, because applications will log the fact that you have accessed them. But you got what you wanted: seeing they were alive. Note that you can configure this type of scan when running Nmap as a super user (so even when you are a super user you can use [3] instead of [1] or [2]) and you will have obtained exactly the same result.

Your second scan sent an ACK to port 80 and an ICMP echo, and 192.168.1.1 ignored it. This could mean that it has a firewall in place. On the other hand, 192.168.1.4 responded either to the ACK or the ICMP echo. If you were in the same network (192.168.1.0), then ARP would have been used instead (see [2])... but if that was the case, for some reason 192.168.1.1 would have not responded to your ARP request, which I find unusual. Therefore, I would guess that you were not in the same network.

In your third scan, in my opinion 192.168.1.3 should have given you the same results as it did in the second scan. The fact that 192.168.1.3 did not show up in the second scan might respond to different facts - perhaps it was connected through wifi and it was down? It happens to my phone sometimes when it disconnects automatically to save power. Did you get these results consistently? You should run more verbose scans to see why exactly Nmap is interpreting network hints the way it does.

Finally, if you are serious about learning the tool, I strongly recommend you to get Fyodor's Nmap book. It is great not only to understand how Nmap works, but also some computer networks behaviour and other tricks. For example, you could use -n to skip reverse DNS lookups and speed up your test. You could also try different ping ports (from the default 80) and different types of ping.

3
  • That's a very good answer. Why, out of interest by the way, doesn't nmap use ARP for the hosts in the same network for unpriv users too, to perform -sn for example? I checked and arping command doesn't require root privs. Jan 15, 2020 at 13:43
  • Never mind, I think I found the answer by performing nmap without sudo for the whole subnet rather than just one IP address. For the IPs that don't exist in the ARP cache, an ARP req is sent first. --disable-arp-ping flag doesn't seem to stop ARPs going out though, which still is a mystery to me. Jan 15, 2020 at 14:00
  • I think you do need root to send raw Ethernet packets - otherwise you could attach IP data to your raw Ethernet packet and send a raw IP packet with no root. When you did the nmap without sudo, you did a 3-way handshake connect() to each address, and during this process, your OS NEEDs to determine each destination MAC address to send them data, so it has to send an ARP request as it would do normally (but it is not sent by Nmap!) This is why the nmap flag didn't stop ARP requests, nmap has no control in the same way as nmap cannot stop the client ACK in during the connect() Feb 29, 2020 at 1:48
0

As you can see in your second scan too 192.168.1.1 is not shown up and the mode of your scan is

-sn -- ping only no port scan

there should be some problem which icmp connectivity which sometimes makes this host ( 192.168.1.3 ) looks as if not up

3
  • So How do I perform a reliable scan?
    – 7_R3X
    Oct 31, 2016 at 14:34
  • What do you want to do ? Just find the alive host Oct 31, 2016 at 14:40
  • Yes. I just want to have a reliable list of all the hosts alive on my network. But performing an individual scan against each IP address sounds like a hectic job.
    – 7_R3X
    Oct 31, 2016 at 14:42
0

There is a difference between privileged and unprivileged scan, but only for port scans (SYN, ACK, etc). The difference is that the privileged one will craft a raw TCP packet against the target IP, meanwhile the unprivileged scan will rely on the connect syscall. It shouldn't affect discovered hosts, just speed (For details about why is that, you should refer to nmap documentation)

The reason why the third scan discovered a host the other two scans didn't may vary. Some hosts don't respond ping packets at all (It shouldn't be a reliable scan unless you're 100% sure the host will respond), some hosts have a minimum delay between responses, dropped packets if the network is overloaded, a firewall, etc

If you want a realiable list of all available hosts you should use more than one type of scan, but the scans you may need depend on the precision level you want, the knowledge of the network you have and the amount of time you can spend

A simple scan that should give you better results could be

sudo nmap -PS --disable-arp-ping 192.168.1.0/24

That will list all discovered hosts using a TCP SYN scan against most common ports. If that doesn't fit your needs (Maybe there are some hosts blocking all common ports scanned) you should try with more advanced scans like:

sudo nmap -PA 192.168.1.0/24
sudo nmap -sA -p1-65535 192.168.1.0/24
sudo nmap -sN -p1-65535 192.168.1.0/24
sudo nmap -PO 192.168.1.0/24

Not all scans will discover every host, that depends on too much things

PS: If you want more detail of what's going on during the scan you could use the flags --reason, --packet-trace and/or -vv. Those flags will enable a more verbose output indicating the reason a port is marked open/closed/filtered/unfiltered, the packets sent to each host and general purpouse verbosity respectively

6
  • 1
    Note that -PS will not likely work against, e.g. a Linux system with iptables in place. In that case, the default -PA might have better chances Dec 7, 2016 at 20:22
  • I have also realised there are some wrong facts in this answer... Jul 25, 2018 at 23:12
  • @user1156544 It would be great if you actually tell what is wrong or at least edit the answer...
    – Mr. E
    Jul 26, 2018 at 16:39
  • Sorry, you are right. Well, one thing is that if you sudo nmap -PS x.x.x.x and x.x.x.x is in your same network as the OP said in a comment, nmap will actually do a -PR instead, so the PS is actually never done! I think this answer has good intentions but fails in some actual operative details Jul 26, 2018 at 22:06
  • @user1156544 Edited my answer with your comment so -PS scans is not actually turned into a -PR scan on local networks
    – Mr. E
    Jul 26, 2018 at 22:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.