It has been just over 12 months since we last looked at network Intrusion Detection Systems and Intrusion Prevention Systems (IDS/IPS). There have certainly been some changes since then. The most obvious are in the command and control capabilities.

Vendors are focusing on the centralised/remote management of the individual sensors or devices, as well as putting more emphasis on comprehensive customisable logging and reporting systems. These can be used for a number of tasks -- from creating graphs/charts for senior management with ROI figures justifying the amount of expenditure by the ICT security department, through to technically analysing detected attacks or suspected attacks from both the outside and inside of the network. In some circumstances this technical analysis can be widened for use in more advanced forensic processes and systems.

Intrusion Detection Systems came first, originally as a signature-orientated system that compared network traffic flows at the point where the system/device was placed. Usually in a transparent or bridged mode, this form of IDS just logged and alerted security administrators/operators about suspected intrusions, the rest was hard manual labour -- searching through the neck-high log of information, often down to the individual packets.

Intrusion Prevention followed, initially using similar signature systems as the detection systems. Prevention added a layer of defence to the network by getting smart and adding rules and policies which administrators could configure to perform certain activities when traffic matches a signature, such as "drop the connection". This became quite complex and confusing. Human error was common -- it was a case of test, re-test, and test again.

There were also a notoriously high number of false positives. The signature-detected traffic can trigger a number of things in an IPS environment, from dropping the connection, to re-directing the file to a honey pot system.

The majority of IPSes these days can be configured in virtually unlimited ways, enabling them to be tailored to fit their intended environments. This includes basic external IDS functionality through to detecting new threats externally and internally. Some IPS's now incorporate technologies which attempt to detect anomalies in traffic that is passing through it. These anomalies can be treated in a similar way to signature-detected traffic.

Issues with both IDSes and IPSes revolve around false positives, overwhelming amounts of logged data, and performance. If IDS/IPS devices are incorrectly matched to the network environment they can form bottlenecks in the data traffic. If insufficient redundancy/failover is built into the deployed IDS/IPS systems, then they may default to closed if faults, or errors will occur. Typically, being bridge devices, these can cut off all network traffic. Naturally the more expectations, policies, rules, and logging the systems are expected to keep up with, mean more additional strain on their ability to perform high speed. The moral here is to test, plan, and even consider over-specifying the equipment to ensure no issues are encountered down the track.

Multiple sensors deployed at logical points around the network assist enterprises in reducing these performance issues and bottlenecks as well as enable external and internal traffic monitoring. Some vendors have a whole family of sensors that cater for different network sizes and environments. For example, a remote office with 30 workers can have a smaller sensor than their corporate headquarters that has 1000 workers and requires several large sensors. The best news is that centralised and remote management of most of these devices has become well refined -- most medium-to-large IDP deployments, particularly those covering diverse geographical locations, would send their logs to a central server.

IPS/IDS systems can come as either software solutions, dedicated appliances, or can be integrated in to other security appliances such as gateway devices or firewalls. These are commonly known as Unified Threat Management (UTM) appliances.

This review deals with the hardware side of the equation, namely dedicated IPS sensors/solutions and integrated security appliances or UTMs that have some level of IDS or IDP options.
Vendors who submitted appliances in this review were: SonicWALL, CyberGuard, Fortinet, Juniper, and WatchGuard.

CyberGuard SG710
This is a 1RU black chassis with a silver plastic bezel. The front incorporates 10, 10/100 Ethernet ports. There is a 9-pin serial console port on the front panel along with five status LEDs. The rear has an IEC power connector, switch, a small fan and empty expansion port.

Configuration, administration, and management are all done via a Web-browser interface. Good options are available to the administrator -- take, for example, the user configurable network ports which can be set to load balance Internet connections such as ADSL, cable, and so on.

Centralised management is available with syslog supported. The logging is relatively limited with nine predefined categories sent out to the syslog server port, or to e-mail. There is no report-generating tool integrated into this device. The logging for the IDS is limited to an external MySQL server. From here the administrator can export logs into several open source or commercial report generators and traffic monitoring systems. There is a basic syslog viewer built into the advanced section of the interface which does show some of the dropped connections and snort rules when they are applied -- this seems to be included more for diagnostic purposes.

Setting up the intrusion detection on the SG710 is straightforward, however, it is best to ensure the rest of the device is setup as the controls are very granular and it becomes worthwhile to ensure that the system is working across the LAN/WAN/DMS and other segments that are required.

There are two parts to the CyberGuard Intrusion Detection system. The first is similar to WatchGuard's in that it is a detection and blocking system (IDB), which can be configured to detect TCP and/or UDP probing and optionally set to block individual hosts after a certain number of triggers are set off. There are three default levels which can be used as a guide to set the sensitivity level of the IDB component -- these are Basic, Standard, and Strict. Administrators can add or remove individual items from these lists.

The second component in the Cyberguard IDS uses Snort. This is a rule-based detection system which compares traffic with a number of rules and therefore can pickup anomalies in the packets and block them.

There are about 45 rule sets included and the administrator can pick and choose whichever ones they want to apply.

Overall, this is a straightforward and easy-to-use device with a good range of ports that would provide the flexibility small businesses would need. A definite plus is the ability to set two WAN ports and provide fail-over or load balancing across two PPPoE ADSL connections or even cable connections.
The next generation of the firmware (v3.2), which should be available when this review is published, promises to have more depth to its IDS/IDP solution and to add antivirus at the gateway as well (Clam AV).

Fortinet Fortigate 200A
The Fortigate 200A is a very attractive black and silver 1RU appliance. At the front there are eight Ethernet ports (four internal, two DMZ, and two WAN). There are also two USB ports, a console port, power LED, a small backlit LCD, and four buttons to navigate.

At the rear is a small fan, a power switch, and an IEC power socket. Overall the construction of the device appears sturdy and well refined.

The administrator can set the IP addresses for the internal and external interfaces. And once on the network they can point a browser at the internal interface IP address using HTTPS to access the interface.

The user interface itself is well laid out and straightforward. Key tasks are performed using the menu system on the left. There is also a shortcut menu at the top enabling the operator to access other options such as a java console session to the CLI.

The 200A includes both signature-based and anomaly based IDS features, each relatively independent of one another.

Configuration is straight forward, although there is no automated update of the attack database -- it must be downloaded separately and uploaded from the local admin machine. Custom signatures can be created to counter zero-day threats amongst other things before the master signature database is updated.

Traffic policies and rules can be updated with various -protection profiles" that include IPS settings and there are several pre-configured profiles that can be modified.

Reporting is comprehensive. In particular, the granularity of the log-filter configuration allows the exportation of different logs and events to various logging/reporting systems. Alternatively logs can be viewed and filtered within the system's memory to a certain extent via the Log/Report section of the menu.

This is a very well-refined and developed system that is straight forward and quite easy to use.
The Fortigate 200A is certainly worthy of consideration for SMEs or larger remote office locations.

Juniper IDP 200
The only standalone IDP sensor in this review was the Juniper IDP 200 device. Coming from a family of sensors it enables an enterprise to tailor their IDP solution to fit exactly.

The IDP 200 sensor is clothed in the traditional Juniper blue livery. It is a 2RU device -- the front has 10 RJ45 ports, (two are for management and high availability), there is one DB9M serial console port, and status LEDs for power, hard disk drive, temperature, power supply failure, as well as the usual Link and TX/RX LEDs for the network interfaces.

The rear of the unit has an optical drive unit -- the machine we were shipped has a single power supply blade but there was room for another to provide redundancy.

There are a couple of other components to a Juniper IDP solution besides the sensor itself. The logging server is hosted on a separate server running either Red Hat Linux or Sun Solaris. We opted for Red Hat. There is also a management console which runs on Windows.

The initial setting up of the sensor is routine and straight forward, enabling the administrator to select from a range of options and even a setup wizard via a HTTPS browser interface. And for the traditional administrators there is the standard GUI interface. Like most Juniper devices there is an option for high-availability failover. We configured the device in bridged mode which basically interrogates all traffic between two of the device's ports.

Next we moved on to the centralised management and logging server where we found the setup could not have been easier -- a simple shell script is supplied and once run, the processes are started.
The remote IDP Manager console is excellent, especially considering the flexibility and number of options for the operator, let alone the logs and reports to be parsed and generated. Juniper has certainly done its homework. Once installed and with sensors added, the administrator can create security policies, either from the "cookie cutter" policies provided, or totally customised for their environment.

The updated IDP signature file can be downloaded and pushed out to update the devices. The granularity in control over both the administration and reporting side of the systems is phenomenal. Sitting at the top of the tree is the dashboard viewer which allows the operator to monitor their own defined hosts and sources as well as attack summaries and the device status etc. At any time they can drill further down into each frame to get detailed information.

For the medium-to-large enterprise with a layered (multi-segmented) network or a network that is geographically diverse, one IDS/IDP device/sensor sitting on or just behind the firewall really is not going to help too much. A far better solution would be to sit sensors at each network interconnection (trusted or untrusted) and have a central repository for all the data. Juniper can provide that solution.

SonicWALL 5060
The 5060 is the top of the range when it comes to SonicWALL security appliances. There are six (user configurable) RJ45 copper Gigabit ports on the front of the device and also a fibre version. There is a 9-pin serial console port and three status LEDs (power, test, and alarm) on the front. The rear of the unit has five small fans that are surprisingly quiet, an IEC power connector, and power switch.

Management, and basic log/reporting tasks can be performed through the browser interface. For more advanced command and control over one, or many SonicWALL devices the centralised management and reporting console, called the SonicWALL Global Management System (SGMS), is the way to go.

The SonicWALL intrusion prevention settings are found under the Security Services menu section of the devices console. Once here the operator is presented with the status of the Signature files. You can make changes to the IPS Global Settings while more granular zone-based control can be exercised by going to the network-zones section.

Under the global settings three options can be selected for either level of attacks (high, medium, or low) for detecting, or for detection and prevention. There are also options for IP reassembly and the creation of an IPS exclusion list based around IP addresses/ranges. The individual IPS policies are also under this menu, covering 41 separate categories -- a total of 2016 signatures were contained in the latest release at the time of testing.

Really all this is the tip of the iceberg once the administrator has set up policies and logging. You can view the logs directly from the administration console, or use ViewPoint or SGMS to access advanced reporting tools. It can quickly and efficiently display a range of statistics and graphs at the click of a mouse button. In summary, small-to-medium enterprises could do very well to deploy a SonicWALL security solution. There are so many integrated benefits and options, such as firewall, IPS, threat control at the gateway (spyware etc), ease of use, centralised management, and proprietary secure wireless access points, to either balance or outweigh the argument of "all eggs in one basket".

A SonicWALL deployment is not a "set and forget" security solution but it would certainly reduce the administrative burden of maintaining, administering, and securing four or five technologies.

It would create time to allow security administrators more time to ensure that the security is tested correctly and running securely instead of having them rush from console to console trying to put out fires as they arise.

WatchGuard Firebox X1000
WatchGuard has a great range of products, the beauty is that each device can be upgraded without removing or replacing any hardware -- simply purchase an upgrade key and the equipment's firmware is updated.

The front of the device includes six copper network ports, a serial/console port, four configuration buttons, a small backlit LCD, and 12 status indicators (10 of them showing each of the network port's connection speed). The remaining two show power and Arm/Disarm. The rear of the unit has a standard IEC power connector and switch.

The configuration and administration is performed via a client-based application -- WatchGuard System Manager. We were supplied with WSM 8.0 and once installed, we were guided through a quick setup wizard that covers things such as the licence key and initial port setup -- PPPoE on WAN if applicable.
Administration comes via WSM and is a straight-forward menu system. On the topic of logging, amongst the usual formats Firebox logs can also be output in XML (with Fireware Pro) and WebTrends (WELF) format. When the Firebox System Manager is launched, a graphical representation is shown of traffic load as well as port status and other key system details.

The WatchGuard IDS system primarily revolves around blocking traffic and packets that can be defined in the Setup-Intrusion Prevention settings under the Fireware Policy Manager application. This includes selecting and setting parameters for a variety of common scans and attacks such as port and address space probes, and flood and spoofing attacks.

There is also a default policy for preventing denial-of-service (DS) attacks by simply limiting the quota of connections per second allowed to clients and servers on the network. The signature file settings can also be set here, but the actual updating is either automatic (if the administrator chooses), or manually via the Firebox System Manager application Security Service tab. Clients can also be notified if their connection is disabled by the appliance.

Also under the IPS settings is an option to setup blocked sites and ports. The blocked site is an IP-based system and can either be a Host IP, Network IP, or a Host Range. Blocked ports are simply individual ports, however, these can be set to automatically block sites that try to use the blocked ones.

Overall the Firebox X1000 is a very well-designed security appliance, with a configuration system slightly different from the run-of-the-mill browser-controlled systems. The WatchGuard system is slightly more complex but adds flexibility and can offer increased security.

Tier-3 Huntsman
Tier-3's Huntsman can be used as an IDP solution enhancer -- it allows enterprises who already have a capable signature-based IDS/IDP to add an anomaly-based detection and prevention system. As discussed in the IDP review, signature systems rely on databases of known attacks being created and distributed to update the devices which use them. This is well and good if the attack is defined and the signature updated prior to the attack being launched but in this age of paranoia of unknown or "zero day" attacks, the signatures and updates may be slightly behind the actual attacks. This is where anomaly detection systems such as Huntsman's come in. They work by sitting agents on the network at key points and simply watching all the traffic flowing by (reporting back to a central repository) and building up an idea of "normal" traffic flows, size, direction, type, frequency, time of day, and hundreds of other parameters. As soon as something new or different occurs (an anomaly), the system can monitor it, and if it appears too out of the ordinary then an array of policies and rules can swing into action.

Tier-3 has coined the term "Behavioural Anomaly Detection" or BAD for short and Huntsman can not only use it for IDP but also for risk management and policy compliance.

Enterprise security policies can be applied in Huntsman to detect internal abuses of the policies by detecting anomalies in the network traffic such as internal nodes attempting to access information they should not normally access, or copying large slabs of data for no reason.

The "Decider Engine" is the brains behind the system which actually compares the traffic, and if necessary sends it off to the "guardian" that can automatically perform tasks such as locking users etc. All this data can be captured and used later for forensic investigations.

The best explanation of this can actually be found on Tier-3's own Web site: "Huntsman uses Tier-3's next generation hybrid behavioural anomaly detection (BAD) technology to protect intellectual property and sensitive information and instantly alert on any illegal or non-compliant business or IT activity.

"By collecting and centralising audit logs and security information from across the enterprise Huntsman uses standards-based risk management methodologies to enhance the security management process. Huntsman delivers real-time audit information on business activities and permits immediate remediation of any emerging IT risk across the enterprise. Additionally, it protects the enterprise against known and unknown malicious activity on the perimeter, thus, enabling Huntsman to protect the enterprise from external threats as well as monitoring compliance on internal business applications and activities."

Overall, if your job is ensuring that the security policies are enforced within your enterprise it may well be worth your while to have a look at Huntsman from Tier-3.

How we tested
We used a powerful yet simple tool called IDS Informer from Blade Software, to see how these devices performed in the detection stakes. While designed to test traditional inline or passive IDS/IDPs, we found that we could tweak the integrated security service appliances and the IDS informer configuration to enable successful running of the attacks.

IDS Informer uses a host Windows machine that has two network interface cards installed. The software includes several hundred pre-programmed attack sequences, some successful and some unsuccessful. One NIC sends out the attacks aimed at the other NIC which receives and responds to the requests, simulating a real-world response on behalf of a machine under attack. This has two benefits: the first is that the test engineer can be sure the traffic is getting through; secondly that both successful and unsuccessful attacks can be launched to see how the IDS/IDP solution under test goes at identifying one or the other.

Another great feature is that the application allows the test engineer an amazing amount of control over both the source and destination machine's IP addresses. Even in a disparate network environment, gateways can be set to the MAC address level, to enable some form of routing. One can even use wildcards in the IP settings to simulate attacks coming from many external sources or against several internal targets, each of which is collected and responded to by the secondary NIC.

We ran IDS informer on an Intel P4 2.8Ghz machine, with 1GB of RAM and two 1GB NIC's. Wherever possible we ran all the attacks through the devices on test just to see if any strange behaviour occurred, then we ran a selection of common attacks to have a look at the vendor's logging and reporting systems.

Three must-read resources for routine testing and evaluating of IDS/IDP solutions can be found at the following locations.

Test Analysis
The Fortigate, Juniper, and SonicWall were the devices most capable of actually identifying and reporting the names of the attacks that we launched. The other UTM appliances did a very good job at detecting and blocking the greater part of the attacks but they did this through a combination of mainly their firewall rules/policies more so than their IDP systems.

In some cases they didn't even attempt to identify the name of the suspected attack and only provided the necessary defence against it. In the real world however, this is fine, as ultimately it is what they are designed to perform.

It seems in these cases that the IDS/IDP solutions add another layer of security insurance behind the firewall, rather than allowing security teams to build up an entire picture of the exact attacks being launched to/from their networks, regardless of whether they are warded off by the firewall systems or the IDS/IDP systems.

Scenario
This company has become concerned about external attacks and wants to implement a network intrusion detection/prevention system to trace and manage intrusions on its 150-node network.

Concerns: The ability to recognise and block external attacks is the key issue, but the network manager wants to be sure the device can intelligently handle the data to reduce management effort. The ability to integrate with existing network/enterprise management software will also be taken into consideration. Logging and reporting is key for the security team and some forensic analysis functionality would also be great.

Scenario winner: SonicWALL 5060 and Juniper IDP200
The scenario winner this month goes to both SonicWALL and Juniper. While both similarly priced, the SonicWALL, being a UTM, provides a greater range of options relating to other security concerns a SME may have. The Juniper is a dedicated IPS and is better suited to an enterprise that prefers to keep its security systems separate. Both are powerful systems that are easy to use and will reduce the administrative burden. Both are also very good at pin-pointing the exact name/type of attack being launched.

Editor's choice: Juniper IDP200
The Editor's Choice goes to Juniper for their IDP 200. While a little on the pricey side, if an enterprise needs and is looking for a scalable, hardware-based, centrally controlled and logged, dedicated IPS solution with remote management that is powerful yet easy to deploy, then they would be hard pressed to go past the Juniper range.

About RMIT
RMIT IT Test Labs is an independent testing institution based in Melbourne, Victoria, performing IT product testing for clients such as IBM, Coles-Myer, and a wide variety of government bodies. In the Labs' testing for T&B, they are in direct contact with the clients supplying products and the magazine is responsible for the full cost of the testing. The findings are the Labs' own -- only the specifications of the products to be tested are provided by the magazine. For more information on RMIT, please contact the Lab Manager, Steven Turvey.

This article was first published in Technology & Business magazine.Click here for subscription information.

Thank You

By registering you become a member of the CBS Interactive family of sites and you have read and agree to the Terms of Use, Privacy Policy and Video Services Policy. You agree to receive updates, alerts and promotions from CBS and that CBS may share information about you with our marketing partners so that they may contact you by email or otherwise about their products or services.
You will also receive a complimentary subscription to the ZDNet's Tech Update Today and ZDNet Announcement newsletters. You may unsubscribe from these newsletters at any time.