Determining false positives when scanning for live hosts with Nmap

Question

When doing a vulnerability assessment on a large network, it seems general practice to determine which hosts on the network are live.

This can be done in various ways. From what I have read it is good to do some ICMP scans, perhaps use a vulnerability scanner that has a discovery component, and perhaps do some TCP/UDP scans to find hosts that don't respond to or block ICMP traffic.

I've run into a problem when doing TCP or UDP scans to determine if a host is alive or not.

Consider a sample network of 1000 hosts. Perhaps 50 will respond to ICMP traffic and can be considered live. Sometimes when doing a TCP/UDP scan, every host will be considered by nmap to be live, even if no ports are detected.

This is by using the -PN switch with nmap, which is necessary as otherwise hosts appear to be down and I do find additional live hosts with tcp ports open this way. It's just that most other hosts are also reported as being live when this isn't the case.

Is there a way to weed out false positive (i.e. hosts that report as up but have no ports open) for live hosts when using TCP or UDP scans?

Answer 1

What I typically do for this depends on the time I have for the scan. If I'm looking for relatively fast discovery beyond basic nmap (ICMP + port 80 ACK) I do a discovery scan with a list of common TCP ports something like

nmap -sP -PS 21,22,23,53,80,443,500,3389 [input range]

If I've got a bit more time, I'll add in a no ping scan for the top-1000 ports and only mark one's as up if they have at least one port open.

Lastly if I have a lot of time and the ranges aren't too huge I'll try a 65k TCP scan with no ping. This can take a really long time to complete so only do it if you need to be sure you've got everything, also I'd recommend making use of nmap's timing flags to speed up the process (e.g. --max-rtt-timeout, --max-retries, --max-scan-delay )

Answer 2

you can use the flag -PE, which performs a ICMP echo as an example:

nmap -sn -n -PE 192.168.1.1-255

or for a cleaner result

nmap -sn -n -PE 192.168.1.1-255 | grep report | cut -d" " -f5

Answer 3

How do you weed out false positives on a non-local network in nmap? Ports. If the target has ports up, it's live. If not, it's unknown.

ARP scans are best for weeding out false positives, and you might need a pivot point on the non-local network to do the scans to take advantage of that.

Otherwise, if possible, you might need to perform a packet capture to see if the hosts are generating traffic. But, it has to be the right situation for this to work.

Answer 4

This situation continues even after some time asked. I've been going through this for some time now and have to turn on debugging on the scans(pressing d repeatedly for the desired level and D to decrease to the desired level) to level three to see what is happening behind the scenes.

You can get port 21, 22, 80, 8080 when none of these are up on the hosts.

As per the nmap book, you have to use methods that make your scans stealthier.

Following on https://nmap.org/book/firewall-subversion.html and the articles before and after it on the nmap site gives you can an idea of the techniques available for use.

From the list on the nmap site I have used the following with good results:

--randomize-hosts

--scan-delay 1075ms

--source-port 53

These are not bullet-proof though since some better firewalls/IPS caught them and started giving open ports just like the others.

I've tested SYN scan on specific hosts -PS80,443,3389 and those get flagged quickly. I've also done the ACK scan on specific hosts such -PA80 and again, it gets flagged quickly as well. I had some luck with UDP-specific scans such as -PU53 or -PU161.

What worked well but would require a lot of time, is to lower your scan timing. You can either do that manually using minrtt or maxrtt, etc. or you choose -T1 or if you have some days' time you can use -T0.

Also what works well is dividing your scan target into fewer hosts, like five or ten hosts per scan.

Conclusion,try

nmap -sn -T0 -PU53 --scan-delay 1075ms --source-port 53 10.10.10.1-3

Answer 5

You are definitely looking for the following nmap flags --

-T1 -n -Pn --open --version-intensity 0 -sUSV -p-

This is not how I run nmap (as it is too slow and not very verbose), but it solves the problem you are asking about best. Perhaps you should try asking better questions and using your tool(s) more efficiently. Check for some of my other questions and answers in this forum.