8 Jul 13:08
Re: Disabling rules for one argument
From: Nick Gearls <nickgearls <at> gmail.com>
Subject: Re: Disabling rules for one argument
Newsgroups: gmane.comp.apache.mod-security.user
Date: 2008-07-08 11:08:42 GMT
Subject: Re: Disabling rules for one argument
Newsgroups: gmane.comp.apache.mod-security.user
Date: 2008-07-08 11:08:42 GMT
There could potentially be a solution.
Is there any way to use a transaction/environment variable inside a
check, like
SecRule ARGS|!ARGS:'/%{tx.ignored}/' ...
That would be one way of achieving the result, at least in some
circumstances
Nick
Brian Rectanus wrote:
> Nick Gearls wrote:
>> Thanks Barnett,
>> I was a bit afraid beforehand about the answer
>>
>> If I understand correctly, there is no way, for example, to remove a
>> core rule check for one argument without modifying the core rule,
>> right ?
>
>
> To some degree. It is a needed feature ;)
>
> You can remove the rule and write a replacement, but it is a config
> time, not a runtime feature (ie you must use SecRuleRemoveById vs
> ctl:ruleRemoveById). But, doing this, you do not have to touch the
> actual core rule file unless you need the rule in the same order.
>
>
>> How does the ctl:ruleRemoveById rule work exactly ?
>> I suppose it is evaluated
>> 1. either before the id rule is defined
>> -> id was not defined
>> -> ignored
>> 2. or after the id rule is defined
>> -> the request was already blocked
>> -> never reached
>
> The ctl actions are evaluated at runtime. So, in this case, it builds a
> list of rule IDs to remove. if it comes accross one of those rules in
> the future, then it is just skipped. So, you need the
> ctl:ruleRemoveById=N rule to be executed *before* the rule N.
>
> Note, that the ctl:ruleRemoveById action does handle prior removal of
> the rule via SecRuleRemoveById (which must be used after the rule) as
> well as removal of the rule targetd with a skipAfter action.
>
> -B
>
>>
>> Regards,
>>
>> Nick
>>
>>
>> Ryan Barnett wrote:
>>>> -----Original Message-----
>>>> From: Nick Gearls [mailto:nickgearls <at> gmail.com]
>>>> Sent: Friday, July 04, 2008 11:04 AM
>>>> To: Ryan Barnett
>>>> Cc: mod-security-users <at> lists.sourceforge.net
>>>> Subject: Re: [mod-security-users] Disabling rules for one argument
>>>>
>>>> Obviously, I was not specific enough.
>>>>
>>>> I want to create a rule for all arguments at the global level, then,
>>>> inside a sub-location, disable it for one specific argument.
>>>> Ex:
>>>> SecRule ARGS "bad pattern" "id:10000,..."
>>>> ...
>>>> <Location ...>
>>>> SecRule ARGS:name \
>>>> "phase:2,t:none,allow,nolog,ctl:ruleRemoveById=10000"
>>>> </Location>
>>>>
>>> [Ryan Barnett] Thanks for clarifying. This is a bit of a tricky one :)
>>> In order to get the rule logic that you want, you will most likely need
>>> to use some combination of skip actions. Here is an example rule set
>>> that should work (not tested though) -
>>>
>>> SecRule REQUEST_FILENAME "^/location/path/"
>>> "chain,phase:2,id:10000,deny"
>>> SecRule ARGS|!ARGS:name "bad pattern"
>>> SecRule REQUEST_FILENAME "^/location/path/" "phase:2,nolog,pass,skip:1"
>>> SecRule ARGS "bad pattern" "phase:2,id:10001,..."
>>>
>>> The 1st rule evaluates the Location that you wanted for the exception
>>> and then applies the updated variable list. Next, you need to use that
>>> same Location check to determine if you are going to run your global
>>> rule or not. If it is not the exception Location then it will run your
>>> global rule.
>>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> mod-security-users mailing list
>> mod-security-users <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>>
>
>
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
RSS Feed