Policies, in IntruShield parlance, are where attack signatures and DoS (denial of service) detection are enabled and disabled. Each attack is defined to detect a discrete event, like Unicode-encoded URLs or binary traffic in a protocol header. Attacks are organized by protocol, so it's a simple matter to drill down into a policy and see what is enabled. Unfortunately, Network Associates doesn't let users see what constitutes a signature. When we asked about this, the company said it didn't want to help people develop evasion techniques. The Exploit Alert Detail dialog on the Alert Viewer reveals text matches for a given alert, but that one match could be a subset of all possible matches.

Given time, we could have puzzled out most of the signatures via exhaustive searches, so we think Network Associates is just being difficult. In comparison, NetScreen opens signatures for review and editing--an approach we prefer.

The lack of signature information quickly became frustrating, and it complicated troubleshooting when a match was based on a protocol anomaly because there wasn't enough information to know why a match occurred. We had to send packet traces to Network Associates to determine why an SNMP packet was being detected as a NetBIOS issue. It took a few days, but the company resolved the problem and provided an update to the signatures. Signature updates are automated, but you need to buy a support contract to get them.

Policies All Around

IntruShield's policy assignment is very flexible, which is a double-edged benefit. We could apply policies to individual interfaces or, when in inline mode, to interface pairs, and there were policies defined for both outbound and inbound traffic, so asymmetric detection was possible.

Policies could be tuned in two ways. A rule set could make wholesale limitations in what types of attacks were detected by limiting the policy to signatures that match a set of categories, protocols, OSs, applications and other classifications. For example, we created a rule set that included all categories of attacks against IIS Web servers over HTTP. We then defined an IIS Web Server Policy using that rule set. All signatures that did not match the criteria were not selected for the policy. The alternative to using rule sets is to enable/disable individual attacks in the policy manually; however, if you want a symmetric policy, you must edit both the inbound and outbound attacks.

Policies can be applied to individual hosts or groups of hosts, but this process was more complex than with IDP. Subinterfaces are used to group hosts by CIDR blocks or 802.1Q VLAN tags. Unfortunately, all hosts may not be in the same CIDR block or virtual LAN. So we had to reconfigure our host IPs to group similar hosts within a CIDR block or add hosts individually to the subinterface using a 32-bit subnet mask. We chose the latter because renumbering is a difficult process. Also note that CIDR blocks can be defined only once per interface (see "Policy Assignment Per CIDR Block,").

Policy Assignment Per CIDR Block click to enlarge

We had a vulnerable Microsoft SQL Server 2000 on 192.168.2.40. We successfully ran the Resolution Service Stack Overflow against that server, and it was detected by IntruShield under the policy assigned to the CIDR block 192.168.0.0/16. We then ran the same exploit against our Sun Solaris box, which is governed by the Solaris policy assigned to the subinterface containing the CIDR block where our Solaris server resides. That attempt was not alerted because the signature governing that address was not enabled.

The moral of the story: Tuning policies reduces false positives and lets you focus on relevant alerts.

Reporting

Once we completed our configuration, we ran a number of exploits against our target hosts. This gave us an opportunity to examine IntruShield Manager's reporting and data-mining features.

The Alert Viewer provided us with real-time and historical views of alerts, while consolidated graphs showed rollups of alerts by severity, top attacks, and source and destination IP addresses. The graphs are context-sensitive and changed as each bar was highlighted. Double-clicking on an attack bar, for example, brought up a new window that showed just those attacks.

The Real-Time Attack Details showed each event as it was logged. Double-clicking on an event brought up details pertinent to that event, such as an attack description; addressing information; and, if there was a signature match, the data that was matched on. Most of the alerts also captured the offending packets, which we then could view using Ethereal. Some attacks generated multiple alerts. For example, a Unicode-encoded directory traversal attack triggered three alerts--for Unicode encoding, for directory traversal and for running cmd.exe.

Real-Time Attack views can be frozen, and the columns can be sorted. The drill-down function provides a high-level categorization view from which to start. For example, selecting the attack drill-down showed us the 20 or so detected attacks and the counts for each. Clicking one of the listed attacks brought up a filtered dialog showing those attacks.

The reports are full-featured, and the scheduler offers daily and weekly report generation.

The IntruShield product line worked well as an IDS and, with administrative forethought, as a NIP device. The reporting is top-notch and, for the most part, informative. The policy configuration, while initially cumbersome, provides for granular tuning where required.

McAfee IntruShield 4000, Network Associates, (972) 963-8000. www.networkassociates.com