No subject

Thu Nov 23 16:31:58 EST 2017

than any IDS out there.

Even with a proxy that report event to a managed console of whatever
type and a solid NIDS net that monitor your network your still at risk,
but giving the right tool the right subject to observe will give you
more fine grained information that obviously would be lost over the
noise generated only by an IDS.=20

I guess this kind of issues are on the thin line and questionability
about HTTP preprocessing expension
should be taken with care, how mutch processing do you think it would
take to decompress every gziped header=20
a sensor can meet on the wire lets say at some 300Mbps.=20

I guess an other part of the problem is that the open source version of
snort ( not idea on what  can be runned on sourcefire appliance) are
single threaded and that decoding can't be done asyncroniously while
processing other packets so even if you use buffered libpcap you might
encounter major overhead here generated only by one preprocessor.=20

Are you going to deploy an http_gunzip preprocessor version of snort
with a normal snort version side to side on the same wire for mabey few
exploit attempt over gziped content?

Furthermore there is alot of other concern over HTTP based signature
like javascript & al , just think
base64 encoded script.


Eric Lauzon

> -----Original Message-----
> From: snort-devel-admin at
> [mailto:snort-devel-admin at] On Behalf Of=20
> Frank Knobbe
> Sent: 2 janvier 2006 09:35
> To: snort-devel at
> Subject: [Snort-devel] http_gunzip preprocessor
> Greetings,
> the third version of the metasploit for the WMF issue is=20
> capable of gzipped HTTP responses. Any attack (and I have=20
> caught a few in the past) that runs over compressed HTTP=20
> responses is not detected by Snort.
> While a gunzip implementation in the http_inspect=20
> preprocessor is certainly harmful to performance, I believe=20
> the capability should be added nevertheless so that the user=20
> may enable it in times when it is needed. Currently, with the=20
> next, still unpatched WMF exploits using compressed HTTP,=20
> this capability is absolutely essential. Without it, Snort=20
> can not compete against other IDS systems that support=20
> decompression of gzipped HTTP traffic.
> So my question to the developers is: Will Snort receive this=20
> capability any time soon? Is anyone working on an=20
> http_inspect_gunzip preprocessor yet?=20
> Regards,
> Frank
> --
> It is said that the Internet is a public utility. As such, it=20
> is best compared to a sewer. A big, fat pipe with a bunch of=20
> crap sloshing against your ports.

More information about the Snort-devel mailing list