ModSecurity-nginx VS coreruleset

ModSecurity v3 has also introduced major changes in how ModSecurity works. The entire WAF is not packed together anymore. Instead, the single libmodsecurity engine is paired with a connector module that interfaces the application with the server. Different connectors are available based on the server and are hosted as independent packages. This means that there's a separate ModSecurity v3 Nginx Connector project.

As far as I can tell there is a feature request and/or some custom method to pass variables from modsecurity back to nginx but I'm looking for the other way around

I'm currently erring toward ModSecurity & the Nginx connector now that it's been de-Apache'd.

ModSecurity Connector: https://github.com/SpiderLabs/ModSecurity-nginx

--OWASP® ModSecurity Core Rule Set website

The other thing that came to my mind is the OWASP ModSecurity Core Rule Set (https://coreruleset.org/), which seems somewhat analogous to your proposal. If so, it might be worth chatting with some of the CRS maintainers about what their journey was.

I would say it depends on your version. The core rule set git repo shows REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf being in versions 3.0.2 through 3.3.4.

If your focus is on generic detection rules than a good resource to start with is the OWASP ModSecurity Core Rule Set (CRS) - However, this rule set is built for the mod_security WAF but depending on what data you get in from your customers, you might be able to forward it against your own mod_security instance and process the mod_security audit logs in Splunk without having to re-write/convert the rules.

I'm always getting great and helpful support from the CRS issue tracker: https://github.com/coreruleset/coreruleset/issues

Host-based firewalls and network firewalls won't always quite "cut it", OWASP ModSecurity is an open-source rule set for critical web applications that require an additional level of security.

Other than that we rely on quite a lot of things these days, notably ModSecurity and the OWASP Core Rule Set alongside some other heavy restricting of our apps. (the idea being that the app is safe on its own, but those act as extra layers of defense in case we fuck up something really badly in the app one day)

sudo git clone https://github.com/coreruleset/coreruleset /usr/share/modsecurity-crs

It's quite hard, because it's not just "use known vulnerabilities on this specific address" - you can block it easily, and there are projects (such as CRS: https://github.com/coreruleset/coreruleset) that tries to emulate this. It's more of combined specific attacks, which is amplified because if CloudFlare detected an attempt on a single high-profile site, then that IP address can be propagate to all of the protected properties. Combine that with how random is an address allocated in Tor, and you've got blocks without using an explicit Tor list.