Juniper NetScreen IDP 500
Best user interface and analysis tool set we have seen, allied to its ease of setup (once you figure out what to do from the incomplete Quick Start Guide).
Its internal security, the Quick Start documentation, and support.
A reasonably competent IPS, but pricey and, unfortunately, it is still flawed in several areas.
Every now and then you find a product that has major warts but which really, under the warts, is a pretty good product. Then you wish the vendor would get its act together, because you would really like to buy and use the product.
The Juniper NetScreen IDP 500 is exactly that sort of product. The good news is that Juniper, having acquired NetScreen, seems determined solve the problems that caused us to step away from this product family (specifically the NetScreen IDP1000) in a recent group review of intrusion prevention devices.
The NetScreen 500 is in the middle of the NetScreen product family. We did not test pure performance issues, such as latency, response speed, number of attacks recognized, and so forth.
Instead, as we did in the recent group review, we focused upon the usability of the device. For a more detailed description of our testing methodology, see pages 53 and 54 in the July 2004 issue.
The IDP 500 is a complete appliance (hardware and installed software) supplied with the additional software required (such as a management console, user interface, documentation on CD and a backup CD to reinstall the software on the appliance if necessary).
The product was, however, supplied with the wrong network interface cards for our test setup. The default configuration uses two copper gigabit and two fiber-optic gigabit NICs.
However, we do not have a fiber test bed, so we needed the copper NICs only. There was no discussion of this prior to shipping the product to us for testing. The enclosed Quick Start Guide does not make the issue of ports clear and, as a result, we had a couple of unsatisfying support calls.
Finally, we were put through to one of the development engineers. With his help, the problem was solved in minutes. We received two quad copper NICs and we were able to get on with the installation.
We were very disappointed in the quality and knowledge of the support engineers as well as the accuracy of the Quick Start Guide. The guide should take into account that not all installations will be default installations, and should either accommodate non-typical installs or reference an alternative information source directly.
Since we were interested in how easy the product is to set up and use, as well as features that help in the analysis of attacks prevented, we began by installing the product in front of a honeypot sitting unprotected on the internet. Setup, once you know what needs to be done, is very straightforward and fast.
However, we discovered that if, for some reason, the User Interface (UI) cannot connect with the management server, it continues to try indefinitely. The only way to stop it is to reboot the UI computer.
For example, at one point we were unable to get the UI to work, so we reinstalled it from scratch, an action that proved successful.
The UI, however, needs a time-out for this type of problem. We have no idea why it failed (it worked earlier), but having to reboot and reinstall seems to require more effort than it should.
There was one further surprise. The system requires an additional computer to use as a management server, and this computer must be running Linux or Solaris.
The required computer must also be pretty robust, with at least one gigabyte of RAM. We could find nothing that told us about this need for another computer until we opened the Quick Start Guide. Fortunately, we have a Sun Sparc Ultra 80 running Solaris 8 in our lab and were able to configure it as the management server.
We then performed a number of scans and attacks against the protected device. The IDP 500, set up in a default security policy, responded very well.
We updated the policy and found that the device had protected the honeypot against everything it claimed it would.
For the attacks where we expected the IDP 500 to respond, we found no indication in the honeypot logs or the Snort logs of the honeypot's sensor that any attack had got through.
Having attacked the device ourselves, we then simply left it operating for a two-week period, collecting attacks and protecting the honeypot. The results were similar to those under controlled testing conditions. We found that it performed as represented.
From the perspective of analysis, the IDP 500's user interface is the best we have seen. It is a simple, intuitive web-based interface that can reside on any Windows machine making access to the system by administrators very easy. The product, though, is not without serious weaknesses.
The internal security of the device is a serious issue. We found it very easy to defeat any controls on the system. It is embedded in a Red Hat Linux operating system in which it runs as a kernel mode process.
We saw no evidence of any particular measures to harden the operating system, and logging in as root to the operating system allowed us to change anything we wished, including altering and/or removing logs.
We also logged in remotely using SecureShell and then we were able to SU to root and do anything we wished. Because there is a management server as well, we see multiple avenues for compromising security. This impacts the feature set of the product.
Generally, we found the IDP 500 to be a reasonably competent intrusion prevention device, if a bit pricey at $34,995 plus two quad NICs at $1,495 each.
Annual support, which is all-inclusive, costs $4,090, bringing the total tab, as delivered to us, at $42,075. The additional requirement for the management server raises the ante even further, however, severely impacting its rating for value for money.