Coreruleset: Scanner detection not worked on modsecurity 3.x if SecRequestBodyAccess is Off

[SandakovMM]

Describe the bug

I have a little problem with moving from modsecurity 2.9.3 on Apache to modsecurity 3.0.4 on nginx.
For checking I do request with curl like:
curl -H "User-Agent: Nikto" [my_host]

In my configuration i use "SecRequestBodyAccess Off". This needed to make fastest checks and go further.

When I use ruleset with modsecurity 2.9.3 on Apache with "SecRequestBodyAccess Off" all works fine. Rule with id 913100 from REQUEST-913-SCANNER-DETECTION.conf block my request.
When I use modsecurity 3.0.4 on nginx this rule doesn't block my request. Seems like rule 913100 don't be executed in this case at all (based on modsecurity logs: _"[160585442791.933958] [/] [4] Request body processing is disabled"_).

Background.

As far as i could see behaviour of SecRequestBodyAccess was changed in modsecurity 3.x against modsecurity 2.x. At modsecurity 2 this parameter just avoid reading of request body, but rules at phase 2 works if they don't depend on request body. But since version 3 if this parameter if Off, any rules in phase 2 just dropped.
For some reason rules in REQUEST-913-SCANNER-DETECTION.conf file checks REQUEST_HEADERS, but placed to phase 2. Not sure why, maybe someone can help with it?

Proposal.

Seems like there can be fixed with moving this rules (that checks only request headers, but not request body) from phase 2 to phase 1. I could try to make PR about it if this is fine from your point of view.

Steps to reproduce

1. Use modsecurity 3.0.4 with nginx
2. Add "SecRequestBodyAccess Off" to modsecurity configuration
3. Make request:
   curl -H "User-Agent: Nikto" [my_host]
4. Request passed, nothing in modsecurity audit log.

Expected behaviour

Request is blocked just like in case with apache and modsecurity 2.x.

Actual behaviour

Request passed, nothing in modsecurity audit log.

Your Environment

Ruleset version: 3.0.2, also checked on 3.4/dev branch with same result.
Paranoia level: 1
ModSecurity version: 3.0.4
nginx version: nginx/1.18.0
OS: CentOS-7

[airween]

Hi @SandakovMM,

thanks for reporting, we'll investigate this issue soon.

[airween]

Hi @SandakovMM,

thanks again this report - looks like this is a ModSecurity bug. I've created a new issue at there, and now I'm going to close this one.

Btw keep in touch with me, we're planning to move some rules from phase:2 to phase:1, hope that will solve your problem.

[airween]

Hi @SandakovMM,

just for your information: there is a PR (#1941), you can check with your instance - hope that will solve your problem.

[SandakovMM]

Hooray! Thank you very much @airween

[SandakovMM]

Hi @airween
I checked ruleset with your fix. Original problem is fixed as far as I could see. With this ruleset I get messages from rule 913100 in audit log. Thank you for a fix again :)
But there is another problem. When I using ruleset with modsecurity 2.9.4 on apache, request is blocked with code 403. But not in case with modsecurity 3.x + nginx.
I made a little research about it. Seems like base problem is same: phase 2 rules not executed. Based on audit log from apache, I found out that request is blocked by rule with id 949110 from REQUEST-949-BLOCKING-EVALUATION.conf.
When i moved this rule and some another connected rules("id:949060, "id:949061, "id:949062, "id:949063) to phase 1 problem is gone. But as far as i understood this is totally wrong decision, because rule 949110 needed to use anomaly score from phase 2 such as from phase 1. So if we moved it to phase 1, there is no rule that can react to anomaly score at phase 2. Am i right?

Also i must add a little context about crs-setup.conf. I using this rules as default action:

SecDefaultAction "phase:1,log,auditlog,pass"
SecDefaultAction "phase:2,log,auditlog,pass"

If i remove them with:

# SecDefaultAction "phase:1,log,auditlog,deny,status:403"
# SecDefaultAction "phase:2,log,auditlog,deny,status:403"

requests is going to be blocked on 913100 failed as expected.

Seems like this is question can be moved to another issue, whichever is more convenient for you.

[airween]

Hi @SandakovMM,

I checked ruleset with your fix. Original problem is fixed as far as I could see. With this ruleset I get messages from rule 913100 in audit log. Thank you for a fix again :)

You're welcome - it's good to see that helped to you.

But there is another problem. When I using ruleset with modsecurity 2.9.4 on apache, request is blocked with code 403. But not in case with modsecurity 3.x + nginx.
I made a little research about it. Seems like base problem is same: phase 2 rules not executed. Based on audit log from apache, I found out that request is blocked by rule with id 949110 from REQUEST-949-BLOCKING-EVALUATION.conf.

Yep, I see your pain. But I'm afraid we can't help it immediately.

When i moved this rule and some another connected rules("id:949060, "id:949061, "id:949062, "id:949063) to phase 1 problem is gone. But as far as i understood this is totally wrong decision, because rule 949110 needed to use anomaly score from phase 2 such as from phase 1. So if we moved it to phase 1, there is no rule that can react to anomaly score at phase 2. Am i right?

Yes, you're absolutely right.

I've added a comment to the issue at ModSecurity. If you want to follow that thread, you can subscribe it.

Also i must add a little context about crs-setup.conf. I using this rules as default action:

SecDefaultAction "phase:1,log,auditlog,pass"
SecDefaultAction "phase:2,log,auditlog,pass"

If i remove them with:

# SecDefaultAction "phase:1,log,auditlog,deny,status:403"
# SecDefaultAction "phase:2,log,auditlog,deny,status:403"

requests is going to be blocked on 913100 failed as expected.

Seems like this is question can be moved to another issue, whichever is more convenient for you.

We (CRS team) will have the meeting next Monday, hope we can discuss this request.