In today’s blog, we are going to explore the concept of a Demilitarized Zone (DMZ) in computer networking. Specifically, what is a DMZ and what does it protect your organization from? Second, we will explore what makes a DMZ so important and why so many compliance regulations require one. With that, let’s jump right into it.
What is a DMZ?
The term DMZ comes from a military term. When nations are at war, sometimes they set-up (usually through treaties) a demilitarized zone. Simply put, this is a span of land where no nation is allowed to have any military installations or troops. The most famous one that is currently enacted is between North and South Korea. The purpose of the DMZ is to protect both sides from attack. If North Korea was going to attack South Korea, they would have to pass through this tract of land, giving South Korea a short amount of time to alert that an attack was imminent. Additionally, this allows both sides to better prepare their defenses. If a large amount of troops are seen crossing through the DMZ, then either side would view that as a threat and try to thwart the attack. Without a DMZ, neither Korea would know whether the group of people approaching were intending on attacking or simply walking down the street. Because no one is allowed/authorized to be in that section of land without serious approvals, it allows for the identification of threats vs. non-threats.
In networking, a DMZ refers to a subnet that is physically or logically separated from the internal network. This subnet is used to separate untrusted devices from trusted devices. Traditionally, in a DMZ you would put all the devices that are required to be Internet-accessible. These can include your web servers, an SFTP server, email exchange servers, etc. Then, access from the DMZ to the internal network is further controlled and closely monitored, usually through a firewall.
The image on the left is an example of a network DMZ. As you can see in the image, any traffic from the internet will go through a firewall to access the web server in the DMZ. What you can also see is that any traffic from the DMZ must also go through a firewall to access the internal network. This is traditionally the same firewall with a separate interface and access control list, however, it could be two physically separate firewalls.
It is important to consider that many of the severs in the DMZ still need to access systems on an internal network. For example, the web server may need to be able to reach into the internal network to access the backup server to perform daily backups or the database server to store information. Therefore, it is important to know that a DMZ is not necessarily blocking all connections, but it is restricting them to only approved connections based on source/port/service/destination.
Why is a DMZ Necessary?
Now that we have a good understanding of what a DMZ is, let me explain why it is necessary. As we have already discussed, a DMZ is used to house those servers and applications that are exposed to the Internet. Many of these are required to be exposed to the Internet with a legitimate business-related justification. You can’t just deny access to your website or you won’t get any business. However, because they are exposed to the Internet, they are at a much higher risk of compromise. Anyone can access these, and if you don’t already know it, let me be the first to tell you that any device exposed to the Internet is under constant attack. Even if you have a great security posture, all it takes is one zero-day vulnerability or a patch that you didn’t apply, and an attacker may be able to compromise one of these systems. Therefore, you should treat these systems as untrusted, or at the very least, at a higher risk level.
A DMZ is one layer of security that assumes one of these systems will be compromised eventually and tries to limit the damage an attacker can do. By requiring all traffic from the DMZ to pass through a firewall, you are effectively limiting the damage an attacker can do. If this firewall ACL is configured properly, only authorized communications should be allowed from the DMZ to the internal network. This means that an attacker will have a much harder time pivoting to the internal network and attacking internal systems.
Other Security Considerations
As mentioned above, the systems in the DMZ are still exposed to the Internet and thus have a higher level of residual risk. Because of that, there are some additional security considerations for these devices, including:
- Ensure these devices are hardened using industry-recognized benchmarks. We recommend the Center for Internet Security (CIS) Benchmarks located here.
- Use different passwords on these systems than other systems. When an attacker compromises a system, they can dump the contents of memory, which may include passwords.
- Perform regular penetration tests to validate the effectiveness of your controls. This should include external penetration tests to see the exposure of the systems in the DMZ as well as segmentation validation testing that assesses whether an attacker can pivot into the internal network.