Re: [mod-security-users] Still content compression problems with2.5?

[Stefan Müller-W. <ste...@re...>]

Thanks Avi and Ryan for your answers.

Just to make sure I got that one right: does that mean that if I switch off content compression on the app server and enable mod_deflate and mod_security on the Apache httpd, I _should_ no longer get content compression blind spots with 2.5 and get rid of the 960903 while getting all benefits of ModSecurity?

Cheers
 Stefan.

________
Von: Ryan Barnett [Ryan.Barnett@Breach.com]
Gesendet: Donnerstag, 20. März 2008 15:48
An: Avi Aminov; Stefan Müller-Wilken; mod...@li...
Betreff: RE: [mod-security-users] Still content compression problems with2.5?

> -----Original Message-----
> From: mod...@li... [mailto:mod-
> sec...@li...] On Behalf Of Avi Aminov
> Sent: Thursday, March 20, 2008 10:32 AM
> To: Stefan Müller-Wilken; mod...@li...
> Subject: Re: [mod-security-users] Still content compression problems
> with2.5?
>
>
> > -----Original Message-----
> > From: mod...@li... [mailto:mod-
> > sec...@li...] On Behalf Of Stefan
> M?ller-
> > Wilken
> > Sent: Thursday, March 20, 2008 3:17 PM
> > To: mod...@li...
> > Subject: [mod-security-users] Still content compression problems with
> 2.5?
> >
> > [This is a repost as I didn't see my post arrive on the list - sorry, if
> > it actually now has twice!]
> >
> > Dear all,
> >
> > we're still struggling with the infamous content compression problems
> with
> > a screened tomcat gzipping its output and flooding our reverse proxy
> logs
> > with "id 960903" errors. Two questions:
> >
> > a) Why can't I switch of 960903 using "SecRemoveRuleById "960903" as I
> can
> > with all other CRS rules?
>
> [Avi] Actually this should work. Do note that the name is
> SecRuleRemoveById, and not SecRemoveRuleById, and the directive should
> appear _after_ the rule itself.
>
[Ryan Barnett] Also note that with 2.5, you have the "ctl:ruleRemoveById" action.  Two benefits of the ctl action vs. the directive -

1) You can specify disabling a rule based on any Mod data.  Most people either specify SecRuleRemoveById globally or they use the Apache Scope directives such as Location which only allows you to disable a rule based on the URI data.

2) Another nice feature is that you do not have to specify it AFTER the rule you are disabling like you have to do with SecRuleRemoveById.  You can specify the ctl action anywhere in the config and Mod will disable the rule appropriately.  This makes it a bit easier to avoid issues.

> >
> > b) Does version 2.5 support combining mod_deflate with mod_security
> (e.g.
> > by defining the order in which the two are executed) to switch off
> content
> > compression on the app server and relocate it to the reverse proxy?
>
> [Avi] on an embedded system, modSecurity runs before mod_deflate on the
> reply, so inspection is possible. On a reverse proxy, the content is
> already compressed, so if you still need the compression to the backend,
> you can use apache's filter directives to define running mod_deflate to
> decompress, then mod_security, then mod_deflate again to recompress.
>
[Ryan Barnett] What Avi outlines certainly would work, however there would be a hit on processing and latency.  Ideally the process of compressing outbound content should be handled by the Mod reverse proxy so that the communication between the proxy and the backend web app is normal.

Brian Rectanus may have more info along these lines as he is our resident guru for Apache/Mod interactions.


Resco GmbH
Geschäftsführer: Michael Mörchen
Amtsgericht Hamburg, HRB 76048
Ust.Ident-Nr.:DE208833022

Haftungsausschluss: Diese Nachricht ist ausschließlich für die Person oder Einheit bestimmt, an die sie gerichtet ist. Sie enthält unter Umständen Informationen, die unter geltendem Recht vertraulich, gesetzlich geschützt oder von der Offenlegung ausgeschlossen sind. Falls Sie nicht der vorgesehene Empfänger oder verantwortlich für die Weiterleitung dieser Nachricht an den vorgesehenen Empfänger sind, ist es Ihnen strengstens untersagt, diese Nachricht offenzulegen, zu verteilen, zu kopieren oder in irgendeiner Art zu benutzen. Sollten Sie diese Nachricht versehentlich erhalten haben, benachrichtigen Sie bitte den Absender und löschen und vernichten Sie jegliche Kopie davon, die Sie möglicherweise erhalten haben.

Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.