| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 |
||||
 |
|
|||
 |
||||
|
|
|
||
|
|||||||||||||||||||||||||||||||||||||||||
 COLUMN
Once-promising intrusion detection systems stumble over a myriad of problems WE HAD HIGH HOPES in 1998 when we reviewed the new security technology, network-based IDS (intrusion detection systems). The review shared cautious optimism about the security industry's ability to thwart (or at least detect) malicious hacker attacks. After all, didn't we all want to know what really passed across those electron-filled copper wires? But today, after nearly three years of battle scars, we are here to announce the death of network IDS.
Hope turns to headaches One of the first problems discovered with early IDS technology is its dependency on shared network segments. This old-school networking technology allows everyone on the same network segment to listen to all the traffic being sent on the wire. Because of the shared-segment requirement of IDS sensors, IDS solutions can be painful for companies that depend on performance-enhanced switched networking technology. Switching technology is so pervasive in organizations today that accommodating most network IDS proves daunting. Along with switched-technology adoption, the need for higher network speeds has drawn most organizations to 100Mbps and 1Gbps speeds for their heaviest traffic segments. The sheer volume of packets traveling the wire at any given second on these large Web sites and e-commerce servers can make IDS as effective as a fly drinking from a fire hose. And the legitimate traffic is only the beginning. Consider the myriad network DoS (denial of service) techniques that can be used to force most IDS to drop packets. The rub with packet loss is that you'll never know which packets are being dropped, the legitimate or the malicious ones. And we don't need to remind you of the fragmentation reassembly, insertion, and DoS problems with network IDS, do we? The IDS attacks made famous in 1998 by Timothy Newsham and Thomas Ptacek live on to this day as the de facto techniques for avoiding IDS. Fundamentally flawed? The core architectural anomaly in network IDS is its dependency on attack signatures, which by definition must be unique, requiring an overworked, underpaid software engineer to identify and code them. Who is to say that one engineer's heuristic techniques for identifying a particular attack is the best or most accurate? This is precisely why false positives abound with IDS. It's one of the industry's dirty little secrets. (Want to see an IDS provider squirm? Ask why false positives continue to plague companies.) Of course, because attack signatures are often flawed, typical evasion techniques still confound most commercial IDS software, including those found in the freeware product whisker from Rain Forest Puppy. And you need only go to your Bugtraq inbox to find the latest obfuscation technique that can often be used to blind IDS. Using hex or Unicode to wrap attacks, thus hiding them from IDS, allows them to pass unabated by the sensor and then translate to their original messages at the target Web servers. The biggest inhibitor to network IDS growth has always been encryption. Commercial Web servers encrypt session traffic over SSL (Secure Sockets Layer) connections, effectively blinding network IDS sensors from finding hacker attacks on the wire. Although many SSL servers do not maintain the same directory structure and configuration of the default Web server, many do, and those that do provide an encrypted tunnel for unfettered attacking. The practice is so pervasive that if a client's Web server has SSL running, we won't even bother attacking the normal Web server when we search for vulnerabilities. Instead, we attempt to gain access to the network through the SSL server. The only defense for this Achilles' heel of network IDS is on-the-fly SSL decryption technology such as ssldump (www.rtfm.com/ssldump). This technology allows for inline decryption of SSL traffic and analysis of its payload. The prerequisite for on-the-fly decryption is possession of the SSL server's private certificates, but this technique does breathe life into the corpse of IDS. If you still insist on using network IDS, look at an excellent freeware version, such as Snort by Martin Roesch. Do you have any place for network IDS in your company? Send your IDS love notes to security_watch@infoworld.com. Stuart Mcclure is president and CTO and Joel Scambray is managing principal at security consultant Foundstone ( www.foundstone.com ). They wrote the best-seller Hacking Exposed, just out in a second edition from Osborne McGraw-Hill.  RELATED SUBJECTS  SecurityMORE > SPONSORED WHITE PAPERS 
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
