Hi there,

I have been thinking about this problem for a while.
So far we have two possible solutions.

Ryan proposed to skip rule-blocks adressing the 2nd (or n-th) 
http_method. Rick and Helwin opted for rule chaining.

Initially I thought rule chaining would be the way to go here,
but this is very limiting for complicated rulesets.

So I am back to skipping. Yet I added a twist. What does the
mailing list think about this proposal (still all in phase 2)?

<LocationMatch "/some/url">

    SecRule REQUEST_METHOD "!^(GET|SUBSCRIBE)$"  "t:none,deny,..."

    SecRule REQUEST_METHOD "^GET$" "t:none,skip:1"
    SecRule REQUEST_METHOD "^SUBSCRIBE$" "t:none,skip:n"  -> n is the distance to the SUBSCRIBE rule group

    # http_method GET skip-target-point
    SecRule-1
    SecRule-2
    SecRule-3
    ...
    SecRule-n-2
    SecAction "skip:k"  -> jump to the final allow-rule

    # http_method SUBSCRIBE skip target-point
    SecRule-1
    SecRule-2
    SecRule-3
    ...
    SecRule-k-1

    # final allow-rule skip-target-point
    SecAction "allow,t:none,msg:'Request method passed all checks and is thus allowed'"

</LocationMatch>

I do not think this is very feasible for handwritten rulesets.
But with a rule-generator, the skip distances can be calculated
automatically. So I will try add this to the next remo release.

Unless there is something I missed.

Christian

On Wed, Apr 04, 2007 at 07:31:01AM +0200, modsecowa wrote:
> Hi,
> 
> We tried this to allow multiple specified methods (get and subscribe in 
> this example) on one location with different rules:
> 
> <LocationMatch "/some/url">
>     SecRuleA
>     SecRuleB
> 
>     SecRule REQUEST_METHOD "!^GET$" "t:none,skip:3"
>     SecRule1
>     SecRule2
>     SecRule3
> 
>     SecRule REQUEST_METHOD !"!^SUBSCRIBE$" "t:none,skip:4"
>     SecRule4
>     SecRule5
>     SecRule6
>     SecRule7
>     SecAction "allow,t:none,msg:'Request method passed all checks and is thus allowed'"
> </LocationMatch>
> 
> Which resulted in a deny for every subscribe method for the specified 
> location. This is because
> 
> SecRule REQUEST_METHOD "!^GET$" "skip:3"
> 
> matches "SUBSCRIBE /some/url/".
> 
> Anyways, we've tried a bit and found the following solution which worked 
> fine for us:
> 
> <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> 
> 
> 
> The fist rule denies every other method than get or subscribe (eg. post 
> or search) for the specified location. This rule is followed by two rule 
> chains for the allowed methods for this location.
> NB. all rules are processed in phase 2.
> 
> greetz,
> 
> Rick & Helwin.
> 
> Ryan Barnett schreef:
> >> -----Original Message-----
> >> From: mod-security-users-bounces <at> lists.sourceforge.net [mailto:mod-
> >> security-users-bounces <at> lists.sourceforge.net] On Behalf Of Christian
> >> Bockermann
> >> Sent: Friday, March 30, 2007 9:41 AM
> >> To: modsecowa <at> gmail.com
> >> Cc: Mod Security
> >> Subject: Re: [mod-security-users] Two LocationMatch blocks for the
> >>     
> > same
> >   
> >> fileor directory with different methods
> >>
> >>
> >> Am 30.03.2007 um 15:33 schrieb modsecowa <at> gmail.com:
> >>
> >>     
> >>> Hi,
> >>>
> >>> In Outlook Web Access, it is possible for some files or directories
> >>> that both the GET and SUBSCRIBE methods are used. However, we can't
> >>> create two LocationMatch blocks in the ModSecurity configuration
> >>> for the same directory or file. That is because the first
> >>> LocationMatch block will always match and if the used method does
> >>> not comply with the rule the request is rejected. So this means
> >>> that the second LocationMatch block that contains the correct
> >>> method will never be looked at. It is possible to create one "big"
> >>> rule that accepts both GET and SUBSCRIBE methods, but then you also
> >>> have to specify all possible headers and other options which
> >>> originally never will be used against the file or directory when
> >>> one of the two methods is used. But ModSecurity is then configured
> >>> to accept those options, which doesn't seem appropiate when using
> >>> whitelisting/positive security model.
> >>>
> >>> Perhaps there is simple way to work around this, but we did not
> >>> find the solution yet. Does someone know how to handle this
> >>> scenario using the positive security model in ModSecurity?
> >>>
> >>> We are using ModSecurity 2.1.0 with Apache 2.2.4 on a Linux
> >>> distribution.
> >>>
> >>>       
> > [Ryan Barnett] Keep in mind that you don't have to use the Apache Scope
> > directives such as LocationMatch to trigger on URL locations.  You can
> > instead use ModSecurity chained rules.  Most people opt to use the
> > LocationMatch directives since it is a bit "prettier" on the eyes to
> > visually see what context the rules are running in however there are
> > some limitations as you have pointed out.  Additionally, Apache scope
> > directives can only run in Mod phase:2 so you could use Mod chained
> > rules in phase:1 if you wanted to check on the URL and Request Headers.
> >
> >   
> >> You can create rules that depend on the request-method like this:
> >>
> >>
> >> <LocationMatch "/some/url">
> >>     SecRuleA
> >>     SecRuleB
> >>
> >>     SecRule REQUEST_METHOD !"GET" "skip:3"
> >>     SecRule1
> >>     SecRule2
> >>     SecRule3
> >>
> >>     SecRule REQUEST_METHOD !"SUBSCRIBE" "skip:4"
> >>     SecRule4
> >>     SecRule5
> >>     SecRule6
> >>     SecRule7
> >> </LocationMatch>
> >>
> >>
> >> This way, rules "A" and "B" are checked for all requests that hit "/
> >> some/url" regardless
> >> by which method. When a GET-request arrives, additionally Rules 1,2,3
> >> get checked and
> >> as "GET" does not match "SUBSCRIBE" rules 4,5,6,7 will be skipped and
> >> vice versa.
> >>
> >>     
> > [Ryan Barnett] I think your description of the rules is reversed.  If
> > the Request Method for that location is GET, then rules A, B, 4, 5, 6
> > and 7 will be executed in that order.  If the Request Method is
> > SUBSCRIBE, then rules A, B, 1, 2 and 3 will execute in that order.  This
> > is also assuming that all of those sample rules are running in phase:2
> > (since it was not specified).
> >
> > A few more syntax notes - the "!" character for inverted rules needs to
> > go inside the double-quotes otherwise it is assuming that the
> > double-quotes are part of the actual RegEx pattern.  Should be like this
> > - "!GET" - and even better is like this with anchor tags - "!^GET$".
> > Also check to verify if there are any transformation functions (such as
> > lowercase) being applied.  If so, the rule should then read - "!^get$"
> >
> >   
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> mod-security-users mailing list
> mod-security-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mod-security-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV