coreruleset: Add blocking mode for CRS Sandbox
Motivation
Currently, the sandbox never blocks: https://coreruleset.org/docs/development/sandbox/#example
The sandbox will return a 200 response code, no matter if an attack was detected or not.
This can be confusing for tools that benchmark or compare WAF configurations:
- How does my configuration compare to vanilla CRS?
- How does WAF X compare to CRS?
Proposed solution
It would be great if this behaviour could be dynamically changed per request by adding headers. Similar options to control the behaviour of the sandbox are already configurable using headers: https://coreruleset.org/docs/development/sandbox/#changing-options.
Useful options could be:
- Blocking/Detection
- Anomaly Threshold
Alternatives
–
Additional context
One tool that could be interesting with respect to the sandbox is GoTestWAF. This tool provides an option that might help circumvent the problem but I have not got it to wor yet:
--blockRegex string Regex to detect a blocking page with the same HTTP response status code as a not blocked request
FYI: @roguelabs
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 28 (26 by maintainers)
Oh, well, that’s the default, of course. If you set the header
x-crs-mode: blocking, that’s what you get.I think that’s the way to go.
And then we ought to think about whether we want to have 5 as default as with CRS.
@studersi Ok, I’ve implemented the first option using the new header
x-crs-mode: blocking. Anything else will keep mode inDetectionOnly. Do you want to use the new v4 naming for this?Oh, I see it now. I was only thinking on the docker variables side, but then of course those variables are for setting up the rules, so we can always change them from the rules side.
Will try to figure it out using this now.