Solutions for handling symlink attacks

[Infopro]

I think this is what you're looking for:

WHM » Server Configuration » Tweak Settings, Security tab.

* EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell.

If mod_ruid2 is compiled in via EasyApache, mod_ruid2 is enabled, and a user has their shell set to jailshell or noshell, enabling this option will chroot() a user's Apache Virtual Host into the cPanel® jailshell environment. Each user will require 14 bind mounts. While modern Linux supports a very large number of bind mounts, many processes read /proc/mounts (even mkdir on RHEL 5 and CentOS 5). Reading /proc/mounts can be quite expensive when it becomes large. It is highly recommended that you do not exceed 256 jailed users unless you are using RHEL 6 or CentOS 6.

 

[AlexAT]

I see, thank you!

 

[ThinIce]

Thanks for your continued work on this guys. Out of interest Is the plan for mod_ruid2 and apache jails to eventually replace suphp as the default for new installs if it turns out to be a stable way of doing things?

 

[cPanelNick]

Thanks for your continued work on this guys. Out of interest Is the plan for mod_ruid2 and apache jails to eventually replace suphp as the default for new installs if it turns out to be a stable way of doing things?

Its something we are considering, but its too soon to tell if its going to meet the majority of our customer's needs.

 

[cPanelNick]

I have attempted to provide a brief summary of the existing solutions. If I've left something out, please let me know.

Filesystem level solutions (best choices):


mod_ruid + jailshell [RECOMMENDED]: cPanel & WHM 11.38 Release Notes
Upside: Very easy to enable, just recompile apache + enable in tweak settings and you are done.
Downside: Requires cPanel 11.38 (RELEASE soon), doesn't scale well on CentOS5/RHEL5 (ok if < 256 users), requires mod_ruid2, marked EXPERIMENTAL

cagefs [RECOMMENDED]: CloudLinux Documentation
Upside: Available on all cPanel supported platforms today, already included with CloudLinux
Downside: Nominal fee (requires CloudLinux), requires cagefsctl --update when changes are made

Kernel + Apache solutions (good choices):


GRSec Kernel Patch: grsecurity forums - View topic - Prevent Symlink Attack
Upside: Kernel level protection, you can't really get any better then this
Downside: Requires a custom kernel and the burden of maintaining and installing it.

mod_hostinglimits securelinks w/ CloudLinux kernel: Introducing SecureLinks for Apache, CloudLinux Documentation
Upside: Already installed if you are using CloudLinux
Downside: The directive will not affect VirtualHost without a user id specified

Apache Level Patches (last resort choices):


Note: These are not recommended as they can be defeated with a little bit of knowledge. You should only use ONE of these options as a last resort if you cannot implement one of the above.

For more details and a more in-depth comparison, please see: Symlink Race Condition Protection

Bluehost provided patch (available in EasyApache): Symlink Race Condition Protection
Upside: Can be easily installed via an easy apache update
Downside: Protection is not as good as a kernel or filesystem level solution, performance penalty

Rack911 provided patch: http://layer1.rack911.com/before_apache_make
Upside: Faster then the patch provided in easy apache. Simple
Downside: Protection is not as good as a kernel or filesystem level solution.

Mod Note: Redirected several links, Aug 8 2017.

 

[ThinIce]

Nick,

Are there any comparisons knocking around between jailshell and cagefs? Such would probably be handy for those choosing between the two recommended implementations

 

[cPanelNick]

Nick,

Are there any comparisons knocking around between jailshell and cagefs? Such would probably be handy for those choosing between the two recommended implementations

The apache jails are a very new feature so there isn't anything floating around just yet. I expect we won't see much feedback on them until we go to RELEASE for 11.38 (hopefully in the next 7-10 days)

 

[quizknows]

Resolved? laughable. The patch in cPanel took forever and isn't even as good as the rack911 patch. Add the rack911 style patch to EA and then you could really call this resolved.

For the probably 100th time, I wish they'd just have both patches available in EA. It's really the sensible option here.

And yes, I know both theoretically can be worked around, but I haven't seen a single script kiddy manage to do it. Obviously on a real professional level I'd recommend something like cloudlinux with securelinks, but many people just won't do it. I still contend the rack911 patch is a better "solution" for most people than the one currently in easyapache, due to performance and PHP handler compatibility.

 

[cPanelNick]

Add the rack911 style patch to EA and then you could really call this resolved..... I still contend the rack911 patch is a better "solution" for most people than the one currently in easyapache, due to performance and PHP handler compatibility.

I have updated the summary with all the comments and corrections we have received: https://forums.cpanel.net/f185/solutions-handling-symlink-attacks-202242-p23.html#post1397221

I'm not sure how responsible we would be to add another apache level patch now that better solutions have become available.

And yes, I know both theoretically can be worked around, but I haven't seen a single script kiddy manage to do it.

Please see details via PM.

 

[faisikhan]

Got hit like this as well. how to prevent -if we disable follow symlinks any impact on web sites?

I'd also more interested to know the brief answer of that please?

 

[quizknows]

The link that Nick posted pretty well sums up your options:

https://forums.cpanel.net/f185/solutions-handling-symlink-attacks-202242-p23.html#post1397221

Apache level patches should be a last resort. Cloudlinux with Securelinks (the CageFS option) is the best idea, as applications can have followsymlinks enabled, but the server stops cross-account symlinks.

I personally have used the rack911 patch with much success, as it makes FollowSymlinks act like SymlinksIfOwnerMatch. It's a pretty good solution to stop cross-account symlink hacks, however, it can be defeated. I haven't seen hackers bother to get around it, but it can be done. Disabling compliers in WHM can help stop that. At the end of the day, it depends if the hacker you're dealing with really knows what they're doing, or is just running automated scripts; many of them just run the automated scritps.

 

[Spetsnaz]

Does rack911 patch work with the new apache 2.4?

 

[sahostking]

The link that Nick posted pretty well sums up your options:

https://forums.cpanel.net/f185/solutions-handling-symlink-attacks-202242-p23.html#post1397221

Apache level patches should be a last resort. Cloudlinux with Securelinks (the CageFS option) is the best idea, as applications can have followsymlinks enabled, but the server stops cross-account symlinks.

I personally have used the rack911 patch with much success, as it makes FollowSymlinks act like SymlinksIfOwnerMatch. It's a pretty good solution to stop cross-account symlink hacks, however, it can be defeated. I haven't seen hackers bother to get around it, but it can be done. Disabling compliers in WHM can help stop that. At the end of the day, it depends if the hacker you're dealing with really knows what they're doing, or is just running automated scripts; many of them just run the automated scritps.

So are you stating having both followsymlinks disabled and have cloudlinux SecureLinks enabled is unnecessary? Rather have followsymlinks = allowed and SecureLinks=enabled? Is this still secure and safe?

 

[Spetsnaz]

sahostking

I think having followsymlinks disabled and securelinks enabled is fine.

I did all the suggestions they recommended but without the ones with cloudlinux needed.

 

[quizknows]

Does rack911 patch work with the new apache 2.4?

No, it does not (sorry, I said yes at first because I though it said 2.2.24).

sahostking: If you have securelinks, you don't have to mess with Apache at all. Leaving followsymlinks on is fine if you have cloudlinux with securelinks.

 

[wd0325]

Hi all,
I was try securing server with rack911 method and configure open_basedir = /home/
Symlink access in file manager and browser was successfully blocked, but I can access symlink to root via FTP.
I was try to install cageFS, but the problem still exist. I still can access symlink to root via 'FTP client' like 'CoreFTP' from cpanel client account.
Can someone help to resolve this problem?

 

[LAZer]

today i installed apache 2.2.25 , php 5.3.27 , with the option of symlink race condition protection in easyapache
now every file that is uploaded via php to the server gets permission 600 , and is not accessible until adding read permissions to it , changing to 644 .
how can i set default uploaded file permissions to 644 instead of current 600 ?

i tested and saw that some users scripts like whmcs or wordpress are working fine and some scripts like rapidleech have this problem.

 

[inthukha]

Hi all,
I was try securing server with rack911 method and configure open_basedir = /home/
Symlink access in file manager and browser was successfully blocked, but I can access symlink to root via FTP.
I was try to install cageFS, but the problem still exist. I still can access symlink to root via 'FTP client' like 'CoreFTP' from cpanel client account.
Can someone help to resolve this problem?

Can you tell me steps how you get the root directory access via client account ? so i will check mine ?

 

[ikillbill]

any new solution if we use apache 2.4.6 without cloudlinux/cagefs?
I wish rack911 has patch for apache 2.4 though~

 

[quizknows]

I have not tested a build, but the cPanel option for race condition protection shows up in easyapache with 2.4 selected. If I get a chance I may test that.

Edit: The EA option for symlink race condition protection seems to work fine on apache 2.4. I removed my rack911 patch file prior to the build (obviously).