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:

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:

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:

Nicht als erste Diagnosemaßnahme geeignet sind:

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

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:

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:

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:

Beispiel für eine sinnvolle Reihenfolge

Anforderung:

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:

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:

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:

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:

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:

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:

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:

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:

Zu prüfen sind:

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:

Typische Symptome eines Timeoutproblems:

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:

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:

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:

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

Zonen und virtuelle Kontexte

Viele Firewalls besitzen:

Zu prüfen sind:

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:

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:

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:

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:

Zu prüfen sind:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

Ein Simulationsergebnis beweist nicht:

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:

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:

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:

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:

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:

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:

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

Verifikation

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

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

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.

Revision #1
Created 2 August 2026 20:39:51 by Admin
Updated 2 August 2026 20:40:30 by Admin