Description
There is a difference in behavior between Coraza and ModSecurity v2 regarding the log action.
This difference was revealed with CRS rule 980170. As of this the rule message is never logged into error log and the "reporting feature" of CRS is not working out of the box for Coraza.
But this is a general issue with all rules in phases 3, 4 & 5. In general, rules don't have the log action, and CRS ensures that the matched rules are logged by setting the SecDefaultAction. However, the crs-setup.conf.example only recommends this for phases 1 & 2.
The main behavioral difference between the two engines is that ModSecurity enables logging by
default for all phases, whereas Coraza only enables it for phase 2.
This finding has also been discussed on Coraza side corazawaf/coraza#1606, ending up with a recommended coraza conf enabling setting SecDefaultAction for the remaining phases.
Solution proposal
A proposed solution would be to extend the crs-setup.conf.example with SecDefaultAction for phase 3,4 & 5 as well. This would ensure all the required settings for the CRS are working as intended, are handled by CRS itself, and do not rely on the engine's defaults.
libmodsecurity3 + Nginx
Based on feedback from @airween , the rule 980170 is also not triggered on libmodsecurity3 + Nginx:
And just to complete the experiences: libmodsecurity3 + Nginx does not log this rule at all, even I add the log action to the rule... Actually I don't know it's a library issue or the connector does not handle that.
So the CRS reporting features also don't work out-of-the-box with the ModSecurity-Nginx connector. But it has not looked into the details yet, why this is. And it may or may not have the same source of the issue.
This issues started as a slack thread and was moved here: https://owasp.slack.com/archives/CBKGH8A5P/p1781684644578379
Your Environment
- CRS v4.25.0
- Coraza v3.7.0 + coraza-envoy-go-filter v2.0.1
Confirmation
Description
There is a difference in behavior between Coraza and ModSecurity v2 regarding the
logaction.This difference was revealed with CRS rule 980170. As of this the rule message is never logged into error log and the "reporting feature" of CRS is not working out of the box for Coraza.
But this is a general issue with all rules in phases 3, 4 & 5. In general, rules don't have the log action, and CRS ensures that the matched rules are logged by setting the
SecDefaultAction. However, thecrs-setup.conf.exampleonly recommends this for phases 1 & 2.The main behavioral difference between the two engines is that ModSecurity enables logging by
default for all phases, whereas Coraza only enables it for phase 2.
This finding has also been discussed on Coraza side corazawaf/coraza#1606, ending up with a recommended coraza conf enabling setting
SecDefaultActionfor the remaining phases.Solution proposal
A proposed solution would be to extend the
crs-setup.conf.examplewithSecDefaultActionfor phase 3,4 & 5 as well. This would ensure all the required settings for the CRS are working as intended, are handled by CRS itself, and do not rely on the engine's defaults.libmodsecurity3 + Nginx
Based on feedback from @airween , the rule 980170 is also not triggered on libmodsecurity3 + Nginx:
So the CRS reporting features also don't work out-of-the-box with the ModSecurity-Nginx connector. But it has not looked into the details yet, why this is. And it may or may not have the same source of the issue.
This issues started as a slack thread and was moved here: https://owasp.slack.com/archives/CBKGH8A5P/p1781684644578379
Your Environment
Confirmation