Understanding the Nessus "Safe Checks" Option

Nessus has more than 11,000 plugins which can be used to audit networks with host based checks and network checks. There are also many different options that Nessus users can configure to optimize their scans. One of these options is to enable or disable "safe checks". The "safe checks" setting allows Nessus users to enable a set of plugins within Nessus' library of vulnerability checks which Tenable feels can have negative effects on the network, device or application being tested. This post will explain why disabling "safe checks" for testing pre-production equipment is a good idea, why enabling "safe checks" for production testing is recommended and why some network plugins for Nessus can have adverse effects.

The "safe checks" setting effects network check plugins. These are plugins which make some sort of network check other than leveraging credentials such as SSH, Windows domain or SNMP. When Tenable writes a network check, we try to make the check as "nice" as possible. The goal is to accept no damage or interruption of the target system except perhaps a log entry from the probe. Usually, Tenable is able to produce not only a host-based patch audit for a given vulnerability, but if there is a network service involved, also produce a network check which does not require credentials. In some cases though, if a network vulnerability has been patched, there may not be an elegant way to check for this without credentials. 

For these network checks, Tenable may still be able to write a check that finds the vulnerability, but also has some sort of negative impact on a target, such as crashing a network daemon. When this happens, Tenable's policy is to write the check anyway, but mark the plugin as "unsafe". These checks will only become enabled when the "safe checks" setting has been disabled. Please keep in mind that the majority of the time, Tenable is able to write a Nessus network check which can accurately test a remote network service without impact.   

When Tenable encounters Denial of Service (DOS) checks and various vulnerabilities in non-robust targets such as embedded devices, we almost always mark these plugins as unsafe checks. Tenable regularly encounters vulnerabilities in embedded devices such as routers and printers. Often these devices have network services, but if they are pushed too hard with any sort of testing, the service or the actual device may crash. For example, Tenable recently was testing a network storage device and found that multiple queries to URLs outside of the "admin" page eventually DOSed the web service. The only way to really test this class of vulnerabilities is to try them.

Historically, some older Nessus plugins do have behavior changes based on the "safe checks" setting. For example, if "safe checks" is enabled, the apache_2_0_45.nasl (Nessus plugin #11507) will perform it's audit based solely on the banner, otherwise it will perform a query. While it's not all that common in newer checks, Tenable does occasionally use the "safe checks" setting such as in Nessus plugin #22204, which checks for last month's flaws in Ruby on Rails. Usually though, the "safe checks" setting is completely enabling or disabling a plugin we feel is suspect.

So as a rule of thumb:

• If you are scanning multiple hosts or entire networks, "safe checks" should be enabled. This will minimize any negative side effects of the scanning and also decrease your scanning time.
• If you are auditing one or more hosts in a pre-production environment, disabling "safe checks" will perform a slightly more complete audit, but at the risk or performing a test which might have negative impact on the tested systems.
• If you are auditing a network device, an embedded device that is operational and want a complete audit, consider setting up a test network with the devices of concern and run a Nessus scan with "safe checks" disabled.
• Enabling "safe checks" is no guarantee that a poorly written or managed network component, application or system won't have an issue with the next ICMP ping packet, SYN scan or web query. If you'd like to minimize impact to your network, you should consider performing your scans entirely with credentials or using Tenable's Passive Vulnerability Scanner.