Optimizing Enterprise Nessus Scans for Speed

Tenable often receives requests for advice and strategies to help very large organizations decrease their scanning time. Readers should keep in mind that from Tenable's point of view, a "large" organization is someone with multiple Class B networks and more than 1 million items reported by Nessus. A basic concept to keep in mind when modifying how scans run is that there is a balance between scanning speed, thoroughness and invasiveness. For example, one may simply be able to decrease scan speed times by decreasing the number of tests performed. The scan happens faster but is not as thorough. This blog entry details some strategies that can help decrease scanning times with Nessus for very large networks. 

Distributed Scanning

Load balancing multiple Nessus 3 scanners can also speed up your scan times. We've blogged about this before, but don't want organizations to forget to take advantage of this. 

Tenable regularly deals with large organizations that deploy 10, 20 or even 30 scanners to scan millions of IP addresses. They manage these scanners with the Security Center.

Don't do Full Port Scans

There is nothing technically wrong with performing a full port scan, except that the laws of physics must be observed. For any network, there will be a maximum number of simultaneous ports and hosts that can be probed. Choke points can come from network devices such as firewalls, low bandwidth links or even the performance of the systems being scanned.

From a "realtive work" perspective, there are 65535 ports that can be targeted whereas there are less than 15,000 Nessus plugins. Most of those plugins don't even run because Nessus efficiently disables plugins that aren't relevant for the system being scanned. This means that for full port scans, it will take much longer to find the open ports than to perform the vulnerability audit.

Also, for enterprise scans, the default port range used by Nessus is typically "good enough" for finding most of your open ports. Tenable's experience with large customers has shown that full port scans do find a few more open ports than the default ports targeted by Nessus, but the amount of extra time involved performing these scans is beyond the point of diminishing returns.

If looking for all open ports is a corporate requirement, consider deploying more Nessus 3 scanners closer to their target networks. Also consider deploying Passive Vulnerability Scanners which find open ports (as well as browsed ports, Internet browsing devices and internal trust relationships) in real-time.

Disable Slower Scan Options

Two parameters for Nessus scans that can dramatically impact  performance are to disable both the "CGI Abuses" and "CGI ABuses : XSS" families and to also disabled "Thorough Tests".

With the 1000s of CGI and XSS (Cross Site Scripting) vulnerabilities disclosed to date, testing for all of them on every discovered web server might not be the most efficient course of action for a large scan. If these families are enabled, for every web server discovered, Nessus will probe for each potential CGI application installed. Since many devices ship with embedded web servers, disabling these families can let you concentrate full scans on just the authorized web servers for your organization. Nessus clients also have a scan policy setting named "Disable CGI scanning" which prevents all things related to CGI probing.

Also, the "Thorough Tests" scanning parameter causes various NASL scripts to "work harder". For example,  when looking through SMB file shares, a NASL might choose to look 3 levels deep instead of 1. This could cause much more network traffic and analysis if the target host has more shares. By default, all Security Center scans have "Thorough Tests" disabled.

Don't scan Dead Space

Another way to scan large amounts of address space is to try and ignore the hosts that are not there. Scanning "dead space" slows down scans because no matter how much CPU or network bandwidth you have access to, Nessus will wait a fixed amount of time to decide that a host isn't there. Of course the caveat is that if you think an IP address isn't occupied, you'll never know it unless you watch for network traffic from it or try to scan it occasionally. Some strategies to only scan an accurate list of active hosts include:

• The Security Center can be used to create a dynamic asset list of all available hosts and then a chained scan can be used to scan just hosts of a certain type, a certain age, a certain OS or many other parameters.
• If one or more Passive Vulnerability Scanners are in place, the information from these hosts can be used to identify active hosts in a dynamic asset list, and then targeted with an active scan.
• If you have access to some sort of asset tracking system, or can query your switching infrastructure for a list of active IP addresses, these can be fed into a Nessus scan or a Security Center static asset list.

If you can place your Nessus 3 scanners closer to the collision domain of a target network, an Ethernet ping will be performed. This is much faster than an ICMP ping and will decrease the amount of time waiting for hosts to reply that are not there.

Look for Choke Points

Another type of analysis that can be performed is to consider the actual network being scanned. There may be choke points that slow down a scan. Here are some ideas to consider and research for your local network:

Are all scans going through the same switch, switching infrastructure, vlan or router? Asking your network engineering folks about network performance during a scan could be enlightening.

Are there security devices or gateways that are operating at capacity during the scan? For example, consider the performance of firewalls, proxy devices, and wireless gateways during the scan.

Consider the "Information about the scan" Plugin

Nessus plugin ID #19506 records the results of the scan, including the amount of time it takes to complete the scan. Below is a screen shot of an example result under the Security Center:

In this case, the host was fully scanned in 10 seconds. However, what if we want to create dynamic asset lists based on the amount of time it takes to complete a scan of a host? This would allow us to use the Security Center's powerful reporting,, sorting, filtering and analysis capabilities to identify which class systems is taking to long.

To do this, we'd need to create some dynamic asset lists and use some regular expressions to identify hosts with "long" scan times. For a quick review of some dynamic asset list creation examples, consider this previous blog entry.

For each of these dynamic asset rules, we will tag it to plugin ID #19506. In each of these examples we will tag the text string "Scan duration : 10 sec" and uses regular expression to look for times other than "10".

Here are some example "text strings" you can drop directly into a Security Center regular expression dynamic asset rule:

• 30 Seconds or more
  19506:Scan duration : ([3-9][0-9])|([0-9]{3}) sec
  This will match scan times larger than 29 seconds.
• 60 Seconds or more
  19506:Scan duration : ([6-9][0-9])|([0-9]{3}) sec
  This will match scan times larger than 59 seconds.
• 100 Seconds or more
  19506:Scan duration : [0-9]{3} sec
  This will match scan times from 100 seconds to 999 seconds.
• 200 Seconds or more
  19506:Scan duration : ([2-9][0-9][0-9]) sec
  This will match scan times from 200 seconds to 999 seconds.
• 300 Seconds or more
  19506:Scan duration : ([3-9][0-9][0-9]) sec
  This will match scan times from 300 second to 999 seconds.

For performance, the 100, 200 and 300 regular expression rules are more efficient than the 30 and 60 second rules.

To add these to your Security Center, add a new Dynamic Asset List. Then add a "pluginid" match filter for 19506. Then add a "plugintext" regex filter for one of the patterns in italics shown above.

In the screen shot below, an asset list named "Long Scan Time" was created with the "30 Seconds or more" example above. We can see that the scan time of this host 37 seconds. On our demo network, this also matched hosts with scan times of 407 seconds, 58 seconds and 39 seconds.

So what sort of analysis can you perform with this type of approach? Consider the following techniques:

• Are these systems all part of the same network or subnet? This could indicate some sort of choke point.
• Do these systems all have something in common that "faster" hosts don't have? Consider things like CPU, memory, and system firewalls. Also consider things like actual applications. It might make sense that the IIS web servers take longer to scan than a Windows 2003 file server.
• Is there a set of vulnerabilities or open ports common to these assets? 

This type of analysis is ideally suited for the Security Center 3D tool. Performing a query for a target network and then a second query for the hosts that have long scan times will allow you to visually compare the open ports and vulnerabilities present such as in this screen shot below:

Summary

Although this blog entry focused on some advanced things to consider for your network scans, don't forget the basics. Make sure your Nessus scanners have enough horsepower (watch their CPU usage during a scan) and enough network bandwidth.

Also, most organizations have upgraded to Nessus 3. If you are still using Nessus 2, consider doing an upgrade as version 3 is much faster than 2. Tenable has produced a comprehensive comparison between Nessus 2 and Nessus 3 scanning speed.

And lastly, Security Center users with multiple Nessus scanners should not run their scanner directly on the Security Center. Generally, you can scan with Nessus from the Security Center, but the performance impact is unacceptable for large scans. If you don't mind the impact to Security Center, your scans will still complete faster by utilizing the CPUs on the Security Center system.

Tenable customers also have access to the support knowledge base which includes other best practices for configuring scans. If you have tips on optimizing your Nessus scan results, please feel free to send them to Tenable or post them to the Nessus mailing list.