Tenable Blog

This webinar will feature myself and Ron Gula and discuss how to use Nessus to perform security auditing of custom web applications.

A friend of mine, who was preparing to teach a workshop that included information about Nessus, recently asked: "What are the top three things you would tell people about Nessus?" Below is a more detailed version of my response:

1) Network Scanning - With over 28,000 plugins, Nessus has some excellent coverage in terms of vulnerability scanning for your systems and network. When running a network-based scan it is important to tune it appropriately. Look at the different plugin families and enable the ones that you think are most relevant. In addition, review the Advanced options for your scan. If you are performing web application testing, take a look at the Advanced options global variable settings. If speed is not a factor, you can get some awesome results by enabling CGI scanning, experimental plugins and thorough tests. Finally, don't just look at the high level alerts: some medium and low level alerts can lead to root access!

At a recent OWASP meeting in Princeton, NJ I gave a short presentation on some techniques to have Nessus dig deeper into your web applications. There are several approaches to web application testing:

"Blind Tests" - Often a penetration tester is provided a range of address spaces and some rules of engagement to define the parameters of the test. Information such as which IP addresses and/or hostnames are running web servers is not typically provided, nor is a list of which web applications are running on those web servers. Nessus contains functionality to identify running web servers and vulnerable web applications, which is is very useful if you have large amounts of address space to scan. This does not replace manual testing, but provides a starting point for detailed web application tests.

Web sites have a way of evading vulnerability scanners in the form of virtual hosting. It is a common practice to host multiple web-sites (and associated applications) on a single web server using only one IP addresses. This causes problems for vulnerability scanners, including Nessus, as they look for vulnerabilities on the single IP or hostname provided. The remote server directs this traffic to a specific virtual host or web application, leaving a considerable amount of virtual real-estate untouched. The problem is that Nessus has no easy way to enumerate the domain names or additional IP addresses associated with a given system. Scanning every hostname, domain name and IP address associated with the server could reveal additional vulnerabilities in the web applications or hosts associated with the given server. For example, when scanning just a single IP address in the lab, I received the following result:

A Nessus user recently asked us the following question:

"I would like to have Nessus read Nmap scan results from the command line. I already have Nmap portscanning and operating system fingerprinting, can I import the Nmap findings using Nessus in batch mode?"

Tenable has supported Nmap usage within Nessus for several years. Nmap and Nessus have different types of scanning philosophies and understanding how they work can help you achieve success with your network scanning efforts. The Nessus server includes its own portscanning, service fingerprinting and operating system identification techniques that are similar but independent from Nmap’s. However, you may run into a situation where Nmap was run first and you already have the output from this tool and want to apply the results to your vulnerability scan. I set out to do this in my lab and realized this would be a good opportunity to highlight some of the features in Nessus. Below is a step-by-step guide on configuring Nessus to run batch mode scans based on Nmap results:

Stacking Up to CIS 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 Security Center customers through the 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.

PCI-DSS Scanning

The effectiveness of the Payment Card Industry (PCI) standards to secure systems responsible for credit card transaction processing is a question of debate among information security professionals. Regardless of the hype or negativity surrounding PCI, it remains a requirement for many organizations to follow. Nessus has built-in PCI-DSS compliance checks that compare scan results with the PCI standards and produce a report on your compliance posture. It is very important to note that a successful compliance scan does not guarantee compliance or a secure infrastructure. Compliance scanning is just one tool to be used as part of a comprehensive program that includes the appropriate policies and procedures to ensure that assets are appropriately protected.

XSLT Reporting

A new feature in Nessus 4 is the ability to use XSLT stylesheets to create custom reports. The stylesheets read the .nessus XML file and allow you to create a number of different report styles, such as HTML and CSV, as well as extract or sort specific data from the scan results. Nessus 4 comes with several built-in stylesheets that can sort results and display a report based on several criteria, including:

• Sort By CVE
• Sort By IP Address
• Sort By Port
• Sort By Vulnerability

You can use this feature in conjunction with the report filtering to more easily create custom reports.

Nessus Scanning Through Firewalls

A number of factors can inhibit a successful Nessus scan: busy systems, congested networks, hosts with large amounts of listening services and legacy systems with poor performance all contribute to scan failure(s). However, firewalls (or other types of filtering devices) are one of the major causes of slow or inaccurate scans. Firewalls are essential for an organization’s perimeter protection and internal network segregation. Host-based firewalls are now common on both Linux and Windows systems. Scanners can be placed on network segments behind a firewall to avoid these problems, but this may not be feasible in your network, create extra burden moving a scanner around and is ineffective against host-based firewalls. Even if you allow the scanner's IP address through the firewall, connection tracking and stateful inspection can interfere with the scan. There are two strategies for dealing with firewalls when using Nessus to perform internal or external vulnerability scans.

The Tenable research team has been steadily working on creating accurate checking for Conficker infected hosts. Over the weekend researchers Felix Leder and Tillmann Werner of the University at Bonn released details on how to detect Conficker using network-based checks. This checking methodology was used as a basis for Nessus plugin 36036 as well as the Nmap NSE script created for the same purpose.