Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

R E V I E W

NIP Attacks in the Bud

September 4, 2003
By Mike Fratto

>> continued from previous page

Name That Tune

	Issue TOC
	Print full article
	Print this page
	Download as PDF
	E-Mail this URL
	Discuss this article
	Flame the author

	In this article
	Introduction
	Name That Tune
	Detect This
	Network Associates McAfee IntruShield 4000
	NetScreen Technologies NetScreen-IDP 500
	How We Tested \| Report Card
	NIP Lessons Learned

A properly tuned policy will reduce false positives, but tuning a detection policy means customizing the detection-signature set to suit your environment. Examples of tuning include:

• Enabling signatures that pertain to your servers. If Apache isn't installed on your network, do you really want to see Apache-specific alerts? We think not.

• Ignoring alerts from specific hosts or subnets. For example, a vulnerability-assessment tool will light up a NIP device like a Christmas tree, so it's probably safe to ignore attacks from that host. Network-discovery tools that use ICMP, port scans, NetBIOS and SNMP to enumerate hosts will trigger a high number of alerts as well.

Although both NetScreen's IDP Manager and Network Associates' IntruShield Manager have robust tuning capabilities, they take radically different approaches. It's a Scylla and Charybdis thing: IDP Manager, which uses a rule-based paradigm, is familiar and easy to use but can easily lead to rule overload. IntruShield, on the other hand, relies heavily on policies applied to subinterfaces or virtual IDSs, raising the potential of lots of small, highly customized policies. We prefer a rule-based approach because it's the sea monster we know, but we recognize that rule bases can get complex. Individual policies are simpler conceptually, but changes need to be made multiple times, which adds complexity.

Vendors at a Glance

click to enlarge

Reducing false negatives is a different matter. Factors contributing to false negatives include timeliness of signature updates, poorly written signatures and nonstateful packet inspection. If a signature doesn't exist for an exploit, it won't be detected, so clearly, it's critical to update signatures as quickly as possible. We'll qualify that statement by saying protocol analysis may spot unknown exploits by detecting, for example, violations in a protocol sending binary data, such as shell code, in an HTTP or SMTP header. But protocol analysis can just as easily raise false positives, so though it's a good early warning system, it's not a reliable method of detecting attacks.

An alternative to rapid updates is custom signatures. Although signature development is complex and best left to experts, a little knowledge of signature writing can let you block fast-moving worms or create custom signatures for your environment. Each product has its own signature-creation method, so there will be a learning curve to negotiate, but we found documentation pretty helpful.

Stateful packet inspection is almost a given in IDSs, and it's no different in NIP systems. Common games that attackers play when trying to evade signature-based systems include fragmenting packets into tiny pieces, splitting the protocol headers or attack into multiple packets, sending packets out of order and sending packets with unusual combinations of options. At the application level, encoding of HTTP URLs is a common way to obfuscate HTTP-based attacks. Packet reassembly and protocol canonicalization strive to present the IDS with the packets that will be seen by the destination system. IDP and IntruShield both perform stateful packet inspection and normalize traffic prior to signature matching, so these tricks were generally thwarted.