DMZ: Die entmilitarisierte Zone richtig aufbauen

Eine DMZ (Demilitarisierte Zone, auch entmilitarisierte Zone oder Perimeter-Netz) ist ein Netzabschnitt, der zwischen dem Internet und dem internen Netz liegt. Er beherbergt Systeme, die von außen erreichbar sein müssen – und schützt bei deren Kompromittierung das interne Netz.

Die Grundidee

Ohne DMZ steht ein öffentlich erreichbarer Webserver direkt im internen Netz. Wird er übernommen, hat der Angreifer freie Sicht auf alle internen Systeme. Mit DMZ gilt:

Internet
   |
   v
[ Firewall aussen ]
   |
   v
[ DMZ ]  Webserver, Mail-Relay, Reverse-Proxy, VPN-Endpunkt
   |
   v
[ Firewall innen ]
   |
   v
[ Internes Netz ]  Datenbanken, Dateiserver, Arbeitsplaetze, Verzeichnisdienst

Regel: Aus der DMZ darf NICHT alles ins interne Netz.
       Vom internen Netz darf in die DMZ administriert werden.
       Direktzugriff vom Internet ins interne Netz ist unterbunden.

Warum zwei Firewalls (oder eine mit drei Beinen)

Die Aufteilung hat einen konkreten Zweck: Selbst wenn ein System in der DMZ vollständig übernommen wurde, ist der Angreifer damit nicht automatisch im internen Netz. Er muss zusätzlich die innere Firewall überwinden. Das ist ein zusätzlicher, unabhängiger Kontrollpunkt.

# Variante A: Zwei getrennte Firewalls (hoechste Sicherheit)
#   Hersteller und Regelwerke getrennt -> ein Fehler in einer
#   Implementierung reicht nicht fuer den Durchbruch.
#   Nachteil: zwei Geraete, doppelter Verwaltungsaufwand.

# Variante B: Eine Firewall mit drei Beinen (haeufigste Praxis)
#   bein1: Internet
#   bein2: DMZ
#   bein3: internes Netz
#   Regeln: Internet <-> DMZ erlaubt (eingeschraenkt)
#           DMZ -> intern  NUR bestimmte Ziele und Ports
#           intern -> DMZ  erlaubt (Administration)
#           Internet -> intern  verboten
#   Vorteil: ein Regelwerk, eine Verwaltung.
#   Nachteil: ein Fehler in der Firewall betrifft alles.

Was in eine DMZ gehört

Öffentliche Webserver: Der klassische Fall.
Reverse-Proxy / Lastverteiler: Nimmt Anfragen an und leitet sie an die Anwendung im internen Netz weiter. Sehr wirkungsvoll, weil nur der Proxy erreichbar ist.
Mail-Gateway: Nimmt Mail von außen an, prüft sie und übergibt sie an den internen Mailserver.
VPN-Endpunkt: Der Zugangspunkt für Mitarbeiter von außen.
DNS-Server für öffentliche Zonen: Ausschließlich die externe Sicht.
Dateiübergabe: Ein Bereich für den Austausch mit Externen. Aber nicht als Freigabe umgesetzt, sondern als Upload-Endpunkt mit Prüfung – siehe unten.

Was NICHT in eine DMZ gehört

Datenbanken mit echten Daten. Wenn der Webserver in der DMZ auf die interne Datenbank zugreifen muss, ist ein genau abgestimmter Zugang nötig (Ziel, Port, Benutzer, nur von dieser Quelle, nur diese Abfragen). Besser: Die Anwendung selbst läuft im inneren Netz, und nur der Proxy steht in der DMZ.
Verzeichnisdienst und Domänencontroller. Ein Domänencontroller in der DMZ ist ein Angriffsziel ersten Ranges. Wenn Anmeldungen nötig sind, gehört ein eigener, isolierter Dienst dorthin – nicht der zentrale.
Administrationssysteme. Sprungpunkte gehören ins interne Netz oder in ein eigenes Verwaltungsnetz.
Arbeitsplätze. Ausnahmen für Home-Office-Rechner sind eine häufige Schwachstelle.
Backup-Systeme. Die Sicherung ist das Ziel eines Angriffs, nicht der Weg hinein.

Regeln einer Firewall mit drei Beinen

# Grundhaltung: alles verbieten, Ausnahmen ausdruecklich erlauben
policy drop

# Internet -> DMZ: nur die oeffentlichen Dienste
pass in on $internet proto tcp to $web_dmz port {80, 443} flags S/SA keep state
pass in on $internet proto tcp to $mail_dmz port {25, 587, 465, 993} flags S/SA keep state

# Antworten der DMZ ins Internet
pass out on $internet from $dmz_net to any flags S/SA keep state

# DMZ -> intern: NUR was absolut noetig ist, je Ziel einzeln
pass out on $intern from $web_dmz to $db_intern port 5432 flags S/SA keep state
block out on $intern from $dmz_net to any

# Intern -> DMZ: Administration und Zugriff
pass in on $intern from $admin_net to $dmz_net port {22, 443} keep state

# Internet -> intern: NICHTS
block in on $internet to $intern_net

# ICMP nur wo noetig
pass in on $internet inet proto icmp to $web_dmz icmp-type {echoreq} keep state
block in on $internet inet proto icmp to $intern_net

# Protokoll mitloggen, was abgewiesen wird (begrenzt!)
block log (all, to pflog0) in on $internet

Die wichtigsten Fallstricke

Die DMZ wird zur Brücke. Der häufigste Fehler ist eine Regel DMZ -> intern: any. Damit ist der Schutz aufgehoben – der Angreifer macht zwei Hüpfer statt einem. Jede Regel von der DMZ ins Innere muss begründet und auf Ziel sowie Port begrenzt sein.
Die gleichen Dienste von außen und innen. Ein Management-Zugang (SSH, Datenbank-Port, Admin-Oberfläche) darf nicht von außen erreichbar sein. Häufig wird vergessen, dass der Web-Dienst auch auf anderen Ports lauscht.
Datenbank in der DMZ. Naheliegend und falsch – siehe oben.
Backup in die DMZ. Sicherungen der DMZ-Systeme gehören ins interne Netz gezogen, nicht umgekehrt.
Kein Protokoll der abgewiesenen Verbindungen. Ohne Protokoll sieht man Angriffe erst, wenn sie erfolgreich waren.
Geteilte Konten zwischen DMZ und innen. Ein Benutzer, der in beiden Netzen gilt, hebt die Trennung teilweise auf. Getrennte Konten verwenden.
„Dateiaustausch“ als SMB-Freigabe. Eine Freigabe in der DMZ, die von innen gemountet wird, ist ein Durchgang für Schadsoftware. Dateien über einen Upload-Endpunkt annehmen und dann kontrolliert (Virenprüfung, Typbestimmung) ins Innere übernehmen.
Keine Überwachung der DMZ selbst. Gerade weil DMZ-Systeme öffentlich erreichbar sind, gehört dort ein eigener Beobachtungspunkt hin (IDS-Sensor, Dateiintegritätsprüfung).
Vergessene Testsysteme. Ein Testserver in der DMZ, der nie aktualisiert wird, ist ein offenes Tor. Inventar führen.
Verwaltung über die DMZ. Wer die DMZ von innen administriert, braucht einen klaren Weg (Sprungpunkt). Ein zweiter, unkontrollierter Weg (Fernwartungssoftware) hebt die Trennung auf.

Prüfliste

Sind alle Regeln von der DMZ ins interne Netz einzeln begründet und auf Ziel sowie Port begrenzt?
Ist jede Management-Oberfläche von außen unerreichbar?
Liegen echte Daten im internen Netz und nur Datenkopien oder gar keine Daten in der DMZ?
Gibt es getrennte Konten für DMZ und internes Netz?
Wird protokolliert, was abgewiesen wird – und wird es ausgewertet?
Sind allen DMZ-Systeme inventarisiert, aktualisiert und überwacht?
Ist der Weg vom Internet ins interne Netz an jeder Stelle unterbunden – auch über IPv6, WLAN-Gastnetze und Fernwartung?
Gibt es einen dokumentierten Ausnahmeprozess, wenn ein Dienst doch Zugriff braucht?

Verwandte Grundlagen: Firewall, IDS und IPS, Netzwerksegmentierung, NAT und Portweiterleitung.

Netzwerk: Sicherheit