Cloudtidings.com

The Hyper-V management tools are available separately to allow remote management of a server running Hyper-V. Packages are available to install the tools on Windows Vista with Service Pack 1 (SP1) and on 32-bit editions of Windows Server 2008. The following download packages are available:

· For 64-bit editions of Windows Vista with SP1, see http://go.microsoft.com/fwlink/?LinkId=123540.

· For 32-bit editions of Windows Vista with SP1, see http://go.microsoft.com/fwlink/?LinkId=123541.

· For 32-bit editions of Windows Server 2008, see http://go.microsoft.com/fwlink/?LinkId=123542.

Important

The remote management tools update package for the 32-bit editions of Windows Server 2008 is a permanent package. Once you install the update package, you cannot remove it.

For instructions about installing the tools, see Install and Configure Hyper-V Tools for Remote Administration.

As you plan your backup strategy, consider the compatibility between the storage and backup solutions:

·      Virtual hard disks. These offer the best compatibility and can be stored on many types of physical media. For more information about the types of storage you can use with Hyper-V, see Hardware Considerations.

·      Physical disks that are directly attached to a virtual machine. These disks cannot be backed up by the Hyper-V VSS writer. As a result, this type of disk will not be included in any backup performed by a backup program that uses the Hyper-V VSS writer. In this situation, you would need to use some other process to back up the physical disk, such as running a backup application within the guest operating system.

·      iSCSI-based storage. This storage is supported for backup by the Hyper-V VSS writer when the storage is connected through the management operating system and the storage is used for virtual hard disks.

·      Storage accessed from a virtual machine by using an Internet SCSI (iSCSI) initiator within the guest operating system. This storage will not be included in a backup of the physical computer. In this scenario, you must use another process to back up the data from the iSCSI-based storage before you perform a full server backup. For example, you could run a backup of the data on the iSCSI storage from a backup application running in the guest operating system.

For more information about deploying storage for Hyper-V, see Implementing Disks and Storage.

Supported Virtual Environments

Microsoft ISA Server and Forefront TMG are supported on hardware virtualization in accordance with the following programs:

• Microsoft Support Lifecycle
• Microsoft ISA Server system requirements
• Forefront TMG system requirements
• Microsoft Server Virtualization Validation Program (SVVP)
• Support Policy for Microsoft software running on non-Microsoft hardware virtualization software

The option showing on the figure offers the highest network security possible without the addition of IPsec or other network-layer security mechanisms, such as 802.1x. The Child partitions are assigned a virtual network which is completely separate from the virtual network assigned to the Parent partition. Overall performance of the virtual deployment is still dependent on the performance offered by the ISA / TMG server itself.

Deployment Planning

The primary deployment criteria for any edge protection deployment must be security, stability and performance. Defining the priority of each of these is a task that has to incorporate deep analysis of the organization’s line-of-business (LOB) application requirements, general and network security needs as well as any regulatory compliance. Although it is not possible to address all possible scenarios, this whitepaper will outline the critical points for the most common deployments.

Best Practices:

1. Where possible, pass traffic through a Child partition running ISA Server or Forefront TMG. This will help you control traffic between networks and detect attacks from local and remote hosts, virtual and physical

2. Avoid the use of “allow all” rules. If your application vendor cannot clearly define the traffic profile for you, some time spent with your favorite network capture tool can be of use.

3. Restrict RPC and DCOM to specific ports. By default, RPC and DCOM will use whatever ephemeral ports are available when the related server application starts up and request connections or sockets. By limiting the range of ports available to them, you can also limit your acceptable traffic profile

Application security

You should avoid mixing virtual applications or servers of differing security contexts within a single Parent partition; especially when one or more of them face the network edge. Protecting your Exchange server becomes much more difficult when the adjacent Child partitions or (worse yet) the Parent partition is hosting a game server. This is another place where ISA or TMG can offer protection between hosts. Because Child partitions on separate parents are effectively on separate networks, you can potentially use ISA or TMG to isolate those applications and achieve greater overall security than if they were deployed on dedicated hardware.

Best Practices:

1. Install Windows Server 2008 Core on the parent. This limits the attack surface and patching requirements to the bare minimum. Since Windows 2008 Core does not support applications which rely on Windows UI mechanisms, this will help prevent installation of non-essential applications on the Parent partition

2. Each Child partition on a specific Parent partition should be of near-identical security. For instance, the Exchange and SharePoint Child partitions that user access from the Internet should meet the same security and access requirements as much as possible. You cannot satisfy this if you deploy your Exchange and SharePoint servers and game servers as Child partitions on the same Parent partition.

3. The Parent partition must be up-to-date on patches. A vulnerability of the parent translates to a potential vulnerability on each and every guest it hosts.

4. Each Child partition must be up to date on patches. While an unpatched Child partition not generally as threatening as an unpatched Parent partition, if a compromised Child partition has access to the Parent partition, it may be able to mount an attack on the parent and thus poses a potential threat to all guests; regardless of their vulnerability to that particular threat or their network proximity to the compromised Child partition.

5. DO NOT use the Parent partition as a workstation. The fewer applications that are installed and running on the parent, the smaller the attack surface it presents. If you install Windows Server 2008 Core on the parent, this threat is much better mitigated.

6. Restrict access and management of the parent partition. As detailed later, the accounts with management access to the Parent partition effectively have full control over any and all Child partitions.

7. Use a TPM-based parent partition with BitLocker. The deeper you can enforce access controls to the Parent partition, the better protection you afford the Child partitions.

Network security

Of particular interest in the virtual environment is the question of managing traffic flow for the Child partitions, Parent partition and the physical network. If a guest has direct access to any physical network, it potentially presents a greater threat to its sibling Child partitions and Parent partition than if it were forced to pass through a traffic control such as an ISA Server or Forefront TMG. While defining a network which imposes such traffic controls is a critical part of the network design, management control of this network is even more critical.

Routing traffic around an ISA or TMG server presents a state where it is not able to provide any security for the network whatsoever simply by virtue of having been effectively removed from the traffic path. While this case seems to be no different than a mis-patched network cable in the data center, you must consider that there will be no obvious visual indicators for misrouted virtual networking as there might be with a network cable plugged into the wrong port on a physical patch panel or switch. This point will make identifying these problems correspondingly more difficult and time consuming, effectively making problem resolution that much more costly. The best way to prevent such occurrences is to define and enforce very clear data center change control policies and system monitoring / reporting systems.

Best Practices:

1. Avoid connecting the Parent partition to the Internet without additional protection. While Windows Server 2008 Filtering Platform provides a much stronger host firewall than previous Windows releases, network security best practices dictates that you should layer your network security. You can accomplish this by using an external layer-3 filtering device between the Parent connection and the Internet. ISA Server or Forefront TMG on a separate physical host works well for this purpose.

2. Avoid connecting the Parent partition to any virtual network unless absolutely necessary. Because the Parent partition is the key to keeping the Child partitions alive and well and because the Parent partition is likely to use at least one physical network, the fewer points of entry you provide to the Parent partition from a Child partition, the better. For instance, Hyper-V “Local” virtual networks are invisible to the Parent partition and so are good choices for use as isolated perimeter networks usable only by connected Child partitions.

3. Avoid sharing the same Internet virtual switch connection between multiple guests. You cannot ensure traffic security for your network if your game server Child partition is sharing the Internet connection with the ISA / TMG Child partition. Better that any Child partition which needs Internet access should access it through the ISA / TMG Child partition.

4. Avoid combining your perimeter network segments on a single Parent partition. In any deployment, the use of perimeter networks is intended to create security boundaries between networks of differing trusts. By placing all of these machines and networks on the same Parent partition, you may inadvertently bridge these security boundaries through one or more Parent partition virtual network connections or by mis-assignment of a server to the wrong virtual network.

5. Avoid collapsing your perimeter network design to simplify the virtual network design. Your perimeter network design was created to satisfy the requirements imposed on you by multiple sources. It’s highly unlikely that if the design cannot be collapsed in hardware that it can be collapsed in virtual networks.

The Parent partition

Regardless of whether the VM deployment is edge- or internally-placed, the Parent partition is the most important and therefore the most critical machine among them. If the Parent partition is compromised or fails, all of its Child partitions are threatened.

Best Practices:

1. Use hardware that passes Windows Hardware Quality Labs as “certified for”:

· Windows Server 2008. If you expect to have server-class functionality and reliability, you cannot hope to achieve that using home-computer class system hardware or drivers. An investment in devices and related drivers that were designed and tested to experience server-class workloads will go a long way toward keeping your virtual deployments on-line under heavy loads. In particular, while it’s generally true that drivers written for Windows Vista will “work” on Windows Server 2008, the odds are that they will not stand up to the heavier workload presented by server applications or virtualization.

· Hyper-V. By limiting your choices to hardware which satisfies WHQL testing specifically targeted at Microsoft Hypervisor, you provide a better chance that your virtual deployment will behave properly. Many hardware vendors are working closely with all server virtualization vendors to validate their offerings for one or more server virtualization platforms.

2. Keep the system drivers current. The single most common cause of server network problems is the system drivers themselves; most commonly – the network drivers. When these need to work closely with other high-performing drivers such as those found in today’s virtualization solutions, the performance and stability of the system drivers is even more important. While it may not always be possible especially in test environments, you should consider limiting your production deployments to signed drivers only.

3. Use Windows Server 2008 Core for the Parent partition. This provides the smallest possible attack surface of any Windows Server deployment option, while simultaneously restricting the user’s ability to weaken this security posture.

4. Disable any Externally-facing NICs for the Parent partition. After you have created an “external” virtual switch for use by Child partitions, you should disable the related virtual NIC in the parent to prevent access to the Parent from the Internet.

5. If you cannot disable “external” virtual switches for the Parent, unbind all L3+ protocols and enable WFP for those NICs. By unbinding protocols and settings a heavily-restrictive policy in WFP, a host that cannot communicate using a protocol on which an attack depends is not vulnerable to the attack from a network at which the protocol is unbound and filtered. In other words, “if I can’t hear you, you can’t bother me”.

6. If the previous steps cannot be employed to protect the parent, use an external layer-2+ firewall. There should be no reason to make the parent accessible to Internet-based attacks. If you find yourself considering such a deployment, you should re-evaluate your planning.

7. Use a dedicated, Out-Of-Band (OOB) network connection to provide management connectivity to the parent.

· Dedicated connection: by providing a network connection that is unrelated to any virtual network, the parent will remain available even if the virtual networking mechanisms should fail.

· OOB connection: by separating the parent management from the guest networking, you can effectively isolate the parent from the network where application-based attacks would be seen.

8. Use TPM-supported hardware and Bitlocker on Windows Server 2008 to control access to the Parent partition and protect Child partition disks and definition files from unauthorized access. Server theft is a reality that must be considered in any deployment and the ability to acquire multiple servers in a single box can only make this even more attractive to would-be thieves. By placing all of your guests on a Bitlocker-protected disk, you effectively hide your servers from would-be thieves.

Parent and Guest Connections

You must balance the requirements of your virtual networks with the security needs of the whole environment. For instance, a single virtual network for each partition connection associated with a single NIC offers better off-host network performance than does a physical connection shared by multiple partitions through a single virtual switch. If the Child partition imposes a comparatively light network requirement, then it may be a candidate for sharing a virtual network with other Child partitions.

See: http://technet.microsoft.com/en-au/library/cc891502.aspx for detailed discussion