Hi Michael,
What is the context for this? Are you approaching this as a hobbyist?
For a personal CRS deployment? For a professional/business deployment?
Or maybe you're looking to validate a CRS integration in a commercial
product? Academic testing interest? Something else? I think the
approach and advice given would vary quite a bit...
Both main versions of CRS (v3 and v4) have full test suites that
include positive and negative tests for every* rule (the "benign"
versus "attack" traffic you mentioned.) You can execute these test
suites to ensure a CRS-powered WAF is behaving correctly. Some
deviation is expected between WAF engines (e.g. Apache vs nginx vs
standalone, ModSecurity v2 vs v3, other engines can behave quite
differently, etc.) but, in general, if you find that *many* tests are
failing then that may indicate mis-configuration or an engine problem.
If you get, say 99% passing tests then your deployment is likely
correct (and maybe this is the confirmation you're looking for?).
(*I think the CRS v3.3.7 tests cover *all* rules... But certainly, the
v4 tests are fuller and more complete!)
As for tooling: the go-ftw testing tool is your friend. This is used
by CRS to check for regressions and was written specifically for CRS
and its requirements, written by CRS developers.
* Project page + documentation:
https://github.com/coreruleset/go-ftw
* Releases:
https://github.com/coreruleset/go-ftw/releases
* How we set up containers for testing:
https://github.com/coreruleset/coreruleset/blob/main/tests/docker-compose.yml
*Please note*: You'll almost certainly need an *older version* of the
go-ftw testing tool if you're working with CRS v3. Check out the
version we pin for building the official Docker containers: if you
follow the same testing version we use then you should be able to get
the same results (i.e. passing results).
Alternatively, if you're working with a *specific* web application /
deployment type, it's a very good idea to write your own positive and
negative tests. For example: each rule exclusion you add, you should
include tests to make sure that the relevant false positive stays
fixed! But also add tests to make sure that the 'hole' you open in
your WAF is the correct size and not accidentally too big (e.g. test
against the wrong URI or with the wrong HTTP method and make sure that
a block correctly occurs.)
I hope these thoughts can help you out on your testing journey.
Thanks,
Andrew Howe