 |
|
|
Juniper Networks IDP 600F V3.1 The Juniper Networks 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. The IDP 600F is capable of operating in both in-line mode (as an Intrusion Prevention System) or as a passive Intrusion Detection System attached to a SPAN or mirror port on a switch. The IDP 600F is designed for 500Mbps networks and can handle its maximum rated bandwidth under most normal traffic conditions likely to be encountered on a sub-Gigabit network. On a typical network, we would deem the 500Mbps rating to be conservative. Latency is excellent under all conditions and all packet sizes providing the device is not subjected to heavy DOS/DDOS attacks. We recommend that the device is deployed behind an effective attack mitigation appliance. We found the IDP 600F to be to be very stable and reliable, coping with our extensive reliability tests with ease and without blocking any legitimate traffic or succumbing to common evasion techniques. The management system has been well designed to handle management and configuration of large numbers of sensors across the enterprise. Policy definition and deployment is extremely flexible and powerful, and the alert handling and reporting/forensic capabilities are extensive - some of the most flexible we have seen in terms of drill-down and quick reporting capabilities. IDP uses a three-tier architecture that consists of the IDP Sensor, the IDP Management Server, and the IDP User Interface.
With this latest release, Juniper has replaced the old standard Dell hardware with a purpose-built appliance of its own, available in four main versions:
The model submitted for testing was the IDP 600F, a 2U device with Intel Xeon processor rated at 500Mbps, and sporting a total of ten monitoring interfaces (eight fibre and two copper) allowing it to monitor up to five in-line pairs or ten subnets in passive mode. 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 Protection 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. There are four in-line deployment options:
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. IDP operates as an in-line, active device that inspects all traffic and determines what constitutes an intrusion. IDP detection mechanisms can be applied bi-directionally to detect attacks in both client-to-server and server-to-client traffic (as described in the report introduction). 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: Stateful Signature - IDP includes several hundred signature Attack Objects that use stateful signatures to detect known attacks. The administrator can view, create, edit, or delete signature Attack Objects using the Signature Editor in the UI. Compound signatures allow multiple individual signatures (both stateful signatures and protocol anomalies) to be combined into a single compound signature to detect complex attacks in a single session. The language for creating custom signatures includes Perl style regular expressions to make it easier to create signatures that can be used to detect an underlying vulnerability rather than a specific exploit based on that vulnerability. The number of stateful signature fields available when writing custom signatures is over 500. Protocol Anomaly - Protocol anomalies are deviations from the standard protocol. Most legitimate traffic adheres to the published specifications (RFC) for protocols, but traffic that doesn’t produces an anomaly. The IDP system uses the RFC to create protocol anomaly Attack Objects for deviations from the protocol’s published specification. The latest release has added a further eight protocols, bringing the total number of decoded protocols to almost 60. Backdoor - Backdoor detection uses network traffic patterns and heuristics of packet transmissions to detect interactive traffic, a common sign of an attacker using a Trojan or backdoor. Unlike anti-virus software, which scans for known backdoor files or executables on the host system, IDP detects the interactive traffic that is produced when backdoors are used, but without requiring a specific signature. This method ensures that IDP can detect all backdoors, both known and unknown, even if the data is encrypted. Normal bi-directional services (such as FTP) are excluded from the default policies. Traffic Anomaly - A traffic anomaly is a pattern that indicates abnormal network activity such as port scans and other distributed network attacks. The IDP system counts the number of ports scanned in a specified time period and uses this traffic flow analysis to identify scans. IP Spoofing - IP spoofing occurs when a packet uses a fake IP address, and the IDP system detects IP spoofing by comparing the IP addresses of packets to the IP addresses of devices on the protected network. An IP address is considered spoofed if an incoming packet uses an IP address that belongs to a Network Object on the internal network, or if an outgoing packet uses an IP address that does not belong to a Network Object on the internal network DOS Detection - IDP detects and prevents DOS attacks such as SYN floods by ensuring that the TCP handshake is performed correctly. In in-line mode, SYN requests can be proxied by IDP until they are completed successfully. Any incomplete SYN requests can be discarded by IDP after time without affecting the host at which the original request was aimed. Layer 2 Attack Detection - Attackers can manipulate Layer 2 protocols to perform ARP attacks (such as ARP cache poisoning) and other MAC attacks. The IDP system detects Layer 2 attacks by defining implied rules on the IDP Sensor. Implied rules include ARP table restrictions, fragment-handling, connection timeouts, byte/length thresholds for data packets, and other mechanisms. Network Honeypot - Whilst not strictly speaking a detection method, the IDP Network Honeypot impersonates open ports on existing servers in order to lure attackers into attempting exploits for the purpose of evidence gathering. When operating in-line, it is essential that traffic is not interrupted by device failures. It is therefore possible to deploy the IDP system (IDP 200 and above) in a high availability (HA) configuration to provide failure protection, either in a standalone configuration or using third-party hardware. In high availability, two to sixteen 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 dedicated state-sync network interfaces. High availability configurations are available for transparent, bridge, router, and proxy-ARP deployment modes. An integrated hardware bypass is included for all copper detection ports on all models, allowing fail-open operation in the event of failure. Third party bypass units are required to provide the same capability on fibre ports. The IDP Management Server consists of software that manages system resources and data that drives IDP functionality. The IDP Management Server requires an enterprise class server running Sun Solaris 8/9 (SPARC) or Linux RedHat 7.2, 8 or RHEL 3.0 (Intel). It 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 Juniper Networks 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 Juniper Networks also claims offers high levels of performance (over 20,000 events 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. The aim of this section is to verify that the sensor is capable of detecting and blocking exploits when subjected to increasing loads of background traffic up to the maximum bandwidth supported as claimed by the vendor. For each type of background traffic, we also determine the maximum load the IPS can sustain before it begins to drop packets/miss alerts. It is worth noting that devices which demonstrate 100 per cent blocking but less than 100 per cent detection in these tests will be prone to blocking legitimate traffic under similar loads. The IDP 600F was tested as a 500Mbps device, and performance at almost all levels of our load tests was excellent, with 100 per cent of all attacks being detected and blocked under most load conditions. The one exception was Test 4.2.4 where we determined that there was a limit of approximately 8,000 HTTP connections per second (equating to approximately 400Mbps) meaning the test could not be completed. Beyond this limit, legitimate connections began to fail, but all attack traffic was still blocked successfully. However, we would happily confirm Juniper’s 500Mbps rating for this device under normal network conditions, and would actually consider it to be conservative on a typical network. Basic latency figures were very good for a device of this type at all traffic loads and packet sizes, ranging from 86�s with 125Mbps of 256 byte packets, to 145�s with 500Mbps of 1000 byte packets. Behaviour through all of the tests with no background traffic was very predictable, with relatively small increases in latency as traffic levels increased from 125Mbps to 500Mbps across each packet size. Placing the device under a half load of 250Mbps of HTTP traffic we noted small increases in latency across the board, rising from 86�s to 133�s with 250 byte packets, from 111�s to 149�s with 550 byte packets, and from 138�s to 175�s with 1000 byte packets. These results are excellent for a 500Mbps device, and given that HTTP response times were also excellent, we believe that the IDP 600F could be deployed anywhere on a 500Mbps network, either internally or at the perimeter. Whether or not the SYN Protector was enabled, the IDP 600F was unable to handle the 50Mbps of SYN flood traffic we launched during our DOS/DDOS tests. Once we had exceeded the 8000 connections per second (i.e. 8000 SYNs per second) maximum we discovered in the HTTP stress tests, the device became unresponsive, effectively blocking all traffic, both malicious and legitimate. More effective SYN protection is planned for a future release, but for now we recommend the IDP 600F is deployed behind an attack mitigation device or firewall with full DOS/DDOS mitigation capabilities. The IDP 600F performed consistently and completely reliably throughout our tests. Under eight hours of extended attack (comprising millions of exploits mixed with genuine traffic) it continued to block 100 per cent of attack traffic, whilst passing 100 per cent of legitimate traffic. Exposing the sensor interface to ISIC-generated traffic had no adverse effect, and the device continued to detect and block all other exploits (as well as raising ISIC-related alerts) throughout and following the ISIC attack. Please refer to the Testing Methodology section for full details of the methodology used and performance results. We installed one IDP 600F sensor with the latest signature set. The Security Policy was created from scratch, switching on all Attack Objects including Critical, High, Medium and Low (omitting only Informational signatures, which are more suited to auditing purposes), as well as turning on Backdoor Protection and the SYN Protector. We also enabled fragmented packet detection and flow error detection in order to identify certain DOS and ICMP attacks. Finally, we disabled all HTTP server-to-client signatures for performance reasons. These would not generally be required for a typical internal deployment, where performance would be paramount. There is a severe performance impact when enabling HTTP server-to-client signatures, reducing throughput of the device to 200-250Mbps and making it more suitable for a perimeter deployment. Signature recognition (with blocking disabled) was excellent out of the box at 95 per cent. This figure was increased to 97 per cent following a signature pack update which Juniper provided within 48 hours. Blocking performance was identical throughout the tests. Note that with the HTTP server-to-client signatures enabled, the attack recognition rose to a perfect 100 per cent (though with a corresponding decrease in maximum performance as a result). All of our “false negative” (modified exploit) cases were detected correctly out of the box, demonstrating that the Juniper signatures are generally designed to detect the underlying vulnerability rather than a specific exploit. A major concern in deploying an IPS is the blocking of legitimate traffic, and the IDP 600F did block three of our false positive test cases out of the box. This was rectified following the signature update, after which we noted no further false positives throughout the rest of the testing. The IDP 600F comes with a number of suggested Protection Policy templates to aid the administrator when setting up initially. These include suggested policies for file servers, Web servers, DNS servers, and a typical “default” policy, and are based on a number of carefully constructed Dynamic Groups which will allow Juniper (or the administrator) to modify these policies automatically with each signature update. Resistance to known evasion techniques was excellent, with the IDP 600F achieving a clean sweep across the board in all our main evasion tests. Fragroute, Whisker, ADMmutate and even RPC record fragging all failed to trick the IDP 600F into ignoring valid attacks. Not only were the fragmented and obfuscated attacks blocked successfully, but all but one of them - a single fragroute evasion - were decoded accurately as well when not blocking. Only a couple of miscellaneous FTP evasion techniques were effective in evading the device - although we do not consider this to be too serious, it is a situation which we would prefer to see remedied as soon as possible, and Juniper is working on a solution at the time of writing. Out of the box, the device maintained state on up to 100,000 open connections, successfully detecting our half-open exploit as it was completed. It also continued to detect and block new exploits as we maintained 100,000 open connections, and no legitimate traffic was blocked during this stage of these tests. With a simple change to the flow-related parameters in the GUI, it was possible to maintain state across 500,000 open connections (though Juniper actually recommends 220,000 as the maximum on this device). Default operation of the device is to refuse new connections when the state tables are full or resources are low, meaning that legitimate traffic is blocked and new attacks are not alerted. However, state is maintained completely on existing flows and attack traffic should never be allowed through the device. Stateless “exploits” are not alerted upon (this is correct behaviour in order to be resistant to Stick and Snot tools), and mid-flows are blocked by default. It is not possible to configure the device to allow mid-flows. Please refer to the Testing Methodology section for full details of the methodology used and performance results. This part of the test procedure consists of a subjective evaluation of the features and capabilities of the product, and covers installation, configuration, policy editing, alert handling, and reporting and analysis. Installation is very straightforward. The Management Server can be installed on any secure and trusted Sun Solaris 8/9 (SPARC) or Linux RedHat 7.2/8 or RHEL 3.0 (Intel) host. 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 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 User Interface (UI) is installed - versions are available 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 600F 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 thanks to the ability to apply individual rules to specific sensors within the same policy. 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).
The UI contains eight main components:
Each of the above options is accessed via a hierarchical menu tree in a pane on the left of the UI (some of the above options have several sub-levels within the menu tree), 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 (though it can be slow to refresh when the number of alerts is excessive). The data that appears in the Dashboard is real time, and refreshes periodically from the IDP Management Server. It is possible to drill-down quickly from the high-level display to the detailed events behind it. 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. Objects are the IDP representation of the components of the system, 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 are updated daily - a simple update procedure allows the administrator to connect to the Juniper Networks 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 (a nice touch, and one we would like to see more often in other products) - 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 very 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. The concept of dynamic groups of signatures allows the administrator to create groups which will be updated automatically as new signatures are added to the product. Dynamic groups make it possible to categorise signatures by various properties including vendor (i.e. all Microsoft applications), application (i.e. all IIS or Apache signatures), protocol (i.e. SMB only), direction (i.e. client to server), severity (i.e. critical only) and potential for false positives (i.e. never). These filters can be combined in many different ways, allowing the administrator to build very specific groups (i.e. all critical SMB signatures that are client-to-server and have a low possibility for false positives) or wide-ranging ones (i.e. all Microsoft applications). Whenever signature updates are downloaded, the appropriate signatures are added to the correct dynamic groups automatically, ensuring, for example, that your IIS policy automatically includes all the latest IIS signatures with no intervention required. This is an excellent feature, and is used extensively by Juniper to create some very useful default Policy templates.
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 seven 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 (several Policy Templates are provided to help kick-start the definition process), 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 seven tabs of information which can be accessed via the Signature Editor:
The creation of new pattern-matching 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. Protocol anomaly signatures can neither be edited nor created from scratch, since these require extensive coding and can thus only be added or modified by Juniper Networks developers. However, IDP does include the ability to define Compound Signatures, which allow multiple individual signatures (both stateful and protocol anomaly) to be combined into a single signature to enable detection of complex exploits. This is an extremely powerful and flexible capability, providing for the creation of some very complex and accurate custom signatures.
IDP is one of the more open systems currently available, providing the means to copy and edit the built-in Attack signatures. All of the critical fields from the protocol decoders are exposed to the UI, and can be used in regular expressions to match for suspicious traffic. Note that this is more than simply “pattern matching”, where a signature has to look for a particular pattern in a lengthy data stream. Instead, it is possible for an individual field - say the FTP user name - to be isolated and used in complex expressions. These can then be combined together (perhaps looking for a particular user name followed by a password greater than a specified length) into the aforementioned Compound Signatures. 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 a 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. This is available at both the Attack Object level and within the Policy Editor (the latter being a very welcome new capability in the V3.0 release). It does, however, only find signatures one at a time, requiring you to keep pressing “next” in order to find all matches for a given search. It also allows you to search on only a single parameter at a time. It would be nice if it allowed the specification of multiple parameters in a single search and returned multiple signatures in the result set, perhaps then allowing the application of bulk edits to the entire group.
The Exempt rulebase allows the administrator to specify that certain legitimate traffic be ignored for the purposes of matching for exploits. For example, vulnerability scanners can trigger many signatures, and so it would be possible to define rules that allowed a specific machine to scan one or more servers on the corporate network without hindrance. These rules can be defined manually, or by selecting an alert and clicking on the “Exempt” menu option. The latter method is ideal for rapidly fine tuning a security policy based on false alarms which may have been raised. 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), the Signature Editor (shows why the incident was triggered), the Security Policy Editor (shows which Policy triggered the event), the Enterprise Security Profiler (ESP) (provides an on-demand view of network activity for detailed analysis), and the Security Explorer (provides a means to focus on a particular host, showing all activity relating to it specifically).
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, as well as an Extended Information tab that provides detailed vulnerability and exploit information from the TruSecure IntelliShield database. 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 four 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 (including extensive material from the TruSecure database), and includes links to external references (such as the CVE database). The remaining two tabs at the foot of the screen provide an instant whois lookup for the selected IP address, and access to detailed host, application and networking information collected by the Enterprise Security Profiler (ESP) module (covered in more detail in the Reporting and Analysis section). Right-clicking on any log entry brings up a sub-menu which allows the administrator immediately to:
A number of flags can be set to aid other administrators, including the priority of an alert, and whether it: is a false positive; has been assigned to an investigator; should be followed up; is pending; 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 from the Log Viewer menu. It is also possible to export log records for use in other applications - PDF and Postscript options are available from the GUI, and export to XML, CSV, SNMP, SMTP, Syslog, script, or PostgreSQL database format can be achieved via the command line interface. The latest drill-down operation is always saved in the Drill Down window in the Log Viewer menu hierarchy, thus providing a means for the administrator to switch quickly between drill-down data and higher-level information. Multiple instances of the Log Viewer can also be spawned, each in a new window and each containing unique views of the log data. In addition to alert entries, the Log Viewer also provides access to Profiler Logs (information on individual hosts acquired by the Enterprise System Profiler (ESP)), Scans, and Traffic Logs (including fragmentation errors, flow-related errors, and so on).
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. These include the following:
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.
Custom reports provide the administrator with the means to specify his own selection criteria, report content (from a list of data collected for each alert), time period and report style (count or time based, bar or pie chart). These can be named and saved in the Custom Report section of the main menu tree. In addition, “Quick Reports” can be created rapidly from the Alert Viewer based on criteria taken directly from the alert being viewed at the time, and these too can be saved in the Custom Reports section for later use. The Log Investigator is designed along the lines of a dynamic “reporting spreadsheet” and is intended to provide the administrator with the means to “slice and dice” log entries in various ways. It allows him to select 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 choose which criteria he wishes to see on the left and right axes of the table, and then 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. The Enterprise Security Profiler (ESP) is intended to help administrators monitor their network security posture by collecting forensic data on network traffic and storing that data to form a network profile. Data can then be used to identify changes in network behaviour, which in turn can be translated into policy modifications. In addition to being a proactive analysis and planning tool, data collected by ESP provides administrators with a useful post attack analysis tool. The way ESP works is that it stores data already collected during the attack detection process, and makes that available via a number of database views and filters. The administrator needs to first configure the system to collect Profiler data - it does not do this by default (since this would have an impact on overall performance of the sensor - note that the Profiler was disabled for our performance testing). ESP collects data at both the network layer and the application layer. Network information collected includes items such as IP addresses (host connected to and from), and port number, whilst application level data includes items such as the actual application used over the network (IE, Apache, IIS, and so on), version number, user name, and URL.
Data on individual hosts (IP address, MAC address, host name, protocols used, ports used, etc.) is stored and displayed within the Profiler (it has its own menu option) as well as against each alert in the Alert Viewer, where it populates its own Profile Information tab in the alert details window at the bottom of the main Alert Viewer screen. Once the Profile Information tab has been selected for a particular alert, the administrator can choose from a number of display options in a drop down menu, offering host detail, TCP ports used, UDP ports used, RPC services, layer 3 protocols used, and details of other machines with which the host has communicated. The Profiler view - selectable via the main menu tree - provides a direct view into the Profiler database. A number of selection criteria are available to enable the administrator to examine which clients are communicating with which servers, which protocols are being used, and which applications are being run over his network. There are three different views in the Profiler to help administrators zero in on the information they need: the Network View for layer 3 and 4 information, Application View for layer 7 data, and Violation View for pseudo firewall policies that help pinpoint what an administrator may not know about the network. The Network View provides data filtered and displayed on source and destination IP address, port number, MAC address, and so on. The Application View can often be much more interesting, since it displays the context of each suspicious activity, including the server name and version, the actual command issued, the URL requested, and so on. Thus it is a simple matter to focus on FTP servers, then select all those occasions where someone tried to log in as root or administrator. Likewise, it would be a simple matter to focus on a particular version of Apache or IIS, and then see what activity has been aimed at that particular server or group of servers. This information can then be used to set Violation rules, to ensure that only valid client-server communications are allowed across the network. For example, the administrator can define that FTP traffic is allowed only between one particular group of IP addresses and one particular FTP server, or that Telnet traffic is not allowed at all. This way, IDP can detect and prevent malicious traffic based purely on policy violations rather than specific exploits. The Enterprise Security Profiler is an extremely useful feature, and one that goes beyond pure intrusion detection or prevention, and into the realms of policy enforcement.
The final forensic and reporting tool is a recent addition to the product - the Security Explorer. By selecting a particular IP address from the source or destination field of any alert using ALT-left mouse click, the administrator gains immediate access to a number of different views of all the data pertaining to that address. The most striking is the useful graphical representation of the relationships between the selected host and all other hosts with which it has interacted or attacks which have involved it. The view is selected from a drop-down menu which allows the administrator to select Top Attacks, Top Attackers or Top Targets in the last 24 hours. The graphical display “swims” around the pane, reorienting itself depending on which node (or connection between two nodes) is selected as the main point of focus, and any node can be double-clicked to bring up a new tab with the focus on the node selected. Selecting various points on the graphical view brings up summary information of the active services on a particular host, network addresses used, attacks seen and context information. Below this is the normal Log Viewer display containing a list of all the alerts pertaining to the IP address selected. This free-format display is actually more difficult to explain than it is to use, but it can be an extremely powerful alert handling and forensic tool, allowing the administrator to simply “wander around” the most recent data pertaining to a particular host at will. Performance The IDP 600F is rated at 500Mbps when deployed in-line, and performance at almost all levels of our tests was very good, with 100 per cent of all attacks being detected and blocked under all but the most extreme (10,000 connections per second) load conditions. Even when pushed beyond its limits (8,000cps), the IDP 600F continued to block all malicious traffic successfully. We would happily confirm Juniper Network’s 500Mbps rating for this device under normal network conditions, and would deem it conservative in a typical network environment. Basic latency figures were very good for a device of this type at all traffic loads and packet sizes. Behaviour through all of the tests with no background traffic and with a half load of 250Mbps of HTTP traffic was very predictable, and HTTP response times were also very good. Overall, the results were excellent for a 500Mbps device, and we believe that the IDP 600F could be deployed anywhere on a 500Mbps network, either internally or at the perimeter. Whether or not the SYN Protector was enabled, the IDP 600F was unable to handle the 50Mbps of SYN flood traffic we launched during our DOS/DDOS tests, and until a more effective SYN protection mechanism is implemented, we recommend the IDP 600F is deployed behind an attack mitigation device or firewall with full DOS/DDOS mitigation capabilities. The IDP 600F performed consistently and completely reliably throughout our tests, and resistance to ISIC-generated traffic was complete. Security Effectiveness Signature recognition (with blocking disabled) was excellent out of the box at 95 per cent. This figure was increased to 97 per cent following a signature pack update which Juniper provided within 48 hours. Blocking performance was identical throughout the tests. Note that with the HTTP server-to-client signatures enabled, the attack recognition rose to a perfect 100 per cent (though with a corresponding decrease in maximum performance as a result). It is unfortunate that the HTTP server-to-client signatures come with such a performance impact, but at least Juniper includes this capability, giving the administrator the choice between total coverage at the expense of performance, or slightly reduced coverage (irrelevant in a purely internal deployment) with maximum performance. All of our “false negative” (modified exploit) cases were detected correctly out of the box, demonstrating that the Juniper signatures are generally designed to detect the underlying vulnerability rather than a specific exploit. The IDP 600F blocked three of our false positive test cases out of the box. However, this was rectified following the signature update, and we noted no further false positives throughout the remainder of the testing. Resistance to known evasion techniques was excellent, with the IDP 600F achieving a clean sweep across the board in all our main evasion tests. Fragroute, Whisker, ADMmutate and even RPC record fragging all failed to trick the IDP 600F into ignoring valid attacks. Out of the box, the IDP-600F handled 100,000 open connections, and 500,000 connections after tuning (the supported maximum is 220,000) - acceptable for a 500Mbps device. Default operation of the device is to block new connections when the state tables are full or resources are low, and this behaviour is not configurable. It would be nice to see a choice offered to the administrator of whether to age out old connections or block new ones. The IDP 600F comes with a number of suggested Protection Policy templates to aid the administrator when setting up initially - these include suggested policies for file servers, Web servers, DNS servers, and so on, along with a typical “default” policy. These are based on a number of carefully constructed Dynamic Groups which will allow Juniper to modify these policies with each signature update, adding new signatures automatically, or moving signatures between alert and block modes as confidence in a new signature increases. Usability In terms of day to day operation, the IDP 600F 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. We did notice that this management solution performed significantly better than others in our labs when under heavy attack, with little or no interruption to communication between Sensor and Management Server. The management interface is very straightforward to use, allowing the administrator to create and modify Security Policies easily. Signature updates occur daily 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 available, 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. In this respect, Juniper Networks IDP is one of the most open systems we have seen, and the Compound Signature capability provides the means to create some very complex and accurate signatures. 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 (with the ability to configure individual rules within a Policy for individual Sensors), 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. The ability to apply filters quickly and easily (often by simply right-clicking on a value in an alert and selecting an option from a drop-down menu) and drill down to more detailed views within the Log Viewer and Log Investigator makes it a useful tool for the forensic investigator. A wealth of useful forensic/reporting features include the ability to create custom views and reports, Quick Reports (created from the Alert Viewer), the unusual Security Explorer, and the excellent Enterprise Security Profiler. The latter provides the means for the administrator to take IDP beyond pure intrusion detection and prevention, and into the realms of policy enforcement, increasing its usefulness in many corporate environments. All of these combine to make the IDP 600F one of the strongest products in terms of alert handling, reporting and forensic analysis that we have seen. Company
name: Juniper Networks Click
here
to return to the Juniper questionnaire |
Send mail to webmaster
with questions or
|