DMZ taucht ohne beigefügte Definition auf. Ein Punkt auf einer Sicherheits-Checkliste, ein Satz im Härtungsdokument eines Anbieters, eine Anforderung in einer Stellenanzeige, direkt neben TLS und Least Privilege.
Sie schlagen es nach und finden das Schema einer Firewall mit drei Netzwerkkabeln. Eines führt ins Internet, eines zu einer Reihe von Servern, eines in ein Büro-LAN. Was Sie verwalten, ist ein einzelner gemieteter Server mit einer öffentlichen IP und ohne freie Netzwerkschnittstelle.
Das erste Bild zeigt eine echte DMZ-Architektur. Auf einem einzelnen Server lässt sich ein Teil ihres Sicherheitsziels nachbilden: begrenzen, was das Internet erreichen kann. Was sich auf demselben Host nicht nachbilden lässt, ist die separate Netzwerkgrenze, die eine DMZ überhaupt erst zur DMZ macht.
Die Kurzfassung
- Eine DMZ trennt die Dienste, die Fremde erreichen müssen, vom Rest dessen, was Sie betreiben.
- Es ging nie um die Verkabelung: Es ging darum, dass eine Kompromittierung auf der öffentlichen Seite dort endet.
- Sie können eine Firewall konfigurieren und trotzdem keine DMZ haben.
- Ein einzelner Server mit einer öffentlichen IP kann die Angriffsfläche mit einem Reverse Proxy, Host-Firewallregeln und privaten oder Loopback-Bindungen verkleinern, aber er schafft damit kein separates DMZ-Segment.
- Diese Variante teilt sich einen Kernel mit dem, was sie schützt, zählen Sie sie also als verringerte Angriffsfläche und nicht als Isolation.
Was dieser Artikel nicht behandelt
Der Rahmen hier ist das mentale Modell, und drei angrenzende Themen bleiben bewusst außen vor.
- Keine Bauanleitung. Es gibt hier keine Reverse-Proxy-Konfiguration, keine Firewall-Regelsyntax und keine Empfehlung, welches Werkzeug installiert werden soll.
- Keine Konfiguration von Consumer-Routern. Der Schalter „DMZ host“ an einem Heimrouter bezeichnet etwas völlig anderes.
- Kein Urteil über Zero Trust. Ob das Netzwerkperimeter noch die richtige primäre Kontrolle ist, ist eine echte Debatte, und sie wird hier nicht entschieden.
Was ist eine DMZ, und wofür ist sie da?
Eine DMZ, also eine entmilitarisierte Zone, ist ein Netzwerksegment zwischen dem nicht vertrauenswürdigen Internet und einem internen Netzwerk. Dort liegen die Dienste, die öffentlich erreichbar sein müssen, etwa Web- und Mailserver. Alles andere bleibt hinter einer zweiten Grenze, sodass der Zugriff auf den öffentlichen Dienst nicht den Zugriff auf den Rest bedeutet.
Der Glossareintrag von Mozilla zur DMZ bringt die entscheidende Hälfte davon in einem einzigen Satzteil unter: Sie stellt nur bestimmte definierte Endpunkte bereit und verweigert gleichzeitig den Zugriff auf das interne Netzwerk von außen. Das ist das gesamte Entwurfsziel, formuliert ohne jeden Bezug auf Hardware.
Die Diensttypen, die dort klassischerweise stehen, ergeben sich aus dem Ziel. Webserver, Mailserver, FTP-Server, VoIP-Server: Dinge, zu denen Fremde sich verbinden können sollen. Verzeichnisdienste, Datenbanken, Dateifreigaben, interne Anwendungen und Verwaltungsoberflächen stehen nicht auf dieser Liste, denn von außen soll sie niemand erreichen.
Halten Sie sich an die Eigenschaft, nicht an das Bild. Drei Netzwerkschnittstellen sind eine Möglichkeit, eine eigene Vertrauensgrenze zu schaffen. Cloud- und Einzelserver-Designs können dasselbe Prinzip der Expositionskontrolle anders umsetzen, aber nur Designs mit einer eigenständigen Perimeterzone bilden die DMZ selbst nach.
Wie funktioniert die klassische DMZ mit drei Schnittstellen?
Die klassische DMZ wird auf zwei Arten gebaut. Ein Single-Firewall-Entwurf gibt einer Firewall drei Schnittstellen, je eine zum Internet, zur DMZ und zum internen Netzwerk. Ein Dual-Firewall-Entwurf legt die DMZ zwischen zwei getrennte Firewalls. Beide setzen dieselbe Regel durch. Das Internet erreicht die DMZ. Das Internet erreicht niemals das interne Netzwerk.
Das Single-Firewall-Modell (Three-Legged)
Eine Firewall, drei Netzwerkschnittstellen. Die erste zeigt zum Internet. Die zweite zeigt zur DMZ, wo die öffentlichen Dienste leben. Die dritte zeigt zum internen Netzwerk. Die Firewall erlaubt eingehenden Verkehr aus dem Internet zu bestimmten Ports in der DMZ, erlaubt eng begrenzten Verkehr von der DMZ nach innen, wo eine Anwendung es verlangt, und verweigert alles andere.
Der Name für diese Form ist Three-Legged-Firewall. Jedes Paket, das zwischen Zonen wechselt, läuft über ein einziges Gerät, womit diese Firewall zum Single Point of Failure für zonenübergreifenden Verkehr wird. Fällt sie aus, sind Konnektivität und Richtliniendurchsetzung betroffen, je nach Ausfallverhalten der Firewall und der von Ihnen vorgesehenen Redundanz.
Ich habe ein Jahrzehnt lang den Netzbetrieb bei einem ISP geleitet, und was die Leute an einer DMZ-Schnittstelle überraschte, war, wie unspektakulär sie war. Ein gewöhnlicher Ethernet-Port mit einem anderen Vertrauenslabel in der Firewall-Konfiguration. Die Architektur steckte nicht im Kupfer. Sie steckte im Regelwerk und darin, dass sich jemand sorgfältig überlegt hatte, in welche Richtung jeder Fluss erlaubt war.
Das Dual-Firewall-Modell (Rücken an Rücken)
Zwei Firewalls in Reihe, mit der DMZ dazwischen. Die äußere Firewall lässt Internetverkehr in die DMZ und nicht weiter. Die innere lässt nur den spezifischen Verkehr von der DMZ nach innen zu, den eine Anwendung braucht. Ein Angreifer, der die DMZ erreicht, muss immer noch die Richtliniengrenze der inneren Firewall überwinden, bevor er ins interne Netzwerk gelangt.
Zwei Firewalls geben Ihnen zwei getrennt durchgesetzte Richtliniengrenzen, sie bringen aber auch Konfiguration, Patching und Betriebsaufwand mit. Ein Ausfall oder eine Kompromittierung der äußeren Grenze entfernt die innere nicht automatisch, auch wenn der Schutz weiterhin davon abhängt, wie beide Firewalls konfiguriert und betrieben werden.
Ist eine DMZ dasselbe wie eine Firewall?
Nein. Eine DMZ ist ein eigenes Perimeternetz oder Netzwerksegment. Eine Firewall ist eine gängige Kontrolle, mit der der Verkehr zwischen dieser Zone, dem Internet und dem internen Netzwerk geregelt wird. Sie können Firewallregeln in einem flachen Netz konfigurieren, ohne eine DMZ zu schaffen, der Unterschied ist also architektonisch und nicht bloß eine Frage der Konfiguration.
Die Verwechslung ist nachvollziehbar. Die Firewall ist das Objekt, in das man sich einloggt, das Ding mit Konfigurationsdatei, Hersteller und Supportvertrag, also sammelt sie den Namen dessen ein, was sie hervorbringt. In ein Segment loggt sich nie jemand ein.
Die Folge zeigt sich im denkbar schlechtesten Moment. Nehmen Sie an, Ihr öffentlicher Webserver ist kompromittiert, denn irgendwann wird er es sein. In einem flachen Netz hat der Angreifer nun einen Brückenkopf auf einer Maschine, die bereits mit Ihrer Datenbank, Ihrem Dateiserver und Ihren Verwaltungsoberflächen sprechen darf, und der Wechsel zwischen ihnen ist bloß die Nutzung eines ohnehin erlaubten Zugriffs. Diese Seitwärtsbewegung heißt Lateral Movement, und genau dafür gibt es die zweite Grenze. Die DMZ verhindert nicht, dass der Webserver kompromittiert wird. Sie verhindert, dass ein kompromittierter Webserver zum Zugang zu allem anderen wird.
Eine Klarstellung, solange der Begriff vor Augen liegt: Die Einstellung „DMZ host“ an einem Heim- oder Kleinbüro-Router ist eine andere Funktion. Sie leitet unaufgeforderten eingehenden Verkehr an ein einzelnes internes Gerät weiter und setzt dieses Gerät direkt dem Internet aus; ein eigenes, geschütztes DMZ-Netz entsteht dabei nicht.
Wie wenden Sie DMZ-Prinzipien auf einem einzelnen Server an?
Ein einzelner Server mit einer öffentlichen IP kann einen Teil des Expositionsziels einer DMZ nachbilden, ohne deren Netztrennung nachzubilden. Ein Reverse Proxy kann der einzige öffentliche Eingang werden, eingehende Firewallregeln mit Default-Deny können den Rest blockieren, und interne Dienste können auf Loopback oder einer privaten Schnittstelle lauschen statt auf der öffentlichen Adresse.
Beginnen Sie mit der Randbedingung, die dieser Abschnitt voraussetzt: ein VPS, eine öffentliche Schnittstelle und keine separate Firewall-Appliance und kein DMZ-Subnetz unter Ihrer Kontrolle. In diesem Aufbau lässt sich die klassische Three-Legged-Topologie auf demselben Host nicht nachbauen. Host-Firewallregeln, die Wahl der Lauschadresse und ein Reverse Proxy können die Angriffsfläche weiterhin verkleinern, aber dieselbe Isolationsgrenze schaffen sie nicht.
Ein Reverse Proxy kann die öffentliche Schnittstelle auf den Ports 80 und 443 belegen und zum einzigen Eingang auf Anwendungsebene für Webverkehr werden. Das verkleinert die öffentliche Angriffsfläche, entspricht aber keiner separaten DMZ-Schnittstelle, denn der Proxy teilt sich den Host weiterhin mit den Diensten dahinter.
Die eingehenden Firewallregeln auf dem Host erlauben diese zwei Ports und verwerfen den Rest. Jeder andere Dienst auf der Maschine mag laufen und lauschen, aber von außen kann niemand eine Verbindung zu ihm aufbauen. Das kommt der Vorgabe „nur die vorgesehenen Ports sind erreichbar“ auf einem Host nahe; eine eigene Grenze zum internen Netz entsteht dadurch nicht.
Anwendungsserver, Datenbanken und Adminpanels sollten nicht auf der öffentlichen Adresse lauschen. Läuft der Proxy auf demselben Host, können sie auf Loopback lauschen; läuft er anderswo im privaten Netz, können sie auf einer privaten Adresse lauschen. In beiden Fällen gibt es für diese Dienste keinen Lauscher auf der öffentlichen Schnittstelle, sodass das Öffnen einer eingehenden Regel allein auf dieser Schnittstelle sie nicht freilegt.
Administrativer Zugang gehört auf die interne Seite, nicht auf die DMZ-Seite. SSH und Verwaltungsoberflächen aus dem öffentlichen Pfad herauszuhalten, hinter einem VPN oder einem privaten Netz, verhindert direkte Verbindungen dorthin aus dem öffentlichen Internet.
Wie lassen sich DMZ-Konzepte auf VPC-Subnetze und Sicherheitsgruppen abbilden?
Das klassische Modell lässt sich begrifflich recht eng auf Cloud-Netzwerkprimitive abbilden, aber nicht eins zu eins. Ein DMZ-Segment wird zu einem öffentlichen Subnetz. Das interne Netzwerk wird zu einem privaten Subnetz ohne Route zu einem Internet-Gateway. Das Regelwerk der Firewall verteilt sich auf Sicherheitsgruppen, die an Netzwerkschnittstellen von Ressourcen hängen, und Netzwerk-ACLs, die an Subnetzen hängen.
| Klassisches Element | Cloud-Entsprechung | Was es durchsetzt |
|---|---|---|
| DMZ-Segment | Öffentliches Subnetz | Stellt eine Internetroute bereit; eine Ressource braucht außerdem eine öffentliche Adresse und Sicherheitsregeln, die den Verkehr erlauben |
| Internes Netzwerksegment | Privates Subnetz | Keine direkte Route zum Internet-Gateway, sodass das Internet über diesen Weg keine direkten Verbindungen aufbauen kann |
| Firewall-Schnittstelle zwischen Zonen | Routing-Tabelle + angehängtes Internet-Gateway | Wohin Verkehr geleitet werden kann; öffentliche Adressierung und Sicherheitskontrollen bestimmen weiterhin, ob eine Ressource erreichbar ist |
| Firewall-Regelwerk (pro Zone) | Netzwerk-ACLs | Zustandslose Allow- und Deny-Regeln, ausgewertet an der Subnetzgrenze |
| Firewall-Regelwerk (pro Host) | Sicherheitsgruppen | Zustandsbehaftete Allow-Regeln, angewendet auf die Netzwerkschnittstellen der zugeordneten Ressourcen |
| Öffentlich erreichbarer Dienst in der DMZ | Load Balancer oder Proxy-Instanz im öffentlichen Subnetz | Der einzige Eingang, durch den der Verkehr laufen muss |
Cloud-Anbieter verwenden dieses Vokabular selbst, was ein gutes Indiz dafür ist, dass der Begriff weiterhin aktuell ist. Der Networking-Blog von AWS beschreibt eine DMZ-Architektur auf Amazon VPC die öffentlich erreichbare Dienste von internen Netzwerken isoliert und auf VPC Block Public Access aufbaut, einer im November 2024 eingeführten Kontrolle auf Regionsebene.
Die Subnetze sind der tragende Teil dieser Abbildung. Ein öffentliches Subnetz ist öffentlich, weil seine Routing-Tabelle auf ein Internet-Gateway zeigt. Da Routing-Tabellen entscheiden, wohin Pakete reisen, prägt der Zuschnitt der Subnetze Ihre Angriffsfläche noch vor jeder einzelnen Regel.
Die Abbildung ist an genau einer Stelle unvollkommen. Eine Firewall-Schnittstelle setzte eine Grenze für ein ganzes Segment durch; eine Sicherheitsgruppe dagegen hängt an der Netzwerkschnittstelle einer Ressource. Zwei Maschinen im selben privaten Subnetz können völlig unterschiedliche Sicherheitsgruppen tragen, sodass die Durchsetzung feinkörniger greift, als es eine physische Schnittstelle je vermochte. Das ist meist ein Fortschritt. Es bedeutet aber auch, dass der Name eines Subnetzes weniger darüber verrät, was erreichbar ist, als es ein Netzwerkdiagramm früher tat.
Wo die Einzelserver-Variante zu kurz greift
Auf einem Host teilen sich der öffentlich exponierte Prozess und die internen Dienste einen Kernel und eine Maschine. Getrennte Segmente zwingen einen Angreifer über eine Netzwerkgrenze, die eine Firewall inspiziert; ein einzelner Host tut das nicht. Das Einzelserver-Muster verkleinert die Angriffsfläche. Es bildet keine Trennung nach.
Wird der Reverse Proxy so kompromittiert, dass der Angreifer Codeausführung erhält, läuft dieser Code bereits auf der Maschine, auf der auch Ihre Datenbank läuft. Loopback-Binding hilft dann nicht, denn Loopback ist vom Host aus erreichbar. Container- oder Benutzerisolation kann den nötigen Aufwand erhöhen, aber Container auf demselben Host teilen sich weiterhin dessen Kernel. Im klassischen Modell war der nächste Schritt des Angreifers ein Paket über ein Kabel, das etwas inspizierte. Hier ist es ein lokaler Socket.
Die praktische Folge ist eine Schwelle, kein Urteil. Wenn das, was hinter dem Proxy steht, mehr wert ist als der Aufwand einer zweiten Maschine, nehmen Sie eine zweite Maschine und ein privates Netz dazwischen. Nichts aus diesem Artikel muss dafür neu gelernt werden, denn nichts davon ging je um die Hardware.
Entwickeln Sie auf einem Linux-VPS mit Root-Zugriff, NVMe und AMD-EPYC-Power.
Linux-Pläne ansehenDas Perimeter ist nicht mehr der einzige Ort, an dem Sicherheitsrichtlinien durchgesetzt werden können. Zero-Trust-Architektur beseitigt implizites Vertrauen aufgrund der Netzwerkposition, während private Konnektivität, gebaut mit WireGuard oder Tailscale die öffentliche Angriffsfläche verkleinern kann. Keiner der beiden Ansätze ersetzt automatisch Segmentierung oder Autorisierung. Meine Position zur engeren Frage ist eindeutig. Als mentales Modell: Sortieren Sie, was erreichbar ist, von dem, was es nicht ist, und wissen Sie, welche Grenze eine Kompromittierung einschließt. Diese Frage überlebt jede oben genannte Architektur, und genau darum lohnt es sich noch immer, sie zu beantworten.
Häufig gestellte Fragen
Ist eine DMZ dasselbe wie ein VPN?
Nein. Sie lösen verschiedene Probleme. Eine DMZ steuert, was nicht vertrauenswürdige Außenstehende erreichen können, indem sie eine kleine Menge Dienste bereitstellt und sonst nichts. Ein VPN gibt vertrauenswürdigen Außenstehenden einen privaten Weg hinein, indem es sie in ein Netzwerk authentifiziert, das sie sonst nicht erreichen würden. Viele Netze betreiben beides, und keines ersetzt das andere.
Ist eine DMZ sicher?
Eine DMZ macht einen exponierten Dienst nicht sicher. Sie begrenzt, wie weit dessen Kompromittierung reicht. Der öffentlich erreichbare Dienst bleibt öffentlich erreichbar, bleibt dem gesamten Internet ausgesetzt und braucht weiterhin Patches, Überwachung und Härtung aus eigenem Recht. Die DMZ entscheidet, was nach seinem Fall geschieht, nicht ob er fällt.
Brauche ich eine DMZ, wenn ich nur einen Server habe?
Nicht im klassischen Sinn, und auf einem einzelnen Host ließe sich ohnehin keine bauen. Die Drei-Schnittstellen-Topologie braucht getrennte Netzwerksegmente, und ein Server mit einer öffentlichen IP hat keines. Was Sie tun können, ist Exposition steuern: einen Reverse Proxy zum einzigen öffentlichen Eingang machen, die übrigen eingehenden Ports standardmäßig verweigern und interne Dienste auf Loopback oder einer privaten Adresse lauschen lassen. Das verkleinert, was das Internet erreichen kann, ohne den öffentlichen Dienst vom Rest des Hosts zu isolieren. Wenn das hinter dem Proxy mehr wert ist als die Kosten einer zweiten Maschine, nehmen Sie zwei Maschinen und ein privates Netz dazwischen.
Warum heißt es entmilitarisierte Zone?
Der Begriff ist dem militärischen Sinn entlehnt: ein Pufferbereich zwischen zwei gegnerischen Kräften, in dem keine von beiden voll das Sagen hat. Der Netzwerkgebrauch bewahrt die Metapher: Die DMZ gehört weder ganz dem nicht vertrauenswürdigen Außen noch ganz dem vertrauten Innen.
Diskussion
Kommentare
Melden Sie sich an, um mitzudiskutieren.