See errors with crs 3.3.2

[joshi-mohit]

failed to compile the directive "secauditlogrelevantstatus": error parsing regexp: invalid or unsupported Perl syntax: (?!
Saw this (though not specific to 3.3.2)
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
when moved to this, it works fine
SecAuditLogRelevantStatus "^(?:(5|4)(0|1)[0-9])$"

Getting some pocre errors from rules from Core Rule Set ver.3.3.2
Help needed here
a) Can I pick some some CRS rule set version which I can use directly ?

b)
Noticed similar problem on setting Paranoia level
failed to parse string: failed to compile the directive "secrule": invalid arguments, expected collection TX
SecRule TX:EXECUTING_PARANOIA_LEVEL "@lt 1" "id:913011,phase:1,pass,nolog,skipAfter:END-REQUEST-913-SCANNER-DETECTION"
SecRule TX:EXECUTING_PARANOIA_LEVEL "@lt 1" "id:913012,phase:2,pass,nolog,skipAfter:END-REQUEST-913-SCANNER-DETECTION"

c) other regex related parsing errors

[M4tteoP]

Hi @joshi-mohit, any CRS v3.* is not supported by Coraza v3 and leads to parsing errors. CRS v4 comes with a refactored way of generating the regexes, making them compatible with Go (RE2), and therefore with Coraza.

[joshi-mohit]

oh ok, thanks. was not aware that 4.0 is officially released ?

[M4tteoP]

You are right, It is not officially released yet, but we are pointing to the v4.0/dev branch, keeping up the pace to be fully compatible as soon as it gets officially released. v4.0.0-rc1 is currently the latest tag, not for much longer :)

[joshi-mohit]

In my application using CRS 4.0 RC1,

running a very simple curl request to check SQL injection rules
curl -v http://http-service:8090/jsonloopback/test0 --data '{"email":"[email protected]", "password":"-1+union+select+1,2,3,4,5,6,7,8,9,10"}' -H "X-User-Email: [email protected]" -H "Accept: application/json"
-H "Content-Type: application/json"
once all phases are over in the application running through tx.MatchedRules().

but see too many rules around 70 of them showing as part of MatchedRules -- Most of them are related to setting variables (e.g. setting paranoia levels or setting flags etc
SecRule TX:DETECTION_PARANOIA_LEVEL "@lt 2" "id:930013,phase:1,pass,nolog,skipAfter:END-REQUEST-930-APPLICATION-ATTACK-LFI"

There any way to prevent such rules from showing up in matched_rules. One of the way I thought was checking the severity of the rule (Rule().Severity() as most of them variable setting rules won't have severity -- but then saw all the rules have severity as "emergency"..

Any way to come out of this

[jptosso]

That's a change we have to make, rules without "log" shouldn't expose data in MatchedRules

CC @jcchavezs

[M4tteoP]

I opened a specific issue for this in which we can continue the discussion: #839 and a PR that should implement what has been proposed by @jptosso: #840