Since you never got a a response, I will chime in as I am having the same issue. First I will post the errors received, then all my server information as well as what I have tried.
If I run in concurrent, every time a rule is triggered by a user's site, mode I receive the following errors:
My original config (before testing other options)
I am just using the "Default Configuration" that comes with it the base install; no custom rules, no imported rules, nothing. I I have tried the following and am now at a complete loss on what to do next.
I am completely out of ideas and at the point where I believe my only options are to remove either modsecurity or mod_ruid2.
If I run in concurrent, every time a rule is triggered by a user's site, mode I receive the following errors:
If I run in serial mode, every time a rule is triggered by a user's site, I receive the following errors whenev:
Server Information
Code:
CentOS release 6.5 (Final)
WHM 11.44.1 (build 17)
Apache/2.2.27 (Unix)
PHP/5.4.32 configured
mod_ruid2/0.9.8 enabled
ModSecurity for Apache/2.8.0
ModSecurity: APR compiled version="1.5.1"; loaded version="1.5.1"
ModSecurity: PCRE compiled version="8.35 "; loaded version="8.35 2014-04-04"
ModSecurity: LUA compiled version="Lua 5.1"
ModSecurity: LIBXML compiled version="2.9.1.20140611"
Status engine is currently disabled, enable it by set SecStatusEngine to On.
Code:
LoadFile /opt/xml2/lib/libxml2.so
# LoadFile /opt/lua/lib/liblua.so
LoadModule security2_module modules/mod_security2.so
<IfModule mod_security2.c>
SecRuleEngine On
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf
# "Add the rules that will do exactly the same as the directives"
# SecFilterCheckURLEncoding On
# SecFilterForceByteRange 0 255
SecAuditEngine RelevantOnly
<IfModule mod_ruid2.c>
SecAuditLogStorageDir /usr/local/apache/logs/modsec_audit
SecAuditLogType Concurrent
</IfModule>
<IfModule itk.c>
SecAuditLogStorageDir /usr/local/apache/logs/modsec_audit
SecAuditLogType Concurrent
</IfModule>
SecAuditLog logs/modsec_audit.log
SecDebugLog logs/modsec_debug_log
SecDebugLogLevel 0
SecDefaultAction "phase:2,deny,log,status:406"
SecRule MULTIPART_STRICT_ERROR "[email protected] 0" "phase:2,t:none,log,deny,status:44,msg:'Multipart request body failed strict validation: PE %{REQBODY_PROCESSOR_ERROR}, BQ %{MULTIPART_BOUNDARY_QUOTED}, BW %{MULTIPART_BOUNDARY_WHITESPACE}, DB %{MULTIPART_DATA_BEFORE}, DA %{MULTIPART_DATA_AFTER}, HF %{MULTIPART_HEADER_FOLDING}, LF %{MULTIPART_LF_LINE}, SM %{MULTIPART_MISSING_SEMICOLON}, IQ %{MULTIPART_INVALID_QUOTING}, IP %{MULTIPART_INVALID_PART}, IH %{MULTIPART_INVALID_HEADER_FOLDING}, FL %{MULTIPART_FILE_LIMIT_EXCEEDED}',id:1234123456"
SecRule REMOTE_ADDR "^127.0.0.1$" nolog,allow,id:1234123455
Include "/usr/local/apache/conf/modsec2.cpanel.conf"
Include "/usr/local/apache/conf/modsec2.user.conf"
</IfModule>- recompiled Apache
- ran upcp --force
- changed the permissions on the '/usr/local/apache/logs/modsec_audit' directory to 777
- changed the permissions on the '/usr/local/apache/logs/modsec_audit.log' file to 777
- made apache the owner of the '/usr/local/apache/logs/modsec_audit' directory
- made apache the owner of the '/usr/local/apache/logs/modsec_audit.log' file
- changed the permissions on the '/usr/local/apache/logs/modsec_audit' directory to 6777 with apache as owner
- changed the permissions on the '/usr/local/apache/logs/modsec_audit.log' file to 6777 with apache as owner
- moved the 'modesec_audit' directory to '/' which, changes the (Read-only file system) portion of the above error above to (Permission Denied)
- I have added 'SecAuditLogDirMode 0777' and 'SecAuditLogFileMode 0550' to the modsec2.conf
I am completely out of ideas and at the point where I believe my only options are to remove either modsecurity or mod_ruid2.
TomboAhi,
Do you have "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell" enabled under the "Security" tab in "WHM >> Tweak Settings"?
Thank you.
Do you have "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell" enabled under the "Security" tab in "WHM >> Tweak Settings"?
Thank you.
Here is a summary of internal case number 110129, which is open to address an issue with this option:
Internal case number 110129 is open to address an issue when enabling "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell." results in "/usr" mounted as readonly, causing mod_security logging to fail. Because the logging fails, modsecparse.pl can not parse the logs so it can not populate the database that the mod_security plugin uses.
The temporary workaround is to disable this option until a resolution for this case has been released.
Thank you.
That is the problem that I'm interested.
Thanks Michael, it's nice to hear from the cPanel team about issues like this before jumping in.
I'll give it a go and see what happens.
Thanks Michael, it's nice to hear from the cPanel team about issues like this before jumping in.
I'll give it a go and see what happens.
Michael,
Wouldn't it be an idea to put the modsec_audit under the users home folder in virtfs. I don't play with things like this too often but something like this in the vhost templates would work somehow wouldn't it? If Ruid2 and the Jail then define the modsec_audit under /home/virtfs/$user Then it would be in the jailed area and writing as the user.
PHP:
<IfModule mod_ruid2.c>
RMode config
RUidGid [% vhost.user %] [% vhost.group %]
[% IF jailapache && vhost.jailed -%]
RDocumentChRoot /home/virtfs/[% vhost.user %] [% vhost.documentroot %]
[% END -%]
</IfModule>
[% IF jailapache && vhost.jailed -%]
<IfModule mod_security.c>
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4\d[^4])"
SecAuditLogType Concurrent
SecAuditLog /usr/local/apache/logs/modsec_audit.log
SecAuditLogStorageDir /home/virtfs/[% vhost.user %]/modsec_audit
SecAuditLogDirMode 0700
SecAuditLogFileMode 0600
</IfModule>
[% END -%]Also can anybody think of a security issue as to why customers shouldn't have access to their own audits? At least that way they can see for themselves and would believe us when we say their Wordpress isn't coming up because the server is protecting them from bad code in the Wordpress application. LOL All mod_security folks have been there.
Wil
Correction the path if I am able to get it functioning would be
SecAuditLogStorageDir /home/virtfs/[% vhost.user %]/home/[% vhost.user %]/modsec_audit
SecAuditLogStorageDir /home/virtfs/[% vhost.user %]/home/[% vhost.user %]/modsec_audit
I think it would be a pretty good idea [to give each user their own audit log]. The only potential security issues I can think of off the top of my head are pretty edge cases IMO, for example if a POST payload is caught containing valid admin session data, a PHP shell with access to the audit log could pull that session data. This requires a lot of unlikely conditions though.
I feel that the risk involved does not out-weigh the benefit of individual audit logs with ruid2, since the site would have to effectively be compromised already anyway for an attacker to gain audit log data.
I feel that the risk involved does not out-weigh the benefit of individual audit logs with ruid2, since the site would have to effectively be compromised already anyway for an attacker to gain audit log data.
To solve the problem Audit log: Failed to lock global mutex: Permission denied
Using mod_ruid2 and mod_security together:
find the configuration file which loads finally in mod security (example: /usr/local/apache/conf/modsec2.cpanel.conf)
Add these line to the end of file:
Check the directory of /usr/local/apache/logs/modsec_audit for proper permissions of : 1733
This solved my problem
Regards
Farhad Sakhaei
Using mod_ruid2 and mod_security together:
find the configuration file which loads finally in mod security (example: /usr/local/apache/conf/modsec2.cpanel.conf)
Add these line to the end of file:
Code:
SecAuditLogDirMode 1733
SecAuditLogFileMode 0550
SecAuditLogType Concurrent
SecAuditLogStorageDir /usr/local/apache/logs/modsec_auditThis solved my problem
Regards
Farhad Sakhaei
There's currently no update to this specific case. However, I don't believe the issue should persist with EasyApache 4 due to the log location change:
Introduction to EasyApache 4 - EasyApache 4 - cPanel Documentation
Thank you.
