Einen öffentlichen Dienst in einer DMZ absichern

Das Kulturforum Nord will sein neues Veranstaltungsportal veröffentlichen. Besucherinnen und Besucher sollen Termine ansehen und Anmeldungen über HTTPS absenden können. Der Webzugang steht deshalb in einer demilitarisierten Zone (DMZ). Die eigentliche Anwendung und die Anmeldedaten bleiben im internen Netz.

Kurz vor der Freigabe liegt nur dieser Wunsch vor: “Der Dienst soll aus dem Internet erreichbar sein.” Für ein Firewall-Regelwerk reicht das nicht. Du musst klären, welches System mit welchem Ziel über welches Protokoll kommunizieren darf. Genauso wichtig ist die Gegenfrage: Welche Verbindung darf gerade nicht entstehen?

Was du für die Aufgabe brauchst

Du solltest IP-Adressen, TCP und typische Dienstports grundsätzlich einordnen können. Du brauchst keine Erfahrung mit einem bestimmten Firewall-Produkt. Die Regeln in dieser Lektion beschreiben eine herstellerunabhängige Sicherheitsabsicht.

Nach der Lektion kannst du:

• Vertrauensgrenzen einer DMZ erklären,
• aus einem Dienstablauf minimale Datenflüsse ableiten,
• zustandsbehaftete Regeln formulieren,
• Administration und Protokollierung gesondert behandeln,
• erlaubte und verbotene Verbindungen gezielt testen.

Eine DMZ begrenzt Verbindungen

Eine DMZ ist ein eigener Netzbereich für Systeme, die aus einem weniger vertrauenswürdigen Netz erreichbar sein müssen. In unserem Szenario ist das Internet weniger vertrauenswürdig als die DMZ. Die DMZ ist wiederum weniger vertrauenswürdig als das interne Netz mit Anwendung und Anmeldedaten.

Der Webzugang steht nicht in der DMZ, weil er dadurch automatisch sicher wäre. Er steht dort, damit ein kompromittiertes öffentliches System nicht ohne weitere Kontrolle auf das interne Netz zugreifen kann. Jeder Übergang bildet eine Vertrauensgrenze, an der eine Firewall nur vorher begründete Kommunikation zulässt.

Erst der Dienstablauf, dann die Regel

Das BSI fordert für Firewalls einen Allowlist-Ansatz: Erlaubte Kommunikationsbeziehungen werden eindeutig festgelegt, alle anderen Verbindungen werden unterbunden. Deshalb beginnt ein gutes Regelwerk nicht mit einer Portliste. Es beginnt mit dem tatsächlichen Ablauf des Dienstes.

Für das Kulturforum gelten diese Systeme:

Eine öffentliche virtuelle IP-Adresse wird per Destination Network Address Translation auf 172.20.10.20 übersetzt. Diese Übersetzung ersetzt keine Freigabe. NAT ändert eine Adresse, die Firewall entscheidet über die Verbindung.

Für jede Beziehung stellst du dieselben Fragen:

1. Wer startet die Verbindung?
2. Welches einzelne Ziel wird benötigt?
3. Welches Transportprotokoll und welcher Zielport gehören zum Dienst?
4. Ist die Verbindung fachlich begründet?
5. Wie lässt sie sich später prüfen und einem Verantwortlichen zuordnen?

Stateful Inspection ordnet Antworten einer Verbindung zu

Eine zustandsbehaftete Firewall merkt sich den Zustand eines erlaubten Datenflusses. Startet ein Besucher eine zulässige HTTPS-Verbindung zum Webzugang, kann die Firewall die zugehörigen Antwortpakete diesem Zustand zuordnen. Für die Rückrichtung brauchst du deshalb nicht einfach eine zweite, dauerhaft offene Regel mit beliebigen Quellports.

RFC 7754 grenzt das von zustandsloser Filterung ab: Ein zustandsloser Filter bewertet Pakete anhand fester Merkmale. Stateful Packet Filtering hält zusätzlich Zustand, um richtungsbezogene Regeln für einen Datenfluss durchzusetzen. Das BSI verlangt im Baustein NET.3.2 grundsätzlich zustandsbehaftete Filterregeln, auch für UDP und ICMP.

Das bedeutet nicht, dass jede Antwort automatisch vertrauenswürdig ist. Sie muss zu einem bekannten Zustand passen. Zeitüberschreitungen, asymmetrische Wege über verschiedene Firewalls oder erschöpfte Zustandstabellen können Verbindungen trotzdem scheitern lassen.

Das Regelwerk formulieren

Die folgende Tabelle beschreibt die Sicherheitsabsicht. Die konkrete Syntax und die Stelle, an der NAT berücksichtigt wird, hängen vom Produkt ab.

Die Regeln 10 bis 40 erlauben neue Verbindungen in genau der angegebenen Richtung. Zugehöriger Rückverkehr wird über den Zustand der Verbindung zugelassen. Regel 90 bildet den Abschluss. Bei einer Firewall, die Regeln von oben nach unten prüft und beim ersten Treffer stoppt, gehört die allgemeine Verwerfregel hinter die spezifischen Freigaben.

Die Regelnummern lassen Lücken. So kann der Betrieb später eine begründete Regel zwischen zwei Einträge setzen, ohne alle folgenden Nummern zu ändern. Noch wichtiger als die Nummer ist eine dokumentierte Zuständigkeit: Wer hat die Regel beantragt, wer hat sie freigegeben, wann wurde sie getestet und wann wird sie erneut geprüft?

Administration und Logs sind eigene Datenflüsse

Eine Firewall schützt die DMZ nur so lange, wie auch ihre Verwaltung und das Regelwerk geschützt bleiben. Für den Webzugang kommt die Administration deshalb nicht aus dem Internet und nicht von jedem internen Client. Nur 10.40.99.10 aus dem Managementnetz darf die SSH-Verbindung starten. Sichere Authentisierung, aktuelle Software und begrenzte Konten bleiben zusätzlich nötig.

Das BSI empfiehlt für die Firewall selbst ein getrenntes Managementnetz und fordert, Administrationszugänge auf einzelne Quelladressen oder Adressbereiche einzuschränken. Für unser kleines Übungsszenario bildet die eigene Managementzone dieses Prinzip ab. In einer realen Architektur würdest du außerdem den Verwaltungsweg zur Firewall selbst und einen Notfallzugriff planen.

Protokollierung ist ebenfalls mehr als “Logging einschalten”. Abgewiesene Netzverbindungen sollten mindestens Quelle, Ziel, relevante Ports sowie Datum und Uhrzeit enthalten. Konfigurationsänderungen und fehlgeschlagene administrative Zugriffe gehören ebenfalls in die Auswertung. Die Logübertragung geht an einen getrennten Server, damit ein kompromittierter Webzugang seine Spuren nicht so leicht lokal verändern kann.

Nicht jedes erlaubte Paket muss dauerhaft vollständig protokolliert werden. Zu viele gleichförmige Einträge erschweren die Auswertung und belasten Systeme. Lege deshalb fest, welche Ereignisse du für Betrieb, Fehlersuche und Sicherheit brauchst, wie lange sie aufbewahrt werden und wer sie lesen darf.

Mit positiven und negativen Fällen testen

Ein positiver Test zeigt, dass eine gewünschte Verbindung funktioniert. Er beweist noch nicht, dass unerwünschte Wege gesperrt sind. Dafür brauchst du negative Tests.

Führe solche Tests nur in einer freigegebenen Testumgebung oder einem abgestimmten Wartungsfenster durch. Notiere dabei Ausgangssystem, Ziel, Zeitpunkt, verwendetes Werkzeug, Ergebnis und zugehörigen Logeintrag. So wird aus “Port 443 geht” ein nachvollziehbarer Wirksamkeitsnachweis.

Grenzen des Entwurfs

Die DMZ begrenzt mögliche Verbindungen. Sie beseitigt keine Schwachstelle im Webzugang und garantiert keine absolute Sicherheit. Eine erlaubte HTTPS-Verbindung kann weiterhin schädliche Eingaben transportieren. Deshalb gehören sichere Anwendungskonfiguration, Aktualisierungen, Härtung, Rechtebegrenzung und Überwachung zum Gesamtkonzept.

Auch eine zustandsbehaftete Firewall hat Grenzen. Ein Angriff kann ihre Zustandstabelle oder Rechenleistung auslasten. Verschlüsselter Verkehr ist für einen reinen Paketfilter nur eingeschränkt beurteilbar. Eine einzelne falsch gesetzte, breite Freigabe kann die gewünschte Trennung aufheben. Das BSI grenzt zusätzliche Funktionen wie Anwendungserkennung, Intrusion Detection und Web Application Firewalls deshalb ausdrücklich als eigene Betrachtungen ab.

Der Rahmenlehrplan spricht von einem relativen Sicherheitsniveau. Das passt zu dieser Lektion: Du vergleichst das erreichte Ergebnis mit den Anforderungen und benennst verbleibende Risiken. “Die DMZ ist sicher” wäre zu pauschal. Tragfähig ist: “Die dokumentierten Datenflüsse sind auf die benötigten Systeme und Dienste begrenzt und wurden mit den festgelegten Testfällen geprüft.”

Transfer: Einen Download-Dienst ergänzen

Was du mitnehmen kannst

Ein belastbares DMZ-Regelwerk entsteht in fünf Schritten:

1. Zonen und Vertrauensgrenzen benennen.
2. Den Dienstablauf als einzelne Kommunikationsbeziehungen beschreiben.
3. Nur diese Beziehungen mit eindeutiger Richtung erlauben.
4. Administration, Protokollierung und Zuständigkeiten gesondert dokumentieren.
5. Gewünschte und unerwünschte Verbindungen testen und die Grenzen des Ergebnisses festhalten.

Damit steht nicht nur eine Portliste. Du hast eine begründete, prüfbare Sicherheitsentscheidung.

Quellenbasis und Abgrenzung

Die Zuordnung zu Lernfeld 11b folgt dem KMK-Rahmenlehrplan: Schutzbedarf ermitteln, Maßnahmen planen und umsetzen, Sicherheit prüfen, dokumentieren und das relative Sicherheitsniveau bewerten. Die Ausbildungsordnung trägt die Verbindung zu IT-Sicherheitsmaßnahmen und zum Installieren und Konfigurieren von Netzwerken. Der FISI-Prüfungskatalog 2026 nennt Firewalls, Sicherheitslösungen, Funktions- und Belastungstests sowie Protokolldateien und Änderungsverfolgung im möglichen Themenumfang.

Ältere Beispielprüfungen wurden ausschließlich daraufhin ausgewertet, welche Aufgabenformen wiederkehren. Dazu gehören die Erklärung von Stateful Packet Inspection und tabellarische Regeln. Szenario, Adressen, Datenflüsse, Fragen und Lösungen dieser Lektion sind neu erstellt.

Die technischen Leitlinien stammen vor allem aus dem BSI-Baustein NET.3.2. RFC 7754 stützt die begriffliche Abgrenzung von zustandsloser und zustandsbehafteter Filterung. Die Lektion behandelt keine produktbezogene Konfiguration, keine vollständige IPv6-Filterstrategie, keine Web Application Firewall und keine allgemeine Netzsegmentierung mit VLANs.

Belegmatrix