Snort mailing list archives
Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17
From: "evilghost () packetmail net" <evilghost () packetmail net>
Date: Tue, 23 Mar 2010 21:04:06 -0500
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
Current thread:
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17, (continued)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Will Metcalf (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Joel Esler (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Will Metcalf (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Joel Esler (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Mike Cox (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Joel Esler (Mar 23)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 evilghost () packetmail net (Mar 23)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 Sethsec (Mar 23)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 L0rd Ch0de1m0rt (Mar 24)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 Frank Knobbe (Mar 23)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 evilghost () packetmail net (Mar 23)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 Frank Knobbe (Mar 23)
- Re: Sourcefire VRT Certified Snort RulesUpdate2010-03-17 evilghost () packetmail net (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Will Metcalf (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Mike Cox (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Joel Esler (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Seth Art (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Will Metcalf (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Seth Art (Mar 23)
- Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17 Will Metcalf (Mar 24)
- Re: Sourcefire VRT Certified Snort Rules Update2010-03-17 evilghost () packetmail net (Mar 24)
- Re: Sourcefire VRT Certified Snort Rules Update2010-03-17 Matt Olney (Mar 24)