Re: Disabling rules for one argument
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
>
--
--
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
RSS Feed