By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Best practices regarding physical servers usually dictate that the servers should be locked in a server room and BIOS-level console access should be restricted to only a few administrators. This concept is not much different when dealing with virtual machines (VMs). The host computer that is running Microsoft Virtual Server 2005 should be locked in the server room. By default, this means that the VMs running on it are locked in the server room. However, BIOS-level console access to VMs can be achieved from anywhere with a network connection to the host machine. This makes securing console access to a VM slightly more involved than locking the physical host machine in the server room. Of course, you could always choose to disconnect the Microsoft Virtual Server 2005 host machine from the network, but then the server could only be used by the systems administrator that is locked in the server room with it. Locking systems administrators in the server room is not considered best practice and we usually want other departments to be able to use our Virtual Server host machine anyway. So, we have no choice but to follow some guidelines in order to secure our virtual machines.
Securing the Microsoft Virtual Server configuration file
The VM configuration file is generally configured through the administration Website. The section of the site that you can use to manage the security of Virtual Server 2005 configuration is the "Server Properties -> Virtual Server Security" link. The configuration screen is shown in the figure below.
The VM configuration file is "options.xml" and it is located in "C:\Documents and Settings\All Users\Application Data\Microsoft\Virtual Server". The permission settings defined on this page will actually modify the discretionary access control list (DACL) entries for the parent "Virtual Server" folder. A full listing of what DACL entries that the options on the "Virtual Server Security Properties" page modify can be found in the Securing Virtual Server TechNet article.
The files under this folder will inherit the folder's permissions by default. Also, as you can see by the above figure, only members of the local administrators group on the Virtual Server Host can configure Virtual Server or virtual machine resources and networks. In order to add permissions for other users or groups, you simply click on the "add entry" button and add the appropriate user or group entries. It should also be noted that the CGI application used by the Virtual Server Administration site is VSWebApp.exe, and it is located in "Program Files\Microsoft Virtual Server\Website\VirtualServer" by default. A user must have execute permissions in that folder in order to use the "Administration Website" and the "Virtual Server Security Properties" page.
Securing the virtual machine configuration and resource files
Since virtual machines consist of a series of files, the first step in securing VMs is to secure access to the VM files. This will be accomplished through NTFS permissions.
There are several files that make up the VM: the Virtual Machine General Configuration File (Virtual machine name.vmc), the Virtual Network Configuration Files (Internal Network.vnc, External Network.vnc, and Loopback Network.vnc), and the Virtual Hard Disk File (Name.vhd). By default the local administrators group on the Virtual Server Host and the creator of the virtual machine have Full Control permissions for the General Configuration, and the Virtual Hard Disk Files and the local administrators group has Full Control permissions for the Virtual Network Configuration Files.
However, more than likely, other departments will need access to the VMs that are hosted on the Virtual Server Host. In this case it is recommended to abandon the default "C:\Documents and Settings\All Users\Documents\Shared Virtual Machines" folder structure and create a folder structure that will accommodate the separation of virtual machines by department. An example of this can be seen in the figure below.
Once separate folders are created for each department's VMs, the user who will be running the virtual machine need read, execute, and write permissions for the Virtual Machine General Configuration File and the Virtual Hard Disk File for the VM that the user is running. The Virtual Network Configuration Files can stay in the "C:\Documents and Settings\All Users\Documents\Shared Virtual Networks" location. However, in order to run a VM, the user or Virtual Machine Helper account needs read and execute permissions for the Virtual Network Configuration Files.
It is also important to know that it is possible to connect to a VM using the Virtual Machine Remote Control (VMRC.exe) client. If you are using vmrc.exe behind a firewall to connect to a VM in a domain environment, there are several ports that need to be opened. Port 5900 is for the VMRC server. Port 1024 is for the Administration Website. Ports 137 and 138 are for the Kerberos V5 Ticket Granting Authority.
The VMRC client also allows multiple users to connect to a VM at the same time and view the remote connection. While this may be desirable in a lab, this functionality may not be wanted in a production environment. In this case, it might be best to use Terminal Service (i.e. Remote Desktop) to connect to the VM if it has this functionality. Otherwise, you should remove the Traverse Folder/Execute permissions from the Virtual Machine Configuration and Resource Files.
The next article in this series tells you how to secure remote access to the host.
About the author: Harley Stagner has been an IT professional for almost eight years. He has a wide range of knowledge in many areas of the IT field, including network design and administration, scripting and troubleshooting. Of particular interest to Harley is virtualization technology. He was the technical editor for Chris Wolf and Erick M. Halter's book Virtualization: From Desktop to the Enterprise and currently writes his own blog at www.harleystagner.com.