 |
|
|
The NetScreen Intrusion Detection and Prevention (IDP)system is a turnkey appliance-based system which uses as many as eight detection methods to detect malicious network traffic. Unlike other Intrusion Detection Systems that provide only a passive sniffer mode, IDP has the ability to operate in-line as an active gateway, directly in the path of traffic entering and leaving the network. IDP uses a three-tier architecture that consists of the IDP Sensor, the IDP Management Server, and the IDP User Interface.
� IDP Sensor - monitors the network on which the IDP system is installed. The Sensor is a hardware appliance that runs the Linux-based IDP Sensor software. � IDP Management Server - stores and manages all Attack Objects (including attack signatures and protocol anomalies), log information, rulebases, and Security Policies. Multiple Sensors can be managed by a single Management Server. � User Interface (UI) - a graphical interface for interacting with the IDP system. The UI is used to access remotely and manipulate the information stored on the Management Server. Based on the Dell PowerEdge 1650 1U rack mount hardware platform with dual-Pentium processors and 4GB RAM, the IDP 500 submitted for this test sports two fibre Gigabit interfaces for packet detection/forwarding, and two copper 100/1000 interfaces for management. This device is rated at 500Mbps, but the range also includes the IDP-10 (20Mbps) and the IDP-100 (200Mbps). The Sensor�s primary task is to detect suspicious and anomalous network traffic based on specific rules defined in IDP rulebases. If the Sensor is running in-line, it can also take a predefined action against malicious traffic. IDP Sensors can be deployed as active gateways or passive sniffers. A passive sniffer Sensor connects to a switch or hub in promiscuous mode and sniffs the network traffic as it passes by. The Sensor monitors network traffic, records security events, and can create alarms for attacks. However, because a sniffer Sensor cannot take direct action against the attack, it cannot prevent it.
An active gateway Sensor sits between the network and a firewall, or a network and a DMZ, and takes an active role in protecting the network. When it detects intrusions or attacks defined by Security Policies, the Sensor can drop, block, or ignore the suspicious connection, or drop only the suspicious packets. Because active gateway Sensors are installed in-line they can take direct action against the attack, thus preventing it. The Sensor can be deployed in router, bridge, or proxy ARP modes, providing a high degree of flexibility in deployment options. The IDP appliance supports the 802.1Q VLAN protocol at the kernel level and can generate 802.1Q frames in all in-line IDP deployment modes. It also allows the creation of multiple virtual routers on a single IDP Sensor. The simplest in-line deployment option, however, is bridge mode, which allows the Sensor to be dropped in and out of the network with no change to the network addressing around it. The Sensor stores logs on the local hard drive initially, and then transmits the logs to the Management Server. If communication between the Sensor and Management Server fails, the Sensor attempts to restore communication and stores new logs on the local file system until available disk space is consumed. If no disk space remains and communication has not been restored, the Sensor first deletes sysinfo logs (debug and error messages) followed by packet captures to free up disk space. If communications cannot be restored before all local disk space is consumed, the Sensor ceases to detect new attacks. Unlike passive intrusion detections systems, IDP can operate as an in-line, active device that looks at all traffic and determine what constitutes an intrusion. If instructed by the Security Policy, IDP can deny traffic associated with the intrusion by dropping the connection or associated packets (when operating in-line). Rules are created in the IDP rulebases to specify what actions IDP takes when a particular attack is detected. Detection methods (rulebases) include:
When operating in-line, it is essential that traffic is not interrupted by device failures. It is therefore possible to deploy the IDP system in a high availability (HA) configuration to provide failure protection, either in a standalone configuration or using third-party hardware. In high availability, 2 to 16 Sensors are joined together in a HA cluster that provides failure protection and/or load balancing. In load balancing mode, all Sensors in the cluster share network traffic equally, and if a Sensor fails, network traffic is redirected to the other Sensors in the cluster. With hot standby, a primary Sensor handles all network traffic while a secondary Sensor stands by. If the primary Sensor fails, network traffic is redirected to the secondary Sensor. State information is shared between Sensors in the cluster using state-sync interfaces and dedicated network interface cards. High availability configurations are available for bridge, router, and proxy-ARP deployment modes. Also available when operating in bridge mode (IDP 10 and IDP 100 only) is the IDP Bypass Unit - a fail-open network device for the IDP system. If traffic flow through the IDP appliance is disrupted, the Bypass Unit can automatically reroute traffic. The NetScreen-IDP Management Server consists of software that manages system resources and data that drives IDP functionality. The Management Server software can be installed on the IDP appliance for evaluation purposes or for single Sensor deployments on small networks (IDP 100 only). In all other situations, the Management Server must be installed on a separate computer running Red Hat Linux 7.2 or Solaris 7/8 (this is the recommended configuration due to performance considerations). The Management Server centralises the logging, reporting, data, and Security Policy management for the IDP system. Logs from multiple Sensors are consolidated into a single, central repository, and the Management Server also provides a single point of management, policy definition and deployment. All objects, Security Policies, and logs are stored in databases on the Management Server and are administered using the User Interface by one or more administrators. Management Server communication with the other two tiers of the IDP system (the Sensor and User Interface) is encrypted and authenticated to provide an additional level of security. The Management Server gathers log records for security events using a proprietary communication mechanism utilising a modified version of UDP which NetScreen claims is more reliable than ordinary UDP, requires less CPU and memory resources from servers, and reduces the number of acknowledgement packets on the network. Alerts are stored in a proprietary database which NetScreen also claims offers high levels of performance (over 50,000 logs per second). When IDP detects a DoS attack, the Sensor increases its transmission rate and injects redundant packets to increase the odds of transmitting the logs to the central location. The User Interface (UI) is software that provides a graphical environment for centrally managing IDP. The UI is a java-based software application that can be installed on multiple computers across the network. Although the UI supports multiple users, only one user at a time can take control of the Management Server - this eliminates concerns about synchronisation or data loss. Each administrator can configure the UI with his own preferences - IDP stores user preferences and custom Log Viewer views in the central database so that they remain consistent when accessed from different client machines. Installation is very straightforward. The Management Server can be installed on any secure and trusted Red Hat Linux 7.2 or Solaris 7/8 computer. It is installed via a simple shell script that walks the administrator through all the steps necessary to install the software, and this process takes no more than five minutes.
Next, the Sensor is connected to the network to be protected, and one of the interfaces connected to the management network. Using the Appliance Configuration Manager (ACM), a Web-based tool, a Wizard guides the administrator through the six-section configuration process of configuring the IDS Sensor software. During this process, key parameters such as Sensor name, passwords, deployment mode, network interface settings, SSH settings, date and time are configured. The administrator is also prompted to enter a One Time Password (OTP) and is provided with a unique identification number (VIN) for the Sensor. This is used later when adding Sensor devices in the UI. Finally, the NetScreen User Interface (UI) is installed. Versions are provided for Windows and Red Hat Linux. Once network components have been added (starting with the Sensors themselves) and a security policy defined and deployed (see following section), the IDP 500 is ready to go. The rule-based, centralised management system makes it easy to configure, update, and maintain the IDP system from a single administration point if required. An unlimited number of IDP Sensors can be managed with a single, logical Security Policy - there is no need to manage individual configuration files for individual sensors. Once the administrator has defined an enterprise-wide Security Policy it can be distributed at the push of a button. All relevant configuration and signature information is automatically sent to the IDP Sensors in a secure manner (authenticated and encrypted).
An unlimited number of remote User Interface installations (running on either Windows- or Linux-based systems) can access and manage all aspects of the IDP system. The UI contains seven components:
Each of the above options is accessed via a hierarchical menu tree in a pane on the left of the UI, whilst data is displayed in a second pane on the right. The Dashboard component is the default component shown in the main display area when the administrator first logs in. This provides a one-screen high-level view which displays the vital statistics of the network and the IDP system. The data that appears in the Dashboard is real time, and refreshes periodically from the IDP Management Server. The administrator can customise the Dashboard to display only the information that is most important to him, including:
The first step in making the IDP system functional is to create Network Objects for each of the IDP Sensors. A Network Object is the IDP system representation of the components on the network, including:
Network Objects are the basic building blocks used in Security Policy rules to specify both the network components and the Sensor(s) which will protect those components. Attack Objects are used in IDP rules to detect attack signatures and protocol anomalies that could compromise the network being protected. IDP includes a database of several hundred Attack Objects that can be updated weekly - a simple update procedure allows the administrator to connect to the NetScreen Web site or to upload Objects from a file which has been previously downloaded and stored locally. The update procedure provides a detailed report of which Objects are new, which are updated, and which will be deleted - custom amendments can be preserved if required. The administrator has the option to select all the suggested changes or only some of them as required - this is a well thought out update procedure.
Attack Objects are categorised and grouped according to severity first (Critical, High, Medium, Low or Informational), and target application or platform second. This is useful in that it allows the administrator to create a policy which, for example, monitors only for Critical exploits. However, it does make it more difficult to create a policy which only monitors for IIS exploits, since the appropriate Attack Objects would need to be enabled in several different categories. It would be nice if the UI provided to option to group object either by severity or target application/platform. The Object Editor provides the means to view and edit pre-defined Objects, as well as create new ones (including custom signatures). When defining Security Policies in the IDP UI, they take the form of multiple rules laid out in a format that will be very familiar to most firewall administrators. Rules are organised into rulebases, collections of rules that use the same detection method to detect and prevent network intrusions. There are six IDP rulebases which combine to form a Security Policy:
Each rulebase uses a different detection mechanism to protect against intrusions (see architecture section for details). It is possible to have any number of Security Policies stored in the IDP system (three sample Policies are provided as examples), but each IDP Sensor can use only one Security Policy at a time. Installing a Security Policy on an IDP Sensor gives the Sensor a set of instructions about the actions the Sensor should take in response to specific network situations. The same Security Policy can be installed on multiple IDP Sensors, or unique Security Policies can be installed on each Sensor in the network.
When creating custom rules, the administrator defines the patterns or circumstances to be matched against each packet (including protocol, source and destination IP addresses, source and destination ports, flow direction, context within packet, packet contents, and so on), and the actions taken when a match is found. Each Attack Object has five tabs of information which can be accessed via the Signature Editor:
The creation of new signatures is relatively straightforward, although a knowledge of regular expressions would be a requirement in most cases for specification of the exploit patterns to be matched.
The IDP contains a default set of actions that the Sensor can perform against network traffic that matches the specified pattern or circumstance when operating in-line. These actions include :
If the current network traffic matches a rule, IDP can perform an IP action against future network traffic that uses the same IP address. IP actions are similar to other actions in that they tell IDP to drop or close the connection, but they also allow the Sensor to block the attacker for a specified amount of time.
A number of notification options are also available whenever an attempted exploit is detected:
Action and Alert options can only be set at the individual rule level. Given that a single rule could contain a single Attack Object or every single Attack Object available, it could be said that this is as flexible as it needs to be. However, in order to improve readability, most Security Policies would consist of multiple rules. The ability to set Action and Alert options on a global Policy-wide basis would thus be a welcome addition, saving the administrator the effort of having to change these options for every single rule in a Policy if, for example, he wanted to turn on or off packet logging for all Objects. When editing Policies, it is often useful to be able to search for existing signatures that fit specific criteria. The IDP UI contains an excellent search facility which allows the administrator to search for one or more signatures based on various criteria including name, key words, description, CVE reference, BugTraq ID, false positive rating or target application/platform. Finally, it is worth noting that all of the main Sensor operational parameters - such as flow table sizes, flow timeouts, fragmentation reassembly parameters, maximum flows, thresholds, etc. - are exposed in the Settings tab in the Policy Editor. Thus it is possible to alter default values to accommodate environments where, for example, it is necessary to monitor more than the default 100,000 open connections. The default values are adequate for most circumstances, but it is nice to see parameters such as these made available for editing in such a straightforward manner.
Once a Security Policy has been created and verified, it can be deployed to one or more Sensors - a list of Sensors appears during deployment allowing the administrator to select all Sensors (the default), groups of Sensors or an individual Sensor. One useful addition would be the ability to logically group Sensors together in order to select a specific collection of Sensors (those protecting DMZ networks, for example) with a single check box. When creating or editing individual rules within a Policy, it is possible to specify whether that rule applies to all Sensors or one or more individual devices. When the Security Policy is subsequently deployed, the rules become active only on the Sensors selected in the rulebase. This provides the option to have a single global Security Policy, with individual rules activated or deactivated on a per-Sensor basis. Alternatively, it is also possible to create multiple Security Policies to be applied to different Sensors. This is an extremely flexible method of handling Policy creation and deployment, and is a feature we would like to see implemented in more IDS products. A Sensor can only use one Security Policy at a time, and when a new Security Policy is installed, it overwrites any existing policies on the Sensor. Each time Policy is deployed, however, the IDP saves a version of the Policy currently installed. A version is a copy of the original Security Policy, and contains information about when the policy was installed on the Sensors and which user performed the install. It is possible to view, reinstall, and delete previous versions of a Security Policy. However, because policy versions are designed to provide an audit trail of the rules that were operating on a Sensor at a given time, it is not possible to edit previously installed Security Policy versions. The administrator can print and export (as PDF or postscript) all rulebases in a Security Policy. In the Log Viewer, the administrator can view log records that IDP Sensors generate based on criteria defined in the Security Policies. The Log Viewer displays log records in table format and can be modified using filters or column settings. When viewing log entries it is important to be able quickly to access all information relevant to that particular alert. Thus, IDP provides one-click navigation between the Log Viewer (shows incidents), the Session Viewer (shows associated packet contents in detail), and the Security Policy Editor (shows why the incident was triggered). The Signature Editor also contains a References tab that provides links to outside information about the attack, such as the attack CVE number and description.
The ability to access directly the Security Policy that triggered a particular alert is extremely useful when attempting to refine Policies to reduce the incidence of false positives. If an alert is identified as a false positive, the administrator can access the Policy with a single click, disable or tune that Attack Object, and re-deploy the Policy immediately. Log records contain a great deal of data about the activity on the network, but it is not always necessary nor desirable to see all the information at one time. The administrator can use the Log Viewer to manipulate, analyse, and export the information contained in the log records to display only the information that is of immediate interest. For example, using the Log Viewer it is possible to:
Although the main part of the Log Viewer screen provides a tabular view of the log entries, selecting individual entries populates two tabs at the bottom of the screen which provide more detail on the alert in question. The �All Fields� tab duplicates all the data from the log record in a condensed format removing the need to scroll across and thus making it easier to read. The �Summary� tab provides a detailed description of the security event, and includes links to external references (such as the CVE database).
Right-clicking on any log entry brings up a sub-menu which allows the administrator immediately to set filters based on that entry (including or excluding all other similar entries), search for similar entries, show packet data, security policy or attack data, or flag the alert. A number of flags can be set to aid other administrators, including the priority of an alert, whether it is a false positive, whether it has been assigned to an investigator, whether it should be followed up, whether it is pending, or whether it is closed. There is no way to correlate or group related alerts together, however, either automatically or manually. It is possible to create multiple unique, customised views of the log data within the Log Viewer by:
Any number of such customised views can be saved along with all applicable filters enabling them to be recalled and used repeatedly. It is also possible to export your log records for use in other applications. However, to export to XML, CSV, SNMP, SMTP, Syslog, script, or Postgres database format, it is necessary to use the command line interface (although a UI is also available for export to a Postgres database) New log files are created each day automatically. Log records which are no longer needed can be purged from the Management Server database. The administrator can also set the IDP system to automatically purge logs when the Management Server disk space becomes low. Log entries are lost once purged - there is no archive option. There are a number of pre-defined graphical reports included in the UI which are based on log records that summarise threats and traffic behaviour over time.
Reports present log record data using Log Viewer filters. After selecting a report it is possible to set individual options for its appearance, including selecting a date range and chart style. It is also possible to view the log records on which the report table entries are based (by right-clicking on the data to view and selecting the �View in Log Viewer� option), allowing the administrator to �drill down� quickly from a high level graphical summary to a detailed view. In addition to the pre-defined reports, the Log Investigator is designed to provide the administrator with the means to �slice and dice� log entries in various ways, selecting different data sets via the use of filters and include/exclude options to incrementally refine the search for a specific range of entries.
The Log Investigator uses a default filter that selects only log records with the value of ATTACK in the category column of the Log Viewer. The administrator can set additional filters to narrow the focus of his analysis of the data. For example, he might choose to filter by the flag column and have the Log Investigator only consider log records with ATTACK in the category column and a HIGH setting in the flag column. For individual table cells, or entire rows and columns, the administrator can �zoom in� to focus on the destination ports, attacks, or time. The Log Viewer then appears in a separate window, displaying the log records which produced the entries in the Log Investigator. The filters that produced the Log Investigator entries appear on the status bar. Although equipped with Gigabit interfaces, NetScreen rates this product at a maximum of 500Mbps. This rating was verified in our tests when using �normal� traffic, although it does appear as if the current hardware platform is operating at its limits. This can reduce the effective rating in environments which experience very high TCP connection rates, for example. For most �normal� deployments, however, the 500Mbps rating is a true reflection of the device�s capabilities. In terms of day to day operation, the NetScreen-IDP 500 demonstrates high levels of usability with an excellent set of centralised management tools. The three tier architecture should scale well, particularly given the claims for the proprietary inter-device communications protocol and high-performance alert logging database.
The management interface is very straightforward to use, allowing the administrator to create and modify Security Policies easily. Signature updates occur regularly and the update procedure is excellent, allowing the administrator to �vet� the changes before new signatures are downloaded. The facility to create custom signatures is also offered, and is also very straightforward to use. An extensive search facility within the Policy Editor provides the administrator with the means to effect very precise searches for specific signatures, which can then be easily copied or modified. Once Policies have been created or updated, a single button provides the means to deploy them to all Sensors in a single operation. One really nice feature is the automatic version control, with a complete audit trail of all previous Policies applied to each Sensor, and the ability to roll back to a previous version if required. The administrator is provided with a high degree of flexibility and control in how Policies are defined, stored and deployed, and we found Policy management to be very strong in this product. Alert handling, too, was well implemented. Alerts appear quickly at the UI Console, and the descriptions are generally very accurate. It did tend to be on the �noisy� side on occasion, often raising more alerts than we thought were strictly necessary, although in general we could not fault the accuracy of those alerts. The ability to apply filters and drill down to more details views within the Log Viewer and Log Investigator makes it a useful tool for the forensic investigator. One thing it lacks in this area, however, is the ability to correlate alerts - either manually or automatically - in order to group related alerts together into a single �event� for further investigation. All in all, we found the NetScreen-IDP 500 to be easy to install, easy to manage and a good performer up to its rated speed of 500Mbps. Company
name:
NetScreen Technologies Click
here
to return to the Netscreen questionnaire |
Send mail to webmaster
with questions or
|