Filling the Application Gap

Application traffic continues to grow at an astonishing pace, which certainly means many things to many people, but for Network Equipment Manufacturers (NEMs) and service providers it means that network devices must perform with all of this traffic AND do it at high-speeds of 10 gigabit per second and faster.  Today we announced a toolkit to allow for native generation of stateful proprietary application traffic (news release).  I thought I would also share a couple of graphics we've been working on to show the "application gap" that exists and what we are trying to do about it:

Legacy test vendors have been unable to meet the application traffic needs of NEMs and service providers due to their locked-down architecture. However it is critical to be able to test network equipment with stateful application traffic including business, recreational, malicious, and proprietary application traffic.

As slide 2 shows, BreakingPoint is closing the "application gap" with the release of this toolkit which allows, for the first time, native generation of stateful proprietary application traffic.  The equation becomes simple: business, recreational, malicious, and proprietary application traffic plus the ability to simulate this traffic at speeds of 10 Gigabits per second on a single interface and scale up to 160 Gigabits per second and you are talking "real-world performance testing".

Faster, ActiveX! Kill, Kill!

If you haven't thought about ActiveX Exploitation in a while, a read-through of Warlord's January 2008 article, "ActiveX - Active Exploitation" is in order. I bring this up because the next StrikePack will feature a new strike, "Analysis: Killed ActiveX Instantiation."

As the name implies, this strike iterates through the client-side ActiveX controls that Microsoft has "killed" via the kill bit mechanism, and simulates a series of evil web pages which instantiate those controls. As of today, there are 445 kill bits set on Windows XP and Vista. These are all controls that Microsoft, in no uncertain terms, has labeled as Very Bad For Internet Explorer. If you run any of these controls, your browser will crash in horrible ways, or you risk getting commands passed directly to the shell, or your browser hands over all your personal data, or some other awful desktop fate.

Instantiating these controls is easy -- just deliver an OBJECT tag with the appropriate CLSID, reference the object with your exploitastic Javascript, and you're pretty much done. Thus, you would think that blocking these controls from instantiating in the first place would be as fundamental to malware detection as any string matching Slammer or Blaster signature.

However, informal testing of a couple devices we have around the office proved this assumption to be baseless. Rather than the forty or fifty percent detection rates I was expecting, I found rates between zero and ten percent.

Admittedly, I had low expectations to begin with, so I wasn't exactly shocked. That said, if you're in the market for a fancy expensive device that claims client-side coverage, you may want consider how that gear stacks up against vendor confirmed, publicly disclosed, easy to use browser vectors.

Load Profiles for Layer 4-7 Traffic

Dennis just put together a new screencast which gives you a quick tour of load profiles for Layer 4-7 traffic. He also goes into how to create steps and loops in Layer 2/3 test components. For current BreakingPoint users, the load profiles shown in the screencast will be found in the 1.2.1 release.

Below is a preview or you can always view it in full glory in a Separate Window (it's a little over 6 min.).

Deep Packet Inspection (DPI) Webinar

NSS Labs has announced a Webinar series focused on "High-Speed Deep Packet Inspection (DPI)".  The Webinar series starts on July 16th at 10am PDT with NSS Labs Chief Scientist, Bob Walder and CEO, Vik Phatak. After the first one we will certainly be discussing in more detail here on the blog and welcome you to ping us on Twitter during the webinar.

More information and registration.

When Looking Bad Makes You Good

Aren’t you afraid you’re going to make everybody look bad?

I often get asked this question when I am demonstrating the product, discussing test results, or explaining how my product works to the folks who are testing network devices. Why is it that everyone is afraid of looking bad? It seems like the whole network industry has been immersed in this fear for so long that they’re willing to do anything to look good.

Test gear companies are aware of this fear, so they’ve built their products to favor specific network equipment vendors. At the end of the day, test gear companies will do anything to ensure that their customers’ products don’t look bad – even if it means tweaking their test gear to work better with certain network equipment. My problem with this is: how will network equipment manufacturers ever know if their stuff really works if they’re not breaking their equipment?

One of the reasons why the companies I’ve been with have all been successful is because we focused on breaking our equipment. I wanted to find test gear that showed me the problems with our products; I wasn’t particularly looking for test gear that would help improve the specs on our data sheets. Obviously, that’ s not a bad thing, but it’s not the most important thing. The most important thing for us was finding the issues with our products before they were released into the field. After all, the field is the worse place to find an issue, the costs are a lot higher and the debugging time is infinitely longer.

So, my answer to the question, “Aren’t you afraid you’re going to make everyone look bad?” is no. I’m afraid of what will happen if someone installs network equipment that wasn’t properly tested. I’m afraid something terrible will happen, like a CEO not being able to access their e-mail or giant wombats overtaking the world.

What do you use your test gear for?