3
VULNERABILITY SCANNERS

Although vulnerability management has several other components, the raw data you collect from your vulnerability scanner is the most important. If the scanner isn’t configured correctly or if it’s located in the wrong place, it won’t give you the data you need for the rest of your vulnerability management process.

This book assumes use of a network-based scanner, which learns about a system by sending packets across the network and listening for particular responses. In this chapter, I’ll discuss how network-based vulnerability scanners work and how to make the most of them in your environment.

What Vulnerability Scanners Do

A scanner discovers all it can about the OS and running services on every device you configure it to scan. Based on the discovered information, the scanner determines whether the device is susceptible to any known vulnerabilities. Once it finishes collecting a list of vulnerabilities on all the devices within the specified network ranges, the scanner produces a report. The report consists of a list of hosts, any information known about them, and which vulnerabilities exist on each host. You’ll use this report as a major component of your vulnerability analysis.

How Vulnerability Scanners Work

Security administrators configure scanners to scan specific network ranges or individual systems, or targets. The scanner sends ping packets to all IP addresses in the given target—reaching out to hosts to determine what is active and responding. Once the scanner knows which IP addresses belong to live devices, it sends additional pings, connection requests to open ports, or packets crafted to elicit certain status messages or error responses. An administrator can configure the scanner to be more or less aggressive when probing. At higher levels of aggression, the scanner will send thousands of packets to each device to find out which ports are open and what kind of device it is.

Once the scanner recognizes what a device is and what services are running on it, it sends probes to determine additional information. For instance, if it detects that the device is listening on port 80 (a typical web server port), it will try to connect to the web server to identify which server software is running (and which version is in use). The scanner matches version information against its own internal vulnerability database. If, for instance, the device is running version 3.1 of a specific piece of software, and vulnerabilities in that software were fixed in version 3.2, the scanner reports that the device is vulnerable to those issues. In addition, some scanners have specific tests for certain vulnerabilities. These tests are useful in cases where other mitigations that prevent exploitation of that vulnerability have already been implemented.

Scanning isn’t an exact science. Although fingerprinting often discovers the OS running on a device, exceptional cases might throw it off. For example, a customized network stack can make a machine appear to be running a different OS, or a rare OS without a good fingerprint available might be misidentified.

A similar level of uncertainty exists with vulnerability discovery. For instance, an HTTP server reports that it’s running Apache 2.2.0, and the scanner infers that it’s vulnerable to specific issues that weren’t fixed until Apache 2.2.1. But that system’s vendor backported those fixes to its customized version of Apache 2.2.0, so in fact the system isn’t vulnerable. The scanner has no way of knowing this, so it reports the false positive that the system is vulnerable. Although you can minimize these errors, false positives are part of network vulnerability scanning.

How to Deploy Vulnerability Scanners

You have a number of choices to make about how you deploy scanners in your systems, including how to give them access to the networks they need to scan, what OS and hardware they run on, and how to configure them so they are effective in your environment.

Ensuring the Scanner Has Access

Scanner placement within the network is critical. If you’re trying to scan any network segment other than the local network, the scanner will send packets through routers and maybe even firewalls. Those devices might have ACLs or firewall rules preventing certain sorts of traffic, both of which are likely to drop the scanner’s probe packets. As such, you can use two general methods for deploying scanners.

First, you can open full access through any intervening network devices from the scanner to any network ranges you intend to scan. This might involve excluding the scanner’s traffic from IPS policies. Opening full access ensures that packets aren’t blocked between the scanner and its target, which could cause incorrect results.

Second, you can set up multiple scanners—each local, or close in the network topology, to the network segments to scan. For instance, if you want to scan a firewall demilitarized zone (DMZ), place a scanner within the DMZ so it has direct access to the systems it’s trying to scan. Both approaches have strengths and weaknesses.

Opening Full Access to Your Scanner

By configuring the network to accept and pass all scanner traffic and responses, you can locate the scanner anywhere in your network. You can also use a single scanner for multiple network segments, which reduces the cost of setting up a scanning environment. But opening full access from the scanner can also be dangerous; attackers can leverage holes in your router and firewall infrastructure. If an attacker compromises the scanner system, they could use its access to the rest of the network to compromise other systems more easily.

Setting Up Multiple Scanners

Setting up multiple scanners might seem to be the best approach. You don’t need to open firewall ports or add ACLs. But this method has its own drawbacks.

First, it costs more to set up, because each scanner requires its own physical or virtual hardware. Also, if you’re using a commercial scanner, the licensing fees could cost more than the underlying hardware.

Second, you might have a coordination issue: either you’ll have to connect to each scanner directly to set up scans and retrieve the results separately, or you’ll need some kind of hierarchical environment to manage the scanners from a central location. For example, Tenable sells Security Center to manage multiple Nessus scanners, and Qualys uses the cloud-based QualysGuard. This coordination adds time and costs to scanner deployment.

Additionally, you’ll likely still need to open firewall ports and router configurations to ensure the analyst (or central control system) can access these scanners in various network locations.

Choosing Your OS and Hardware

Some scanners, such as Qualys, use their own appliances, so you don’t have control over the underlying system. But others—including Nessus and OpenVAS—are applications that run on whichever platform you prefer. The OS you choose doesn’t matter, as long as your scanner of choice supports it. You can use whichever platform you’re most familiar with or whichever follows your organization’s policy.

For the hardware, more power is always better. Scanners use a tremendous amount of RAM because they run a large number of concurrent tests against multiple targets, so it’s best to beef up the RAM first. Generally speaking, two CPUs and 8GB of RAM should be enough for a small deployment. Less RAM will work, but your system might be unresponsive while the scanner is running. A fast connection (high speed with low latency) is also essential; otherwise, the network tests will take a long time and might even return false positives or negatives if they time out before completion.

Configuring Your Scanner

Once your scanner is set up and online, you need to tailor the scanner to your environment. Scanners have a long list of configuration options, often called policies or templates. They let you configure how fast your scanner sends out its packets, what types of tests to run, and many other choices. The options ensure that the scanner returns useful results without overburdening your network or causing issues with the devices it scans. If you have a test environment, this is a good time to use it: configure your scan policies and then scan the test network. If you run into problems (for example, network congestion, or slowdowns, or device malfunctions caused by the scanner’s actions), adjust your policy until you eliminate those issues. Once you’re sure the scanner is properly customized, you can scan your live environment. Whether or not you can practice on a test network first, it’s still best to run a few scans on a small portion of your live network before scanning the entire system. It’s better to experience problems with a few systems—preferably those you manage that are geographically close—than to cause your entire production database environment to reboot!

Once you’ve tested your scan policy and are ready to scan larger parts of your network, or even the entire system, consider the best way to set up your scans’ targets and schedules. There are a few reasons to break up your scans into more manageable pieces. If you run one enormous scan, it might take a very long time to complete—time you could otherwise be using to analyze scan data from smaller scans. If you have several scanners, you’ll need to set up your scans so the correct scanners are targeting the correct networks. Additionally, the ideal times to run the scans might be different for different network segments. Although it might be fine to run scans on your workstation VLANs after hours, that might be prime processing time in some of your data center environments. Some sensitive or production-critical networks might simply be off limits until designated change windows, just in case something goes wrong and a system becomes unresponsive.

When you’re planning your scans, inform other stakeholders of your scan plans and policies and involve them in determining appropriate scan targets and time windows. Involving others early in the planning process ensures you won’t catch them by surprise if you run a scan that causes a domain controller to crash. You don’t want the Windows administrators to successfully lobby for their systems to be exempt from future scans. To have a complete view of your network, you’ll need buy-in, or at the very least grudging acceptance, of the scanning regimen before you begin. In Chapter 6, we’ll talk more about how to get scanning and remediation accomplished in a business environment.

Some organizations simply won’t allow regular automated vulnerability scans. In this case, manually run the scans with an analyst present to monitor the scan progress. Then, if any issues pop up on the scanned systems, the scapegoat—I mean, analyst—can halt the scan before downtime is incurred or prolonged.

Organizations with very stringent uptime requirements and extremely rare maintenance windows might use lab or redundant systems as scan targets instead of live systems. An additional set of ­servers—or an entire network—is duplicated, including the network configurations, OS, applications, and patch levels. Any scan data from the test systems will, in principle, be identical to any data from live systems.

But it can be very difficult to perfectly synchronize the patch levels of systems. Any difference in configuration can lead to differing scan results—for instance, if the host-based firewall on a lab system opens a different set of ports than on the live system. The bottom line is that there is no way to ensure accurate results without conducting scans against the real-world systems that you’re tasked to protect.

Getting Results

Scanners can report their results in many ways: a plaintext file; a structured format like XML or CSV; or more readable formats like HTML, an RTF or Word file, or a PDF. Although the last options are preferable for reading the reports directly, we’ll focus on the machine-readable output formats, such as XML and CSV. The reason is that running the scanner and collecting its results is only the first step. You’ll still need to analyze this data to get useful vulnerability intelligence. Most, if not all, scanners can produce output in XML, and that is the format you’ll use most in this guide. But any structured, computer-parseable format will do.

Summary

Vulnerability scanners can generate vast amounts of information, and it’s important to understand what is useful to you as a vulnerability analyst. By properly deploying and configuring your vulnerability scanners, you can ensure that you’re collecting only (or at least primarily) data that matters to you while disregarding irrelevant information. In some environments, it might make sense to deploy several scanners to get different views of your network or to gain visibility into otherwise heavily restricted network segments. You might also separate your scans into smaller targets to get results faster or to limit the chances of causing networkwide outages as a scanning side effect.

In addition, you must consider the broader operational environment you’re part of. Scans can be intrusive and in extreme cases cause system downtime, so you need to carefully introduce regular vulnerability scanning. Involve other teams in the process of determining appropriate targets and schedules so you’re not solely responsible if a scan goes wrong.

In the next chapter, you’ll learn how to collect and analyze the data your scanners produce. You’ll also be introduced to the automated methods for collection and analysis that you’ll build in the practical portion of this book.