CHAPTER OUTLINE
Server Core installation considerations
Network and domain considerations
Designing your virtual network
Monitoring and other considerations
Working in a virtualized environment does not absolve you of the responsibility of securing the virtual infrastructure. Virtual machines are no less vulnerable to malware, hacking, denial of service, and other attacks than their nonvirtual counterparts. Fortunately, apart from the usual steps taken to secure a nonvirtual infrastructure work in a virtual environment, there are additional steps that can further secure you against mishap. In this chapter, we will discuss the customary methods that are used and how to implement them in a virtual infrastructure. We will also introduce you to the new methods available to you to further secure your virtual systems, and we will offer some design considerations for your virtual network. Finally, we will discuss how to keep your systems up to date, and how monitoring your virtual networks can be accomplished.
The most efficient step you can take to secure your Hyper-V host and environment is at the beginning, by using Windows Server 2008 Server Core. Server Core installs with a minimal set of features; it does not even include a full GUI. It begins with a very small surface of attack. Because it has fewer services running at start, more of the hardware’s resources are available for the virtual machines. In addition, Server Core has fewer services installed or running at start, greatly decreasing the attack surface of the underlying OS.
Note
Not all third-party applications will install or run on Server Core edition. The .NET environment in particular is unavailable for Server Core, so anything based on it will not install. We do not recommend running any other applications in conjunction with your Management OS (that is what the virtual machines are for!), but if you choose to do so, keep this restriction in mind.
In Chapter 3, we addressed how to install the Hyper-V role, but in the Standard edition, not Core. Because Core does not have a standard GUI, you will need to perform the steps in a slightly different manner. Any command will need to be typed into the PowerShell window that displays immediately upon logon.
To begin with, patches must be manually downloaded from another machine, transferred to the Core server, and installed via the following command:
msiexec.exe <patchname>.msi
Another option is to enable Windows Update in automatic mode, with the following command:
Cscript c:\windows\system32\scregedit.wsf/au4
This will enable automatic updates at 3 a.m. If you wish to start an update check immediately, issue the wuauclt / detectnow command to do so.
With the proper patches installed, you next enable the Hyper-V role by typing the following:
Start /w ocsetup Microsoft-Hyper-V
Note that you will not be prompted with the same questions as with the GUI installation. Instead, the defaults you were presented with in Chapter 3 will be chosen, requiring additional configuration once the install has completed.
Once the Hyper-V role is installed, it is worth noting that all of the operating system instances on the physical computer are virtualized, including the one you use to manage the Hyper-V system (called the Management OS). The hardware is accessed by all of the instances through a microkernel that does not allow any third-party code to run within it. Only the Management OS can access the microkernel in any way, allowing the creation and management of additional virtual machines.
The Management OS will still be vulnerable to malware, however, so a business-class malware solution should be a vital part of your security strategy. You will be using this for your Windows-based virtual machines as well, so it will make your life much easier to use a solution that provides a central point of management and updates.
Server Core installs with the built-in firewall at maximum protection, meaning that few outbound or inbound services are enabled through it. You will need to turn on remote management, WMI, and possibly Remote Desktop services before you will be able to efficiently manage the host system. These steps are addressed in Chapter 3, where the installation of the Hyper-V role is discussed in greater detail.
Finally, you will want to ensure that updates are installed on the system on a regular basis. There are several automated systems available for this, the most common one being Windows Server Update Services, available for free from Microsoft.
When you installed Hyper-V, you were given the option of creating a management interface from one of the network cards; a step we recommend. An important step to consider is to determine if you will join the management OS to your domain or not. Because the management OS has no other function beyond managing the virtual machines it hosts, it is not necessary to join it to your domain for full Hyper-V functionality (your virtual machines, of course, will most likely still need to be, depending on their function). However, you trade off losing the significant effort you have put into automating and securing your network resources via AD and related tools for the additional security of isolating the management OS. For instance, if you do not join the management OS to your domain, you will need to configure individual local accounts, security policies, and updates by hand, instead of using the existing infrastructure already in place in your AD. We believe that the ease of management that being an AD member brings to the table offsets the disadvantages of losing the network isolation. If you do join the management OS to your domain, be sure to create a secured OU for the system to reside in, and use Group Policy to ensure that only approved groups have logon access to the Hyper-V hosts.
Hyper-V is designed to be used primarily with Windows servers and SUSE Enterprise Linux. Because these systems are presented to the network exactly as they would be if installed on physical hardware, you will want to take the typical precautions when securing them, keeping in mind their final function. With Hyper-V, it is much more feasible to have a single instance host a single function, which makes securing the instance much easier. With a single function to concern yourself with, it is much easier to restrict outbound services, for instance, to only those necessary for minimal function and the single service that virtual machine provides. The considerations discussed above when dealing with the host instance hold true with the guest instances as well, including antimalware, updates, and so forth.
There are steps you can take to further secure the virtual machine configuration files and virtual hard disk files. By default, the machine configuration files are kept in %programdata% | Microsoft | Windows | Hyper-V | directory. These files are very small, and usually the default location is acceptable. If you choose to move them, be sure that the System account and the Administrators group both have Full Control over the directory and files. Other groups should be allowed only the access required for their function, that is, the service account used for backups, and so forth. Virtual hard drive (VHD) files can vary greatly in size, as they contain the virtual machine OS and data. These are kept by default in the %users% | Public | Documents | Hyper-V| Virtual Hard Disks directory. These files you will most likely want to move, and further secure. You can supply a new location for these files in the Hyper-V manager. The rights listed in Table 9.1 will need to be applied to the directory containing the VHD files.
Note
Table 9.1 lists the default permissions on the default folder for the VHD files. Table 9.2 lists the rights that are required for running the virtual machines and their VHDs. If you were to relocate the default folders you would need to set these rights on those folders.
Windows Encrypted File System, or EFS, was a popular method in previous Microsoft virtualization strategies for encrypting the virtual drive files. With Hyper-V, this is no longer supported for VHD files.
Instead, we recommend placing these files on a separate drive from the management OS, and using Bitlocker to encrypt them, as discussed in Chapter 3. This will provide an additional layer of protection for the data within the virtual machines, with less impact on their performance than if data encryption were performed within the virtual machine. You may also wish to move any Virtual Floppy Disk (VFD) and ISO files to this location, especially if they are used to boot the virtual OS.
Syskey is a utility that can be used to encrypt Windows account data, including the SAM on Domain Controllers. On virtual machines, syskey can be challenging to enable in a fashion that actually preserves security; storing the key either on the virtual drive itself, or on a virtual boot floppy, only results in an image that can be taken elsewhere to be cracked at leisure, while a boot password can make automated management and update tools more challenging to use. In addition, a syskey-encrypted SAM is not significantly more difficult for password crackers to manage, as most of them simply obtain the necessary system files to decrypt the SAM at the same time, or use other tools to reset the Administrator password entirely. While syskey does add an additional layer of protection to your passwords, the added difficulty for management makes the trade off debatable.
Note
Your log management server or application may require SNMP to be enabled. The process for this is no different for a virtualized server than for a host-based one.
Windows Firewall is a stateful firewall that comes installed with most modern versions of Windows by default. On Windows 2008 Server machines, the firewall is enabled by default, blocking many of the ports that cause so much trouble in otherwise unprotected Windows systems. On virtual servers, the Windows Firewall ensures that only the services necessary for the chosen function are exposed (the firewall will automatically configure itself for new server roles, for instance, and when certain server applications are installed). As members of your domain, the Windows Firewall of your virtual servers can be managed remotely, or through Group Policy.
Auditing your server logs is an important way to ensure that nothing has gone awry with your systems. Windows Server 2008 supports event subscriptions, allowing you to send the log files of your virtual servers to a central location for monitoring and management.
You may find it useful, for instance, to have the event subscriptions of your virtual servers to be sent to the computer you use for managing your Hyper-V installation. The logs are also available through the typical remote management options.
Disk and file access can be audited as usual with Windows servers, as well; virtualization does not require you to change your methods there.
Virtualizing your servers does not require you to make significant changes to your auditing strategy. The ability to create separate private networks between virtual servers, however, opens up new opportunities to obtain audit data without impacting the throughput of bandwidth-intensive applications.
The introduction to Hyper-V discussed several different types of networks available to a virtual machine. These different networks give us some flexibility in designing our enterprise for security as well as performance.
Remember that when you create a virtual machine, you have the option of creating three different types of virtual networks: External, which connects a virtual machine to the physical network; Internal, which allows virtual machines on the same host to communicate with each other, and with the management OS; and Private, which only allows virtual machines on the same host to communicate with each other. What does this mean to you? Imagine for a moment a typical web store, with purchasing and item data kept on a SQL server, and the Web site itself running on IIS. In a virtual environment, you might set it up similar to Figure 9.1.
By using a combination of private and external networks, you are able to create a site that is much more resistant to attack, by removing the database server from the external network entirely, allowing it to communicate only with the IIS server.
However, the ability to isolate key functions of your network also creates challenges when it comes to monitoring and maintaining the virtual systems. Systems that do not have an external private network, of course, cannot communicate with your physical network; indeed, unless the virtual machine is part of an internal network, it cannot communicate with the management OS either!
You will want to take this into account when designing your virtual network. In particular, you may have monitoring solutions in place that utilize SNMP, or agent-style probes. These will need to be forwarded to your monitoring server, typically by including some sort of forwarding agent in the private network. In addition, update systems such as WSUS will be unable to communicate with the virtual machines, and enterprise antivirus solutions will be similarly affected. It may be worthwhile to consider using internal virtual networks, instead of private ones, and configure the management OS as an agent for the various monitoring and management systems you have in place. Reserve private virtual networks for those systems that require higher security, and establish a method to monitor and update them either manually, or with an agent system that is included in both the private virtual network and the external one.
FIGURE 9.1 A Virtual Web site protected by private networks.
Note
The Management OS will always be able to manage a virtual machine instance that it hosts, through the management console.
We presented an overview of security in the context of a Hyper-V virtual environment. When the Hyper-V role is installed, everything is run in an instance, including the Management OS. This does not mean that your regular duties toward security can be bypassed, however; you still need the usual updates, antimalware, and the like.
The files that are the virtual machine configuration files and VHDs can be relocated, and we presented you with the permissions needed on the folders that contain them. In addition, Bitlocker encryption can provide further security for these files when not in active use.
The three network types available to your virtual machines give you a great deal of flexibility when designing your virtual infrastructure; it is possible to create systems that protect your valuable data by preventing the database servers from communicating on the external network at all. This provides challenges when attempting to maintain and monitor these instances, however.
Chapter 10 will introduce you to the concept of the Dynamic Data Center, and how to use your virtual infrastructure to create and utilize one.
