When Juniper shipped the Integrated Security Gateway 2000 late last year, the company said it was more than another low-density NetScreen firewall. In addition to the basic firewall and VPN capability built into the chassis, Juniper said the ISG 2000 could accommodate as many as three other blades providing security applications, such as intrusion prevention, without affecting the performance of the base firewall and VPN.
The blades came out in the spring, and we've been testing the ISG 2000 with three IDP (Juniper's intrusion-prevention product) blades on our live network for four months, focusing on hardware, management software and architecture.
How we did it
We installed the ISG 2000 with IDP blades into our production network at its very edge, connected directly to our two upstream routers. With two 45Mbit/s circuits coming into our network, we kept the ISG 2000 busy, but did not stress it. The hardware was specified to operate at speeds far above our load.
Throughout the test, the ISG 2000 ran on Version 5.0 of Juniper's ScreenOS operating system. The management system was more fluid. We upgraded an existing NetScreen-Security Manager management system to version 2004-IDP (and later to 2005.1 and 2005.2) and proceeded to push our standard firewall policy to the ISG 2000. Because the ISG 2000 was upstream of all our existing firewalls, we combined all of the other firewall policies into a super-policy, adjusted for network topology, and were running within a few hours.
With the ISG 2000, the firewall configuration drives data streams into the intrusion-prevention system (IPS) part of the product. For every firewall rule, you say whether the IPS is enabled. We started with IPS turned on for all traffic, but simply alerting and not dropping or resetting connections.
After studying the false positives over a month, we refined our IPS policy to skip problematic systems and signatures.
Then we put the IPS into block mode, asking it to drop packets or reset connections that triggered its signatures. (A few days after we put the IDP into block mode we discovered one of our IDP boards had failed and was blocking traffic at random.)
For the next three months, we checked in on the management system daily, looking for log entries that might be signs of false positives, and updating and tuning the system. We used the logs several times to track down problems for our help desk. And of course, we had to make a number of changes to the firewall configuration.
During the testing, we worked with Juniper technical support to resolve questions and refine our understanding of the system. Juniper also provided on-site technical support at the end of the test to let us sanity-check our conclusions and to collect feedback.
Hardware: Too hard
The ISG 2000 design doesn't fall in line with Juniper's long-standing reputation of producing maintainable hardware. While port cards, fan modules and power supplies are easy to replace, you cannot hot-swap interface cards. Additionally, getting to the IDP blades and the management module means pulling the chassis out of the rack, unscrewing the top cover, and dealing with slots and boards that were not designed for easy maintenance.
The difficulty of maintaining this hardware was driven home in our tests when one of the blades stopped working properly. Juniper technical support was quick to diagnose the problem, but we had to pull the unit out of our network while we waited for a replacement part to arrive. Had the hardware been more maintainable, we could have quickly pulled the bad board and run on a reduced configuration.
We ran into another hardware-integration problem when we first tried to install the ISG 2000 in our network. Juniper's ScreenOS firewall software is running at either Version 5.2 or 5.3 in all current models - except for the ISG 2000, with Version 5.0. Unfortunately, 5.0 is missing a key feature allowing for asymmetric routing needed to install the ISG 2000 at the edge of a network with multiple ISP connections. Because of the versioning issue, we had to install additional switches to work around the unsupported topology.
Software: Too soft
Management of the chassis with IDP blades installed requires Juniper's NetScreenSecurity Manager, a client-server application for controlling the configuration of and analysing logs from the ISG 2000. Although managing the firewall and VPN components from this application is stable, the NetScreen-Security Manager doesn't control the IDP blade as well as the single-function management wares shipping with Juniper's stand-alone IPS boxes.
An intrusion-prevention system (IPS) requires frequent configuration to tune, tighten and reduce false positives. Operations that should be easy to do, such as adding an IPS signature to an exception list, require a significant number of steps, take you through a series of modal configuration dialogues and can be frustratingly unpredictable. Even with Juniper on-site, we couldn't figure out whether this unpredictable behaviour was caused by bugs or some exceptionally subtle issue of how and where you click.
Simple tasks, such as finding a signature to learn more about it, are difficult to do. When we finally discovered (with the help of technical support) the well-hidden "find" function in the NetScreen-Security Manager GUI, we found a not-so-well-hidden bug: It doesn't find things very often. We were reduced to searching and scrolling through thousands of signatures to get the information we required.
We also expected to see more by way of integrated management across modules. In places where Juniper could have shared configuration between the firewall and IDP, it didn't. For example, although the firewall rules are used to say whether the IDP protects a stream, all details of the firewall rules are lost once you enter the IDP. If you want to customise your signatures for different firewall rules, you have to recreate the rules before you can pick and choose the signatures that apply.
In all, we went through three released versions of the management software during our four-month test. It's hard to tell whether the problems we ran into with NetScreen-Security Manager are the result of a rushed design, or just a buggy user interface that didn't work very well. In either case, Juniper doesn't meet its own standards for intrusion prevention management tools with this release of the ISG 2000.
Architecture: Just right
If hardware and management software are the twin Achilles' heels of the ISG 2000, Juniper gets extra credit for getting the hardest part right: the architecture. Merging a firewall and an IPS is not easy. We've seen products from a half-dozen vendors go through our labs with the dual moniker of firewall and IPS, and most of them were so badly integrated that the IPS function might as well have been disabled. Not so with the ISG 2000. Juniper has done a good job of merging the two functions into a single system and giving the security manager sufficient control to make it all work - without putting so many knobs on the system that managing it is disproportionately burdensome.
Our months of letting the ISG 2000 protect our network ahead of all our other firewalls gave us hard-to-measure benefits. With any IPS, it's hard to say what didn't happen to you because you had an IPS in place. We had millions of attack events blocked, but it's impossible to say how many infections we didn't get because the IPS was in place. We were able to use the alerting system on the ISG 2000 to show us systems inside our networks already infected with spyware. Because the ISG 2000 was upstream of - and beefier than - all our other firewalls, it dramatically reduced the events coming from those firewalls, but that was also expected behaviour.
The ISG 2000 is like a mostly baked cake (or to the turophile, an underaged Parmesan). If Juniper fixes the management system, this product will be a valuable addition to any network. At this stage, the ISG 2000 will appeal to those die-hards who are familiar with Juniper's IDP product line and are eager to better integrate their firewall and IPS functionality into a single system and single management console.
Joel Snyder is a senior partner at Opus One in Tucson, Arizona.
Overall, while Juniper got the architecture of the system right, it's got some work to do in terms of maintaining hardware and management software.