[Snort-sigs] Another question about the inspect_gzip option in Snort 2.8.6

Bhagya Bantwal bbantwal at ...435...
Tue May 18 14:23:33 EDT 2010


inspect_gzip will just decompress the compressed data and store it in a
different buffer.

No compression in case of inline mode. So since we don't overwrite the
packet payload with decompressed data we dont need to compress the data
again.

max_gzip_mem (as mentioned in the manual) along with decompress and compress
depths determines the maximum number of http sessions (with gzipped data) to
decompress. This is an optimization option. We dont want the system to run
out of memory trying to decompress all the compressed data.


Hope that helps.
-B

On Tue, May 18, 2010 at 1:26 PM, L0rd Ch0de1m0rt
<l0rdch0de1m0rt at ...2420...>wrote:

> Hello.  I have a simple question about the inspect_gzip option in
> Snort 2.8.6.  I am reading in the manual where it says, on page 55 "To
> enable compression of HTTP server response, Snort should be configured
> with the –enable-zlib flag."  I thought that the inspect_gzip option
> just decompressed the gzip data for Snort, not compressed it.  Or is
> for in-line Snort where the inspected gzipped data gets gzipped back
> up before being passed on?  If so, why not just keep a copy of the
> original gzipped data in a separate buffer and forward that instead.
> I guess if you did that you'd have to drop the whole gzip buffer up to
> max_gzip_mem bytes on an IPS drop event.  Or am I reading too much
> into this?
>
> Thanks.
>
> -L0rd Ch0de1m0rt
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20100518/3920bae8/attachment.html>


More information about the Snort-sigs mailing list