Secure Virtual Networks
Joern shows how to design a virtual infrastructure with security in mind.
Last year I wrote about general security issues to keep in mind when moving parts of your IT infrastructure to virtual machines ("Virtual Security
," August 2008). Here are additional pointers for networking these virtual machines (VMs) securely.
A typical virtualization project starts with converting a physical server or two, but soon afterward your network is bound to contain several servers running VMware, Hyper-V or another virtualization solution, with each solution hosting multiple VMs. All of these VMs need to communicate with each other, and if you don't configure the networking with security in mind, you're bound to introduce vulnerabilities that can be difficult to eliminate. To avoid this, you should design your virtual infrastructure with security in mind.
In some ways a network infrastructure that includes VMs is not all that different from a purely physical network infrastructure. Sure, virtual switches won't let you easily see which cables are plugged into which port. Also, you can't simply unplug a cable when you need to remove a computer from the network, but you can still use virtual switches to connect computers and to separate network segments. Most virtualization software programs even let you create VLANs. However, these switches may also connect VMs with the host computer, and this can create unique vulnerabilities. Also, VMs and the host share hardware resources, which can make denial-of-service (DOS) attacks more problematic.
As you're placing VMs on hosts, think carefully about which roles these computers are performing. All computers on a single host should have similar security requirements. For example, a DOS attack against your Web server can prevent access to your Web site, which is bad enough. If this server runs on the same physical server as your domain controller (DC) and shares resources with it, the attack may also bring your internal network to a screeching halt. You would be better off keeping the Web server and the DC completely separate.
One common mistake in designing a virtual network is to combine servers that were previously located on separate network segments onto the same host. If you currently segment your network and place Internet-facing servers into a demilitarized zone (DMZ), don't try to save hardware resources by combining the Exchange Edge Transport server from the DMZ with the Mailbox server from your internal network on the same host. You likely had good reasons to create the DMZ in the first place, so don't ditch it for some small hardware savings.
One aspect of any virtualization implementation that makes it different from a physical data center is the underlying software that makes the virtualization possible. This may take various forms, from the specialized OS used by VMware, to the base OS partition used by Hyper-V, to the combination of OS and virtualization software employed by Virtual Server and other products. No matter what the specifics, this part of the infrastructure requires extra attention. If the security of this underlying component is compromised, all VMs on the server are impacted. This means the host should be locked down, regularly patched and perform no tasks other than running VMs. You should also pay close attention to any possible interaction between the host and VMs running on it. This may require using multiple physical network adapters to separate traffic.
Physical NICs and Virtual Switches
Most virtualization solutions let you set up multiple VMs on a server with only a single network adapter. Even though there's only one physical NIC, the host and each VM see a separate adapter, and the underlying software magically translates the network traffic so the single physical adapter impersonates each of the virtual NICs. The risk factor with this configuration is that something as simple as an IP address not properly configured in one of your VMs or a DOS attack against any of them can prevent network access to all VMs and the host itself. If this happens, you won't be able to shut down the affected VMs or take other corrective action anymore. Because of this, it's best to assign a dedicated network adapter to the host itself and use it only to manage the host, including starting and stopping VMs. With this configuration you'll still be able to shut down any of the VMs or disconnect them from the network no matter what the problem is.
Virtualization also gives you additional choices for configuring entirely virtual network switches. For example, in Hyper-V you can configure a virtual switch that's connected to the internal network, which is shared by the host and one or more VMs. Avoid connecting VMs to this network because it enables network traffic from a compromised VM to the host and thus could give an attacker control not only over the host, but also over all VMs running on it. If there's a need to have a VM communicate with the host, try to keep the attack surface as small as possible by configuring packet filters and using other methods to keep this traffic to a bare minimum.
A private network, in Hyper-V lingo, also connects VMs to each other but allows no access to the host OS. This is the preferred solution for letting VMs communicate with each other. You can even define multiple private networks to further isolate network traffic between only certain VMs while ensuring that other VMs can't see the network. In addition to the security implications, keeping this network traffic off your physical infrastructure can also improve overall network performance.
Let's put some of these concepts together and take a look at how to design a virtual network for some typical servers you can find in a DMZ. Figure 1 depicts a virtualization host with multiple VMs: an ISA Server that acts as a firewall, an Exchange Edge server, a Web server and a DNS server. The Web server also accesses a SQL Server for some non-sensitive data, and all servers get their patches from a server running Windows Update Services.
The physical server contains three network adapters: one is dedicated to host management, one connects to the Internet and one connects to the internal network. All traffic between the Internet and the DMZ and between the DMZ and the internal network is controlled by ISA Server. ISA Server allows selected traffic for servers requiring an Internet connection through Virtual Switch 1. All traffic between the Web server and the SQL Server is routed through Virtual Switch 2. Virtual Switch 3 is used for traffic between the Windows Update server and the other servers. This design provides for complete isolation between the host and VM network traffic. Because you can create virtual switches easily, you can create separate segments for dissimilar network traffic more easily than if you had to use physical switches.
Virtualizing ISA Server brings up the question of whether a firewall should be running as a VM. The answer is, as in so many topics related to security: It depends. In the configuration depicted in Figure 1, all Internet traffic ends up at the ISA Server, and no connections from the Internet to the host or other VMs can be established. However, even a simple configuration mistake could change this. As a result, the network configuration I've shown is not ideal -- but it may be secure enough if none of the virtual servers in the DMZ contain valuable data and if there's another firewall between the DMZ and the internal network.
[Click on image for larger view.]
|Figure 1. A virtual network design for a demilitarized zone.
Using virtual switches can make things more secure, but they can also render part of your security infrastructure ineffective. A firewall between different security zones in your network can add to security, but many of today's firewalls are hardware appliances that can't be integrated into virtual switches. Luckily, there are vendors offering virtual appliances that can connect to these switches. A firewall running on a standard OS, such as ISA Server, can also be a viable solution to the problem. A network-based intrusion-detection system (IDS) that connects to switches to spot issues from common threats to a full-blown intrusion presents a similar problem. You can't connect network probes for most IDSes to virtual switches.
Fortunately, there are a few vendors that offer virtual appliances for VMware that do connect to virtual switches to monitor network traffic and forward events to an IDS management console. Some of these vendors are also working on solutions for Hyper-V.
Virtualizing portions of your network can increase the security of your network, but it can also make things worse. Your results will depend on the specifics of your implementation, but I hope that I've illustrated the main issues to consider so you can ask the right questions as you enter into the virtual network world.