For the Love of 19506
If you are a die-hard Nessus fan like myself you are most likely familiar with the ‘Nessus Scan Information” plugin, 19506. If not, it’s a treasure trove of great scan data.
The plugin fires for any asset/IP scanned by Nessus regardless of the output. The use cases of where this information is critical is too numerous for a medium article. I think I could write a “19506 for dummies” guide on the 100s of use cases that bring you back to this data. For now I will do my best to distill the usefulness into three broad use cases.
Top 3 Use Cases
Out of the 100s of different ways and reasons one may use the data found in the plugin output of the scan information plugin, there are three core scenarios that drive someone to look for the data held.
“Nessus took down the server”
Nessus by default will scan roughly 4700 TCP ports and if you have a system that is sensitive to port scanning the result can be a service disruption. The proof all starts with 19506.
As an example, you can see when the scan started, down to the second, and how many seconds it persisted. This has saved hundreds of Nessus users from being blamed for an outage. Below is a navi screenshot below:
Once you correlate this data with the server logs you can be sure if the scan contributed to the problem. If there was a correlation the next piece of information that will be valuable is the port range which is also in the plugin output:
As you can see above the default port range was scanned; roughly 4790 commonly used ports. The ports are found in the nessus-services file on the Nessus scanner. In addition, you can see what scanner scanned the asset which is immensely helpful if you’re scan policy is using a group of scanners.
If none of the ports were found to be the problem, then you may want to look at how many checks were run on the system in question, which is also in the 19506 output.
The Max checks is how many plugins will fire at a single time on a scanned asset. I’ve changed the default in my lab from ‘5’ to ‘10’ to decrease scan times. However, it should be noted that this puts more stress on the scanned asset which should be accounted for in your scanning architecture. If you have older assets, you may want to reduce the number of checks per asset.
Last, I would be remised if I didn’t bring up Paranoid level, Experimental tests and safe checks. These are all safety features normally turned off for obvious reasons. However, if there is an event, it would be good to be sure they remained off during the scan in question.
“Nessus didn’t find a vulnerability”
It’s critical to keep your Nessus plugins up-to-date. Tenable typically creates new plugins daily and tackles zero-days within 24–48 hours of disclosure. If you do not keep your plugins up-to-date the result will be a less accurate view of risk.
As you should have guessed by now, you can verify the version of Nessus and the Plugin feed version in the output of the 19506 plugin.
Another common reason for Nessus missing vulnerabilities is due to the lack of credentials or authority in a scan policy. If Nessus can’t log into the asset and get authoritative data then it’s left up to port scanning and banner grabbing; to simplify it to it’s basic functions.
By now, you should be noticing a theme, the data is in the 19506 output.
To take a quick tangent, if you see ‘no’:
Then it could mean that the credentials were not added to the policy or they failed. Take a look at plugin 104410 for failed credentials. Screen shot below from navi:
Tag by these assets using navi and begin your remediation workflow to get better data on these assets:
navi tag --c "Credential failures" --v "104410" --plugin 104410“Why did the scan take so long?”
This is a difficult question to answer for the entire scan. As shown above the duration is at the very bottom of the plugin output. So if you are focused on how long a single asset took, this is an easy answer.
But how do you start to identify scan-wide problems?
The answer is to parse the 19506 plugin data and pull out the duration and analyze the data. This would require a CSV export of the plugin 19506 data and some manual parsing.
If you are using Tenable.io to wield the power of Nessus than you can use navi to parse the 19506 plugin data and get insights into your scans.
I created it “for the love of 19506!”
navi scan evaluate --scanid <your scan id> --histid <history ID if desired>
In addition to the above output, you will get a parsed CSV with the duration from each asset as a column. This data mixed with some decent excel skills and you can start to hone in an your assets that are taking longer than their similar counter-parts. Below is a snippet of the CSV output. Take a glance at how scan duration fluctuates between assets/IPs; From 88 seconds to 3022 seconds in the below screenshot.
When you go down this rabbit hole of why some assets take longer than others, a few more plugins will come in handy. It’s not always going to be as easy as tweaking a setting.
Plugin 12264 — Record Route — This plugin will help you understand if the scanner is too far from the target.
Plugin 10287 — Trace Route — This plugin will help you understand if the scanner is too far from the target.
Plugin 45433 — Memory Information — This plugin can grab the RAM from DMI. An asset that is low on RAM may take longer to scan. Especially if the “Max Checks” is higher than 5.
Plugin 56299 — Linux/Proc/CPU info — This plugin gathers information from the linux machine on the processers type and other features.
Plugin 45432 — Processor Information — This plugin gathers processor information from DMI
Conclusion
For the love of 19506 use the data in the Nessus plugin outputs. The handful of plugins shown in this article only briefly highlight the power of Nessus.
There are thousands of “Informational plugins” that can be used to start workflows, make better decisions, isolate assets and deepen your understanding of your attack surface.
