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

Detect This

	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

Our expectations on detection were straightforward: The attacks we threw at the NIP devices should have been detected properly, even when we used evasion techniques like fragmenting and reordering. We weren't disappointed, exactly. On our test bed, the devices performed flawlessly, detecting all the attacks we threw at them. What we didn't expect were the rather odd false positives that cropped up when we installed the products on our live network.

For example, we use SSL over SMTP because we authenticate to our mail server before sending e-mail. IDP triggered on there being binary data where SMTP commands should have been because it didn't recognize the STARTTLS command. We added a new signature that detected the STARTTLS command, created a rule that detected STARTTLS and then ignored the rest of the flow. We placed that rule at the top of the rule base so it would be triggered first.

Next, we had to deal with IDP thinking that our NTP server was UDP-scanning a remote host that was trying to synchronize time. We used WildPackets' EtherPeekNX to analyze traffic between the two hosts, which was NTP traffic while the IDP was alerting us about a UDP port scan!

IntruShield had a few quirks, too. For example, it claimed that SNMP traps (UDP 162) sent to the broadcast address were overly long NetBIOS name queries, and that SNMP responses were another form of UDP port scanning. Once we had things tuned (a never-ending process, really) we were able to track all those pesky attackers trying to break in. False positives happen, so we strongly urge you to thoroughly understand why an alert is being generated before you decide to block that traffic.

Something To Talk About

Before we decided to block traffic, we had to investigate the alerts and log entries we were seeing. In the deluge of events, information management is key. IntruShield excelled in this area with its simple but powerful tools to filter alert presentations and delve into specific areas. For example, IntruShield Manager let us drill down into the alerts via a variety of avenues. We had more than 15,000 entries, but we could sort them by individual protocols, eight of which carried alerts. That's a manageable starting point. After several weeks of monitoring, IntruShield detected 33 individual attacks, with the bulk of the attacks in the top 10 of the total 33 discovered. Individual views could be sorted by any column, and packet capture was available and predefined for certain alerts. You will need to install Ethereal or another protocol analyzer capable of reading pcap files.

NIPS Performance

click to enlarge

IDP defined filters on the real-time event viewer to pare down the information, and it let us save the filters in a view, which could be used time and again. If you know what you're looking for, you'll be able to locate it easily. Unfortunately, we could not get a view of all the attacks detected, besides a Top 10 list. The predefined reports left a lot to be desired, and there was no scheduling facility to generate reports periodically--a feature offered by IntruShield.

After extensive testing, we found both products' protection measures reasonable. When installed inline, both IntruShield and IDP can drop packets and streams or send resets to the client, server or both. We enabled autoblocking on our live connection for those alerts we determined had a very low probability of false positives. These were generally HTTP-related encoding, directory traversal and command-execution attacks. We did not autoblock for servers where we expected some false positives. Your comfort level, and therefore mileage, may vary.

We gave our Editor's Choice nod to Network Associates' McAfee IntruShield 4000, largely because of its top-notch detection and report facilities, for which you will pay a premium. For sites with less than 500 Mbps of network traffic, NetScreen-IDP is certainly a contender. Its firewall-like rule base will be familiar to most administrators, and its reporting, after some massaging, was adequate.