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:36:31 -0500
Inline Frank Knobbe wrote:
On Tue, Mar 23, 2010 at 09:04:06PM -0500, evilghost () packetmail net wrote: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.Then why aren't you asking for a Javascript decoder plugin?
Frank, I'm sane and have feasible and realistic expectations.
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.I can see where your happyness about gzip might lead you to a false sense of security (at the cost of CPU). Again, what about SSL? Javascript de- obfuscation?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.Okay, so once that's done, you'll be back complaining about the missing email attachment unzipper/decoder?
Hmm... That's a good point. If the current security theater were that where the primary mechanism for C&C and security were over SMTP, it were not easily mitigated by alternative security solutions (antispam, etc) then yes, absolutely I would be upset. Anyone who things that complacency and response to threats of yester-year is the answer to security needs to wake up.
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.They use it today! I'm sure they have been for a couple years. Ever wondered why most ET sigs dealing with malware are looking at the URI's instead of the data portion?
Well, guess it time to throw out content matches against HTTP body.
This is *how* we detect infected workstations since aside from a decent HIPS, AV is a great placebo.No, you're detecting attempts. I could care less if Snort is able to unzip a web page delivering yet another FakeAV that doesn't stick on the workstation. I prefer to look to the actual infection, focusing on what the workstation does next. But we probably have different approaches to that angle, so there's no point in taking that further.
No, I'm detecting positive infection as a result of egress HTTP check-in/C&C/tertiary behavior.
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 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 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)
- Re: Sourcefire VRT Certified Snort Rules Update2010-03-17 evilghost () packetmail net (Mar 24)
- Re: Sourcefire VRT Certified Snort Rules Update2010-03-17 Alex Kirk (Mar 24)