Open EsadCetiner opened 3 months ago
Hi @EsadCetiner,
many thanks for your detailed answer here too. I'm sorry that I didn't see the original report, now I wrote an answer under that issue.
I keep this issue open while it won't be clear that this behavior is really a bug or your config has some mistake. Or feel free to close it if you think that's not a ModSecurity issue.
Thanks again.
Thank you for the reply @airween, I wasn't able to respond earlier but I have time now.
I didn't use the REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
file for the rules I provided, I completely forgot it's a thing. I re-tested by placing my rules in there, but I'm still observing the same behavior.
Sending curl http://127.0.0.1?exec=/bin/bash
gives me these results:
Request is blocked with 403, as expected when using this code
SecRule REQUEST_HEADERS:Host "!@streq example.com" "id:1,phase:1,pass,t:none,nolog,ctl:ruleRemoveById=2"
SecRule REQUEST_FILENAME "@unconditionalMatch" \
"id:2,phase:1,pass,t:none,nolog,ctl:ruleRemoveByTag=OWASP_CRS"
Request is allowed with 200 when using this code, which is not expected behavior.
SecRule REQUEST_HEADERS:Host "!@streq example.com" "id:1,phase:1,pass,t:none,nolog,ctl:ruleRemoveById=2"
SecAction \
"id:2,phase:1,pass,t:none,nolog,ctl:ruleRemoveByTag=OWASP_CRS"
This is how I'm including the files into ModSecurity, in case your doing it a bit different to me:
Include /etc/nginx/modsecurity/coreruleset/crs-setup.conf
Include /etc/nginx/modsecurity/coreruleset/plugins/*-config.conf
Include /etc/nginx/modsecurity/coreruleset/plugins/*-before.conf
Include /etc/nginx/modsecurity/modsecurity.conf
Include /etc/nginx/modsecurity/coreruleset/rules/*.conf
Include /etc/nginx/modsecurity/coreruleset/plugins/*-after.conf
SecAuditLog /var/log/modsec_audit.log
nginx.conf:
modsecurity on;
modsecurity_rules_file /etc/nginx/modsecurity/main.conf;
And I have SecRuleEngine
set to on
.
My test environment is minimal, so I'm not sure what kind of a config issue it could be.
This is my debug log (set to 4) when trying to disable a SecAction. all that stood out to me was this, which as I understand it, means that rule 2 wasn't disabled.
[170748352988.757381] [/?exec=/bin/bash] [4] (Rule: 1) Executing operator "StrEq" with param "example.com" against REQUEST_HEADERS:Host.
[170748352988.757381] [/?exec=/bin/bash] [4] Rule returned 1.
[170748352988.757381] [/?exec=/bin/bash] [4] Running (disruptive) action: pass.
[170748352988.757381] [/?exec=/bin/bash] [4] (Rule: 2) Executing unconditional rule...
[170748352988.757381] [/?exec=/bin/bash] [4] Running (disruptive) action: pass.
And this is when I'm disabling a SecRule, where everything is working as expected. debug_secrule.log
If your still having trouble reproducing, I can try to give you a test environment for you to download where the issue occurs.
Hi @EsadCetiner,
thanks again your detailed report - now I see the problem. Meantime we chatted about this issue and we convinced that it works on Apache (mod_security2).
I created a regression test file, anyone can try this issue.
I think we should change the behavior of the engine that it should disable SecAction
items too, not just SecRule
's.
Any other opinions are welcome.
Describe the bug
In libmodsecurity3, SecAction can't be disabled via a ctl action like with SecRules. This issue isn't present in ModSecurity2.
Logs and dumps
N/A
To Reproduce
Steps to reproduce the behavior:
apt install nginx-extras libnginx-mod-http-modsecurity
SecRuleEngine
directive set to on, but it shouldn't matter what rulesets are used.Include /etc/nginx/modsecurity/coreruleset/rules/*.conf
)SecAction \ "id:2,phase:1,pass,t:none,nolog,ctl:ruleRemoveByTag=OWASP_CRS"
SecRule REQUEST_HEADERS:Host "!@streq example.com" "id:1,phase:1,pass,t:none,nolog,ctl:ruleRemoveById=2"
SecRule REQUEST_FILENAME "@unconditionalMatch" \ "id:2,phase:1,pass,t:none,nolog,ctl:ruleRemoveByTag=OWASP_CRS"