Re: [mod-security-users] ctl:ruleRemoveById not working?

[Manuel S. <spa...@gm...>]

Hi Eirik,

You could try setting the debug level to 4 and follow the order of
execution and precedence of the rules, some cases requires the rule to be
defined before you hit the rule they are modifying while others have to be
processed before the rule you need to change.Let me try to explain it
because it is a bit confusing.

Supposing you want to disable rule 1 you have many options that work and
some that will not work like:

Inclusion order:
 SecRule id:1
 SecRuleRemoveById 1

Results in rule 1 disabled but if they are reversed it will not work as the
rule 1 would be created after it was removed

Inclusion order (same phase):
 SecRule id:1
 SecRule id:2,ctl:RuleRemoveById=1

Results in rule 1 being processed before 2 is executed, unless rule 2 is
included before 1

Inclusion order (different phases):
 SecRule id:1,phase:2
 SecRule id:2,phase:1ctl:RuleRemoveById=1

Results in rule 2 being processed before 1 is executed as the orders are
evaluated by phase then by inclusion order

Cheers!

El dom., 24 feb. 2019 a las 11:20, <ltn...@an...> escribió:

> Hi again,
>
> as always when I raise a question, it manage to butcher the test case. Due
> to a confusion about which CRS version was being used, the below is only
> partially true. My findings so far indicate that the initial SecRule fails
> to trigger, so the ctl: part (no matter if I use ruleRemoveById,
> ruleRemoveByTag or ruleRemoveTargetByTag) never takes effect.
>
> I've tried variants of
> SecRule REQUEST_HEADERS:Content-Type "@unconditionalMatch"
> SecRule REQUEST_HEADERS:Content-Type "@rx charset\s*=\s*([^;\s]+)"
> SecRule REQUEST_URI "@rx
> ^(/mdpayacs/pareq|/pan-tokenisation/PanTokenServiceImpl).*"
>
> to make it stick, to no avail. I'm not terribly experienced here and might
> be beating about the bush in all the wrong ways, but any help would be
> welcome. Sorry about the noise.
>
> /Eirik
>
> > On 24 Feb 2019, at 16:19, ltn...@an... wrote:
> >
> > Hi all,
> >
> > I feel like I'm going blind here, I'm sure the problem is obvious and
> (to me) embarrassing. But - I'm trying to write a whitelist rule that
> selectively disabled a specific rule:
> >
> > # acs: Some clients stick charsets in content-type request headers
> > SecRule REQUEST_HEADERS:Content-Type "@rx charset\s*=\s*([^;\s]+)" \
> >    "phase:request,id:1103,t:none,pass,nolog,tag:'md-debug',chain,\
> >        ctl:ruleRemoveById=920480"
> >            SecRule REQUEST_URI "@rx
> ^(/mdpayacs/pareq|/pan-tokenisation/PanTokenServiceImpl).*" "t:none"
> >
> > I know the matcher works, because when I use
> >
> ctl:ruleRemoveTargetByTag='OWASP_CRS/PROTOCOL_VIOLATION/CONTENT_TYPE_CHARSET';REQUEST_HEADERS:Content-Type"
> >
> > the whitelist works as expected. I just think disabling the explicit
> rule would be the more correct/cheap thing to do.
> >
> > What am I doing wrong?
> > libmodsecurity 3.0.3 and nginx on FreeBSD, CRS 3.1.0.
> > Note that it works with CRS 3.0.0 but I think rule 920480 is new in 3.1,
> so that would explain that part.
> >
> > /Eirik
> >
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > http://www.modsecurity.org/projects/commercial/rules/
> > http://www.modsecurity.org/projects/commercial/support/
> >
>
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>