Easyapache 4 + Modsecurity + Mod_ruid2 errors
Hi,
OS: CentOS Linux release 7.3.1611 (Core)
WHM/cPanel: WHM 62.0 (build 8)
Server MPM: prefork
PHP-FPM: Yes (php-fpm: master process (/opt/cpanel/ea-php70/root/etc/php-fpm.conf) / php-fpm: master process (/usr/local/cpanel/etc/php-fpm.conf)
Installed packages via WHM: Yes
Conflict Modsecurity + mod_ruid2 is solved or not in WHM 62.0 (build 8) / Easyapache4?
Apache error log(OWASP ModSecurity Core Rule Set):
tail -f /usr/local/apache/logs/error_log
1. Solution to work Modsecurity with mod_ruid2 on EA4(WHM 62.0 (build 8)? 2. Jail Apache Virtual Hosts using mod_ruid2 and cPanel" jailshell is still EXPERIMENTAL in 2017? 3. Why COMODO Mod Security Rules not compatible with Easyapache4?(Vendor added via: waf.comodo.com/doc/meta_comodo_apache.yaml)
[Wed Feb 08 07:19:47.368806 2017] [:error] [pid 18362] [client 88.xx.xxx.xxx] ModSecurity: Geo Lookup: Failed to lock proc mutex: Permission denied [hostname "www.example.com"> [uri "/wp-cron.php"> [unique_id "WJq4gxoNZ0NsrRs3VcpdbQAAAAo">
[Wed Feb 08 07:19:47.614697 2017] [:error] [pid 18362] [client 88.xx.xxx.xxx] ModSecurity: collection_store: Failed to access DBM file "/var/cpanel/secdatadir/ip": Permission denied [hostname "www.example.com"> [uri "/wp-cron.php"> [unique_id "WJq4gxoNZ0NsrRs3VcpdbQAAAAo">
[Wed Feb 08 07:19:47.614782 2017] [:error] [pid 18362] [client 88.xx.xxx.xxx] ModSecurity: Audit log: Failed to create subdirectories: /etc/apache2/logs/modsec_audit/marius/20170208/20170208-0719 (Permission denied) [hostname "www.example.com"> [uri "/wp-cron.php"> [unique_id "WJq4gxoNZ0NsrRs3VcpdbQAAAAo">
[Wed Feb 08 07:20:01.778308 2017] [:error] [pid 18360] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"> [line "317"> [id "960009"> [rev "1"> [msg "Request Missing a User Agent Header"> [severity "NOTICE"> [ver "OWASP_CRS/3.0.0"> [maturity "9"> [accuracy "9"> [tag "Host: "> [tag "application-multi"> [tag "language-multi"> [tag "platform-multi"> [tag "attack-protocol"> [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA"> [tag "WASCTC/WASC-21"> [tag "OWASP_TOP_10/A7"> [tag "PCI/6.5.10"> [hostname "server.example.com"> [uri "/whm-server-status"> [unique_id "WJq4kanq5WrIr4YLH5L2BgAAAAg">1. Solution to work Modsecurity with mod_ruid2 on EA4(WHM 62.0 (build 8)? 2. Jail Apache Virtual Hosts using mod_ruid2 and cPanel" jailshell is still EXPERIMENTAL in 2017? 3. Why COMODO Mod Security Rules not compatible with Easyapache4?(Vendor added via: waf.comodo.com/doc/meta_comodo_apache.yaml)
-
Hello, Under Mod_Ruid2/MPM-ITK, the Apache process is run as the cPanel user, and therefore does not have access to obtain a lock on the GeoIP database. This is documented at: Apache Module: ModSecurity - EasyApache 4 - cPanel Documentation Additional discussion of this topic is found at: ModSecurity + MPM ITK compatibility - inconsistent documentation Thank you. 0 -
Hello, Under Mod_Ruid2/MPM-ITK, the Apache process is run as the cPanel user, and therefore does not have access to obtain a lock on the GeoIP database. This is documented at:
In my first post I've specified: Server MPM: prefork(cPanel default) - > So this apply to prefork too or only to MPM-ITK? Far as I know MPM prefork and MPM ITK are 2 different modules.0 -
In my first post I've specified: Server MPM: prefork(cPanel default) - > So this apply to prefork too or only to MPM-ITK? Far as I know MPM prefork and MPM ITK are 2 different modules.
Hello, This was a blanket statement to note the Apache process is run as the cPanel user when using either Mod_Ruid2 or MPM-ITK. In your case, the system uses Mod_Ruid2. Thanks!0 -
Ok, I understand that in my case the system uses Mod_Ruid2. But nobody from staff answer to my main question: Conflict Modsecurity + mod_ruid2 is solved or not in WHM?(I provided log & all the information's). Thanks! 0 -
But nobody from staff answer to my main question: Conflict Modsecurity + mod_ruid2 is solved or not in WHM?(I provided log & all the information's).
ModSecurity: Geo Lookup: Failed to lock proc mutex:
Hello, This issue will still occur when using Mod_Ruid2 and Mod_Security. The topic is discussed in more detail on the URL referenced in the earlier response: ModSecurity + MPM ITK compatibility - inconsistent documentation Note that the title references MPM ITK, but the same issue applies to Ruid2. Thank you.0 -
So what needs to be done to fix this? Does this new version fix it? OWASP has released version 3 of their Core Rule Set for ModSecurity". This new version of the ruleset provides enhanced protection for a number of attacks on web servers. To install the new set of rules or upgrade from the older version, go to Home " Security Center " ModSecurity" Vendors. 0 -
So what needs to be done to fix this? Does this new version fix it? OWASP has released version 3 of their Core Rule Set for ModSecurity". This new version of the ruleset provides enhanced protection for a number of attacks on web servers. To install the new set of rules or upgrade from the older version, go to Home " Security Center " ModSecurity" Vendors.
Hello @joako, The issue originates from a bug with Mod Security itself, however we recently have begun working on a solution to ensure Mod Security correctly logs ModSecEvents when using MPM-ITK or RUID2, so that persistent logging works properly. You can find the most recent update at: ModSecurity + MPM ITK compatibility - inconsistent documentation Thank you.0 -
We fixed this by manually editing /etc/apache2/conf.d/modsec/modsec2.cpanel.conf and adding the following line: SecDataDir "/var/log/secdatadir"
(or changing the existing /var/cpanel/secdatadir to that path) Afterwards run the following commands: $ sudo cp -R /var/cpanel/secdatadir /var/log/ $ sudo chmod 1733 /var/log/secdatadir $ sudo chown -R nobody:nobody /var/log/secdatadir $ sudo chmod ugo+rw /var/log/secdatadir/*
Then change any modsec setting in WHM under [ModSecurityTM Configuration] to trigger the regeneration of the config and you're all set. No more errors.0 -
We fixed this by manually editing /etc/apache2/conf.d/modsec/modsec2.cpanel.conf and adding the following line: (or changing the existing /var/cpanel/secdatadir to that path) Afterwards run the following commands: Then change any modsec setting in WHM under [ModSecurityTM Configuration] to trigger the regeneration of the config and you're all set. No more errors.
I tried this but as soon as I change the modsec settings in whm the config file reverts to the old path.0 -
I tried this but as soon as I change the modsec settings in whm the config file reverts to the old path.
You may find the following thread helpful: ModSecurity - SecDataDir Thank you.0
Please sign in to leave a comment.
Comments
10 comments