Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17

[Frank Knobbe <frank () knobbe us>]

On Tue, Mar 23, 2010 at 07:58:07PM -0500, evilghost () packetmail net wrote:
> Judging from Joel's response evidently Mike is spot-on, which just 
> caused my jaw to drop.  Are you serious?  You seriously didn't support 
> gzip encoded data until 2.8.6? 


Okay, I'll bite (although your email does sound like your trolling).

Joel/SF can probably explain better the various technical reasons for that.
In my opinion, first off, it's CPU intensive. These days CPU's have gotten
faster where this is actually feasible. But several years ago, when we first
discussed this on the list (search snort-users archives, my guess would be
around 2004 time-frame, if not earlier), systems weren't quite fast enough
to keep up with the load. When your busy unzipping HTTP data (think a full
Slashdot page, heck throw some large images in there and you can do the
math!), eventually your IDS will run behind and start dropping data.
That's not what you want either.

Second, it's not just gzip. There deflate (which I assume is supported).
How about Base64 or other data encodings? Who supports those? Oh, and while
you are complaining, what about that friggin SSL? I don't hear you whining
about that. 

There are many, many ways to evade an IDS if you really want to. There is
no silver bullet that can decode and analyze everything. If I have to choose
between being able to keep up with traffic and not inspect gzip encoded pages,
or being able to decode these and have Snort waste cycles on that, and then 
missing *other* traffic (perhaps more important traffic!), then I rather
turn gzip support off and watch the other traffic, and let those devices that
deal with HTTP stuff (you know, proxy servers, web content filters etc)
deal with the gzip stuff.

I'd rather be able to detect a compromised workstation successfully instead
of seeing the web traffic that that workstation is accessing.

This sorta leads into the debate about detecting attack/infection *attempts*
versus detecting actual compromise/infection. I think we have way too many
sigs that alerts on attempts instead of the real deal. 

I prefer real deal.

Cheers,
Frank


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs