Mod_Ruid2 + SuPHP Issue - Internal Server Error

[mannnq]

My issue is simple to explain but cant figure out what is happening to solve, there we go;

I have an fresh CentOS 6 and cPanel Install.

I have compiled with EasyApache an ModRuid2 to prevent Symlink Attack and Im getting those results:

- SuPHP without Jail Apache = PHP Works
- SuPHP with Jail Apache = Internal Server Error on any PHP Files
- CGI with Jail Apache = PHP Works

Any idea how to keep SuPHP and Jail Apache working together against symlink attacks?

Regards

 

[vanessa]

Do not use ruid2 with suphp - it's supposed to be used with mod_php.

 

[mannnq]

Thanks for the prompt reply, my last server was compromised against that attack, thats why im moving and still worried about it, wish combination do you think are better against it (except cloud linux)?

 

[quizknows]

RUID / jailed apache / mod_php is probably technically more secure, but you may run into compatibility issues.

Personally most of my customers use SuPHP with the EA provided symlink race condition protection. I have yet to see anyone symlink hack multiple CMSes with that in place. If you have a lot of customers this is likely to be less of a headache IMO.

 

[vanessa]

I personally stick with suphp without ruid2. Using mod_ruid2+mod_php alone is fine, but there are some reservations about the security aspects of mod_ruid2 itself, and the fact that more valuable tools, such as mod_security, are rendered nonfunctional with this installed.

You probably don't want to invest too much in the symlink hack issue, as that tends to be a very small part of security problems in shared hosting environments. Really, the only way you're going to get true segmentation is by actually jailing users, which requires something like CageFS (cloudlinux) or CloakFS (betterlinux). Both of these also protect against symlink attacks.

 

[quizknows]

Vanessa, from what I'm told, ModSecurity is now functional with RUID2. That said I also still have my reservations about it and opt for SuPHP with symlink race condition protection (at least for customers who don't use CL with securelinks).

Regarding symlink hacks, I find them to be a huge issue in shared hosting environments. I've long since lost count of the number of hosting resellers hosted in my data center who had their businesses turned upside down for a day or two because they didn't have any protection in place for them. If they were lucky, they had backups. If they were unlucky, it was hours of malware removal and sed commands to remove infections. A sizeable percentage of the hacked WP or Joomla sites I investigate (which is usually several a day) see an attempted symlink hack while the script kiddies are in there.

 

[vanessa]

Regarding symlink hacks, I find them to be a huge issue in shared hosting environments. I've long since lost count of the number of hosting resellers hosted in my data center who had their businesses turned upside down for a day or two because they didn't have any protection in place for them. If they were lucky, they had backups. If they were unlucky, it was hours of malware removal and sed commands to remove infections. A sizeable percentage of the hacked WP or Joomla sites I investigate (which is usually several a day) see an attempted symlink hack while the script kiddies are in there.

I agree - I wasn't implying that this issue should be ignored, but rather that focusing solely on this problem in lieu of the larger problems presented with shared hosting could be problematic. I tend to veer on the site of solving the solution as a whole, meaning, actually segmenting users on the system.

 

[quizknows]

Definitely a solid view and approach. Cheers.

 

[cPanelMichael]

Hello

I just wanted to note the following links for other users who may see this thread:

Solutions for handling Symlink Attacks
Mod_Ruid2 - Documentation

Thank you.

 

[KurtN.]

Vanessa, from what I'm told, ModSecurity is now functional with RUID2. That said I also still have my reservations about it and opt for SuPHP with symlink race condition protection (at least for customers who don't use CL with securelinks).

The issues with Mod Security and any kind of MPM (or module like ruid2) that switch users, are two-fold:

1. Mod Security uses a file-based lock when writing events, which means, more than user is unable access the same lock file.
2. Mod Security uses a global database for DBM backed events.

With respect to 1, EasyApache got around the file-based lock by using the Mod Security "concurrent" logging configuration, as well as patching it, to ensure each user writes to their own logging area. Rather than dealing with that, it would be interesting to see if the modules could be updated (or patched), to instead have a configurable lock type (e.g. provide POSIX-based semaphore locking since this works across multiple threads and processes).

With respect to 2, we have not found a reliable mechanism for ModSec'd DBM rules, as it requires the rule to define an explicit path. So any rule that uses that, will not work correctly.