DMZ - Demilitarized zone in network security

The Demilitarized Zone (DMZ) is a network segment that is logically and physically separated from the internal corporate network; it hosts publicly accessible services while protecting the internal network from direct access from the Internet. The term originates from the military and refers to a neutral buffer zone between two conflicting parties—in network security, it denotes a controlled intermediate segment between the untrusted Internet and the highly trusted internal network.

Why a DMZ?

Without a DMZ, there are two poor alternatives:

Servers directly on the Internet: Maximum exposure; any vulnerability in the server can be exploited directly to gain access to the internal network.
Servers directly on the internal network: Internal resources are inaccessible from the outside—not practical for public services.

The DMZ resolves this dilemma: Publicly accessible servers reside in the buffer segment. If a DMZ system is compromised, the attacker still has no direct connection to the internal network—they must bypass a second firewall.

DMZ Architectures

Single-Firewall DMZ (Three-Legged Firewall)

The simplest DMZ variant uses a single firewall with three network interfaces:

Internet → [Firewall] → DMZ
                    ↘ Internal network

Interface 1: Connection to the Internet (WAN)
Interface 2: Connection to the DMZ
Interface 3: Connection to the internal network

Advantages: Simple management, lower hardware costs, centralized rule sets.

Disadvantages: Single point of failure—if the firewall is compromised, both the DMZ and the internal network are exposed. Not sufficient for security-critical environments.

Dual-Firewall DMZ (Screened Subnet)

The superior model: Two separate firewalls protect the DMZ on both sides.

Internet → [Outer Firewall] → DMZ → [Inner Firewall] → Internal network

Outer Firewall (Front-End Firewall): Filters incoming Internet traffic. Allows only specific protocols/ports to DMZ servers.
Inner Firewall (Back-End Firewall): Protects the internal network from the DMZ. Allows only necessary, defined connections from DMZ systems to the inside.

Advantages: Defense in depth. An attacker must overcome two independent firewalls. Recommended for all environments that operate publicly accessible services.

Disadvantages: Greater complexity, more hardware, more complex management.

Multi-Layer DMZ

For complex infrastructures, multiple DMZ segments are used, tiered according to protection requirements:

Internet → [FW1] → DMZ-Public (Web, Mail)
                → [FW2] → DMZ-Internal (Middleware, APIs)
                         → [FW3] → Internal Network (DB, Directory Services)

Typical for financial institutions, healthcare facilities, and KRITIS operators.

Typical Services in the DMZ

Only systems that must be accessible from the outside are placed in the DMZ:

Service	Protocol/Port	Notes
Web server (HTTP/HTTPS)	TCP 80, 443	Prefer reverse proxy
Mail gateway (SMTP)	TCP 25, 587, 465	Spam filter, TLS enforcement
DNS (authoritative)	UDP/TCP 53	Only external DNS in DMZ
VPN gateway	UDP 1194, 4500	Note split tunneling
FTP/SFTP	TCP 21, 22	Prefer SFTP
Remote Desktop Gateway	TCP 443 (RDP over HTTPS)	Never expose RDP directly
API Gateway	TCP 443	Place WAF in front
Monitoring Proxy	Variable	Exports metrics externally

Do not place in the DMZ: Databases, Active Directory domain controllers, backup servers, internal file servers, all systems without a direct need for external communication.

Firewall Rules for the DMZ

An effective DMZ rule set follows the default deny principle: Everything is prohibited unless explicitly permitted.

Basic Rules (simplified)

Outer Firewall (Internet → DMZ):

Allow: TCP 443 from the Internet to the web server IP in the DMZ
Allow: TCP 25 from the Internet to the mail gateway IP in the DMZ
Deny: All other incoming connections

Inner Firewall (DMZ → Internal Network):

Allow: TCP 1433 (MSSQL) from Web Server IP to Database IP (internal)
Allow: TCP 389/636 (LDAP/LDAPS) from App Server IP to AD IP (internal)
Block: All other connections from DMZ to internal
Block: All connections from the internal network to the DMZ initiated from the internal network (except defined management connections)

Critical: Connections from the DMZ to the internal network must be limited to the absolute minimum and documented individually.

Best Practices for DMZ Implementation

Segmentation and Isolation

Each DMZ service should be isolated in its own VLAN or segment to prevent lateral movement between DMZ servers
Micro-segmentation with host-based firewalls in addition to the network firewall
Separate management networks for administering DMZ systems

Hardening DMZ Servers

Minimal OS image (install only necessary packages)
Regular patch management—DMZ systems are the first target of attacks
Do not allow unnecessary outbound traffic from DMZ systems to the Internet
Configure a local firewall on every DMZ host

Monitoring and Logging

Enable full logging of all firewall rules
SIEM integration for DMZ logs (detect suspicious connection attempts immediately)
Operate an IDS/IPS system in the DMZ
Use honeypot systems for early detection of lateral movement

Encryption

All connections between the Internet and the DMZ via TLS 1.2+ (ideally TLS 1.3)
Internally as well: Encrypt connections between the DMZ and the internal network (zero-trust principle)
Automate certificate management (ACME/Let’s Encrypt or internal PKI)

Maintenance and Testing

Regularly include DMZ systems in penetration tests
Audit firewall rules at least annually and remove rules that are no longer needed
Adhere to a change management process for all firewall changes

DMZ and Modern Architectures

Cloud and Hybrid Infrastructures

In cloud environments (AWS, Azure, GCP), the DMZ concept is implemented using Security Groups, Network Access Control Lists (NACLs), and Virtual Private Clouds (VPCs). An explicit DMZ VPC between public and private subnets is best practice.

Zero Trust and DMZ

The Zero Trust model challenges the traditional DMZ concept: If no network segment is trusted by default, the DMZ loses its significance as a "trust buffer." In practice, both approaches coexist: The DMZ remains relevant for network segmentation, while Zero Trust principles (explicit authentication, least privilege, encryption of all connections) also apply within the DMZ.

Containers and Kubernetes

In containerized environments, Kubernetes Network Policy replaces traditional DMZ firewalls. Ingress controllers take over the function of the reverse proxy, and service meshes (Istio, Linkerd) implement mTLS between all services—including internally.

Common Mistakes in DMZ Implementation

Too many services in a DMZ segment: No further isolation between DMZ hosts—if one host is compromised, all others are directly accessible
Database access directly from the DMZ: Database servers belong on the internal network, not in the DMZ
No outbound filter rules for DMZ systems: Compromised DMZ systems can establish C2 connections unimpeded
Management via the same interface: Admins manage DMZ systems via the DMZ network instead of a dedicated management VLAN
Outdated firewall rules: Rules for services that have long been disabled remain active and open attack vectors unnoticed

Conclusion

The DMZ is a proven and indispensable element of any professional network security architecture. It creates a controlled buffer zone between the internet and the internal network and significantly limits the damage in the event of a compromise of publicly accessible services. For modern environments, the following applies: dual-firewall architecture, consistent default-deny policy, micro-segmentation within the DMZ, and comprehensive logging. In cloud and container environments, the same concepts are implemented using the respective native tools.