

ISS RealSecure Pushes Past Newer IDS Players
May 17, 1999
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 it--sort 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.
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-all-night.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.
|