Advantages Of Running Both Network & Authenticated Nessus Scans

Implementing Different Scan Types

Often, Nessus and Security Center users ask how often they should run a vulnerability scan, and what kinds of scans should be run. In a previous post we explored some of the different scan types, including network checks, local checks and configuration auditing. I often encourage people to run all three types of scans against their network with different frequency. All three types provide interesting and useful results that should be included in your vulnerability management program. In this post we will explore the differences, and benefits, of running the first two types of scans mentioned: network-based scans and local checks.

Network-Based Scanning

My test system is an older version of Fedora Linux (Fedora Core 5). It is missing several patches and contains a web application, osCommerce, with several vulnerabilities. I scanned the system using a standard Nessus network-based scan and got results that one would expect from a scan with this configuration. For example, Nessus reported the current HTTP server version and type:

Nessus did not find any vulnerabilities or missing patches associated with this instance of Apache. The banner that was retrieved indicated that it is Apache version "2.2.0" running on Fedora. This version is reported to contain several vulnerabilities:

http://httpd.apache.org/security/vulnerabilities_22.html

The obvious question is, "if Nessus found that the banner contains a vulnerable version of Apache, why didn't it show up in the report?" The answer has to do with "backporting". Backporting is when a Linux distribution applies patches to a particular software package, but does not update the banner that is displayed by the service over the network (i.e. patching an older version rather than upgrading to a newer version without the vulnerabilities). Therefore, even if the banner in this case reports a vulnerable version of Apache, there is no way to be certain because it's part of a distribution (Fedora), which may have backported the patches. In order to reduce false positives, Nessus now includes "backport.inc", which documents the various banners from several different Linux distributions and identifies the backported version and the real version. The "backported version" is the version of the software that was patched by the Linux distribution, and the real version is the latest version of the product. For example, the entry for Fedora Core 5's instance of Apache is:

backported_versions[i++] = "Apache/2.2.0 (Fedora)";

real_versions[j++] = "Apache/2.2.99 (Fedora)";

This information tells Nessus that while Fedora will report Apache 2.2.0, they've been backporting fixes since then. Nessus sets the real version to Apache version 2.2.99, which does not exist, but ensures that the Fedora Apache will always be flagged as a backport. There are new plugins that will report when this condition has occurred, according to the service. For example, the host we scanned in this example also has an alert on port 80 that reads:

Nevertheless, how can we tell if those patches have really been applied? We'll get to that in the local checks section, but first let’s look at one advantage that network checking has over local checking. In the following alert Nessus discovered that osCommerce was installed and contained an unprotected Admin directory:

This is an advantage because in order to test a service and application, sometimes you need to see it running. In this case, Nessus was able to find evidence that osCommerce was configured incorrectly and exposing a vulnerability to the network.

Local Checking

To get a complete and accurate picture of the vulnerabilities that exist on a particular host, a local check for current patches can be performed. This testing requires that you have credentials on the hosts that you are testing. When run against our test host, Nessus finds that there are several missing patches, including updates for the "httpd" package, which is Apache:

Suppose we want to see all of the patches that are missing from this particular host. We can use the filtering and reporting features in the Nessus client to produce a report that lists each patch that is missing:

The report above uses a template that was documented in the post titled "Creating Custom Reports with Nessus 4". This report is formatted nicely for network administrators as they can use it as a guide to apply patches. For example, if the systems administrator sees the report above, they should issue commands to apply the patches. However, the Fedora release running on this system is no longer supported, so it is recommended that the system be rebuilt with Centos 5. Once the system has been rebuilt, you can ensure all the latest operating system updates are applied by issuing the "yum update" command. If there are packages to be updated, they will be listed:

If you see the message "No Packages marked for Update", this means your system is up-to-date. An up-to-date system scanned with local checks may not contain results. You can disable "Silent Dependencies" and make sure that Nessus was able to login in and check for patches:

Conclusion

In the examples above, we can see the value in running both network-based and local authenticated Nessus scans that check for the presence of patches. In the network example, we see how Nessus is able to avoid false positives and report on distributions performing backporting of security patches. In addition, Nessus has several plugins that identify vulnerabilities in applications and services across the network. Local checking allows Nessus to perform a full patch audit, and when coupled with the reporting features can provide a report that can be shared with systems administrators and used to help keep tabs on which systems are missing patches.

Resources

• Misleading Patch Audits
• Testing the Effectiveness of your Patch Management System
• Knowing When to Patch
• How did you test for MS08-067?