Network Computingwww.networkcomputing.com

	Issue TOC Print full article Print this page E-Mail this URL Discuss this article Flame the author     In this article Introduction Test Data Product Requirements Test Environments

We are interested in testing products that detect and prevent network attacks. The focus of this review is products that are installed in-line with the network, don't require network address changes and use signatures to detect attacks. Anomaly detection may be acceptable. However, we are not testing systems that detect attacks or suspicious traffic based solely on statistical traffic analysis. Also, we are not interested in IDS systems where the sole mechanism to block traffic is adding rules to an external firewall.

We will be testing the products on a testbed (see Proposed Test Network Map) as well as placing each product on a live network (see Live Network Map). On the testbed, we will be rating the ability of the products to detect attacks using known tools gathered from sites like SecurityFocus and PacketStorm as well as attacks that have been manipulated in an attempt to evade detection. We will test vulnerabilities in the SANS Top 20 as well as current exploits. We will be testing against common vulnerable services, such as IIS, Apache, SendMail, Oracle SQL*Net, telnet and SSH, along with other enterpriseclass applications.

We will test the ability of the product to detect and prevent the attacks with no other traffic flowing, and we will test the ability of the product to detect and prevent the attacks while under load. We will be using Antara.net Flamethrower to generate a mix of HTTP, SMTP, FTP and POP3 bi-directional traffic. While background traffic is flowing, attacks will be launched. We will use Network Associates' EG2S Distributed Sniffer to determine if attacks successfully passed through the device under test.

For live network testing, we will place one NIPS in front of our firewall at the Syracuse University Real-World Labs(R), which has a Fast Ethernet connection to the university backbone, and we will place one device in front of the firewall at NWC Inc. in Green Bay, Wis.; NWC Inc.'s firewall is connected to the Internet via a 1.5-Mbps DSL circuit. We will enable intrusion prevention on each device for common protocols that we allow through our firewalls, like HTTP, SMTP and POP3.

We will also examine the user interface, including the reporting system, the management system and the ability to tune the IDS to selected targets. We will ask for list pricing for the device under test and the management station, along with any related signature subscription costs.