Virtualmin security hosting

Virtualmin
1

Hello,

My main question is:

Do you consider Virtualmin secure enough to share hosting for customers who blatantly don’t feel inclined to update/patch vulnerable code in their websites which would allow an attacker to access (change/delete/upload/etc) the files on the web server (most specifically within their relative ~/public_html directory).

Is Virtualmin & linux robust enough in terms of the security setup & permissions that you don’t think this is even an issue. Or would you feel more inclined to suspect that in a situation like this, eventually one customer’s hack, could wind up affecting other customers, etc.

We are considering offering customers two hosting plans:

  1. Basic - Website is on a shared Virtualmin server with other websites from various customers.
  2. High Security - Website is on a shared Virtualmin server with other websites from other customers. Each of these customers monthly fees includes paying us a fixed amount to upgrade their Joomla install (as Joomla project security & maintenance updates are released) & upgrade/disable/replace Joomla plug-ins that have known vulnerabilities.

The main idea is that for customers who want a basic stagnant website AND the cheapest hosting, they all get grouped together onto one server that we do install Debian apt-get updates onto (including as prompted by Virtualmin, but also via apt-get manually).

If these customers Joomla installs are not updated every 3-10 weeks (depending on Joomala maintenance releases), their websites will effectively have security vulnerabilities. And depending on the nature of those vulnerabilities, an attacker may be able to remotely execute code, install a back-door PHP script, etc. Once this happens, our concern is whether they would be able to take it a step further & access/change OS/daemon configuration files, install kernel modules (root kits), etc. Also a concern would be whether they’d be able to access & mess with other customers website files, etc. We currently don’t allow SSH access (from outside of our network) to our servers. But I have seen some of the PHP tools these guys put on servers to give them a web front-end to try & further infiltrate the server via PHP. It is somewhat unsettling.

Hence our idea that we keep all customers who are willing to spend the money to keep on top of security updates on 1 Virtualmin server. And everybody else goes on the other server (which we have the assumption is more likely to eventually get hacked via a customer’s vulnerable PHP code).

What are others doing to address the security concerns? I would greatly appreciate the feedback from others in this community, as well as the best-practice recommendations from the Virtualmin devs themselves.

Thanks,

Doug Mortensen
Impala Networks, Inc.
www.impalanetworks.com

2

A customers website was hacked one day and the hacker tried to escalate through a php script. He was unsuccessful, because we run the servers in mod_fcgi and have several security measures in place.

However a server is never 100% safe. Even the biggest companies get hacked or should I say especially?
The bigger hosting companies worry would be DDOS attacks by the competitor rather than a website being defaced.

That said it is obvious that any script should be well written and kept up-to-date. Passwords should be pretty strong and changed on a regular basis.
In my opinion the provider should take care of this and a client wouldn’t have to pay extra for this neither

3

Generally speaking, Virtualmin users shouldn’t be able to harm the system, or other users, except in terms of resource usage. It may be possible for a user to DoS the server for other users, but if your system (including the kernel) is up to date, you should be pretty safe from escalation. That’s not a guarantee…but nothing short of full virtualization for every user can guarantee no escalation.

Those who claim that chroot makes you safer from this sort of escalation are probably wrong (chroot breaks some security features of some server software, and means that if the chroot gets broken, the user has access to a root-level process, which historically has made escalation more likely rather than less).

SELinux could help prevent escalation, but it also makes it very difficult to provide full-featured virtual hosting, and in our experience leads to folks doing truly stupid things like “chmod 777” on all their files to try to fix permission denied errors (SELinux errors show up in the kernel log and not on the command line). I’ve enabled SELinux on Virtualmin systems in the past that needed really strong security, and if you spend the time tweaking it to suit your particular deployment, it can be a great option. I’ve considered putting out a package of SELinux policies for hosting…but SELinux is really challenging and I fear I’d get a bunch of stuff wrong, which might just give people a false sense of security. Virtualmin does have some SELinux features, in terms of setting contexts on new files and such, but I’m pretty sure it’s not comprehensive, and you’ll need to do some of it manually. Again, SELinux is stupidly hard to figure out; I never know whether I’m doing what I think I’m doing, and about 50% of the time I find out I did it wrong after testing my changes. But, it’s also pretty difficult to overcome…off the shelf exploits will pretty much always be shut right down by SELinux.

So, if I were in your shoes and could tell who the “good” and “careless” customers were, I’d put the careless ones on a server running with SELinux enabled, and only allow a few specific applications in a few specific places. Joomla probably would not be one of the applications I would offer those users, as it historically has needed constant maintenance to remain on top of security vulnerabilities. Virtualmin Pro can auto-update Joomla instances across all virtual servers, but even with the auto-update, problems can pop up, especially if the users are customizing their Joomla core code (which happens more than you’d think).

All that said, if you follow good practices with regard to system updates (including kernels), use only strong passwords and enforce strong passwords for your users, don’t run unnecessary services (especially services you don’t pay attention to and might forget to update or restart or check the logs of), and don’t let very careless users have more privileges than they need, you should be pretty safe. There is very little different about Virtualmin from a hosting environment you’d setup manually; though, we do automate a lot of security related features (like suexec) that many self-hosters don’t go to the trouble to setup, so Virtualmin might be a bit safer than the average. There’s the potential for the administrator to have less knowledge of their underlying system, however, which can work counter to the safety of the system.