Mod RUID 2 and ModSecurity

[Solokron]

Has anyone made any headway into the logging issue which occurs when RUID is in place?

I have about 10% of the rules working properly. By properly, I mean they are detected AND logged properly which allows for ConfigServer Firewall to pick off the bad bots etc. This I suspect because it occurs before the PHP layer. What I do not have is brute force attacks to scripts such as WordPress and Joomla being blocked off because although picked up by ModSecuriy, it is unable to write to the log file because of RUIDs influence at the account level when PHP is involved and it's attempt to write back as the user.

 

[cPanelMichael]

Hello

There are scheduled resolutions for Mod_Security and Mod_Ruid2 incompatibilities in EasyApache version 3.24. Here is a quote from one of our EasyApache team members on another thread:

We were on the brink of releasing 3.24, but found some last minute issues with respect to updating, particularly for users that expected Apache 1.3 and 2.0 to be there.

Also, we've internally resolved the Mod Ruid2 and Mod Security incompatibility (Case 76493) for the 3.24 update. The fix you can look forward to involved a small code and configuration change.

The core of the incompatibility between these two modules is that Mod Security, by default, uses a file-based lock. This lock is needed because the default behavior of Mod Security, is to write all events into a single log file; /usr/local/apache/logs/modsec_audit.log. Since Mod Ruid2 changes the process ownership, this naturally causes complications when two different users try to acquire a lock on the same file they don't own.

Thank you.

 

[Solokron]

Thank you Michael!!

- - - Updated - - -

That is exactly what I thought was going on contrary to popular consensus! Great news!

 

[Solokron]

Hello Michael,

Any eta on that update? Thank you.

 

[cPanelMichael]

Hello Michael,

Any eta on that update? Thank you.

There are no additional updates at this time. You can monitor the EasyApache change log for version 3.24:

EasyApache Change Log

Thank you.

 

[Ebridge]

I'm a bit puzzled here... cPanelKurtN mentions that the mod_security incompatibility has case number 76493.

The changelog on EasyApache < AllDocumentation/ChangeLog < TWiki mentions case 76493 has been "implemented" in EasyApache 3.22.28

Does this mean that the compatibility issues has already (silently) been resolved in 3.22.28?

There are scheduled resolutions for Mod_Security and Mod_Ruid2 incompatibilities in EasyApache version 3.24. Here is a quote from one of our EasyApache team members on another thread:

We were on the brink of releasing 3.24, but found some last minute issues with respect to updating, particularly for users that expected Apache 1.3 and 2.0 to be there.

Also, we've internally resolved the Mod Ruid2 and Mod Security incompatibility (Case 76493) for the 3.24 update. The fix you can look forward to involved a small code and configuration change.

The core of the incompatibility between these two modules is that Mod Security, by default, uses a file-based lock. This lock is needed because the default behavior of Mod Security, is to write all events into a single log file; /usr/local/apache/logs/modsec_audit.log. Since Mod Ruid2 changes the process ownership, this naturally causes complications when two different users try to acquire a lock on the same file they don't own.

 

[KurtN.]

Thanks for incidentally spotting the incorrect case number in the ChangeLog. We will fix this. The case that SHOULD be here is, 85957.

We have not released this fix yet because we found some issues during QA testing.

 

[vicos]

I have a new server build with Easy::Apache v3.24.11 on

CENTOS 6.5 x86_64 standard – rs11
WHM 11.40.1 (build 11)
Apache 2.4 with Ruid2 and mod_security

Just discovered that mod_security is still throwing these errors:

Audit log: Failed to lock global mutex: Permission denied

Is this a show stopper? Do I need to rebuild and remove mod_security? We assumed this was fixed because EasyApache no longer disabled mod_security when selecting Ruid2

 

[KurtN.]

If you want to continue using Mod Ruid2, then you should remove Mod Security from your Apache installation.

It's documented in both the Mod Ruid2 and Mod Security documentation pages.

 

[coolice]

Anithing new here ...It's strage how wheel of history is spinning...

several years ago my site ot my server was defaced cause of dso and old version of wordpress and i stop using it now dso (ruid2) become the most secure option for cPanel and it's steel blazing fast... if somebody told me a year ago I'll never believe it

pls cpanel released this mod security fix soon need to beta test

 

[vicos]

Anything new here

It was promised for a long time that EasyApache 3.24 would resolve the Ruid2 / mod_security issue. Sure enough, I built a new server that came with 3.24 and EA no longer unselected mod_security when you chose Ruid2 as it had in previous versions; and the on screen warning messages were gone. It does build Apache with both, but the mutex errors continue.

So, while as Kurt points out, the documentation still states that it is incompatible, the EA allows the conflict to be built unlike before. So, looks like there was a mistake and it was not fixed as promised. My system still shows 3.24 and allows mod_security and Ruid2 to be built together. Mistakes happen... I'm sure it will be fixed soon enough.

 

[ScottTh]

Hi everybody,

The EasyApache team is targeting early next week to release the compatibility fix for mod_ruid2 and mod_security that's being discussed in this thread. Should we not be able to release this bug fix I'll update this thread.

Thanks all for the discussion and questions!

 

[ScottTh]

Hello again,

The EasyApache team has released version 3.24.12 and with that the long rumored and discussed compatibility fix for mod_ruid2 and mod_security is now available. Please view the change log and let us know if there are any questions.

Thanks!

 

[dalem]

Still have the ModSecurity: Audit log: Failed to unlock global mutex: Permission denied if you set the logging to SecAuditLogType Concurrent you get permission denied to create logs

 

[teeps]

Just updated. Still getting this:

[Tue Mar 11 11:30:02 2014] [error] [client xxx.xxx.xxx.xxx] ModSecurity: collection_store: Failed to access DBM file "/tmp/ip": Permission denied [hostname "www.somewebsite.com"] [uri "/wp-login.php"] [unique_id "Ux86CmAeILYAACsfEsAAAAAO"]

# cat /usr/local/apache/conf/modsec2.conf
LoadFile /opt/xml2/lib/libxml2.so
# LoadFile /opt/lua/lib/liblua.so
LoadModule security2_module modules/mod_security2.so
<IfModule mod_security2.c>
SecUploadDir /tmp
SecTmpDir /tmp
SecDataDir /tmp
SecRuleEngine On
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
Include "/usr/local/apache/conf/modsec2.user.conf"
</IfModule>

Moving it out of tmp and into a strictly nobody owned directory has the same effect:

Failed to access DBM file "/var/asl/data/msa/ip": Permission denied

# stat /var/asl/data/msa
File: `/var/asl/data/msa'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 806h/2054d Inode: 523467 Links: 2
Access: (0777/drwxrwxrwx) Uid: ( 99/ nobody) Gid: ( 99/ nobody)

 

[Vinayak]

Working fine for me on several servers.

Steps I took

/scripts/upcp --force
/scripts/easyapache

WHM >> Mod Security >> Reset configuration to: Default Configuration >> Save
Added back custom rules.

No other custom changes to apache.

And it's working fine, no errors, no issues.

 

[dalem]

are you using the gotroot ruleset ??

 

[Vinayak]

No, just some custom rules from here and there.

 

[KurtN.]

Just updated. Still getting this:

[Tue Mar 11 11:30:02 2014] [error] [client xxx.xxx.xxx.xxx] ModSecurity: collection_store: Failed to access DBM file "/tmp/ip": Permission denied [hostname "www.somewebsite.com"] [uri "/wp-login.php"] [unique_id "Ux86CmAeILYAACsfEsAAAAAO"]



Moving it out of tmp and into a strictly nobody owned directory has the same effect:

Failed to access DBM file "/var/asl/data/msa/ip": Permission denied

# stat /var/asl/data/msa
File: `/var/asl/data/msa'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 806h/2054d Inode: 523467 Links: 2
Access: (0777/drwxrwxrwx) Uid: ( 99/ nobody) Gid: ( 99/ nobody)

Are you using CloudLinux with CageFS?

 

[colorcloud]

Hello Kurt,

We are using CloudLinux with CageFS and have same problem:
Message: collection_store: Failed to access DBM file "/tmp/ip": Permission denied

how can I fix this issue?