 |
|
|
Based on a mix of off-the-shelf and custom-designed processors, the McAfee IntruShield system is a high-performance appliance that offers real-time network intrusion detection and prevention against known, unknown, and Denial of Service attacks for enterprise networks. The IntruShield system enables network attack detection and prevention at up to 2 Gbps, and is capable of operating in-line, or as a passive IDS, or both at the same time using different ports in the same appliance. The product line includes the IntruShield Security Management (ISM) system and a range of dedicated appliances covering bandwidth requirements from 100Mbps to 2Gbps, and deployment scenarios from SMB/Branch Office to ISP/MSP/Enterprise core. The performance of the device submitted for testing - the IntruShield 4010 - was very impressive, combining near-perfect security effectiveness with excellent latency under all traffic loads. It also handled our demanding extended false positive, false-negative and evasion tests easily, and without blocking any legitimate traffic or succumbing to common evasion techniques Management and control capabilities are outstanding, and despite the Java-based IMS looking to be ready for a change (this is currently in the pipeline), it still provides extremely powerful and flexible means of controlling anything from a single device to a large enterprise-wide deployment. The admin domains and user roles make it easy to delegate the most fine-grained control across the largest organisation, whilst the rule-based policy definition makes it easy to define complex policies which can then be rolled out to a single sensor or the entire network at the click of a mouse. And once the policies have been applied, the alert handling and forensic analysis capabilities are feature-rich and very flexible. The Virtual IPS capability was unique when the product was first launched, and now other vendors are clamouring to emulate it. This enables the administrator to apply separate policies right down to individual host level if required. The internal firewall is also a useful feature, providing the means for an administrator to apply firewall rules in the core of the network without having to deploy a layer 3 device, and to implement McAfee’s concept of the internal “Virtual Perimeter”. Finally, the SSL decryption capability is unique at the time of writing and enables IntruShield to decrypt selected SSL traffic on the fly and apply detection and protection capabilities to that traffic. The IntruShield offering is available as a range of dedicated, purpose-built hardware appliances, managed by a centralised, scalable management system. The main components of the IntruShield system are as follows: Six purpose-built IntruShield appliances are available:
The device submitted for testing was the top-of-the line, newly released IntruShield 4010. Designed for high-bandwidth links in enterprise and service provider environments, it is equipped to support up to twelve SPAN ports or six in-line connections, or any combination of the aforementioned for up to 2Gbps of aggregated traffic. The 4010 is a 2U rack mount unit which contains three redundant fans and can contain two hot-swap power supplies (a second redundant power supply needs to be purchased separately). The 4010 is equipped with the following ports:
High Availability (HA) options are well covered with the IntruShield product range, covering everything from multiple redundant components (such as fans and power supplies) to full-blown HA configurations with multiple IntruShield sensors. The 4010 supports active-active failover for High Availability (HA) configurations. The two sensors that make up a failover pair are interconnected using two Gigabit failover interfaces, and each sensor mirrors all of the traffic on its monitoring interface(s) to the second sensor in the failover pair via the failover interfaces. Should either device fail it will fail closed, and the second device continues to function normally without losing state on any existing connections. The IntruShield architecture allows for the creation of multiple Virtual Intrusion Prevention Systems (VIPS), an extremely useful feature which was unique when IntruShield was launched, and which only now competitors are scrambling to emulate. Up to 1000 Virtual IPS domains can be set up for specific departments, geographic locations or functions within an organisation, and security policies can then be set for each Virtual IPS. The VIPS functionality can be implemented in three ways:
CIDR-based VIDS implementation allows granularity down to an individual host level. For example, DoS attacks can be identified and responded to with unique policies for individual hosts. Dedicated Management Domains can be assigned at the sub-interface level. This allows for greater control of the personnel tasked with managing the security infrastructure. For example, operators can have rights assigned to one Management Domain while being restricted from having access to any other defined system Domains. This granularity in operator control increases the overall accountability and security of the installed system, ensuring that individual administrators are only permitted access to their own ports or appliances, to their own alerts and their own reports. This makes IntruShield one of the few devices suitable for a true Managed Services environment. Internal Firewall Adding firewall capabilities inside the network perimeter has considerable advantages when the firewall is also part of the IPS appliance. IPS devices are normally installed at Layer 2 as a “bump in the wire”, removing the need to allocate IP addresses to the interfaces and renumber networks on either side - a typical administrative overhead when deploying traditional Layer 3 firewall devices in the network core. In addition, the provision of multiple ports on a single appliance provides the means to firewall traffic between a number of different networks using a single device. IntruShield incorporates a simple packet-filtering firewall capability, allowing it to filter and permit/deny packets based on IP address, port number and protocol, while eliminating the more costly firewall elements (both in terms of cost, and deployment effort) such as Network Address Translation (NAT) and Virtual Private Networks (VPN). This is not, therefore, intended as a replacement for the corporate firewall, but merely as a complement. With firewall capabilities integrated into the IPS appliance, for example, the opportunity arises to impose far more granular security policies within the corporate network. It is possible to enforce different security policies for each pair of ports - and thus a different security policy for each subnet. Outbound HTTP traffic can therefore be permitted from all client machines, while being denied from HTTP servers, thus preventing the propagation of harmful Trojans should an HTTP server be infected. Likewise, the inbound SMTP traffic can be denied to all machines other than the mail server. Nor is it necessary to rely on the IPS device purely for the prevention of malicious traffic. Instead, by simply applying ACL rules that restrict access to certain resources from specific parts of the corporate network, it can also be used to enforce generic corporate security policy. The provision of firewall capabilities on the IPS device has one other important advantage, especially when deployed in the core of the network. Given that the analysis of packets and streams for malicious traffic is the most difficult task it has to perform, the elimination of a significant portion of that traffic based on simple firewall rules (i.e. simply deny all HTTP traffic to a network segment with no Web servers) can help to ensure that the detection engine is never stressed. This can potentially improve scalability of the overall security solution and permit much higher total levels of traffic to be handled by all the IPS devices on the network. SSL Decryption Protecting against malicious traffic contained within encrypted SSL streams has hitherto been impossible using in-line IPS devices. Historically the only practical method for protecting against SSL-encrypted attacks has been with the use of host IPS solutions, which can inspect the traffic coming into the host after it has been decrypted, or monitor the behaviour of the underlying system to mitigate an attack after it has entered the system. IntruShield now provides the means to protect against SSL-encrypted attacks in-line by inspecting the SSL data stream, decrypted on the fly using a copy of the server private key securely stored on the sensor. When a client initiates a connection request to the SSL server, IntruShield recognizes the SSL session request and monitors the SSL session initiation transaction between the client and the server. During the SSL session establishment phase, IntruShield uses the server’s private key to decrypt and inspect the data and to determine the session keys. With these session keys, the IntruShield sensor can decrypt data packets for the life of the SSL connection. As an encrypted packet enters the sensor, IntruShield copies the encrypted packet, decrypts and then inspects the contents of the packet. The original packet is temporarily stored in a buffer in the sensor during the inspection phase. In the case of non-attack SSL traffic, the original packet is released from the input buffer to the destination and the data from the detection engine is discarded. This approach ensures the integrity of the original packet and relieves the sensor from the overhead associated with re-encrypting the packet. Upon detection of an attack, IntruShield can be configured to block the attack packet, allow the packet to pass while raising an alert, or allow the packet to pass without raising an alert. If an attack is detected within the packet and the system is configured to block the attack, the original packet stored in the buffer is dropped and the sensor sends notification to the ISM to log and/or send an alert to the designated operator(s). IntruShield can protect multiple SSL servers that use different private keys automatically. All SSL sessions are processed and tracked in separate input queues in the sensor. Overall performance is maintained via the use of custom silicon processing engines incorporated into the sensor. Protection of the SSL Private Key is paramount, and IntruShield uses a number of mechanisms to ensure key confidentiality. Private keys are encrypted and exported from the SSL Server in PKCS #12 format and are imported into the IntruShield ISM via portable media, writable CD, floppy disk, etc. The encrypted key is imported into the IntruShield ISM and is encrypted again with the public key of the IntruShield sensor on which it will be used. When the Sensor is configured to perform SSL inspection, the ISM pushes the encrypted key to the sensor. The sensor decrypts the key with its private key and stores the resulting clear text SSL Private Key in volatile memory in the sensor. Should someone gain unauthorised access to the IntruShield ISM the value of the SSL Key can not be determined without the possession of the Sensor Private Key that is generated and stored on the Sensor itself. If the Sensor is physically stolen, the unencrypted copy of the Private SSL Key is lost as soon as power is removed from the Sensor, or a re-boot of the Sensor is performed. The Private SSL Key is never transmitted or stored in unencrypted format and only exists in an unencrypted format in volatile RAM within the Sensor. IntruShield Security Management System (ISM) The IntruShield Security Management (ISM) system is the management solution for managing IntruShield sensor appliance deployments for large and distributed enterprise networks. ISM offers features to define, distribute, enforce, and audit security policies to protect critical servers, data centres, individual departments, distributed branches, and remote offices of a global business. There are two versions of the ISM system:
The ISM server is a dedicated Windows or Sun Solaris platform running the Manager software. Depending on the server platform used and the amount of alert and logging activity on the network, the ISM can manage hundreds of sensors. Sensors use the 10/100 Management port to communicate with the ISM server over a secure, encrypted link. The ISM software provides a Web-based user interface for configuring and managing the IntruShield system. IntruShield users connect to the ISM server from their workstations through a standard Web browser. New signatures and software patches are made available to customers over the Internet via the Update Server, which provides secure, fully automated, real-time signature updates without requiring any manual intervention. According to a user-configured schedule or via a manual process, the ISM polls the Update Server, and compares the file on the Update Server with what is already available in the ISM server to determine what needs to be downloaded. Once it has received the update, the ISM then determines what signatures need to be pushed out to sensors based on the policy applied to the sensor. For example, a policy defined for a Windows environment will receive only updated signatures that apply to that environment. The ISM compiles a specific update for each sensor and the update can then be pushed to sensors either manually, in an automated, real-time fashion or via automatic scheduled updates. One nice feature of IntruShield is that it maintains state completely during a signature update, and new signatures are even applied to subsequent packets of existing flows. 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. Note that although MacAfee rates the IntruShield 4010 as a 2Gbps device, it was tested to a maximum of 1Gbps in this round of testing. As you would expect with this amount of headroom, performance at all levels of our 1Gbps load tests was impeccable, with 100 per cent of all attacks being detected and blocked under all load conditions. We also ran some tests up to the maximum of 2Gbps, and under normal network conditions, we would have no hesitation in rating the IntruShield 4010 as a true 2Gbps device. Latency figures were excellent across the board with all packet sizes (even down to 64 byte packets) and all traffic loads. Latency ranged from 63�s with 250Mbps of 256 byte packets, to 127�s with 1Gbps of 1000 byte packets. Behaviour throughout the tests with no background traffic was very predictable, with minimal increases in latency as traffic levels increased from 250Mbps to 1Gbps across each packet size. Placing the device under a half load of 500Mbps of HTTP traffic, we noted significant increases in latency, although all results remained below the “magic figure” of 300 microseconds - our limit for deploying in-line devices in the core of the network. HTTP response times were also very good, meaning IntruShield could be situated anywhere on a Gigabit network, either internally or at the perimeter. Using the SYN proxy capability, SYN Flood mitigation was almost total, and 100Mbps of SYN flood traffic had a minimal effect on latency of normal traffic through the device. Average HTTP response increased from 204ms to 1716ms during the SYN flood, although no legitimate traffic was blocked during the attack. The IntruShield 4010 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 extreme levels of ISIC-generated traffic had no adverse effect, and the device continued to detect and block all other exploits 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 sensor with the latest signature pack, and utilised the “All inclusive With Audit” policy provided out of the box - this policy has every attack signature and every audit signature (almost 1800 in total) enabled. Signature recognition was excellent out of the box (95 per cent), and was increased to a perfect 100 per cent after the application of a signature pack update which was provided to us in under 24 hours. Blocking performance was identical throughout the tests. We noted a minimum of “noise”, with very few test cases raising multiple alerts for a single exploit, and the accuracy of the exploit descriptions was high. Performance in our “false negative” tests was very good out of the box, and there is every indication that the majority of signatures are written for the underlying vulnerability rather than specific exploits. Specific exploit signatures are also included where appropriate, however, to provide more accurate identification for the administrator. A major concern in deploying an IPS is the blocking of legitimate traffic. IntruShield’s resistance to false positives was excellent in our tests, and was increased to a perfect 100 per cent following the signature update. IntruShield arrives with a number of default policies configured for different environments and with sensible PASS and BLOCK actions set for appropriate signatures. Resistance to known evasion techniques was excellent, with IntruShield achieving a clean sweep across the board in all our evasion tests. IP packet fragmentation, TCP stream segmentation, URL obfuscation, shell-code mutation, FTP evasion and RPC record fragmentation (ONC and MS-RPC) all failed to trick IntruShield into ignoring valid attacks. Not only were the fragmented and obfuscated attacks blocked successfully, but all of them were decoded accurately as well. The IntruShield 4010 demonstrated perfect performance in our stateful operation tests out of the box, handling over 1 million open connections with no tuning required. Default operation of the device is to age out “least used” connections when the state tables are full or resources are low - this behaviour is not configurable. 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 possible to configure the device to permit mid-flows if required. 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 of the IntruShield Sensor and ISM software are very straightforward. We installed ISM on a Windows 2003 host, and all that was required was to insert the CD and run the set-up program. During installation, the Java Runtime Environment (JRE) is installed on the ISM host if it was not already installed. On firing up the Console for the first time, it is necessary to add each Sensor to the Resource Tree using the System Configuration Tool. Each Sensor is given a unique name and shared secret to secure the initial public key exchange between ISM and Sensor. At the Sensor itself, it is then necessary to initiate a CLI session via a PC attached to the serial console port. A few simple CLI commands are all that is required to set the Sensor name, shared secret and the IP configuration of the management port, at which point the Sensor establishes communication with the ISM, secures the connection, and makes itself available for remote management functions. By default, the twelve Gigabit micro-GBIC interfaces (which can have either fibre or copper GBICs installed) come up in In-Line mode, each with the Default In-Line IPS policy applied, and thus the IntruShield Sensor is ready to run out of the box as an in-line IPS device with six in-line connections. The 4010 is capable of operating in one of three modes:
Deployment modes can be mixed on a
single sensor, allowing two ports to be deployed in-line, another two to
passively monitor two separate network segments, and so on. For our
tests, we configured one port pair in In-line mode and
applied the Default In-Line IPS policy.
Extensive, and extremely useful, documentation in electronic format accompanies the IntruShield ISM and IntruShield sensors (hard copy versions are available to purchase). This documentation set consists of:
The IntruShield product line has been developed from the ground up with high-speed switched networks and large-scale distributed deployments in mind. The thought that has gone into this is evident both in the hardware and the management software, the latter demonstrating some extremely sophisticated features. One of those which will appeal most to administrators of larger distributed networks is the administrative domain.
The admin domain is an organisational tool used specifically to group IntruShield resources so that management of the resources can be delegated to specific IntruShield users. An admin domain can contain other admin domains, sensors, sensor interfaces, and sensor sub-interfaces. This administrative domain concept enables enterprises to create a central authority that is responsible for the overall IntruShield system, and to allow this central authority to delegate day-to-day operations of IntruShield security resources to appropriate entities - business units, geographic regions, IT departments, individual security personnel, and so on. Although it is possible to manage an entire set of IntruShield security resources from a single domain, if it is desired to delegate responsibilities for managing those resources among multiple individuals within an organisation then it is necessary to create one or more child domains. The top level admin domain is called the Root Admin Domain, and users with Super User access to the Root Admin Domain have complete control over the entire administrative domain and all resources within it, including any child domains. Initially, Policies are inherited from the parent domains, but they can subsequently be changed at a child domain level. To delegate responsibilities, user accounts are created and allocated a role that defines how the user can interact with the resources in the child admin domain. The Root Admin Domain can be divided into child domains that are large, from a resource perspective, delegating management of all the IntruShield resources protecting multiple geographic regions. Or the domains can be very small - a few interfaces on a single sensor, or even a VLAN tag or single CIDR address within a segment of traffic transmitting between two hosts in the protected network.
Child domains can be further broken down into smaller sub-domains in order to provide a very fine degree of management granularity. Administrative domains are graphically represented in the Resource Tree of the ISM Console as a hierarchical tree structure. Resources in the IntruShield system are represented as nodes on the Resource Tree. When a user logs into the Console, he will be presented with only those nodes that have been delegated to his particular domain or sub-domain. In addition, he will only be able to see alerts that relate directly to the nodes and resources under his administrative control. The ISM Console is a Web-based Java application that can be run from any PC on the same network as the management port of the ISM server. The ISM hosts the central alert database (MySQL by default, though Oracle is also supported) and performs all the necessary alerting and reporting tasks for the IntruShield system. All the Sensors report back to the ISM host. When first logging on to the Console, the administrator is presented with a graphical overview “dashboard” display called the Network Console. This provides an at-a-glance indication of the sensor health via a coloured indicator, and an unacknowledged alert summary which shows totals of high, medium and low level alerts that have not yet been acknowledged. A hyperlink below each of these provides instant access to the System Health Status screen and the Alert Viewer, and additional buttons provide access to the Configuration and Reporting utilities. The System Health Status provides a colour-coded (red, green or yellow) summary of the health of various system components, including the ISM, the Sensor and the database. Where the status is not green, hyperlinks provide instant access to the events that caused the problem, and system faults - like alerts - can be forwarded by severity to either an SNMP or Syslog server, sent to an administrator via e-mail or pager, or processed via a script. Once the events have been investigated and resolved, they can be acknowledged and the status will return to green.
The System Configuration utility provides a hierarchical Resource Tree down the left of the screen, and one or more tabbed configuration screens on the right. In addition to providing the ability to manage users and domains as mentioned earlier, the System Configuration utility also enables the administrator to configure system notification parameters (e-mail, pager, SNMP syslog or script), perform database backups and restores (these can be on demand or scheduled), acquire software and signature updates from the Update Server (on demand or scheduled), carry out system file maintenance operations (deleting old log file entries, for example, on demand or scheduled), manage LDAP and RADIUS authentication mechanisms, create custom signatures, and create, edit and deploy security policies. Note that signature updates can be rolled out to all sensors at the click of a button and applied to each sensor in real time without requiring a reboot. It is also possible to roll back to a previous signature pack version just as easily. State on existing connections is maintained during a signature update, and new signatures are even applied to subsequent packets of existing flows - this kind of continuous operation is very reassuring to administrators when deploying in-line devices. Both sensor and policy configurations can be exported and imported between ISM servers. This would allow an administrator to operate both staging and production version of the ISM, and easily move configuration information between them. When working with IntruShield policies, the term attack is used rather than signature. An attack as defined in IntruShield is comprised of one or more signatures, where each signature is a method of detecting an attempt to exploit a particular vulnerability in a system. These signatures may contain very specific means for identifying a known exploit of the vulnerability, or more generic detection methods that aid in detecting unknown exploits for the vulnerability (such as buffer overflows). Combining several such signatures into a single attack provides for maximum accuracy in attack detection.
It is possible to create user-defined signatures and attacks, and since the Wizard-driven User Defined Signature Editor provides access to all fields extracted by the protocol decoders as well as basic strings (such as URI, etc.), this capability is tremendously flexible and powerful. The administrator is able to take advantage of known protocols and packages in order to perform field comparisons (i.e. check if the traffic is HTTP and the source port is 32324) or define new ones from scratch. It is also possible to perform simple packet grep string matches. Any number of data comparisons can be added to a signature (connected with AND, OR or ANDTHEN conditions ), and any number of signatures can be added to an attack. This allows for some very fine-grained control over user-defined signatures and should hopefully help to reduce false positives providing the signature is defined correctly in the first place. McAfee supplies a set of pre-configured policies for immediate application in a number of different network environments. As well as including policies specific to particular operating systems (Windows, Solaris, etc.), server functions (Web server, mail server, FTP server, etc.) and physical locations (outside firewall, inside firewall, DMZ, etc.), there are also four catch-all policies: Default IDS, Default In-Line IPS, All Inclusive With Audit and All Inclusive Without Audit. The Default policies include all attacks that McAfee considers are applicable to an “average” network, whilst the All Inclusive With Audit policy includes every single available signature - exploits and audit/informational alike. The All Inclusive Without Audit policy includes all available attacks, but excludes pure audit signatures. The built-in policies are available in the Policy Editor, and should be considered as good starting points, designed to help get the system up and running quickly.
Any of the default scenarios can be applied and used as they stand, or they can be cloned (pre-defined policies cannot be edited directly) and modified in order to apply custom policies. The McAfee Default In-Line IPS policy, applied automatically when the first sensor is added, enables the administrator to begin protecting the network immediately with the most wide-ranging policy, but excluding all the known noisy signatures. For many people, the Default In-Line IPS policy will prove more than adequate to begin with. For our testing we deployed the All Inclusive Without Audit policy, and the sensor performance did not appear to suffer from having all signatures enabled. Attacks are classified into four general areas:
All IntruShield policies are rule-based - each rule in the set is either an include rule or an exclude rule, and determines what signature or group of signatures will be incorporated into the policy. An include rule usually starts a rule set and consists of a set of parameters that encompass a broad range of well-known attacks for detection. More than one include rule can be applied, of course, if it is required to be specific about the rules included in a policy (specifying the inclusion of only HTTP and FTP rules, for example). One or more exclude rules can then be applied to remove elements from the include rules in order to focus the policy’s rule set further.
For example, it would be possible to include all HTTP rules but exclude the Apache-related rules if there are no Apache servers in the organisation. By this process of broadening (includes) and narrowing (excludes) the policy focus, a policy eventually comes to contain exactly the signature set that is required for a given deployment scenario. Each attack in the IntruShield system has a wide range of informational parameters associated with it, including:
The rule set can use any or all of these parameters in order to provide the most highly focussed policy. For example, if a sensor is operating in-line in front of a DMZ with only IIS Web servers, the administrator might include all HTTP signatures, and then exclude all non-IIS signatures and finally exclude all those signatures with a benign trigger probability greater than “Low”. That way, only the relevant signatures are applied, and the administrator can be reasonably sure that false positives will not cause a self-inflicted Denial of Service condition by ensuring that only the most focussed and accurate signatures are applied in in-line mode. A separate interface on the IntruShield could then be used to monitor the same DMZ segment in SPAN mode with a broader policy, just in case something slips through.
Once the rule set has been created it can be applied to a policy, and different rule sets can be applied to inbound traffic and outbound traffic if required. Whilst this might seem overkill, it is actually an incredibly powerful feature that allows the administrator to refine the differences in how inbound and outbound traffic are inspected. Whereas most will assign the same rule set in both directions, some will undoubtedly find this capability invaluable. Once one or more rule sets have been applied, the Policy Editor displays the number of attacks that have been selected, grouped by protocol. Double clicking on a protocol brings up a list of the individual attacks, from where it is possible to customise certain elements of those attacks, including:
A useful bulk-edit capability allows the administrator to select multiple attacks (using standard Windows selection capabilities via the SHIFT and CTRL keys) and subsequently apply changes to certain parameters (such as the enable/disable flag, or alert response) to an entire group of attacks in a single operation.
Note that it is impossible to tune the actual built-in signatures in any way. This means that if a built-in signature is misfiring for some reason, it is not possible to alter the regular expression, for example, to ensure that it does not trigger on benign network traffic. Instead, an administrator can employ alert filters or disable the misfiring attack signature, after which he would have to start from scratch in creating his own user-defined signature. A powerful search facility allows the administrator to display all attacks, only those recommended by McAfee for blocking, or by a number of user-defined search options, and bulk edit operations can be applied to the results of the search. Whereas the bulk edit capability allows the administrator to change multiple attacks in a single policy, there is also the requirement to change one or more attacks across all policies (to change an attack response to block on every sensor in an organisation which includes that attack in its policy, for example). This bulk edit across all policies capability is provided by the Global Attack Response Editor (GARE), and is something we would like to see in more products. Separate policy settings are available for DoS attacks and reconnaissance probes. The sensor is automatically in learning mode by default, allowing it to monitor normal network traffic for a period of time so that it is able to determine what constitutes an abnormal flood. Individual DoS profiles can be created per sensor, and these can be uploaded to the ISM from where they can be applied to other sensors if required. For those administrators who would prefer to have more manual control over the DoS detection process, it is also possible to switch to threshold mode, where he can set the threshold level and interval for individual DoS attacks. Note that both threshold and learning mode can be enabled or disabled on a per-attack basis, and both methods worked extremely well in our tests. Finally, reconnaissance probes - port scans, host sweeps and brute force password cracking attempts - are configured purely on a per sensor basis and cannot be a part of a global policy. Each of these are configured using thresholds, and once again the default settings worked well in our tests.
After a policy has been configured using the Policy Editor, it can be applied to a resource - for example, an entire admin domain (or child domain), a sensor, an individual interface, or a sub-interface. Once applied to a resource, the policy is then propagated to the appropriate sensor (or sensors) for enforcement. Whenever a policy is amended, the Sensor Update page provides an at-a-glance list of all the Sensors which require updating as a result, with a check box against each one. Most of the time, all that is required is to click on the Update button, but it is a simple matter to uncheck any Sensors to which the administrator does not wish to apply the changes made. We found it to be fairly slow to deploy a policy to one or more sensors, although it should be noted that there is no interruption in traffic processing at any point in the update process. Whenever new signature updates are downloaded from the Web, the new signatures are added to all policies (within the confines of the applied rule sets), which can also be quite slow. IntruShield’s Virtual IPS (VIPS) feature enables the administrator to configure multiple policies for multiple unique environments all monitored with a single IntruShield sensor. Different policies can be applied to different interfaces, for example, allowing one pair of interfaces to monitor the DMZ with a predominantly Web-based policy in in-line mode, whilst another interface monitors the internal network in SPAN mode using the Default IDS policy. A clever feature of IntruShield sensors takes port monitoring one step further than the physical interface-level, however. Using sub-interfaces, it is possible to segment the security management and apply policies at a traffic sub-flow level within an interface - in other words, the sensor monitors only a portion of the traffic passing through a physical interface. This sub-interface is also known as a Virtual IPS (VIPS). A VIPS can be defined based on a block of IP addresses (a CIDR block), or on one or more VLAN tags. IntruShield sensors can process these segments of data and apply multiple traffic policies for the multiple subnets transmitting across a single wire, right down to policies protecting individual hosts. Other IPS products may allow filtering of addresses to achieve something similar, but they still generally only allow a single policy to be applied to each sensor. The particularly clever feature of IntruShield is the ability to support up to 1000 VIDS per sensor, and a different policy can be applied to every single VIDS. This means that on some networks, it would be possible to have a separate unique detection policy running for every single host on the network, all monitored from a single sensor!
It is also possible to mix interface modes in a single sensor, and apply different policies to each interface. One scenario we tested, for example, was to use two ports paired in in-line mode running a restrictive policy with intrusion prevention enabled for certain signatures, but with all the signatures with potential for false alarms disabled. We also created a VIPS on the same interface pair which consisted of a single mail server, to which we applied a slightly different in-line policy with more focus on SMTP exploits. We then used one of the remaining ports in SPAN mode attached to the SPAN port of our switch, and with a much broader policy applied which was set to capture the entire flow. Although the initial VIPS configuration requires some thought, once it has been accomplished, assigning policies to the separate VIPS is extremely simple, and the whole test scenario worked perfectly. Ports and sub-interfaces are managed via the Resource Tree in the System Configuration utility, where it is possible to create sub-interfaces beneath an interface node, or VIPS nodes within child domains - both of these are different manifestations of the Virtual IPS, and allow the allocation of multiple policies to the same physical interface.
A VIPS within a child domain can be allocated to an administrator who only has rights to that child domain and nothing else. Thus, when that administrator logs in, he will be able to configure and allocate policies to the VIPS under his control without affecting any other interfaces or VIPS in the system. One area that does require improvement in the current release is that when creating a policy it is possible have it visible to all child domains or none. In a Managed Services environment, the root-level administrator may want to have individual policies visible only to the administrators in a particular domain. Right now every administrator can view every policy, and even though the granular admin roles would prevent them from applying policies to Sensors over which they have no control, the fact that the administrator of one client can see the policy used by another client would be cause for concern to some. In our opinion, this is the only feature which prevents this being the perfect management system for Managed Service Providers, and McAfee has promised to address this with full-blown per-policy ACLs in a future release. Alerts exist in one of three states within the IntruShield system: unacknowledged, acknowledged, and marked for deletion. When an alert is first raised, it appears in the ISM Console in an unacknowledged state, and remains in that state until the administrator either acknowledges or deletes it. These alerts display in the Unacknowledged Alert Summary section of the Network Console and the Real-time view in the Alert Viewer. Acknowledging alerts dismisses them from these views, after which they display only in the Historical view in the Alert Viewer and in reports. It is not possible to annotate alerts as they are acknowledged, however - a shame, since that would be a useful facility to record the results of an investigation into the alert and why it was eventually regarded as unimportant. Deleting an alert both marks it for deletion and acknowledges it in the same operation. The alert is not actually deleted until a scheduled File Maintenance operation takes place, however, at which time IntruShield removes all alerts marked for deletion along with any alerts meeting the deletion criteria specified in the scheduler (older than 30 days, for example). Alerts are backed up to the database and archived in order of occurrence, whereas deleted alerts are removed from the database altogether. Using the Historical view in the Alert Viewer, it is possible to return an acknowledged alert back to an unacknowledged state or un-delete an alert, providing it has not been “cleaned up” by the file maintenance utility.
The IntruShield Alert Viewer is available via a hyperlink on the Network Console display. When it is first opened, the administrator must specify a time frame and a type of view - either Real-time or Historical. The Real-time View sets the alert filter to display information retrieved from an “alert cache” for a configured number of unacknowledged alerts. Once opened, the Real-time View refreshes frequently to display the alerts that are being detected by the sensors, but once closed, the only way to report on those alerts is to re-open the Viewer in Historical mode. The alert cache stores up to 500,000 of the most recent unacknowledged alerts, and all cached alerts are also listed in the database. Since the cache is a FIFO system, the oldest alerts in the cache are dropped once the cache maximum has been reached with newer incoming alerts that “overflow” the cache. Dropped alerts are simply discarded, since they have also been written to the database and are thus a matter of permanent record. At any point, the administrator can freeze the real-time display in order to work on the alerts currently on view (re-sorting columns, and so on). The Historical View sets the filter to retrieve information for both acknowledged and unacknowledged alerts written to the database within a specified time frame. Older data can be archived to separate files based on date range, and can be restored to any ISM server for further analysis at a later date.
Once alerts have been retrieved either from a particular time period, or in real time, the Alert Viewer interface displays the alerts in four main views:
The real power of the Alert Viewer lies in the drill-down capabilities. Right-clicking or double-clicking on any column in a graph in the Consolidated View (or using the Drilldown toolbar menu) will cause the remaining graphs to be redrawn with new data.
For example, initially, the Top 10 Alerts graph shows the top 10 alerts overall. Double click on the High column in the Severity graph, however, and the Top 10 Alerts chart is redrawn to display the top 10 alerts which have a Severity level of High. Subsequently double-clicking on one of the top 10 bars launches an additional window containing a list of all the individual alerts - the Alert Details View. It is also possible to right-click on a bar in one of the Consolidated View graphs and bring up a summary window grouped and sorted by time, severity, attack, IP address, interface, protocol, domain, type, or sensor. Once again, any of the groups can be double-clicked to call up the Alert Details View populated with the individual alert entries for that group (or right-clicked, and the entire group of alerts acknowledged or deleted in a single operation). There are thus many different ways of slicing and dicing data in order to drill down from very high level summaries to very low level detail. Should the number of open “floating” windows become confusing, a useful Window Manager provides the means to see an overview of open windows and jump quickly between them. It is also possible to save window layouts in user preferences to preserve them each time the Console is started, and save selected windows in PDF or CSV format to create quick reports. Overall the system works extremely well.
Double clicking on an individual alert entry brings up the Exploit Alert Detail windows for that entry with multiple tabbed windows. The Exploit tab provides information on the alert, including the attack name, sensor ID, interface name, severity, time, domain, alert ID and a link to a detailed description of the attack. Note that by processing network traffic passing through a sensor, it is sometimes possible for the IntruShield to determine the results status of an attempted attack - this can be one of failed, successful, unknown, suspicious or blocked. Of course, this works with varying degrees of success depending on the exploit and subsequent traffic. Many of our tests cases showed up simply as “Unknown”, but a significant number did show as “Suspicious”, and those which had very obviously failed (i.e. if a 404 error was returned by the Web server) or succeeded (i.e. if a Unix command shell was detected following the exploit) were always correctly identified. This is a useful capability. The Alert tab provides details specific to the attack type, which could be an exploit, a DoS attack, a port scan, and so on. This tab includes information such as source and destination IP address, network protocol, application protocol, threshold values, and target ports. The Response tab provides response information, where the administrator can examine the exploit packet, including the 256 bytes immediately preceding it or even the entire flow if those logging options were enabled for that particular signature. A packet log is created by an IntruShield sensor capturing the network traffic of and around an offending transmission. If logging was enabled for specific exploit attacks (the Configured Response tab provides details on exactly which responses were triggered by the alert, and thus provides an indication to the administrator of exactly what logging data is available), the appropriate packet logs are saved in library packet capture (libpcap) format, and stored in the ISM database. Ethereal is used as the packet viewer, which is actually a very sensible option since so many security personnel will be familiar with it, and it also provides excellent protocol decode capabilities.
The final tab in the detailed alert view window is the Signature Description, which provides some information on exactly what caused the packet to trigger this particular alert. This is useful given that it is not possible to examine the actual signatures within the IntruShield system. Once an alert has been examined and investigated, it can be acknowledged. At that point it is removed from the various statistical/summary views, and is subsequently only retrieved from the database for Historical View searches and IPS Reports. An alert can also be saved as an Evidence Report. This opens a complete view of a selected alert row in a separate window, and provides the option to save the alert information, including a packet log (if available), in a zip file which can be saved or passed to others for forensic analysis. For more extensive forensic analysis, IntruShield provides the concept of “Incidents”. An Incident is a collection of related alerts which can be correlated automatically by the Incident Generator based on pre-configured criteria such as 100 attacks from the same source in 15 minutes. This is accomplished by a process known as the Incident Generation Service which runs in the background on the ISM server. Incidents can also be created manually by the administrator, who can select and group together a collection of related alerts from the Alert Viewer using the User-Generated Incidents tool. Defining an incident enables the administrator to build a file for research, use in an investigation, or any other assortment of forensic analysis uses. The Incident Viewer displays incident statistics, provides a comments area for case management purposes, and enables deletion of incidents, and basic workflow capabilities allow each incident to be assigned to, and annotated by, a number of different personnel.
Assigning a responsible party is useful for quick recognition upon future opening of the incident and is very helpful in multiple administrator environments where more than one person will perform tasks on collected data. In all respects, the alert handling capabilities are extremely comprehensive and powerful and yet relatively easy to use once the interface has been mastered. The drill-down and automated correlation (incident) capabilities make it very easy for administrators to focus on the relevant detail. Whilst the Alert Viewer provides both real-time monitoring and interactive forensic analysis capabilities (as well as the ability to save selected windows in PDF/CSV format to create quick reports), the Report Generator offers the administrator the opportunity to create more comprehensive, and higher-level summary reports both in text and graphical format. As with the Alert Viewer, the Report Generator is available at the click of a button from the main IntruShield Network Console view. The IPS reports (still labelled as IDS Reports on the menu) provide summary information on the alerts generated from the installed sensors. The generated alert information can include source and destination IP of the attack, time when attack occurred, sensor that detected the attack, and so forth. The multiple reports in this category provide various, concentrated views according to the specific parameters of each report, and each report lists alerts from most to least common detected. There are six options in the IPS Reports menu, including four pre-defined reports, a user-defined reports option, and a template management capability:
Configuration reports provide information on the settings applied using the System Configuration tool. Reports can be generated to view admin-related information such as the current software and signature versions, the status of a sensor, or policy settings. The available configuration reports are:
The Scheduled Reports options simplify the reporting process by automating the report generation procedure. Scheduled reports can be generated and e-mailed on a daily or weekly basis.
All reports can be viewed in either HTML or PDF format. The Top N Report can also be viewed in bar graph or pie chart format. Performance Note that although MacAfee rates the IntruShield 4010 as a 2Gbps device, it was tested to a maximum of 1Gbps in this round of testing. As you would expect with this amount of headroom, performance at all levels of our 1Gbps load tests was impeccable, with 100 per cent of all attacks being detected and blocked under all load conditions. We also ran some tests up to the maximum of 2Gbps, and under normal network conditions, we would have no hesitation in rating the IntruShield 4010 as a true 2Gbps device. Latency figures were excellent across the board with all packet sizes (even down to 64 byte packets) and all traffic loads, and behaviour throughout the tests with no background traffic was very predictable, with minimal increases in latency as traffic levels increased from 250Mbps to 1Gbps across each packet size. Placing the device under a half load of 500Mbps of HTTP traffic, we noted significant increases in latency, although all results remained below the “magic figure” of 300 microseconds - our limit for deploying in-line devices in the core of the network. HTTP response times were also very good, meaning IntruShield could be situated anywhere on a Gigabit network, either internally or at the perimeter. Using the SYN proxy capability, SYN Flood mitigation was almost total, and 100Mbps of SYN flood traffic had a minimal effect on latency of normal traffic through the device. Average HTTP response increased from 204ms to 1716ms during the SYN flood, although no legitimate traffic was blocked during the attack. The IntruShield 4010 performed consistently and completely reliably throughout our tests, and exposing the sensor interface to extreme levels of ISIC-generated traffic had no adverse effect. Security Effectiveness Signature recognition and blocking performance were excellent out of the box (95 per cent), and was increased to a perfect 100 per cent after the application of a signature pack update which was provided to us in under 24 hours. We noted a minimum of “noise”, with very few test cases raising multiple alerts for a single exploit, and the accuracy of the exploit descriptions was high. Performance in our “false negative” tests was very good out of the box, and there is every indication that the majority of signatures are written for the underlying vulnerability rather than specific exploits. IntruShield’s resistance to false positives was excellent in our tests, and was increased to a perfect 100 per cent following the signature update. IntruShield arrives with a number of default policies configured for different environments and with sensible PASS and BLOCK actions set for appropriate signatures. Resistance to known evasion techniques was excellent, with IntruShield achieving a clean sweep across the board in all our evasion tests. The IntruShield 4010 demonstrated perfect performance in our stateful operation tests out of the box, handling over 1 million open connections with no tuning required. Usability The current UI is beginning to look a little dated, but a sneak glimpse at the new version currently in development (due to be released later in 2006) impressed us - the new look is much cleaner and more modern, whilst retaining much of the current mode of operation familiar to existing users. The IMS and Console have been designed from the ground up to handle large distributed deployments and even managed services environments, and they contain several useful features to make this type of deployment easier to handle. To begin with, the ability to define up to 1000 Virtual IPS’ across the twelve ports and assign an individual policy to each of them makes this one of the most flexible systems we have seen in our labs - IntruShield was the first with this, and only recently has the competition begun attempts to emulate it. That flexibility is boosted by the fact that each port or port pair can be configured in different ways - either in “traditional” SPAN mode, or in tap mode, or in in-line mode for the ultimate in protection. Or they can be grouped together as a port cluster and the traffic aggregated across them. The admin domains and user roles make it easy to delegate the most fine-grained control across the largest organisation. The rule-based policy definition makes it easy to define complex policies, which can then be rolled out to a single sensor or the entire network by simply allocating the policies at the appropriate level in the Resource Tree. And once the policies have been applied, the alert handling (including correlation) and forensic analysis capabilities are incredibly powerful and flexible. The internal firewall is also a useful feature, providing the means for an administrator to apply firewall rules in the core of the network without having to deploy a layer 3 device. Finally, the SSL decryption capability is unique at the time of writing and enables IntruShield to decrypt selected SSL traffic on the fly and apply detection and protection capabilities to that traffic. Overall, IntruShield is an excellent product which demonstrates high levels of performance and scalability, and incredibly flexible and powerful management and alert-handling capabilities. Company
name: McAfee, Inc Click here to return to the IPS Index Section |
Send mail to webmaster
with questions or
|