DMZ - Demilitarisierte Zone in der Netzwerksicherheit

Die Demilitarisierte Zone (DMZ) ist ein logisch und physisch vom internen Unternehmensnetzwerk getrenntes Netzwerksegment, das öffentlich erreichbare Dienste aufnimmt und gleichzeitig das interne Netz vor direktem Zugriff aus dem Internet schützt. Der Begriff stammt aus dem Militärbereich und bezeichnet eine neutrale Pufferzone zwischen zwei Konfliktparteien - in der Netzwerksicherheit steht er für ein kontrolliertes Zwischensegment zwischen dem nicht vertrauenswürdigen Internet und dem hochvertrauenswürdigen internen Netz.

Warum eine DMZ?

Ohne DMZ stehen zwei schlechte Alternativen:

Server direkt im Internet: Maximale Exposition, jede Schwachstelle des Servers kann direkt genutzt werden, um ins interne Netz zu gelangen.
Server direkt im internen Netz: Interne Ressourcen sind von außen nicht erreichbar - für öffentliche Dienste nicht praktikabel.

Die DMZ löst dieses Dilemma: Öffentlich erreichbare Server stehen im Puffersegment. Wird ein DMZ-System kompromittiert, hat der Angreifer noch keine direkte Verbindung zum internen Netz - er muss eine zweite Firewall überwinden.

DMZ-Architekturen

Single-Firewall-DMZ (Drei-Bein-Firewall)

Die einfachste DMZ-Variante verwendet eine einzige Firewall mit drei Netzwerkinterfaces:

Internet → [Firewall] → DMZ
                    ↘ Internes Netz

Interface 1: Verbindung zum Internet (WAN)
Interface 2: Verbindung zur DMZ
Interface 3: Verbindung zum internen Netz

Vorteile: Einfaches Management, geringere Hardware-Kosten, zentralisierte Regelwerke.

Nachteile: Single Point of Failure - wird die Firewall kompromittiert, ist sowohl DMZ als auch internes Netz exponiert. Für sicherheitskritische Umgebungen nicht ausreichend.

Dual-Firewall-DMZ (Screened-Subnet)

Das überlegene Modell: Zwei separate Firewalls schützen die DMZ auf beiden Seiten.

Internet → [Outer Firewall] → DMZ → [Inner Firewall] → Internes Netz

Outer Firewall (Front-End-Firewall): Filtert eingehenden Internet-Traffic. Erlaubt nur spezifische Protokolle/Ports zu DMZ-Servern.
Inner Firewall (Back-End-Firewall): Schützt das interne Netz vor der DMZ. Erlaubt nur notwendige, definierte Verbindungen von DMZ-Systemen nach innen.

Vorteile: Tiefenverteidigung (Defense in Depth). Ein Angreifer muss zwei unabhängige Firewalls überwinden. Empfohlen für alle Umgebungen, die öffentlich erreichbare Dienste betreiben.

Nachteile: Höhere Komplexität, mehr Hardware, aufwändigeres Management.

Mehrfach-DMZ (Multi-Layer-DMZ)

Für komplexe Infrastrukturen werden mehrere DMZ-Segmente verwendet, die nach Schutzbedarfsstufen gestaffelt sind:

Internet → [FW1] → DMZ-Public (Web, Mail)
                → [FW2] → DMZ-Internal (Middleware, APIs)
                         → [FW3] → Internes Netz (DB, Verzeichnisdienste)

Typisch für Finanzinstitute, Gesundheitseinrichtungen und KRITIS-Betreiber.

Typische Dienste in der DMZ

In der DMZ werden ausschließlich Systeme platziert, die von außen erreichbar sein müssen:

Dienst	Protokoll/Port	Hinweise
Webserver (HTTP/HTTPS)	TCP 80, 443	Reverse Proxy bevorzugen
Mail-Gateway (SMTP)	TCP 25, 587, 465	Spam-Filter, TLS-Enforcing
DNS (autoritativ)	UDP/TCP 53	Nur externer DNS in DMZ
VPN-Gateway	UDP 1194, 4500	Split-Tunneling beachten
FTP/SFTP	TCP 21, 22	SFTP bevorzugen
Remote Desktop Gateway	TCP 443 (RDP über HTTPS)	Nie RDP direkt exponieren
API-Gateway	TCP 443	WAF vorschalten
Monitoring-Proxy	Variabel	Exportiert Metriken nach außen

Nicht in die DMZ gehören: Datenbanken, Active Directory Domain Controller, Backup-Server, interne Dateiserver, alle Systeme ohne direkten Bedarf zur Außenkommunikation.

Firewall-Regelwerk für die DMZ

Ein wirksames DMZ-Regelwerk folgt dem Default-Deny-Prinzip: Alles ist verboten, was nicht explizit erlaubt ist.

Grundlegende Regeln (vereinfacht)

Outer Firewall (Internet → DMZ):

Erlaube: TCP 443 von Internet zu Webserver-IP in DMZ
Erlaube: TCP 25 von Internet zu Mail-Gateway-IP in DMZ
Verbiete: Alle anderen eingehenden Verbindungen

Inner Firewall (DMZ → Internes Netz):

Erlaube: TCP 1433 (MSSQL) von Webserver-IP zu Datenbank-IP (intern)
Erlaube: TCP 389/636 (LDAP/LDAPS) von App-Server-IP zu AD-IP (intern)
Verbiete: Alle anderen Verbindungen von DMZ nach intern
Verbiete: Alle Verbindungen vom internen Netz Richtung DMZ initiiert von intern (außer definierte Management-Verbindungen)

Kritisch: Verbindungen von der DMZ zum internen Netz müssen auf das absolute Minimum beschränkt und einzeln dokumentiert sein.

Best Practices für die DMZ-Implementierung

Segmentierung und Isolation

Jeder DMZ-Dienst sollte in einem eigenen VLAN oder Segment isoliert sein, um laterale Bewegung zwischen DMZ-Servern zu verhindern
Micro-Segmentierung mit Host-based Firewalls zusätzlich zur Netzwerkfirewall
Getrennte Management-Netze für Administration der DMZ-Systeme

Härtung der DMZ-Server

Minimales OS-Image (nur benötigte Pakete installieren)
Regelmäßiges Patch-Management - DMZ-Systeme sind das erste Angriffsziel
Kein unnötiger ausgehender Traffic von DMZ-Systemen ins Internet erlauben
Lokale Firewall auf jedem DMZ-Host konfigurieren

Monitoring und Logging

Vollständiges Logging aller Firewall-Regeln aktivieren
SIEM-Integration für DMZ-Logs (verdächtige Verbindungsversuche sofort erkennen)
IDS/IPS-System in der DMZ betreiben
Honeypot-Systeme zur Früherkennung von lateraler Bewegung

Verschlüsselung

Alle Verbindungen zwischen Internet und DMZ via TLS 1.2+ (idealerweise TLS 1.3)
Auch intern: Verbindungen zwischen DMZ und innerem Netz verschlüsseln (Zero-Trust-Prinzip)
Zertifikatsverwaltung automatisieren (ACME/Let’s Encrypt oder interne PKI)

Wartung und Testing

DMZ-Systeme regelmäßig in Penetrationstests einbeziehen
Firewall-Regelwerke mindestens jährlich auditieren und nicht mehr benötigte Regeln entfernen
Change-Management-Prozess für alle Firewall-Änderungen einhalten

DMZ und moderne Architekturen

Cloud und Hybrid-Infrastrukturen

In Cloud-Umgebungen (AWS, Azure, GCP) wird das DMZ-Konzept durch Security Groups, Network Access Control Lists (NACLs) und Virtual Private Clouds (VPCs) umgesetzt. Eine explizite DMZ-VPC zwischen öffentlichem Subnetz und privaten Subnetzen ist Best Practice.

Zero Trust und DMZ

Das Zero-Trust-Modell hinterfragt das klassische DMZ-Konzept: Wenn keinem Netzwerksegment grundsätzlich vertraut wird, verliert die DMZ als “Vertrauenspuffer” an Bedeutung. In der Praxis koexistieren beide Ansätze: Die DMZ bleibt für die Netzwerksegmentierung relevant, während Zero-Trust-Prinzipien (explizite Authentifizierung, minimale Berechtigungen, Verschlüsselung aller Verbindungen) auch innerhalb der DMZ gelten.

Container und Kubernetes

In containerisierten Umgebungen ersetzt die Kubernetes Network Policy klassische DMZ-Firewalls. Ingress-Controller übernehmen die Funktion des Reverse Proxy, und Service Meshes (Istio, Linkerd) implementieren mTLS zwischen allen Services - auch intern.

Häufige Fehler bei der DMZ-Implementierung

Zu viele Dienste in einem DMZ-Segment: Keine weitere Isolation zwischen DMZ-Hosts - bei Kompromittierung eines Hosts sind alle anderen direkt erreichbar
Datenbankzugriff direkt aus DMZ: Datenbank-Server gehören ins interne Netz, nicht in die DMZ
Keine ausgehenden Filterregeln für DMZ-Systeme: Kompromittierte DMZ-Systeme können ungehindert C2-Verbindungen aufbauen
Management über dasselbe Interface: Admins verwalten DMZ-Systeme über das DMZ-Netz statt über ein dediziertes Management-VLAN
Veraltete Firewall-Regeln: Regeln für längst abgeschaltete Dienste bleiben aktiv und öffnen unbemerkt Angriffswege

Fazit

Die DMZ ist ein bewährtes und unverzichtbares Element jeder professionellen Netzwerksicherheitsarchitektur. Sie schafft eine kontrollierte Pufferzone zwischen Internet und internem Netz und begrenzt den Schaden bei einer Kompromittierung öffentlich erreichbarer Dienste erheblich. Für moderne Umgebungen gilt: Dual-Firewall-Architektur, konsequentes Default-Deny, Micro-Segmentierung innerhalb der DMZ und vollständiges Logging. In Cloud- und Container-Umgebungen werden die gleichen Konzepte mit den jeweiligen nativen Werkzeugen umgesetzt.