OWASP Modsecurity rules showing warnings and does not block anithing

Hi all!

Just a contribution here, after a day breaking my head!
The OWASP rules was notworking, showing only warnings in logs, nothing was blocked.
Before check file orders, configurations, I notice 2 things:

1. The slide that enables modsecurity for each domain was on (green) but no created modsecurity.conf file with SecRuleEngine On. Just Off and On the slide and file was created.
2. The directory /usr/local/apache/conf.d/modsecurity-owasp-latest/rules have 2 files .conf.example. One of those is the MORE IMPORTANT file, REQUEST-901-INITIALIZATION.conf.example. Just copy this file to REQUEST-901-INITIALIZATION.conf

Reload your apache and it's working.

Now if someone would write a KB article on how to upgrade your ModSecurity & OWASP CRS ruleset... 

Hi Starburst

The panel just update rules automatically.
Happens to m, now, the OWASPrules are updated and file become .conf.example again and stop working.

I have to rename again!

He's making a subtle suggestion to switch to the latest OWASP CRS:
https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-owasp-crs-ruleset-to-4-27-0-running-cwp-and-apache-on-almalinux-9/
https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-modsecurity-to-2-9-14-running-cwp-and-apache-on-almalinux-8-9/
Then you don't have to keep looking over your shoulder (but do keep updating the rulesets from time to time).

Hi Starburst

The panel just update rules automatically.
Happens to m, now, the OWASPrules are updated and file become .conf.example again and stop working.

I have to rename again!

Actually, No, it doesn't updated automatically. Even thought that's what it says in the panel.

I would verify the effective ModSecurity configuration rather than relying on what the CWP UI reports.

First confirm which ruleset Apache is actually loading, whether the active include points to the .conf file rather than .conf.example, and whether ModSecurity is running in blocking mode rather than detection-only mode. Then send a harmless request that should trigger a known CRS rule and confirm the event appears in the ModSecurity audit log.

That separates three different problems: the rules aren't being loaded, they're loaded but only detecting, or CWP is changing the configuration during an update/rebuild.

I'd also record the file timestamps before and after a CWP update/rebuild. If the working configuration is being replaced automatically, that gives you a much clearer point to investigate than repeatedly renaming the file.

I develop CWP7 Resource Shield, which is designed around this broader problem of coordinating CWP traffic protection instead of relying on a single defensive layer. It can combine traffic-pattern analysis with Cloudflare and optional CSF workflows. I'm mentioning it because this is directly related to the problem it was built for; I'd still verify the active ModSecurity configuration first before adding another layer.