Full text

Network-Based IDS

A low-frequency hum of routers and workstations permeated our lab as we launched an array of attacks against the targeted hosts. Surrounded by Unix workstations, Windows NT servers, Windows95 clients, routers, switches, firewalls and approximately $100,000 worth of Intrusion detection systems (IDS), we pounded away at our objective. Scanning, poking, prodding, exploiting...we pounded and pounded and pounded.

And while we saturated links, created thousands of sessions and blasted segments until the hubs red-lined, our IDSes kept on chugging. They endured almost everything we threw their way, carefully watching, inspecting and discarding every packet. Unfortunately, they also blithely inspected, discarded and overlooked the attack that remotely ripped the NT SAM database, containing all of the domain's user names and passwords, right out from under their noses.

Real Time, Real Threats The threat of intrusion is real. Hacker penetrations have moved out of folklore status and into the mainstream. Sorting through the glossy marketing literature, it's easy to believe that without intrusion detection, your network is being lead to the slaughterhouse. After our testing, we're convinced you may be heading there anyway.

Current IDS implementations are not the final answer to the threat of intrusion. They do not stop hackers dead in their tracks, and they certainly don't offer an all-encompassing security solution. IDSes aren't perfect-in fact, they're a long way from being polished. However, IDS technology can put an administrator in touch with what's going down on the network from a security perspective in real time. Giving administrators the tools to see in areas where they were previously blind is invaluable. IDSes can be a significant asset in the administrator's repertoire, and their place in the enterprise is quickly becoming apparent.

As in many of our security product tests, in the end we determined we had an assortment of useful products that would have made for a remarkable solution if we somehow could have combined pieces of each into one package. Cisco Systems' NetRanger is quite the robust workhorse, and it has a strong set of attack signatures. AXENT Technologies' ID-Trak is by far the easiest to customize, and offers a simple solution to specific problems. Network Flight Recorders' NFR Intrusion Detection Appliance has a wonderful back end with a mighty scripting language. But when all is said and done, ISS' RealSecure gets our Editors' Choice award; it's the most useful and mature IDS out of the box.

Packet Sniffer on Steroids? At the root of IDSes is the concept of identifying a particular attack method. While there is an endless number of possible sequences, the raw building blocks of most assaults are based on smaller components or "exploits." Building on internal databases of such exploits and patterns, IDS vendors create what are referred to as attack signatures. Using these defined signatures while inspecting real-time network traffic, IDSes try to analyze sets of packets for a signature match.

IDSes typically employ two basic components: sensors and back-end management stations. The sensor or "watcher" module is responsible for grabbing (essentially sniffing) the network traffic and inspecting it, while the back end handles the logging of attacks and the issuance of any alarms or countermeasures.

Although this combination allows for a fairly painless deployment strategy, the network-based model of intrusion detection faces two fundamental challenges. First, the sensor has to see the packets before it can inspect them. This makes monitoring switched or high-bandwidth environments a little tricky. Currently, the only option for switched networks is to span the switch port to which the IDS is attached, duplicating all of the switch's traffic on a single interface. If you are pushing 100 Mbps of traffic through a multigigabit switch, you're out of luck-you simply aren't going to see everything.

This is less of an issue for anyone who uses IDSes on their perimeterfew organizations come anywhere close to 100 Mbps externally. However, internal networks frequently hit 100 Mbps and beyond. This presents a problem for network-based IDSes, as none can accurately keep up at these speeds. Because of this, and the fact that current deployments are still primarily used at the perimeter, the bulk of our testing was based on a 10-Mbps environment.

Second, most network-centric intrusion detection implementations base the bulk of their usefulness on known attack signatures. As new attacks arise, the IDS may or may not detect the attack. No IDS vendor has any sort of push technology in place to update its signature database. The best we can hope for is a timely software update. But vendors aren't shipping upgrades more then a few times a year. Much like the state of your virus scanner when a new virus hits the street, your IDS will likely miss the cutting-edge attacks.

Finally, and quite frankly, networkbased ID systems are rather dumb. They can log short-term trends, identify predefined attacks, and do some basic configuring of perimeter devices, such as routers and firewalls. They do not employ any intelligence when reporting on long-term trends, and they are completely oblivious to user trends.

However, these issues are being addressed, and some of these technologies are not far off. Systems like the U.S. Navy's Shadow package can perform long-term trend analysis and detect packet scans as staggered as two packets per day. Host-based IDSes also solve some of these problems. We will be examining host-based IDS later this year.

ISS RealSecure

Following in the footsteps of ISS's flagship product, Internet Security Scanner, RealSecure is the most polished IDS solution now shipping. Although it doesn't offer the flexibility of NFR or IDTrak, RealSecure delivers a solid, welldocumented and easy-to-use system.

Combined with a base of more than 100 network-attack signatures, RealSecure is a welcome addition to the security administrator's tool belt.

RealSecure's architecture uses a sensor (or "network engine," in ISS-speak) to communicate with a management console. Using this model, sensors can be deployed across multiple networks while reporting to multiple consoles. This distribution allows for large-scale coverage and a level of fault tolerance: If a console crashes or is attacked, other consoles can still detect sensor output. Because the actual inspection occurs in the sensor, any console can view the results of any sensor.

We tested RealSecure by installing both the sensor and the console on Windows NT servers. Installation was a snap-we were running and defining policies in less than 10 minutes. RealSecure administrators are given the option of maintaining multiple sensor configurations or "policies," which are particularly useful if you want to locate or isolate, a specific type of event. If, for example, you have a highly sensitive yet barely used area of your network, you may wish to enable all attack signatures-or maybe even create some custom ones. However, that same policy, crammed with enabled checks, may send your console into a tailspin if installed on a sensor attached to a saturated Web farm. By using multiple policies, administrators can create policy templates and swap them out at will. In the case of a highly trafficked Web farm, administrators may choose to disable some of the more informational/trivial checks. Removing checks for ActiveX usage warnings, for example, may lower the percentage of false positives.

Once an attack signature or event is matched, the sensor reports the event to the management console. This is where RealSecure shines: The console interface allows administrators multiple views of the gathered incident data. For example, sifting through the day's events we were able to view attacks by target (destination), source or event type. When someone targeted a single machine, we could switch to the destination view and see the assortment of attacks run against the machine. However, when we were trying to determine the origins of a coordinated attack, we could flip to the sources view, where we were presented with a grid of hostile machines and their offending actions. The quick, easy and accurate portrayal of this type of information is invaluable to anyone trying to react to an incident.

Unfortunately, RealSecure's console has some annoying habits. First, while you can clear the warning boxes that list events based on severity level (low, medium and high), the event matrices are locked. After populating the RealSecure event viewer with a few dozen trivial attacks, we were ready to clean the slate and get medieval. The only way to wipe the plate before the onslaught is to close down the console application. Worse, the advantages of the event viewer are weakened by the fact that if you exit the console to clear those events, there is no way to replot them. If you want to see an overview of excursions you're out of luck if they've been wiped. The only way to retrieve this data is to query the database. Not surprisingly, the text file that is produced isn't nearly as pleasing.

ISS RealSecure not only harnesses raw data but provides an intuitive interface for viewing it. Administrators can sort through attacks based on source, destination or type.

Also painfully lacking is threshold adjustment and customization. Less than a dozen of RealSecure's signatures allow for some amount of threshold adjustment; the vast majority of them do not. And, unlike NetRanger, RealSecure has no capacity to do regular expression searches when it comes to network traffic. The customizable "user-defined" rules are about as useful as basic route filters. Using Cisco ACLs (access control lists) with syslog can accomplish similar tasks, and that combination doesn't carry a hefty price tag.

Finally, in a world of wretched grammar, acquisition chaos, merged product lines and embedded video games, it's nice to see a vendor take the time to thoroughly and professionally document its product. ISS did a first-rate job in an area where so many vendors frequently fail.

Cisco Systems NetRanger

NetRanger was one of the first commercial IDS implementations to ship, and the offering draws upon Cisco's experience in the IDS field. A demon of an intrusion detiction solution, NetRanger could give the Energizer Bunny a run for its money. Obviously written by Unix people for Unix people, the product is one hard-core ID implementation that is fairly versatile. Its healthy attack-signature database, the staple of any good IDS, even has some creative signatures you won't find anywhere else. However, NetRanger's dependence on Hewlett-Packard Co.'s OpenView, its lack of clear documentation both in and out of the product, and its failure to provide a clear overview of attacks drop it into second place behind RealSecure.

For our evaluation Cisco shipped us both a "director" unit-a Sun UltraSPARC 10 running the director software-and a turnkey rack-mountable sensor unit, which ran the sensor software on top of Solaris x86. The sensor is essentially a beast-in-a-box: the dual Intel Pentium Is drive Solaris and the associated services across a 100-Mbps private pipe to the director unit. We found the private link to be a nice touch, as the director is completely shielded from any attacks experienced on the monitored network segments.

Building on this architecturally secure model is the fact that the sensor itself is virtually undetectable: The external interface, the one facing the monitored segment, has no IP address bound to it. We were unable to figure out a Layer 3 method of attacking the sensor directly.

Configuring NetRanger wasn't as intuitive as we would have liked. While a Unix-savvy administrator will quickly pick up on the various daemons and startup scripts, Cisco failed to supply any documentation detailing the ins-and-outs of running NetRanger. Cisco's support engineers were able to forward us draft documents that were of great help, but Cisco is obviously not where it needs to be when it comes to clear reference-a lot of information is still folklore

For the actual sensor and director configuration, administrators are presented with numerous scripts, Java applets and OpenView commands. Cisco chose to join the Java bandwagon for the main configuration engine, and this is one implementation the textbooks should skip. While the configuration applet wasn't as slow as NFR's (also Java-based) interface, it still leaves a bad taste in your mouth. Making matters worse is the fact that NetRanger uses HP OpenView. Let us clarify: It doesn't just snap into OpenView, it depends on OpenView.

While we see the obvious benefit of integrating IDSes with OpenView installations, not everyone is an OpenView guru. This issue burned us when we decided to reconfigure the interfaces on the director unit. OpenView puked when it saw the new configuration, and we were unable to use the NetRanger product. Admittedly this was through no fault of Cisco, but it brings a valid point to light: Interdependencies can needlessly complicate matters. The other products we tested don't suffer this problem.

Aside from these philosophical and cosmetic differences, when push came to shove, NetRanger delivered. It was the only product to fully recover from the ICMP (Internet Control Message Protocol) redirect storms with which we punished our lab networks. Using winfreeze, a recent denial of service (DoS) attack circulating in the community of the mischievous, we dumped approximately 10 million ICMP redirect requests onto the wire from a remote host. The ensuing chaos slowed most platforms to a crawl, and crashed several of our NT servers.

While the bombardment continued, we tried to sneak connection scans past the IDSes in an effort to perform basic network reconnaissance (see "How We Tested IDSes," page 100). NetRanger complained bitterly by sending multiple alerts to the console, and several daemons on the sensor reported failure. Then the services restarted, continued to process packets, and NetRanger caught our scans. In comparison, ID-Trak (running on NT) was neutralized by the attack, and NFR and RealSecure just sat there and took itsort of. Neither complained about the millions of packets screaming down the wire, yet they were both sluggish. Nevertheless, RealSecure still caught most of our scans.

Multiple Consoles Give NetRanger and RealSecure a Leg Up

NetRanger also has its own set of clever attack signatures. For example, any session, be it telnet, FTP or Web, that has "/etc/shadow" (the Unix password file) in it is instantly flagged. Simple configuration tricks, such as placing a "+ +" in an ".rhosts" file, are also caught. By using the included definition tools with regular expressions, you can search any portion of the IP payload for keywords, phrases or files. This is particularly useful if you have a closely guarded contacts list, report or financial statement that shouldn't find its way outside company boundaries.

Taking it a step further, you can have NetRanger act upon these occurrences. We set up NetRanger to protect our coveted caffeine chart: "up-allnight.xls." Any attempt to touch this file would be instantly reset. Sure enough, when we attempted to steal the secrets of long hours of work via FTP, our sessions were stopped dead in their tracks.

NetRanger, like RealSecure, offers administrators the ability to have the IDS reconfigure perimeter devices on the fly in an effort to stop certain types of attacks. Called "shunning," this method of defense can be an extremely powerful tool if used properly. One word of caution: NetRanger is not able to do multiple step condition-based actions. In short, you cannot tell NetRanger "if this occurs and this occurs, then do that." Due to the absence of this functionality, we encourage administrators to be very careful when using such features. While all four products are capable of reconfiguring the perimeter by pushing out router ACLs or modifying certain firewall rule sets to block offending networks, this type of power can wreak havoc if not closely watched. As with any weapon of mass protection, improper configurations can prove quite harmful.

It should be noted that using the shielded director approach is not a requirement: In the past, some NetRanger implementers have used existing SPARC units as their primary sensors, making use of legacy SPARC-based resources. It is interesting to note, however, that Cisco has recently stopped shipping the Solaris-based sensor software. This forces customers to purchase the turnkey rack units instead. While we didn't have any problems using the sensor unit, we wonder if the decision to solely deploy proprietary units shouldn't be made by the customer. Most network administrators aren't thrilled with the idea of forced platforms-especially when they have to shell out $20,000 a pop for them.

AXENT Technologies ID-Trak

With the purchase of Internet Tools earlier this year, AXENT added a networkbased IDS that complements its current host-based IDS, Intruder Alert. ID-Trak, which runs under NT, offers administrators a surprisingly flexible assortment of security and intrusion detection-related tools. While it doesn't match RealSecure or NetRanger in robustness or depth, its unique features and functionality still make it a valuable asset. Depending on your needs, it may even be the best tool for the job.

ID-Trak uses a slightly different approach to monitoring a protected network than its rivals. Rather than inspect everything that traverses the wire, ID-Trak forces the administrator to define a list of hosts to watch over. AXENT includes a utility called "profiler" that lets you define a range of IP addresses in which to search for hosts. However, the profiler needs some work. We turned it loose on our range of target hosts, and while it did a decent job of recognizing common services, it misdiagnosed many of our OSes. Normally that's not a big deal, but the profiler also assigns OS-specific attack signatures on a case-by-case basis. For example, our Unix machines running Samba were assigned a' set of NT-based attacks. Although we were able to fix the problem fairly easily, this adds to configuration time and complexity.

While ID-Trak has a smaller base of prebuilt attack signatures than its competitors (approximately 70), it surpasses all but NFR when it comes to customizability. ID-Trak includes a rule-building utility that can create custom inspection modules to examine certain types of traffic. Using these modules as building blocks, administrators can build more complex checks by dragging and dropping various components into the rule designer. This flexibility far exceeds the customizability of NetRanger and RealSecure.

In addition to some powerful customization tools, ID-Trak has other interesting features. One is its ability to easily snoop active sessions. ID-Trak keeps tabs on all open sessions, giving an administrator a visual, real-time display of what's transpiring on the network. Selecting any of the listed sessions launches a window that can be used to actively monitor the session without sifting through packet decodes. The view is identical to what the user sees for some session types (others still resort to raw packet dumps). Some would argue that this could be used as a privacy-invasion tool, but it saves Unix administrators the hassle of messing with utilities such as ttysnoop.

AXENT's ID-Trak combines flexibility with ease of use. Using the included tools, systems administrators can build custom attack signatures fairly easily.

Another simple, but much appreciated, feature in ID-Trak is its packetdropping statistic. While no one wants to see his or her IDS start choking, it's nice to know when it is getting overloaded. NFR and ID-Trak were the only two IDSes that offered this stat. We suspect NetRanger was overwhelmed at times, and we know RealSecure dropped some traffic, but we have no definitive way of telling just how pegged either of those IDSes were.

Unfortunately, ID-Trak's interface is rivaled only by NetRanger when it comes to compounded frustration. We were repeatedly lost in its configuration and monitoring screens, often staring at a submenu that looked familiar, but wasn't what we wanted. After living with the product for a few months, we became a little more familiar with its mazes of menus, but we hope AXENT hires some interface-gifted people to help clean it up.

Network-Based IDS Features

We are eager to look at the upcoming merger of the two product lines, IDTrak and Intruder Alert, as they offer an assortment of useful utilities. For now, however, Axent delivers a security tool that can be extremely useful in certain situations.

Network Flight Recorder NFR Intrusion Detection Appliance

NFR brings a unique approach to intrusion detection. Much like the open software movement, NFR has taken a very public approach to its product development. In fact, you can download the source code to the research versions of NFR from the company's Web site. This is the ultimate example of putting one's money where one's mouth is.

NFR has worked to develop a strong Unix- and Web-based back end with a powerful language called "ncode" that can be used for scripting attack signatures. However, it has spent less time populating the actual attack signature database than on the engine itself-the product ships with very few checks. Although NFR has delivered an intuitive and easy-to-use engine, IDSes witnessing attacks without signatures are about as useful as magazine editors on deadline without Mountain Dew-it's a bad scene. Some of NFR's resellers package NFR with a number of additional checks. But even with the additional components, NFR comes up short on the signature front compared with NetRanger and RealSecure.

Recently, however, NFR has teamed up with L0pht-one of the more talented crews on the hacker scene-to code some more advanced n-code modules. Unfortunately, until more signatures are produced, or until you employ a staff of protocol and code jockeys, NFR will not be as useful out of the box as RealSecure and NetRanger for mainstream administration needs.

In our lab we were able to preview an early beta of a new breed of IDS-an ID appliance or "toaster." NFR is completing development of a self-contained, self-installing and completely packaged IDS device. Popping a boot floppy and CD into a brand new Intel-based PC, we had an IDS operational in less than five minutes. And we must admit the unit as well as the concept is pretty damn cool.

We've also been watching the NFR mailing list for a few months, and we are continually amazed by the successful creation of knowledge bases based on a user community. If the level of expertise of NFR's user base is any testament to the product, NFR has a bright future ahead. NFR is less expensive, far more customizable, and growing in popularity. If you're willing to invest some time and expertise, the products NFR is producing are worth exploring.

Vendor Information

ID-Trak, AXENT Technologies, (888) 44AXENT, www.axent.com

Cisco NetRanger, Cisco Systems, (800) 553-2447, fax (408) 526-4100, www.cisco.com or [email protected]

RealSecure 3.Q, Internet Security Systems, (800) 776-2362, (678) 4436000, fax (678) 443-6477, www.iss.net NFR Intrusion Detection Appliance, Network Flight Recorder, (202) 662-1400, www. nfr.net

For more information on products tested in this issue, go to www.networkcomputing.com/finks.