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

[<ltn...@an...>]

Hi,

holy c...! I completely missed the fact that the phase in the rule I want to disable (1) is before my whitelist ("request")..

Thanks a lot. Went quiet like in a grave in my Graylog now. Exactly the way I like it :)

/Eirik

> On 24 Feb 2019, at 18:56, Manuel Spartan <spa...@gm...> wrote:
> 
> 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/
> _______________________________________________
> 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/