Plugin Ignores rules in REQUEST-900(?)

[StasABerg]

Hey, I seem to have an issue where the plugin seems to ignore IP addresses that I add to actl:ruleEngine=off rule

SecRule REMOTE_ADDR "@ipMatch co.oo.l.ip,127.0.0.1, etc" \
     "id:1000100,\
     phase:1,\
     pass,\
     nolog,\
     ctl:ruleEngine=Off"

tried adding also

      ctl:ruleRemoveById=0-999999999"

but still seems to ignore the IP addreses I wish enable full access to.

Im using the nginx+modsecurity docker container which comes with modsecurity v3 + crsv4 which i guess could be the issue? But still why would it ignore the rule mentioned above?

Any recommendations?

[RedXanadu]

Hi @StasABerg,

Firstly, I always strongly recommend against attempting to implement any sort of anti-DoS logic in ModSecurity. It is simply not a good place to implement such logic/protection. (See the README page for more detailed info and lots of alternative recommendations/solutions.)

Secondly, as described in the "Compatibility" section of the README, this plugin is only compatible with ModSecurity v2. This is because the v3 engine is missing key functionality to make the DoS protection logic work. Using this plugin with the ModSecurity v3 Docker image will almost certainly not work.

There was an attempt to write a workaround for the missing feature in ModSecurity v3, but I don't think that was ever completed.

I'm marking this issue as closed, but please do reply if you have any further questions or re-open if you think there's more to do here (e.g. if you install ModSecurity v2 and still have issues with this ‘v2 plugin’ then please let us know.)

[RedXanadu]

(@StasABerg And, of course, you can always try the ModSec v2 container! I'd always take v2 over v3, any day :wink:)

[StasABerg]

(@StasABerg And, of course, you can always try the ModSec v2 container! I'd always take v2 over v3, any day 😉)

What would be the differences between v2 and v3? Why v2 is better? Is there a nginx + v2 container somewhere?

[RedXanadu]

What would be the differences between v2 and v3? Why v2 is better? Is there a nginx + v2 container somewhere?

@StasABerg So, ModSecurity v2 and ModSecurity v3 are both still active and maintained projects. (In fact, they both recently joined the OWASP umbrella (January 2024), which is very exciting and should ensure the long-term future of ModSecurity.)

In reality, you have two choices:

• ModSecurity v2 + Apache
• ModSecurity v3 + Nginx

They both work well. CRS offers official Docker container images for each of those two combinations.

(There is also the very new Coraza engine, but that is not compatible with either Apache or Nginx.)

ModSecurity v2 + Nginx is not officially supported. ModSecurity v3 + Apache is technically possible, but is definitely not production ready. (There might be fresh work to change this in the near future!)

The ModSecurity v3 engine was a rewrite in C++, and you could say it was never fully finished… There are many ‘implementation gaps’ and ‘quirks’ with v3. Some things were never implemented, some things were implemented oddly, there are undocumented changes in behaviour from v2 to v3 (some are still being discovered!), and more.

ModSecurity v2 + Apache is the reference implementation / reference platform for CRS. ModSecurity (2.9.x) passes 100% of the CRS unit tests on Apache. v2 is considered to be stable and a ‘known quantity’. It's been around for a very long time and is used in many, many deployments. No other platform ticks all of those boxes. v3 + Nginx is also widely used, but you have to live with the ‘quirks’ of the engine.

It probably depends a lot on your use case, too. If this is for a personal website, for example, then it probably doesn't matter much if you go v2 or v3. If this is for a large estate of WAFs then you might need to think more carefully about which way you go and why.

We have a full write-up about the state of different engine options here: https://coreruleset.org/docs/deployment/engine_integration_options/

I hope this helps! :slightly_smiling_face: