Mu's Internet attacks in a can

Mu Dynamics' Mu-4000 Analyzer and Published Vulnerability Attacks take a hammer to our UTMs

Page 2 of 2

The Mu-4000 represents a vulnerability analysis tool that has moved beyond the spray-and-pray attitude of days past, allowing you to instrument whatever piece or pieces of each device your analysis wants to concentrate upon. Instrumentation could involve querying the CPU status via SNMP, the link utilization of key interfaces you get off the serial console, or the time it takes to yank an important Web page off a server. We scratched the surface here, as our test only measured whether the attack could get through.

Next time we'll probably try to instrument the UTM further in-depth so that we can tell when the device under test was too overwhelmed to pass any bits or whether the device had to restart due to overload. The engineers at Mu Dynamics made sure we knew that there were multiple ways to restart firewalls; they were absolutely sure that we were going to lock up some of the devices. Most basic of the restarters were two 10-amp power relays to drop the power out from under a device. However, we could have used any of the Mu remote access technologies to run control scripts.

Our objective in using the MU-4000 in this UTM shoot-out was two-fold: First, we wanted to learn how well the UTM could handle a wide range of attacks based on known vulnerabilities in popular operating system, application, and networking software. Second, we wanted to find out how much overall throughput is lost as the UTM confronts a series of attack runs. Remember: The base premise of this test was to avoid letting the UTM dedicate 100 percent of its resources to a single task. Hit it with Internet, intranet, VPN, and attack traffic all at once, and we would get a much better picture of how these firewalls work in the real world.

Having run what we hope will be a groundbreaking scenario-based test, we tossed a wish list at the Mu Dynamics developers.

  • Instead of relying upon a ping through a device before running an analysis, it would be much better to send a single sample transaction for the protocol being tested. This way, you won't have to artificially open holes in firewalls to get a script to start.
  • Add a larger comment field for each analysis run so that more configuration information can be captured.
  • Provide some sort of common test equipment console so that we can automatically correlate test data from multiple pieces of gear. We really hate the tedium of trying to match up events from multiple timelines.

Regarding that third bullet, we're happy to report that Mu Dynamics is now part of the TesLA (Test Lab Automation) alliance, along with Ixia, Shunra, Codenomicon, and others. With a goal of a single console for executing tests and correlating results from the various test instruments of multiple vendors, we think we might actually be on our way to true scenario-based testing.

| 1 2 Page 2