Mod RUID 2 and ModSecurity
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.
-
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: [quote="cPanelKurtN, post: 1530951">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.0 -
Thank you Michael!! [COLOR="silver">- - - Updated - - - That is exactly what I thought was going on contrary to popular consensus! Great news! 0 -
Hello Michael, Any eta on that update? Thank you. 0 -
[quote="Solokron, post: 1561492">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: [url=http://docs.cpanel.net/twiki/bin/view/AllDocumentation/ChangeLog/EasyApache]EasyApache Change Log Thank you.0 -
I'm a bit puzzled here... cPanelKurtN mentions that the mod_security incompatibility has case number 76493. The changelog on [url=http://docs.cpanel.net/twiki/bin/view/AllDocumentation/ChangeLog/EasyApache]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? [quote="cPanelMichael, post: 1552451"> 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: [quote] 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.
0 -
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. 0 -
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 0 -
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. 0 -
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 0 -
[quote="coolice, post: 1585562">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.0 -
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! 0 -
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! 0 -
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 :( 0 -
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"> [QUOTE]# 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 SecUploadDir /tmp SecTmpDir /tmp SecDataDir /tmp SecRuleEngine On SecAuditEngine RelevantOnly SecAuditLogStorageDir /usr/local/apache/logs/modsec_audit SecAuditLogType Concurrent SecAuditLogStorageDir /usr/local/apache/logs/modsec_audit SecAuditLogType Concurrent SecAuditLog logs/modsec_audit.log SecDebugLog logs/modsec_debug_log SecDebugLogLevel 0 Include "/usr/local/apache/conf/modsec2.user.conf"
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)0 -
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. 0 -
are you using the gotroot ruleset ?? 0 -
No, just some custom rules from here and there. 0 -
[quote="teeps, post: 1592822">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?0 -
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? 0 -
I would strongly consider changing the directory to something specific to your ruleset, as opposed to using /tmp. For example, the comment above mentioned placing it in /var/asl/data/msa. If you change it to that directory then try updating your /etc/cagefs/cagefs.mp file with the following: /var/asl/data/msa 0 -
[quote="cPanelKurtN, post: 1594502">Are you using CloudLinux with CageFS?
Hello Kurt, I'm seeing the same issue with CentOS without CageFS. As I understand the problem is CPanel solved the log file by modifying modsecurity source to append the username of the apache process to the directory path of the log files (great ideia btw) but hasn't done the same thing for the secDataDir. (CPanel changes @File modsecurity-apache/apache2/msc_logging.c') For the secDataDir the first request owner still gets to create the files but all others requests from other owners get access denied since it's a file from a different owner and without access permissions. My programming knowledge ain't that good but it should be on 'persist_dbm.c'. Problem is the structure which provides the UID isn't passed on that function and as such the changes required might require more changes in mod_security code. As a workaround and easier fix it should be possible to change the code to create the file as a shared file with different permissions (this isn't secure as each user could have impact on another). If anyone has a solution for this or a better approach please advise, as it stand no rules that make use of secDataDir are working. Regards, Manuel0 -
Hi Manuel, thanks for the feedback. After briefly looking at the mod_security plugin, I also do not see an easy alternative given mod_security's current implementation. A few possibilities could be (NOTE: this is not an exhaustive list): - ]
- World-writable DBM: This requires a modification to mod_security to prevent the file from being forced as 640. It would also be a security violation since this would allow anyone to write to the file and as-such, would not be a good approach.
- Per-user DBM (without CageFS): This would also require a modification to mod_security, thus forcing it to write to an alternative directory. Unfortunately, this would have the unintended consequence of writing to a path that is different than what was specified by the rule itself. It could also have other unintended consequences with respect to file/directory creation.
- Per-user DBM (with CageFS): CageFS appears to have the functionality necessary to achieve this without any modifications to mod_security. The instructions for this are defined in the CloudLinux documentation, under Per user virtual mount points. Note: I have not tested this approach yet.
0 -
We too continue to encounter this issue - run CentOS without CloudLinux, ModSecurity, RUID2. After exhaustive research I am about to come to the conclusion that RUID simply cannot be run alongside ModSecurity and ModSecurity properly function. Is that the correct take-away from the current state of affairs? Another way of asking this is - do we effectively have to choose between the two technologies? 0 -
[quote="jhawkins003, post: 1711632">We too continue to encounter this issue - run CentOS without CloudLinux, ModSecurity, RUID2. After exhaustive research I am about to come to the conclusion that RUID simply cannot be run alongside ModSecurity and ModSecurity properly function. Is that the correct take-away from the current state of affairs? Another way of asking this is - do we effectively have to choose between the two technologies?
Yes, if you're using Mod Security rules that need the DBM functionality. No, if you're not using those kinds of rules.0 -
I'm using the free rules from Comodo. Is there an easy way of detecting which rules use DBM so I can just leave those disabled? 0 -
I was wondering if there is an internal case number for fixing this issue and any expected release timeframe? Is there any way for us to track progress on this case? 0 -
[quote="Recifier, post: 1819771">I was wondering if there is an internal case number for fixing this issue and any expected release timeframe? Is there any way for us to track progress on this case?
Could you elaborate on the specific issue you are still encountering at this time? Thank you.0 -
The same problem as the last few posters. Creating a ModSecurity rule that uses DBM while Mod_RUID2 is enabled causes the message: collection_store: Failed to access DBM file "/tmp/ip": Permission denied and the rules have no effect. 0 -
[quote="Recifier, post: 1820692">The same problem as the last few posters. Creating a ModSecurity rule that uses DBM while Mod_RUID2 is enabled causes the message: collection_store: Failed to access DBM file "/tmp/ip": Permission denied and the rules have no effect.
Please see the following posts (there are no new updates): [QUOTE]We too continue to encounter this issue - run CentOS without CloudLinux, ModSecurity, RUID2. After exhaustive research I am about to come to the conclusion that RUID simply cannot be run alongside ModSecurity and ModSecurity properly function. Is that the correct take-away from the current state of affairs? Another way of asking this is - do we effectively have to choose between the two technologies?
[quote="cPanelKurtN, post: 1712662">Yes, if you're using Mod Security rules that need the DBM functionality. No, if you're not using those kinds of rules.
In addition: [quote="cPanelKurtN, post: 1712662">Hi Manuel, thanks for the feedback. After briefly looking at the mod_security plugin, I also do not see an easy alternative given mod_security's current implementation. A few possibilities could be (NOTE: this is not an exhaustive list): World-writable DBM: This requires a modification to mod_security to prevent the file from being forced as 640. It would also be a security violation since this would allow anyone to write to the file and as-such, would not be a good approach. Per-user DBM (without CageFS): This would also require a modification to mod_security, thus forcing it to write to an alternative directory. Unfortunately, this would have the unintended consequence of writing to a path that is different than what was specified by the rule itself. It could also have other unintended consequences with respect to file/directory creation. Per-user DBM (with CageFS): CageFS appears to have the functionality necessary to achieve this without any modifications to mod_security. The instructions for this are defined in the CloudLinux documentation, under Per user virtual mount points. Note: I have not tested this approach yet.0 -
Yes, I read the thread as well... which brought me to ask my original question :) Is there a case number for this and is there any expected release timeframe? I just want to be able to keep track against the changelog so I know when to try my rules again. 0
Please sign in to leave a comment.
Comments
39 comments