Jun

Difference between safe and unsafe check plugins in Nessus

admin

Between, Check, Difference, Nessus, Plugins, safe, unsafe

Difference between safe and unsafe check plugins in Nessus

Nessus Automated Vulnerability Scanner has more than 40,000 plugins which can be used to audit networks with host based checks and network checks. There are also many different options that we used to configure to optimize our scans. One of these options is to enable or disable “safe checks”. The “safe checks” setting allows us to enable a set of plugins within our framework’s library of vulnerability checks which Nessus 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 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 Nessus 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, Nessus 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, Nessus 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, Nessus’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, Nessus is able to write a network check which can accurately test a remote network service without impact.

When Nessus 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. Nessus 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, Nessus 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 of our older plugins do have behavior changes based on the “safe checks” setting. For example, if “safe checks” is enabled, some plugins will perform it’s audit based solely on the banner, otherwise it will perform a query. 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.