Add a new known issue for replacement phase 1 rules

[RedXanadu]

If completely replacing a CRS phase 1 rule (not just updating a rule target etc. but completely replacing a rule, i.e. the operator is being modified) then this cannot occur in the REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf file because any anomaly scoring will be wiped and set to 0 immediately after when REQUEST-901-INITIALIZATION.conf executes.

RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf is also no good as the replacement rule needs to come before REQUEST-949-BLOCKING-EVALUATION.conf/RESPONSE-959-BLOCKING-EVALUATION.conf so that the replacement rule correctly contributes to anomaly scoring totals. Otherwise, things like early blocking mode can start to break.

Document corner case as a known issue.

Include two ideas as solutions:

• SecRuleRemoveById and then add new rule, all after the includes
• Add in a custom REQUEST-902-CUSTOM-RULES-POST-INIT file, or something similar, if there are going to be many such replacement rules

---

Reference: coreruleset/coreruleset#2878

[dune73]

I see some merit in a 902 rule file. But I would like to postpone the discussion after 4.0. We need to think this through and it also touches on the idea of a CRS recommend rules file.

[RedXanadu]

As discussed in this evening's team chat, the original PR that spawned this new issue will be closed, while this documentation issue will remain open so that we can have a rethink about the underlying problem post-CRS 4.0.

[fardarter]

@RedXanadu Appreciate this approach. Glad it continues to stay on the table.

[fzipi]

Are we going to do something here before v4 LTS? CC: @RedXanadu