I wanted to clarify some things about the NetScreen IDP and extend an
invitation to those with questions regarding how the product works to ask
someone that knows instead of taking the word of someone who may not have
all of the facts.

The following comment was found in a recent post:
> Netscreen and Manhunt are superficially great products, but the core
> engine underneath them is weak.

There were no specific examples given regarding the 'weak engine' claim, but
I wish to point out some specific things.

The 'engine' uses a number of ways to detect attacks. They include stateful
signatures and protocol anomaly detections among others. In addition to all
of the detection methods it also does all of things expected of a modern IDS
product with regards to IP defrag, TCP stream reassembly and protocol
decoding.

The poster goes on to mention a recent post by Rob Graham regarding
"protocol validation and not anomaly detection". I believe that the
following passage is the one he is referring to:
> We refer to an anomaly as something that is legal (as far as
> the RFC is concerned), but otherwise odd. For example, a 100-character
> password is legal as far as the FTP RFC is concerned, but we still
> trigger on it as an anomaly.

I agree that this is an optimal method of detecting anomalies based on
protocol examination.

The IDP also does this type of anomaly detection and the specific parameters
regarding these type of detects can be edited by the user. Some of the
protocols covered by this type of detection include:
 HTTP, FTP, SMTP, POP3, IMAP, DNS.

This leads us to a couple of posts regarding having an IPS or IDS respond to
a 'protocol anomaly':
>> What about blocking only a few certain attacks, that could not be easily
>> spoofed. Such like HTTP vulnerabilities and others that need a complete
>> handshake to work.
> Thank you for bringing this up. I'm a bit angered by all-or-nothing
> attitude. As you correctly said, active response doesn't need to happen
> to any and all signatures, or rule violations.

This is a great point, especially when dealing with anomaly based detection
methods. You need to be flexible when dealing with all of the software
packages that are coded to break RFCs.

With the IDP you can put it inline and choose not to drop any traffic at all
or specify only drop certain attacks going to or coming from specific hosts;
on a *per rule basis*.

The thing that you have to keep in mind is the thought process behind the
management of the IDP; it is based on a "firewall philosophy" of management.
So, it can be quickly configured to respond differently based on source IP,
destination IP, service port and/or attacks detected.

I view vendor and reseller participation on a forum such as this should be
in the role providing useful information so people can draw their own
conclusions. I hope to do the same while checking any opinions at the door.

If you have any questions about the IDP or would like to see it in an
evaluation, feel free to contact us. Or, if you prefer that the
sales-hounds be kept off your trail for a while, you can contact me
directly.

--Steven Richards
Sr. Systems Engineer
NetScreen - Chicago

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]