Enterasys' Dragon Intrusion Detection 7.1

Setup is simple. It's based on the Zero G InstallAnywhere Java installer, which establishes the type of deployment, interface configuration and basic device settings. I used a standalone installation, and all management IPs were set to the lab network IP of the device. I used one of the on-board ports for a management interface and assigned it that address. A crossover cable connected one PCI port to my test client, which would serve as an attacker; the other PCI port was connected directly into the network.

InstallAnywhere was also used when I installed the management client onto another test server. Since the management client is Java, the installer provides its own JVM for the client, helping to reduce dependencies.For install, I connected through KVM, but you can also use a serial console connection for an easy remote deployment. Once the install is done, the appliance needs no more direct connections.

For the first trip out, I followed Dragon's tutorial, but after a quick walk-through, I was comfortable with the management client. Getting the appliance fully functional involves adding the sensor (by IP address), NetworkSensor, interfaces and a virtual sensor for those interfaces, and then applying the policies and signatures to the sensor. While that might seem like a laundry list, it's a well-documented, straightforward process.

For intrusion-prevention testing, I added an intrusion-prevention sensor to protect traffic between the two copper gigabit ports and enabled every signature on that device. Viewing events requires use of the Web interface, whose back end has been totally rewritten in Java.

To get as much data as I could, I left all signatures in Dragon's database enabled. Sure enough, firing up a Web browser on my test client immediately triggered events on the analysis station. Dragon's large signature database is both a strength and a weakness: Once it's carefully pruned and adjusted to an environment, it provides thorough protection, but until then, the deluge of alerts can be overwhelming.After observing the built-in signatures trigger, I created my own JW:JWIENS signature. The new management client, with its options laid out on a GUI form, makes signature creation much easier than it used to be, though some GUI fields still need simplification. I designed my signature to trigger on TCP connections destined to any Web server port, with the text jwiens. Thus, any Web requests for a file named jwiens should trigger the signature. Next, I applied that test signature library to my sensor, deployed the new configuration and verified it by surfing various URLs from the crossover client.

To block further exploits of the vicious JW:JWIENS attack, I entered the Event Prevention Settings tab under my virtual IPS (intrusion-prevention system) and enabled the prevent settings for that signature. Because Enterasys respects Dragon's users enough to provide full access to the appliance's Linux core, I could use the venerable tcpdump tool to monitor the expected behavior on the sensor itself.

Two Out of Three

Initially, I had trouble getting the IPS to block traffic. There are three main responses available under IPS settings: drop packets, send transport error and firewall block. The first two behaved as desired: Drop packets did the obvious, forcing the client connecting with the malicious URL to time out, while send transport error sent a TCP reset, which killed the session. However, the firewall block feature did not function at all. This option is supposed to use a built-in firewall to block all traffic from an attacking host, but it failed to stop any traffic. Enterasys engineers acknowledged the bug and have a fix that should be included in a 7.1.1 release.

Dragon's intrusion-prevention features are a good start. The flexibility of responses to any signature is important, but some additional responses would be useful. I wish the product would have let me do dynamic firewalling selectively--for example, block mail traffic but not Web requests from a virus-infected host.Although the intrusion-prevention capability is a major addition, the full list of new features, including pre-event collection (buffering data so traffic that occurred before a triggered event can be logged), the updated XML-based signature language and additional active responses, deserves credit for reviving Dragon.

Enterasys says the active response features (part of the vendor's "Dynamic Intrusion Response Solution") integrate with assorted network devices to locate the source of an event and take such varied actions as adjusting firewall rules and disabling a switch port--something I didn't test. These active response features are enabled through the use of NetSight ASM (Automated Security Manager), which currently speaks to Enterasys, Alcatel, Foundry Networks and some Cisco Systems network gear. Shortly after you read this, a new release is expected to expand Cisco support, and the subsequent release toward the end of the year will add a wizard-style discovery process to learning devices and topologies.

Forward and Back

For current customers, Enterasys makes backward compatibility a priority. The new Java back end for the Web interface doesn't alter the trending and forensics console, and the command-line forensic tools remain unchanged as well.

Any add-on tools or homegrown utilities should be easily adapted to the new code as the many ways of interfacing with the data and the server--such as raw file logs, SNMP traps and command-line management--remain open and available. Furthermore, Enterasys has added the ability to write custom signatures handling plug-ins, as well as direct access to the back-end database.Integrating IDS/IPS capabilities into release 7.1 of Dragon has helped Enterasys return this former Network Computing Editor's Choice winner to the top of its game. The complexity of the product and time required to tune the signatures might scare off some customers, but you'll find that putting in the effort will yield powerful results. Intruders had better watch out or they're likely to get burned.

Jordan Wiens is a network security engineer at the University of Florida. Write to him at [email protected].