Facebook
Twitter
Azurel
Silver Pleskian
- Server operating system version
- AlmaLinux 9.8
- Plesk version and microupdate number
- 18.0.80#5
Hi, after upgrading this server from AlmaLinux8to9, I noticed that ModSecurity no longer appears to be working correctly.
In the Plesk GUI under Tools & Settings → Web Application Firewall (ModSecurity), ModSecurity is shown as On.
The Plesk configuration also confirms this:
However, the actual ModSecurity status says:
Apache also does not seem to have the ModSecurity module loaded:
There is no active LoadModule directive for ModSecurity:
The installed module itself exists and the RPM verifies successfully:
/etc/httpd/conf.d/security2.conf exists, but contains a comment:
One additional observation: /usr/lib64/httpd/modules/mod_security2.so has a different modification timestamp than most other Apache modules on this server.
The main symptom is that:
/var/log/modsec_audit.log no longer receives any ModSecurity events and currently remains at 0 bytes.
The Fail2Ban plesk-modsecurity jail is enabled and correctly monitors this file, but naturally receives no events:
Before the OS upgrade, modsec_audit.log was populated daily. I receive this file automatically by email every day, so I can confirm that it was still receiving new data before upgrade to AlmaLinux 9. After the upgrade/reboot into AlmaLinux 9 no new ModSecurity audit entries appeared.
So the current situation seems to be:
What is the recommended way to diagnose and fix this inconsistency?
Should I simply toggle ModSecurity Off → On in the Plesk GUI to force Plesk to re-enable the Apache security2 module, or should I check/repair something else first?
I would especially like to understand why Plesk reports the WAF as enabled while modsecurity_ctl --status reports Disabled, and how to restore ModSecurity correctly so that /var/log/modsec_audit.log receives events again.
In the Plesk GUI under Tools & Settings → Web Application Firewall (ModSecurity), ModSecurity is shown as On.
The Plesk configuration also confirms this:
Code:
# plesk bin server_pref --show-web-app-firewall
[waf-rule-engine]
on
[waf-web-server]
apache
[waf-rule-set]
comodo_free
[waf-config-preset]
fastHowever, the actual ModSecurity status says:
Code:
# plesk sbin modsecurity_ctl --status
DisabledApache also does not seem to have the ModSecurity module loaded:
Code:
# httpd -M 2>&1 | grep -Ei 'security|unique_id'
unique_id_module (shared)There is no active LoadModule directive for ModSecurity:
Code:
# grep -RniE '^[[:space:]]*LoadModule[[:space:]].*security' /etc/httpd
<no output>The installed module itself exists and the RPM verifies successfully:
Code:
# rpm -q mod_security
mod_security-2.9.14-2.redhat.9+p18.0.80.0+t260729.1206.x86_64/etc/httpd/conf.d/security2.conf exists, but contains a comment:
Code:
#LoadModule security2_module modules/mod_security2.soOne additional observation: /usr/lib64/httpd/modules/mod_security2.so has a different modification timestamp than most other Apache modules on this server.
The main symptom is that:
/var/log/modsec_audit.log no longer receives any ModSecurity events and currently remains at 0 bytes.
The Fail2Ban plesk-modsecurity jail is enabled and correctly monitors this file, but naturally receives no events:
Code:
# fail2ban-client status plesk-modsecurity
Currently failed: 0
Total failed: 0
File list: /var/log/modsec_audit.logBefore the OS upgrade, modsec_audit.log was populated daily. I receive this file automatically by email every day, so I can confirm that it was still receiving new data before upgrade to AlmaLinux 9. After the upgrade/reboot into AlmaLinux 9 no new ModSecurity audit entries appeared.
So the current situation seems to be:
What is the recommended way to diagnose and fix this inconsistency?
Should I simply toggle ModSecurity Off → On in the Plesk GUI to force Plesk to re-enable the Apache security2 module, or should I check/repair something else first?
I would especially like to understand why Plesk reports the WAF as enabled while modsecurity_ctl --status reports Disabled, and how to restore ModSecurity correctly so that /var/log/modsec_audit.log receives events again.
