Ben Armstrong (MS virtualisation whiz, The Virtual PC Guy) blogged overnight about a tool that allows administrators or developers to get at and analyse the contents of RAM in a saved state Hyper-V VM. The tool is called VM2DMP. It will convert a Hyper-V saved state memory to a DMP file that DMP analysis tools can load up.
This brings up a question: security. Lets forget about TV shows like 24 and movies like the Net. That stuff can be fun. Sit back and think: what is the easiest way to gain access to some piece of data or files? The answer is simple. Gain physical access and literally steal the disks.
If I had access to a saved state VM then in theory (if I had the skills) I could use that tool to convert the memory, poke around and gain access to sensitive items that were stored in RAM.
Virtualisation makes this even easier. You don’t have to remove the disks because they’re files. Gain access to the host and away you go. I remember when I started working on server virtualisation and having a chat with my cousin who is a senior security consultant with a major international company. His previous role had him working in a lab and projects were to think up scenarios and find threats. So he asked me: “how do you secure VM’s when they are only files?”.
It’s possible. But you’ve got to do all the right things.
Security starts and ends with physical access. Control access to the computer room(s) and monitor that access. Be very strict about it. The data centre I work in doesn’t care if they see you every day. If you are not expected or not properly processed then you don’t get past the front door. It sounds inflexible and it is. But damn is that place secure!
Hyper-V run on Windows Server 2008 and Windows Server 2008 R2. You have the option of enabling BitLocker on the host. That’ll work on standalone hosts but not on a cluster.
Maintain control of who can log into the host. You’ve got to treat host logon permissions the same way as you would treat computer room access. That logon prompt and those drive access rights must be at least as important as access through the door. If you can log into a host or gain access to drives remotely then the door is wide open to play.
There is no need to give access (administrative or interactive logon) to a host beyond the virtualisation team. Rights can be delegated. The ideal solution for that is VMM. You can allow delegated administrators to do admin work via the VMM console. Members of self-service roles can use the portal to deploy and manage VM’s. If you don’t have VMM then you can use the Hyper-V authorisation manager to delegate access.
And yes, you can enable and RDP into a VM.
Most of this stuff goes back to the basics of what you should be doing already. Membership of domain admins should be very limited. Nested groups and local group population via Group Policy (restricted groups) allows delegation. Give only the access that is required. Treat physical access like getting into somewhere like the NSA. Use the right tools for the right reasons and don’t be lazy. And the stuff I’m talking about here is not unique to Hyper-V. You need to take precautions with all hardware virtualisation solutions.
The tool that Ben blogged about has legitimate uses; just be sure that only the right people get to use it on your Hyper-V hosts.