Mod Security

[muscator]

After upgrade to 1.30.9 the nightly run suddenly produced ModSec error saying "mod sec is not enabled" although I had it running withoutproblems on owasp for years

After inspecting the panel it says:

"OWASP rules are only logging, not blocking. The installed OWASP Core Rule Set was set up without its anomaly-scoring initialization (REQUEST-901), so matching requests are written to the audit log but never denied, even with SecRuleEngine On. Enabling blocking may stop requests that sites currently rely on - review the ModSecurity logs afterwards and add per-domain rule exceptions where needed."

Disabling Owasp then enabling Comodo, the disabling Comodo and reenabling Owasp removed the warning

But there seems to be an error in the new version 1.30.9 that produces the error as the exact same error happende simultanously on several servers

Further more the nightly cron run produeces this error on several servers:

######################
Update Server Packages
######################
Redirecting to /bin/systemctl reload httpd.service
Job for httpd.service failed.
See "systemctl status httpd.service" and "journalctl -xeu httpd.service" for details.
grep: /usr/local/cwpsrv/logs/error_log: binary file matches
Redirecting to /bin/systemctl reload httpd.service
Job for httpd.service failed.
See "systemctl status httpd.service" and "journalctl -xeu httpd.service" for details.
Redirecting to /bin/systemctl reload httpd.service
Job for httpd.service failed.
See "systemctl status httpd.service" and "journalctl -xeu httpd.service" for details.

Also never happened before

[muscator]

Update:

apparently it is the Owasp rules that breaks apache, as it stops httpd when enabling Owasp, while the old Comodo rules runs without problems but not to much avail as they are way too old - the old standard Owasp rules runs without breaking httpd as well

Running logcheck, the following error description occurs:

Nov 13 07:45:03 ddd.ddd.net apachectl[1875213]: AH00526: Syntax error on line 43 of /usr/local/apache/modsecurity-owasp-latest/rules/REQUEST-922-MULTIPART-ATTACK.conf:
Nov 13 07:45:03 ddd.ddd.net apachectl[1875213]: Error creating rule: Unknown variable: &MULTIPART_PART_HEADERS
Nov 13 07:45:03 ddd.ddd.net systemd[1]: httpd.service: Control process exited, code=exited, status=1/FAILURE

Checking Owasp rule mentioned, it seems that the culprit has been found:

 This file is to address the 3UWMWA6W vulnerability.
# It requires ModSecurity version 2.9.6 or 3.0.8 (or an updated version with backports
# of the security fixes in these versions) or a compatible engine supporting these changes.
#
# If you cannot upgrade ModSecurity, this file will cause ModSecurity to fail to start.
# In that case, you can temporarily delete this file. However, you will be missing
# protection from these rules. Therefore, we recommend upgrading your engine instead.

# The rules in this file will be part of the 920 / 921 in the future.

CWP runs Mod Security 2.9.1:
> grep -i "ModSecurity for Apache" /usr/local/apache/logs/error_log | tail -n 5

[Fri Nov 13 07:27:04.074769 2026] [:notice] [pid 1865501:tid 1865501] ModSecurity for Apache/2.9.1 (http://www.modsecurity.org/) configured

Apparently ModSec 2.9.1 does not support the new OWASP 3.x/4.x rules and therefore needs to be updated

Will that be a part of the next update of CWP or do we need to try and update Mod Sec ourselves?

Went along and used Starbursts upgrade instructions:

https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-modsecurity-to-2-9-15-running-cwp-and-apache-on-almalinux-8-9/

It solved the issue

[muscator]

Having checked a bit more, the described method actually produces a pcre warning in modsec logs - it seems that this is not a fatal error and that removal of the warning needs recompilation of modsec again:

"[security2:warn] [pid 238454:tid 238454] ModSecurity: Loaded PCRE do not match with compiled!"

[6Sense]

I switched to latest rules via modsec UI (CWP 1.30.12) and it ran OWASP 3.x which is not desireable so I had to revert.

I think most of us now are all running OWASP 4.x using @starburst work around due to modsec rules being outdated for so long to remain secure.

[muscator]

I switched to latest rules via modsec UI (CWP 1.30.12) and it ran OWASP 3.x which is not desireable so I had to revert.

I think most of us now are all running OWASP 4.x using @starburst work around due to modsec rules being outdated for so long to remain secure.

I agree - therefore it also seems a little confusing, that in cwp->mod security it states "Latest - with automatic updates" when in fact both mod sec and the dataset is if not obsolete, then rather old

In the newest versions CWP states that all applications etc always - from now on - will contain newest versions of anything present as application in cwp

Owasp 3.x rules are indeed obsolete as per Q326:


CRS 3.3.0   July 1, 2020   6 years, 4 months old   End-of-Life (Q3 2026)

So


I see in Edge 2.x that modsec at least is on newer version than earlier, but as you mention it seems as the rules still are version 3.x instead of 4.x

Hopefully this will be corrected soon in order to live up to the label stating that it uses 'latest version'

Funny to see that the Comodo version also states 'latest version' - this is not incorrect, as the last version was "1.240" in 2024....  but maybe a false security to urge newbies to use the Comodo version with 'latest' rules from 2024 and that is not good for anyone....

Furthermore CWP writes that in the Edge version, modsec is updated to use 2.9.8, which is also obsolete and indeed not the latest version:

• Release Milestone. Version 2.9.8 was the first major maintenance update after the project was officially transferred from Trustwave to OWASP in 2024.
• Current Status. It is outdated and missing several critical security patches. Since September 2024, the OWASP ModSecurity team has released multiple patches to fix Denial of Service (DoS) and memory vulnerabilities, bringing the current v2 branch up to v2.9.15