Mu’s Internet attacks in a can

Ixia’s IxLoad system was key to our scenario-based UTM test by allowing us to fire a baseline of legitimate traffic through the devices’ various firewall interfaces and VPNs. The Mu test tool let us systematically test each UTM’s attack blocking capabilities. Only by using the Mu tool were we able to measure the impact of attacks on performance and to learn that the threat defenses of some UTMs leave a lot to be desired.

The Mu-4000, with Mu’s Published Vulnerability Attacks module, does not replay captured attacks, but rather generates attacks against known vulnerabilities according to the environment under test and in compliance with the industry’s common taxonomy. The attacks can be run against actual devices (Web servers, switches, routers, firewalls) or in pass-through mode, where the Mu-4000 connects through a device (like a UTM) and attacks a simulated server on another Mu-4000 interface.

[ When is a UTM not a UTM? Read the overall conclusions of the InfoWorld Test Center’s great UTM challenge. Read the reviews: Astaro Security Gateway 425 | SonicWall NSA E7500 | WatchGuard Firebox Peak X5500e | ZyXel ZyWall USG1000 | Compare the UTMs feature by feature. ]

In addition to generating exploits based on vulnerabilities from both public and private sources, the Mu tool provides an outstanding set of reports from each test run. Each attack in an analysis is explained in context with the vulnerability and exposes the XML definition for the attack so that vendors can dive into what-if customization. In addition to the published vulnerability attacks (PVAs), the Mu-4000 can also “mutate” portions of the attack similar to how many zero-day attack variants are created. These mutations now no longer match the original attack signatures and can expose weaknesses in security device algorithms. We did not expose our UTMs to these attack mutations; our test only included Mu’s known attacks.

We also chose not to run Mu’s denial-of-service module, fearing that the UTM vendors would be unwilling to confront it. However, the DoS module seems to do a great job of simulating even huge bot networks to pound the heck out of any unlucky device. It may not come in a review like this one, but we’ll have an opportunity to exercise the DoS functionality before too long. There’s just too much to talk about regarding the ways that network infrastructures respond to massive traffic attacks.

[ Read more about our UTM acid test and the Ixia test tool: “How to stress a UTM” | “Ixia IxLoad’s multithreaded testing” ]

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.