Turn back the calendar to the early 1990s. The Internet is off the ground and running in universities. CERT is up and operational. The World Wide Web is more or less an experiment that is creeping into Gopher’s territory. Vendors are vehemently denying most security bugs, and Unix administrators are just beginning to feel the wrath of clever attackers. Internet security practices as we know them today are in their infancy, but the blueprints for modern day tool sets are being drawn up.

In 1992, a computer science student named Chris Klaus was experimenting with Internet security concepts. He created a scanning tool called Internet Security Scanner (ISS) that could be used to remotely probe Unix systems for a set of common vulnerabilities. In Chris’s words:

Although the cynic in me is inclined to ask what has changed since then (many of Chris’s observations still ring true today), ISS was one of the early, if not the first, remote vulnerability assessment scanners to be deployed en masse on the Internet. ISS looked for a few dozen common security holes and flagged them as issues to be resolved. Although a few people were nervous about the tool’s obvious power in the wrong hands, most administrators welcomed it with open arms.

A few years later, Dan Farmer (of COPS fame) and Wietse Venema (of TCP_Wrapper fame) authored a similar tool called SATAN (Security Administrator Tool for Analyzing Networks). SATAN essentially did the same thing as ISS, but had some advancements: a more mature scanning engine, a Web-based interface, and a wider assortment of checks. Unlike ISS, however, the pending release of SATAN became a media-crazed event. So hyped was its release that in April 1995 (the month it was officially released), Time magazine published an article on it and Dan Farmer. CERT even issued an advisory on its abilities (CA-1995-06). Many people feared that the release of SATAN would bring about total chaos on the Internet.

Obviously this was not the case, as SATAN’s release did little more than cause some extra traffic for a few days as people downloaded it, but this does show how the public’s attitude toward the Internet had changed in the intervening years. By 1995, commerce had begun in earnest and the real risk of monetary losses due to security became apparent.

Since then, the vulnerability assessment scene has continued to grow and mature. Today, there are more than a dozen scanners in circulation, each with its own set of strengths and weaknesses. The fundamental concepts, however, have not changed much since the early days of ISS and SATAN.

As you’ll see in both the Microsoft and Unix chapters, vulnerabilities come in many flavors. However, there are primarily two classifications for operating system vulnerabilities: ones that are local exposure points (host-level), and ones that are remote exposure points (remote-level).

In addressing remote exposure points, there are a number of methods one can use to approach the task of automated vulnerability scanning. For example, one approach might involve using a port-scanning tool such as Nmap, identifying the operating system, and then logging all the listening ports. The user would then be given a list of ports (21, 25, 53, 80, and so on) and an OS type (Linux Kernel 2.2). This approach has a few problems, however, as the user is left with a ton of data (port information) and no details as to what services are actually vulnerable. The user is simply given a blueprint of the system. Identifying what those listening services are, and whether they are vulnerable, is an exercise left to the user. For example, if my data set tells me that machine X is running the Linux 2.2 Kernel and has a service listening at port 21, I still have very little idea as to whether I am vulnerable to the any of the wu-ftpd buffer-overflow bugs. In fact, I don’t even know whether this particular system is running wu-ftpd—it might be running ProFTPd or glftpd, instead. So even when hunting down a single port, I still need to

Although this approach might be feasible for a dozen machines or so, it obviously won’t work in mid- to large-sized organizations where thousands of machines are present. The task at hand then moves from difficult to impossible.

A more practical approach would be to build on the previous model of port scanning and OS identification, and then add some mechanism to identify the listening service types and versions. You would then have another piece of the puzzle completed. Going back to the wu-ftpd buffer overflow example, by identifying the service version, you would now know

Let’s say that your service query process informs you that you are using wu-ftpd v2.4.2. This gets you even closer, as now you simply need to research whether wu-ftpd v2.4.2 has any known vulnerabilities.

The last remaining component to this process is research—knowing what versions of what services are vulnerable. In many ways, this ties into what attackers do: scan, query, research, and exploit. In this case, it turns out that wu-ftpd v2.4.2 is indeed vulnerable to a known attack type.

Based on the sheer number of known product vulnerabilities (estimated between 2,000–3,000 to date), creating a thorough system to properly identify and track all these product vulnerabilities is a fairly daunting task. The mining and managing of this vulnerability data presents the biggest challenge and the biggest argument for using an automated tool.

Although implementation details vary, based on these examples, you can deduce that there are a number of common components throughout most scanning approaches:

Some scanners will break this mold, but they are more often the exception than the rule.

Like any product-purchasing decision, before answering the question of which product is right, you first need to decide your specific requirements. For example, if plotting vulnerability-remediation progress over time is something you want automated, then a product’s capability to log and plot multiple scan sets is a feature you need to look for. If you have a large NetWare environment, you might want to make sure that the scanner has NetWare-specific checks. If you have to scan 50–100 hosts, efficiency might not be an issue. However, if you need to scan thousands at a time, you’ll want to make sure the scanner can scale to that range. Again, many of these issues are specific to what you’ll need your vulnerability scanner to do.

There are also some common areas of concern that all products need to address. A few of the issues that you will come into contact with in choosing a vulnerability scanner include the following:

No scanner that I know of has addressed all these issues well, but Nessus and Internet Security Scanner come pretty close.

Just about every security tool discussed in this book has had a set of fundamental problems, and vulnerability scanners are no different. Knowing their limitations is as important as knowing their strengths.

The major shortcomings of these products can be grouped into three categories: completeness, timeliness, and accuracy. First, reviews of these products have shown that many of them catch a fairly high number of known vulnerabilities, but none of them are equipped to identify all of them.

Second, none of these products can be completely up to date. From the time a new vulnerability becomes known, it takes time to incorporate it into the product and release a new version. Some products are released on an as needed basis, or a fixed regular schedule—some as long as once per quarter. If a vulnerability is announced in January, your scanner might not be equipped to detect that vulnerability until March. That leaves you with two months to fend for yourself when it comes to scanning. Now, your internal threat identification effort should be on top of this problem anyway, but the point is that these scanners should not be your primary method of defense when it comes to hunting down remotely exploitable exposures. When you really get down to the fundamentals, these products can do nothing that a well-informed security specialist can’t do manually.

Another problem is that most modern-day scanners are simply implementing “banner-grabbing” techniques to identify service versions. This technique is arguably sufficient for most environments; however, it can create some interesting scenarios. For example, by simply telnetting to port 25 (SMTP mail) and port 21 (FTP), you can identify versions of these two services.

Note that these two machines appear to be running Microsoft Exchange 5.5 and version 4.0 of the Microsoft FTP server. However, many services such as BIND, sendmail, and wu-ftpd are now allowing administrators to change these banners in their configuration files. Although this is not a security threat, changing a default wu-ftpd banner to “Fabio’s favorite FTP Server v1.0” will completely confuse most vulnerability scanning tools. The strange and disturbing moral of this story is that if you want your scanners to be effective, don’t change your default banners.

In addition to changed-banner confusion, some companies choose to run well-known services on ports other than the standard port (HTTP servers on port 8080, for example). This can cause some scanners to fail. Some address this issue and test the type of service running on each port rather than making assumptions about standards. If your organization uses nonstandard ports, be certain that the product you choose has this feature.

Finally, these products still struggle with false positives. Frequently on large and diverse networks, vulnerability scanners will misfire and report on vulnerabilities that simply do not exist. Although it’s better to be safe than sorry, this does create some overhead as personnel then have to run around trying to hunt down phantom vulnerabilities.

In an ideal world, technology-purchasing decisions would be backed by proper requirement gathering, proper testing, and realistic budgeting. However, I’ve grown to realize that people rarely have the luxury of doing things the right way. It is for this very reason that I’ve picked what I consider to be the top vulnerability scanners on the market today, and listed them here. This is not to say that the other products won’t do a sufficient job—these are just my personal favorites based on my field experiences and testing. I still encourage the reader to perform a thorough investigation when choosing a product to adopt, but the list of products in the following sections should get you started.

The following is a list of scanners that are up-and-coming (although this is not as comprehensive a list as the previous one). I encourage the reader to continue to monitor the progress of these products, and test them whenever possible.

Although vulnerability scanners are by no means an all-encompassing solution to identifying vulnerabilities and locking down systems, they can still be extremely valuable tools. As with any security tool, however, one should be aware of the weaknesses these tools exhibit. They are consistently behind when it comes to vulnerability announcements, they do not always report information accurately, they have false positives, and they are not exhaustive when it comes to the depth of their vulnerability data. Using a scanner in conjunction with a solid vulnerability identification effort and a solid set of system lockdown procedures, however, will result in a strong strategy for combating the overall problem.