[Snort-devel] Re: [Snort-users] Has anybody checked this out?

Martin Roesch roesch at ...48...
Sun Feb 25 14:17:56 EST 2001

Fyodor wrote:
> On Wed, Jan 31, 2001 at 03:03:28AM +0000, Dr SuSE wrote:
> > Hmm, perhaps he forgot to include a rule set in his snort.conf file.
> > I find it very hard to believe that out of 100,000 attacks Snort detected zero.
> > Could it be that the 100,000 attacks were the same and there simply was not
> > Snort signature for this particular attack or maybe there was but it somehow
> > got removed or commented out.....
> >
> >
> Anyway, I looked through prelude code and there are definetely some things
> which look interesting and which we may probably borrow in snort 2.x (some
> of them were discussed on the list for quite some time already (report queue
> is our spooling mechanism, stateful protocol expection features etc etc)).

I'll have a look at it, but I've definitely got some ideas already about
what I want a lot of the features in Snort 2.0 to look like.

>  The only thing which I don't understand why Yoann talks in such aggressive
> manner.  Yoann seems to be a guy with attitude. Althrough there are definetely
> some weaknesses and design problems in current snort implementation, (that is
> why we are going for snort 2.x :)) I don't think that claim 'while snort detected
> 0 attacks prelude detected 100,000' has any base. It depends on how you configure
> both tools though, you could run snort -dv and definetely will not see any alerts :) The
> guy seems to have odd understanding of what 'attack' is too..
> " Generating bad packet is often used as a kind of DOS attack to make the
> remote operating system IP stack crash. I believe that an IDS have to report
> such attack.".
> I don't think all kinds of maliformed/corrupted dataframes on the wire deserve
> to be triggered as attacks, one of the common problems with IDS configuration
> which I see around, is that guys try to trigger and alert everything (including
> 'HTTP cookies, SMTP mail from: headers' etc), which at the end creates the
> situation that you get hundreds of alerts every day which you don't even look
> through.

I think that the real issue here is that 100000 alerts for bad packets
are really one large event (malformed packet) and having the IDS
identify every different way in which a packet is malformed isn't
especially useful.  Even if you aggregate those alerts into a single
meta-event, you've still got inherently useless data unless you are
reporting a known DoS event, not just a "this might be a Dos".

Snort's concept of operation is "configure me to tell you what you are
interested in", not "let me tell you what I find interesting".  There's
a big difference.  If people want the Snort decoders to pop an alert
everytime they get a bad packet, I'll write it up to do that but I'm
willing to bet that people aren't really interested in that sort of

Furthermore, saying that "Snort didn't detect 100000 attacks" is pure
hyperbole and has nothing to do with Snort's real detection
capabilities.  I find it strange that this would even be an issue if he
truly inderstood the nature of Snort and find it to be pretty
intellectually dishonest coming from a coder.  It smacks of marketing to
my mind, and in the open source world there's not a whole lot of room
for that kind of BS (maybe I'm just being naive)... :)

I'd like to test out the code and see if there's some really original
stuff here, but unfortunately it doesn't compile cleanly on FreeBSD or
OpenBSD so I haven't had a chance to check it out yet.


Martin Roesch
roesch at ...48...

More information about the Snort-devel mailing list