The Network Connection

Another challenge for each virtualization host is ensuring a secure network connection for the guests. Essentially three different types of network communication occur: (1) guests communicate with other guests or the outside world, (2) administrative communication manages and controls the guests, and (3) accessing the hard disk images creates traffic to the memory back end. Admins typically separate these flows with the use of multiple physical networks. Figure 2 outlines a simple host structure with three network interfaces.

Figure 2: Schematic network connection of a host with three ports.

The problem is that the Linux kernel loves to communicate, which means that, in case of an incorrect guest configuration, the guest might be able to access the other networks rather than just the host. In an unfavorable case, this can mean, for example, that the guest can gain access to disk images belonging to other guests.

An Attack Scenario

The following example assumes that the host implements the connection as a Linux bridge. (However, similar dangers also exist with other connectivity methods, such as MacVTap [7].) The host will then use Layer 2 packet forwarding. In the simplest case, it therefore acts as a switch, routing packets between the guests themselves or between the guests and the external network interface of the guest network. The routing is usually handled by an external device; the guest learns its address via DHCP.

But what if the guest uses the host as its router? How does the host react, if it receives a packet from the guest with a target IP address belonging to a computer of the storage back end? Technically, you can reduce this to the question of whether IP forwarding is enabled on the host. You would assume it wasn't, because there's no reason to do so.

Unfortunately, it is set up automatically during the libvirt installation. If the administrator now makes the mistake of not only assigning IP addresses to the network interfaces for the management and storage network, but also to the network interface on the guest network, the barn door is flung open. Now, the host acts like a router that generously conveys packets between the networks, if you only ask it to do so.

Routing Without an IP Address

Even if the guest network interface does not have an IP address, the guest might still manage to communicate beyond the border of the guest network, because of the IP forwarding mechanism, which may be basic in terms of design but is anything but intuitive. What does a Linux system do with a received packet that is addressed to itself in Layer 2 (MAC address), but to another system in Layer 3 (IP address)? To put it simply: If IP forwarding is enabled, Linux forwards the packet to the target system; otherwise, it drops the packet. It follows that the network interface on which a packet arrives does not need to have an IP address itself for the kernel to decide to forward the packet.

Forwarding a response packet often does not work in practice, but still, an incorrectly routed DHCP or DNS packet can cause a great deal of damage. The admin must therefore ensure that no IP address is attached to the network interface of the guest network, that IP forwarding is disabled, and that the reverse path (RP) filter is switched on.