Windows Server 2012 Hyper-V Security Features

Network Virtualization gateways come in different form factors. They can be built on a VPN gateway that creates a VPN connection to link two virtualized networks across a physical network. For this purpose, you can use a Server 2012 server that's running RRAS. Network Virtualization gateway functionality can also be provided by a dedicated networking device (e.g., a switch, a network appliance) that acts as a routing gateway for Network Virtualization. At the time of this writing, Network Virtualization gateway appliances are provided or being planned by F5 Networks and nAppliance Networks. To configure the Network Virtualization gateways, you can use PowerShell. To get started, see the sample script in the Microsoft article "Simple Hyper-V Network Virtualization Script with Gateway."

Luckily, VMM SP1 also includes extensions to centrally and automatically manage Network Virtualization Gateway policies. When a VM is created or updated, VMM can automatically update the routing topology of each Network Virtualization gateway device. For more information about Network Virtualization gateways, see the Microsoft article "Hyper-V Network Virtualization Gateway Architectural Guide."

For much more information about Network Virtualization in general, see the Microsoft article "Microsoft Windows Server 2012 Hyper-V Network Virtualization Survival Guide." A nice summary of the steps that you must follow to set up Network Virtualization is also available in the Microsoft TechNet blog post "Step-by-Step: Hyper-V Network Virtualization."

Extensible Virtual Switch

In Hyper-V 3.0, Microsoft also made significant changes to its virtual switch architecture—now referred to as the extensible switch. This Layer 2 virtual network switch can be configured on each Hyper-V host and is at the intersection of network traffic between VMs, between VMs and the Hyper-V host, and with external machines. The extensible switch is the Hyper-V component that enforces Network Virtualization policies and includes other interesting, security-related features.

Microsoft partners can build extensible switch extensions that use the Windows Filtering Platform (WFP) or Windows network device interface specification (NDIS) filters to monitor or modify network packets, authorize connections, or filter traffic. Thanks to this new architecture, the extensible switch can enforce security and isolation policies when connecting VMs to the network. A virtual switch is the ideal place to scan the inter-VM traffic on a host for malware. Classic malware and intrusion prevention solutions typically cannot scan this traffic and can examine only physical host-to-host traffic. A few Microsoft partners that have already jumped on the extensible-switch bandwagon are sFlow, which provides a monitoring extension; 5nine, which provides a virtual firewall extension; and NEC, which provides an OpenFlow-based monitoring extension. OpenFlow is an important open-source protocol for SDN.

The new extensible switch also supports the definition of PVLANs. Administrators can create PVLANs by assigning a VM to a primary VLAN and then to one or more secondary VLANs. Using these PVLANs, administrators can ensure that VMs either can communicate only with VMs with the same VLAN ID or IDs or can communicate with any other VM with the same primary VLAN ID, regardless of secondary VLAN ID. As I pointed out earlier, PVLANs don't counter the complexity of VLAN management across virtual and physical networking devices. These problems can be addressed only through the use of Network Virtualization.

Another powerful extensible switch feature is the ACL-based isolation policies that can be defined and enforced on the extensible switch virtual ports. These policies are basically lists of Allow and Deny rules that ensure that VMs are isolated and can't communicate with other VMs based on their IP or MAC addresses. These extensible switch isolation policies can also be defined from VMM.

Finally, the extensible switch supports new security features such as DHCP Guard, IPsec Task Offload, and protection against Address Resolution Protocol (ARP) poisoning. DHCP Guard can be used to prevent VMs from acting as a DHCP server. DHCP Guard works by dropping any packets that a VM attempts to send that would indicate that it's a DHCP server. DHCP Guard is a property that can be configured for each VM network adapter. You can do so from the Hyper-V Manager, in the Advanced Features section of the network adapter settings in the VM properties, as Figure 2 shows. I recommend that you enable this setting during the creation of your VM golden image.

Figure 2: Enabling DHCP Guard 

IPsec Task Offload allows Hyper-V to offload IPsec-related processing to a network adapter. This is possible only when the network adapter supports the feature. IPsec Task Offload can reduce the Hyper-V host-processor performance hit that's associated with the use of IPsec encryption algorithms. You can also enable this setting from Hyper-V Manager: Use the Hardware Acceleration section of the network adapter settings in the VM properties, as Figure 3 shows.

Figure 3: Enabling IPsec Task Offload