Virtual DMZs in the cloud

June 18, 2014 by

Dejan Lukan

DMZ or DeMilitarized Zone is primarily used to separate the network into multiple blocks to enhance security. The name is derived from the same term used to define an area between two nations where military actions are prohibited.

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

When managing a network, we usually want to have some services or systems accessible to the outside world, while others are kept in a secure internal environment which isn't accessible from the outside. Normally, we want to expose one of the following services: http, ftp, smtp, dns, ssh, etc., which can safely be done by using a DMZ. A DMZ can therefore be used to create different network segments, where only defined traffic is allowed to traverse between different segments – this is established by using a firewall and intrusion detection and intrusion prevention systems. We have to plan the network topology in advance and decide which traffic can pass between the defined network segments. We always have to keep in mind that a DMZ network is inherently less secure than an internal network – therefore, we must properly secure a DMZ network from outside as well as inside attacks. If an attacker has successfully exploited a vulnerability in an externally accessible service and gained access to the DMZ network, proper security measures need to be in place to forbid him from gaining access to other internal systems.

Do you remember the TCP/IP stack from the university class? Well if you don't, let me quickly recap: each packet transmitted over the network has to go through the encapsulation process, where on each layer of TCP/IP stack, a header is appended to the data to be transmitted across the network. The appended headers correspond to the each layer of the OSI model as presented below (the picture was taken from [3]).

In order to understand DMZ networks, we must remember about different network devices used to route packets through the network from source to destination. There are a lot of different devices in use today, but mainly we need to know about hubs, switches and routers. A hub copies and sends every packet it receives on every port whether it was destined to go there or not; this makes it a great sniffer without actually having to do MITM attack, but that's a story for another time. There are also switches operating on a data-link layer, where the packets are sent only to the destination port, where MAC addresses of network interfaces are kept in ARP tables; in such cases, we can still issue a MITM attack to get the data of another machine on the internal network. There are also routers operating on the network layer, where IP addresses are used to route traffic through networks.

We talked about different network devices because it gives us a great starting point to explain why we need to allocate a different subnet for each DMZ network.

If we want to make HTTP service available on host A, which is on the same subnet as host B, which should be accessible only in the internal network, can we still properly secure the host B if host A is compromised? Yes, we can properly secure host B, but there are many conditions that must be met in order to do it. First, all the hosts need to be connected to a network device operating on the network layer (thus a router must be used) – this is because FW/IDS/IPS devices are most often operating on the network layer: IP addresses, TCP/UDP ports and a lot of other information, but certainly not MAC addresses. If a switch is used and compromised and host A wants to communicate with host B, the switch will normally pass traffic from host A to host B without being blocked by any kind of firewall rules (if VLAN is not used of course). But even if we connect the devices by using a network layer devices, there are still numerous problems when the hosts are in the same subnet.

Imagine that host A and B are in the 10.1.1.0/24 subnet, where port 80 on host A is accessible over the Internet and host B needs to be kept private. First let me say that it is possible to partially protect host B from host A by implementing complex rules where any traffic from host A destined to host B is blocked by the firewall running on the network layer device. But what if there are multiple hosts that need to have some service available and multiple hosts that need to be accessible only in the internal network? Even further, imagine we have DHCP in place which gives the same IP address to the same MAC address – what happens if an attacker compromises host A, changes the MAC address of the network interface, and requests a new IP address; will a rule on FW exist that will prevent the newly configured IP address of host A to communication with host B? Probably not. Even if hosts are using static IP addresses, an attacker can manually change its own IP address and probably gain access to host B. There are numerous other use cases where an attacker can access the internal host B if host A is compromised and they are in the same subnet; not to mention the time taken to manage such a deployment.

Therefore a different approach is needed. What if hosts with externally available services are placed in a different subnet than internally available hosts? This effectively protects against all of the above problems, where the attacker can compromise host A and it won't be able to access host B, no matter the IP address that he forcefully got from the router. We still have to have appropriate firewall rules in place on the router, but its number will be lower than before and their maintenance time will be reduced considerably.

This is where the DMZs come in, because what is a DMZ if not only a fancy name for a separate subnet with properly defined firewall rules between the network segments. Therefore, when creating a new DMZ network, we need to create a new subnet. Since the traffic can only traverse different network subnets on the network layer, we can define rules and protocols that are allowed to be sent between the subnets: we are in control to determine which traffic is allowed into the subnet and which traffic is allowed outside the subnet.

DMZs in a physical environment

When setting up a physical DMZ, we basically need to plug the server into a different logical network and then place the firewall on the border with the Internet and with other internal networks. A basic schematic representation looks like presented below (the picture was taken from [4]). The picture below presents a DMZ where the attacker connects via the public Internet to the service in a DMZ through the external firewall. The external firewall is the first line of defense where ports for externally needed services are open. Once the attacker compromises a host in a DMZ, he must still beat the internal firewall to get access to internal machines.

Another alternative representation of a DMZ is shown below: the representation is slightly different, but is the same, since the the connections from the external network are behind a firewall, and a firewall is also used to restrict access from a DMZ to an internal network LAN.

The diagram above is most often used in practice, because it's cost effective, since we only need one firewall instead of two. The first scheme is considered safer, since two firewalls are used, and now it would be a perfect opportunity to discuss why a DMZ should have two firewalls in place.

In a highly secure environment it's advisable to use two firewalls, each of a different vendor, so if the attacker is able to bypass one firewall, he won't be able to bypass the second one. Also, if two firewalls are in place, the attackers needs to bypass both firewalls to get to the internal network, which provides an additional layer of security.

Every host in a DMZ should also have two network interface cards: the first network interface card is for external connections, so web clients are able to connect to exposed services over the Internet (or any other external network) – the default gateway is outside the firewall and is needed when a server needs to have access to the Internet. And the second network interface card is for internal connections, which are usually used for a host in a DMZ to be able to access a database, which is in the internal network, or connect to a backup server to backup its data – the default gateway is inside the firewall and is needed when the server needs to have access to the internal network. By using two network interface cards, we're adding an additional layer of defense on the physical layer – if only one interface card was used, the host server would have to connect to the external and internal devices over the same physical layer by using the the same router somewhere along the network path – this means that the internal and external devices are connected to the same router, which doesn't provide any security on the physical layer [1]. An attacker can bypass the router's routing table, which could allow an attacker to exchange packets between the external and internal hosts; dual NIC solves this problem.

To isolate one DMZ network from the other DMZ network, we can use the following technologies:

• Physical Network Separation: the network is configured in such a way that the traffic between two DMZs can only go through a security appliance where the proper rules are in place to accept or deny the traffic. This is the most expensive setting, since it requires most physical devices that separate the DMZs.
• Logical Network Separation: provides a way to separate traffic on a network device between different logical segments.
• VLAN (Virtual Local Area Network): works on layer 2 where the interfaces with the same tags are in the same broadcast domain (by default, every interface on a switch is in a broadcast domain). To use VLANs, our network switch must support VLAN tagging, which enables us to use the same port on a switch to trunk multiple VLANs; consequentially, we don't need to add any additional hardware to the internal network and still be able to properly separate the networks.
• VRF (Virtual Routing and Forwarding): works on layer 3 and allows multiple routing tables to coexist on the same router at the same time, which allows network segmentation by using just one device.
• MPLS (Multiprotocol Label Switching): works on layer 3 and routes packets based on labels rather than network addresses stored in routing tables. The labels are used to identify the distant node to which the packet will be forwarded.
• vSwitch: virtual switch in Vmware can just as easily be used to separate one network from the other.

Note that the firewalls on the system above are usually security appliances, like ASA security appliance, which offers firewall protection, application security, denial-of-service protection, access control lists, DMZ, VPN, and many other features. This enhances security considerably, because all the traffic is inspected against malicious traffic, and if such traffic is detected, it is blocked by the security appliance before it can reach the internal network.

Also remember that the hosts in a DMZ should not run any services which are not necessary for the successful operation of the server. This minimizes the chance of a successful attack, because usually the attacker will compromise the easiest target first – but if it finds only patched services running on the server, it's very likely he won't take the time to compromise them. This is true for a non-targeted attack, where a persistent attacker with an intent to compromise the security of a specific company has much more time to plan and execute its attack.

Remember that a server in a DMZ should also use different passwords from any other hosts in the network to limit the attacker even further.

DMZs in a virtualized environment

When a virtualized DMZ is properly set up, it is as secure as the physical DMZ where the virtualization layer doesn't decrease security [2]. In recent years, there has been an increase of transforming physical DMZs into virtual DMZs by moving the physical servers to virtual machines running on the same physical host – now the DMZ security zones are virtual. Later in the article we'll see how the network communication between different security zones is isolated to keep virtual machines in one zone separated from the other zone.

The biggest security concern when using virtualized DMZ is its misconfiguration, and not the technology being used. A typical virtualized DMZ is shown in the picture below [2] and clearly represents a DMZ that is quite similar to the physical DMZ, except that the virtual machines are used inside each zone instead of physical machines.

Three typical virtualized DMZ configurations in use today are the following (summarized after [2]):

• Partially Collapsed DMZ with Separate Physical Trust Zones: each zone is physically separated from the other zones and the hosts in each zone are virtualized. This DMZ configuration directly resembles the physical DMZ, where the network separation is done on the physical network and not within the virtualization infrastructure.
• Partially Collapsed DMZ with Virtual Separation of Trust Zones: different zones are virtually separated, but are physically on the same ESX host. Each DMZ zone uses a separate virtual switch, which ensures the hosts connected to that virtual switch are separated from the hosts in the other zones. The communication between different DMZ zones still occurs through the physical network. With this configuration we must regularly check whether the virtual machine is placed in the right network.
• Fully Collapsed DMZ: a whole DMZ is virtualized, where everything is virtualized, but the DMZs are still separated if properly configured.

Let's look at the security issues that can arise with the arrival of virtualized DMZs:

• Compromising the ESX Host: a virtual machine on an ESX host has a virtual NIC that is connected to its own virtual switch, which isn't connected to the internal network. Normally this is considered safe, but an attacker that has compromised a VM on the host can exploit a vulnerability in a hypervisor to gain access to the whole host. Since the host has access to every single VM on that host, even the internal hosts, the attacker can therefore also gain access to the internal systems. An attack vector knows as Cloudburst has been developed by Immunity Inc in 2008, which enables the attacker to escape from the virtual machine jail [5]. This is also the biggest concern when moving from physical to virtual DMZ, but in reality there were only a few occurrences of such an attack being possible in the past, which makes the hypervisors quite secure. To protect against such exploits, no matter how slim the chances of successful exploitation of virtualization hypervisor, we must regularly update the virtualization software to achieve maximum security.
• Virtual NIC Configuration: if an administrator places a virtual NIC of certain virtual machine in the wrong virtual switch, that VM could access sensitive information in that DMZ. Therefore, extra care must be taken when configuring virtual machines to have access to a certain virtual switch. On the other hand, a physical DMZ could just as easily be misconfigured by plugging the cables into the wrong physical switch.
• Access to the Service Console/VMkernel: an attacker can bruteforce or guess a password through a compromised virtual machine in an untrusted DMZ to login to the service console, which gives him full access to all virtual machines on the host. When using ESX, the management interface needs to be properly isolated by assigning it to a dedicated , which has at least one pNIC. It's also a good idea if the configuration and management switch has a redundant pNIC for failover in case the first physical NIC fails. A VM belonging to a DMZ should never be on the same as Service Console or VMkernel, because a compromised VM in a DMZ could be used by the attacker to gain full access to the management console and every VM on a host.
• Access to Storage Network: the storage networks should be defined in its own to further protect the network: usually the network storage is done by using iSCSI/NFS protocols.
• Protections on Virtual Switches: each virtual switch can be configured to detect and protect against layer 2 attacks like MAC spoofing, MITM attacks, promiscuous mode.
• Virtual Machine Resource Limitations: if an attacker compromises a virtual machine on the ESX host and that virtual machine doesn't have resource limitations in place, an attacker can perform a DoS attack on every virtual machine on that host by taking up all the host's resources, leaving none for the rest of the virtual machines. This can easily be prevented by using proper resource limitations, where each virtual machine is given a proportional share of available resources. It's also a good idea for every to have multiple pNICs, so the traffic load can be spread across all physical NICs to avoid congestion.
• DMZ on separate : we can create a DMZ network by either placing the VMs in a separate or by using multiple VLANs on the same . The first method is the better of the two, because a dedicated uses a separate pNIC, thus physically separating the traffic from internal and external VLAN. If a VM from external VLAN wants to communicate with a VM on the internal VM, the traffic needs to go to the physical router over pNICs where a firewall can be used to block or pass the traffic through.
• Virtual DMZ Configuration Auditing: each part of the virtualized DMZ network needs to be properly audited every once in a while to determine whether every security best practice is being followed.
• Configuration of User Roles: each administrator should belong to the user group that gives him just enough access to the ESX as is needed for him to do his job; he shouldn't have root access to the host, since that would enhance the chance of him misconfiguring the configuration.

Conclusion

In this article we've seen what a DMZ is and how and why is it used. With the coming of the cloud, the DMZ has moved from a physical to virtual environment, which reduces the cost of the overall network configuration and maintenance. We've seen the advantages and disadvantages of using a virtual DMZ and presented security related considerations that need to be taken into account when implementing a virtual DMZ.

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Sources

• Designing a DMZ, SANS Institute InfoSec Reading Room
• DMZ Virtualization with VMware Infrastructure
• TCP/IP Architecture and the TCP/IP Model, TCP/IP Guide
• Public DMZ network architecture
• Virtual machine escape