[Snort-devel] http_gunzip preprocessor

Michael Loftis mloftis at ...2776...
Thu Jan 5 10:51:01 EST 2006


--On January 5, 2006 12:33:38 PM -0600 Frank Knobbe <frank at ...2134...> wrote:

> On Thu, 2006-01-05 at 12:52 -0500, Eric Lauzon wrote:
>> Think about javascript emulation, html(base64 decoding), uudecode ,
>> cache (dns poisoning
>> and xss[cross zone] detection), SSL MITM for encrypted stream inspection
>
> I thought I said that earlier. I'm not after content screening. And
> please stop bringing up SSL and such.
>
>> [...] you need to have
>> a product or opensource components that will be built for the purpose ,
>> dont think
>> you can have your IDS do the everything everytime.
>
> *sigh*  I was under the impressions that IDSes are used to detect
> intrusions. I'm not trying to misuse it as a content screen which you
> have been trying to imply.
>
> Could we please keep the devel list focused on the technical aspects and
> not abuse it for misguided evangelism?

I have to agree, the replies Frank is getting are downright troll-ish.  I 
think being able to inspect, or atleast *OFFER* the option to inspect (even 
a portion of) compressed content of HTTP streams is essential.  It's no 
different than looking at the content of any other packet.  Yeah, it 
requires more work, yeah there are pitfalls.  But as long as they're 
documented (which you guys have completely beat the damned dead horse on) 
there's no reason NOT to allow that feature assuming it works well and 
doesn't introduce any new bugs.  For SNORT this might mean a modified 
implementation because it would need to STOP possibly even partially 
through decoding a block, as soon as it hit it's limit.  It would also need 
to be very robust in the face of malicious data designed to trip up the 
sensor.

Yeah using it as a content screen is misusing it, but ffs, nothing prevents 
someone who has too much time and CPU on their hands to doing it.  Just 
because a feature is there doesn't mean that's what it'll be used for, so 
drop it.

Things can be taken one step at a time.  Right now all that's wanted is the 
ability to begin to spot signatures of malicious worm code in compressed 
HTTP streams....correct me if I'm wrong, but doesn't snort already have 
signatures do (things like) that for uncompressed streams?






More information about the Snort-devel mailing list