Virtualization Security (Part 3)

Virtualized Networking

Full virtualization hypervisors can provide networking capabilities, allowing the individual guest OSs to communicate with one another while simultaneously limiting access to the external physical network. The network interfaces that the guest OSs see may be virtual, physical, or both. Typical hypervisors offer three primary forms of network access:

1. Network Bridging. The guest OS is given direct access to the host’s network interface cards (NIC) independent of the host OS.

2. Network Address Translation (NAT). The guest OS is given a virtual NIC that is connected to a simulated NAT inside the hypervisor. As in a traditional NAT, all outbound network traffic is sent through the virtual NIC to the host OS for forwarding, usually to a physical NIC on the host system.

3. Host Only Networking. The guest OS is given a virtual NIC that does not directly route to a physical NIC. In this scenario, guest OSs can be configured to communicate with one another and, potentially, with the host OS.

When a number of guest OSs exist on a single host, the hypervisor can provide a virtual network for these guest OSs. The hypervisor may implement virtual switches, hubs, and other network devices. Using a hypervisor’s networking for communications between guests on a single host has the advantage of greatly increased speed because the packets never hit physical networking devices. Internal host-only networking can be done in many ways by the hypervisor. In some systems, the internal network looks like a virtual switch. Others use virtual LAN (VLAN) standards to allow better control of how the guest systems are connected. Most hypervisors also provide internal network address and port translation (NAPT) that acts like a virtual router with NAT.

Networks that are internal to a hypervisor’s networking structure can pose an operational disadvantage, however. Many networks rely on tools that watch traffic as it flows across routers and switches; these tools cannot view traffic as it moves in a hypervisor’s network. There are some hypervisors that allow network monitoring, but this capability is generally not as robust as the tools that many organizations have come to expect for significant monitoring of physical networks. Some hypervisors provide APIs that allow a privileged VM to have full visibility to the network traffic. Unfortunately, these APIs may also provide additional ways for attackers to attempt to monitor network communications. Another concern with network monitoring through a hypervisor is the potential for performance degradation or denial of service conditions to occur for the hypervisor because of high volumes of traffic.

The security implications of networks internal to a hypervisor should not be minimized. For example, assume that an organization has two computers, one that acts as a public-facing web server and another that is an internal database server. The organization also monitors the switch that connects the two computers, watching for traffic that would indicate an attack on the database. If both of those servers were moved onto a single hypervisor, and the hypervisor’s virtual network was used for communications between the servers for increased efficiency, the ability to monitor all the traffic between the two systems would be lost unless the hypervisor itself can perform this monitoring that meets the organization’s security policies.

To get around this loss of visibility, some organizations purposely expose network traffic between virtualized hosts to the physical network already in place in the organization. This requires the system on which the hypervisor is running to have multiple network interfaces, and this may significantly slow network communications as compared to a virtual-only network, but the advantage is that the organization does not need to change its security policies to gain the cost advantages of virtualization. Organizations should consider the tradeoffs between traffic being hidden within a hypervisor and the extra overhead and risk of exposing that traffic but being able to control it using the same tools already used for controlling other network traffic.

(Reproduced from NIST publication SP800-125)