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.
-
Yes, I've found the OWASP rules do not work properly when mod_ruid2 is enabled alongside the experimental Jailshell with Apache. If I recompile with suPHP and use that instead, no problem at all. It'd be nice to try and get the new Mod Security/OWASP rules functionality working with mod_ruid2. 0 -
This has been assigned internal case number 160281. Note that it might not necessarily result in an immediate resolution, but at the very least our documentation will be updated to reflect this incompatibility. There is currently no timeline on a release. Thank you. 0 -
Has anyone made any headway with this issue? 0 -
Nope and probably never will 0 -
It's something, besides setting 1777 on /tmp/global and /tmp/ip, where there any other changes which were necessary?
I wouldn't use /tmp but that's bout it. You don't need sticky or execute bit, just make it 0666 or 1666 if you prefer to keep sticky bit. In my case i'm using /dev/shm/... and i'm creating the directory structure on boot. This gives faster performance since it's running out on memory. My script is: #!/bin/sh mkdir -p /dev/shm/ touch /dev/shm//{default_SESSION,global,ip}.{dir,pag} chown nobody. /dev/shm//* chmod a+w /dev/shm//* You just need to change , and add an entry at crontab to run it @reboot. You also need to add/change SecDataDir at /etc/httpd/conf/modsec2.user.conf. It's been running ok for months, don't get scared with the sizes of the files because they are sparse and don't really use that much. For instance, checking on one machine, ip.pag gives 64M on ls -l but really uses 840K as shown on ls -s. From time to time, depending on rules and specially on busy hosts, this ip.pag can cause issues (either on memory or disk) and grows to huge sizes (Gb). When that happens apache status starts having processes "hanging" on Logging for some time (seconds). In reality it's reading lots of 0s from the sparse file. That's the size reported and not real size, in the above example 64M. Whenever the size is over 150-200Mb I use: "> ip.dir > ip.pag" on the directory to reset files without needing to remake them. This looses information that's stored but keeps things running smoothly. Feel free to use/adjust this. As I said it's been working for me for months now and the only issue was when I started having the processes on logging and a EC2 machine run out of iops (was using disk at the time).0 -
Excellent. Great use! I am going to give this a shot now on one of our servers. Wouldn't placing the script in the init.d for startup be better? That way it is only ran once on boot. Then run a file rotation in cron? I wouldn't use /tmp but that's bout it. You don't need sticky or execute bit, just make it 0666 or 1666 if you prefer to keep sticky bit. In my case i'm using /dev/shm/... and i'm creating the directory structure on boot. This gives faster performance since it's running out on memory. My script is: #!/bin/sh mkdir -p /dev/shm/ touch /dev/shm//{default_SESSION,global,ip}.{dir,pag} chown nobody. /dev/shm//* chmod a+w /dev/shm//* You just need to change , and add an entry at crontab to run it @reboot. You also need to add/change SecDataDir at /etc/httpd/conf/modsec2.user.conf. It's been running ok for months, don't get scared with the sizes of the files because they are sparse and don't really use that much. For instance, checking on one machine, ip.pag gives 64M on ls -l but really uses 840K as shown on ls -s. From time to time, depending on rules and specially on busy hosts, this ip.pag can cause issues (either on memory or disk) and grows to huge sizes (Gb). When that happens apache status starts having processes "hanging" on Logging for some time (seconds). In reality it's reading lots of 0s from the sparse file. That's the size reported and not real size, in the above example 64M. Whenever the size is over 150-200Mb I use: "> ip.dir > ip.pag" on the directory to reset files without needing to remake them. This looses information that's stored but keeps things running smoothly. Feel free to use/adjust this. As I said it's been working for me for months now and the only issue was when I started having the processes on logging and a EC2 machine run out of iops (was using disk at the time).
0 -
Excellent. Great use! I am going to give this a shot now on one of our servers. Wouldn't placing the script in the init.d for startup be better? That way it is only ran once on boot. Then run a file rotation in cron?
Init.d would probably be better since you can control it to start before apache but I was lazy at the time and it's been a cron entry ever since. A cron @reboot only runs when the machine boots up, if you do the startup script feel free to reply here and I'll probably change mine.0
Please sign in to leave a comment.
Comments
39 comments