Guide CyberPanel ModSecurity + OWASP Rules: It Said Enabled, but Blocked Nothing

Guide CyberPanel ModSecurity + OWASP Rules: It Said Enabled, but Blocked Nothing - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: CyberPanel (https://adminsforum.com/Forum-cyberpanel)
+---- Forum: CyberPanel Guides & Tutorials (https://adminsforum.com/Forum-cyberpanel-guides-tutorials)
+----- Forum: CyberPanel Getting Started Guides (https://adminsforum.com/Forum-cyberpanel-getting-started-guides)
+----- Thread: Guide CyberPanel ModSecurity + OWASP Rules: It Said Enabled, but Blocked Nothing (/Thread-guide-cyberpanel-modsecurity-owasp-rules-it-said-enabled-but-blocked-nothing)

CyberPanel ModSecurity + OWASP Rules: It Said Enabled, but Blocked Nothing - JAY - 10-26-2026

CyberPanel ModSecurity + OWASP Rules: It Said Enabled, but Blocked Nothing

CyberPanel 3.0 has a one-click ModSecurity web application firewall (WAF) with the OWASP Core Rule Set. On our test server both switches turned green, the panel said "Operation successful", and SQL injection, XSS and path traversal requests still went straight through to WordPress. The module wasn't even loading. Here is how to test your WAF properly, what was broken, and the fix that made it block attacks.

If you came here looking for CSF: CyberPanel 3.0 doesn't offer it any more. The old

Code:

/firewall/csf

page returned "Not Found" on our server, and the Security menu only lists the built-in Firewall, ModSecurity and the Imunify add-ons. See the CyberPanel firewall guide for ports and rules.

Step 1: Test before you change anything
A WAF you haven't tested is a guess. We used a tiny shell function that prints the HTTP status for a request against our WordPress site:

Code:

W=https://yourdomain.com
T(){ curl -s -o /dev/null -w "$1 %{http_code}\n" "$W/?$2"; }
T sqli 'id=1%27%20OR%201=1--'
T lfi 'f=../../../../etc/passwd'
T xss 'q=%3Cscript%3Ealert(1)%3C/script%3E'

These are harmless test strings; WordPress ignores them. Without a WAF, all three come back 200:

Code:

sqli 200
lfi 200
xss 200

Use a new parameter name or value for each test run (we used

Code:

id

, then

Code:

uid

Code:

k

Code:

r

...). LiteSpeed Cache can store the first answer for a URL and serve it again later, which hides whether the WAF changed anything.

Step 2: Install ModSecurity in the panel
Open Security > ModSecurity (

Code:

https://YOUR-SERVER-IP:8090/firewall/modSecurity

Click Install ModSecurity. After a few seconds the configuration page appeared with the engine, audit log and rule engine all switched on:
[Image: attachment.php?aid=523]

Step 3: Turn on the OWASP rules
Open Security > Rule Packs (

Code:

/firewall/modSecRulesPacks

) and switch on OWASP ModSecurity Core Rules. Our panel showed only this one pack and answered "Operation successful". It downloaded the rules to

Code:

/usr/local/lsws/conf/modsec/owasp-modsecurity-crs-3.0-master/

and added them to the OpenLiteSpeed config. Note the version: CRS 3.0, a very old release of the rule set.

Then we ran the tests again. Still 200, 200, 200. Nothing was blocked.

Step 4: Check whether the module actually loads
The panel can't tell you this. The web server's error log can:

Code:

grep -i 'mod_security' /usr/local/lsws/logs/error.log | tail -3

Code:

Failed to load module [mod_security], error: libyajl.so.2: cannot open shared object file: No such file or directory

OpenLiteSpeed started without ModSecurity, quietly, while the panel showed it as enabled. A missing library, so we installed it:

Code:

apt-get install -y libyajl2
systemctl restart lsws

The next error:

Code:

Failed to load module [mod_security], error: /usr/local/lsws/modules/mod_security.so: undefined symbol: pcre_free

This one isn't a missing package (

Code:

libpcre3

was installed). The

Code:

mod_security.so

that CyberPanel had put in place (57 MB, dated November 2025) didn't fit this system. Next to it, CyberPanel had kept the module that came with OpenLiteSpeed as

Code:

mod_security.so.backup.<number>

(83 MB). We kept a copy of CyberPanel's file and put the original back:

Code:

cd /usr/local/lsws/modules
ls -l mod_security.so*
cp mod_security.so /root/mod_security.so.cyberpanel
cp mod_security.so.backup.* mod_security.so
systemctl restart lsws
grep -i 'mod_security' /usr/local/lsws/logs/error.log | tail -2

(If you have more than one backup file, copy the right one by its full name instead of using

Code:

*

.) This time the log said

Code:

[Module: mod_security mod_security 1.4] has been initialized successfully

.

Step 5: Test again
With new parameter names, so no cached answers:
[Image: attachment.php?aid=538]

Home page and a normal WordPress search (
Code:
?s=hello+world
): 200.
Path traversal, SQL injection, XSS: 403.

The audit log shows which rules fired:

Code:

grep -o 'id "[0-9]*"' /usr/local/lsws/logs/auditmodsec.log | sort | uniq -c | sort -rn

Rule

Code:

949110

is the OWASP "anomaly score exceeded" rule that does the actual blocking;

Code:

942100

is SQL injection, the

Code:

941xxx

rules are XSS, and

Code:

99999

is a small "Drive Access" rule (

Code:

../

) that CyberPanel adds itself in

Code:

/usr/local/lsws/conf/modsec/rules.conf

. Rules

Code:

920440

and

Code:

930130

(restricted file types and paths) came from bots on the internet probing for files like

Code:

/.svn/wc.db

Code:

/.ssh/id_rsa

Code:

/backup.sql

and

Code:

/wp-config.php

within a few hours of the WAF going live, which is the WAF doing its job.

Before you leave it on

False positives. OWASP rules sometimes block normal things: saving a post with code in it, page builders, some plugin forms. Test your admin area and forms. When something legit gets a 403, find its rule ID in
Code:
auditmodsec.log
and disable just that rule for your site, rather than turning the WAF off.
The rule set is old. CRS 3.0 from the panel is years behind the current release. It still blocked our tests, but newer CRS versions catch more and cause fewer false positives.
Updates can undo the fix. A CyberPanel update may put its own
Code:
mod_security.so
back. After every update run the
Code:
grep
from Step 4 and one test from Step 1.
Logs grow.
Code:
auditmodsec.log
records every blocked request. Bots will fill it. Keep an eye on its size.

Quick check after any change

Code:

grep -i 'mod_security' /usr/local/lsws/logs/error.log | tail -1
T test$RANDOM 'x=../../../../etc/passwd'

If the first line says "initialized successfully" and the second prints 403, your WAF works.

More CyberPanel guides

Tested on CyberPanel 3.0 (build 8, OpenLiteSpeed edition) on Ubuntu 24.04, October 2026. Menu names can change slightly between versions.