In a physical environment, DMZ networks provide a buffer between the internal network and the Internet, securing servers that connect to both. Yet new security challenges arise when connecting virtual environments to DMZ network architecture, requiring network managers to try new design methodologies.
In a physical environment, servers are connected to an isolated network switch that is protected by a physical firewall that has interfaces to the DMZ switch, the internal network and the external network. The server itself only has direct network connectivity in the DMZ, and its network connections to the internal and external networks are protected by the firewall. If the server were compromised, an attacker would only have access to the DMZ network and would not be able to access the internal network without getting through the firewall.
Any server that exists in the DMZ should only be connected to the DMZ switch and should never have physical connections to both the DMZ network and the internal network. If a server is connected to both networks it essentially acts as a bridge, and when compromised, offers attackers a direct route to the internal network without going through the firewall. However, segregating your internal network, the DMZ network and the external Internet works well.
With virtualization, the traditional methodologies of isolating physical servers onto a DMZ network don’t work well for several reasons:
As a result, when connecting your virtual environment to a DMZ network architecture, you need design methodologies to adapt to the virtualization architecture.
There are several options available for connecting hosts and VMs to a DMZ network architecture, and all of them have one thing in common: The management console of the host is connected to an internal network. This seems to defy the basic principle that a physical server should never be connected to both public and private networks, as it can act as an open bridge between them. While you wouldn’t want to do this with a server running a traditional operating system, it is OK to do this with a bare metal (Type 1) hypervisor like vSphere.
A Type 1 hypervisor is designed to isolate and compartmentalize virtual machines and vSwitches. If a VM is compromised and people have full access to the OS of the VM, while they can exploit the VM at the OS layer, they cannot access or exploit the hypervisor to gain access to other VMs or host networks. This is a proven design and VMware has never had a reported incident with ESX and ESXi hypervisors being compromised this way.
However, that management console should be located on an internal network, but not on the DMZ, where it can provide access to every VM running on a host, making it a rich, fat target.
The rest of the network architecture of a host that is connected to a DMZ can be done several different ways. A virtual switch (vSwitch) can support multiple physical NICs as well as multiple VLANs when tagging is used. A host can have multiple vSwitches, but physical NICs must be dedicated to a vSwitch and cannot be shared among them. It is common to have multiple vSwitches that are dedicated to certain host functions or groups of VMs. In addition, vSwitches typically have multiple physical NICs for failover and load balancing.
When creating a DMZ network architecture on a host, there is one golden rule to follow: Dedicate a vSwitch to the DMZ and do not share it with any internal VLANs. Doing this isolates DMZ traffic to its own physical NIC so it is not shared with any traffic from VMs on private networks. A vSwitch is essentially a software Layer 2 switch that exists in the RAM of a host that has physical NICs (uplinks) that are connected to the virtual NICs that are assigned to VMs. Each vSwitch is isolated from each other and there are no backend interconnects that connect vSwitches to each other. If a VM on one vSwitch needs to connect to a VM on another vSwitch on the same host, it needs to traverse the physical network so traditional physical network security can be used to protect and isolate traffic between vSwitches. By dedicating a vSwitch to a DMZ, you can use a traditional physical firewall to protect it and it keeps it isolated from other vSwitches on a host that may be connected to internal networks.
You can further segregate your DMZ network by using VLAN tagging inside the vSwitch to support multiple VLANs in the DMZ. However, it might be desirable to physically isolate virtual machines, in which case you could create multiple vSwitches that each have its own physical NIC that are connected to the DMZ network. This allows each vSwitch to be protected by a physical firewall; it also forces intra-VM traffic to go through a physical firewall.
So, you’ve dedicated one or more vSwitches on a host to a DMZ network—do you dedicate the whole host as well to DMZ-only VMs? You can if you want to provide better security and separation with your VMs that connect to internal networks, but it is not uncommon to have both vSwitches connected to internal networks, and vSwitches connected to external networks on the same host. As we covered earlier, this is OK because the hypervisor keeps the traffic from each vSwitch separated from other vSwitches. Below is a diagram of a typical network configuration for a host that is connected to a DMZ network that has separate vSwitches for DMZ network VM traffic, internal network VM traffic and management console traffic:
This design allows you to maximize your host resources, as you may only have a few VMs that need to connect to a DMZ. Dedicating a whole host to them would be a waste of resources. Each vSwitch has its own physical NIC that connects to separate physical switches that are protected from other networks by physical firewalls.
Connecting to the Internet always carries some risk, but it is possible to connect a host to a DMZ network if you make smart design decisions. A secure DMZ network architecture should combine proper design and security controls at both the virtual and physical levels. By doing this you can safely extend the advantages that virtualization provides to your DMZ environment.
30 Jun 2011