What is a DMZ, and why is it important?
A DMZ, or De-Militarized Zone, is a term originally coined by the military. Wikipedia defines a DMZ as:
“An area in which treaties or agreements between nations, military powers or contending groups forbid military installations, activities or personnel. A DMZ often lies along an established frontier or boundary between two or more military powers or alliances.
Many demilitarized zones are considered. neutral territory because neither side is allowed to control it, even for non-combat administration.”
In network security, a DMZ — also called a screened subnet — is essentially a buffer between an organization’s private, internal network, and untrusted networks, such as the Internet. Unlike the military definition, it should definitely be under control (of the organization). The commonality between the two definitions is in it’s purpose as an intermediary between two sides.
The DMZ is a perimeter network that is often home to web, proxy, e-mail, and DNS servers, as well as other external-facing services.
Typically, a firewall is placed in between the private network and the DMZ, and the DMZ and the Internet, to better secure outbound and inbound network traffic. Many modern organizations will also use a reverse proxy on their web servers, which prevents overloading, enforces SSL encryption and caching, improves overall safety of their back-end infrastructure, among other uses.
The DMZ adds an additional layer of security for both outbound traffic from the private, local area network (LAN), and for inbound traffic from the Internet (WAN). An organization needs to be able to access untrusted networks (via the Internet), while also safeguarding it’s private network. DMZs are generally segmented, so that the external-facing network is not on same subnet as the private, internal network.
Say, for instance, an organization’s network is at 10.0.0.x/24, where x denotes the host bits. Now, the public-facing network and private network could all be on the same subnet. 10.0.0.1 could be the web server, 10.0.0.2 could be the e-mail server, 10.0.0.3 could be a private network, etc. While this is convenient, think about it from an attacker’s perspective (hypothetically speaking):
An adversary performs a network scan to enumerate the live hosts on a target network. Penetration testers who use NMap (who hasn’t?) are familiar with the -sn switch, which runs a simple ping sweep against the specified IP range. As seen in the example below (source: LinuxHint), NMap outputs the hosts that are up, and their MAC addresses.
Note: The -sP switch is a deprecated version of -sn.
They probe further into discovering open and listening ports, the services running, and find a vulnerability on, say, the web server. The adversary uses an exploit against the vulnerability and gains initial access. If the adversary attempts to move laterally within the network, there will be a higher chance of success if the hosts and services are all on the same subnet (as shown in the example above).
On the other hand, if the external-facing network services are segmented onto their own subnet, such as 10.0.254.x/23 for web traffic, a different subnet for the mail server, etc, and 10.0.0.x/24 for the private, internal network, it’s one more step for the adversary. Designing a network in this way does not eliminate the risk of an internal network compromise, it merely makes it more difficult.
This, of course, is implemented in combination with other security measures, such as strong user authentication controls, service hardening and patching, network intrusion visibility, among others.
