Apache vhosts are not segmented or chroot()ed
How to fix error: Apache vhosts are not segmented or chroot()ed? we have enabled Jailed Shell but error still are not removed.
50235
-
Hello, You'd need to use Mod_Ruid2 with the "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel" jailshell" option enabled in "WHM >> Tweak Settings". Or, you'd need to use CageFS with CloudLinux. Thank you. 0 -
Hello, You'd need to use Mod_Ruid2 with the "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel" jailshell" option enabled in "WHM >> Tweak Settings". Or, you'd need to use CageFS with CloudLinux. Thank you.
So we need enable Mod_Ruid2 for use "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel" jailshell" option enabled in "WHM >> Tweak Settings"? Ones enabled option "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 then Can disabled Mod_Ruid2?0 -
So we need enable Mod_Ruid2 for use "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel" jailshell" option enabled in "WHM >> Tweak Settings"? Ones enabled option "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 then Can disabled Mod_Ruid2?
That's correct, you will need to enable both Mod_Ruid2 and the "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel" jailshell" option. Disable Mod_Ruid2 after enabling the option will automatically disable the option, as Mod_Ruid2 is required for it to work. Thank you.0 -
It sounded like maybe he was asking more DO we need to enable... I'm wondering the same thing. This warning shows as critical on the list from the system analyzer, yet it seems like this is not a security issue or setting included in the base setup, but more of a hack/fix. So: is it something that should absolutely be done on our dedicated servers? Or is it something that is really only necessary on shared servers with potentially malicious users? 0 -
Hello @kwdamp, Good question! We do recommend taking steps to ensure Apache virtual hosts are segmented or chroot()ed. While Mod_Ruid2 and the "Jail Apache" option together is one way to achieve this, using CageFS with CloudLinux is ideal if you are able to purchase a CloudLinux license. Note we have an internal case (SWAT-733) open to ensure that specific Security Advisor alert reflects the fact that Mod_Ruid2 is required in order to use the "Jail Apache" option. Thank you. 0 -
Is it correct that this risk only exists if malicious users exist on the server (whether they get in by hacking an account login or have one assigned to them)? The scenario I'm referring in particular is a dedicated server, where all accounts are under my control, and all user accounts are set to "Disabled Shell" in Home "Account Functions "Manage Shell Access. Doesn't that eliminate the concern entirely? Please advise... 0 -
Is it correct that this risk only exists if malicious users exist on the server (whether they get in by hacking an account login or have one assigned to them)?
That's correct. Though do note that disabling shell access to the account doesn't mitigate the issue. Thank you.0 -
That's correct. Though do note that disabling shell access to the account doesn't mitigate the issue.
Good point. I shouldn't have even mentioned the shell access setting. This doesn't represent an immediate concern for me because I am the only user, that could change in the future, and I'm sure for many others this is a current concern. Which leads me to this question: HTTP/2 seems to be a forward looking standard but enabling mod_HTTP/2 requires the removal of mod_ruid2. Therefore are we to understand that the only available solution is to purchase and run CloudLinux? Is it really the case that if you want to move to HTTP/2 and don't want to run CouldLinux you're just stuck with a security hole, or is there more to this story?0 -
Is it really the case that if you want to move to HTTP/2 and don't want to run CouldLinux you're just stuck with a security hole, or is there more to this story?
That's correct. Without the Ruid2/Jail Apache functionality (which doesn't allow the use of HTTP/2), the only supported alternate solution at this point in time is to use a third-party product such as CloudLinux. Thank you.0 -
What about chrooting in a php-fpm environment. There's some discussion scattered throughout the the Feature Request for Enhanced FPM Support, but specifically: Enhance FPM support Has this been completely abandoned? The jailmount for cPanel needs a little bit of work (it doesn't mount everything). I'm pretty sure I've mentioned that some where, but I can't remember where. This doesn't solve CGI execution. Although that could be improved and possibly solved with some help from cPanel and Apache. This doesn't provide complete isolation like CloudLinux does. But, how else do end users execute code in a shared hosting environment? Shell (jailshell solves this) or PHP (chroot'd php-fpm solves this) or CGI (no current solution). How much is CGI actually used any more? 0 -
Hello @sparek-3 Per our setting in the Tweak Settings interface (WHM >> Home >> Server Configuration >> Tweak Settings).
Thus, even when using PHP-FPM, Mod_Ruid2 and the "Experimental: Jail Apache Virtual Hosts using mod_ruid2 and cPanel" jailshell" option are still required so the system automatically binds the user pool to the virtfs mount. Thank you.0 -
You may want to double check this. Mod_Ruid2 and the "Experimental: Jail Apache Virtual Hosts using mod_ruid2 and cPanel" jailshell" aren't required for PHP-FPM to run in a chroot'd environment. At least not in what I have tested. Using PHP-FPM and creating the /var/cpanel/feature_toggles/apachefpmjail file and insuring that the user is using noshell or jailshell as their shell, executes PHP through the php-fpm socket for that user in a chroot'd environment. Perhaps I have my system misconfigured? If so, I don't want to fix it. Granted, the jailmount that cPanel's modified php-fpm binary does to run the code in the chroot leaves a bit to be desired - it doesn't fully mount the /home/virtfs/%user% path. (The fix: login as the user using jailshell, and the path gets fully populated). But other than that, it seems to operate just as expected. I've often wondered why this didn't get much fanfare, but perhaps that's because the right hand doesn't know what the left hand is doing. One of the key features of CloudLinux is the CageFS system. But cPanel essentially has the same thing already baked in, with their jail system. But for whatever reason cPanel doesn't want to expand on this jail system and seems to just want to to forget that it's there, and then push people over to CloudLinux for CageFS. 0 -
Granted, the jailmount that cPanel's modified php-fpm binary does to run the code in the chroot leaves a bit to be desired - it doesn't fully mount the /home/virtfs/%user% path. (The fix: login as the user using jailshell, and the path gets fully populated). But other than that, it seems to operate just as expected.
Hello, While it's not required, we recommend enabling the Experimental: Jail Apache Virtual Hosts using mod_ruid2 and cPanel" jailshell option. When PHP-FPM jails are active (e.g. /var/cpanel/feature_toggles/apachefpmjail exists and noshell or jailshell is enabled for a user), it causes PHP-FPM to attempt to chroot to virtfs for that user. However, it only verifies the jail is mounted (as opposed to fully setup and populated). This presents a problem when Mod_Ruid2 and the Experimental: Jail Apache Virtual Hosts using mod_ruid2 and cPanel" jailshell option are not enabled because PHP-FPM can potentially attempt to chroot into an incomplete jail environment. Internal case EA-5524 is open to address this behavior. Thank you.0 -
Hello, You'd need to use Mod_Ruid2 with the "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel" jailshell" option enabled in "WHM >> Tweak Settings". Or, you'd need to use CageFS with CloudLinux. Thank you.
For me this option is greyed out, so, what do i do?0 -
For me this option is greyed out, so, what do i do?
You have to install Mod_Ruid2 on the system using WHM >> EasyApache 4 in order to allow that option to be enabled. Note some modules are not compatible with Mod_Ruid2 (e.g. suPHP). WHM >> EasyApache 4 will prompt you if any modules currently installed on your server are not compatible with Mod_Ruid2 when you go to enable it under the Apache Modules section in the interface. Thank you.0 -
When i go to turn it on i get this list: The following conflicts are installed on this machine. They will be removed as part of this package selection: mod_mpm_worker mod_cgid mod_suphp mod_suexec What do these things do? would i miss them? 0 -
Hello, It means that Mod_Ruid2 is not compatible with some of the existing RPMs installed as part of your EasyApache 4 profile. If you were to install Mod_Ruid2, you'd have to remove those RPMs and thus would require that you use a different MPM and uninstall suPHP. If you prefer to use the Worker MPM and suPHP on the server, then you won't be able to use Mod_Ruid2 and thus would need to use something like CageFS to address that warning in Security Advisor. Thank you. 0 -
I don't understand, to my knowledge this is a stock install of WHM, why is the security adviser advising that the settings presumably setup by cPanel inc. as the default ones are not good enough while it needs some serious re configuration to sort this out? I thought that buying commercial software would mean that it would work rather that warn me against itself's in built vulnerabilities! what is "suPHP" and "WORKER" ?what do they do for me? what do i replace them with ? SSH is disabled, isn't this enough? 0 -
Hello @Thunderchild, We consider both security and functionality when deciding on the default options enabled as part of new cPanel & WHM installations. The advice you see in WHM >> Security Advisor is intended to provide you with information to help increase your server's security, but sometimes the most secure configuration isn't the most functional for the websites that you host. Security Advisor is intended to provide you with information to help improve your server's security, but it's ultimately up to you and/or your system administrator if you take that advice. We're happy to help if you have questions about a specific warning that's presented in Security Advisor. what is "suPHP" and "WORKER" ?what do they do for me? what do i replace them with ?
MPM stands for Multi-Processing Module and we document how each option works at: Multi-Processing Modules - MPMs - EasyApache 4 - cPanel Documentation suPHP is a PHP handler. We document the available PHP handlers and their requirements at: PHP Handlers - EasyApache 4 - cPanel DocumentationSSH is disabled, isn't this enough?
No, the option in-question will chroot() a user's Apache Virtual Host into the jailshell environment. Disabling SSH access on your accounts doesn't do that and doesn't negate the security issue addressed by this option or by an alternative such as CageFS. Thank you.0 -
Well i am sorry if i am cautious by cPanels "standard" setup was blatantly insecure. this is the full message i get when i go to enable mod_ruid2: The following conflicts are installed on this machine. They will be removed as part of this package selection: mod_mpm_worker mod_cgid mod_suphp mod_suexec The following requirements are not installed on this machine. They will be added as part of this package selection: mod_mpm_prefork mod_cgi mod_ruid2 Is this proposing to automatically replace the removed components with some thing that will do the same thing but be compatible? 0 -
so prefork replaces worker and apparently is the default but to my knowledge I have not altered it but i have worker. 0 -
Is this proposing to automatically replace the removed components with some thing that will do the same thing but be compatible?
Hello, That's correct. Looking at the output you provided, the main difference is that you'll need to use DSO with Mod_Ruid2 instead of suPHP as your PHP handler. Thank you.0 -
So if i enable mod_ruid2 it will automatically take care of things to maintain current functionality? 0 -
So if i enable mod_ruid2 it will automatically take care of things to maintain current functionality?
Hello @Thunderchild, You should also ensure the DSO PHP package in enabled under the PHP Extensions section in WHM's PHP Handlers - EasyApache 4 - cPanel Documentation Thank you.0 -
That's correct. Though do note that disabling shell access to the account doesn't mitigate the issue. Thank you.
So what you're really saying here then is that disabling shell doesn't actually disable shell and thus is a useless feature and giving users the wrong impression that they are disabling shell access when in fact they aren't? If so, this is very bad system design and very bad business practice as this is a feature relating to security of user's system. Might want to think about either updating that functionality or providing more documentation/warnings that disabling shell doesn't actually disable all shell access for the user.0 -
To bring you up to speed very fast all linux server stuff is a joke. I started with Vesta CP that is free and naturally had not very much graphical interface functionality, but i could not get help because i am not a linux expert and the forums stare down their noses and laugh at you. So I thought I'd pay for commercial software so that it would work preconfigured out of the box and would have the rough stuff dealt with. What I am instead finding is the same "attitude" as no explanation can be made simple and a request for more information just gets me pointed and an equally cryptic user manual for the open source project that was incorporated into cPanel. For all of their greatness all cPanel seem to have done is produce a cryptic user interface that ties together freely available software. BE WARNED the default install has all security turned off and you are quickly recommended to install yet another freeware program you could run on any server. My server got the arse hacked out of it because none of the security was enabled. So yea I am feeling moderately scammed. Clearly these linux people want to keep the plebs out. I never chose to run my own server but with all the problems I have had from crooked hosting companies that oversell their resources until they are running on thin air I decided it would actually be more cost effective to just have my own server, I don't want to steal anyones business. i just want hosting that actually does what it is supposed to do and does not have silly limits. 0 -
So what you're really saying here then is that disabling shell doesn't actually disable shell and thus is a useless feature and giving users the wrong impression that they are disabling shell access when in fact they aren't? If so, this is very bad system design and very bad business practice as this is a feature relating to security of user's system. Might want to think about either updating that functionality or providing more documentation/warnings that disabling shell doesn't actually disable all shell access for the user.
Hello @James Bowlin, Disabling shell access on an account does prevent direct shell access as that account's username, but some services may still make use of the jailed shell environment. This is explained in more detail on the following document: VirtFS - Jailed Shell - Version 76 Documentation - cPanel Documentation Let me know if you have any questions about how this works. Thank you.0 -
What I am instead finding is the same "attitude" as no explanation can be made simple and a request for more information just gets me pointed and an equally cryptic user manual for the open source project that was incorporated into cPanel. For all of their greatness all cPanel seem to have done is produce a cryptic user interface that ties together freely available software.
Hi @Thunderchild, I'm happy to help provide you with more information, or point you in the right direction. Is there a specific request or topic you'd like help with? Thank you.0 -
Thank you for the information in this post. I would like to extent the question a bit further. If SSH (port 22) is closed (say in CSF/LFD) to all but known/defined IP addresses, is this security advisory still a concern and is it still recommended? Thanks! 0 -
If SSH (port 22) is closed (say in CSF/LFD) to all but known/defined IP addresses, is this security advisory still a concern and is it still recommended?
Hello @FreedomNet, Disabling SSH access or blocking the SSH port does not address the security concern noted in the warning. Thank you.0
Please sign in to leave a comment.
Comments
35 comments