Firewall-Regeln aufräumen: Schritt-für-Schritt-Anleitung zur Bereinigung & Auditierung

Eine gewachsene Firewall-Regelbasis ist wie ein Aktenschrank, in den seit Jahren niemand mehr aufgeräumt hat: Jede Ausnahme, jede „nur für zwei Wochen“ freigeschaltete Portregel, jeder Testzugang bleibt liegen – und wird nie wieder entfernt. Nach ein paar Jahren Betrieb enthält die typische Rule-Base eines mittelständischen Unternehmens mehrere Hundert Einträge, von denen ein erheblicher Teil nachweislich nie mehr benötigt wird. Genau hier setzt ein strukturiertes Firewall-Regel-Audit an: Es macht sichtbar, was wirklich gebraucht wird, deckt Sicherheitslücken auf und sorgt nebenbei für spürbar bessere Performance. Dieser Beitrag zeigt die Methodik, mit der wir bei K&C NetFox Rule-Base-Audits durchführen – von der Vorbereitung bis zur Automatisierung.

Warum eine unkontrollierte Rule-Base ein Sicherheitsrisiko ist

Drei Regel-Typen sind für die meisten Vorfälle verantwortlich, die wir bei Audits finden. Schattenregeln (Shadow Rules) entstehen, wenn eine weiter oben stehende, breiter gefasste Regel eine spätere, eigentlich striktere Regel vollständig verdeckt – die untere Regel greift dann nie, obwohl sie im Regelwerk sichtbar ist und einen falschen Eindruck von Kontrolle vermittelt. Overly-Broad-Regeln sind Freigaben mit „any-any“-Quellen, offenen Portbereichen oder /0-Netzen, die aus Zeitdruck angelegt und nie wieder auf das tatsächlich benötigte Minimum reduziert wurden. Duplicate Rules schließlich entstehen, wenn über Jahre mehrere Administrator:innen unabhängig voneinander ähnliche Freigaben anlegen, weil die bestehende Regel nicht gefunden oder nicht verstanden wurde – das bläht nicht nur die Übersichtlichkeit auf, sondern auch die Verarbeitungszeit pro Paket.

Diese drei Muster sind kein theoretisches Problem: Der CIS Firewall Benchmark listet die Bereinigung ungenutzter und überbreiter Regeln explizit als Kontrollpunkt, und auch NIST SP 800-41 Rev. 1 (Guidelines on Firewalls and Firewall Policy) fordert eine regelmäßige Überprüfung des Regelwerks als festen Bestandteil des Policy-Lifecycles – nicht als einmaliges Projekt bei der Einführung.

Vorbereitung: Backup, Snapshot & Change-Window planen

Bevor die erste Regel angefasst wird, steht ein vollständiges, versioniertes Konfigurations-Backup – im Idealfall als Textexport in einem Git-Repository, damit jede spätere Änderung als Diff nachvollziehbar bleibt. Bei virtualisierten Firewalls (pfSense, OPNsense, MikroTik CHR) empfiehlt sich zusätzlich ein VM-Snapshot unmittelbar vor dem Wartungsfenster, um im Zweifel in Sekunden statt Minuten zurückzurollen. Für produktive Firewalls sollte das Vorgehen einem klassischen ITIL-Change-Management-Prozess folgen: ein dokumentiertes Request for Change mit Zielsetzung, Betroffenheitsanalyse und Rollback-Plan, eine Freigabe durch das Change Advisory Board sowie ein klar definiertes, kommuniziertes Wartungsfenster außerhalb der Kernarbeitszeiten. Wer diesen Rahmen überspringt, riskiert nicht nur einen Ausfall, sondern auch, dass niemand mehr nachvollziehen kann, warum eine bestimmte Regel irgendwann entfernt wurde.

Schritt 1: Traffic-Daten & Hit-Count-Analyse (Tools & Metriken)

Der Ausgangspunkt jedes seriösen Audits ist Datenlage statt Bauchgefühl. Nahezu jede Firewall-Plattform führt pro Regel einen Hit-Counter – bei FortiGate in der Policy-Übersicht, bei Palo Alto im Policy-Optimizer-Report, bei Check Point in SmartView Tracker, bei Cisco ASA über show access-list mit hitcnt, bei pfSense/OPNsense über die States-Tabelle je Regel. Entscheidend ist der Beobachtungszeitraum: Ein Snapshot von einer Woche fängt keine monatlichen Batch-Jobs, quartalsweisen Reportings oder saisonalen Zugriffe ein. Wir setzen als Mindestwert Hit-Count über 90 Tage an, weil damit auch die üblichen Monats- und Quartalsabschlüsse zuverlässig erfasst werden. Parallel dazu lohnt sich ein unabhängiger NetFlow-/sFlow-/IPFIX-Export an einen Collector (z. B. ntopng oder eine Elastic-Stack-Auswertung) – so lässt sich der interne Hit-Counter der Firewall gegen tatsächlich beobachteten Traffic verifizieren, statt sich blind auf eine einzelne Datenquelle zu verlassen.

Schritt 2: Unused & Low-Use Rules identifizieren (Kriterien & Validierung)

Mit den Hit-Count-Daten aus Schritt 1 lassen sich Regeln in drei Kategorien einsortieren: nachweislich ungenutzt (0 Treffer über den vollen 90-Tage-Zeitraum), selten genutzt (einzelne Treffer, aber möglicherweise geschäftskritisch, etwa ein quartalsweiser Backup-Job zu einem externen Rechenzentrum) und aktiv genutzt. Nur die erste Kategorie ist ein direkter Löschkandidat – und selbst dann gilt: nicht sofort hart löschen, sondern zunächst in einen „Log-only“- bzw. deaktivierten Zustand versetzen und für einen weiteren Beobachtungszeitraum belassen. Bei der zweiten Kategorie ist eine Rückfrage bei der fachlich verantwortlichen Abteilung Pflicht, bevor irgendetwas angefasst wird. Zusätzlich zur reinen Nutzungshäufigkeit prüfen wir zwei weitere Dinge: das TCP/UDP-Port-Mapping – stimmen die in der Regel erlaubten Ports tatsächlich mit den in den Traffic-Daten beobachteten Ports überein, oder ist die Regel breiter gefasst als der reale Bedarf? – sowie die Service-Objekt-Validierung: Zeigen die referenzierten Adress- oder Service-Objekte noch auf aktive Systeme, oder verweisen sie auf längst abgebaute Server, deren IP-Adresse inzwischen anderweitig vergeben sein könnte?

Schritt 3: Shadow & Conflict Rules auflösen (Policy-Ordering, Testmatrix)

Shadow Rules lassen sich nicht am Hit-Count allein erkennen, da eine verdeckte Regel per Definition wenige oder gar keine Treffer zeigt – nicht, weil sie unnötig wäre, sondern weil eine andere Regel sie nie zum Zug kommen lässt. Next-Generation-Firewalls wie FortiGate oder Palo Alto bringen dafür meist einen eingebauten Policy-Analyzer bzw. Redundanz-Check mit; bei pfSense und OPNsense fehlt dieses Werkzeug, hier hilft nur eine manuelle Testmatrix aus Quellzone, Zielzone und Port, mit der jede Regel vor und nach einer Umsortierung gegen das erwartete Ergebnis geprüft wird. Beim anschließenden Reordering gilt die Faustregel: von spezifisch nach allgemein. Die spezifischste Regel steht oben, generische Catch-all-Regeln stehen ganz unten. Für die Performance lohnt sich zusätzlich eine Rule-Index-Optimierung: Regeln mit den höchsten Hit-Counts wandern – solange die Spezifitäts-Reihenfolge dabei nicht verletzt wird – möglichst weit nach oben, damit die Firewall im Durchschnitt weniger Regeln pro Paket durchlaufen muss, bevor eine Entscheidung fällt.

Schritt 4: Overly Broad / Admin-Backdoor Regeln härten

Die risikoreichste Kategorie sind Regeln, die ursprünglich als Übergangslösung gedacht waren und nie wieder angefasst wurden: eine „temporäre“ Any-any-Freigabe für einen Migrationstest, ein Management-Zugriff auf SSH oder HTTPS, der von jeder beliebigen WAN-Adresse aus erreichbar ist, oder unveränderte Werksregeln aus der Erstinbetriebnahme. Solche Regeln sind für externe Angreifer der erste Ansatzpunkt, weil sie im Zweifel den direkten Weg auf die Management-Oberfläche der Firewall selbst öffnen. Härtung bedeutet hier konkret: Any-any-Regeln durch explizite Quell-/Ziel-/Service-Objekte ersetzen, administrative Zugriffe ausschließlich über VPN oder einen dedizierten Jump-Host erlauben, Multi-Faktor-Authentifizierung für jeden Remote-Admin-Zugang verpflichtend machen und Management-Traffic in ein eigenes VLAN segmentieren, das vom produktiven Netz getrennt ist – ein Prinzip, das sich am Zero-Trust-Grundgedanken orientiert: kein impliziertes Vertrauen allein aufgrund der Position im Netzwerk.

Schritt 5: Dokumentation & Automatisierung (CI/CD, GitOps, Policy-as-Code)

Ein bereinigtes Regelwerk bleibt nur dann sauber, wenn jede neue Regel von Anfang an dokumentiert wird: Owner, fachliche Begründung, Ticket-Referenz und – wo sinnvoll – ein Ablaufdatum, das eine automatische Wiedervorlage auslöst. Der nächste Reifegrad ist Policy-as-Code: Die Regelbasis liegt als deklarative Konfiguration in einem Git-Repository (z. B. über Terraform-Provider für FortiGate/Palo Alto oder Ansible-Module für pfSense/OPNsense), Änderungen laufen über Pull Requests mit Review durch eine zweite Person, und eine CI-Pipeline prüft vor jedem Deployment automatisiert auf Syntaxfehler, Redundanzen und Verstöße gegen definierte Policy-Regeln (z. B. „keine neuen Any-any-Freigaben“). Der Gewinn: eine vollständige, manipulationssichere Änderungshistorie über git log, ein Vier-Augen-Prinzip, das menschliche Fehler abfängt, bevor sie produktiv werden, und ein Rollback, der sich im Zweifel auf einen einzigen git revert reduziert.

Nachbereitung: Monitoring, Rollback-Plan & Re-Audit-Rhythmus

Nach jeder Änderung folgt ein Beobachtungsfenster von 24 bis 72 Stunden, in dem Logs gezielt auf unerwartete Drops geprüft werden – nichts ist unangenehmer als ein monatlicher Batch-Job, der erst vier Wochen nach der Bereinigung fehlschlägt, weil die zugehörige Regel fälschlich als ungenutzt eingestuft wurde. Für genau diesen Fall braucht es einen vorab getesteten, dokumentierten Rollback-Plan mit klaren Auslösekriterien, nicht erst eine Ad-hoc-Lösung unter Zeitdruck. Und weil sich eine Rule-Base ab dem ersten Tag nach dem Audit wieder zu füllen beginnt, gehört ein Re-Audit-Rhythmus fest in den Betriebskalender: ein vollständiges Audit mindestens zweimal jährlich, ergänzt um eine leichte Kurzprüfung nach jeder größeren Änderung sowie automatisch ausgelöste Reviews, sobald das dokumentierte Ablaufdatum einer Regel erreicht ist. So bleibt Bereinigung ein Prozess statt eines einmaligen Projekts – und ergänzt sich gut mit einer sauberen 3-2-1-Backup-Strategie, da eine gehärtete, aufgeräumte Firewall und ein durchdachtes Backup-Konzept gemeinsam die wirksamste Verteidigungslinie gegen Ransomware bilden.

Ein Firewall-Audit ist kein Aufräumtag, sondern ein Prozess mit Wiederholung. Die Regelbasis, die heute sauber ist, ist in einem Jahr wieder gewachsen – wenn niemand nachschaut.

Fazit & Quick-Win-Checkliste

Ein strukturiertes Firewall-Regel-Audit ist kein Nice-to-have, sondern eine der wirksamsten Maßnahmen, um Angriffsfläche zu reduzieren und gleichzeitig die Performance der Firewall spürbar zu verbessern – oft ganz ohne zusätzliche Hardware. Wer sich an Hit-Count-Daten statt an Vermutungen hält, jede Änderung über ein sauberes Change-Window absichert und die Regelbasis anschließend als Code versioniert, reduziert das Risiko menschlicher Fehler drastisch und schafft die Grundlage für jeden zukünftigen Audit-Zyklus. Die folgende Checkliste fasst den Ablauf als Quick-Reference zusammen:

FAQ

Wie oft sollte ein Firewall-Regel-Audit durchgeführt werden?
Mindestens zweimal jährlich als Vollaudit, ergänzt um eine kurze Prüfung nach jeder größeren Änderung. Bei stark frequentierten Regelwerken mit vielen Administrator:innen empfiehlt sich ein quartalsweiser Rhythmus.

Was ist eine Schattenregel (Shadow Rule)?
Eine Regel, die durch eine weiter oben stehende, breiter gefasste Regel bereits vollständig abgedeckt wird und daher nie zur Anwendung kommt – sie bleibt sichtbar im Regelwerk, hat aber keine praktische Wirkung mehr.

Kann ich eine Regel einfach löschen, wenn der Hit-Count null ist?
Nicht direkt. Erst über mindestens 90 Tage beobachten, um saisonale oder quartalsweise Zugriffe nicht zu übersehen, dann in einen Log-only-/deaktivierten Zustand versetzen und final erst nach Rückbestätigung durch die fachlich verantwortliche Stelle löschen.

Welche Rolle spielt NIST SP 800-41 bei einem Firewall-Audit?
NIST SP 800-41 Rev. 1 („Guidelines on Firewalls and Firewall Policy“) beschreibt den Policy-Lifecycle inklusive regelmäßiger Überprüfung als Standardpraxis und dient vielen Audit-Methodiken, auch der hier beschriebenen, als fachliche Grundlage.

Wie lange dauert ein vollständiges Rule-Base-Audit?
Je nach Größe des Regelwerks realistischerweise zwei bis vier Wochen inklusive der Beobachtungsphase für Hit-Count-Daten – die eigentliche manuelle Analyse- und Umsetzungsarbeit liegt meist bei fünf bis zehn Personentagen.