Warum eine Firewall-Policy immer verwildert
Kein Regelwerk bleibt sauber. Jede Regel wurde aus gutem Grund angelegt, von jemandem, der an diesem Tag ein Problem lösen musste. Was fast nie geschieht, ist das Entfernen: Das Projekt endet, der Server wird außer Betrieb genommen, der Dienstleister geht, und die Regel bleibt. Nach einigen Jahren beschreibt die Policy eher die Geschichte des Unternehmens als seinen aktuellen Bedarf.
Hier sind die Fehler, die in nahezu jedem Audit auftauchen, und wie Sie sie erkennen, ohne Tausende Zeilen von Hand zu lesen.
Sechs wiederkehrende Fehler
1. Verdeckte Regeln (shadowed rules)
Eine weiter oben stehende Regel fängt den gesamten Traffic ab, den eine weiter unten stehende Regel behandeln sollte. Die zweite greift nie. Das ist der trügerischste Fehler: Die Regel existiert, sie ist dokumentiert, sie wirkt beruhigend, und sie ist tot. Verdeckte Regeln findet man nur, wenn man Reihenfolge und Überschneidungen der Objekte analysiert, nicht durch das Lesen einzelner Zeilen.
2. Duplikate
Dieselbe Freigabe zweimal formuliert, oft mit unterschiedlich benannten Objekten. An sich harmlos, doch jedes Duplikat verdoppelt den Prüfaufwand und birgt das Risiko einer halben Änderung: Eine Regel wird verschärft, die andere vergessen, und der Datenfluss bleibt offen.
3. Zu großzügige Regeln
any/any ist der auffälligste Fall, aber selten der häufigste. Die unauffälligeren Varianten richten genauso viel Schaden an: ein „any“-Ziel auf einem bestimmten Port, eine Objektgruppe, die so lange gewachsen ist, bis sie ein ganzes Netz abdeckt, ein „any“-Dienst auf einem ansonsten legitimen Paar aus Quelle und Ziel. Der tatsächlich erlaubte Traffic ist weit größer als ursprünglich beabsichtigt.
4. Ungenutzte Regeln
Eine Regel, die seit Monaten kein Paket getroffen hat, schützt entweder einen Datenfluss, den es nicht mehr gibt, oder erlaubt einen, den niemand beobachtet. Sie ist die beste Kandidatin für eine Löschung, doch die Entscheidung erfordert Daten, die die Konfiguration allein nicht enthält: Trefferzähler.
5. Unsichere Dienste
Telnet, FTP, SNMP v1 oder v2c, Administration über unverschlüsseltes HTTP: Protokolle, die noch erlaubt sind, weil ein altes Gerät sie einmal brauchte. Die Regel überlebt oft das Gerät, das sie gerechtfertigt hat.
6. Fehlende Protokollierung
Eine Regel ohne Protokollierung ist bei einer Untersuchung unsichtbar. Man entdeckt sie erst in dem Moment, in dem man einen Vorfall erklären will, also zu spät.
Warum die manuelle Prüfung scheitert
Keiner dieser Fehler ist beim Lesen einzelner Regeln sichtbar, denn alle sind relational: Sie entstehen aus dem Zusammenspiel mehrerer Regeln, der Auswertungsreihenfolge und dem tatsächlichen Inhalt der Objektgruppen. Wer Zeile 400 liest, hat Zeile 12 vergessen. Das ist eine Analyseaufgabe, keine Leseaufgabe.
Die Herstellervielfalt verschärft das Problem: Dieselbe Absicht wird auf jeder Firewall anders ausgedrückt, was einen Vergleich zwischen Standorten ohne vorherige Normalisierung unmöglich macht.
Was mit den Ergebnissen geschehen sollte
Ein Audit mit achthundert Befunden wird nicht umgesetzt. Nützlich wird die Übung durch Priorisierung: zuerst die zu großzügigen Regeln, die aus einer nicht vertrauenswürdigen Zone erreichbar sind, dann die unsicheren Dienste, dann die toten Regeln, deren Entfernung kein Risiko birgt. Duplikate und Kosmetik kommen zuletzt.
Die zweite nützliche Gewohnheit: den Trend messen statt den Zustand. Eine Policy, die sich jedes Quartal um einige Punkte verbessert, schlägt ein perfektes Audit, das nie umgesetzt wird. Unsere Seite zum Firewall-Regelaudit beschreibt die automatisierte Analyse dieser Fehler, und das Firewall-Modul zeigt, wie das Risiko Regel für Regel bewertet wird.
