Freitagnachmittag, ganz gewöhnlicher Vorgang: Eine Mail soll raus, Thunderbird meldet einen Verbindungsfehler zum SMTP-Server. Empfang läuft, IMAP steht, nur das Senden bricht ab - auf jedem Client im Netz, ausnahmslos. Kein Update, keine Änderung an Thunderbird, kein Wartungsfenster beim Provider. Es „ging einfach nicht mehr", ohne erkennbaren Auslöser. Au dem Mobiltelfon ging es - am Mailclient nicht mehr.
Der Reflex bei so einem Symptom ist immer derselbe: Mailserver- Konfiguration, Zertifikat, Auth-Methode. Alles unauffällig. Erst der rohe TCP-Connect-Test - ganz ohne TLS, ganz ohne Thunderbird - brachte die eigentliche Antwort: Port 587 zu, Port 465 zu, Port 993 (IMAP) offen. Kein Anwendungsproblem. Ein Netzwerkproblem.
Drei Mengen, nicht zwei#
Wer eine Firewall als Positivliste betreibt, denkt meistens in zwei Kategorien: erlaubt und verboten. Das Erlaubter-Raum-Modell, das hier auch für die eigene Infrastruktur gilt, unterscheidet schärfer - und genau diese Schärfe hat den Vorfall am Ende erklärt, statt ihn nur zu beheben.
Drei Mengen sind zu unterscheiden. Erstens die erlaubten Einwirkungen (AIA): das, was ausdrücklich freigegeben ist. Zweitens die physikalisch möglichen Einwirkungen (PIA): alles, was auf einem Kanal technisch überhaupt ankommen könnte - unabhängig davon, ob es erwünscht ist. Und drittens, als reine Rechengröße, nie selbst gepflegt: die unsicheren/ungewollten Handlungen (UCA) - schlicht der Rest. Formal: UCA = PIA minus AIA.
Der entscheidende Punkt: UCA kennt keine Ausnahme für „aber das bin doch ich". Die Formel unterscheidet nicht zwischen einem Spam-Bot und dem eigenen Mailserver. Sie unterscheidet nur zwischen dem, was deklariert wurde, und dem, was nicht deklariert wurde.
Eine korrekte Regel mit einer Lücke#
Der konkrete Fall: Eine Egress-Regel nach Erlaubter Raum blockiert ausgehenden Verkehr auf
den Mail-Versandports 25, 465 und 587 aus dem gesamten LAN heraus -
Ziel: irgendein Host im Internet, also dst: any. Der Grund dafür ist
gut begründet und keine Übervorsicht: Ausgehender SMTP-Verkehr direkt
aus einem internen Netz ist ein klassischer Spam- und Exfiltrations-
Indikator. Kompromittierte Rechner versenden genau so.
Die Regel war also nicht falsch. Sie war nur nicht vollständig. Für den Kanal „TCP 587/465/25 aus dem LAN" war die AIA-Menge - das ausdrücklich Erlaubte - leer. Und weil AIA leer war, fiel restlos alles auf diesem Kanal in UCA. Auch die eine Verbindung, die eigentlich niemanden überraschen sollte: der eigene Mailserver, der schlicht vergessen worden war, als die Regel geschrieben wurde.
Die Pointe#
Das ist keine Geschichte über eine kaputte Firewall. Die Firewall hat exakt das getan, wozu sie gebaut wurde: jede Einwirkung, die nicht in der erlaubten Menge steht, wird zurückgewiesen. Das Problem lag nie in der Durchsetzung, sondern eine Ebene davor - in der Deklaration. Eine UCA ist nicht automatisch böswillig; sie ist alles, was außerhalb des erlaubten Raums liegt, und „das eigene, vergessene Ding" liegt dort genauso zuverlässig wie ein tatsächlicher Angriffsversuch.
Dasselbe Muster überall, wo eine Positivliste steht#
Der Vorfall betraf hier eine Firewall-Regel, aber das Muster ist nicht auf Netzwerke beschränkt. Jede Positivliste hat dieselbe Eigenschaft: RBAC-Rollen, ISMS-Freigaben, API-Allowlists, Zugriffsrechte auf ein Dokument. Überall gilt dieselbe Formel, und überall gilt derselbe blinde Fleck - wer die eigene, legitime Nutzung nicht mitdeklariert, sperrt sie exakt so zuverlässig aus wie einen tatsächlichen Angriff.
Das ist auch der Grund, warum „sicher" und „vollständig deklariert" zwei verschiedene Fragen sind. Eine Regel kann streng korrekt arbeiten und trotzdem an ihrer eigenen Lücke scheitern - nicht, weil sie zu wenig, sondern weil sie zu präzise verboten hat, was niemand vollständig aufgezählt hatte.
Kein Bug, eine offene Aufgabe#
Am Ende war der Fix trivial: eine zusätzliche Erlauben-Regel, mit niedrigerer Priorität vor dem Block platziert, für genau den einen Host. Zwei Minuten Deploy. Die interessantere Erkenntnis liegt nicht im Fix, sondern in der Einordnung: Das war kein Firmware-Fehler, kein Konfigurationsdrift, kein Zufall. Es war der Beweis, dass das Modell tut, was es soll - es deckt eine Lücke in der eigenen Deklaration auf, anstatt sie stillschweigend zu tolerieren. Die Firewall hatte recht. Nur die Liste war noch nicht fertig.