UnityOne's Network Defense System (NDS) performs intrusion detection, traffic blocking and alerting before traffic gets to the firewall. Tuning itself to the network, it identifies protected devices and services, and reduces the number of meaningless alerts common in other IDSs (intrusion-detection systems). Unfortunately, the product missed some key servers in my tests (see sidebar, "False-Positive Reduction.").

Ready, Set, Action

The IDS component is the heart of UnityOne. It groups signatures into attack categories -- absolute, standard and policy -- and assigns attacks a severity level -- from critical to informational -- to apply an action to an attack. Absolute attacks -- those with no possible false positives -- can be identified and blocked. Standard attacks are suspicious but may be caused by normal activity, so packets that trigger this alert can be captured and checked later or passed on accompanied by an alert. Policy attacks -- violations of best practices -- can be assigned a variety of actions. Per-packet processing takes less than 1 ms from NIC to NIC.

Each filter also has configurable actions. Administrators can be e-mailed, paged or sent SMS (Short Message Server) notifications that include a brief description of the event and a URL to the CERT advisory. Unfortunately, the URL is not a live link. Also, I'd appreciate links to the Bugtraq ID and CVE (Common Vulnerabilities and Exposures) entry.

Bottom line: When using UnityOne, make every attempt to validate the rule sets to ensure your traffic is not affected. Also, though UnityOne can be helpful, you should use it only as augmentation to a properly configured firewall and server patch-management system.

False-Positive Reduction

Event alerts can overwhelm even the most seasoned administrator installing a network IDS. TippingPoint provides automated event management by reducing the number of alerts based on what it knows about the existing network.

UnityOne uses network discovery, a combination of port scans and Nmap -- like OS identification to identify the servers and services that it is protecting. After it has identified open TCP ports, the NDS attempts to determine what service is running on the port using modified NESSUS code. UnityOne uses this information to alert on only the most relevant events. For example, if the only services available to the Internet are Apache Web servers, Bind DNS servers and Sendmail MTAs, UnityOne will log all the events but only alert on attacks to those services. The effect is to show only what is interesting to the administrator, reducing incidents of false positives.

There were some issues with the network discovery -- UnityOne only detected 37 hosts on our network when a similar scan using Nmap produced 57 hosts. The results of the scans were accurate in terms of assessing the OS as Nmap, however.

Also, the NDS identified our Cisco router as a Windows XP computer, but changing the identification was simple. This problem should be cleared up in the final release of UnityOne.

Slow Going Because of Beta Bug

TippingPoint claims each UnityOne 2000 can process up to 2 Gbps; however, when I used Caw Networks' Avalanche to generate HTTP requests and Caw Reflector to act as a Web farm, my results were far lower. My infrastructure sustained 20,000 sessions per second and about 950,000 concurrent TCP sessions at less than 200 Mbps.

The NDS started dropping sessions long before reaching those numbers. I called TippingPoint engineers for assistance and they discovered that much of the traffic was hitting a trigger that matched "file=" on the string "Profile=" in the HTTP GET request. That caused the NDS to inspect that traffic more thoroughly, negatively impacting performance.