Der erlaubte Raum an der Firewall — wie wir das Lebensfähigkeitsmodell auf unsere eigene OPNsense angewandt haben#
Ich behaupte, dass eine Methode, welche für Maschinen und Organisationen gilt, auch für einen Paketfilter gelten muss — sonst ist sie keine Methode, sondern eine Meinung. Diesen Sommer haben wir in OTSM das an unserer eigenen Edge-Firewall ausprobiert. Hier ist, was dabei herauskam, inklusive der Stelle, an der wir uns geirrt hatten.
Ausgangslage: sieben Regeln, keine davon begründet#
Unsere OPNsense hatte sieben manuell angelegte Filterregeln. Jede einzelne war irgendwann einmal sinnvoll gewesen. Zusammen ergaben sie kein Bild:
- Ein Regelpaar sollte den Zugriff auf den Git-Server auf einen einzigen Quellhost beschränken.
- Das Roadwarrior-VPN durfte alles, überallhin.
- Das LAN durfte alles ins Internet, für IPv4 und IPv6 getrennt.
- Eine Regel hieß wörtlich „Temp" und stammte aus einer Migration, die seit Monaten abgeschlossen war.
- Dazu zwei NAT-Weiterleitungen, die Entwicklungs-App und Identity-Provider direkt am Reverse-Proxy vorbei nach außen reichten.
Keine dieser Regeln war falsch im Sinne von „verletzt eine Signatur". Alle zusammen waren falsch im Sinne von „niemand kann sagen, welcher Verkehr erlaubt sein soll". Das ist die Aufzählungs-Logik: Man schreibt auf, was man gerade braucht, und der Rest ist Restmenge — unbenannt, ungeprüft, implizit erlaubt.
Der Irrtum, der die Methode rettete#
Die erste Reaktion war naheliegend: das Git-Regelpaar härten. Bis die Frage kam, ob diese Regeln überhaupt je ein Paket gesehen haben.
Hatten sie nicht. In einem flachen /24-Netz läuft Verkehr zwischen zwei LAN-Hosts über den Switch und passiert die Firewall nie. Zwei Regeln, die seit Wochen als Schutz galten, waren Dekoration.
Das ist keine Firewall-Anekdote, sondern der Kern von Pflicht 3 des Lebensfähigkeitsmodells: Wird das Vitale wirklich gemessen — oder geschätzt? Eine Regel, deren Wirksamkeit nie gemessen wurde, ist eine Schätzung. Die Konsequenz war unbequem, aber eindeutig: Die Perimeter-Firewall kann genau drei Verkehrsklassen regeln — Eingang aus dem Internet, VPN ins LAN, LAN ins Internet. Alles andere gehört auf die Hosts selbst. Das wurde ein eigener Change Request, nicht ein Nebensatz.
Die Übersetzung: Schlauch statt Signaturliste#
Im Methodenpapier Erlaubter Raum steht, dass die IT-Sicherheit den Übergang von der Aufzählung zur Restmengen-Logik längst vollzogen hat — Allowlisting, Zero Trust. Die Geometrie ist dieselbe wie bei einer Maschine:
| Schlauch-Element | An der Firewall |
|---|---|
| Breite | Die Positivliste: welcher Quelle ist welches Ziel auf welchem Port erlaubt |
| Mittellinie | Der Normalbetrieb: die Flüsse, die jeden Tag tatsächlich laufen |
| Verlauf außerhalb | Ein geloggter Block — kein Angriff, sondern erst einmal eine Lücke in der Liste |
Aus dieser Übersetzung folgt die Regel-Struktur fast von selbst: Je Verkehrsklasse eine Positivliste, dahinter ein Default-Block, der loggt. Der Block ist nicht primär ein Sicherheitsmechanismus — er ist das Messinstrument, das die Lücke zwischen deklariertem und tatsächlichem Verkehr sichtbar macht.
Die fünf Pflichten, konkret#
Pflicht 1 — Zweck und Adressat. Die Firewall schützt nicht „das Netz". Sie schützt die Entwicklungsumgebung eines Softwareunternehmens, und der Adressat ist der Betreiber, der am Morgen nach einem Vorfall beweisen muss, was erlaubt war. Das klingt trivial, entscheidet aber die Form: Die Regelliste muss lesbar und versioniert sein, nicht nur wirksam.
Pflicht 2 — Idealzustand mit Datum. Die Positivliste liegt als Ansible-Gruppenvariable in Git. Jeder Fluss trägt eine Begründung im Klartext. Das Datum liefert der Commit. Ein Soll ohne Datum wäre wieder die „Temp"-Regel — gültig, bis jemand zufällig nachschaut.
Pflicht 3 — Messmittelfähigkeit. Block-und-Log statt Block-still. Der erste Funktionstest nach dem Umbau war ein geblockter Aufruf eines internen Dienstes, im Log mit Referenz auf den Change Request. Telemetrie vor Beobachtung: Das Firewall-Log ist die Maschinen-Quelle der Drift-Inbox, nicht ein Admin, der „mal schaut".
Pflicht 4 — Schwachpunkt, nicht Mittelwert. Das schwächste Glied war nicht die schlechteste Regel, sondern die Netzarchitektur darunter: ein flaches Segment, in dem die Firewall für den Großteil des Verkehrs gar nicht zuständig ist. Ein Audit, das sieben Regeln bewertet und den Durchschnitt bildet, hätte das nie gefunden.
Pflicht 5 — Beweglichkeit. Der Auslöser war ein dokumentierter ISMS-Vorfall (eine Konfiguration, die sichtbar war, die es nicht hätte sein dürfen). Die Reaktionszeit von Signal bis zur ersten applied Positivliste ist aus dem Vorfall-Datum und dem Seal-Tag ablesbar. Drei Folge-Changes sind am Vorfall verknüpft. Das ist der Teil, den wir in OTSM selbst erfassen — der Vorfall, die Changes, der Prozess — damit die Reaktionszeit beim nächsten Mal eine gemessene Größe ist und keine Erinnerung.
Lebendig und eingefroren#
Das Modell verlangt je Block zwei Zustände und die sichtbare Lücke dazwischen. An der Firewall ist das überraschend wörtlich umsetzbar:
- Lebendig: die Positivliste in Git, angewendet per Playbook, idempotent (der zweite Lauf ändert nichts).
- Eingefroren: der Konfigurations-Export der OPNsense vor und nach dem Umbau, ebenfalls versioniert.
Die Lücke ist ein diff. Wenn jemand in der Oberfläche eine Regel nachträgt, zeigt der nächste Export die Abweichung vom deklarierten Soll. Nicht, weil wir ein Compliance-Tool gekauft hätten, sondern weil die Methode genau das verlangt und Git es umsonst liefert.
Was Phase 1 geändert hat — und was bewusst nicht#
Entfernt: das wirkungslose Git-Regelpaar, die Temp-Regel, die VPN-Alles-Regel, die beiden NAT-Durchreichungen am Proxy vorbei.
Eingeführt: eine deklarative Rolle mit Positivliste für das VPN (dreizehn begründete Flüsse), ein Default-Block mit Log dahinter, und als risikofreier Sofortgewinn ein Block für ausgehende Mail-Ports aus dem gesamten Netz.
Nicht geändert: die ausgehende Default-Erlaubnis des LAN ins Internet. Die Egress-Positivliste ist bereits geschrieben, aber abgeschaltet. Erst läuft eine Beobachtungswoche mit Log-only, in der das Firewall-Log zeigt, welche legitimen Ziele in der Liste fehlen — Paketquellen, Zertifikatsdienste, Modell-Downloads. Dann wird scharf geschaltet, dann fällt die Default-Erlaubnis. Das ist dieselbe Detect-first-Disziplin, die wir beim Intrusion-Detection-Sensor angewandt haben: Der erlaubte Raum wird aus dem gemessenen Normalbetrieb verengt, nicht aus dem Gedächtnis geraten.
Was das für Kunden heißt#
Nichts an diesem Vorgehen ist OPNsense-spezifisch. Es braucht drei Dinge: eine Stelle, an der das Soll deklariert und datiert liegt; einen Mechanismus, der Abweichungen loggt statt sie still zu schlucken; und die Disziplin, den Schwachpunkt dort zu suchen, wo die Messung fehlt — nicht dort, wo die Regel am ältesten aussieht.
Das ist exakt der Werkzeugkasten, den OTSM für Anforderungen, Prozesse und Risiken bereitstellt. Wir haben ihn auf unsere eigene Infrastruktur angewandt, den Vorfall, die Changes und den Prozess in OTSM erfasst, und dabei eine Regel gefunden, die wochenlang nur so getan hat, als würde sie schützen. Das ist kein Werbeargument. Das ist der Grund, warum wir die Methode überhaupt gebaut haben.
Bezug: Methodenpapier „Lebensfähigkeitsmodell" (fünf Pflichten, lebendig/eingefroren, Drift-Inbox) und „Erlaubter Raum" (Schlauch-Geometrie, Abschnitt IT-Sicherheit). Phase 2 (Egress enforce) folgt nach der Beobachtungswoche.