Most of the vulnerabilities reported by Nessus are signature and value-based, which Nessus makes a decision on based on the code present in the plugins. It is required to confirm these vulnerabilities using manual techniques such as Nmap scripts or port-specific open source tools. This will allow the administration team to put their efforts into the mitigation of the actual vulnerabilities instead of false positives. Also, sometimes, Nessus reports vulnerabilities for which workarounds have already been applied as Nessus only checks with respect to the conditions mentioned in the plugin and cannot recognize any other deviations. In this recipe, we will look at sets to verify multiple vulnerabilities reported by Nessus using Nmap and other open source tools.

In order to create this recipe, we will perform a demo basic network scan on Metasploitable 2's vulnerable virtual machine (look at the Getting ready section in order to download this). Once the scan is complete, a glance at the results will display a total of seven critical, five high, 18 medium, and seven low vulnerabilities. Out of the vulnerabilities reported by Nessus, we will try to manually confirm the following vulnerabilities:

• Bind shell backdoor detection: This is a critical-risk vulnerability that's reported by Nessus. This vulnerability points out that a port on the remote host is allowing any user on the network to run a shell with root privileges on the vulnerable virtual machine. We will use the Windows Telnet utility to confirm this vulnerability:

• SSL version 2 and 3 protocol detection: This is a high-risk vulnerability that's reported by Nessus. This vulnerability pertains to the usage of a legacy SSL protocol, such as SSL version 2 and version 3, which are known to cause multiple vulnerabilities. We will use Nmap script to confirm this vulnerability:

• Apache Tomcat default files: This is a medium-risk vulnerability that's reported by Nessus. This vulnerability mentions various default files which are created upon the installation of Apache tools. These are still available for any user on the network without authentication. We will use a web browser (Chrome, in this case) to confirm this vulnerability.