UPDATE [9/25/2020]: An engineer from Tenable happened across this post and reached out to clarify some of the seemingly peculiar behavior described in the original post. First, on the topic of why Nessus scans ports you haven’t explicitly targeted - Essentially, according to Tenable, it really can’t be avoided. I pretty much knew this as I had previously found the built-in config file specifying ping methods and port targets. What I found more illuminating was that Nessus has a Ping hierarchy where basically, it will try certain ping methods first and if they are successful, will NOT attempt subsequent ping methods. This answers why in cases where i specified certain ports be “pinged”, they were not actually targeted. This is because I had successful pings that preceded it, thus rendering pinging the arbitrary points unnecessary. Basically the point of the “Ping” portion of a Nessus scan is to find ONE piece of evidence a host is live rather than see all the ways a host is live. So Nessus may not in-fact be “lying” to us after all, but that doesnt make it any less confusing =).

End of Update


Part of any Vulnerability Management (VM) program is comprehensive, fast Host Discovery scans. Recently, I decided to take a closer look at the discovery scans configured within my organizations Tenable.sc instance with the goal of improving the speed and efficiency by which the scans would run. Here’s what everything looked like after some tweaking…

I got the scan policy whittled down to just two plugins, the FQDN plugin (12053) and the standard “Nessus Scan Information” plugin (19506).

All Plugins

FQDN Plugin

19506 Plugin

I then disabled all port scanning and service discovery switches.

Port Scanners Off Service Discovery Off

Finally I disabled ARP and UDP ping methods in the “Host Discovery” tab of the scan policy, leaving only ICMP and TCP ping switches on (with TCP ping Destination ports of 22,80,135,139,443,445 and 1337) as shown below…

*The TCP ping port 1337 has been included here for demonstration purposes.

Discovery Settings TCP Ping On

I then logged into the cli for the Nessus scanner which would be sending the scan traffic, started a network capture and observed what traffic this very lightweight policy would send. My expectation of course, was that it would send exactly what I told it to - an ICMP ping as well as TCP pings to the specified ports. Instead, I got the following…

Network Capture w/ TCP Pings ENABLED

Ok, so a couple observations… First, and most obviously, a lot more traffic was sent than I expected, including to ports I did not explicitly set. This seemed a bit strange, but after some research I found that Nessus has a built-in set of ports it uses for its TCP Ping Methods. Typically, this port-set is requested by inputting ‘default’ in the TCP destination ports for the “Ping Methods” section of the “Host Discovery” tab in the Nessus scan policy (…inhales…). However, I did not specify ‘default’, rather I put my own custom range in. Clearly Nessus is ignoring me here. Now the second, and more frustrating observation is that I don’t actually see the syn packet to my ‘1337’ port either!

Alright, so let’s move on from the TCP Ping switch. Let’s observe the behavior when this switch is disabled completely…

Discovery Settings TCP Ping Off

Network Capture w/ TCP Pings DISABLED


… … …
Interesting…

So even with TCP ping off, Nessus goes right ahead and tries to initiate some handshakes with a bunch of ports that look suspiciously like the ‘default’ ports from before (also known as ping_host4.inc file located on the Nessus box).

At this point I gave up trying to convince the Nessus policy to obey me. But I was still curious, what would happen if I disabled everything, and I mean EVERYTHING in the policy. I toggled every switch, even disabling ICMP pings. I turned off all plugins. I shut it all down. I then ran the scan… No change in behavior.

Suffice it to say, Nessus is lying to us.