Security /

How we did it

By
Network World, 10/08/01

The testing was done at Miercom's lab in Princeton Junction, N.J., in July and August 2001. We created a test network consisting of two attackers running Debian Linux (unstable release) and Windows 2000 respectively, and three victims, running Debian Linux, Windows NT Server 4.0 with Service Pack 6a, and Win 2000 with Service Pack 1. We also used five PCs running NetIQ's Chariot software for generating background traffic. Four PCs were configured as endpoints, and one was configured as our Chariot console. We used a laptop running Ethereal (open-source code from www.ethereal.com) for troubleshooting, and when necessary, a PC running Win 2000 with Service Pack 1 for the console software and a Compaq ML370 Server running Win 2000 with Service Pack 1 for the IDS Sensor. For connectivity, we used three Extreme Summit 48 Fast Ethernet switches. We mirrored the crossover port on the first switch and all three victims on the second switch.

Intrusion battleground evolves
Review: IDS products grow up
NetResults
Interactive Buyer's Guide

We connected two of our switches together using a crossover cable. Our Win 2000 attacker was connected to the first switch, and our Linux attacker was connected to the same switch through a Linux router. All three victims were connected to the second switch. Then we connected two Chariot end points to each switch. Next, we connected the IDS Sensor to the mirrored port on the first switch and our laptop to the mirrored port on the second switch. The management interface on the IDS sensor and the IDS console were connected to a third switch for out-of-band management.

First, we measured the ability of each IDS to detect a variety of attacks and probes, including denial-of-service attacks, port scans and Trojan horse connections. We attempted 27 "intrusions" and recorded the total number each IDS was able to properly detect and identify. Then we used Chariot to generate background HTTP traffic at speeds of 40M-, 60M-, and 90M bit/sec and reran the attacks to see how each product would successfully identify the attacks under those traffic loads. The 40M bit/sec streams averaged 9,700 packet/sec, the 60M bit/sec streams averaged 14,200 packet/sec, and the 90M bit/sec streams averaged 67,000 packet/sec.

Our last series of tests were designed to determine how well each product could detect intrusions employing various IDS evasion techniques, such as Unicode scripts, blinding and fragmentation. For our fragmentation tests, we used our Linux router running Fragrouter in an "out of order" configuration.

Our IDS console platform was a PC running Win 2000 with Service Pack 1 on an Intel Pentium III 500-MHz processor and 256M bytes of RAM. When necessary, we supplied a Compaq ProLiant ML370 server with dual Intel Pentium III 866-MHz processors and 1G byte of RAM for the IDS sensors. Additionally, when necessary, vendors supplied their own server for event collection.