[Snort-devel] http_gunzip preprocessor
eric.lauzon at ...1967...
Thu Jan 5 11:13:12 EST 2006
> -----Original Message-----
> From: snort-devel-admin at lists.sourceforge.net
> [mailto:snort-devel-admin at lists.sourceforge.net] On Behalf Of
> Michael Loftis
> Sent: 5 janvier 2006 13:50
> To: Frank Knobbe
> Cc: snort-devel at lists.sourceforge.net
> Subject: RE: [Snort-devel] http_gunzip preprocessor
> --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:
> 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*
I dont see the trollish in exposing the fact.
Case where you wont see anything:
to redirect you to a server where there is the WMF, even if the initial
is "decompressed", where are you gonna be able to detect anything?
As of notice most of signature allways match public cases where private
vectors usualy goes undetected because they use slight modification or
One good example is :shellcode detection where after the birth of
ADMmutate,ASCII shellcode encoding
,polymorphism , the only real way to detect shellcode is to have host
based IDS that monitor process memory, process structure and Instruction
The scope of should be writing a portion of code for a specific case
just arised but has been exploited before why not think about an http
can use sub preprocessor on the http stream this could then lead toward
stream anomaly / state
But as for keeping the ole stream both client and server, you need to
have some kind
of dedication to the instance of snort you deploy.
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.
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.
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)
More information about the Snort-devel