Know How - VMware

Setting up the free VMware Server is not as easy as it seems. For me. Perhaps that is, because I like to have a secured environment and VMware has a little bit weird attitude when it comes to Security. Here I write down all things I found out how to use, setup, run and perhaps make more secure VMware Server.

  1. Setting up VMware Server on Debian
  2. Securing VMware Server
  3. Managing VMware Server via WWW
  4. VMware Server via vmrun
  5. PXE boot of a guest of VMware server
  6. vmware-mount
  7. Trouble

Notes

Environment

  • The environment is Linux, mostly Debian and derivates.
  • Also it is assumed that the VMware server is installed on a "root server" like you can get cheaply from all major ISPs around the world.
  • This also means, that you have full control over the host, but nothing else (like the network).
  • You cannot use private IP range for the outside interface (one of my ISPs monitors the IP and MAC layer, and if some wrong IP or MAC is used, the machine is shut down immediately).

Additional things

  • Need to be able to boot VMs from the network.
  • Cannot use any network infrastructure besides which is built into the host, as it is a hosted system with no control over the main backbone.
  • I am not affiliated with VMware besides that I am a paying customer of VMware Workstation (Windows) and user of the free products of VMware Player (Windows) and VMware Server (Linux).
  • VMware, VMware Server, VMware Client, etc. are all trademarks of VMware Inc. (I think. I do not own nor know anything about trademarks, also Bamboo lacks a Trademark-Method to mark trademarks properly, sorry.)

Notes about security

  • Security is crucial. This means, a product to be considered secure must come with a secure setup in the default install. VMware server is lacking such a secure setup and therefor cannot be considered a secure application. Therefor running VMware server renders your machine insecure. Period.
  • Security means to hardened things against typical forms of attacks. To harden something means in the first place, hide anything except the pure services for others from observers. Having open ports listening on all interfaces is the direct opposite of such a strategy. As VMware Server does open zillions of administratively used ports on all your interfaces it becomes very difficult to secure such a setup.
  • Requirements like needing a firewall to secure things is bad or even contra productive. Firewalls are no solution to security issues. If your system becomes insecure without firewall, you know you have a bad security design (Intranets usually are a nightmare from a security perspective). Firewalls are only helpful to prevent a common class of attacks, and they are good to have a single point, where you can stop all traffic to the outside. However on a hosted server stopping connections from the outside means to isolate the machine. Therefor you are unable to manage the machine, as you, the admin, sit on the outside.
  • Getting past a firewall is a common strategy, as firewalls only work on the outside and do not prevent attacks from the inside. A hacked VM is a common situation, therefor you must assume, that an attacker comes from the inside and already is past any firewall. This also means, using firewall rules from the Linux kernel are no solution for a bad security design as VMware server shows.

How I would like to see security (one example)

There should be a way to restrict vmWare Server to listen to only one interface (usually 127.0.0.1 per default).

This way, to secure a server in a multi user environment, would mean, to configure some (possible for normal users hidden) networking interface which the server listens on, which than can be tunnelled to.

Perhaps this is possible, but I did not find a way to get this done. However note that this is an advantage of vmWare-Server, as you are able to fully control all "open port" aspects of the server. With something like ESXi I did not find a way to close the ports.

Again to stress it: Firewalling, like restricting IPs which are allowed to contact a port, are no good solution. As then you need some other fixed IP to work from. What happens if this IP is gone? Have a second IP! And if this second IP is gone as well? Have a third IP! And if this gone as well?

In weird situations you simply cannot predict what happens, so there must not be any restriction. When the power outage struck Germany (and half Europe), 5 of 6 datacenters I am working with went down, too. The servers stayed up, but connectivity was lost. If you now want to manage your server in this remaining datacenter but need IPs from any of your other datacenters, you are locked out.

Yes, this are exceptional situations. However a good security strategy must only hinder you min while it hinders everybody else max. Firewalling usually is the worst choice in this respect.

With vmWare Server I can even use "Port knocking", that is, implement my own port knocking script to open a port in case I need it. This is independently working in any situation, such that I am not hinderered. How to do this out of the box with a product, which has a closed OS which cannot be scripted as you like it? That's a major burden for me to use something else.

And besides, the performance loss of vmWare-Server compared with other methods is minimal. Performance tuning is not about the last 10%, it is about keeping more than 50% free resources to be able to handle the peak load. Therefore if vmWare-Server gets too slow, the right answer probably is to use dedicated hardware. At least in my case.

If you are a big datacenter offering virtual appliances to zillion different uses your mileage may vary. But I am "only" an admin running a little bit more than 10 servers which are consolidated partially into VMs.

-Tino, 2008-09-04, Updated 2010-02-19