# 11.4 DMZ und Sicherheitszonen im Detail DMZ steht für: Demilitarized Zone Eine DMZ ist ein separates Netzwerksegment für Dienste, die von außen erreichbar sein müssen. Typische Dienste in einer DMZ: - Webserver - Reverse Proxy - Mailgateway - VPN-Gateway - öffentlicher DNS-Server - öffentliche API - Proxyserver - Bastion Host Merksatz: DMZ = eigenes Netz für öffentlich erreichbare Dienste. --- **Warum braucht man eine DMZ?** Öffentlich erreichbare Dienste sind stärker gefährdet als rein interne Dienste. Beispiel: Ein Webserver ist aus dem Internet erreichbar. Wenn dieser Webserver kompromittiert wird, soll der Angreifer nicht direkt Zugriff auf das interne LAN bekommen. Die DMZ trennt deshalb öffentliche Dienste vom internen Netz. Merksatz: Eine DMZ begrenzt den Schaden, wenn ein öffentlich erreichbarer Dienst angegriffen wird. --- **Grundidee einer DMZ** Eine DMZ liegt logisch zwischen: externem Netz und internem Netz Vereinfacht: Internet → Firewall → DMZ → Firewall-Regeln → internes LAN Die DMZ ist nicht so vertrauenswürdig wie das interne LAN. Aber sie ist kontrollierter als das Internet. Merksatz: DMZ liegt kontrolliert zwischen außen und innen. --- **DMZ ist nicht das interne LAN** Ein häufiger Fehler ist: Ein öffentlich erreichbarer Server steht direkt im internen LAN. Das ist riskant. Besser: öffentliche Dienste in DMZ stellen und Zugriffe ins LAN stark einschränken. Warum? Wird ein DMZ-System kompromittiert, soll der Angreifer nicht automatisch interne Clients, Server oder Verwaltungsdienste erreichen. Merksatz: Öffentliche Dienste gehören nicht ungefiltert ins interne LAN. --- **DMZ als Sicherheitszone** Eine DMZ ist eine Sicherheitszone. Eine Sicherheitszone ist ein Netzbereich mit eigenem Schutzbedarf. Typische Zonen: - WAN - LAN - DMZ - Servernetz - Managementnetz - Gastnetz - IoT-Netz - VPN-Zone Zwischen diesen Zonen gelten Firewall-Regeln. Merksatz: Sicherheitszonen trennen Netze nach Vertrauensniveau. --- **Vertrauensniveau von Zonen** Nicht jedes Netz ist gleich vertrauenswürdig. Beispiel: | Zone | Vertrauensniveau | Beispiel | |---|---|---| | WAN | sehr gering | Internet | | Gastnetz | gering | Besuchergeräte | | IoT-Netz | gering bis mittel | Kameras, Sensoren | | DMZ | mittel / eingeschränkt | öffentliche Dienste | | LAN | höher | interne Clients | | Servernetz | hoch | interne Server | | Managementnetz | sehr hoch | Adminzugänge | Merksatz: Je kritischer eine Zone ist, desto strenger müssen Zugriffe kontrolliert werden. --- **Typischer Drei-Zonen-Aufbau** Ein klassischer Aufbau besteht aus drei Zonen: WAN DMZ LAN WAN: externes Netz oder Internet DMZ: öffentliche Dienste LAN: internes Unternehmensnetz Merksatz: Drei-Zonen-Aufbau = WAN, DMZ, LAN. --- **Beispielaufbau** Vereinfacht: Internet | Firewall / \ DMZ LAN Web Clients Mail interne Server Die Firewall kontrolliert, welche Zone mit welcher Zone kommunizieren darf. Merksatz: Die Firewall ist der kontrollierte Übergang zwischen den Zonen. --- **Regelidee Internet zur DMZ** Vom Internet zur DMZ sollte nur erlaubt sein, was wirklich öffentlich erreichbar sein muss. Beispiele: | Quelle | Ziel | Dienst | Aktion | |---|---|---|---| | Internet | Reverse Proxy DMZ | HTTPS TCP 443 | erlauben | | Internet | Mailgateway DMZ | SMTP TCP 25 | erlauben | | Internet | VPN-Gateway DMZ | VPN-Port | erlauben | | Internet | DMZ-Server | SSH TCP 22 | blockieren | | Internet | interne Server | any | blockieren | Merksatz: Internet darf nur notwendige öffentliche Dienste in der DMZ erreichen. --- **Regelidee DMZ zum LAN** Von der DMZ ins LAN sollte sehr wenig erlaubt sein. Beispiele: | Quelle | Ziel | Dienst | Aktion | |---|---|---|---| | Reverse Proxy DMZ | interner Webdienst | TCP 8080 | erlauben | | Webserver DMZ | Datenbankserver | TCP 5432 | nur wenn nötig | | Mailgateway DMZ | interner Mailserver | SMTP | nur gezielt | | DMZ allgemein | LAN allgemein | any | blockieren | Wichtig: DMZ darf keine freie Brücke ins interne Netz sein. Merksatz: Von DMZ ins LAN nur das zwingend Notwendige erlauben. --- **Regelidee LAN zur DMZ** Das interne LAN darf je nach Bedarf Dienste in der DMZ erreichen. Beispiele: interne Clients → DMZ-Webserver HTTPS Admin-Netz → DMZ-Server SSH Monitoring → DMZ-Systeme SNMP Aber auch hier gilt: nicht alles für jeden erlauben. Merksatz: Auch LAN zur DMZ sollte gezielt geregelt werden. --- **Regelidee Management zur DMZ** Administration sollte nicht aus beliebigen Netzen erlaubt sein. Besser: Managementnetz oder Bastion Host oder VPN-Adminzugang Beispiel: Managementnetz → DMZ-Server SSH TCP 22 erlauben Aber nicht: gesamtes LAN → DMZ-Server SSH erlauben Und erst recht nicht: Internet → DMZ-Server SSH erlauben Merksatz: Administration nur aus kontrollierten Managementbereichen erlauben. --- **DMZ und Reverse Proxy** Ein Reverse Proxy steht häufig in der DMZ. Er nimmt externe HTTPS-Anfragen entgegen und leitet sie an interne Dienste weiter. Beispiel: Internet → Reverse Proxy DMZ → interner Wiki-Server Vorteile: - zentrale TLS-Verwaltung - weniger direkte Veröffentlichung interner Server - mehrere Dienste über eine öffentliche IP - Zugriffskontrolle - bessere Protokollierung - Trennung zwischen extern und intern Merksatz: Reverse Proxy in der DMZ schützt interne Webdienste besser als direkte Freigabe. --- **DMZ und Webserver** Ein Webserver in der DMZ kann öffentliche Webseiten bereitstellen. Wichtig: Der Webserver sollte nur die internen Systeme erreichen, die er wirklich braucht. Beispiel: Webserver braucht Datenbankzugriff. Dann gilt: Webserver DMZ → Datenbankserver TCP 5432 erlauben Aber nicht: Webserver DMZ → gesamtes LAN any erlauben Merksatz: Webserver in DMZ nur mit notwendigen Backend-Zugriffen ausstatten. --- **DMZ und Mailgateway** Ein Mailgateway in der DMZ kann E-Mails aus dem Internet annehmen. Typische Aufgabe: Internet → Mailgateway DMZ Mailgateway prüft Spam und Malware Mailgateway leitet an internen Mailserver weiter Vorteil: Der interne Mailserver steht nicht direkt im Internet. Merksatz: Mailgateway in der DMZ schützt interne Mailserver. --- **DMZ und VPN-Gateway** Ein VPN-Gateway kann in der DMZ stehen. Ablauf: externer Benutzer verbindet sich zum VPN-Gateway nach erfolgreicher Anmeldung erhält er Zugriff auf erlaubte interne Ressourcen Wichtig: VPN-Zugriff darf nicht automatisch das gesamte LAN erlauben. Besser: VPN-Benutzer in eigene Zone einordnen und gezielte Regeln setzen. Merksatz: VPN-Gateway kann in der DMZ stehen, aber VPN-Rechte müssen begrenzt werden. --- **DMZ und öffentlicher DNS** Ein öffentlicher DNS-Server kann in einer DMZ stehen, wenn eine Organisation eigene öffentliche DNS-Zonen bereitstellt. Wichtig: öffentlicher DNS sollte nur öffentliche Informationen enthalten. Interne Servernamen sollten nicht öffentlich sichtbar sein. Merksatz: Öffentlicher DNS darf keine internen Strukturen verraten. --- **DMZ und Bastion Host** Ein Bastion Host ist ein besonders abgesicherter Sprungserver. Er kann genutzt werden, um administrative Zugriffe auf DMZ-Systeme zu bündeln. Ablauf: Admin → VPN oder Managementnetz → Bastion Host → DMZ-System Vorteile: - zentrale Kontrolle - bessere Protokollierung - weniger direkte Adminzugänge - zusätzliche Sicherheitsprüfung Merksatz: Bastion Host bündelt und kontrolliert Adminzugriffe. --- **Bastion Host ist besonders kritisch** Ein Bastion Host hat oft Zugriff auf wichtige Systeme. Deshalb muss er besonders geschützt werden. Maßnahmen: - MFA - starke Authentifizierung - nur Admins erlauben - Protokollierung - regelmäßige Updates - keine unnötigen Dienste - harte Firewall-Regeln - Monitoring - getrennte Admin-Konten Merksatz: Bastion Host stark absichern, weil er ein zentraler Zugangspunkt ist. --- **DMZ und Datenbankserver** Datenbankserver sollten normalerweise nicht direkt in der öffentlichen DMZ stehen. Besser: Datenbank im internen Servernetz und nur gezielter Zugriff vom Webserver oder Anwendungsserver Beispiel: Webserver DMZ → Datenbankserver TCP 5432 Wichtig: kein allgemeiner Zugriff von Internet oder DMZ auf Datenbank. Merksatz: Datenbanken nicht öffentlich platzieren. --- **DMZ und interne Daten** DMZ-Systeme sollten möglichst wenig interne Daten enthalten. Warum? Sie sind stärker exponiert. Wenn sensible Daten in der DMZ liegen, ist das Risiko bei einem Angriff höher. Besser: DMZ-Systeme nur mit notwendigen Daten ausstatten und interne Datenbanken geschützt halten. Merksatz: In der DMZ nur Daten, die dort wirklich benötigt werden. --- **DMZ und Protokollierung** DMZ-Systeme sollten gut protokolliert werden. Wichtige Logs: - Firewall-Logs - Webserver-Logs - Reverse-Proxy-Logs - Authentifizierungslogs - Systemlogs - IDS/IPS-Logs - VPN-Logs - Mailgateway-Logs Logs helfen bei: - Angriffserkennung - Fehlersuche - Nachvollziehbarkeit - Sicherheitsanalyse Merksatz: DMZ-Systeme brauchen gute Logs. --- **DMZ und Monitoring** DMZ-Systeme sollten überwacht werden. Typische Prüfwerte: - Erreichbarkeit - CPU - RAM - Speicherplatz - Dienste - Zertifikate - Loggröße - ungewöhnliche Verbindungen - fehlgeschlagene Logins - Updates - offene Ports Merksatz: DMZ-Systeme müssen aktiv überwacht werden. --- **DMZ und IDS/IPS** IDS steht für: Intrusion Detection System IPS steht für: Intrusion Prevention System IDS erkennt verdächtigen Verkehr. IPS kann verdächtigen Verkehr zusätzlich blockieren. In einer DMZ können IDS/IPS-Systeme helfen, Angriffe auf öffentliche Dienste zu erkennen. Merksatz: IDS erkennt. IPS blockiert zusätzlich. --- **DMZ und WAF** WAF steht für: Web Application Firewall Eine WAF schützt Webanwendungen auf Anwendungsebene. Sie prüft zum Beispiel HTTP-Anfragen auf: - SQL-Injection - Cross-Site Scripting - ungewöhnliche Muster - bekannte Angriffsversuche - fehlerhafte Requests Eine WAF ersetzt keine sichere Anwendung, kann aber zusätzlichen Schutz bieten. Merksatz: WAF schützt Webanwendungen auf Schicht 7. --- **DMZ und TLS** Öffentliche Dienste in der DMZ nutzen häufig TLS. Beispiele: HTTPS SMTPS IMAPS LDAPS VPN mit Zertifikaten Wichtig: Zertifikate aktuell halten private Schlüssel schützen TLS-Versionen sicher konfigurieren Zertifikatskette vollständig liefern Merksatz: Öffentliche Dienste brauchen saubere TLS-Konfiguration. --- **TLS-Terminierung in der DMZ** TLS-Terminierung bedeutet: TLS endet am Reverse Proxy oder Load Balancer. Ablauf: Client → HTTPS → Reverse Proxy DMZ Reverse Proxy → HTTP oder HTTPS → Backend Vorteile: - zentrale Zertifikatsverwaltung - Entlastung der Backendserver - bessere Kontrolle - einheitliche Sicherheitsrichtlinien Wichtig: Die interne Verbindung sollte je nach Schutzbedarf ebenfalls gesichert werden. Merksatz: TLS-Terminierung beendet TLS an einem zentralen Punkt. --- **TLS Passthrough** TLS Passthrough bedeutet: Die TLS-Verbindung wird durchgereicht, ohne am Proxy entschlüsselt zu werden. Ablauf: Client → TLS → Proxy → TLS → Backend Vorteil: Ende der TLS-Verbindung liegt am Backend. Nachteil: Proxy kann Inhalte weniger gut prüfen oder steuern. Merksatz: TLS Passthrough reicht verschlüsselten Verkehr weiter. --- **DMZ und Updates** DMZ-Systeme sind oft exponiert. Deshalb sind Updates besonders wichtig. Betroffen sind: - Betriebssystem - Webserver - Reverse Proxy - Anwendung - Frameworks - Bibliotheken - VPN-Software - Mailgateway - TLS-Komponenten Merksatz: Exponierte Systeme müssen besonders konsequent aktualisiert werden. --- **DMZ und Härtung** Härtung bedeutet: Systeme sicher konfigurieren und unnötige Angriffsflächen reduzieren. Maßnahmen: - unnötige Dienste deaktivieren - Standardpasswörter ändern - Adminzugänge beschränken - Updates einspielen - Dateirechte prüfen - sichere TLS-Konfiguration - Logging aktivieren - nur notwendige Ports öffnen - Dienstkonten begrenzen Merksatz: Härtung reduziert Angriffsfläche. --- **DMZ und Least Privilege** Auch in der DMZ gilt: nur notwendige Rechte vergeben. Beispiele: Webdienstkonto braucht keinen Domain-Admin. Reverse Proxy braucht nur Zugriff auf definierte Backends. Monitoring braucht nur Leserechte. Adminzugriff nur für Admins. Merksatz: Least Privilege gilt auch für Dienste und Server. --- **DMZ und Netzwerksegmentierung** Netzwerksegmentierung bedeutet: Netzbereiche werden getrennt, damit nicht alle Systeme frei miteinander kommunizieren können. Die DMZ ist ein Beispiel für Segmentierung. Weitere Segmentierung: - Servernetz - Datenbanknetz - Managementnetz - Backupnetz - Gastnetz - IoT-Netz Merksatz: Segmentierung begrenzt Bewegungsfreiheit bei Angriffen. --- **Laterale Bewegung** Laterale Bewegung bedeutet: Ein Angreifer bewegt sich nach einem ersten Einbruch weiter im Netzwerk. Beispiel: Angriff auf Webserver in DMZ. Danach Versuch, interne Server oder Datenbanken zu erreichen. Segmentierung und Firewall-Regeln sollen das erschweren. Merksatz: DMZ soll laterale Bewegung ins LAN erschweren. --- **DMZ und Zero Trust** Zero Trust bedeutet vereinfacht: keinem Zugriff automatisch vertrauen. Auch DMZ-Systeme werden nicht automatisch als sicher betrachtet. Prinzipien: - Identität prüfen - Zugriff begrenzen - Verbindungen protokollieren - nur notwendige Dienste erlauben - Systeme überwachen - Rechte regelmäßig prüfen Merksatz: Auch innerhalb des Netzes nicht blind vertrauen. --- **DMZ und Hochverfügbarkeit** Öffentliche Dienste sollen oft zuverlässig erreichbar sein. Möglichkeiten: - zwei Firewalls - zwei Reverse Proxys - Load Balancer - redundante Internetanschlüsse - mehrere Server - Monitoring - automatischer Failover - regelmäßige Backups Merksatz: DMZ-Dienste brauchen je nach Kritikalität Verfügbarkeit und Redundanz. --- **DMZ und Backup** DMZ-Systeme brauchen Backups, aber Backups dürfen nicht unsicher erreichbar sein. Wichtig: - Backupzugriff einschränken - Backupdaten schützen - keine Schreibrechte aus DMZ auf zentrale Backups ohne Kontrolle - Wiederherstellung testen - Ransomware-Risiko beachten Merksatz: DMZ-Systeme sichern, aber Backup-Infrastruktur schützen. --- **DMZ und Datenfluss** Bei einer DMZ muss man Datenflüsse genau kennen. Fragen: Wer spricht mit wem? Welche Anwendung? Welcher Port? Welche Richtung? Welche Daten? Wie sensibel sind die Daten? Wird verschlüsselt? Wird protokolliert? Ist der Zugriff notwendig? Merksatz: DMZ-Regeln entstehen aus klaren Datenflüssen. --- **Datenflussdiagramm für DMZ** Ein einfaches Datenflussdiagramm kann zeigen: Internet → Reverse Proxy TCP 443 Reverse Proxy → interner Webdienst TCP 8080 interner Webdienst → Datenbank TCP 5432 Monitoring → Reverse Proxy SNMP oder Agent-Port Admin-Netz → Reverse Proxy SSH So erkennt man, welche Regeln wirklich nötig sind. Merksatz: Datenflüsse sichtbar machen, bevor Regeln erstellt werden. --- **DMZ und Richtung der Verbindungen** Die Richtung der Verbindung ist wichtig. Beispiel: Internet startet Verbindung zum Reverse Proxy. Reverse Proxy startet Verbindung zum Backend. Backend sollte normalerweise nicht beliebig Verbindungen ins Internet starten. Firewall-Regeln müssen nach der tatsächlichen Verbindungsrichtung erstellt werden. Merksatz: Regeln nach Verbindungsstart planen. --- **DMZ und ausgehender Verkehr** Auch ausgehender Verkehr aus der DMZ sollte kontrolliert werden. Warum? Ein kompromittiertes DMZ-System könnte versuchen: - Schadsoftware nachzuladen - Daten abzuziehen - Verbindung zu Command-and-Control-Servern aufzubauen - interne Systeme zu scannen - Spam zu versenden Merksatz: DMZ outbound nicht blind erlauben. --- **DMZ und DNS** DMZ-Systeme brauchen oft DNS. Aber: Sie sollten möglichst definierte DNS-Resolver nutzen. Regelidee: DMZ-Systeme → interner oder DMZ-DNS UDP/TCP 53 erlauben Nicht ideal: DMZ-Systeme → beliebige externe DNS-Server erlauben Merksatz: DNS aus der DMZ kontrollieren. --- **DMZ und NTP** DMZ-Systeme brauchen korrekte Uhrzeit. NTP ist wichtig für: - Zertifikate - Logs - Authentifizierung - Monitoring - Fehlersuche Regelidee: DMZ-Systeme → freigegebener NTP-Server UDP 123 Merksatz: DMZ-Systeme brauchen kontrollierte Zeitsynchronisation. --- **DMZ und Namenskonzept** Ein sauberes Namenskonzept hilft bei DMZ-Diensten. Beispiele: extern: www.firma.de vpn.firma.de mail.firma.de intern: reverseproxy01.dmz.firma.local mailgw01.dmz.firma.local Wichtig: öffentliche Namen, interne Namen und Zertifikate müssen zusammenpassen. Merksatz: DNS-Namen und Zertifikate sauber planen. --- **DMZ und interne Authentifizierung** Manchmal müssen DMZ-Dienste Benutzer gegen interne Verzeichnisdienste prüfen. Beispiel: Webanwendung in DMZ nutzt LDAP oder SSO. Problem: Direkter Zugriff aus DMZ auf interne Domain Controller kann riskant sein. Mögliche Lösungen: - gezielte LDAPS-Regeln - Reverse Proxy mit Authentifizierung - Federation / SSO - getrennte Identitätsdienste - Proxy-Dienst für Authentifizierung Merksatz: Authentifizierung aus der DMZ ins LAN nur gezielt und sicher erlauben. --- **DMZ und Datenbankzugriff** Wenn DMZ-Systeme Datenbankzugriff brauchen, sollte dieser stark begrenzt werden. Prüfen: Muss die Datenbank wirklich intern stehen? Welche Quelle darf zugreifen? Welcher Port? Welches Konto? Welche Rechte? Ist TLS nötig? Gibt es Protokollierung? Gibt es Eingabevalidierung in der Anwendung? Merksatz: Datenbankzugriff aus der DMZ ist kritisch. --- **DMZ und direkte Internetzugriffe** Nicht jedes DMZ-System braucht freien Internetzugang. Beispiele für notwendige ausgehende Verbindungen: Updateserver Zertifikatsprüfung Paketquellen Monitoring externe API Besser: gezielte Ziele erlauben oder Proxy nutzen Merksatz: DMZ-Systeme nicht beliebig ins Internet lassen. --- **DMZ und öffentliche APIs** Öffentliche APIs sollten besonders geschützt werden. Maßnahmen: - HTTPS - Authentifizierung - Autorisierung - Rate Limiting - Eingabevalidierung - Logging - Monitoring - WAF - API-Gateway - keine unnötigen Daten ausgeben Merksatz: Öffentliche API = stark exponierter Schicht-7-Dienst. --- **DMZ und Fehlersuche** Bei DMZ-Problemen prüft man systematisch: 1. DNS zeigt richtig? 2. öffentliche IP korrekt? 3. NAT oder Portweiterleitung korrekt? 4. Firewall-Regel WAN → DMZ korrekt? 5. Dienst in DMZ läuft? 6. Host-Firewall erlaubt Zugriff? 7. Zertifikat passt? 8. Proxy leitet korrekt weiter? 9. Regel DMZ → Backend korrekt? 10. Backend läuft? 11. Logs prüfen. Merksatz: DMZ-Fehlersuche braucht DNS, NAT, Firewall, Dienst und Backend. --- **Fehlerbild: Öffentlicher Webdienst nicht erreichbar** Mögliche Ursachen: - DNS zeigt auf falsche öffentliche IP - NAT-Regel fehlt - Firewall-Regel fehlt - Reverse Proxy down - Webserver hört nicht auf Port - Host-Firewall blockiert - Zertifikatfehler - falscher virtueller Host - Backend nicht erreichbar - Provider oder CGNAT-Problem Merksatz: Öffentlicher Webdienst braucht komplette Kette von DNS bis Backend. --- **Fehlerbild: Reverse Proxy zeigt 502** Mögliche Ursachen: - Backend läuft nicht - falscher Backend-Port - falsches Protokoll HTTP/HTTPS - Firewall DMZ → Backend blockiert - Backend-DNS falsch - Container-Name oder interner Hostname falsch - Backend antwortet ungültig - Timeout Merksatz: 502 bedeutet oft: Proxy erreicht Backend nicht sauber. --- **Fehlerbild: DMZ-Server erreicht LAN nicht** Mögliche Ursachen: - Firewall-Regel fehlt - falsche Richtung - falsches Ziel - falscher Port - Route fehlt - Rückweg fehlt - Zielserver-Firewall blockiert - DNS löst intern falsch auf - Regel durch frühere Blockregel verdeckt Merksatz: DMZ zu LAN nur gezielt erlauben und sauber prüfen. --- **Fehlerbild: DMZ-Server kann Updates nicht laden** Mögliche Ursachen: - kein ausgehender Internetzugang erlaubt - DNS nicht erlaubt - Proxy erforderlich - Zertifikatsprüfung schlägt fehl - NTP falsch und Zertifikat wirkt ungültig - Paketquelle blockiert - Firewall-Regel zu eng Merksatz: Auch ausgehender DMZ-Verkehr braucht passende Regeln. --- **Fehlerbild: Zertifikat passt intern, extern aber nicht** Mögliche Ursachen: - extern anderer Hostname - Reverse Proxy liefert falsches Zertifikat - DNS zeigt auf falsche IP - Split DNS falsch - Zertifikat enthält externen Namen nicht - SNI-Konfiguration falsch Merksatz: Zertifikat muss zum tatsächlich aufgerufenen Namen passen. --- **SNI kurz erklärt** SNI steht für: Server Name Indication SNI ermöglicht, dass ein Server mehrere TLS-Zertifikate für verschiedene Hostnamen auf derselben IP anbieten kann. Beispiel: wiki.firma.de cloud.firma.de git.firma.de alle über: dieselbe öffentliche IP und TCP 443 Der Client teilt beim TLS-Aufbau den gewünschten Hostnamen mit. Merksatz: SNI hilft bei mehreren HTTPS-Diensten auf einer IP. --- **DMZ und Prüfungsdenken** In Prüfungsaufgaben wird oft erwartet, dass man erkennt: Öffentliche Dienste gehören in die DMZ. Interne Systeme gehören nicht direkt ins Internet. DMZ-Systeme dürfen nur notwendige Verbindungen ins LAN aufbauen. Firewall-Regeln müssen Quelle, Ziel, Dienst und Richtung enthalten. NAT und Firewall-Regeln müssen zusammenpassen. Merksatz: DMZ-Aufgaben immer mit Zonen und Datenflüssen lösen. --- **Was eine DMZ nicht macht** Eine DMZ macht nicht automatisch: - Webserver sicher - Software aktuell - Passwörter stark - TLS korrekt - Anwendung fehlerfrei - Datenbank geschützt - Angriffe unmöglich - Logs ausgewertet - Backups vorhanden Eine DMZ reduziert Risiken, ersetzt aber keine weiteren Sicherheitsmaßnahmen. Merksatz: DMZ ist Netztrennung, kein vollständiges Sicherheitskonzept. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Wofür steht DMZ? - Was ist der Zweck einer DMZ? - Welche Systeme gehören typischerweise in eine DMZ? - Warum stehen öffentliche Server besser in der DMZ als im LAN? - Welche Regeln braucht ein Webserver in der DMZ? - Warum sollte die DMZ nicht frei ins LAN dürfen? - Was ist ein Reverse Proxy in der DMZ? - Was ist ein Bastion Host? - Was ist der Unterschied zwischen LAN, WAN und DMZ? - Warum sind Sicherheitszonen sinnvoll? - Was bedeutet Netzwerksegmentierung? - Was ist laterale Bewegung? - Welche Rolle spielen Firewall-Regeln zwischen Zonen? - Warum muss auch ausgehender Verkehr aus der DMZ kontrolliert werden? - Warum ist Monitoring in der DMZ wichtig? --- **Typische Prüfungsfallen** DMZ steht für Demilitarized Zone. DMZ ist ein separates Netz. DMZ ist nicht das interne LAN. Öffentliche Dienste gehören besser in die DMZ. DMZ schützt das LAN durch Trennung. DMZ darf nicht ungefiltert ins LAN. Internet darf nur notwendige DMZ-Dienste erreichen. Adminzugriff auf DMZ nicht aus dem gesamten Internet erlauben. Reverse Proxy kann in der DMZ stehen. Mailgateway kann in der DMZ stehen. VPN-Gateway kann in der DMZ stehen. Datenbankserver normalerweise nicht öffentlich in die DMZ stellen. DMZ-Systeme brauchen Updates und Härtung. DMZ-Systeme brauchen Monitoring und Logs. Firewall-Regeln zwischen Zonen müssen Richtung beachten. DMZ outbound ebenfalls kontrollieren. NAT-Regeln und Firewall-Regeln müssen zusammenpassen. DMZ ersetzt keine sichere Anwendung. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | DMZ | separates Netz für öffentlich erreichbare Dienste | | Sicherheitszone | Netzbereich mit eigenem Schutzbedarf | | WAN | externes Netz oder Internet | | LAN | internes Netz | | Managementnetz | Netz für Administration | | Gastnetz | separates Netz für Gäste | | Reverse Proxy | nimmt Anfragen an und leitet an Backends weiter | | Mailgateway | Mailserver-Schutz- oder Weiterleitungssystem | | VPN-Gateway | Einstiegspunkt für VPN-Verbindungen | | Bastion Host | abgesicherter Sprungserver | | Segmentierung | Aufteilung in getrennte Netzbereiche | | laterale Bewegung | Bewegung eines Angreifers innerhalb des Netzes | | IDS | erkennt Angriffe | | IPS | erkennt und blockiert Angriffe | | WAF | Web Application Firewall | | TLS-Terminierung | TLS endet am Proxy oder Load Balancer | | TLS Passthrough | TLS wird verschlüsselt weitergereicht | | SNI | Hostname-Anzeige beim TLS-Aufbau | | Härtung | sichere Konfiguration eines Systems | --- **IHK-sichere Kurzformulierung** Eine DMZ, also Demilitarized Zone, ist ein separates Netzwerksegment für Dienste, die aus dem Internet erreichbar sein müssen. Typische Systeme in einer DMZ sind Webserver, Reverse Proxys, Mailgateways oder VPN-Gateways. Der Zweck einer DMZ besteht darin, öffentliche Dienste vom internen LAN zu trennen und dadurch das interne Netz besser zu schützen. Zwischen WAN, DMZ und LAN werden gezielte Firewall-Regeln eingerichtet. Aus dem Internet sollten nur notwendige Dienste in der DMZ erreichbar sein, und von der DMZ ins interne LAN sollten nur zwingend erforderliche Verbindungen erlaubt werden. Eine DMZ reduziert Risiken, ersetzt aber keine Updates, Härtung, sichere Anwendungen, Monitoring oder Protokollierung. --- **Merksätze** DMZ = Demilitarized Zone. DMZ = separates Netz für öffentliche Dienste. DMZ ist nicht LAN. DMZ liegt zwischen Internet und internem Netz. Öffentliche Dienste gehören besser in die DMZ. DMZ schützt internes LAN durch Trennung. Internet → DMZ nur notwendige Dienste erlauben. Internet → LAN blockieren. DMZ → LAN nur zwingend notwendige Verbindungen erlauben. LAN → DMZ gezielt erlauben. Adminzugriff nur aus Managementnetz oder über Bastion Host. Reverse Proxy kann in der DMZ stehen. Mailgateway kann in der DMZ stehen. VPN-Gateway kann in der DMZ stehen. Datenbanken nicht direkt öffentlich platzieren. DMZ outbound kontrollieren. DNS und NTP für DMZ gezielt erlauben. DMZ-Systeme brauchen Updates. DMZ-Systeme brauchen Härtung. DMZ-Systeme brauchen Monitoring. DMZ-Systeme brauchen Logs. IDS erkennt Angriffe. IPS blockiert zusätzlich. WAF schützt Webanwendungen. TLS-Terminierung endet am Proxy. TLS Passthrough reicht TLS weiter. SNI ermöglicht mehrere HTTPS-Namen auf einer IP. Segmentierung begrenzt laterale Bewegung. DMZ ersetzt kein vollständiges Sicherheitskonzept.