[Snort-devel] http_gunzip preprocessor
eric.lauzon at ...1967...
Thu Jan 5 09:53:04 EST 2006
> -----Original Message-----
> From: snort-devel-admin at lists.sourceforge.net
> [mailto:snort-devel-admin at lists.sourceforge.net] On Behalf Of
> Frank Knobbe
> Sent: 5 janvier 2006 11:44
> To: Brian Caswell
> Cc: snort-devel at lists.sourceforge.net
> Subject: Re: [Snort-devel] http_gunzip preprocessor
> On Thu, 2006-01-05 at 11:34 -0500, Brian Caswell wrote:
> > While a gige sensor is probably much faster, even if it was 6 times
> > faster, adding additional second per to handle those requests means
> > Snort is going to drop a TON of traffic.
> > Decompression is NOT negligible. Even only doing 500 bytes of it.
> Relatively to decompressing the whole stream, yes.
> If performance is required, like on Gig links, don't turn it
> on. I'm sure you guys tune sensors based on their deployment
> environment, so disabling any CPU intensive things on heavily
> loaded sensors should be normal procedure anyway. Wouldn't you agree?
I still dont understand where Snort should act as an http proxy,
protocol inspector and disector.
As of just bundling one feature for one case i guess Snort would need
more than gzip decoding.
cache (dns poisoning
and xss[cross zone] detection), SSL MITM for encrypted stream inspection
Sure this would also need to be a special preprocessor,set of
enabled in special cases where you want to do http content inspection
probably you would also use a restricted ruleset.
Still what other IDS out there catch full metasploit payload on this
one? Or even
what product do you know will do SSL decoding / Inspection and
being the gateway[proxy] for the information?
Overall, im just stating that having a mechanism that
inspect http content keep http state and detect malicious behavior
[going to web server, going to web clients ] you need to have
a product or opensource components that will be built for the purpose ,
you can have your IDS do the everything everytime.
More information about the Snort-devel