Skip to main content

9.5 Netzwerkfirewall, ACL-Reihenfolge und Stateful Inspection

Eine Netzwerkfirewall kontrolliert den Datenverkehr zwischen Netzen, Sicherheitszonen, Standorten, Cloud-Umgebungen oder einzelnen Netzsegmenten. Eine vorhandene Freigaberegel beweist jedoch noch nicht, dass der Datenverkehr tatsächlich erlaubt wird. Entscheidend sind unter anderem:

  • die tatsächlich durchlaufene Firewall;
  • die Eingangs- und Ausgangsschnittstelle;
  • Quell- und Zielzone;
  • Quell- und Zieladresse;
  • Quell- und Zielport;
  • Protokoll;
  • Regelreihenfolge und Priorität;
  • NAT-Verarbeitung;
  • Routingentscheidung;
  • bestehender Sitzungszustand;
  • zusätzliche Sicherheitsprofile;
  • Rückweg;
  • Hochverfügbarkeitszustand;
  • verwendeter virtueller Firewallkontext;
  • Zeitpunkt und Konfigurationsversion.

Diese Seite behandelt Netzwerkfirewalls und zentrale Netzwerk-ACLs. Die lokale Firewall eines Endgeräts oder Servers wurde bereits unter 9.4 Lokale Host-Firewall prüfen behandelt.

Ziele

Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können:

  • ob der betroffene Datenverkehr die vorgesehene Firewall durchläuft;
  • welche Regel tatsächlich angewendet wird;
  • ob eine allgemeinere Regel eine spezifische Regel überschattet;
  • ob ein implizites Verbot greift;
  • ob die Firewall zustandsbehaftet oder zustandslos arbeitet;
  • ob eine vorhandene Sitzung den aktuellen Test beeinflusst;
  • ob der Rückverkehr einer bestehenden Sitzung zugeordnet wird;
  • ob NAT, Routing oder Zonenwahl die Regelzuordnung verändern;
  • ob ein Sicherheitsprofil trotz erlaubender Netzwerkregel blockiert;
  • ob die Störung an der Firewall oder an einem anderen Netzabschnitt liegt;
  • wie eine Änderung kontrolliert und anschließend verifiziert wird.

Sicherheits- und Änderungsgrundsätze

Eine Netzwerkfirewall ist häufig ein zentraler Sicherheits- und Verfügbarkeitsbestandteil. Unkontrollierte Änderungen können viele Systeme gleichzeitig betreffen.

Vor jeder Änderung sind mindestens festzuhalten:

  • betroffene Anwendung;
  • Quelle und Ziel;
  • benötigtes Protokoll;
  • benötigte Ports;
  • Datenflussrichtung;
  • betroffene Sicherheitszonen;
  • aktuell passende Regel;
  • aktuelle Konfigurationsversion;
  • zuständige Freigabe;
  • Risiko;
  • Rückweg;
  • Erfolgskriterium;
  • vorgesehenes Testverfahren;
  • Wartungs- oder Änderungsfenster.

Nicht als erste Diagnosemaßnahme geeignet sind:

  • Firewall deaktivieren;
  • eine allgemeine any-zu-any-Freigabe erstellen;
  • Regelwerk vollständig neu laden;
  • produktive Regeln ungeprüft verschieben;
  • Sitzungs- oder Verbindungstabellen vollständig löschen;
  • NAT-Tabellen vollständig leeren;
  • Hochverfügbarkeitsumschaltung erzwingen;
  • Sicherheitsprofile pauschal deaktivieren;
  • Intrusion Prevention abschalten;
  • TLS-Inspektion global ausschalten;
  • Paketfilterung durch eine direkte Umgehungsroute umgehen;
  • Firewall oder Cluster vorsorglich neu starten;
  • Zähler vor der Beweissicherung zurücksetzen.

Eine kurzfristige Testregel muss genauso präzise wie eine dauerhafte Regel begrenzt werden. Sie benötigt:

  • eindeutigen Namen;
  • dokumentierten Zweck;
  • exakte Quelle;
  • exaktes Ziel;
  • erforderliches Protokoll;
  • erforderlichen Zielport;
  • Protokollierung;
  • verantwortliche Person;
  • Ablaufzeitpunkt;
  • dokumentierte Entfernung.

Netzwerkfirewall und Host-Firewall unterscheiden

Merkmal Netzwerkfirewall Host-Firewall
Standort zwischen Netzen oder Sicherheitszonen direkt auf dem Endgerät oder Server
Sichtbarer Datenverkehr nur Verkehr, der die Firewall tatsächlich durchläuft ein- und ausgehender Verkehr des lokalen Systems
Typische Regeln Zonen, Netze, Adressen, Dienste, Anwendungen Programme, Dienste, Profile, lokale Ports, Benutzer
Zustandsverwaltung zentrale Sitzungstabelle lokale Verbindungstabelle
Protokollierung zentrale Firewall- und Sicherheitsprotokolle lokales Betriebssystemprotokoll
Häufige Fehlerquelle falsche Zone, Regelreihenfolge, NAT, Route, Sitzung falsches Profil, Dienstregel, Programmpfad
Umgehungsmöglichkeit lokales Routing oder direkter Pfad zwischen Systemen normalerweise nicht für lokalen Netzwerkverkehr

Eine Netzwerkfirewall kann nur Datenverkehr prüfen, der tatsächlich über sie geleitet wird. Befinden sich Quelle und Ziel beispielsweise im selben VLAN, kann der Verkehr die zentrale Firewall vollständig umgehen.

Vereinfachter Datenfluss

Ein typischer Datenfluss kann folgende Verarbeitungsschritte enthalten:

  1. Paket trifft auf einer Eingangsschnittstelle ein.
  2. Eingangszone oder Sicherheitskontext wird bestimmt.
  3. Vorhandene Sitzung wird gesucht.
  4. NAT- und Routingregeln werden ausgewertet.
  5. Ausgangsschnittstelle und Ausgangszone werden bestimmt.
  6. Sicherheitsregel wird ermittelt.
  7. Zusätzliche Prüfungen werden ausgeführt.
  8. Paket wird weitergeleitet oder verworfen.
  9. Eine neue Sitzung wird angelegt oder eine vorhandene aktualisiert.
  10. Rückverkehr wird einer Sitzung zugeordnet.
  11. Ereignisse, Zähler und Sitzungsdaten werden protokolliert.

Die genaue Reihenfolge von NAT, Routing, Sicherheitsrichtlinie, Anwendungserkennung und Inhaltsprüfung ist produktspezifisch. Sie muss für das eingesetzte Firewallprodukt und die verwendete Softwareversion geprüft werden.

Einen Datenfluss eindeutig beschreiben

Vor der Regelprüfung muss der betroffene Datenfluss vollständig beschrieben werden.

Beispiel:

Zeitpunkt:
2026-08-02 10:15:32 Europe/Berlin

Quelle:
192.0.2.100

Quellzone:
CLIENTS

Quellport:
53124

Ziel:
198.51.100.25

Zielzone:
SERVER

Zielport:
443

Protokoll:
TCP

Anwendung:
HTTPS-Zugriff auf app.example.test

Erwarteter Pfad:
CLIENTS -> FW-CLUSTER-01 -> SERVER

Erwartete Regel:
ALLOW-CLIENTS-APP-HTTPS

Erwartete NAT-Verarbeitung:
keine

Bei TCP und UDP wird ein Datenfluss typischerweise über das Fünf-Tupel beschrieben:

Quelladresse
Quellport
Zieladresse
Zielport
IP-Protokoll

Für die Firewalldiagnose kommen weitere Merkmale hinzu:

  • Eingangsschnittstelle;
  • Ausgangsschnittstelle;
  • Quellzone;
  • Zielzone;
  • Mandant oder virtueller Kontext;
  • Benutzeridentität;
  • erkannte Anwendung;
  • NAT-Adressen und NAT-Ports;
  • Zeitplan;
  • Sicherheitsprofil;
  • VPN- oder Tunnelzuordnung;
  • Regel-ID;
  • Sitzungs-ID.

Quellport und Zielport nicht verwechseln

Bei einer üblichen Clientverbindung verwendet der Client einen dynamischen Quellport und der Server einen bekannten Zielport.

Beispiel:

192.0.2.100:53124 -> 198.51.100.25:443/TCP

Dabei gilt:

Feld Bedeutung
192.0.2.100 Clientadresse
53124 dynamischer Quellport des Clients
198.51.100.25 Serveradresse
443 Zielport des HTTPS-Dienstes

Eine Freigabe, die irrtümlich den Quellport 443 statt des Zielports 443 prüft, passt normalerweise nicht auf diesen Verbindungsaufbau.

Der Rückverkehr besitzt vertauschte Adressen und Ports:

198.51.100.25:443 -> 192.0.2.100:53124/TCP

Bei einer zustandsbehafteten Firewall wird dieser Rückverkehr üblicherweise über den bestehenden Sitzungszustand erlaubt. Bei einer zustandslosen ACL muss der Rückverkehr ausdrücklich berücksichtigt werden.

Eingehend und ausgehend richtig einordnen

Inbound, ingress, outbound und egress beziehen sich auf eine bestimmte Schnittstelle, Zone oder Ressource. Die Begriffe dürfen nicht ohne diesen Bezug verwendet werden.

Beispiel:

Clientnetz -> Firewall -> Servernetz

Aus Sicht der Firewall:

  • auf der Client-Schnittstelle trifft der Verbindungsaufbau eingehend ein;
  • zur Server-Schnittstelle verlässt er die Firewall ausgehend;
  • der Rückverkehr trifft auf der Server-Schnittstelle eingehend ein;
  • zum Clientnetz verlässt er die Firewall ausgehend.

Bei Cloud-ACLs kann sich inbound oder outbound auf ein Subnetz, eine Netzwerkschnittstelle oder eine virtuelle Maschine beziehen. Deshalb müssen Ressource und Richtung immer gemeinsam dokumentiert werden.

Arten der Filterung

Verfahren Auswertung Sitzungszustand Typische Eigenschaft
zustandslose ACL jedes Paket einzeln nein Rückverkehr benötigt eigene passende Regel
Stateful Inspection Paket und bestehende Sitzung ja Rückverkehr bestehender Sitzungen wird zugeordnet
Proxy-Firewall beendet und vermittelt die Verbindung ja Client und Ziel kommunizieren nicht direkt miteinander
Application Firewall Anwendung oder Protokollinhalt ja Entscheidung kann von erkannter Anwendung abhängen
Next-Generation Firewall Netzwerk-, Sitzungs-, Benutzer- und Anwendungsdaten ja zusätzliche URL-, Malware-, IPS- oder TLS-Prüfung
Cloud Security Group ressourcenbezogene Regeln häufig ja Verhalten unterscheidet sich von Subnetz-ACLs
Cloud Network ACL subnetzbezogene Paketfilterung häufig nein Priorität und Rückregeln sind besonders wichtig

Die Produktbezeichnung allein reicht nicht zur Bewertung. Es muss geprüft werden, welche Regelkomponente den betroffenen Datenfluss tatsächlich verarbeitet.

ACL-Reihenfolge

Viele Netzwerkfirewalls und Router prüfen Regeln in einer definierten Reihenfolge. Häufig gilt:

  1. Regeln werden von oben nach unten oder nach Priorität geprüft.
  2. Die erste vollständig passende Regel bestimmt die Aktion.
  3. Nach einem Treffer werden nachfolgende Regeln nicht mehr geprüft.
  4. Trifft keine Regel zu, greift häufig eine implizite Standardaktion.

Dieses Verhalten ist verbreitet, aber nicht für jedes Produkt und jede Regelart identisch. Zu prüfen sind:

  • globale Regeln;
  • lokale Regeln;
  • geerbte Regeln;
  • Schnittstellen-ACLs;
  • Zonenregeln;
  • Vorregeln und Nachregeln;
  • Parent- und Child-Policies;
  • Regelgruppen;
  • Sicherheitsprofile;
  • herstellerspezifische Ausnahme- und Standardregeln.

Beispiel für eine sinnvolle Reihenfolge

Anforderung:

  • Host 192.0.2.66 darf den Server nicht erreichen.
  • Andere Clients aus 192.0.2.0/24 dürfen HTTPS verwenden.
  • Nicht ausdrücklich erlaubter Verkehr wird protokolliert verworfen.

Vereinfachte Regelreihenfolge:

10 deny   tcp 192.0.2.66/32  -> 198.51.100.25/32 port 443 log
20 permit tcp 192.0.2.0/24   -> 198.51.100.25/32 port 443 log
90 deny   ip  any            -> any                    log

Die spezifische Sperre steht vor der allgemeineren Freigabe.

Fehlerhafte Reihenfolge:

10 permit tcp 192.0.2.0/24   -> 198.51.100.25/32 port 443 log
20 deny   tcp 192.0.2.66/32  -> 198.51.100.25/32 port 443 log
90 deny   ip  any            -> any                    log

Wenn das Produkt nach dem ersten Treffer beendet, wird Host 192.0.2.66 bereits durch Regel 10 erlaubt. Regel 20 ist für diesen Datenfluss nicht erreichbar.

Überschattete, redundante und widersprüchliche Regeln

Regelproblem Beschreibung Auswirkung
überschattete Regel frühere allgemeinere Regel deckt alle Treffer der späteren Regel ab spätere Regel wird nie verwendet
teilweise überschattete Regel frühere Regel deckt einen Teil des späteren Bereichs ab Regel wirkt nur für den verbleibenden Teil
redundante Regel Regel erlaubt oder verbietet bereits identisch behandelten Verkehr unnötige Komplexität
widersprüchliche Regel gleiche oder überlappende Kriterien besitzen andere Aktion Ergebnis hängt von Reihenfolge ab
veraltete Regel zugehöriger Dienst oder Eigentümer existiert nicht mehr unnötige Angriffsfläche
ungebundene ACL ACL ist definiert, aber keiner Schnittstelle oder Zone zugeordnet keine Wirkung
falscher Kontext Regel liegt in anderem Mandanten oder virtuellen System keine Wirkung auf den betroffenen Verkehr
falsche Richtung Regel ist für Gegenrichtung angelegt erwarteter Verbindungsaufbau bleibt blockiert
falsche Adressphase Regel verwendet falsche NAT-Adresse kein Treffer
falsche Regelart Netzwerkregel statt Anwendungsregel oder umgekehrt unerwartete Verarbeitung

Regelanalysen des Herstellers können bei der Erkennung helfen. Das Ergebnis muss trotzdem mit realen Trefferzählern, Protokollen und einem kontrollierten Verbindungstest bestätigt werden.

Implizite Standardaktion

Viele ACL- und Firewallregelwerke besitzen am Ende eine implizite Verweigerung. Diese Regel ist möglicherweise nicht als normale Konfigurationszeile sichtbar.

Vereinfachtes Modell:

permit <ausdrücklich erlaubter Verkehr>
deny   <ausdrücklich gesperrter Verkehr>
deny   any any <implizit>

Ein explizites abschließendes Verbot mit Protokollierung kann die Diagnose erleichtern:

deny any any log

Ob eine solche Regel sinnvoll und zulässig ist, hängt vom Produkt und der Protokollierungsleistung ab. Eine stark ausgelastete abschließende Protokollregel kann sehr viele Ereignisse erzeugen.

Zu prüfen sind:

  • existiert eine implizite Verweigerung?
  • welche Regelart besitzt sie?
  • gilt sie pro Schnittstelle, Zone, Regelgruppe oder Kontext?
  • wird ein Treffer protokolliert?
  • existieren Ausnahmen für System- oder Verwaltungsverkehr?
  • greifen vorher noch globale oder geerbte Regeln?
  • existiert eine vom Hersteller bereitgestellte Standardregel?

Ein fehlender sichtbarer deny-Eintrag beweist nicht, dass nicht passender Verkehr erlaubt wird.

Regelkriterien vollständig prüfen

Eine moderne Firewall kann deutlich mehr als nur IP-Adresse und Port auswerten.

Kriterium Zu prüfender Punkt
Quellzone stimmt die Zone der tatsächlichen Eingangsschnittstelle?
Zielzone entspricht sie der durch Routing bestimmten Ausgangszone?
Quelladresse Originaladresse, NAT-Adresse oder Adressobjekt?
Zieladresse Originalziel oder übersetztes Ziel?
Quellport dynamischer Port oder fest definierter Dienstport?
Zielport tatsächlich verwendeter Dienstport?
Protokoll TCP, UDP, ICMP, ESP, GRE oder anderes IP-Protokoll?
Anwendung bereits erkannt, noch unbekannt oder verschlüsselt?
Dienst fest definierter Port oder anwendungsabhängiger Standardport?
Benutzer konnte die Firewall die Identität ermitteln?
Gerät passt die Geräte- oder Endpunktklassifizierung?
Zeitplan ist die Regel zum Fehlerzeitpunkt aktiv?
URL-Kategorie wird das Ziel einer anderen Kategorie zugeordnet?
FQDN-Objekt auf welche Adressen wurde der Name aufgelöst?
Sicherheitsprofil Malware-, IPS-, Datei- oder URL-Prüfung aktiv?
Mandant richtiger virtueller Router oder Firewallkontext?
VPN gilt eine zusätzliche VPN- oder Tunnelregel?

Eine Regel kann auf Netzwerkebene allow ergeben und anschließend trotzdem durch ein Sicherheitsprofil blockiert werden.

Adress- und Dienstobjekte prüfen

Regeln verwenden häufig Objekte statt direkt eingetragener IP-Adressen und Ports.

Zu prüfen sind:

  • aktueller Objektinhalt;
  • CIDR-Präfix;
  • IPv4- oder IPv6-Zuordnung;
  • einzelne Adresse oder gesamtes Netz;
  • verschachtelte Objektgruppen;
  • doppelte Gruppenmitgliedschaften;
  • dynamische Gruppen;
  • Cloud-Tags;
  • FQDN-Auflösung;
  • Aktualisierungszeitpunkt;
  • Portbereich;
  • TCP- oder UDP-Zuordnung;
  • deaktivierte oder abgelaufene Objekte;
  • Synchronisation zwischen Clusterknoten.

Beispiel für eine häufige Netzmaskenverwechslung:

192.0.2.0/24

umfasst:

192.0.2.0 bis 192.0.2.255

Dagegen umfasst:

192.0.2.100/32

nur die einzelne Adresse:

192.0.2.100

Bei Produkten mit Wildcard-Masken ist die Schreibweise nicht mit einer normalen Subnetzmaske gleichzusetzen.

FQDN- und dynamische Objekte

Ein FQDN-Objekt kann von der Firewall regelmäßig in eine oder mehrere IP-Adressen aufgelöst werden.

Zu prüfen sind:

  • welcher DNS-Server von der Firewall verwendet wird;
  • ob die DNS-Auflösung erfolgreich ist;
  • welche A- und AAAA-Adressen gespeichert sind;
  • TTL und Aktualisierungszeitpunkt;
  • unterschiedliche Antworten durch Geo-DNS oder CDN;
  • Erreichbarkeit über IPv4 und IPv6;
  • maximale Anzahl unterstützter Adressen;
  • Verhalten bei fehlgeschlagener Aktualisierung;
  • Synchronisation im Cluster.

Ein Client und eine Firewall können denselben FQDN zu unterschiedlichen Zieladressen auflösen. Dann kann eine scheinbar passende FQDN-Regel den tatsächlichen Clientverkehr verfehlen.

Stateful Inspection

Eine zustandsbehaftete Firewall bewertet nicht jedes Paket vollständig unabhängig. Sie führt eine Sitzungstabelle und ordnet weitere Pakete einem bekannten Datenfluss zu.

Vereinfachter TCP-Ablauf:

  1. Client sendet SYN.
  2. Firewall findet keine vorhandene Sitzung.
  3. Firewall prüft Route, Zone, NAT und Richtlinie.
  4. Bei Erlaubnis wird ein Sitzungseintrag angelegt.
  5. Server sendet SYN, ACK.
  6. Firewall ordnet das Paket der bestehenden Sitzung zu.
  7. Client sendet ACK.
  8. Sitzung wechselt in den etablierten Zustand.
  9. Weitere Pakete werden anhand der Sitzung verarbeitet.
  10. FIN, RST oder Timeout beendet die Sitzung.

Eine zustandsbehaftete Firewall kann Pakete verwerfen, wenn diese nicht zum erwarteten Zustand passen, beispielsweise:

  • ACK ohne bekannte Sitzung;
  • unerwartete TCP-Flags;
  • Rückverkehr mit abweichenden Adressen oder Ports;
  • Sequenznummer außerhalb des akzeptierten Fensters;
  • verspäteter Rückverkehr nach Sitzungsablauf;
  • Rückverkehr über einen anderen nicht synchronisierten Firewallknoten;
  • fragmentierter Verkehr, der nicht korrekt zugeordnet werden kann.

Typische Daten eines Sitzungseintrags

Ein Sitzungseintrag kann unter anderem enthalten:

Sitzungs-ID
Protokoll
Quellzone
Zielzone
Eingangsschnittstelle
Ausgangsschnittstelle
Original-Quelladresse
Original-Quellport
Original-Zieladresse
Original-Zielport
übersetzte Quelladresse
übersetzter Quellport
übersetzte Zieladresse
übersetzter Zielport
passende Regel
Anwendung
TCP-Zustand
Startzeit
letzte Aktivität
Timeout
gesendete Pakete
empfangene Pakete
gesendete Bytes
empfangene Bytes
Sitzungsendgrund
Clusterbesitzer

Die Sitzungstabelle ist ein wichtiger Nachweis, ersetzt aber nicht die Prüfung der tatsächlichen Anwendung.

Eine vorhandene Sitzung beweist nur, dass die Firewall einen Zustand führt. Sie beweist nicht automatisch:

  • dass der Serverprozess korrekt antwortet;
  • dass TLS funktioniert;
  • dass die Anwendung ein gültiges Ergebnis liefert;
  • dass Nutzdaten in beide Richtungen übertragen werden;
  • dass die Sitzung nicht bereits festhängt;
  • dass alle weiteren Sicherheitsprüfungen erfolgreich sind.

Zustandslos und zustandsbehaftet vergleichen

Prüfpunkt Zustandslose ACL Stateful Firewall
Verarbeitung jedes Paket einzeln Paket plus Sitzungszustand
Rückverkehr benötigt passende Gegenregel bestehender Sitzung zugeordnet
TCP-Zustand normalerweise nicht vollständig verfolgt Handshake und Status werden verfolgt
UDP jedes Datagramm nach Regel häufig zeitlich begrenzte Pseudositzung
ICMP eigene Regeln pro Richtung erforderlich kann Anfrage und Antwort zuordnen
Asymmetrischer Pfad Regel kann trotzdem passen häufig Sitzungsproblem
Ressourcenverbrauch geringer Sitzungstabelle benötigt Speicher
Timeoutwirkung keine Sitzung Rückverkehr kann nach Ablauf verworfen werden
Regeländerung wirkt auf folgende Pakete bestehende Sitzungen können abweichend behandelt werden

Das Verhalten bei Regeländerungen und bestehenden Sitzungen ist produktspezifisch. Einige Systeme prüfen bestehende Sitzungen nicht sofort erneut, andere beenden betroffene Sitzungen oder bewerten bestimmte Eigenschaften erneut.

TCP-Verkehr prüfen

Bei TCP sind mindestens folgende Punkte zu unterscheiden:

  • erreicht das SYN die Firewall?
  • welche Regel trifft auf das SYN?
  • verlässt das SYN die Firewall?
  • erreicht das SYN den Server?
  • sendet der Server ein SYN, ACK oder RST?
  • erreicht die Antwort dieselbe Firewallinstanz?
  • wird die Antwort der Sitzung zugeordnet?
  • erreicht die Antwort den Client?
  • wird der Handshake vollständig abgeschlossen?
  • endet die Sitzung durch FIN, RST, Timeout oder Richtlinie?

Befundbeispiele:

Paketfolge Mögliche Einordnung
wiederholte SYN, keine Antwort Paketverlust, Firewall-Drop, falsche Route oder Server antwortet nicht
SYN, danach sofortiges RST Ziel lehnt aktiv ab oder Zwischenkomponente erzeugt Reset
SYN, SYN-ACK, anschließend kein ACK Rückweg zum Client oder Clientseite prüfen
vollständiger Handshake, danach sofortiger RST Anwendung, Proxy, Sicherheitsprofil oder Protokollproblem
Daten nur in eine Richtung Rückweg, asymmetrischer Pfad oder Sicherheitsprüfung
Sitzung in Firewall vorhanden, keine Serverantwort Zielsystem, nachgelagerte Firewall oder Route prüfen

UDP-Verkehr prüfen

UDP besitzt keinen TCP-Handshake. Stateful Firewalls führen deshalb häufig eine zeitlich begrenzte Pseudositzung.

Beispiel:

192.0.2.100:54000 -> 198.51.100.53:53/UDP

Die Firewall kann anschließend eine passende Antwort erlauben:

198.51.100.53:53 -> 192.0.2.100:54000/UDP

Zu prüfen sind:

  • wurde das erste Datagramm durch eine Regel erlaubt?
  • wurde eine Pseudositzung angelegt?
  • trifft die Antwort vor Ablauf des UDP-Timeouts ein?
  • stimmen Antwortadresse und Antwortport mit dem erwarteten Datenfluss überein?
  • verwendet die Anwendung mehrere Zieladressen oder Ports?
  • wechselt das Protokoll von UDP zu TCP?
  • wird ICMP Destination Unreachable zurückgegeben?
  • blockiert eine zustandslose Gegen-ACL den Rückverkehr?

Ein vorhandener UDP-Sitzungseintrag beweist keine erfolgreiche Anwendungskommunikation.

ICMP und ICMPv6 prüfen

ICMP transportiert nicht nur Echo-Anfrage und Echo-Antwort, sondern auch wichtige Fehlermeldungen.

Beispiele:

  • Ziel nicht erreichbar;
  • Port nicht erreichbar;
  • Fragmentierung erforderlich;
  • Time Exceeded;
  • Parameter Problem;
  • Packet Too Big bei IPv6.

Zu prüfen sind:

  • ICMP-Typ und ICMP-Code;
  • Richtung;
  • Quell- und Zieladresse;
  • Zuordnung zu einer ursprünglichen Sitzung;
  • separate ICMP-Regeln;
  • ICMP-Inspektionsfunktion;
  • IPv4- und IPv6-Regeln;
  • Rate Limits;
  • vorgeschaltete Router-ACLs.

Das pauschale Blockieren von ICMP kann Diagnose, Path-MTU-Discovery und besonders IPv6-Funktionen beeinträchtigen.

Sitzungstimeouts

Stateful Firewalls entfernen inaktive Sitzungen nach definierten Zeiträumen.

Zu prüfen sind:

  • TCP-Handshake-Timeout;
  • TCP-Idle-Timeout;
  • TCP-Time-Wait- oder Closing-Timeout;
  • UDP-Timeout;
  • ICMP-Timeout;
  • anwendungsspezifischer Timeout;
  • halb offene Verbindungen;
  • Langzeitverbindungen;
  • Keepalive-Verhalten;
  • maximale Sitzungsdauer;
  • benutzerdefinierte Timeoutprofile;
  • Sitzungslast und Tabellenfüllstand.

Typische Symptome eines Timeoutproblems:

  • kurze Verbindungen funktionieren;
  • lange Leerlaufphasen beenden die Verbindung;
  • Anwendung meldet nach einer festen Zeit einen Abbruch;
  • die nächste Übertragung nach Inaktivität schlägt fehl;
  • eine neue Verbindung funktioniert sofort wieder;
  • Client und Server halten die Sitzung unterschiedlich lange für gültig.

Ein Timeout sollte nur geändert werden, wenn der zeitliche Zusammenhang nachgewiesen wurde. Eine pauschale Erhöhung kann den Speicherverbrauch und die Anzahl gleichzeitig geführter Sitzungen vergrößern.

Bestehende Sitzungen bei Regeländerungen

Nach einer Regeländerung sind neue und bestehende Verbindungen getrennt zu prüfen.

Mögliche produktabhängige Verhaltensweisen:

  • neue Sitzungen verwenden die neue Regel;
  • vorhandene Sitzungen laufen nach alter Entscheidung weiter;
  • vorhandene Sitzungen werden neu bewertet;
  • verweigernde Änderung beendet passende Sitzungen;
  • NAT-Änderung wirkt erst auf neue Sitzungen;
  • Anwendungserkennung ändert die verwendete Regel während der Sitzung;
  • Clusterknoten besitzen vorübergehend unterschiedliche Zustände.

Deshalb muss ein Test dokumentieren:

Test A:
bereits vor der Änderung bestehende Verbindung

Test B:
nach der Änderung vollständig neu aufgebaute Verbindung

Wenn ein neuer Test erforderlich ist, sollte nur die einzelne betroffene Anwendungssitzung kontrolliert beendet werden. Das vollständige Löschen der Sitzungstabelle ist unverhältnismäßig und kann viele produktive Verbindungen unterbrechen.

Routing und Zielzone

Die Zielzone wird bei vielen Firewalls anhand der Ausgangsschnittstelle oder Routingentscheidung bestimmt.

Zu prüfen sind:

  • aktive Route zur Zieladresse;
  • Präfixlänge;
  • nächster Hop;
  • Routinginstanz oder VRF;
  • Policy-Based Routing;
  • ECMP;
  • Tunnelroute;
  • dynamisches Routing;
  • Failoverroute;
  • Ausgangsschnittstelle;
  • daraus resultierende Zielzone.

Eine Sicherheitsregel kann inhaltlich korrekt aussehen, aber nicht passen, wenn die Firewall aufgrund einer falschen Route eine andere Zielzone bestimmt.

Beispiel:

Erwartet:
CLIENTS -> SERVER

Tatsächlich:
CLIENTS -> WAN

In diesem Fall ist nicht zuerst die Regel CLIENTS -> SERVER zu verändern. Zunächst muss geklärt werden, warum die Route zur falschen Ausgangszone führt.

NAT und Sicherheitsrichtlinie

NAT kann Adressen und Ports verändern.

Beispiel einer Zielübersetzung:

Original:
203.0.113.40:55000 -> 198.51.100.10:443

Nach DNAT:
203.0.113.40:55000 -> 10.20.30.40:8443

Beispiel einer Quellübersetzung:

Original:
10.10.20.25:53124 -> 203.0.113.80:443

Nach SNAT:
198.51.100.5:61001 -> 203.0.113.80:443

Für die Diagnose sind beide Ansichten zu dokumentieren:

Merkmal Vor NAT Nach NAT
Quelladresse ursprünglicher Absender übersetzte Quelladresse
Quellport ursprünglicher Quellport übersetzter Quellport
Zieladresse aufgerufene Zieladresse internes oder übersetztes Ziel
Zielport aufgerufener Zielport übersetzter Zielport

Je nach Hersteller, Regelart und Richtung kann die Sicherheitsrichtlinie vor oder nach einer bestimmten NAT-Verarbeitung ausgewertet werden. Es darf nicht angenommen werden, dass eine Firewallregel immer die öffentliche oder immer die private Adresse verwenden muss.

Zu prüfen sind:

  • NAT-Regel;
  • Sicherheitsregel;
  • Reihenfolge der Verarbeitung;
  • Original- und Übersetzungsadresse;
  • Original- und Übersetzungsport;
  • NAT-Ausnahme;
  • Hairpin- oder U-Turn-NAT;
  • doppelte NAT-Regeln;
  • Proxy-ARP;
  • Rückroute;
  • NAT-Sitzung;
  • Porterschöpfung;
  • Clusterzustand.

Eine passende Sicherheitsregel kann durch eine falsche NAT-Regel wirkungslos bleiben.

Zonen und virtuelle Kontexte

Viele Firewalls besitzen:

  • Sicherheitszonen;
  • virtuelle Router;
  • virtuelle Systeme;
  • Mandanten;
  • Security Contexts;
  • Routinginstanzen;
  • Verwaltungs- und Datenebenen;
  • zentrale und lokale Richtlinien.

Zu prüfen sind:

  • richtige Firewall;
  • aktiver Clusterknoten;
  • richtiger Mandant;
  • richtiger virtueller Kontext;
  • richtige Routinginstanz;
  • richtige Policy-Version;
  • richtige Eingangszone;
  • richtige Ausgangszone;
  • globale oder geerbte Regeln;
  • lokale Ausnahmen;
  • zentral verwaltete und lokal definierte Regeln.

Eine Regel in einem anderen virtuellen Kontext kann denselben Namen besitzen, aber für den betroffenen Datenverkehr vollständig wirkungslos sein.

Zusätzliche Sicherheitsprüfungen

Eine Regel mit der Aktion allow bedeutet bei modernen Firewalls häufig nur, dass der Datenfluss weiter geprüft werden darf.

Weitere mögliche Prüfungen:

  • Intrusion Prevention;
  • Malware-Erkennung;
  • Antivirus;
  • Dateitypprüfung;
  • URL-Filterung;
  • DNS-Sicherheitsprüfung;
  • Anwendungskontrolle;
  • Benutzeridentifikation;
  • Data Loss Prevention;
  • Botnet-Erkennung;
  • TLS-Entschlüsselung;
  • Zertifikatsprüfung;
  • Protokolldekodierung;
  • Geo-IP-Regel;
  • Reputationsprüfung;
  • Threat-Intelligence-Regel;
  • DoS-Schutz;
  • Zone Protection;
  • Flood Protection.

Deshalb sind mindestens zwei Entscheidungen zu unterscheiden:

Netzwerkregel:
allow

Sicherheitsprofil:
block

Im Protokoll können dafür mehrere Einträge entstehen. Ein allow-Ereignis darf nicht isoliert als Nachweis einer erfolgreichen Verbindung bewertet werden.

Application-Awareness

Eine anwendungsbasierte Firewall kann eine Sitzung zunächst anhand des Ports behandeln und später die erkannte Anwendung berücksichtigen.

Zu prüfen sind:

  • erkannte Anwendung;
  • Zeitpunkt der Erkennung;
  • unbekannte oder unvollständige Anwendung;
  • abweichender Port;
  • verschlüsselter Datenverkehr;
  • SNI;
  • HTTP-Hostheader;
  • ALPN;
  • QUIC;
  • Portwechsel;
  • abhängige Anwendungen;
  • benötigte Grundanwendung;
  • Regel mit application-default;
  • TLS-Entschlüsselungsstatus.

Beispiel:

TCP-Port:
443

Erkannte Anwendung:
quic

Erwartete Anwendung:
ssl/web-browsing

Eine reine Portfreigabe sagt nicht aus, welche Anwendung tatsächlich transportiert wird.

Regelbindung prüfen

Eine definierte ACL oder Policy wirkt nur, wenn sie an der richtigen Stelle eingebunden ist.

Zu prüfen sind:

  • Schnittstelle;
  • Richtung;
  • Sicherheitszone;
  • Regelgruppe;
  • Policy-Paket;
  • virtueller Kontext;
  • Mandant;
  • Gerätegruppe;
  • Zielgerät;
  • aktive Konfiguration;
  • erfolgreicher Commit;
  • erfolgreicher Deploymentstatus;
  • Synchronisation im Cluster;
  • zentrale Vererbung.

Beispielbefund:

ACL:
WEB-IN

Konfiguriert:
ja

Gebunden an:
DMZ-Schnittstelle eingehend

Tatsächlicher Verkehr:
tritt an WAN-Schnittstelle ein

Ergebnis:
ACL WEB-IN verarbeitet diesen Datenfluss nicht

Aktive und gespeicherte Konfiguration unterscheiden

Je nach Produkt können unterschiedliche Konfigurationsstände existieren:

  • bearbeitete Konfiguration;
  • Kandidatenkonfiguration;
  • gespeicherte Startkonfiguration;
  • laufende Konfiguration;
  • zuletzt erfolgreich ausgerollte Richtlinie;
  • zentral vorgesehene Richtlinie;
  • lokale Gerätekonfiguration;
  • Konfiguration des aktiven Knotens;
  • Konfiguration des passiven Knotens.

Zu prüfen sind:

  • wurde die Änderung gespeichert?
  • wurde sie erfolgreich geprüft?
  • wurde sie committed?
  • wurde sie auf das richtige Gerät ausgerollt?
  • ist das Deployment abgeschlossen?
  • existieren Warnungen oder Fehler?
  • verwenden alle Clusterknoten dieselbe Version?
  • wurde eine lokale Änderung durch zentrale Verwaltung überschrieben?

Eine im Managementsystem sichtbare Regel beweist nicht, dass sie bereits auf der Datenebene aktiv ist.

Hochverfügbarkeit und Cluster

Bei einem Firewallcluster sind zusätzlich zu prüfen:

  • aktiver und passiver Knoten;
  • Clusterzustand;
  • Konfigurationssynchronisation;
  • Sitzungssynchronisation;
  • NAT-Synchronisation;
  • Routingzustand;
  • Linkstatus;
  • Split-Brain-Schutz;
  • Eigentümer der Sitzung;
  • Datenpfad des Hinverkehrs;
  • Datenpfad des Rückverkehrs;
  • Zustand nach Failover;
  • Zeitstempel der letzten Umschaltung.

Typischer Fehler:

Hinverkehr:
FW-A

Rückverkehr:
FW-B

Sitzungssynchronisation:
fehlerhaft

FW-B kennt die durch FW-A aufgebaute Sitzung möglicherweise nicht und verwirft den Rückverkehr als ungültig.

Asymmetrische Pfade und Connection Tracking werden in 9.6 Asymmetrische Pfade, Sessiontabellen und Connection Tracking weiter vertieft.

Cloud-Firewalls und Cloud-ACLs

Cloud-Plattformen können mehrere Filterebenen kombinieren:

  • Security Group an der Netzwerkschnittstelle;
  • Subnetz-ACL;
  • zentrale Cloud-Firewall;
  • Load Balancer;
  • Web Application Firewall;
  • Kubernetes Network Policy;
  • Plattformdienst-Firewall;
  • lokaler Hostfilter;
  • On-Premises-Firewall;
  • Routing- und Transitkomponente.

Diese Ebenen müssen einzeln geprüft werden.

AWS Security Groups und Network ACLs

Merkmal AWS Security Group AWS Network ACL
Zuordnung Netzwerkschnittstelle oder Ressource Subnetz
Zustand stateful stateless
Regeln Freigaberegeln Erlauben und Verweigern
Rückverkehr für verfolgte Verbindung automatisch berücksichtigt muss durch Gegenregel erlaubt werden
Reihenfolge keine klassische First-Match-Reihenfolge der Freigaberegeln nach Regelnummer
Diagnosefokus tatsächlich zugeordnete Gruppen tatsächlich zugeordnete Subnetz-ACL
Ephemeral Ports Rückverkehr durch Zustand ausdrücklich berücksichtigen

Bei einer AWS Network ACL muss beispielsweise für eine eingehend erlaubte TCP-Verbindung auch der ausgehende Rückverkehr zum dynamischen Clientport erlaubt sein.

Vereinfachtes Beispiel:

Inbound:
TCP von 192.0.2.0/24 zu Zielport 443 erlauben

Outbound:
TCP zu 192.0.2.0/24 und benötigtem dynamischem Clientportbereich erlauben

Der tatsächlich verwendete Portbereich hängt vom Clientbetriebssystem, der Anwendung und gegebenenfalls weiteren NAT-Komponenten ab.

Azure Network Security Groups

Azure Network Security Groups arbeiten zustandsbehaftet und verwenden Regeln mit Prioritätswerten.

Grundprinzip:

kleinere Prioritätszahl = höhere Priorität

Beispiel:

Priorität 100:
Deny TCP 192.0.2.66 -> 10.20.30.40:443

Priorität 200:
Allow TCP 192.0.2.0/24 -> 10.20.30.40:443

Zu prüfen sind:

  • NSG am Subnetz;
  • NSG an der Netzwerkschnittstelle;
  • effektive Sicherheitsregeln;
  • Priorität;
  • Standardregeln;
  • Service Tags;
  • Application Security Groups;
  • NAT-Bezug;
  • Azure Firewall;
  • User Defined Routes;
  • Load Balancer;
  • Network Watcher Flow Logs;
  • tatsächlich verwendete private Zieladresse.

Bei eingehendem Verkehr verarbeitet eine Azure NSG die Regeln nach der Übersetzung einer öffentlichen in eine private IP-Adresse. Bei ausgehendem Verkehr erfolgt die NSG-Verarbeitung vor der Übersetzung einer privaten in eine öffentliche Adresse.

Netzwerkregel und Anwendungsfirewall unterscheiden

Eine Netzwerkfirewall prüft typischerweise IP-Adressen, Ports, Protokolle, Sitzungen und gegebenenfalls Anwendungen.

Eine Web Application Firewall prüft dagegen HTTP- oder HTTPS-Anfragen auf Anwendungsebene.

Beispiel:

Netzwerkfirewall:
TCP 443 erlaubt

Web Application Firewall:
HTTP-Anfrage wegen Regelverletzung blockiert

Ein erfolgreicher TCP-Handshake bis zum Reverse Proxy beweist daher nicht, dass die Webanwendung die Anfrage akzeptiert.

Ausgangszustand erfassen

Vor Veränderungen sind folgende Informationen zu sichern:

Datum und Uhrzeit
Zeitzone
Clientname und Clientadresse
Servername und Serveradresse
Quellport
Zielport
Protokoll
Anwendung
exakte Fehlermeldung
betroffener Benutzer
Eingangs- und Ausgangszone
erwarteter Firewallpfad
aktiver Firewallknoten
Regelname und Regel-ID
NAT-Regel
Sitzungs-ID
Policy-Version
Logeinträge
Trefferzähler
Paketaufzeichnungen

Die Uhren von Client, Server, Firewall und zentralem Protokollsystem müssen ausreichend synchronisiert sein. Andernfalls können zusammengehörige Ereignisse falsch zugeordnet werden.

Fehlerumfang bestimmen

Zu klären ist:

  • betrifft die Störung nur einen Client?
  • betrifft sie ein gesamtes Quellnetz?
  • betrifft sie nur eine Zieladresse?
  • betrifft sie alle Ziele einer Zone?
  • betrifft sie nur einen Port?
  • betrifft sie TCP, UDP oder ICMP?
  • betrifft sie IPv4, IPv6 oder beide?
  • tritt sie nur über VPN auf?
  • tritt sie nur über einen Standort auf?
  • betrifft sie neue oder auch bestehende Sitzungen?
  • tritt sie erst seit einer Regeländerung auf?
  • betrifft sie nur einen Clusterknoten?
  • tritt sie nur zu bestimmten Uhrzeiten auf?
  • betrifft sie nur eine erkannte Anwendung?
  • ist sie von der Nutzlastgröße abhängig?

Ein präzise begrenzter Fehlerumfang verhindert unnötig weitreichende Regeländerungen.

Firewallpfad nachweisen

Der vorgesehene Firewallpfad darf nicht nur aus dem Netzplan abgeleitet werden.

Mögliche Nachweise:

  • Traceroute;
  • Routingtabellen;
  • Flow Logs;
  • NetFlow oder IPFIX;
  • Firewall-Sitzungstabelle;
  • Eingangs- und Ausgangsaufzeichnung;
  • Schnittstellenzähler;
  • MAC- und ARP-Tabellen;
  • Cloud Network Watcher;
  • zentrale SD-WAN- oder Transitprotokolle;
  • Logeintrag mit Eingangs- und Ausgangszone.

Zu beachten ist, dass Traceroute nicht jede Firewall sichtbar macht. Eine transparente Firewall oder ein Gerät, das TTL-Abläufe nicht beantwortet, kann im Traceroute fehlen.

Regelwerk zunächst nur lesend prüfen

Zu erfassen sind:

  • Name der aktiven Policy;
  • Regel-ID;
  • Regelname;
  • Position oder Priorität;
  • Quelle;
  • Ziel;
  • Zonen;
  • Protokoll;
  • Quellport;
  • Zielport;
  • Anwendung;
  • Aktion;
  • Sicherheitsprofile;
  • Zeitplan;
  • Protokollierung;
  • Trefferzähler;
  • letztes Trefferdatum;
  • Ersteller;
  • Änderungsreferenz;
  • Objektinhalte;
  • Standardaktion.

Ein Screenshot allein ist kein idealer technischer Nachweis. Wenn möglich, sollten zusätzlich exportierbare Text- oder Konfigurationsdaten mit Zeitstempel gesichert werden. Dabei sind Zugangsdaten, Schlüssel und andere schützenswerte Informationen zu entfernen.

Trefferzähler richtig auswerten

Ein Trefferzähler kann zeigen, dass Verkehr eine Regel erreicht hat. Er muss jedoch vorsichtig interpretiert werden.

Zu beachten sind:

  • einige Produkte zählen nur den ersten Paket- oder Sitzungsaufbau;
  • andere zählen alle passenden Pakete;
  • Hardware-Offloading kann separate Zähler verwenden;
  • Zähler können pro Clusterknoten geführt werden;
  • zentrale Ansicht kann verzögert sein;
  • ein breites Regelobjekt kann Verkehr vieler Systeme zählen;
  • alte Treffer beweisen keinen Treffer beim aktuellen Test;
  • Zähler können nach Neustart oder Deployment zurückgesetzt sein;
  • ein Zähleranstieg bei einer allow-Regel beweist keine erfolgreiche Anwendung;
  • ein Zählerstand von null kann auf falschen Pfad, falsche Regel oder falschen Kontext hinweisen.

Belastbarer Ablauf:

  1. aktuellen Zählerstand mit Uhrzeit dokumentieren;
  2. genau einen kontrollierten Test ausführen;
  3. Zähler erneut ablesen;
  4. Differenz bewerten;
  5. gleichzeitig Firewallprotokoll und Anwendungsergebnis prüfen.

Zähler dürfen erst nach der Beweissicherung und nur mit Freigabe zurückgesetzt werden.

Firewallprotokolle auswerten

Ein brauchbarer Protokolleintrag enthält möglichst:

  • Ereigniszeit;
  • Firewallname;
  • Clusterknoten;
  • virtuellen Kontext;
  • Eingangszone;
  • Ausgangszone;
  • Eingangs- und Ausgangsschnittstelle;
  • Quelladresse;
  • Quellport;
  • Zieladresse;
  • Zielport;
  • Protokoll;
  • NAT-Adressen und NAT-Ports;
  • Regelname;
  • Regel-ID;
  • Aktion;
  • erkannte Anwendung;
  • Sicherheitsprofil;
  • Sitzungs-ID;
  • Pakete und Bytes je Richtung;
  • Sitzungsendgrund;
  • Drop-Grund.

Nach exakt diesen Merkmalen sollte gefiltert werden:

source = 192.0.2.100
destination = 198.51.100.25
destination_port = 443
protocol = TCP
time = 2026-08-02 10:15:00 bis 10:16:00

Ein fehlender Logeintrag beweist nicht automatisch, dass die Firewall den Datenfluss nicht gesehen hat. Mögliche Gründe:

  • Protokollierung ist für die Regel deaktiviert;
  • nur Sitzungsende wird protokolliert;
  • Sitzung läuft noch;
  • Ereignisse werden verzögert übertragen;
  • falscher Clusterknoten wurde geprüft;
  • falscher Mandant wurde geprüft;
  • Protokolle werden gefiltert oder begrenzt;
  • Datenfluss verwendet einen anderen Pfad;
  • Paket wird vor der normalen Sicherheitsregel verworfen;
  • Hardware-Offload verwendet andere Diagnosezähler;
  • Rate Limiting unterdrückt Ereignisse.

Erlaubt-, Verworfen- und Sitzungsendgründe unterscheiden

Mögliche Aktionen und Endgründe:

Befund Mögliche Bedeutung
allow Netzwerkregel hat den Datenfluss zugelassen
deny Sicherheitsregel hat den Datenfluss verworfen
drop Paket wurde ohne aktive Ablehnungsantwort verworfen
reject Firewall sendet eine aktive Ablehnungsantwort
reset-client Firewall sendet TCP-RST zum Client
reset-server Firewall sendet TCP-RST zum Server
aged-out Sitzung ist durch Timeout abgelaufen
tcp-rst-from-client Client hat die Sitzung beendet
tcp-rst-from-server Server hat die Sitzung beendet
policy-deny Richtlinie hat den Aufbau blockiert
threat oder ips-drop Sicherheitsprofil hat blockiert
decrypt-error TLS-Entschlüsselung ist fehlgeschlagen
resources-unavailable Kapazitäts- oder Ressourcengrenze
invalid-state Paket passt nicht zum erwarteten Sitzungszustand
no-route keine verwendbare Route
nat-failure NAT-Verarbeitung ist fehlgeschlagen

Die genaue Benennung ist herstellerspezifisch.

Policy-Match- und Packet-Tracer-Werkzeuge

Viele Hersteller bieten Werkzeuge an, die einen hypothetischen Datenfluss gegen die aktuelle Konfiguration prüfen.

Benötigte Eingaben:

Eingangsschnittstelle
Quellzone
Quelladresse
Quellport
Zieladresse
Zielport
Protokoll
Benutzer oder Anwendung, sofern erforderlich

Solche Werkzeuge können unter anderem zeigen:

  • Routingentscheidung;
  • NAT-Regel;
  • Sicherheitsregel;
  • Ausgangsschnittstelle;
  • Zielzone;
  • zulassende oder verweigernde Phase;
  • implizite Standardaktion.

Ein Simulationsergebnis beweist nicht:

  • dass das reale Paket die Firewall erreicht;
  • dass die physische Schnittstelle funktioniert;
  • dass der Server erreichbar ist;
  • dass der Rückweg stimmt;
  • dass die Anwendung antwortet;
  • dass eine nachgelagerte Firewall erlaubt;
  • dass ein Sicherheitsprofil den realen Inhalt akzeptiert;
  • dass derselbe Clusterknoten den realen Datenfluss verarbeitet.

Die Simulation muss mit einem realen Test, Protokollen und gegebenenfalls Paketaufzeichnungen kombiniert werden.

Cisco IOS ACLs lesend prüfen

Beispielbefehle:

show ip access-lists

show ip access-lists <ACL-Name-oder-Nummer>

show running-config | section access-list

show running-config | include ip access-group

show ip interface

Zu prüfen sind:

  • Reihenfolge der Einträge;
  • permit oder deny;
  • Trefferzähler;
  • implizites Verbot;
  • Schnittstellenbindung;
  • Richtung in oder out;
  • Wildcard-Masken;
  • Protokoll;
  • Quell- und Zielport;
  • IPv4- oder IPv6-ACL.

Die genaue Syntax hängt von Plattform und Softwareversion ab.

Cisco Secure Firewall ASA lesend prüfen

ACLs und Bindungen:

show access-list

show access-group

Verbindungen und NAT:

show conn

show conn address 192.0.2.100

show xlate

Routing:

show route

Simulation eines TCP-Pakets:

packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed

Drop-Zähler:

show asp drop

show asp drop liefert interne Drop-Zähler und ist für gezielte Fehleranalysen vorgesehen. Die Ausgabe ist umfangreich und muss zeitlich mit einem kontrollierten Test korreliert werden.

Bei Cisco ASA verwenden normale Zugriffsregeln für NAT-Verkehr die reale Adresse des Ziels. Dieses Verhalten darf nicht ungeprüft auf andere Firewallprodukte übertragen werden.

Juniper SRX lesend prüfen

Beispielbefehle:

show security policies

show security policies hit-count

show security flow session

show security flow session source-prefix 192.0.2.100

show security flow session destination-prefix 198.51.100.25

show route 198.51.100.25

Für eine Richtlinienzuordnung kann abhängig von Junos-Version und Konfiguration show security match-policies verwendet werden. Die vollständige lokale Syntax ist mit der CLI-Hilfe zu prüfen.

Juniper-Sicherheitsrichtlinien werden innerhalb des zutreffenden Zonenkontexts in Reihenfolge ausgewertet. Die erste passende Richtlinie bestimmt die Aktion.

Palo Alto Networks lesend prüfen

Sitzungssuche:

show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443

Routingprüfung:

test routing fib-lookup virtual-router <Routername> ip 198.51.100.25

Policy-Match-Tests und genaue Filteroptionen sind versionsabhängig. Vor der Ausführung ist die lokale CLI-Hilfe zu verwenden:

test security-policy-match ?

show session all filter ?

Bei der Auswertung sind unter anderem zu prüfen:

  • Regelname;
  • Quell- und Zielzone;
  • Anwendung;
  • Dienst;
  • NAT-Regel;
  • Sicherheitsprofile;
  • Sitzungsendgrund;
  • Pakete und Bytes je Richtung.

Palo-Alto-Sicherheitsregeln werden innerhalb der Regelbasis von oben nach unten ausgewertet. Die erste passende Regel wird angewendet. Spezifische Regeln müssen daher vor allgemeineren Regeln stehen.

Linux als Netzwerkfirewall lesend prüfen

Wenn ein Linux-System als Router oder Firewall eingesetzt wird, können abhängig von der Konfiguration folgende Prüfungen relevant sein.

Aktives nftables-Regelwerk:

sudo nft list ruleset

Regelwerk mit Handles:

sudo nft -a list ruleset

Routing:

ip route show

ip -6 route show

Weiterleitungseinstellung:

sysctl net.ipv4.ip_forward

sysctl net.ipv6.conf.all.forwarding

Connection Tracking, sofern das Werkzeug vorhanden ist:

sudo conntrack -L

Gezielte Suche:

sudo conntrack -L \
  -s 192.0.2.100 \
  -d 198.51.100.25 \
  -p tcp

Zu beachten sind:

  • richtige Chain;
  • Hook;
  • Priorität;
  • Tabelle;
  • Familie ip, ip6 oder inet;
  • Eingangs- und Ausgangsschnittstelle;
  • Default Policy;
  • NAT-Chain;
  • Connection-Tracking-Zustand;
  • Paketzähler;
  • Weiterleitung im Kernel.

Das Löschen von Conntrack-Einträgen ist eine verändernde Maßnahme und darf nicht als erster Diagnoseschritt erfolgen.

Paketaufzeichnung an der Firewall

Eine Paketaufzeichnung ist sinnvoll, wenn nicht eindeutig ist:

  • ob das Paket die Firewall erreicht;
  • ob es die Firewall wieder verlässt;
  • ob die Antwort zurückkommt;
  • ob NAT wie vorgesehen angewendet wird;
  • ob ein Reset erzeugt wird;
  • ob Pakete wiederholt werden;
  • ob nur eine Richtung sichtbar ist;
  • ob Fragmentierung auftritt;
  • ob der Datenfluss einen anderen Ausgang verwendet.

Idealer Vergleich:

Aufzeichnung A:
Eingangsschnittstelle

Aufzeichnung B:
Ausgangsschnittstelle

Befundbeispiele:

Eingang Ausgang Einordnung
Paket nicht sichtbar Paket nicht sichtbar Pfad vor der Firewall prüfen
Paket sichtbar Paket nicht sichtbar Firewallverarbeitung, Regel, NAT oder Route prüfen
Paket mit übersetztem Ziel sichtbar Paket erreicht Server Firewall hat Hinverkehr weitergeleitet
Serverantwort am Ausgangsnetz sichtbar Antwort nicht zum Clientnetz Firewallzustand, NAT oder Rückroute prüfen
vollständiger Verkehr auf beiden Seiten Client meldet trotzdem Fehler Host, Anwendung, Proxy oder TLS prüfen

Bei Hardware-Offloading kann eine allgemeine Paketaufzeichnung möglicherweise nicht alle weitergeleiteten Pakete zeigen. Dann sind herstellerspezifische Capture-Funktionen, Dataplane-Diagnosen oder ein externer SPAN/TAP erforderlich.

Aufzeichnungen müssen:

  • zeitlich begrenzt;
  • auf Quelle und Ziel gefiltert;
  • vor unberechtigtem Zugriff geschützt;
  • nach der Auswertung kontrolliert gelöscht oder archiviert;
  • datenschutzrechtlich und organisatorisch freigegeben

werden.

Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Die allgemeine Freigaberegel mit Priorität 100 erlaubt das gesamte
Clientnetz und überschattet die nachfolgende Sperrregel für
192.0.2.66.

Erwarteter Befund:
Ein Policy-Match-Test für 192.0.2.66 -> 198.51.100.25:443 nennt
die allgemeine Freigaberegel. Der Trefferzähler der Sperrregel
ändert sich beim Test nicht.

Gegenbeweis:
Der reale Datenfluss trifft nachweislich die Sperrregel und wird
durch diese verworfen.

Testmethode:
Policy-Match, kontrollierter Verbindungsversuch, Regelzähler und
Firewallprotokoll zeitlich korrelieren.

Risiko:
Nur lesende Diagnose; keine Auswirkung auf Produktivverkehr.

Erfolgskriterium:
Tatsächlich angewendete Regel ist mit Regel-ID und Logeintrag
eindeutig nachgewiesen.

Weitere mögliche Hypothesen:

  • Datenverkehr durchläuft eine andere Firewall.
  • Falsche Route führt zur falschen Zielzone.
  • Firewallregel verwendet die öffentliche statt der intern ausgewerteten Adresse.
  • Eine vorgelagerte globale Regel blockiert vor der lokalen Regel.
  • Bestehende Sitzung verwendet noch den alten Richtlinienzustand.
  • Sicherheitsprofil blockiert nach einer erlaubenden Netzwerkregel.
  • Rückverkehr erreicht einen anderen Clusterknoten.
  • Eine zustandslose Cloud-ACL blockiert den dynamischen Rückport.
  • FQDN-Objekt enthält nicht die vom Client verwendete Zieladresse.
  • IPv4 ist erlaubt, IPv6 jedoch nicht.
  • Die Regel ist konfiguriert, aber nicht ausgerollt.

Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko Rückweg
Regelreihenfolge korrigieren Überschattung nachgewiesen andere Datenflüsse können anders behandelt werden vorherige Reihenfolge wiederherstellen
spezifische Freigabe ergänzen fehlende Freigabe bestätigt zusätzliche Angriffsfläche neue Regel deaktivieren oder entfernen
Adressobjekt korrigieren Objektinhalt nachweislich falsch alle Regeln mit diesem Objekt betroffen vorherigen Objektstand wiederherstellen
Dienstobjekt korrigieren Port oder Protokoll falsch weitere Anwendungen können betroffen sein vorherige Definition wiederherstellen
Zonenbezug korrigieren tatsächlicher Pfad nachgewiesen Segmentierungswirkung ändert sich vorherige Zonenregel wiederherstellen
NAT-Regel korrigieren Übersetzungsfehler bestätigt Erreichbarkeit und Rückweg ändern sich vorherige NAT-Regel aktivieren
Route korrigieren falsche Ausgangszone oder falscher Next Hop viele Ziele können betroffen sein vorherige Route wiederherstellen
Logging aktivieren fehlende Beweisdaten zusätzliche Last und Datenmenge Logging zurücknehmen
einzelne Sitzung beenden alte Sitzung beeinflusst Test eine produktive Verbindung wird unterbrochen Anwendung baut neue Sitzung auf
Timeout anpassen zeitabhängiger Sitzungsabbruch nachgewiesen höhere Sitzungsanzahl und Ressourcennutzung alten Timeoutwert wiederherstellen
Sicherheitsprofil korrigieren Fehlklassifizierung nachgewiesen Schutzwirkung kann sinken vorheriges Profil wiederherstellen
Cluster-Synchronisation reparieren Zustandsabweichung nachgewiesen Failover- und Sitzungsrisiko herstellerspezifischer Rückfallplan

Eine allgemeine Testfreigabe ist kein geeigneter Ersatz für eine präzise Ursachenanalyse.

Vollständiger Diagnoseablauf

  1. Exakte Fehlermeldung, Anwendung, Client, Benutzer und Uhrzeit dokumentieren.
  2. Quelladresse und tatsächlichen Quellport bestimmen.
  3. Zieladresse, Zielport und Protokoll bestimmen.
  4. IPv4 und IPv6 unterscheiden.
  5. Erwarteten Datenfluss und Sollzustand dokumentieren.
  6. Umfang der Störung bestimmen.
  7. Host-Firewalls als eigene Filterebenen berücksichtigen.
  8. Direkte Erreichbarkeit und Dienstzustand prüfen.
  9. Erwarteten Netzwerkpfad dokumentieren.
  10. Tatsächlichen Firewallpfad nachweisen.
  11. Aktiven Firewall- oder Clusterknoten bestimmen.
  12. Richtigen Mandanten und virtuellen Kontext bestimmen.
  13. Eingangs- und Ausgangsschnittstelle bestimmen.
  14. Quell- und Zielzone bestimmen.
  15. Route zur Zieladresse prüfen.
  16. Policy-Based Routing, VRF und Tunnel berücksichtigen.
  17. Originaladressen und Originalports dokumentieren.
  18. NAT-Adressen und NAT-Ports dokumentieren.
  19. Aktive NAT-Regel bestimmen.
  20. Aktive Sicherheitsrichtlinie bestimmen.
  21. Regelreihenfolge und Prioritäten prüfen.
  22. Globale, geerbte und lokale Regeln berücksichtigen.
  23. Implizite Standardaktion bestimmen.
  24. Adress-, Dienst- und FQDN-Objekte auflösen.
  25. Zeitpläne und Identitätskriterien prüfen.
  26. Anwendungs- und Sicherheitsprofile prüfen.
  27. Policy-Match- oder Packet-Tracer-Test durchführen.
  28. Ergebnis nicht mit realem Durchsatz gleichsetzen.
  29. Regelzähler mit Ausgangswert dokumentieren.
  30. Genau einen kontrollierten Verbindungstest ausführen.
  31. Zähleränderung und Protokolle auswerten.
  32. Sitzungstabelle prüfen.
  33. TCP-, UDP- oder ICMP-Zustand auswerten.
  34. Pakete und Bytes je Richtung vergleichen.
  35. Sitzungsendgrund auswerten.
  36. Bestehende und neue Sitzung unterscheiden.
  37. Bei Bedarf Eingangs- und Ausgangsaufzeichnung durchführen.
  38. Hin- und Rückverkehr vergleichen.
  39. Cluster- und Zustandssynchronisation prüfen.
  40. Weitere Cloud- oder Subnetz-ACLs prüfen.
  41. Hypothese, erwarteten Befund und Gegenbeweis formulieren.
  42. Genau eine kontrollierte Maßnahme vorbereiten.
  43. Risiko, Rückweg und Erfolgskriterium dokumentieren.
  44. Maßnahme freigeben und umsetzen.
  45. Neue Verbindung mit identischen Parametern testen.
  46. Regel, Sitzung, Pakete, Bytes und Anwendungsergebnis verifizieren.
  47. Repräsentative weitere Datenflüsse auf Nebenwirkungen prüfen.
  48. Temporäre Logging- und Testregeln zurücknehmen.
  49. Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
kein Firewalllog falscher Pfad, Logging deaktiviert oder früher Drop Route, Capture und Regelprotokollierung prüfen
deny durch erwartete Regel Freigabe fehlt oder Regelinhalt falsch Regelkriterien und Sollzustand vergleichen
deny durch andere Regel Überschattung oder falscher Kontext Reihenfolge und Priorität prüfen
implizites deny keine ausdrückliche Regel passt Zonen, Adressen, Protokoll und Ports prüfen
Allow-Regel hat Zähler null Verkehr trifft Regel nicht Pfad, Bindung, Kontext und Objekte prüfen
Allow-Regel zählt, Anwendung scheitert späterer Filter, Rückweg oder Anwendung Sitzungsende, Sicherheitsprofil und Capture
nur Hinpakete gezählt Rückweg oder Serverantwort fehlt Serverseite und Rückroute prüfen
Pakete in beide Richtungen, null Nutzdaten Handshake- oder Anwendungsproblem TCP-Flags, TLS und Anwendung prüfen
Sitzung aged-out keine Antwort oder Idle-Timeout Paketfluss und Timeoutdauer prüfen
Sitzung endet mit Server-RST Server oder Zwischenkomponente lehnt ab servernahe Aufzeichnung und Dienstprotokoll
Sitzung endet mit Client-RST Client oder Anwendung beendet Clientaufzeichnung und Anwendungsprotokoll
Policy-Test erlaubt, reales Paket fehlt Firewall wird nicht erreicht vorgelagertes Routing und Filter prüfen
Policy-Test erlaubt, reales Paket wird verworfen zusätzliche Prüfung oder Zustand Drop-Grund und Sicherheitsprofil
Zielzone unerwartet Route oder VRF falsch Routingentscheidung prüfen
NAT-Ziel unerwartet falsche oder frühere NAT-Regel NAT-Reihenfolge und Übersetzungstabelle
neue Verbindung scheitert, alte funktioniert neue Richtlinie oder NAT-Entscheidung alte und neue Sitzung vergleichen
alte Verbindung scheitert, neue funktioniert veralteter Sitzungszustand gezielt einzelne Sitzung untersuchen
nur UDP-Rückverkehr fehlt stateless ACL oder Timeout Gegenrichtung und UDP-Sitzung prüfen
nur große Pakete scheitern MTU, Fragmentierung oder ICMP-Block Paketgröße und ICMP-Fehler prüfen
nur IPv6 scheitert fehlende IPv6-Regel oder Route IPv6-Regelwerk und ip -6 route
nur ein Clusterknoten betroffen Konfigurations- oder Zustandsabweichung Knoten direkt vergleichen
AWS Security Group erlaubt, Verkehr scheitert NACL, Route, Hostfilter oder Dienst alle Filterebenen prüfen
AWS NACL erlaubt Hinweg, Rückweg fehlt zustandslose Rückregel fehlt dynamischen Rückportbereich prüfen
Azure NSG-Regel vorhanden, trifft nicht Priorität oder andere NSG effektive Regeln an NIC und Subnetz
allow, danach Threat-Drop Sicherheitsprofil blockiert Bedrohungs- oder IPS-Protokoll
FQDN-Regel trifft nicht andere DNS-Auflösung Firewall- und Clientauflösung vergleichen
nur bestimmte Uhrzeit betroffen Regelzeitplan oder automatisches Deployment Zeitplan und Änderungsprotokoll
nur nach Failover betroffen Sitzungs- oder NAT-Synchronisation HA-Status und neue Sitzung prüfen

Typische Diagnosefehler

  • Netzwerkfirewall und Host-Firewall verwechseln.
  • Nur den vorgesehenen und nicht den tatsächlichen Netzwerkpfad betrachten.
  • Von einer vorhandenen Regel auf eine wirksame Regel schließen.
  • Quellport und Zielport verwechseln.
  • Eingehend oder ausgehend ohne Bezug auf Schnittstelle oder Ressource angeben.
  • Sicherheitszonen nicht dokumentieren.
  • Regelreihenfolge ignorieren.
  • Implizite Verweigerung übersehen.
  • Globale oder geerbte Regeln nicht berücksichtigen.
  • Regel in falschem Mandanten oder Kontext prüfen.
  • Definierte, aber nicht gebundene ACL übersehen.
  • Bearbeitete und aktive Konfiguration verwechseln.
  • Fehlerhaftes Deployment nicht prüfen.
  • Adressobjekte nur nach Namen bewerten.
  • Verschachtelte Objektgruppen nicht auflösen.
  • Wildcard-Maske als Subnetzmaske lesen.
  • IPv4-Freigabe als IPv6-Freigabe interpretieren.
  • FQDN-Auflösung der Firewall nicht mit der Clientauflösung vergleichen.
  • Öffentliche und private NAT-Adresse verwechseln.
  • Herstellerabhängige NAT-Reihenfolge annehmen.
  • Falsche Route durch eine zusätzliche Firewallfreigabe verdecken.
  • Eine allow-Aktion als vollständigen Erfolgsnachweis bewerten.
  • Sicherheitsprofile und Anwendungserkennung ignorieren.
  • Policy-Simulation als Nachweis realer Weiterleitung verwenden.
  • Nur einen Clusterknoten prüfen.
  • Sitzungszähler ohne Zeitbezug auswerten.
  • Regelzähler vor der Beweissicherung zurücksetzen.
  • Alte und neue Sitzungen nicht unterscheiden.
  • Sitzungstabelle vollständig löschen.
  • UDP wie TCP diagnostizieren.
  • Bei zustandsloser ACL den Rückverkehr vergessen.
  • ICMP pauschal sperren.
  • Nur Echo-Anfragen als ICMP betrachten.
  • Pro Verbindungstest mehrere Variablen ändern.
  • Paketaufzeichnung ohne präzisen Filter starten.
  • Nur die Eingangsschnittstelle aufzeichnen.
  • Hardware-Offloading bei Captures ignorieren.
  • Firewall vorsorglich neu starten.
  • Allgemeine any any-Regel als Test erstellen.
  • Temporäre Freigaben oder Protokollierungen aktiv lassen.
  • Nur das Diagnosewerkzeug und nicht die ursprüngliche Anwendung testen.
  • Ursache und Präventionsmaßnahme nicht dokumentieren.

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

  • Client verwendet die erwartete Quelladresse;
  • Zieladresse entspricht dem Sollzustand;
  • Protokoll und Zielport sind korrekt;
  • der Datenfluss durchläuft die vorgesehene Firewall;
  • richtiger Clusterknoten und Kontext werden verwendet;
  • Eingangs- und Ausgangszone sind korrekt;
  • Routingentscheidung ist korrekt;
  • NAT verwendet die erwarteten Adressen und Ports;
  • die vorgesehene Sicherheitsregel trifft;
  • keine allgemeinere Regel überschattet sie;
  • Regelzähler steigt beim kontrollierten Test;
  • Firewallprotokoll enthält die erwartete Aktion;
  • keine nachgelagerte Sicherheitsprüfung blockiert;
  • Sitzung wird korrekt angelegt;
  • TCP-Handshake wird vollständig abgeschlossen;
  • UDP-Antwort wird der Sitzung zugeordnet;
  • benötigte ICMP-Fehlermeldungen werden transportiert;
  • Pakete und Bytes sind in beiden Richtungen plausibel;
  • Sitzungsendgrund ist erwartungsgemäß;
  • neue Verbindung funktioniert;
  • bestehende Verbindungen wurden nicht unbeabsichtigt beeinflusst;
  • IPv4 und IPv6 funktionieren, sofern erforderlich;
  • weitere repräsentative Quellen funktionieren;
  • weitere repräsentative Ziele funktionieren;
  • Hochverfügbarkeit und Synchronisation sind fehlerfrei;
  • Cloud-Sicherheitsgruppen und Subnetz-ACLs sind konsistent;
  • ursprüngliche Anwendung funktioniert;
  • temporäre Testregeln wurden entfernt;
  • temporäre Protokollierung wurde zurückgenommen;
  • Konfigurationsstand wurde gesichert;
  • Ursache, Änderung, Rückweg und Prävention wurden dokumentiert.

Eine erfolgreiche Policy-Simulation oder ein einzelner steigender Regelzähler ist keine ausreichende Gesamtverifikation.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Datum und Uhrzeit:
<Zeitpunkt mit Zeitzone>

Betroffene Anwendung:
<Anwendung oder Dienst>

Quelle:
<Hostname, IP-Adresse und Quellport>

Ziel:
<Hostname, IP-Adresse und Zielport>

Protokoll:
<TCP, UDP, ICMP oder anderes IP-Protokoll>

Erwarteter Pfad:
<Zonen, Router, Firewall und Zielnetz>

Tatsächlicher Pfad:
<nachgewiesener Pfad>

Firewall:
<Gerät, Cluster und aktiver Knoten>

Virtueller Kontext:
<Mandant, VSYS, VRF oder Security Context>

Eingang:
<Schnittstelle und Quellzone>

Ausgang:
<Schnittstelle und Zielzone>

Originaldatenfluss:
<Quell-IP:Port -> Ziel-IP:Port>

Übersetzter Datenfluss:
<NAT-Quell-IP:Port -> NAT-Ziel-IP:Port>

Routingentscheidung:
<Ausgangsschnittstelle und nächster Hop>

Erwartete Regel:
<Name und ID>

Tatsächlich passende Regel:
<Name, ID, Position und Aktion>

Sicherheitsprofile:
<IPS, URL, Malware, TLS oder andere Profile>

Sitzungs-ID:
<ID und Zustand>

Pakete und Bytes:
<je Richtung>

Sitzungsendgrund:
<Grund>

Protokollbefund:
<Logeintrag und Zeitstempel>

Paketaufzeichnung:
<Eingangs- und Ausgangsbefund>

Hypothese:
<vermutete Ursache>

Erwarteter Nachweis:
<messbarer Befund>

Gegenbeweis:
<Befund, der die Hypothese widerlegt>

Nachgewiesene Ursache:
<technischer Nachweis>

Durchgeführte Maßnahme:
<genau beschriebene Änderung>

Risiko:
<mögliche Nebenwirkung>

Rückweg:
<Rollback>

Verifikation:
<identischer Test und Anwendungstest>

Prävention:
<Monitoring, Bereinigung oder Prozessverbesserung>

Checkliste

  • exakte Fehlermeldung dokumentiert
  • Datum, Uhrzeit und Zeitzone erfasst
  • betroffenen Client erfasst
  • betroffene Anwendung erfasst
  • Quelladresse ermittelt
  • Quellport ermittelt
  • Zieladresse ermittelt
  • Zielport ermittelt
  • Protokoll bestimmt
  • IPv4 und IPv6 unterschieden
  • erwarteten Datenfluss dokumentiert
  • Fehlerumfang bestimmt
  • lokale Host-Firewalls berücksichtigt
  • tatsächlichen Netzwerkpfad nachgewiesen
  • tatsächlich durchlaufene Firewall bestimmt
  • aktiven Clusterknoten bestimmt
  • richtigen Mandanten oder Kontext bestimmt
  • Eingangsschnittstelle bestimmt
  • Ausgangsschnittstelle bestimmt
  • Quellzone bestimmt
  • Zielzone bestimmt
  • Routingentscheidung geprüft
  • VRF oder virtuellen Router geprüft
  • Policy-Based Routing berücksichtigt
  • Originaladressen dokumentiert
  • Originalports dokumentiert
  • NAT-Adressen dokumentiert
  • NAT-Ports dokumentiert
  • NAT-Regel bestimmt
  • aktive Sicherheitsrichtlinie bestimmt
  • Regel-ID dokumentiert
  • Regelposition oder Priorität dokumentiert
  • Regelreihenfolge geprüft
  • globale Regeln geprüft
  • geerbte Regeln geprüft
  • implizite Standardaktion geprüft
  • ACL-Bindung geprüft
  • aktive Konfigurationsversion geprüft
  • Deploymentstatus geprüft
  • Cluster-Synchronisation geprüft
  • Quellobjekt aufgelöst
  • Zielobjekt aufgelöst
  • Dienstobjekt aufgelöst
  • verschachtelte Gruppen geprüft
  • FQDN-Objekt geprüft
  • Firewall- und Client-DNS-Ergebnis verglichen
  • Zeitplan geprüft
  • Benutzer- oder Geräteidentität geprüft
  • erkannte Anwendung geprüft
  • Sicherheitsprofile geprüft
  • Policy-Match-Test durchgeführt
  • Simulation nicht als alleinigen Nachweis verwendet
  • Ausgangszähler dokumentiert
  • kontrollierten Test durchgeführt
  • Regelzähler erneut geprüft
  • Firewallprotokolle korreliert
  • erlaubende und blockierende Ereignisse unterschieden
  • Sitzungstabelle geprüft
  • Sitzungs-ID dokumentiert
  • TCP-Zustand geprüft
  • UDP-Pseudositzung berücksichtigt
  • ICMP-Typ und Code berücksichtigt
  • Pakete je Richtung geprüft
  • Bytes je Richtung geprüft
  • Sitzungsendgrund ausgewertet
  • bestehende und neue Sitzung unterschieden
  • Sitzungstimeouts geprüft
  • bei Bedarf Eingangscapture durchgeführt
  • bei Bedarf Ausgangscapture durchgeführt
  • Hin- und Rückverkehr verglichen
  • Hardware-Offloading berücksichtigt
  • weitere Netzwerk-ACLs geprüft
  • Cloud Security Groups geprüft
  • Cloud-Subnetz-ACLs geprüft
  • Hypothese formuliert
  • Gegenbeweis definiert
  • Risiko dokumentiert
  • Rückweg dokumentiert
  • nur eine kontrollierte Maßnahme durchgeführt
  • identischen Test wiederholt
  • ursprüngliche Anwendung verifiziert
  • repräsentative weitere Datenflüsse geprüft
  • temporäre Testregel entfernt
  • temporäre Protokollierung zurückgenommen
  • Ursache und Prävention dokumentiert

Schnellreferenz

Aufgabe Beispiel
Datenfluss dokumentieren 192.0.2.100:53124 -> 198.51.100.25:443/TCP
Cisco IOS ACLs anzeigen show ip access-lists
Cisco IOS ACL-Bindung prüfen show ip interface
ASA ACLs anzeigen show access-list
ASA ACL-Bindung anzeigen show access-group
ASA Sitzungen anzeigen show conn
ASA Sitzung nach Adresse filtern show conn address 192.0.2.100
ASA NAT-Zustand anzeigen show xlate
ASA Route anzeigen show route
ASA Datenfluss simulieren packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed
ASA Drop-Zähler anzeigen show asp drop
Juniper Policies anzeigen show security policies
Juniper Policy-Treffer anzeigen show security policies hit-count
Juniper Sitzungen anzeigen show security flow session
Juniper Route prüfen show route 198.51.100.25
Palo Alto Sitzung suchen show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443
Palo Alto Route prüfen test routing fib-lookup virtual-router <Routername> ip 198.51.100.25
Linux nftables anzeigen sudo nft list ruleset
Linux nftables mit Handles sudo nft -a list ruleset
Linux Routing anzeigen ip route show
Linux IPv6-Routing anzeigen ip -6 route show
Linux Conntrack anzeigen sudo conntrack -L

Befehle, die nicht als erste Diagnosemaßnahme verwendet werden dürfen:

clear conn
clear xlate
clear access-list counters
clear security flow session
clear session all
conntrack -F
nft flush ruleset
iptables -F
policy commit ohne geprüften Änderungsplan
Firewall deaktivieren
Cluster-Failover erzwingen
Firewalldienst neu starten
allgemeine any-any-Freigabe erstellen
Sicherheitsprofile global deaktivieren

Quellen

Grundlagen und Standards

Cisco

Juniper Networks

Palo Alto Networks

Amazon Web Services

Microsoft Azure

Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet.

Back to top