RE: ids inquisition

From: Oliver Petruzel (
Date: 07/27/01

From: "Oliver Petruzel" <>
To: <>
Subject: RE: ids inquisition
Date: Fri, 27 Jul 2001 16:00:35 -0400
Message-ID: <000c01c116d6$cd073aa0$>

Ok, I hate to jump in here... No, wait, no I don’t. (it's a sickday

I admire nice code in general - so don’t attack opensource.
I believe in timely full-disclosure of tools or exploits.
I believe anyone in it just for the money should jump ship.

Well, I also fully believe that BOTH protocol analysis, AND pattern
search are soon to become invalid.
Dozens of IDS companies out there are merketing millions of dollars
worth of contracts consisting of NIDS and HIDS solutions, which will ALL
become invalid within the next few years.(one word: encryption)

Tall statement eh? Well, here's the deal: Go to the kernel.

Processor power these days allows full system-call or kernel-level
analysis without much impact on a cpu. Thus, a few solutions occur
1. no bottle necking or choke points on any portion of the network.
2. minimal false positives
3. allow for the creation of ACTUAL generic signature development which
are not effected by TRUE security mechanisms such as encryption.
(examples: One signature for ANY buffer overflow, or ANY attempt to
deliver cmd.exe calls via URL's...even with SSL involved.)

With that said, the open-source solutions out there, those not trying to
make a buck, are perfect for the here and now. But like the commercial
node products, encryption will make them useless to a degree.

The future will consist of 2 solutions:
1 = traffic, or protocol, -trends- analysis tools. As most SOC's now
monitor with product or another.
    But remember, this is a REACTIONARY method of netowkr observation
and requires 24/7 monitoring. Even truly intelligent traffi analysis
will be difficult to trust and implement when AI is developed to handle

2 = Kernel-level / application layer monitoring via generic or heuristic
PROACTIVE observation.

But go ahead and tell your government contracts and Fortune 100
customers that YOUR IDS solution will protect them. Why not have them
spend more of my money on useless products which will be techniclaly
insufficient 5 years from now. (heck, most of them are easily defeated
5 years which barely gives them time to install and understand them! Ha!
Heck, that way, you may even write a new product and SELL TO THEM AGAIN!
SWELL! Half the protection for twice the bucks! You all should be VERY

Well, im done for now. PLEASE TAKE NOTE: notice I wrote and entire
response without mentioning one specific vendor! Wow.

-Oliver P.

> -----Original Message-----
> From: Robert Graham []
> Sent: Friday, July 27, 2001 3:18 PM
> To: eberkut;
> Subject: Re: ids inquisition
> --- eberkut <> wrote:
> > I am curious. What generic methods does the BlackICE team use to
> > detect attacks before their release either having been subjected to
> > modifications as the polymorphism
> The "generic" method is "protocol analysis".
> We do analyze about 60 protocols, breaking them down on a
> field by field basis. Among the many things we do is
> "protocol validation": we look at each field to see if the
> values supplied are "normal". If not, we trigger an alert.
> In particular, buffer overflows are detected by looking at
> the LENGTH of the field, not the CONTENT. Since we ignore the
> content of the fields, changing the content will not evade
> overflow detection. In other words, you can't use polymorphic
> code to evade us, because we are ignoring the code in the
> first place.
> We added Telnet protocol validation almost a year ago. Among
> the things we validated was overflow within the environmental
> strings passed via the Telnet options. If the input was
> excessively long, then we trigger an alert.
> We wrote this validation before we know of anything that
> might be vulnerable. We wrote that "signature" in a manner we
> call "on spec": we looked at the protocol specification, and
> we just knew that this would likely be a vulnerability.
> This is especially valuable when you consider odd platforms.
> NetBSD is famous for running on a zillion CPUs, all of which
> are vulnerable to the Telnet vulnerability. However, only the
> x86 variant is floating around in public. The one signature
> we have doesn't care about the different variants.
> BTW, this really isn't a "BlackICE" vs. "Snort" issue, but a
> "protocol analysis" vs. "pattern search" issue. BlackICE
> focuses on protocol analysis, and does some pattern search.
> In contrast, Snort focuses on the patterns, but is getting
> more and more protocol analysis. The downside of protocol
> analysis is that you HAVE to code things up, you can't create
> simple rules. There are a lot more tradeoffs (pros and cons)
> than I describe here as well.
> I really don't want to make this sound like a marketing
> document, but there is widespread lack of knowledge about how
> protocol analysis works. When you read a lot of education
> documents on IDS today, they generally assume pattern search
> techniques. They don't really apply to IDSs that use protocol
> analysis.
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with
> Yahoo! Messenger

Relevant Pages

  • RE: Value of "richer" signatures?
    ... Is it that much faster to do "protocol parsing" than ... > Here's an example of how the newer IDS signatures help ... > Let's say you are using a simple packet grepping IDS ...
  • RE: Comparing the performance of two IDS products with different architectures
    ... Comparing the performance of two IDS products with different architectures ... So if you are using protocol analysis, ... You're back to pattern matching. ...
  • Re: ids inquisition
    ... Subject: ids inquisition ... Whenever I buy an IDS I life it ... Well, I also fully believe that BOTH protocol analysis, AND pattern ... > we just knew that this would likely be a vulnerability. ...
  • RE: Comparing the performance of two IDS products with different architectures
    ... Comparing the performance of two IDS products with different architectures ... An interesting point, “a packet is only tested for a signature when needed, and not when it isn't ... and only tests signatures that apply to those contents. ... could argue all day long about the strengths and weaknesses of “pattern matching” vs “protocol ...
  • RE: [fw-wiz] Firewalls Compared
    ... > I'm trying to reconcile "know what the vulnerability looks ... For example if we know from the protocol rules that we're ... signatures that just dump any packet with %n%n or %x or whatever. ... Firewalls MUST be in a default DENY mode." ...