Using Nessus For Host Discovery

A Nessus user recently contacted me about performing a scan that would simply discover hosts on the network. This is a very low impact scan that does not look for vulnerabilities or enumerate ports. There are a few good reasons to run this type of scan:

Systems protected by a network or host-based firewall may only respond on a single port or to an ICMP echo request. Hosts that only respond to an ICMP ping will not show up in the default Nessus scan report. By enumerating these hosts you can include them in the report to show that scans were attempted but did not find any results, then determine if this is normal behavior or not.

Your internal policies may provide specific time windows when vulnerability scanning can occur. By tuning a scan that only discovers live hosts, you can check that your Nessus server is set up properly, collect a list of hosts to scan and stay within your vulnerability scanning policy guidelines.

To configure a scan that will only test if hosts are alive, use the following policy settings:

Click for larger image

In the main policy configuration screen above the only setting in the "Port scanners" section enabled is "Ping host", which tells Nessus not to portscan the target hosts but only send packets that will test if the hosts are alive or not. I've also increased the "Max checks per host" setting from the default of 40 to 80. Since we are only performing tests to check if a host is alive, scanning more hosts per scan will make the scan run much faster with little impact on the network or local Nessus scanner machine.

Click for larger image

All plugins can be disabled in the plugins section. This may seem odd at first, but the "Ping host" checkbox in the first configuration screen will take care of host discovery without any plugins being enabled. You could easily extend this scan to perform operating system identification by enabling the appropriate plugins, but be cautioned that this will trigger several more checks and increase your scan time as well as send more invasive scans to each host.

In the preferences tab under "Ping the remote host", you can tune the host discovery settings. I've checked "Log live hosts in the report", which causes Nessus to report on hosts that respond to a discovery ping, which is not the default behavior. I've also enabled "Fast network discovery", which disabled some of the more advanced features of host discovery, such as proxy server detection.

Processing the results

This is a great scan to run on a regular basis on your network to discover new hosts (and if you enable operating system detection, will tell you the type of hosts appearing on the network). If you are a penetration tester, you may also wish to export the IP addresses to a file for processing by other tools, or even quickly see which type of host discovery test was successful. By exporting the data to an NBE (download the report and save as an NBE file from within the Nessus GUI) file, I came up with two quick Linux (or other UNIX compatible shell) command line tricks to extract this information:

The following command will extract the IP address and the method of discovery:

The following command will extract just the IP addresses:

The nice part about the commands above, is that you can run this against any Nessus scan result file that you've enabled "Ping host" for and it will extract the live host information. This is done with the parameter sent to awk of "/10180/", which is the plugin ID associated with this option. Keep in mind you will be missing the hosts that only responded to host discovery unless you enable the option "Log live hosts in the report".

Conclusion

Knowing what's on your network is extremely important. If you don't know what is on your network, how do you know what needs to be managed, secured or monitored? The data can be used in all sorts of meaningful ways, such as tracking growth on the network or discovering hosts being plugged into the network that need to be scanned later. This is a great use of the new scan scheduling feature of Nessus, or an additional scan in your SecurityCenter. Finally, you may also want to read the post titled, Scanning Large Networks with Nessus, which also contains some tips useful for customizing Nessus scans in this way.