Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17

["evilghost () packetmail net" <evilghost () packetmail net>]

See inline responses.

Frank Knobbe wrote:
> 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).
>   

Honestly, I'm not.  I'm harsh because I'm really pissed off.  I'm pissed 
off often and it helps keep me warm at night.
> 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. 

IDS must evolve with threats.  2004?  We're now six years later.  Talk 
about code stagnation.  It's bad enough we don't have SMP support.

> 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.
>   

So I have two choices; 1) Disregard all gzip encoded data in the hopes 
that I don't encounter an overload situation and I might miss some data 
while at the same time missing a crapton of data, or, 2) BPF, flow-pin, 
and size my IDS according to my traffic volume to handle gzip encoded 
data like I currently am forced to do because Snort doesn't support SMP 
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. 
>
>   

Lets start with gzip first, then move forward.  It looks like if I'm 
able to decode things that HTTPDs do now I'm be a a rock-star.

> 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.
>   

The current security threat tends to be client infection with the 
majority of C&C being HTTP due to egress firewall avoidance.  It seems 
the best way for me, should I be a malware author, would be to use 
HTTP/1.1 with gzip encoding.  The end-point HTTPd won't have any 
problems handing it.  I can count on one hand the the number of things 
non-HTTP signatures catch versus HTTP/client signatures.

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

This is *how* we detect infected workstations since aside from a decent 
HIPS, AV is a great placebo.

> 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.
>   

I agree.  I like to detect gzip deflated data.  I'd like to think we 
could actually detect on *normal* HTTP/1.1 client behavior.  It's 
getting harder and harder to find folks running pre-Internet Explorer 
4.0 and Mozilla/3.0.

> Cheers,
> Frank
>
>   
-evilghost

------------------------------------------------------------------------------
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