What is a DMZ?

The DMZ in plain English

Think of a company’s reception area. Visitors are allowed into the lobby, where they are helped and can drop off documents. The doors to the offices, however, are locked. Even if a visitor misbehaves, they can’t simply walk up to the desks. A DMZ applies exactly this principle to the network.

The abbreviation stands for “demilitarized zone.” The term comes from the military, where it describes a buffer zone between two countries in which no troops may be stationed. In IT, the DMZ is the buffer zone between the internet and your internal network. It hosts the systems that need to be reachable from the outside: web servers, email gateways that accept and inspect incoming messages, or reverse proxies. These are front-end servers that receive requests from the internet and pass them on to internal applications in a controlled way.

How a DMZ works

At the heart of a DMZ are firewalls – filters that use fixed rules to decide which connections are allowed. Typical ground rules look like this:

1. From the internet into the DMZ: Only the services that are truly needed are reachable, such as the encrypted website.
2. From the DMZ into the internal network: Ideally no connections at all. Where this can’t be avoided, for example to access a database, connections are tightly limited to individual systems and services.
3. From the internal network into the DMZ: Only the connections that are needed. Administrative access is additionally restricted to secured channels and designated admin workstations.
4. From the DMZ to the internet: Only what is strictly necessary. Otherwise, a compromised server can freely send data out or fetch an attacker’s commands. This rule is often forgotten.

Technically, there are two common designs: a single firewall with separate interfaces for the internet, the DMZ, and the internal network – or two firewalls placed one behind the other with the DMZ between them. The second variant is considered more robust because an attacker has to overcome two hurdles. In cloud environments, the same principle is implemented with separate network segments and access rules.

A practical example

Here’s a typical scenario: A logistics company runs its shipment tracking on a web server in the DMZ. By exploiting a security vulnerability in the web application, an attacker gains access to this server. Now it becomes clear how well the DMZ was built.

In the worst case, the web server is a member of the internal Windows domain – the central user management system – and an old firewall rule allows connections to the entire corporate network. The attacker can then move from system to system; experts call this lateral movement. In the best case, the server may only talk to a single database, and outbound connections are blocked. The damage remains limited to that one server, and monitoring flags the unusual connection attempts.

Why does this matter for businesses?

Systems that are reachable from the internet are constantly scanned for vulnerabilities by automated tools. When a new vulnerability becomes known, even a well-maintained server can be affected. The DMZ then determines whether an incident on a single server turns into an attack on the entire company. It is no coincidence that the IT-Grundschutz methodology of the BSI (Germany’s Federal Office for Information Security) describes how to divide networks into security zones and how to secure internet gateways with firewalls.

In practice, reality often deviates from the concept. Exceptions pile up over the years: access that was opened up “temporarily,” overly broad rules, shared administrator passwords for the DMZ and the internal network. Each exception seems harmless on its own – together, they can undermine the separation.

How to protect your organization

• Publish only what’s necessary: Place only those services in the DMZ that genuinely need to be reachable from the outside.
• Keep rules tight: Allow specific connections between individual systems and services instead of blanket permissions.
• Restrict outbound traffic: DMZ servers should only establish connections to destinations that are required for business purposes.
• Manage separately: Don’t join DMZ systems to your internal Active Directory – the central Windows user management system – and use dedicated administrator accounts.
• Harden and update: System hardening – disabling unneeded functions and applying secure settings – and timely updates are especially important here.
• Monitor: Log access and have anomalies reported to you.
• Review regularly: Clean up firewall rules and test the separation in practice.

How Rootsektor can help

A penetration test for Network & Infrastructure shows whether your DMZ lives up to its design. We check from the outside which services are reachable and vulnerable and, on request, test from inside the DMZ whether an attacker could get into the internal network. We perform internal tests either on-site or remotely. You can request your fixed-price quote via our Pentest Quote page – you’ll receive it within 24 hours of scoping (on business days).