Re: Disabling rules for one argument

Nick Gearls wrote:
> 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

1) /.../ is a regex and pre-compiled, so macro expansion would only
happen at compile time.
2) No macro expansion is allowed in the TARGET (yet). ;)

-B

> 
> 
> 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
> _______________________________________________
> mod-security-users mailing list
> mod-security-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> 

--

-- 
Brian Rectanus
Breach Security

-------------------------------------------------------------------------
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