Security Advisor - Kernel Symlink Protection

[planetjoin]

Moved from: Apache Symlink Protection is enabled

Actually, the message you see in "WHM >> Security Advisor" is a false positive.

Hello!
I have WHM 60.0 (build 35) with EASY APACHE4
Securty advisor still give me this warning :

"Kernel does not support the prevention of symlink ownership attacks.You do not appear to have any symlink protection enabled through a properly patched kernel on this server, which provides additional protections beyond those solutions employed in userland. Please review the documentation to learn how to apply this protection."

and in Apache Global Configuration i have both Symlinks items as "default"

This is still a "false positive" ?


Regards
Fabian

 

[cPanelMichael]

Hello Fabian,

That message is not a false positive. While other solutions referenced on that document will help protect against symlink attacks, a kernel-level solution such as the cPanel hardened kernel is recommended for additional protection.

Thank you.

 

[uk01]

Hi, what's the best way of doing this with Centos 7 as the Cpanel kernel solution is only for centos 6

Bluehost solution - warns that it slows the server down and is not the most secure

GRsec - not available for Centos 7

Cpanel kernel - Not available for centos 7

Cloudlinux - we only need this on one server, CageFS is not available without purchasing CL for every server on top of Cpanel.

Mod_ruid2/Jailshell - we can't use this as we have suphp and switching to mod_ruid2 I imagine would probably cause too many issues with users php.ini files.

What solution are others using? There doesn't seem to be much we can do with a Centos 7, suphp shared hosting server?
If there is something Im missing, advice would be gratefully received!

 

[cPanelMichael]

Bluehost solution - warns that it slows the server down and is not the most secure

This patch may slow the performance of high-traffic servers, but you could try enabling this option temporarily to determine if the performance actually decreases.

Cloudlinux - we only need this on one server, CageFS is not available without purchasing CL for every server on top of Cpanel.

Could you elaborate on this statement? You should be able to purchase a single CloudLinux license. If this is a VPS, what virtualization software are you using?

Mod_ruid2/Jailshell - we can't use this as we have suphp and switching to mod_ruid2 I imagine would probably cause too many issues with users php.ini files.

This should actually be less of an issue in cPanel version 64 with the implementation of the following case:

Fixed case CPANEL-10610: Have cPanel INI editor edit .htaccess also.

This change ensures that PHP configuration changes made through the MultiPHP INI Editor on systems using suPHP are automatically converted to the corresponding .htaccess entries when switching to DSO.

Thank you.

 

[uk01]

Apologies, the last message formatted wrong, with my replies inside the quote.

This patch may slow the performance of high-traffic servers, but you could try enabling this option temporarily to determine if the performance actually decreases.

Hard to do really with shared hosting as there are around 50 websites on a server, all different, some faster than others depending on plugins, themes etc. I guess the main place to test would be within Wordpress admin or something like that but it's still dificult to judge the effects to all sites.
Being as this patch is not the recommended solution, I'm not keen to invest too much time in this unless I have to.

Could you elaborate on this statement? You should be able to purchase a single CloudLinux license. If this is a VPS, what virtualization software are you using?

Yes sure, we use Vsphere VMWare and have several VPS shared hosting servers currently running on each host machine. We only have one VPS with Cloudlinux and we tend to migrate accounts to that VPS which abuse resources and need some kind of control. ie we have one user with a Wordpress site which thrashes the CPU and CL stops that user crashing the server.

If there is a way of buying one license, I'd be interested in learning about that. However, my thoughts are that each VPS is a separate ip and a separate license, on top of the cost of Cpanel? As the other shared hosting VPS's are ok without CL it's alot of expense just for CageFS.

This should actually be less of an issue in cPanel version 64 with the implementation of the following case:

Fixed case CPANEL-10610: Have cPanel INI editor edit .htaccess also.

This change ensures that PHP configuration changes made through the MultiPHP INI Editor on systems using suPHP are automatically converted to the corresponding .htaccess entries when switching to DSO.

Thank you.

This sounds promising! So if users have added various things in their php.ini files, it would convert them, however we'd need to educate all users to then use htaccess again, not php.ini which isn't good but possible. Especially developers who will start querying the changes.

I guess mod_ruid2 makes DSO just as secure as suphp/suhosin by spawning php processes as each user. I know there's also FastCGI and things are becoming more compatible between EA4 and suhosin etc. However, they seem to still have the symlink issue?

 

[cPanelMichael]

If there is a way of buying one license, I'd be interested in learning about that. However, my thoughts are that each VPS is a separate ip and a separate license, on top of the cost of Cpanel? As the other shared hosting VPS's are ok without CL it's alot of expense just for CageFS.

Thank you for clarifying the question. As I understand, you are asking if you could use a single CloudLinux license for one VPS hardware node and have it applied to all of the VPS accounts created under it. The answer to that question is no, as you'd need a separate license for each individual VPS machine.

This sounds promising! So if users have added various things in their php.ini files, it would convert them, however we'd need to educate all users to then use htaccess again, not php.ini which isn't good but possible. Especially developers who will start querying the changes.

You'd still need to condition users to make any PHP configuration changes via the "cPanel >> MultiPHP INI Editor for cPanel" option documented at:

MultiPHP INI Editor for cPanel - Documentation - cPanel Documentation

Users would need to utilize this feature to ensure the configuration changes are preserved through changes to different PHP versions and handlers.

I guess mod_ruid2 makes DSO just as secure as suphp/suhosin by spawning php processes as each user. I know there's also FastCGI and things are becoming more compatible between EA4 and suhosin etc. However, they seem to still have the symlink issue?

The use of FastCGI alone would not protect against symlink attacks. What I believe would help the most in your case would be support for the cPanel hardened kernel on CentOS 7. I encourage you to open a feature request for this via:

Submit A Feature Request

Thank you.

 

[uk01]

The use of FastCGI alone would not protect against symlink attacks. What I believe would help the most in your case would be support for the cPanel hardened kernel on CentOS 7. I encourage you to open a feature request for this via:

Submit A Feature Request

Thank you.

Definitely! I'll do the feature request now. As that would be a Cpanel kernel, it's the best route really and the most reliable.