#9 Nessus Detects Misconfiguration - Top Ten Things You Didn't Know About Nessus

The Nessus Top Ten List

This is the second post in a series of ten that will cover “The Top Ten Things You Didn’t Know About Nessus”. The first, starting with 10 in David Letterman top ten list fashion, is titled “There's More Than One Way To...” and covers the benefits of both credentialed and uncredentialed vulnerability scanning. Each item on the list will have a blog post and video associated with it. And now, on to number 9: “Nessus Detects Misconfiguration”.

Misconfiguration Leads To Compromise

Nessus helps you answer the question “Do my systems have uniform configuration settings?” Why is this important? Systems are increasingly more complex, and maintaining control of your configurations leads to systems that run smoother and are more resilient to attack. A recent case study that supports this concept was presented in a blog post titled "What do you mean privilege escalation is not HIGH RISK?".

A penetration testing team was able to gain access to a system by exploiting a web application vulnerability. From there, they used several different techniques to escalate privileges and compromise several more systems. The defensive recommendations included the following:

1) Protect your SSH keys - Ensure that all of your SSH private keys require a passphrase before they can be used.

2) Ensure all of your web applications are patched to the latest version - Web applications can be difficult to enumerate across the network. Unless you know the directory and/or hostname associated with an application, it can go unnoticed by vulnerability scanning.

3) Don't allow trusted SSH between servers unless it’s required - Technically, you put rules in place to prevent servers from initiating connections directly to each other via SSH. However, unless you audit the systems you may never know if there was an exception that allowed servers to connect to each other.

4) Don't install compilers and debuggers on your production systems - Once a system goes into production, you can certainly remove compilers and debuggers. However, as maintenance and regular administration is performed these tools can make their way back onto the systems, especially if a systems administrator is in a hurry to correct a problem.

The defensive recommendations above are, for the most part, calling for systems administrators to audit their settings. It’s one thing to agree on a set of configuration polices and another to implement them, but how can you be certain all the systems remain in compliance with your own standards? One of the most difficult things to do when I was a systems administrator was to keep configuration settings the same on all systems (or groups of similar systems). Systems would change, updates would be applied, people would make changes to systems at 3:00AM in an emergency to correct a problem, all contributing to system settings falling out-of-scope of the policies I worked so hard to create and implement. Fortunately, Tenable's Nessus vulnerability scanner allows you to consistently audit the configuration settings on your systems. For example, to address the defensive recommendations above, Nessus allows you to:

1) Execute Linux/UNIX shell commands - Inside a Nessus configuration audit policy you can specify a command to run, and check for the desired result. This means you can script a check to see if SSH keys have a password set.

2) Look inside configuration files - Nessus has the ability to search a configuration (or any plain text file) on a system, locate certain parameters, and test for specific settings. For example, if you wanted to make sure that all of your Red Hat server's SSH configurations did not permit the "root" user to login, the check would look as follows:

The audit check above comes from the CIS benchmark audit file for Red Hat systems.

3) Inventory software - Nessus configuration auditing contains functionality that allows you to identify software packages installed by the OS distribution. To implement checks that look for packages such as compilers, the check is as follows:

The audit check above is also contained in the CIS benchmark checks for Red Hat systems.

Stacking Up to Benchmarks

The Center for Internet Security (CIS) establishes consensus benchmarks for a large variety of applications and operating systems. These benchmarks are a valuable aid to evaluate the security of your systems. Tenable has produced a number of Nessus audit files that have been certified by the Center for Internet Security to perform audits against the CIS standards. These audit files are available to ProfessionalFeed and SecurityCenter customers through the Tenable Support Portal.

To use these audit files, you will need to provide Nessus with credentials to login to the target host to compare the configuration against the CIS standards. Scans that use login credentials run much faster than network-based scans and the results often provide more detailed vulnerability findings and information on configuration issues.

There are several audit files associated with the CIS benchmarks that apply to Linux-based web servers (using the example from the penetration test above). I have the following audits to evaluate the security of the system used to host web applications:

• CIS_MySQL_4.1_5.1_Benchmark_v1.0.1.audit
• CIS_Apache_v2_1.audit
• CIS_Redhat_ES5_1_1.audit

The audit files listed above correspond to the published CIS benchmarks. You can obtain these benchmark documents by registering on the Center for Internet Security web site. The audit files are loaded into Nessus and the scan policy is configured accordingly (please refer to the Nessus 4.4 Users Guide for more information).

Additional Information

• Auditing Linux, Apache, & MySQL Against CIS Benchmarks
• Nessus Cisco Compliance Checks
• Auditing Secure Shell - Part I