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

How We Tested | Report Card

	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

We devised two different scenarios: We started testing by placing the NIP system into a controlled lab network with known characteristics. Once we operated the system and learned how to use it, we placed a second system in one-arm mode on our production network with live traffic.

On the clean test bed, we tested both signature detection and performance. Security testing involved grabbing public script-kiddie tools associated with network-based vulnerabilities in the SANS Top 20 (current vulnerabilities found in recent months). We modified some of the attacks so that they were still successful, but not stock.

Report Card

click to enlarge

We used Nessus and nmap for reconnaissance and ran the exploits across a router, ensuring that the NIP systems properly detected and alerted. Next, we used fragroute to split packets into tiny fragments and reorder packets in an attempt to evade detection. We then ran traffic through the NIP devices and reran all the tests to see if the attacks would still be detected. They were.

To test performance, we measured performance up to the rated capacity--or until we exhausted our rated capacity. We used Spirent WebAvalanche as a Web client and a Spirent WebReflector to mimic a set of Web servers. Each user requested a page consisting of a main page 8 KB in size and 10 subelements at 6 KB each, for a total HTTP payload size of

68 KB. We initially used HTTP/1.1 with keep-alive and ramped up the connections per second. Both devices under test passed all traffic with additional latency. We then switched to HTTP/1.1 without keep-alive so that each GET required a network TCP connection. Again, both products passed traffic with the same result.