Re: [mod-security-users] Two LocationMatch blocks for the same fileor directory with different methods

[Ryan B. <Ryan.Barnett@Breach.com>]

> -----Original Message-----
> From: mod...@li... [mailto:mod-
> sec...@li...] On Behalf Of modsecowa
> Sent: Thursday, April 05, 2007 12:04 PM
> To: Christian Folini
> Cc: Mod Security
> Subject: Re: [mod-security-users] Two LocationMatch blocks for the
same
> fileor directory with different methods
>=20
> Hi,
>=20
> Let me first get back to our "chained solition", this one didn't
exactly
> seemed to work the way we expected;
>=20
> <LocationMatch "/some/url">
> 	SecRule REQUEST_METHOD "!^(GET|SUBSCRIBE)$"
> 	SecRule REQUEST_METHOD "^GET$" "t:none,chain"
> 	SecRule1
> 	SecRule2
> 	...
> 	SecRule REQUEST_METHOD "^SUBSCRIBE$" "t:none,chain"
> 	SecRule3
> 	SecRule4
> 	...
> 	SecAction "allow,t:none,msg:'Request method passed all checks
and it
> is thus allowed'"
> </LocationMatch>
>=20
>=20
> Only the first rule after the 'chain action' is triggered only for the
> specified method. The second and all following rules after the chain
> apply to both (get & subscribe) methods. It seems like the length of a
> chain can only be two lines. so we had to work this around like this;
>=20
> <LocationMatch "/some/url">
> 	SecRule REQUEST_METHOD "!^(GET|SUBSCRIBE)$"
> 	SecRule REQUEST_METHOD "^GET$" "t:none,chain"
> 	SecRule1
> 	SecRule REQUEST_METHOD "^GET$" "t:none,chain"
> 	SecRule2
> 	...
> 	SecRule REQUEST_METHOD "^SUBSCRIBE$" "t:none,chain"
> 	SecRule3
> 	SecRule REQUEST_METHOD "^SUBSCRIBE$" "t:none,chain"
> 	SecRule4
> 	...
> 	SecAction "allow,t:none,msg:'Request method passed all checks
and it
> is thus allowed'"
> </LocationMatch>
>=20
>=20
> Not very pretty but it works though. Question: Is there a way to
create
> a chain which is longer than only 2 rules?
>=20
[Ryan Barnett] You can have many rules within one chain, you just need
to specify the chain action on each rule.  The last rule without a chain
action specified is considered the last rule in the chain.


> The solution described by Christian doesn't seem to work for us at
all.
> In fact we haven't seen the 'skip action' in action yet at all. (we
are
> testing this in an OWA/Exchange scenario)
>=20
> A rule like
>=20
> SecRule REQUEST_METHOD "^GET$" "t:none,skip:1"
>=20
> as mentioned in Christian's solution, will immediately deny every GET
> method passing by.
> audit_log:
>=20
> Message: Warning. Pattern match "^GET$" at REQUEST_METHOD.
> Message: Access denied with code 403 (phase 2). Unconditional match in
> SecAction.
>=20
>=20
> Question: Is there a solution to use the "skip action" in this
> whitelisting scenario ?
[Ryan Barnett] If you do not specify a disruptive action then it will
inherit the SecDefaultAction setting (most likely a deny with a 403
status code).  For that whitelisting scenario, you would need to specify
a "pass" action.