IDS by NFR

The Reviewmeister is on the prowl for an intrusion detection system that can alert me to attacks, but not overwhelm me with false alarms.

This week, we look at an IDS product from NFR Security. NFR’s interface makes a huge distinction between alerting information and forensics. In the product’s attack signatures, the signature chooses when to send an alert, to actually record data to the database side, or when both are appropriate.

By default, NFR only displays 1,000 alerts. We adjusted that number up and discovered when it is set to 10,000 items, it takes 85 seconds to repaint the screen. Make it 20,000 items, and you’ll wait nearly 5 minutes for a refresh.

We discovered that when filtering alerts, you can’t ask the NFR product “show me all the alerts with a destination of this IP address.” You could get all the alerts for a particular time period and sort them by destination IP address, but you can’t trim the list of alerts down to just the set you want.

Next we turned to the issue of tuning. How easily and quickly could we trim the alert list of noise?

NFR’s event filtering worked at both the sensor level and at the GUI level. Sensor-level filters let you individually block data from the alerting or forensics part of NFR. Simply pick an event and define filters for it, applying it to individual sensors or to all sensors at once. It only took a single click to push changes to NFR sensors.

Not every network manager will want to write his own alerts, but we had a specific problem to solve. One worm that struck during our test was going to send traffic to some known hosts out on the Internet. We wanted to catch this traffic, put an alert on it and use that to help disinfect our network.

NFR provides a powerful development environment for its proprietary N-Code language. Clearly, any security manager who wants to write a lot of signatures will gravitate toward NFR’s tool kit. NFR has an array of policy-based signatures that trap traffic based on policy rather than attack detection. We used an out-of-the box policy-based signature first and then tried writing our own N-Code program. N-Code is powerful, but the existing policy-based signature was a lot easier.

Because our test network was intentionally behind on its patches, we knew the Microsoft RPC DCOM vulnerability would hit us hard. The question was who got hit?

With NFR, the key to any forensics investigation is figuring out what event you’re looking for. We knew from CERT’s advisory to look for PING traffic and dove into NFR. Our first guess, “ICMP Pingflood,” turned out to be wrong, but after a few seconds, we came up with “IP Hostscan.” NFR gave us the attacker IP addresses we needed, but little else. For example, we could not see what port numbers were being attacked, which might have been useful in other contexts. NFR’s GUI is also difficult in forensics mode: When you want to see the description for a particular event, you have to jump to another part of the GUI.

Summing up, if you think that writing signatures is going to be part of your application and if you’re looking for a combination of policy enforcement and security, NFR comes in a clear winner with its N-Code language.

For the full report, go to https://www.nwfusion.com/reviews/2003/1013idsrev.html