Rules Rule
We found IDP's rule-based paradigm especially useful when tuning the policy for our production network. Our goal was to have the broadest policy enabled while keeping false positives to a minimum. However, our production network is not what you'd call static: We have a wide variety of technologies running all the time, and new servers are always being installed and upgraded. For example, we have a number of network managers that periodically scan and enumerate Syracuse University's Class B network. These guys triggered tons of alerts, so we created a host group that contained those managers, added a rule that ignored them, and applied the policy, making the alerts disappear faster than audiences at a screening of Gigli.
Unlike firewalls, which dispatch traffic on the first positive match, packets processed through IDP can fall through the rule base and be processed multiple times. But we were able to set rules as terminal, meaning once the rule matched, the action--be it "none," "drop packet," "drop sessions" or "send reset"--would be taken and processing would stop. Order matters and is intuitive.
We did have to add some signatures to the rule base to allow certain kinds of traffic. For example, as we noted earlier, IDP doesn't recognize the STARTTLS command within SMTP, which is used to start TLS for traffic encryption. Every time a TLS-enabled MTA (Message Transfer Agent) or MUA (Mail User Agent) negotiated with the mail server, an alert for a bad command would trigger, and subsequent SMTP packets would be alerted as having binary data in the header. We created a signature that looked for STARTTLS using a regular expression and then ignored the flow that resulted.
Unlike IntruShield's, IDP's signatures are viewable and editable. For example, the smaller IDP 10 product, which we included in our live network testing, kept alerting on HTTP traffic between IntruShield Manager and the laptop running the IntruShield management client. The signature was looking for binary data in the entire TCP payload and triggering. We located the signature and changed it to match only HTTP packets with binary data in the header portion. This edit ability let us easily refine the signatures so that they conformed to our normal traffic. Of course, we would never be cavalier about editing signatures because we know we could just as easily render them useless. But used wisely, NetScreen's signature editing is a powerful capability and a clear advantage over Network Associates' closed signature model.
Reporting Miasma
Although there are lots of things to like about IDP, alert viewing and reporting aren't among them. When we knew exactly what we were looking for, such as specific attacks, ports or hosts, we could define filters in the real-time alert viewer that narrowed the information flow to a manageable level. These filters could be assigned to views so that they could be reused, and the real-time alert viewer provided a filterable log of all events processed. Double-clicking on an event brought up a detail dialog box, which provided a brief description of the event and any applicable references. Right-clicking on the event brought up a context-sensitive menu with options, such as Filter, Show Data and Locate Attack in the attack objects or policy. The Filter options could filter on the column field selected, and subsequent uses of the filter narrowed the data further. For example, we were troubleshooting a POP3 issue, so we filtered first on the POP3 Command-Failed alerts, and then filtered those results by the host we were interested in.
However, there's no decent top-level summary of all the attacks that were seen. The reports weren't interactive, for example, to let us drill down deeper; and there's neither a report scheduler nor a way to customize reports. These are significant weaknesses, given the large amount of data generated by IDP.
The IDP 500 also is limited to 500 Mbps; during testing, we hit 461 Mbps with latency reaching 1.7 seconds, which hurts performance.
NetScreen-IDP 500, NetScreen Technologies. (800) 638-8296, (408) 543-2100. www.netscreen.com
Mike Fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs®; he covers all security-related topics. Prior to joining Network Computing, Mike worked as an independent consultant in central New York. Write to him at mfratto@ nwc.com.
Post a comment or question on this story.
RSS
The NetScreen-IDP 500 has many features comparable to those found in the much pricier IntruShield 4000 and has more straightforward management to boot. Firewall administrators will feel right at home with IDP's rule-based policy, which is flexible and tunable. IDP's sensor, like IntruShield's, can capture packets inline, using an external tap, or from a switch span port; however, it can capture packets using only one mode. Also like its rival, IDP can drop packets and streams while in inline mode, and it can send TCP resets or ICMP unreachables to block malicious traffic in one-arm mode as well.
