Information Security

Defending the digital infrastructure


Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Vulnerability scanners: Not the best tools for network perimeter defense

Vulnerability scanners prove mediocre tools for helping IDSes protect the network perimeter.

To test the value of our five vulnerability analyzers as practical tools for systems managers, we turned them to the very real-world task of tuning our Sourcefire network IDS. We looked at three ways in which we wanted to use VA results to make our IDS more useful. We got mixed results, reflecting the weaknesses the VA tools demonstrated throughout our testing.

  1. Nonstandard ports. Sourcefire can look for Web server attacks on any TCP port, but is initially configured with the most common ones--80, 8000 and 8080. Knowing where we have Web servers running would give us a chance to act on alerts before a vulnerable server caused serious problems.

    It wasn't very easy collecting a list of ports on which our Web servers were running, since our VA tools sort reports either by vulnerability or by host. Only Retina and Nessus found servers on nonstandard ports, so we ran a simple Perl script against their reports written to summarize the Web server results. If we were in a production environment, we would have dumped the events into a database.

    In the real world, we could apply that solution to other kinds of servers, such as e-mail and database, to extend the coverage of our IDS.


  2. Identifying Web servers. Because we had a little of virtually everything on our network, knowing who was running IIS and who had Apache was extremely valuable. Since the majority of attacks are crafted against those two, we broke our network down into three areas--IIS, Apache and everything else. Once again, the reporting structures didn't give us exactly what we wanted, so we wrote our own vulnerability test to simply tag a server as IIS, Apache or "other." SAINT, Nessus and Retina made this easy, with their robust tools for creating custom tests. You can't create custom tests with NetRecon, and it was too difficult with Internet Scanner to be worth the effort.

    Actually, ISS's answer to our problem might be to buy their own RealSecure IDS, which can be linked with another ISS product, SiteProtector, to integrate vulnerability analysis and intrusion detection by feeding information from Internet Scanner to the network IDS.


  3. Matching alerts to vulnerabilities. The ultimate in fine-tuning an IDS is the ability to match specific alerts with specific vulnerabilities. For example, if version 2.1 of a particular CGI script was vulnerable to a problem, we wanted to use VA results to enable or disable the IDS alert based on version information.

    Our results were less than satisfying. Although we found that we could manually track at least some of our IDS alerts to software packages to version information to vulnerabilities, the job was difficult and time-consuming. For example, we picked an IDS alert, then had to see what package caused the alert--not too hard. Version number information wasn't so easy, but most IDS alerts are linked to the MITRE CVE database, which assigns a unique identifier to each problem and often has pointers to additional information. The only problem is that vulnerability analyzers don't list their vulnerabilities by CVE number.

    So we went to Plan B, using the results from the VAs as a filter after the IDS alert had occurred. Before bothering a system manager with an IDS alert, we would use the VA tool to discover what it could about the system or software involved.

    In this case, we weren't so much "tuning" the IDS as filtering or post-processing its output.

    This was a little more successful, but still difficult. You would never want to undertake that kind of correlation without dumping your VA results into a database, both to speed the lookup and because you would want to reorganize the data slightly.

The problem with vulnerability scanners that put their own results in a database is that the schemas weren't particularly helpful for this task. They have no specific field, for example, that stores the name of a software package separately from the version number or the CVE vulnerability number.

The bottom line is that matching vulnerabilities and IDS alerts is possible, and can help enormously in the tuning process. However, unless you have the time and budget to write your own software tools, you'd probably want to turn to third-party products, such as Lightning Console from Tenable Security rather than rolling your own. The alternative is buying an IDS with built-in links to the vendor's own vulnerability analyzer.

About the author:
Joel Snyder is a senior partner at Opus One, an IT consulting firm in Tucson.

Article 3 of 14
This was last published in March 2003

Dig Deeper on Risk assessments, metrics and frameworks

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More Information Security

Access to all of our back issues View All