New in CWP Edge-LatestFree with every CWPpro licenceWebsites up to 300x faster

CWP now includes LSPHP, LSCache and CWP CageFS at no extra cost with all CWPpro licences. The LSCache plugin is integrated into our WordPress and other script installers, and CWP CageFS gives every user complete isolation. Available now in the CWP Edge-Latest version.

Get CWPpro ›

Mod Security

Started by muscator, November 13, 2026, 06:37:22 AM

Previous topic - Next topic

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

#1
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!"