When you think about a virtual switch, do you envision a black or dark-blue box that consumes 1U or 2U at the top of server racks? That ever-present device from Cisco, 3Com or Juniper creates the networking fabric within which your IT infrastructure communicates. Built into its network hardware is a mature Internetwork Operating System that enables the complex routing, switching and access control that users have come to expect from production networks.

Yet any vision of a virtual switch that exactly mirrors a physical one is only fantasy with today’s technology. The virtual switches within virtualization platforms such Microsoft’s Hyper-V might resemble their real-world counterparts, but virtual switches today provide only a subset of the capabilities of physical servers.

That lack of functionality can be a problem for organizations that make assumptions about virtual network security. Simply put, virtual networks are not physical networks, and they need special attention to be secured properly. First and foremost, Hyper-V’s virtual switches are "Learning Layer 2" devices, which means they route their packets based on Media Access Control addresses. It also means that Hyper-V’s switches don’t understand and can’t process the more-advanced IP-based routing and access-control features commonly found in today’s Layer 3 switches. In essence, an access control list (ACL) can’t be applied to an internal Hyper-V virtual switch using current technology.

Hyper-V’s virtual switches are also limited because they lack support for third-party monitoring and enforcement of virtual network traffic. Once traffic leaves a physical network and enters Hyper-V’s internal virtual realm, it disappears from any external intrusion prevention or detection systems.

Thus, a Hyper-V networking environment requires a few workarounds to duplicate the high levels of security found in some physical servers. First, network ACLs that restrict traffic to Hyper-V hosts will need to be designed with the recognition that they’ll be limited to the boundary of the physical network infrastructure. Conversations between individual virtual machines (VMs) on the same host won’t respect those network-based ACLs. Each virtual machine will need its own installation of an operating system-level firewall and intrusion-detection software if those components are required by your security policy.

Microsoft’s guidance for Hyper-V security also strongly recommends that a dedicated network adapter be used for connecting the host’s primary partition (its "management OS") to the network. This protects the primary partition’s OS from traffic that is sent along the interface used by virtual machines. From a security perspective, virtual machine traffic is always considered to be at a lower trust level than the primary partition because protecting the primary partition is critical to ensuring that VMs stay operational. Environments with very high security requirements may consider restricting primary partition management traffic not only to its own network interface but also to its own protected subnet.

Microsoft has strengthened security in Windows Server 2008 R2 with the introduction of a new setting in virtual switch management. In R2, the Hyper-V Virtual Network Manager includes a new check box marked "Allow management operating system to share this network adapter." This check box further ensures that management OS traffic is isolated from virtual machine traffic. By leaving this check box blank, created virtual networks are not exposed to the primary partition.

Environments that need high availability with Hyper-V will also require some form of shared storage between cluster nodes. For many, this involves implementing an iSCSI-based storage-area network for the storage of Hyper-V VMs. It is a best practice to always separate iSCSI network traffic from production network traffic. At the same time, iSCSI traffic should generally be placed into its own subnet to prevent denial-of-service conditions during periods of overuse as well as to further isolate the different types of traffic from each other.

Many people seek to improve system-availability metrics through network interface teaming. To that end, Microsoft itself does not support the teaming of interfaces for high availability. This has often been panned in the media as a major limitation in Hyper-V for production environments. However, note that Microsoft has never supported interface teaming — even in physical environments. Notwithstanding, vendors such as Dell and Hewlett-Packard have for years developed their own set of teaming drivers, many of which will function in a Hyper-V environment. Obviously, you’ll need to verify the level of support that the OEM for such drivers will provide.

In short, the move to virtualization atop Hyper-V is much easier when there are plenty of network interfaces on Hyper-V hosts. It is not unheard-of to see Hyper-V hosts with up to 10 network interfaces as organizations use dual four-port network cards in addition to the typical dual network interfaces built into today’s server motherboards. Having this many network interfaces ensures that enough are available for redundant production networking, storage and management, as well as a few left over for any "interesting" network configurations that may be needed down the road.

Networking can be a hidden danger, but there’s a danger too in how your virtual machines colocate atop Hyper-V hosts. Particularly problematic in clustered environments where VMs can live migrate around for failover and load balancing, VM colocation can be a security as well as a compliance problem or your IT environment.

Tags: Hyper-V, Security