Firewall-Schwachstellen-Scan: 18 automatisierte Prüfungen

Ein automatisierter Scanner prüft eine Firewall auf Schwachstellen

Die meisten Firewall-Teams prüfen ihre Regelwerke ein- oder zweimal im Jahr manuell. Ein erfahrener Engineer exportiert die Konfiguration, scrollt durch Hunderte oder Tausende von Regeln und markiert alles, was falsch aussieht. Das dauert Tage, lässt Dinge übersehen, und wenn der Auditbericht geschrieben ist, hat sich das Regelwerk bereits wieder geändert. Der automatisierte Firewall-Schwachstellen-Scan ersetzt diesen Prozess durch kontinuierliche, wiederholbare Prüfungen, die Policy-Schwächen in dem Moment erkennen, in dem sie auftreten.

In diesem Leitfaden schlüsseln wir die 18 automatisierten Sicherheitsprüfungen auf, die jedes Firewall-Team durchführen sollte, zeigen, wie sie sich 4 Risikokategorien zuordnen lassen, und warum ein flottenweiter Scan in Multi-Vendor-Umgebungen alles verändert.

Was ist ein Firewall-Schwachstellen-Scan?

Ein Firewall-Schwachstellen-Scan ist die automatisierte Analyse von Firewall-Policies, um Sicherheitsschwächen, Fehlkonfigurationen und Compliance-Lücken aufzudecken. Anders als Netzwerk-Schwachstellenscanner (Nessus, Qualys), die Hosts auf Softwarefehler abklopfen, untersucht der Firewall-Schwachstellen-Scan die Regeln selbst, also die Logik, die steuert, welchen Datenverkehr Ihr Netzwerk zulässt und welchen es verweigert.

Diese Unterscheidung ist entscheidend. Eine perfekt gepatchte Firewall mit einem fehlkonfigurierten Regelwerk bleibt ein Sicherheitsrisiko. Eine any/any-Regel, ein offener RDP-Port oder ein fehlendes implizites Deny können Angriffsvektoren schaffen, die kein noch so umfangreiches Firmware-Update beheben wird. Der Firewall-Schwachstellen-Scan erkennt genau diese Probleme auf Policy-Ebene.

Die 4 Risikokategorien

Die 18 Prüfungen sind in 4 Kategorien gegliedert, je nach Art des Risikos, das sie adressieren. Jede Kategorie zielt auf eine andere Klasse von Policy-Schwächen ab.

Permissivität (5 Prüfungen)

Regeln, die mehr Datenverkehr zulassen als nötig. Dies sind die Findings mit dem höchsten Risiko, denn sie vergrößern Ihre Angriffsfläche unmittelbar.

VULN-001: Any-Any-Regeln, Regeln mit beliebiger Quelle, beliebigem Ziel und beliebigem Dienst. Sie lassen uneingeschränkten Datenverkehr zu und gelten als Findings der Schweregrad-Stufe „kritisch“. Ersetzen Sie sie durch spezifische Regeln auf Basis der tatsächlichen Datenverkehrsmuster.
VULN-002: Any-Source-Regeln, Regeln, die Datenverkehr von jeder beliebigen Quell-IP zulassen. Hoher Schweregrad. Beschränken Sie sie auf bekannte IP-Bereiche oder Netzwerkobjekte.
VULN-003: Any-Destination-Regeln, Regeln, die Datenverkehr zu jedem beliebigen Ziel zulassen. Hoher Schweregrad. Beschränken Sie sie auf bestimmte Server oder Netzwerksegmente.
VULN-004: Any-Service-Regeln, Regeln, die alle Protokolle und Ports zulassen. Mittlerer Schweregrad. Beschränken Sie sie auf die von den Anwendungen tatsächlich benötigten Dienste.
VULN-010: Default-Allow als letzte Regel, Wenn die letzte Regel der Policy „Allow-All“ statt „Deny-All“ ist. Kritischer Schweregrad. Jede Firewall-Policy muss mit einem expliziten Deny-All samt Logging enden.

Protokollrisiko (2 Prüfungen)

Regeln, die gefährliche Protokolle oder Ports gegenüber nicht vertrauenswürdigen Zonen freigeben. Diese Prüfungen erkennen Regeln, die in Produktionsumgebungen niemals existieren sollten.

VULN-005: Freigabe riskanter Ports, Regeln, die hochriskante Ports aus externen Zonen freigeben: RDP (3389), SMB (445), Telnet (23), FTP (21), Datenbank-Ports (3306, 5432, 1433), VNC (5900) und weitere. Hoher Schweregrad. Nutzen Sie VPN oder Jump-Hosts für den Fernzugriff.
VULN-011: Unsichere Protokolle, Regeln, die grundsätzlich unsichere Protokolle zulassen: Telnet, FTP, HTTP (statt HTTPS), TFTP. Hoher Schweregrad. Ersetzen Sie sie durch verschlüsselte Alternativen (SSH, SFTP, HTTPS).

Hygiene (9 Prüfungen)

Regeln, die Komplexität erhöhen, die Sichtbarkeit verringern oder auf ein schlechtes Lifecycle-Management hindeuten. Diese Findings steigern das operative Risiko und erschweren die Auditvorbereitung.

VULN-006: Shadow-Regeln, Regeln, die niemals greifen, weil sie vollständig von vorhergehenden Regeln verdeckt werden. Mittlerer Schweregrad.
VULN-007: Ungenutzte Regeln, Regeln mit null Treffern in 90 oder mehr Tagen. Niedriger Schweregrad. Prüfen und entfernen Sie sie, um die Angriffsfläche zu verringern.
VULN-008: Abgelaufene Regeln, Regeln, deren geplantes Ablauf- oder Überprüfungsdatum überschritten ist. Mittlerer Schweregrad.
VULN-009: Fehlendes Logging, Allow-Regeln ohne aktiviertes Logging. Mittlerer Schweregrad. Ohne Logging haben Sie keine Sichtbarkeit darüber, welchen Datenverkehr diese Regeln durchlassen.
VULN-012: Zu breites CIDR, Quelle oder Ziel, die ein /8- oder /16-CIDR verwenden, obwohl engere Bereiche ausreichen würden. Mittlerer Schweregrad.
VULN-014: Doppelte Regeln, Exakte Regelduplikate, die unnötige Komplexität hinzufügen. Niedriger Schweregrad.
VULN-015: Langlebige temporäre Regeln, Als temporär gekennzeichnete Regeln, die älter als 30 Tage sind. Hoher Schweregrad.
VULN-016: Keine Beschreibung, Regeln ohne geschäftliche Begründung oder Beschreibungskommentar. Schweregrad „Info“, aber ein Compliance-Warnsignal.
VULN-017: Deaktiviert, aber vorhanden, Deaktivierte Regeln, die die Policy überladen. Schweregrad „Info“. Entfernen Sie sie, um Verwirrung zu vermeiden.

Segmentierung (2 Prüfungen)

Regeln, die Netzwerksegmentierungs-Policies verletzen. Diese Findings deuten darauf hin, dass Zonengrenzen nicht ordnungsgemäß durchgesetzt werden.

VULN-013: Bidirektionales Allow, Regelpaare, die uneingeschränkten Datenverkehr in beide Richtungen zwischen Zonen zulassen. Mittlerer Schweregrad. Prüfen Sie sie und beschränken Sie sie je Richtung auf die notwendigen Dienste.
VULN-018: Zonenübergreifende Verstöße, Regeln, die die Zonensegmentierungs-Policy verletzen, etwa DMZ zu intern ohne Einschränkung. Hoher Schweregrad. Setzen Sie Zonensegmentierungs-Policies durch.

Flottenweiter Scan vs. Scan pro Firewall

Schwachstellenprüfungen auf einer einzelnen Firewall durchzuführen, ist nützlich. Sie über Ihre gesamte Flotte hinweg durchzuführen, ist transformativ. Ein flottenweiter Scan deckt Muster auf, die einem Audit pro Gerät entgehen: dieselbe Fehlkonfiguration über 20 Firewalls hinweg, ein Hygieneproblem, das jede Niederlassung betrifft, oder ein Segmentierungsverstoß, der nur auf den von einem bestimmten Team verwalteten Geräten existiert.

In Multi-Vendor-Umgebungen normalisiert ein flottenweiter Scan außerdem die Findings über die unterschiedlichen Hersteller-Syntaxen hinweg. Eine any/any-Regel auf Palo Alto sieht anders aus als eine any/any-Regel auf Fortinet oder Check Point, doch die Schwachstelle ist dieselbe. Der automatisierte Scan abstrahiert die Herstellerunterschiede und präsentiert konsistente Findings.

Automatisierte vs. manuelle Audits

Manuelle Firewall-Regel-Audits sind für kontextabhängige Analysen unverzichtbar, etwa um zu verstehen, ob eine bestimmte Regel betrieblich sinnvoll ist, um Risiken im Kontext Ihrer Netzwerktopologie zu bewerten oder um zu prüfen, ob Regeln mit den Anwendungsanforderungen übereinstimmen. Der automatisierte Scan ersetzt dieses Urteilsvermögen nicht.

Was der automatisierte Scan leistet, ist die Bewältigung der mechanischen Prüfungen, die Menschen mühsam und fehleranfällig finden. Kein Mensch sollte in einem Regelwerk mit 2.000 Regeln manuell nach Shadow-Regeln suchen. Kein Mensch sollte CIDR-Bereiche von Hand mit Zonendefinitionen abgleichen. Das sind wiederholbare, deterministische Prüfungen, die Maschinen in Sekunden und Menschen in Stunden erledigen.

Der beste Ansatz: beides

Automatisierter Scan: Läuft kontinuierlich oder nach Zeitplan. Erkennt mechanische Probleme sofort. Verfolgt Trends im Zeitverlauf. Deckt jede Firewall der Flotte ab.
Manuelles Audit: Vierteljährlich oder vor Compliance-Bewertungen durchführen. Validiert den geschäftlichen Kontext. Überprüft Regel-Ownership und -Begründung. Bewertet Architekturentscheidungen.

Schweregrad-Bewertung und Trend-Tracking

Nicht alle Findings sind gleich. FwChange weist jeder Prüfung Schweregradgewichte zu: kritisch (100 Punkte), hoch (75), mittel (50), niedrig (25) und Info (10). Der Gesamtschwachstellen-Score einer Firewall ist die gewichtete Summe aller Findings. So erhalten Sie eine einzige Kennzahl, die Sie über die Zeit verfolgen und geräteübergreifend vergleichen können.

Das Trend-Tracking ist wichtiger als absolute Scores. Eine Firewall, die innerhalb von 3 Monaten von einem Score von 450 auf 200 sinkt, verbessert sich. Eine Firewall, die nach einem Change-Window von 100 auf 350 springt, muss untersucht werden. Das Ziel ist kontinuierliche Verbesserung, nicht Perfektion.

Erste Schritte

Wenn Sie heute Firewall-Regeln ohne automatisierten Schwachstellen-Scan verwalten, beginnen Sie mit diesen Schritten:

1. Erfassen Sie Ihren Ist-Zustand

Führen Sie die 18 Prüfungen gegen Ihre bestehenden Regelwerke aus. Dokumentieren Sie die Gesamtzahl der Findings nach Kategorie und Schweregrad. Das ist Ihr Ausgangspunkt.

2. Priorisieren Sie Kritisch und Hoch

Beheben Sie zuerst any/any-Regeln, Default-Allow, riskante Port-Freigaben und unsichere Protokolle. Das sind die Findings, die Auditoren markieren und Angreifer ausnutzen werden.

3. Planen Sie regelmäßige Scans

Führen Sie Schwachstellen-Scans wöchentlich oder nach jedem Change-Window aus. Verfolgen Sie Ihren Score im Zeitverlauf. Verankern Sie das Scannen in Ihrem Change-Management-Prozess, damit jedes Deployment automatisch geprüft wird.

4. Erweitern Sie auf die gesamte Flotte

Sobald der Scan pro Firewall zur Routine geworden ist, erweitern Sie ihn auf flottenweite Scans. Vergleichen Sie Scores über Geräte und Teams hinweg. Identifizieren Sie systemische Probleme, die Ihre gesamte Infrastruktur betreffen.

Der automatisierte Firewall-Schwachstellen-Scan ist kein Ersatz für versierte Security Engineers. Er ist ein Kraftverstärker, der Ihrem Team erlaubt, sich auf die Analysen zu konzentrieren, die menschliches Urteilsvermögen erfordern, während Maschinen die mechanischen Prüfungen übernehmen, bei denen das nicht der Fall ist.