Selecting vulnerability checks
When Nexpose fingerprints an asset during the discovery phases of a scan, it automatically determines which vulnerability checks to perform based on the fingerprint. On the Vulnerability Checks tab of the Scan Template Configuration page, you can manually configure scans to include more checks than those indicated by the fingerprint. You also can disable checks by group or individually.
To access the Vulnerability Checks tab in your scan template:
- In your Security Console, click the Administration tab.
- In the Scan Options section, click Manage scan templates next to Templates.
- Click the name link of your existing custom scan template to open it. If you don't have a custom scan template yet, click the copy icon next to the built-in scan template of your choice.
Check configuration
The Check Configuration section of your scan template allows you to tune the following vulnerability check options.
Unsafe checks
Unsafe checks include buffer overflow tests against applications like IIS and Apache and services like FTP and SSH. Others include protocol errors in some database clients that trigger system failures.
A warning on running unsafe checks
Scans that run unsafe checks may crash a system or leave a system in an indeterminate state, even though it appears to be operating normally. Scans like this will most likely not do any permanent damage to the target system. However, if processes running in the system cause data corruption in the event of a system failure, unintended side effects may occur.
The benefit of unsafe checks is that they can verify vulnerabilities that threaten denial of service attacks, which render a system unavailable by crashing it, terminating a service, or consuming services to such an extent that the system using them cannot do any work. You should run scheduled unsafe checks against target assets outside of business hours and then restart those assets after scanning. It is also a good idea to run unsafe checks in a pre-production environment to test the resistance of assets to denial-of-service conditions.
Potential checks
If you want to perform checks for potential vulnerabilities, select the appropriate checkbox.
Vulnerability classifications
If a vulnerability can be verified, a confirmed vulnerability is reported. If the system is unable to verify a vulnerability known to be associated with that asset, it reports an unconfirmed or potential vulnerability. The difference between these latter two classifications is the level of probability. Unconfirmed vulnerabilities are more likely to exist than potential ones, based on the asset’s profile.
Correlate reliable checks with regular checks
If you want to correlate reliable checks with regular checks, select the appropriate check box. With this setting enabled, Nexpose puts more trust in operating system patch checks to attempt to override the results of other checks that could be less reliable. Operating system patch checks are more reliable than remote, banner-based vulnerability checks.
For example, if a vulnerability check is positive for an Apache Web server based on inspection the HTTP banner, but an operating system patch check determines that the Apache package has been patched for this specific vulnerability, it will not report a vulnerability. Enabling reliable check correlation is a best practice that reduces false positives.
Nexpose performs operating-system-level patch verification checks for the operating systems supported as recurring vulnerability coverage, including Microsoft Windows, Solaris, VMware, and several Linux distributions.
Check correlation requirements
To use check correlation, you must use a scan template that includes patch verification checks, and you must typically include credentials in your site configuration.
Selected checks
A scan template may specify certain vulnerability checks to be enabled, which means that Nexpose will scan only for those vulnerability check types or categories with that template. If you do not specifically enable any vulnerability checks, then you are essentially enabling all of them, except for those that you specifically disable.
A scan template may specify certain checks as being disabled, which means that Nexpose will scan for all vulnerabilities except for those vulnerability check types or categories with that template. In other words, if no checks are disabled, it will scan for all vulnerabilities. While the exhaustive template includes all possible vulnerability checks, the Full Audit and PCI Audit templates exclude policy checks, which are more time consuming. The Web Audit template appropriately only scans for web-related vulnerabilities.
Checks by category
Categories that are named for manufacturers, such as Microsoft, can serve as supersets of categories that are named for their products. For example, if you select the Microsoft category, you inherently include all Microsoft product categories, such as Microsoft Path and Microsoft Windows. This applies to other "company" categories, such as Adobe, Apple, and Mozilla.
Checks by type
The following list accounts for the current check types that you can choose from:
- Default account
- Local
- Metasploit
- Microsoft hotfix
- Patch
- Policy
- Potential Vulnerabilities
- RPM
- Safe
- Unsafe
- Version
- Windows registry
- Scan Diagnostics
Individual checks
You can also configure a scan template to run very specific vulnerability checks according to your specifications. Since the contents of Nexpose's ever-expanding vulnerability check library numbers in the hundreds of thousands, you will need to search for the individual checks that you want to include before selecting them. Tailoring a purpose-built scan template to only run specific checks is a great way to efficiently scan your assets for some of the most high-profile and critical vulnerabilities out there.
Target system compatibility
Nexpose only checks vulnerabilities relevant to the systems that it scans. It will not perform a check against a non-compatible system even if you specifically selected that check.
Fine-tune your scans with selected vulnerability checks
In general, the fewer vulnerability checks included in the scan template, the sooner the scan completes. However, note that the check-count-to-scan-time relationship does not scale evenly. Some vulnerability checks take longer to scan than others.
The following are a few examples of this:
- The Microsoft IIS directory traversal check tests 500 URL combinations. This can take several minutes against a busy web server.
- Unsafe, denial-of-service checks take a particularly long time since they involve large amounts of data or multiple requests to target systems.
- Cross-site scripting (CSS/XSS) tests may take a long time on web applications with many forms.
Be careful not to sacrifice accuracy by disabling too many checks or essential checks. Choose vulnerability checks in a focused way whenever possible. If you are only scanning web assets, enable web-related vulnerability checks. If you are performing a patch verification scan, enable hotfix checks.
Nexpose is designed to minimize scan times by grouping related checks in one scan pass. This limits the number of open connections and the time interval that connections remain open. For checks relying solely on software version numbers, the application requires no further communication with the target system once it extracts the version information.
Plugins to manage custom checks
If you have created custom vulnerability checks, use the custom vulnerability content plugin to ensure that these checks are available for selection in your scan template. The process involves simply copying the check content into a directory of your Security Console installation.
In Linux, the location is in the plugins/java/1/CustomScanner/1 directory inside the root of your installation path. For example:
In Windows, the location is in the plugins\java\1\CustomScanner\1 directory inside of the root of your installation path. For example:
After copying the files, you can use the checks immediately by selecting them in your scan template configuration.