In the last year I have seen a huge explosion in the use of virtual machine technology for critical infrastructure systems. Many of us have long used virtual machines for testing, software development, and research, but many organizations are increasingly using virtual machines for critical servers. I have seen some companies implement their entire DMZ on a single box, build scalable mail systems spread across a few vm hosts, even an ISP that uses Linux-based virtual machines for many of its backbone routers. There is also a growing number of pre-built virtual appliances becoming available.

So far we haven’t seen a lot of public exploits of vm technology, but I have been noticing some implementation problems that are a recipe for disaster. One of the most common problems is that having access to the vm host is the same as having physical access to a box, and in some cases even worse.

For years we have known about the problems of having physical access to a box. Many companies have just given up trying to secure physical access through technology and relied instead on physical locks and keys. Because once someone has physical access to your server, your box is compromised.

Fortunately, up to now, physical access hasn’t been too much of a risk outside of your own organization. You really didn’t have to worry about Ukrainian hackers breaking in to your server room and taking over your system with a simple boot disk. But vm technology changes that. Someone can now remotely gain physical access to your server by accessing the vm host server.
Having access to the vm console, to the guest OS, is identical to someone physically sitting at the server’s console. Even worse, entire disks are stored as files that one could easily be copied or mounted using one of the many tools available for mounting virtual disks.

Here’s the problem: mounting a virtual disk bypasses nearly all security controls imposed by the guest OS. You just mount the drive and you have full access to its contents. Clearly, this is a huge risk because a hacker gaining access to one server likely means that hacker will own all virtual machines hosted on that server.

Here are some basic ideas to get started securing virtual machines:

1. Place your host machines on trusted networks and don’t allow access to the host OS from the same networks the guests use. A network adaptor on the host OS does not need an IP address for the guest OS’s to work. If physical access is a big concern and you really want to lock things down, don’t give the host OS an IP address at all. If you need an IP address on the host for remote management, add a second adaptor and give it an address on another, preferably internal, network.
2. Always use tight permissions for virtual machine files. By default, most files at least allow general users read access. However, that’s all a user needs to mount a virtual disk. Remove all ACL entries and only allow access to a very specific subset of administrators who need to access the machine’s files.
3. Don’t ever leave a guest OS on the vm console unlocked. I commonly see admins closing the vm console without logging out of each guest OS. Anyone with access to the vm console also now has access to the guest OS’s. It has always been important to log out of a server when done, but with a virtual machine it is now much more important. Always use a password-protected screen saver on every guest OS.

This is only a quick treatment of what could eventually, I predict, become a huge problem, but it is enough to get people looking for solutions.

Related posts

• No related posts.