Testing intrusion-detection systems

When you buy a sports car, it's a no-brainer that you'll take it for a test drive to make sure you like the way it handles, the comfort level and its performance. And if you're like me, when purchasing a security product for your company, you show the same due diligence to make sure you're getting the performance you need.

My company recently tested and acquired a network-based intrusion-detection system (IDS). Over the past few months, I've received many e-mails from readers asking me to explain the performance-testing methodology I used, so I've decided to share how I tested our network-based IDS. (A network-based IDS server watches traffic destined for all host systems on a subnet, while a host-based IDS typically runs on each host system to be protected.)

Performance is only one possible criterion for choosing an IDS. Depending on the level of expertise of you and your staff and the amount of resources available, your requirements and testing criteria may be different from mine. You might focus on ease of use and strong reporting, ease of creating new attack signatures or price.

Performance Is Critical

Performance is critical to me because of the high amount of bandwidth our site must sustain. I can't afford to miss any potential events because of the performance limitations of the IDS infrastructure.

My definition of IDS performance is the ability for an IDS infrastructure to consistently detect x number of attacks within a given bandwidth utilization. The key word here is consistent. Words like usually, sometimes, typically and on average don't work for me. I have to know that at 3 a.m., while I'm tucked away in bed, my IDS is consistently analyzing every packet for signs of an attack.

Most IDSs look at each IP packet and determine whether it's part of an attack. IDS software can take many approaches to accomplish this, just as home burglar alarms have many ways to detect when someone has broken into your home. But I won't go into IDS software technology here.

The issue with performance is that with high levels of bandwidth, I want my IDS to continually and consistently look at every IP packet and respond accordingly. In my environment, I have no tolerance for an IDS missing, or dropping, packets that could be part of an attack.

To set up my tests, I started with a closed (not connected to the Internet), controlled environment in which to configure my IDS. After the configuration was complete, I launched a predictable attack against a specific resource on the network while injecting increasing amounts of network traffic.

If you do this, at some point, the IDS system will no longer be able to effectively and consistently detect the attacks. And that limit, measured in megabits per second, is what interests me. There are many ways to set up this test, but the basic elements consist of an attack generator, a victim system, a packet/traffic generator and the IDS to be tested.

I don't have room to go into the configuration details, but here's how I set up the testing. To start, I needed to have a consistent stimulus for the test to be effective and defendable, so I could use the results for purposes of resource allocation, justification and other budgetary requests.

There are a few things to consider when setting up a test. First, your network traffic generator should be configured to generate a mix of traffic comparable to your network's general level of activity. For my testing, I used a combination of HTTP, Telnet and Internet Control Message Protocol packets. The best way to do this is to take a sample of your network traffic and configure your packet generator accordingly.

Generating Attacks

The next issue is generating the attacks. I picked eight different attacks and scripted them so that when I typed "go 10.34.45.128," my system would launch the attacks against the IP address submitted at the command line.

I built a Linux system just for this purpose. When choosing the attacks, make sure you pick several types, as I did. (Choosing eight port scans or denial-of-service attacks doesn't make for a legitimate testing environment.) I then configured a Solaris Web server with an IP address of 10.34.45.128 as my victim.

For the IDS setup, I chose a policy that's similar to the configuration I use in my production environment. If I had configured the IDS to watch only for the eight attacks I scripted, it wouldn't have been a fair test. I started with no network traffic and launched the attacks against the victim system. That was the litmus test, and any good IDS should be able to detect such attacks. I did this three times as a baseline.

Then I increased the network traffic in 3M to 5M bit/sec. increments and repeated the test, launching each attack three times at each traffic level. I did this until the IDS was no longer consistently responding to the attacks. It was that simple.

If your testing is successful, you should be able to determine at what level your IDS will start dropping packets. In my test case, I was looking for performance in excess of 15M bit/sec., as that seems to be my company's average aggregate bandwidth.

We are using RealSecure from Atlanta-based Internet Security Systems Inc. We based our selection on performance, previous experience and the need to get a system up and running very quickly. Another surprisingly well-performing IDS is Dragon Sensor by Rochester, N.H.-based Enterasys Networks.

With the information you collect from your IDS testing, you can also decide how you want to design your IDS infrastructure. To overcome IDS bandwidth limitations, there are ways to implement load balancing or segregation of your network to make the best use of the discovered IDS limitations.

At the end of the day, you want to ensure that when something goes bump in the night, your IDS will respond accordingly.

Security Bookshelf

Hacking Linux Exposed: Linux Security Secrets & Solutions, by Brian Hatch, James Lee and George Kurtz (McGraw-Hill, 2001). I read security books as reference materials, and this book is an awesome reference. Although the authors' primary focus is Linux, many of the terms, techniques, tools and discussions apply across all aspects of information security.