Extend ModSecurity CRS coverage

[0xbbuddha]

Summary

This PR improves ModSecurity CRS integration by introducing multiple dedicated scenarios for different attack types. Previously, only a single generic scenario existed, making it harder to distinguish between SQLi, XSS, brute force, and other patterns.

Changes introduced:

• Added separate scenarios for different categories of attacks.
• Improved visibility and granularity in detection.
• Updated the CrowdSec ModSecurity collection accordingly.
• Scenarios have been implemented in line with the latest ModSecurity CRS ruleset (v4.17.1).
• WordPress and Nextcloud ModSecurity rules have been implemented in accordance with ModSecurity CRS ruleset (v3.3.4).

Why

By splitting the detection logic into multiple scenarios, we gain better insights into the nature of incoming attacks. This allows for clearer alerts, more accurate remediation, and enhanced observability.

[buixor]

Nice one, give us a bit of time to have a proper look.

thx :)

[0xbbuddha]

no problem

[LaurenceJJones]

Just adding a small note, we should have a look at supporting Coraza caddy logs with the same scenarios as we have access to the same data points.

I believe at the moment there a seperate scenario for caddy coraza which only checks for the scoring ID.

[0xbbuddha]

Do you want me to find out?

[0xbbuddha]

I just looked at the scenario for the Coraza-Caddy collection. It is based on this rule. Would you like me to apply it to this collection? I can also create even more specific scenarios if needed. But by default, we only want to trigger an alert if the level is 'CRITICAL'.

SecRule TX:BLOCKING_INBOUND_ANOMALY_SCORE "@ge %{tx.inbound_anomaly_score_threshold}" \
    "id:949110,\
    phase:2,\
    deny,\
    t:none,\
    msg:'Inbound Anomaly Score Exceeded (Total Score: %{TX.BLOCKING_INBOUND_ANOMALY_SCORE})',\
    tag:'anomaly-evaluation',\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.18.0-dev'"

[0xbbuddha]

I'm going to readjust some rules.