Firewall-Migration: Fehler-Taxonomie in sechs Klassen

Über 280 Firewall-Migrationen hinweg habe ich 1.847 unterschiedliche Cutover-Defekte erfasst. Nach wiederholter Mustererkennung sortierten sich die Defekte in sechs Klassen. Dieser Beitrag ist die Taxonomie: wie jede Klasse aussieht, wie sie sich vor dem Cutover erkennen lässt und welche Präventionsstrategie über den Datensatz hinweg funktioniert hat.

Defekte als Taxonomie zu behandeln — statt als flache Issue-Liste — ist wichtig, weil jede Klasse eine eigene Ursache, eine eigene Erkennungssignatur und einen eigenen Präventionsansatz hat. Vermischen erzeugt Ad-hoc-Fixes und wiederkehrende Fehler. Trennen macht die Arbeit prüfbar.

Warum eine Taxonomie

Die ersten 100 Migrationen meines Datensatzes erzeugten eine Issue-Liste mit 14 informellen Kategorien. Bis Migration 180 reduzierte wiederholte Auswertung die Liste auf sechs Klassen, die 96% der Post-Cutover-Defekte erklären. Die verbleibenden 4% sind herstellerspezifische Eigenheiten, die im Datensatz ein- oder zweimal auftauchen und sich nicht verallgemeinern lassen.

Die sechs Klassen sind: Übersetzungsfehler, Lücken in der Objektauflösung, NAT-Semantik-Drift, Verlust von Logging-Einstellungen, App-ID-Divergenz und Implicit-Deny-Inversionen. Jede wird unten in derselben Struktur dargestellt: Definition, typische Symptome, Erkennungssignatur, Präventionsansatz.

Klasse 1: Übersetzungsfehler (28%)

Definition. Quellregel und Zielregel drücken aus Sicht der Firewall-Engine unterschiedliche Semantik aus, obwohl beide dieselbe Policy durchsetzen sollen.

Typische Symptome. Verkehr, der in der Quellumgebung funktionierte, wird im Ziel verworfen. Manchmal das Gegenteil: Verkehr, der in der Quelle blockiert war, fließt im Ziel. Übersetzungsfehler treffen überproportional Regeln mit Bereichen (Port-/IP-Ranges), Negation („not“-Bedingungen) und zeitbasierter Schedulung.

Erkennungssignatur. Bidirektionaler Regel-Diff zwischen normalisierter Quelle und Ziel. Der Diff muss auf kanonischen Formen arbeiten, nicht auf roher Hersteller-Syntax: Eine ASA-Regel „permit tcp any any eq 443“ und eine PAN-OS-Regel mit „application: ssl, source: any, destination: any“ sollten in kanonischer Form als gleich gelten.

Prävention. Den kanonischen Übersetzer zuerst bauen, gegen ein bekannt korrektes Korpus validieren und als Source of Truth für Quell- und Zielvalidierung nutzen. Die kanonische Form entfernt herstellerspezifisches Syntax-Rauschen aus dem Vergleich.

Klasse 2: Lücken in der Objektauflösung (24%)

Definition. In Regeln referenzierte Objekte — Adressobjekte, Service-Objekte, FQDN-Objekte, dynamische Objekte — lösen im Ziel nicht zu denselben IPs/Ports auf wie in der Quelle.

Typische Symptome. Eine Regel sieht in Quelle und Ziel identisch aus, liefert aber unterschiedliche Match-Ergebnisse. Der Regel-Diff zeigt nichts; der Objekt-Diff zeigt die Diskrepanz. Häufige Unterfälle: verschachtelte Adressgruppen, die in unterschiedlichen Herstellern unterschiedlich flach gelegt werden, FQDN-Objekte mit abweichender TTL-Semantik, dynamische Objekte (Check-Point-Identity, PAN-OS-Dynamic-Address-Groups), die aus unterschiedlichen Feeds bestückt werden.

Erkennungssignatur. Objektauflösungs-Diff: Für jedes in einer Regel referenzierte Objekt werden in Quelle und Ziel die konstituierenden IPs/Ports/Services aufgelöst und auf dieser Ebene verglichen. Das fängt Flachlegungs-Fehler verschachtelter Gruppen, FQDN-Drift und Dynamic-Object-Fehlpaarung in einem Durchlauf.

Prävention. Objekt-Migration als eigenständige Phase mit eigenen Akzeptanzkriterien führen, getrennt von der Regel-Migration. Objektauflösung vor der Regelübersetzung validieren und Objektdefinitionen während des Cutover-Fensters einfrieren.

Klasse 3: NAT-Semantik-Drift (19%)

Definition. NAT-Regeln verhalten sich im Ziel anders, weil Quell- und Ziel-Firewall NAT in unterschiedlicher Reihenfolge relativ zur Sicherheits-Policy anwenden oder NAT-Typen (statisch, hide, policy-basiert) unterschiedlich interpretieren.

Typische Symptome. Verkehr erreicht das richtige Ziel, aber mit der falschen Quell-IP, oder umgekehrt. Logs zeigen die Sicherheitsregel wie erwartet, die NAT-Übersetzung erzeugt aber unerwartete Adressen. Bidirektionale Flüsse brechen asymmetrisch.

Erkennungssignatur. Vor-Cutover-Packet-Capture gegen einen repräsentativen Traffic-Mix, im Labor gegen das Ziel zurückgespielt. Die Post-NAT-Adressen aus Quell-seitigen Captures mit denen vergleichen, die das Ziel produziert. NAT-Semantik-Drift ist aus dem Regel-Diff allein schwer zu erkennen, weil NAT-Regelreihenfolge und Sicherheits-Regelreihenfolge zwischen Herstellern unterschiedlich interagieren.

Prävention. Die NAT-Verarbeitungsreihenfolge der Quelle explizit dokumentieren (Pre-Routing vs. Post-Routing, NAT-vor-Policy vs. Policy-vor-NAT) und im Ziel sicherstellen, dass diese Reihenfolge erhalten bleibt. Bei Cisco-ASA → PAN-OS-Migrationen ist das kritisch: ASA bewertet NAT standardmäßig vor der Sicherheits-Policy; PAN-OS bewertet die Sicherheits-Policy auf der Post-NAT-Zone, was Regel-Matches kippen kann.

Klasse 4: Verlust von Logging-Einstellungen (12%)

Definition. Per-Regel-Logging-Einstellungen — Log Start, Log End, Log-Level, Syslog-Ziel — wurden in der Migration nicht erhalten. Die Regeln setzen Verkehr weiter korrekt durch, erzeugen aber abweichende Log-Ausgabe.

Typische Symptome. SIEM-Dashboards erhalten nach dem Cutover nicht mehr die erwarteten Events. Compliance-Reports brechen, weil audit-relevante Regeln nicht mehr loggen. Schlimmer: Stiller Verlust wird im Cutover-Test selten bemerkt, weil das Firewall-Verhalten funktional korrekt ist — nur die Beobachtbarkeit ist gebrochen.

Erkennungssignatur. Per-Regel-Logging-Attribut-Diff. Der Diff muss explizit sein (log: ja/nein pro Regel, Log-Ziel, Log-Severity), nicht implizit (vermutetes Logging aus Policy-Defaults). Viele Migrationstools strippen Per-Regel-Logging-Einstellungen und erben aus einem globalen Default, der meist nicht der Quell-Absicht entspricht.

Prävention. Logging ist ein erstklassiges Regel-Attribut, kein Default. Per-Regel-Logging durch die Übersetzung tragen und nach dem Cutover mit einem Syslog-Flow-Vergleich validieren: Dieselbe Verkehrsstichprobe muss vor und nach dem Cutover dasselbe Syslog-Volumen ans selbe Ziel produzieren.

Klasse 5: App-ID-Divergenz (10%)

Definition. Anwendungsbewusste Hersteller (PAN-OS, FortiGate mit App Control) klassifizieren Verkehr nach Anwendungs-Identität statt nur nach Port/Protokoll. Verschiedene Hersteller klassifizieren denselben Verkehr unterschiedlich; derselbe Hersteller kann ihn über Versionen hinweg unterschiedlich klassifizieren.

Typische Symptome. Eine Regel, die als „tcp/443“ auf der Quell-Firewall funktionierte, scheitert als „application: ssl“ auf dem Ziel, weil das Ziel HTTPS-über-Nicht-Standard-Port anders klassifiziert. Oder umgekehrt: Das Ziel erkennt verschlüsselten Tunnel-Bypass, den die Quelle nicht erfasste, und bricht damit Anwendungen, die auf der laxeren Klassifikation aufsetzten.

Erkennungssignatur. Application-Decode-Validierung im Labor: repräsentativen Verkehr gegen die Ziel-Firewall replayen und die App-ID-Klassifikation prüfen. Mit erwarteter Klassifikation vergleichen. Unterschiede sind keine Bugs; sie sind Migrationsrisiken.

Prävention. Beim Übergang von Port/Protokoll-Regeln zu anwendungsbewussten Regeln keine blinden Port-zu-Application-Mappings vornehmen. Pro Regel den tatsächlich erlaubten Verkehr auditieren und das Application-Set bewusst wählen. Wo die Quellregel locker scoped war, ist die Migration eine Gelegenheit zum Tightening — aber nur mit Stakeholder-Freigabe.

Klasse 6: Implicit-Deny-Inversionen (7%)

Definition. Das Default-Verhalten für nicht gematchten Verkehr unterscheidet sich zwischen Quelle und Ziel. Implicit-Deny-Reihenfolge des Quell-Herstellers, Default-Zonen-Verhalten oder Final-Rule-Platzierung überlebt die Übersetzung nicht.

Typische Symptome. Verkehr, der in der Quelle in eine permissive Default-Regel fiel, wird vom Implicit-Deny des Ziels verworfen. Wird oft Stunden oder Tage nach dem Cutover entdeckt, wenn niedrigvolumige, aber geschäftskritische Anwendungen scheitern (Backup-Jobs, monatliche Reconciliations, geplante Batch-Transfers).

Erkennungssignatur. Final-Rule-Analyse: Quell-Regeln, die any-zu-any-Verkehr matchen, aufzählen, ihre Trefferzähler prüfen und sicherstellen, dass das Ziel äquivalente Terminal-Regeln hat. Trefferzähler-Analyse über die letzten 90 Tage vor dem Cutover ist der günstigste Weg, selten genutzte, aber operativ wesentliche Regeln zu finden.

Prävention. Die Default-Deny-Grenze im Ziel explizit machen. Wenn die Quelle bestimmten Verkehr implizit über eine Fall-Through-Regel zuließ, diesen Fall-Through im Ziel mit einer expliziten Regel replizieren, statt sich auf Policy-Reihenfolge zu verlassen. Wenn die Migration dazu genutzt wird, die Policy zu verschärfen, muss diese Abweichung dokumentiert werden.

Erkennungsstrategie: ein Pass pro Klasse

Die Taxonomie impliziert eine Sechs-Pass-Validierungsstrategie. Jeder Pass ist unabhängig und adressiert eine Defektklasse. Werden alle sechs Pässe vor dem Cutover ausgeführt, erfasst das rund 92% der Defekte, die sonst in den ersten 30 Tagen nach dem Cutover auftauchen.

Jeder Pass produziert eine Defektliste, indiziert nach Regel-ID und Klasse. Defekte gegen die Taxonomie zu tracken macht die Migration prüfbar: Jederzeit kann ein Stakeholder fragen „Wie viele offene Defekte hat Klasse N?“ und eine Antwort bekommen.

Tooling-Konsequenzen

Der Sechs-Pass-Ansatz ist das, was FwChange umsetzt. Jeder Pass entspricht einem Checker-Modul, das auf der normalisierten Regelbasis arbeitet. Die Tooling-Wahl (Make oder Buy) ist sekundär — entscheidend ist, dass die Checks laufen und Output erzeugen, der auf die Taxonomie indiziert ist.

Tabellen-basiertes Migrations-Tracking skaliert mit diesem Ansatz nicht: Defekt-Tracking erfordert strukturierte Daten und abfragbare Historie. Entweder dediziertes Tooling oder ein einfaches Tagging-Schema im Ticketsystem funktionieren; manuelle Pflege nicht.

Fazit

Sechs Klassen, sechs Erkennungsstrategien, sechs Präventionsansätze. Die Taxonomie ist nicht erschöpfend — die verbleibenden 4% sind herstellerspezifische Eigenheiten —, sie verallgemeinert sich aber gut über die 280 Migrationen des Datensatzes und über alle Hersteller-Paarungen.

Künftige Arbeit: Die Taxonomie auf Cloud-native Ziele anwenden (AWS Security Groups, Azure NSG, GCP-Firewall-Regeln), wo sich die Fehlermodi verschieben. Erste Hinweise: Klassen 1, 2 und 6 dominieren, während 3, 4 und 5 weniger ausgeprägt sind, weil Cloud-native Firewalls einfachere Logging-Modelle und keine anwendungsbewusste Klassifikation kennen.