Nessus false positives

Last Updated on November 23, 2022 by Dave Farquhar

Dealing with false positives is a fact of life for a vulnerability analyst. So here are some tips for investigating and dealing with Nessus false positives from a system administrator turned vulnerability analyst.

The caveat with Nessus false positives

Nessus false positives
Nessus false positives aren’t hard to deal with as long as you take a look at the results column early and often.

With a good vulnerability scanner like Nessus, false positives are actually less of a problem than false negatives. For all the reputation Nessus has, I’ve found it to be very accurate.

Whether you report a false positive or disregard it and fix something, the steps are the same.

Check authentication

The first question is whether the scan authenticated. External scans don’t authenticate; scan internally from the DMZ to confirm or refute a false positive. Unauthenticated scans are always less reliable because they have less to go on, and Nessus doesn’t want to risk stability by testing behavior any further than it has to.

Check the output of plugin 19506 for whether the scans were credentialed. That’s your starting point. Tenable has a long list of authentication-related plugins to run through. If you correct the authentication issues, rescan again and see if your findings go away. When you authenticate, Nessus can check the actual files, which is extremely reliable. Checking behavior is less so.

Nessus does know about backported fixes, but it may require an authenticated check to detect the backport, since the backport may not change the version number that the service reports to the port scan.

Check the port

Next, check the port. If it’s port 22 or 445 it’s much less likely to be a true false positive. Port probes tend to check banners, which can lie to you. Scans via port 22 or 445 check the binaries instead.

Examine the plugin output column

Finally, examine the plugin output column of the finding. This tells you the specific file Nessus objects to, the point of disagreement between Nessus and your operating system. Check that file on the host to see if the findings match what Nessus says. If the file isn’t the same, you have a false positive. If the file is the wrong version like Nessus says, it’s not a false positive. You have a patch that either partially applied, or that partially reverted after the fact, and now the system is vulnerable again. Uninstall and reinstall the update, reboot if necessary, and then rescan to see if the file took this time. Make sure you are completely caught up on the reboots as well.

And if that doesn’t fix it, here are my two favorite tricks from my sysadmin days: look for errors in the ETL files, and here’s how to force a Microsoft update.

That’s how to investigate and take care of Nessus false positives.

If you found this post informative or helpful, please share it!