cPanel Security Advisor

[popeye]

Hi my server as just updated to the new WHM 11.40.0 and i have CENTOS 6.4 STANDARD Installed, but when i check the cPanel Security Advisor i get these messages below and before i change anything i need to know if it will break any customers accounts ? and just wanted to know if anyone could give me some info on them please.


Apache vhosts are not segmented or chroot()ed.
Enable “Jail Apache” in the “Tweak Settings” area, and change users to jailshell in the “Manage Shell Access” area. Consider a more robust solution by using “CageFS on CloudLinux”


Frontpage is installed
Rebuild using “EasyApache” without Frontpage selected, then uninstall the Frontpage RPM (rpm -e frontpage)


Trivially weak passwords are permitted.
Configure Password Strength requirements in the “Password Strength Configuration” area


SSH password authentication is enabled.
Disable SSH password authentication in the “SSH Password Authorization Tweak” area


SSH direct root logins are permitted.
Manually edit /etc/ssh/sshd_config and change PermitRootLogin to “no”, then restart SSH in the “Restart SSH” area


Apache is not being queried to determine the actual sender when mail originates from the “nobody” pseudo-user.
Enable “Query Apache server status to determine the sender of email sent from processes running as nobody” in the “Exim Configuration Manager” area's “Basic Editor”



EasyApache3 has updates available.
EasyApache3 needs to be run periodically to update Apache, PHP and other public server functionality to the latest versions. Updates to EasyApache3 often fix security vulnernabilities in this software.


Users running outside of the jail: web and ukwe.
Change these users to jailshell or noshell in the “Manage Shell Access” area.

 

[MikeDVB]

All of the information presented seems fairly straight-forward. Perhaps if you explain what about it you don't understand?

That said - if you don't understand any of this you may want to look into hiring a competent server administrator.

 

[popeye]

All of the information presented seems fairly straight-forward. Perhaps if you explain what about it you don't understand?

That said - if you don't understand any of this you may want to look into hiring a competent server administrator.

This is my first unmanaged server and still learning loads, no point me hiring a server admin because i would never learn it all if i did.

 

[MikeDVB]

This is my first unmanaged server and still learning loads, no point me hiring a server admin because i would never learn it all if i did.

Sure you can - I started out with managed servers back in 2007 and just made sure to do two things:
1. Try to fix it myself before asking for help.
2. If I ask for help - ask them how they fixed it so that I knew for future reference.

I wouldn't go to an unmanaged server to learn - I'd go to a managed server to learn so I have the safety-net of support if I'm not able to sort it myself.

 

[popeye]

Yes i did start with managed servers, and still have some but they don't give root access so cant look at much, this is why i got my own server to learn more, and what you say about try to fix it your self is not really a good idea when if it all goes wrong my customers sites go offline ?

If you cant or wont help then please don't reply to my post.

 

[MikeDVB]

what you say about try to fix it your self is not really a good idea when if it all goes wrong my customers sites go offline ?

Is this not what you're trying to do right now? You're trying to secure the server without the assistance of an administrator [i.e. on your own] and you're posting on a public forum for help.

Not faulting you - just saying - you may want to hire an actual admin to do the work and learn as they do the work. If they aren't willing to tell you how they fixed it - well they work for you - hire a different one .

If you cant or wont help then please don't reply to my post.

I'm happy to help but what you're asking about seems to be purely common-sense from a server management standpoint. Ultimately they're all optional and you have to make the decision as to whether you want to make a change or not.

Apache vhosts are not segmented or chroot()ed.
Enable “Jail Apache” in the “Tweak Settings” area, and change users to jailshell in the “Manage Shell Access” area. Consider a more robust solution by using “CageFS on CloudLinux”

This is just additional security - not 'required' but not a bad idea either. I know we run CloudLinux+CageFS but it's not necessary.

At the end of the day - it's up to you.

Frontpage is installed
Rebuild using “EasyApache” without Frontpage selected, then uninstall the Frontpage RPM (rpm -e frontpage)

Do you have users that need Frontpage? Only you would know this - if not - then disable it. If you do have users that need it - then it's up to you whether you keep it enabled or not.

At the end of the day - this is a decision you will have to make.

Trivially weak passwords are permitted.
Configure Password Strength requirements in the “Password Strength Configuration” area

Do you want people to be able to create trivially weak passwords or not? Yes? Then leave it as-is. No? Then disable it.

At the end of the day - this is another decision you will have to make. It's your server and your clients - and your decision.

SSH password authentication is enabled.
Disable SSH password authentication in the “SSH Password Authorization Tweak” area

Do you wish to force people to authenticate with SSH keys? Do you have customers that use/need SSH? How do you wish to log into the server for SSH - with a key or a password?

Key-based authentication is more secure so long as nobody gets your key and it's associated password - but it's more of a pain in the butt. It is up to you do you favor convenience or security?

At the end of the day - this is a policy decision that's up to you. Choosing one way or another may or may not cause inconveniences for your customers but only you would know if they're using SSH or not.

SSH direct root logins are permitted.
Manually edit /etc/ssh/sshd_config and change PermitRootLogin to “no”, then restart SSH in the “Restart SSH” area

This is similar to the one above about password authentication - except that it would prevent logging into SSH as root. You would need to create another user that you could sudo to root I imagine. If you don't know how to do this - you'll probably want to leave this disabled but if you do know how - it's a good security practice.

At the end of the day - you'll have to determine if you have the skill to set up an alternative user that can sudo to root and if you should disable direct root log-in or not. Again - convenience or security? Your decision and nobody else's.

Apache is not being queried to determine the actual sender when mail originates from the “nobody” pseudo-user.
Enable “Query Apache server status to determine the sender of email sent from processes running as nobody” in the “Exim Configuration Manager” area's “Basic Editor”

Are you running suPHP? If so - this probably isn't necessary - if not - then you'll want this on unless you don't mind not being able to track spam back to it's sender.

Even if you're running suPHP it shouldn't hurt to have this on - but it can create additional server load in some situations I imagine.

EasyApache3 has updates available.
EasyApache3 needs to be run periodically to update Apache, PHP and other public server functionality to the latest versions. Updates to EasyApache3 often fix security vulnernabilities in this software.

This is entirely up to you - do you want to run the latest Apache and PHP or do you need older versions for script compatibility?

You could install PHP 5.5 or you could stick with 5.2, 5.3, or 5.4. Do you want Apache 2.4? 2.2? 2.0? It's entirely up to you. There are benefits and downsides to each choice - but you need to make the decision based upon your needs and the needs of your clients and not based upon what somebody on a web forum suggests IMHO.

Users running outside of the jail: web and ukwe.
Change these users to jailshell or noshell in the “Manage Shell Access” area.

Are these users supposed to have regular shell? If so - nothing to worry about. If not? Then simply change them off of regular shell. Only you would know whether these were supposed to have regular SSH or not.

I've done my best to address your concerns but as you can see, it really comes down to what you want and you have the discretion.

 

[popeye]

Hi Michael

Yes that's great and just what i wanted to know thank you very much for all the information and sorry if i got a bit funny

Its just that i try to help anyone if i can.

PS what is common sense to you is not to me because i don't know loads about servers yet.

 

[Infopro]

PS what is common sense to you is not to me because i don't know loads about servers yet.

And that's why having the new cPanel Security Adviser there to help point these things out, is a good thing.

Thanks, cPanel!

 

[popeye]

And that's why having the new cPanel Security Adviser there to help point these things out, is a good thing.

Thanks, cPanel!

Yes it is good but not sure why they have to be in red ? i thought red meant its got to be done as its urgent,

 

[Infopro]

It does, you should.

 

[popeye]

It does, you should.

But some things i don't want to update like PHP Version

 

[Infopro]

Then don't, as Mike suggested in his detailed responses above. But it'll still show in red, and won't be ignored by cPSA.

 

[kitchin]

I had about the same warnings and some were mysterious. Much of the advice concerns stuff you'd have to do outside of WHM. Here are my notes to add to what MikeDVB said.

Apache vhosts are not segmented or chroot()ed.
Enable “Jail Apache” in the “Tweak Settings” area, and change users to jailshell in the “Manage Shell Access” area. Consider a more robust solution by using “CageFS on CloudLinux”

This one links to an experimental feature in Tweak, to enable mod_ruid2. If you read cPanel's notes on the mod_ruid2 module, you'll see it's not a simple matter, involves the PHP handler and other stuff. It does look like a step forward though. The alternative mentioned, CloudLinux, means replacing the operating system!

SSH password authentication is enabled.
Disable SSH password authentication in the “SSH Password Authorization Tweak” area

Note, if you do this SFTP will not work without keys, and SFTP is so much better than FTP. Keys are fine, but a more practical warning would be to put SSH on an alternate port, if it is on 22. (Maybe it does check that, I wouldn't know. ) In other words, if you do this your users should probably get Pageant to manage their keys, otherwise they'll use short pass phrases, etc. It's a cascade of the perfect driving out the good.

The weird thing is you can have SFTP without shell access, but this setting affects both.

I had one you did not have:

The pseudo-user “nobody” is permitted to send email.
Enable “Prevent "nobody" from sending mail” in the “Tweak Settings” area

I guess that's OK to enable prevent, though I recall getting some kind of nobody mail from PHP once.

 

[Infopro]

The alternative mentioned, CloudLinux, means replacing the operating system!

Here are the details for this:
Converting To CloudLinux Is Easy

Switching to CloudLinux is very simple, and requires just a few steps. Reboot is needed to make sure new kernel gets loaded. You can switch live servers with existing customers without any data loss. We support cPanel, DirectAdmin, InterWorx, ISP Manager, Hosting Controller, H-Sphere, Plesk as well as custom made control panels.

 

[MikeDVB]

Yeah - converting to CloudLinux is a breeze.

 

[kitchin]

To be clear to everyone, you have to buy a license for Cloud Linux, and it has nothing to do with the cloud.

 

[jimlongo]

And please don't imply CloudLinux is easy. It might be easy for sysadmins on dedicated boxes, but not for everyone else.

 

[MikeDVB]

And please don't imply CloudLinux is easy. It might be easy for sysadmins on dedicated boxes, but not for everyone else.

You would need a dedicated server or, at least, full virtualization to run CloudLinux - i.e. it won't work for OpenVZ or any other form of paravirtualization where you can't install your own kernel.

That said - CloudLinux is just an alternative kernel with some additional options - namely how many CPU cores to apply to each user, how much overall CPU to allow, I/O limits, etc. It's plenty easy so long as you have at least a modicum of experience and some common sense.

If you consider CloudLinux complex I wouldn't advise having an unmanaged server [even without CloudLinux].

tl;dr If you are not comfortable managing a server with CloudLinux you are not comfortable managing a server.

 

[quizknows]

I agree with mike.

Cloudlinux is much easier, safer, and more compatible than mod_ruid2

In my opinion, I really wish the vhosts not being jailed didn't show up as a red issue in the security advisor. Yes, I know it's a big security concern, especially if you're not using symlink race condition protection, but unless people switch to cloudlinux they're just going to break things trying mod_ruid2 until they get fed up enough to revert to their old setup.

 

[jimlongo]

tl;dr If you are not comfortable managing a server with CloudLinux you are not comfortable managing a server.

Yeah, what I meant to say was it's not easy to install for those of us without dedicated boxes. Many(if not most) VPS providers won't support it, so you can't just install it.