[Snort-devel] http_gunzip preprocessor

Michael Loftis mloftis at ...2776...
Thu Jan 5 11:46:02 EST 2006

--On January 5, 2006 2:12:20 PM -0500 Eric Lauzon 
<eric.lauzon at ...1967...> wrote:

> Im still convinced that most of the people wont read
> and will then complain, thee other half will try but will encounter
> huge performances issues.

Then snort may as wssell stop development right here, so with every 
project.  There are always those that don't read, and complain.  That's 
what the users list is for ;)

> Where is the trade off? A quick ""useless"" feature as of it wont help
> over other means of
> exploitation of any attack vector (still part of it could be used in a
> more complete engine)
> or a more complete http_(state/inspection) framework.

Not useless.  It at the least can detect the (possible) presence of (remote 
or local) HTTP requests with known malicious content.  Hell I'd love to be 
able to do that on our network.  If I could see when a payload retrieval 
attempt is started, I could tell the infected machine on my end, and where 
the infection came from.  Fact is a lot of the time it's compressed.  At my 
day employer we compress all outgoing data in order to save bandwidth 
because geographically where we are bandwidth is far more expensive than 
CPU, so our main hosting cluster compresses everything.  Being able to 
increase detection rate (buzzword alert) by doing more defense-in-depth 
techniques is good.  Maybe the request is uncompressed and I catch that, 
maybe the response, and I catch that, maybe one of them, or both, is 
compressed, then, right now, neither is caught.

I'm not saying anyone has to jump on it and develop it by any means. 
Snort, it's modules, etc, are just tools.  gzip (the CLI tool) can just as 
easily break something as snort can in the wrong hands, but noone 
questioned developing it.

Any time you create a tool it can be problematic in amateurs hands.  That's 
their problem.  For those of us that know what we're doing, and yes we 
might be (I tend to think often times probably are in the minority, having 
more modules and features makes it more powerful and more useful.

> Sure the main factor here is time, but i am sure people should look
> deeper rather than just
> trying to fix an issue that is far more complex than stream compression
> (in my opinion)
> -elz

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

More information about the Snort-devel mailing list