A time-honored approach is banner grabbing and fingerprinting—for example, to note that FooServer 8.2.34 has a nasty problem and that patched versions now have a banner of FooServer 8.2.36. This approach has a number of advantages: it is fast, is unlikely to have an impact on the stability of the scanned system, and does not require high levels of access to run the check. The obvious problem is that a user might decide to change the banner, for example, from FooServer 8.2.34 to Go away or I shall taunt you a second time. In such a case, your test wouldn’t be able to determine whether the system is really vulnerable. It probably wouldn’t even notice that a FooServer service was running.

The banner grabbing and fingerprinting approach also has an advantage for the scanner vendor in some cases. One example is Sendmail, which has had a lot of problems over the years. The Sendmail banner normally states the version. Manually running a check for each problem that could historically be present is time-consuming for everyone. It slows down your scan, slows down the development process, and creates a lot of work for the testers. As a problem ages, the relevance of the check declines, and checking banners might be good enough.

Some purists think that exploiting the vulnerability is the only valid scanning approach. It does have the advantage of typically not giving false positives. If the system mailed you /etc/passwd or logged you on as administrator, you would have little doubt as to whether you’d found a problem. For some problems, exploiting the vulnerability—such as guessing passwords to find a weak one—is the only approach that works.

If the attack is complicated and requires some understanding of the system, running the exploit could be difficult. In these cases, you might have to investigate some preconditions. A worse problem comes into play when a buffer overrun is involved—the exploit frequently causes the scanned service, and potentially the entire system, to become unstable. Even momentary service outages are not acceptable on a production network. Claiming that "You should be glad we found the vulnerability before the bad guys did!" only works some of the time. More often, the people running the network will conclude that the cure is worse than the disease—a scanner that is known to cause problems is more of an immediate threat than a real attacker getting into your network. Even if the exploit is relatively clean, it will almost certainly vary according to the service pack, language, and type of processor. Another benefit of the exploitation approach is that the scanner will find whether someone has reintroduced a problem. We were astonished one day when a brand-new UNIX system showed up vulnerable to a problem fixed several years ago.

Depending on the details of a specific issue, false negatives can also be a significant problem when attempting to run actual exploits. The exploit itself might be very fragile or depend on version-specific offsets within the code. A final drawback is that real-world exploits sometimes leave things laying around on the file system.

People often claim that "proof of concept" code is a benefit to system administrators and security professionals. Experience has shown this has rarely been the case. Exploits that are released to the Internet are usually of poor quality. You can also run into code where someone has put a Trojan into the exploit. As always, it is best to run code written by people you trust. If you do end up needing to run code from an unknown source, run it in an isolated environment to minimize the danger of Trojans.

Checks can be written to leverage the fact that developers often fix more than one problem in a patch. For example, in Microsoft Security Bulletin MS02-018, "Cumulative Patch for Internet Information Services (Q319733)," a number of problems were fixed, including some very serious buffer overruns. Running the actual exploit resulted in an unstable system, including hangs. However, the same patch fixed a cross-site scripting problem that was easy to detect. There was no way to patch the system for one bug and not the other. It also had the advantage of not setting off intrusion detection sensors, because the traffic used to detect the problem did not appear to be an attack.

One approach that often works is to run a variant of the exploit. For example, one vulnerability in Microsoft Internet Information Services (IIS) 4.0 and IIS 5.0 (bulletin MS00-031, located at http://www.microsoft.com/technet/security/Bulletin/MS00-031.mspx) allowed an input exceeding 260 characters to cause an overflow. In the patched version, an input greater than 255 characters caused an error message. There was a window of 5 characters in which the vulnerable version responded differently from the patched version, and neither version blew up in that range.

One scanning approach is to take a packet trace of a protocol or an exploit that you don’t understand, and then replay it. This is a somewhat common approach in the attacker community: take a trace of a transaction, modify some fields until you get the server to blow up, and then hone it until you have an exploit. In cases in which you work with undocumented or proprietary protocols, you can’t use any other approach. I’ve worked with a number of checks written this way, and none of them were stable. Minor differences in the protocol can result in false negatives and false positives. Of the four scanning approaches detailed thus far, replaying network sniffs most frequently leads to problems. It takes only very minor variations in the network traffic to cause this approach to fail.

Detecting patches is sometimes your best bet at finding a vulnerability or potential vulnerability. For client-side issues, such as problems in mail readers or Web browsers, the application doesn’t normally listen on the network and there is no way to actively probe it using a scanner. Other techniques do exist, such as provoking a user to visit a particular website, but you can’t easily put them in an automated vulnerability scanner.

In conclusion, writing vulnerability checks (as opposed to exploits, which takes far less skill) is a difficult specialty, and sometimes you end up choosing from the lesser of the evils. You might get to choose between an approach with a high false negative rate; a zero false positive rate; and one with few false negatives but significant false positives, because it is based on a low-confidence approach. All the approaches described work well for some types of vulnerability and not at all for others.

More checks are always better, right? Well, sort of. Most scanners are marketed as having a check for nearly anything you can think of. The Internet Security Systems’ Internet Scanner went from 140 checks in the 4.0 version to over 700 in version 5.6. Some checks are more important than others—a check that finds a remote system-level vulnerability is worth more than several configuration checks. For example, the Microsoft Windows NT line of operating systems (which includes up to Microsoft Windows Server 2003) has seven categories of security events to audit. You can audit success and failure. That makes 14 checks! Some of these are rarely audited because your event log will get very large very quickly, but some customer somewhere might have a policy that one type of event must be audited, so for completeness (and to make Marketing happy), we checked for all of them.

There are also different ways to count these checks. One scanner might find a really old version of Sendmail and count that as one check. It not only tells you that it found an antique version of Sendmail, but also that it is vulnerable to dozens of horrible things, and you should turn it off or upgrade it right away, or better yet flatten the system to get the existing attacker population out. Another scanner might find that old Sendmail and flag six different vulnerabilities. The cure for all of them is exactly the same. Six checks, one work item. Both vendors will claim their way is better.

The biggest problem for you is figuring out which of the 1000 or so checks is really important for your network. Doing a little homework and looking for which checks are most recent can be helpful here. You will also want to get a scanner that is the most up-to-date regarding the type of operating system that you have on your network. Historically, different scanner teams have different levels of ability to build checks for different systems. One scanner might be best for the Windows operating system, another for UNIX or Linux, and still others for specific applications. Scanners exist for security problems in SQL servers, for every major Web server, and even for cross-site scripting bugs. One company could have a great general scanner but a rotten Web server scanner, so spend some time evaluating all the different products. One-stop shopping might not be in your best interest. Decide what’s important to you, try them out, and then buy what you need.

Attempting to compare two scanners check by check is difficult, but scanners that support the Common Vulnerabilities and Exposures (CVE) list, found at http://cve.mitre.org, can be more easily compared. You still might find differences in terminology from one scanner to the next, because the same problem has a different tag name.

As with checks, faster is better. Fairly simple? Like vulnerability checks, this isn’t always the case. The first problem you might hit is that a scanner running too fast can saturate a network, just as a port scanner or ping sweeper can. When doing a trial run of a scanner, bring up a network monitor (it is best to do this on another system or at the switch) and see just how much of a load it imposes on the network. You also don’t want a scanner that trades accuracy for speed.

Sheer network bandwidth isn’t always the whole problem. Say you want to find Telnet servers with weak passwords. You have a nice long list of user name–password pairs you want to run through as fast as you can. You have each check create 32 sockets, each of which makes an independent Telnet session to the host, and then try a user name–password pair. As long as you’re scanning a system that can handle this many simultaneous clients, you’re in great shape. If you happen to hit a telephony device that isn’t as robust, doesn’t have a lot of CPU, and didn’t limit the number of connections, you just created a denial of service attack from the password checker. Although you will certainly spend a lot of time tweaking in the beginning, a scanner that is extremely configurable is helpful at running scans as quickly as possible without breaking things.

Like any other software, you want a scanner that does the job correctly, without failing, and scales to the size of your network. Scanners have a problem unique to any other software: they have to deal with every type of server imaginable, and you can run into situations in which a server did something the scanner programmer just did not expect. Scanners use three basic approaches to doing things in parallel. The first is to have one thread conduct all the checks on one host. This has two drawbacks: if a check blows up, you don’t check anything else on that host; and if a check hangs, you end up with the same problem. The second approach is to have one thread perform the same check on all the hosts. If this aborts, you lose that check on the remaining hosts, unless they’ve implemented a restart capability. The third and most sophisticated approach is to have the minimum work unit be one check on one host. Now if something goes wrong, you lose one check on only one host. Either way, you need the scanner to tell you that something went wrong on this host. You should report the problem to the vendor’s technical support with as many details as possible so that the problem can be fixed. Technical support might ask you to provide portions of the scan logs to provide debugging information.

Scalability can be limited by three different factors. The first is sheer scanning speed. If you need to scan 500,000 hosts once every week, and you can scan only 2000 hosts per hour, you’re not going to make it using one scanning system. Speed is also a function of how much work you’re doing per host—you might need to create different configurations to get the scan rates you need. The second limiting factor is the scanner itself. If the scanner has a nice, flashy GUI that keeps track of everything it finds in real time, it could eat more and more memory as it works its way further into the network. There will be a limit on the number of hosts you can scan in a single pass. If you don’t have a large network, this might not be a problem for you. Many scanners overcome this by offering a command-line version for larger networks, or by distributing the load among several scanners. The third factor is scalability, which can be limited by the way a scanner deals with hung checks. Most scanners have a fixed size pool of workers, and every time one hangs, it runs with less horsepower. If hangs occur frequently, you can get to the point where very few worker threads exist and you need to restart your scan. A really good scanner will build in the ability to maintain a stable pool of workers.

An ideal scanner will never fail, but you’re not likely to be able to buy one of these. You will have a hard time evaluating whether a scanner is accurate, though false positives will show up over time—you’ll ask someone to fix something, and he’ll report that it has already been fixed. False negatives are a more difficult problem—you’ll find these only by running a scanner that uses a different technique, or implementation of the same check, or in the worst case, when your system gets hacked because of something you checked for. Even in the case of trying different scanners, you might find that determining which result is correct is difficult. In the simple case, one scanner is broken and the other works, but networks are rarely simple. You could have a situation where both work most of the time, but they are subtly broken in different ways, and this shows up on different types of hosts. If you get conflicting results, test the systems manually or check for patch compliance.

The accuracy of a check can also be about more than whether the check works. One problem with purely binary scan results is that they don’t give you enough information. There are more possibilities than whether a system is vulnerable—it could be vulnerable, definitely not vulnerable, or level of vulnerability unknown. The nature of the check could account for variations. Checks can have as many as several different returns. For example, say you had a policy that says that FooServer isn’t allowed to run on your network, and if FooServer has a weak password, the administrator is subject to public humiliation. A check that covers your needs would report three possible outcomes: weak password; server not running; and server running, but the password is OK.

This information also comes in handy in other circumstances. Consider one system with two IIS servers: one is running and fully patched, and the other isn’t patched and isn’t running. The second system is OK until someone comes along and turns on the Web server. If the scanner tells you the difference between the two, you have better information to go on.

Most scanners built recently have modular updates available. In general, the more often the updates are available, the better. You especially want to see a company that releases new checks as soon as possible after a new vulnerability is known. The period of time between a new exploit being available and your ability to check for whether a host is vulnerable should obviously be minimized.

That said, downloading the latest check to find out that it doesn’t work properly is not fun. Finding out that the check has gone through three versions in four days is not comforting either. In the worst-case scenario, the new check causes a denial of service, and in your excitement, you didn’t test it on a limited portion of the network first.

Lastly, many scanners offer some limited ability to build your own checks and run them within their overall scanning engines. Most customers want this, but a small percentage actually use it. If you’re good at programming and want to be able to do custom checks, see whether a scanner is extensible. You can also write your own checks to fill in the gaps until the vendor releases an official version.

Reporting is one of the most important aspects of a scanner. It doesn’t do you much good to find problems if you can’t tell people how to fix them. When a scanner finds a problem, it needs to give you a clear description of the issue and how to fix it, and where you can find the patch. You also need reports that provide information at many levels. The 1500-page tome providing full details about several hundred servers is nice for those of us who want to know, but the management teams of the world want reports, too. They want metrics, and run around saying things like "If you can’t measure it, you can’t manage it." You need roll-up reports with nice pie graphs so that those bosses can understand just why they need to spend all this time and money scanning systems.

Seriously, a good reporting system is a very important feature. One problem you’ll immediately notice is that firing up the scanner and finding 1000 things to fix is really quite easy, but getting someone to fix all those problems is not. The better the reporting system is, the more easily you will track progress (or lack thereof). You want an application that can put the information into a database so that you can track how long it takes systems across the network to get fixed. Another issue to track includes whether someone is putting up new systems that are vulnerable. One of the most interesting situations occurs when a system that was not vulnerable during its last scan starts showing up as vulnerable in subsequent scans. The most likely explanation is that someone rebuilt the system and didn’t reapply the patches.

A host-based scanner requires software to be installed on every system being scanned. As you might imagine, installing software on every system on your network is no trivial task. In some cases, the administrators will strongly resist having any additional software on the server, because they are using all the available CPU or memory and would prefer not to have more software consume resources and potentially make systems unstable. Host-based scanners also tend to get expensive, in part because many different operating systems and versions must be supported by the vendor to give you good coverage. Another potential downside of a host-based scanner is that an attacker can disable it.

Host-based scanners do have several advantages, the most important being that they can handle tasks that can’t be accomplished easily across a network. Although the Windows operating system has a well-defined and consistent set of interfaces that allow you to do almost anything to a system across a network, there are times when you might not want to make these interfaces available. When you are dealing with heterogeneous networks, you won’t get the same level of information across the network for all your hosts. A host-based scanner can be a good solution, especially if it is configured to push results out to a collector.

Some types of checks really shouldn’t be conducted across a network. Although you could create cryptographic hashes to verify file versions for an entire disk volume across the network, this is a really bad method, and this check should be conducted locally. There are other examples where an entire file system needs to be searched, or perhaps all the event logs should be checked for a particular type of event. You can also fairly easily combine a host-based scanner with a host-based intrusion detection and/or tamper detection system.

To have additional sources of information, you might eventually be forced to use host-based scanners or to require network scanners to gather lists of hosts from other sources, such as DNS or DHCP servers. As long as you’re running IPv4, a network scanner can try every IP address in a range fairly easily. When you go to IPv6, just the host portion of the IP address consumes 64 bits, and sweeping networks is no longer feasible. In addition, whether you’re running IPv6 or IPv4, if a host is running a personal firewall, you might not even be able to find it with a network-based scanner.

A network-based scanner does not depend on an agent being placed on every system, and it is much easier to deploy. You simply install it on one or more scanning systems and start scanning. The results of your scans are kept (you hope) in a very safe place, not scattered all over the network. The per-host cost of a network-based scanner is typically significantly less than for a host-based scanner. If you are primarily concerned with Windows networks and have administrator-level privileges, you can implement all but a very few checks using a network-based scanner, plus a few more that wouldn’t work well across the network.

The obvious downside of a network-based scanner is that if people turn off network interfaces, you will not get any results. This situation might be acceptable if your primary concern is network-based attacks, but in some cases your only hope of accurately detecting a vulnerability is to check whether patches have been applied.

Scanners, especially network-based scanners, deal with the law of large numbers. If you scan enough systems, something will go wrong. Even if something doesn’t really go wrong, you might get blamed. Here are some anecdotes about things that can happen.

One user unpacked a nice, new scanner, and decided to give it a test spin. This user didn’t bother to alert anyone that he was running the scanner, and he thought it would be a good idea to turn on all the denial of service checks. As you might well imagine, things started blowing up all over the place. Before anyone could figure out just who was causing the mayhem, significant portions of the network were malfunctioning. The company who owned the network wasn’t very happy, the consultant probably didn’t enjoy being chewed out or needing to find a new job, and the scanner vendor didn’t appreciate being blamed for irresponsible use of their product.

OK, so you’d never be that dumb, but many other seemingly benign scans can cause a fair bit of trouble. Several years ago, a certain manufacturer of networked printer cards had a fragile IP stack. It listened on two ports with close to the same numbers. If a port scan managed to connect to both ports at very close to the same time, the printer card hung until the printer was turned off and on. Although it didn’t cripple networks, everyone was annoyed at having a scan bring down all the printers.

Even a ping sweep can cause problems. One site that had a large piece of critical automated equipment also had a network interface so sensitive that pinging it while running caused it to malfunction. Once the problem was found, the scanner operator warned the owner of the equipment, who would take it off the network during scans.

Scanners also find legitimate problems. Someone used a cheap PC as a router and firewall and decided to use two 100-Mb network cards and one 10-Mb card. It turned out that the drivers for that particular operating system and network card were unstable when all the interfaces weren’t the same speed. The system had been experiencing intermittent failures, but the system would nearly always blow up when scanned—the scanner put just enough load on it in just the right way to cause it to fall over. You really can’t blame the scanner. The system was failing at random intervals without being scanned, and we did them a favor by making the problem reproducible.

Here’s what you do to avoid at least some of these problems: test any scanner on a small subset of the environment, and make sure the network operators are well aware of what you’re doing. Never, ever make your first scan a surprise. Start with the safer checks, such as port scans and information gathering. Move up to the more intensive, riskier scans later. Try to avoid running denial of service scans that actually launch real attacks. Until you’re sure it is safe, do not leave a scanner unattended. It might be boring to watch it run, but if someone starts yelling that the network has caught fire and burned, you better be ready to shut down. The biggest point to remember is that you’re dealing with a potentially dangerous tool, so treat it with respect.