Sophos Firewall verworfene Pakete analysieren

Wenn die Sophos Firewall Pakete verwirft, ist das nicht automatisch ein Fehler. Oft ist es genau die gewünschte Sicherheitsentscheidung: eine Regel passt nicht, eine Policy blockiert, ein Paket gehört zu keiner bekannten Verbindung oder ein Modul wie Webfilter, IPS oder Application Control greift.

Schwierig wird es, wenn ein Dienst nicht funktioniert und unklar ist, ob die Firewall blockiert, ob der Traffic gar nicht ankommt oder ob Rücktraffic über einen anderen Weg läuft. Dann braucht man eine saubere Reihenfolge: zuerst Log Viewer, dann Packet Capture, danach bei Bedarf Service-Logs oder CLI.

Für allgemeines Regel-Matching passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture. Dieser Artikel konzentriert sich auf Drops und verworfene Pakete.

Welcher Troubleshooting-Artikel passt?

Nicht jedes Verbindungsproblem ist ein Drop-Problem. Je nach Beobachtung ist ein anderer Einstieg schneller:

• Drop, Invalid traffic, Violation oder Firewall ID 0 sichtbar: Dieser Artikel ist der richtige Einstieg.
• Erwartete Firewall-Regel wird nicht getroffen: Sophos Firewall-Regel greift nicht: Ursachen prüfen.
• Regel soll nach einer Änderung validiert werden: Sophos Firewall Regel testen mit Log Viewer und Packet Capture.
• Pakete sollen im WebAdmin mit engem Filter geprüft werden: Sophos Firewall Packet Capture im WebAdmin verwenden.
• WebAdmin zeigt zu wenig und Logdateien werden benötigt: Sophos Firewall Troubleshooting: Services und Logs.
• Logs sollen länger aufbewahrt oder zentral korreliert werden: Sophos Firewall Syslog an SIEM senden.
• WebAdmin, SSH, DNS, VPN Portal oder SNMP zur Firewall selbst ist betroffen: Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.
• IPsec-Tunnel steht, aber Traffic fliesst nicht korrekt: Sophos Firewall IPsec VPN Troubleshooting.
• Grosse Übertragungen hängen oder einzelne Anwendungen brechen ab: Sophos Firewall MTU und MSS bei VPN-Problemen prüfen.

Diese Auswahl spart Zeit, weil man nicht jedes Problem als Firewall-Regelfehler behandelt. Zuerst muss klar sein, ob die Firewall den Traffic sieht, welche Regel oder welches Modul entscheidet und ob der Rückweg überhaupt über dieselbe Strecke läuft.

Drop ist nicht gleich Drop

Für die Analyse sollte man zuerst unterscheiden, welche Art von Drop vorliegt. Sonst wird schnell an der falschen Stelle gesucht.

• Gewollter Drop: Die Firewall blockiert gemäss Regel, Web Policy, IPS oder Threat Feed. Dann muss man prüfen, ob die Policy fachlich korrekt ist.
• Unerwarteter Drop: Legitimer Traffic wird von einer Regel oder einem Modul verworfen. Rule ID, NAT ID, Modul und Reason im Log Viewer oder Packet Capture prüfen.
• Kein Firewall-Drop: Der Traffic erreicht die Firewall gar nicht oder die Antwort nimmt einen anderen Weg. Client, VLAN, Switch, Gateway, Route, SD-WAN oder Rückweg prüfen.

Diese Einordnung verhindert unnötige Ausnahmen. Wenn der Drop gewollt ist, braucht es keine technische Reparatur, sondern eine Policy-Entscheidung. Wenn der Traffic die Firewall gar nicht erreicht, hilft keine neue Firewall-Regel. Wenn ein Security-Modul blockiert, sollte nicht blind eine breite Firewall-Regel erstellt werden.

Erste Einordnung

Vor der Analyse sollte man den Fehler möglichst konkret eingrenzen.

Wichtige Fragen:

• Welche Source-IP und Destination-IP sind betroffen?
• Welcher Port und welches Protokoll werden genutzt?
• Geht es um Client-Internet, Site-to-Site-VPN, Remote Access, DNAT, WAF oder internen Traffic?
• Ist der Fehler dauerhaft oder sporadisch?
• Betrifft es nur eine Anwendung, nur einen Benutzer oder ein ganzes Netz?
• Wurde kurz vorher eine Firewall-Regel, NAT-Regel, Route, SD-WAN-Regel, TLS Inspection oder Web Policy geändert?

Ohne diese Angaben sucht man im Log Viewer oft zu breit. Besser ist ein reproduzierbarer Test mit Uhrzeit, IP-Adressen und erwarteter Richtung.

Log Viewer richtig verwenden

Der Log Viewer ist der erste Startpunkt. Er zeigt Event Logs und kann nach Modul, Zeit, Feld und Freitext gefiltert werden.

Der Log Viewer öffnet sich oben rechts in der WebAdmin-Oberfläche. Für Drops sind je nach Fall diese Module wichtig:

• Firewall: Regel-Matching, erlaubte und verworfene Verbindungen.
• Web: Web Policy, Kategorie, URL-Gruppe und Malware Scan.
• SSL/TLS inspection: Decryption, TLS-Fehler und Ausnahmen.
• Application filter: Application-Control-Treffer.
• IPS: Intrusion Prevention und DPI-Entscheidungen.
• Active threat response: Threat Feeds, NDR Essentials oder andere ATR-Treffer.
• Web server protection: WAF, Reverse Proxy und veröffentlichte Webdienste.
• VPN: IPsec, SSL VPN und Remote-Access-Ereignisse.

Firewall-Regeln loggen Sessions typischerweise, wenn die Firewall ein Destroy-Event erhält und die Verbindung schliesst. Wenn eine Verbindung ohne dieses Event endet, erscheint sie nicht immer so, wie man es erwartet. Bei SSL/TLS-Verbindungen wird die Verbindung nach dem Handshake und beim Schliessen geloggt.

Wichtig ist auch die Log-Konfiguration. Wenn ein Logtyp unter System services > Log settings nicht aktiviert ist, sieht man ihn lokal, in Sophos Central oder im Syslog nicht zuverlässig. Für längerfristige Auswertung passt Sophos Firewall Syslog an SIEM senden oder Central Firewall Reporting aktivieren.

Invalid Traffic Events einordnen

Invalid traffic ist ein wichtiger Befund, aber keine fertige Ursachenanalyse. Die Firewall meldet damit Traffic, der nicht sauber zu einer gültigen Verbindung oder Policy-Entscheidung passt. Typisch sind Pakete ausserhalb eines erwarteten Session-Zustands, asymmetrische Wege, abgelaufene Sessions, unerwartete TCP-Flags oder Rücktraffic, der nicht über denselben Pfad läuft.

Bei solchen Ereignissen sollte man nicht zuerst eine Allow-Regel bauen. Besser ist dieser Ablauf:

1. Source, Destination, Port und Uhrzeit aus dem Event übernehmen.
2. Im Log Viewer prüfen, ob eine Firewall Rule ID, NAT Rule ID oder ein Modul sichtbar ist.
3. Mit Packet Capture testen, ob beide Richtungen durch dieselbe Firewall laufen.
4. Routing, SD-WAN, VPN-Pfade, HA-Rolle und Rückroute prüfen.
5. Erst danach entscheiden, ob eine Regel, NAT-Logik, Route oder ein Security-Profil angepasst werden muss.

Invalid traffic ist besonders wertvoll als Hinweis auf Zustands- oder Rückwegprobleme. Wenn nur die Allow-Regel erweitert wird, bleibt die eigentliche Ursache oft bestehen.

Packet Capture richtig verwenden

Der Menüpfad lautet:

Diagnostics > Packet capture

Packet Capture zeigt, ob Pakete an einem Interface ankommen, weitergeleitet, von der Firewall selbst verarbeitet oder verworfen werden. Das ist besonders wichtig, wenn im Log Viewer nichts Eindeutiges erscheint.

Grundablauf:

1. Testfall eingrenzen: Source-IP, Destination-IP, Port und Protokoll notieren.
2. Diagnostics > Packet capture öffnen.
3. Capture-Filter möglichst eng setzen.
4. Packet Capture aktivieren.
5. Problem reproduzieren.
6. Capture stoppen.
7. Einträge nach Source, Destination, Rule ID, NAT ID, Status und Reason prüfen.

Packet Capture zeigt unter anderem Rule ID, NAT ID, Status, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID und Username. Diese Felder helfen, wenn nicht nur eine Firewall-Regel, sondern auch Webfilter, IPS, Application Control oder NAT beteiligt sind.

Für die Bedienung des Werkzeugs ist Packet Capture im WebAdmin verwenden die ausführlichere Anleitung.

Packet-Capture-Status verstehen

Die Statuswerte sind für die Analyse entscheidend. Sophos Firewall bietet im Display-Filter sechs Statuswerte an: Allowed, Violation, Consumed, Generated, Incoming und Forwarded.

• Incoming: Das Paket kommt auf einem WAN- oder LAN-Interface an. Die Quelle erreicht die Firewall.
• Allowed: Das Paket wurde von der zuständigen Firewall-Regel oder Policy erlaubt. Dieser Status überschneidet sich in der Praxis oft mit Forwarded; wenn ein Paket als Allowed, aber nicht als Forwarded erscheint, lohnt sich ein Blick auf Routing, Rückweg oder ein nachgelagertes Security-Modul.
• Forwarded: Das Paket wird an ein Interface weitergeleitet. Die Firewall lässt das Paket grundsätzlich passieren.
• Consumed: Das Paket ist für die Firewall selbst bestimmt. Dann sind Device Access, VPN Portal, DNS, DHCP oder ein anderer lokaler Dienst relevant.
• Generated: Das Paket wird von der Firewall erzeugt. Es handelt sich um Antwort- oder Systemtraffic der Firewall.
• Violation: Das Paket wird wegen einer Policy-Verletzung verworfen. Regel, Modul oder Sicherheitsfunktion blockiert.

Ein einzelnes Incoming ohne passendes Forwarded kann bedeuten, dass die Firewall das Paket verwirft, selbst verarbeitet oder dass der Filter nicht den gesamten Fluss zeigt. Deshalb sollte man immer beide Richtungen betrachten.

Nach dem ersten Status sollte nicht sofort eine Ausnahme erstellt werden. Besser ist, den nächsten Test aus dem Status abzuleiten:

• Nur Incoming sichtbar: Filter prüfen, Gegenrichtung erfassen, Rule ID suchen und Firewall ID 0 ausschliessen.
• Incoming und Forwarded, aber keine Antwort: Rückroute, Zielsystem, lokale Server-Firewall, NAT und asymmetrisches Routing prüfen.
• Consumed sichtbar: Device Access, Local service ACL und betroffenen lokalen Firewall-Dienst prüfen.
• Generated sichtbar: Prüfen, ob die Firewall selbst antwortet oder Systemtraffic erzeugt.
• Violation sichtbar: Reason, Rule ID, NAT ID und betroffenes Modul im Log Viewer abgleichen.

Damit bleibt die Analyse reproduzierbar: Der Status entscheidet, welches Werkzeug als nächstes sinnvoll ist. Bei Violation ist der Log Viewer wichtig, bei fehlender Antwort eher Rückweg und Packet Capture, bei Consumed Device Access statt Firewall-Regel.

Schnelle Symptom-Triage

In der Praxis spart eine kurze Symptom-Triage viel Zeit, bevor man tiefer in Logs oder Shell geht:

• Log Viewer zeigt Invalid traffic: Fokus auf Session-Zustand, Rückweg und asymmetrisches Routing. Beide Richtungen mit Packet Capture prüfen.
• Packet Capture zeigt nur Incoming: Fokus auf Drop, lokalen Dienst, Default-Regel oder unvollständigen Filter. Filter erweitern, Policy Test ausführen und Firewall ID 0 prüfen.
• Packet Capture zeigt Forwarded, aber keine Antwort: Fokus auf Zielsystem, Rückroute, NAT oder externe Firewall. Antwortpakete und Rückweg prüfen.
• Packet Capture zeigt Consumed: Fokus auf Traffic zur Firewall selbst. Device Access und Local service ACL prüfen.
• Packet Capture zeigt Violation: Fokus auf Regel, Security-Modul oder Policy-Verletzung. Reason, Rule ID, NAT ID und Modul-Log vergleichen.
• Log Viewer und Packet Capture zeigen gar nichts: Der Traffic erreicht die Firewall wahrscheinlich nicht. Client, VLAN, Switch, Gateway oder falsches Testziel prüfen.

Firewall ID 0 und explizite Drop-Regel

Wenn kein explizites Firewall-Regelwerk matched, verwirft die Sophos Firewall den Traffic über die eingebaute Schlussregel mit Firewall ID 0 beziehungsweise Policy ID 0. Diese Regel steht immer am Ende der Firewall-Regeln. Wichtig für Troubleshooting und SIEM: Die eingebaute Drop-all-Regel loggt Traffic nicht selbst. Wer alle verworfenen Verbindungen nachvollziehbar sehen möchte, braucht deshalb eine eigene explizite Drop-Regel mit aktivem Logging.

Wenn Drops durch die Default-Regel nicht sichtbar werden, ist die Policy-Entscheidung nicht automatisch falsch. Im Packet Capture sieht man dann unter Umständen nur Incoming, aber keinen passenden Violation Firewall-Eintrag. Das Problem ist dann die Nachvollziehbarkeit im Troubleshooting, nicht zwingend die eigentliche Drop-Entscheidung.

Wenn ein Testfall zu keiner Regel passt und trotzdem kein Drop sichtbar wird, sollte man deshalb zusätzlich prüfen:

1. Policy Test verwenden und kontrollieren, ob der Test auf Firewall ID 0 beziehungsweise die Default-Regel fällt.
2. Regelreihenfolge prüfen und sicherstellen, dass keine andere Regel weiter oben unerwartet matched.
3. Am Ende der Regelbasis eine explizite Drop-Regel erstellen, wenn Drops geloggt oder an Central Reporting beziehungsweise Syslog weitergegeben werden sollen.
4. Den Test erneut durchführen und prüfen, ob der Drop nun mit der expliziten Regel-ID sichtbar ist.
5. Die explizite Drop-Regel in Change-Dokumentation und Regelreview aufnehmen, damit sie nicht später als normale Allow-/Deny-Regel missverstanden wird.

Beim Erstellen der Schlussregel sollten die Zonen bewusst gewählt werden. Sophos empfiehlt, einzelne Source- und Destination-Zonen zu verwenden und nicht pauschal Any als Zone zu setzen, damit interne Dienste nicht unnötig beeinflusst werden. Für eine revisionssichere Umgebung ist die explizite Schlussregel hilfreich. Eine saubere Regelstruktur ersetzt sie aber nicht. Wenn sehr viel legitimer Traffic auf der Schlussregel landet, fehlt weiter oben wahrscheinlich eine präzisere erlaubende Regel oder ein Netz wird falsch eingeordnet.

Wichtige Felder im Packet Capture lesen

Bei Drops ist nicht nur der Status wichtig. Die Zusatzfelder zeigen, welcher Teil der Firewall den Traffic verarbeitet hat.

• Rule ID: Gematchte Firewall-Regel. Prüfen, ob sie mit der erwarteten Regel übereinstimmt.
• NAT ID: Gematchte NAT-Regel. Prüfen, ob NAT erwartet war, fehlt oder eine falsche NAT-Regel greift.
• Reason: Begründung für Drop oder Violation. Nicht isoliert lesen, sondern mit Status und Modul vergleichen.
• Web filter ID: Web-Policy-Entscheidung. Kategorie, URL-Gruppe und Benutzerkontext prüfen.
• Application ID: Erkannte Anwendung. Application Control kann anders entscheiden, als der Port vermuten lässt.
• IPS policy ID: Angewendete IPS Policy. Signatur, Regelkontext und False-Positive-Risiko prüfen.
• Username: Erkannter Benutzer. User Matching nur bewerten, wenn der Benutzer wirklich sichtbar ist.

Wenn Rule ID oder NAT ID unerwartet sind, sollte man nicht sofort eine Ausnahme erstellen. Zuerst muss klar sein, ob der Testfall richtig definiert war, ob eine allgemeinere Regel weiter oben matched oder ob NAT die Sicht auf Source und Destination verändert.

Reason als Wegweiser nutzen

Der Reason-Wert ist kein vollständiger Root-Cause-Bericht, aber ein guter Wegweiser zum nächsten Modul. Firewall spricht eher für Regelbasis, Default-Regel oder Zonenlogik. LOCAL_ACL passt zu Device Access und Local service ACL. INVALID_TRAFFIC deutet eher auf Session-Zustand, Rückweg oder asymmetrisches Routing. APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION oder VIRTUAL_HOST zeigen, dass man nicht nur die Firewall-Regel prüfen sollte.

Hilfreich ist deshalb ein kurzer Dreisprung: Erst Status lesen, dann Reason einordnen, danach das passende Modul im Log Viewer öffnen. So wird aus einem einzelnen Violation-Eintrag ein nachvollziehbarer Prüfpfad statt eine Einladung zu einer breiten Ausnahme.

Consumed und lokale Firewall-Dienste

Consumed ist kein normaler Drop. Der Status bedeutet, dass das Paket für die Firewall selbst bestimmt ist. Typische Ziele sind WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN oder SNMP.

In solchen Fällen ist oft nicht die normale Firewall-Regel entscheidend, sondern Device Access und Local service ACL. Wenn zum Beispiel WebAdmin, SSH, VPN Portal oder SNMP nicht erreichbar sind, sollte man nicht nur unter Rules and policies > Firewall rules suchen. Der richtige Startpunkt ist meist Administration > Device access.

Für die Härtung und Fehlersuche bei lokalen Firewall-Diensten passt Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.

Häufige Drop-Ursachen

Keine passende Firewall-Regel

Die häufigste Ursache ist eine Regel, die nicht matched. Gründe können sein:

• falsche Source zone
• falsches Source network
• falsche Destination zone
• Destination-IP bei DNAT falsch interpretiert
• fehlender Service oder falsches Protokoll
• Benutzer ist nicht authentifiziert
• Schedule passt nicht
• eine spezifischere Regel steht unterhalb einer allgemeineren Regel

Für die Regelstruktur hilft Sophos Firewall-Regeln verstehen und richtig konfigurieren. Wenn DNAT beteiligt ist, sollte zusätzlich Server per DNAT auf Sophos Firewall veröffentlichen geprüft werden.

NAT oder Rückweg passt nicht

Manchmal erlaubt die Firewall den Hinweg, aber die Antwort kommt anders zurück oder wird falsch übersetzt.

Typische Punkte:

• SNAT oder MASQ fehlt.
• DNAT zeigt auf den falschen internen Host.
• Eine verlinkte NAT-Regel wurde deaktiviert.
• Rückroute fehlt.
• SD-WAN oder statisches Routing schickt Antworttraffic über einen anderen Pfad.
• Bei VPN-Traffic fehlt eine passende IPsec-Route oder Rückroute.

Asymmetrisches Routing erzeugt oft schwer verständliche Fehler, weil die Firewall den Verbindungszustand nicht sauber zuordnen kann. Dann erscheinen Pakete unter Umständen als nicht zur Verbindung gehörend.

Paket gehört zu keiner bekannten Verbindung

Meldungen wie Could not associate packet to any connection oder ähnliche Conntrack-Hinweise bedeuten häufig, dass die Firewall kein passendes Verbindungskontextobjekt findet.

Mögliche Ursachen:

• Rücktraffic nimmt einen anderen Weg.
• Verbindung wurde auf einem anderen HA-Knoten aufgebaut.
• Session ist bereits abgelaufen.
• TCP-Flags passen nicht zur erwarteten Verbindung.
• Ein Gerät sendet Antworten ohne vorherige Anfrage.
• Stateful Inspection sieht nur einen Teil des Datenflusses.

Hier ist Packet Capture wichtiger als ein einzelner Logeintrag. Man muss sehen, ob beide Richtungen durch dieselbe Firewall und dieselbe Zone laufen.

Webfilter, TLS Inspection, Application Control oder IPS blockiert

Nicht jeder Drop kommt aus der Firewall-Regel selbst. Häufig wird Traffic erlaubt, aber danach durch ein Security-Modul blockiert.

Typische Beispiele:

• Web Policy blockiert eine Kategorie oder URL-Gruppe.
• TLS Inspection bricht wegen Zertifikat, SNI, Cipher oder Exception ab.
• Application Control erkennt eine unerwünschte Anwendung.
• IPS blockiert ein Muster.
• Active Threat Response trifft auf einen IoC.
• Zero-Day Protection hält einen Download zurück oder blockiert ihn.

Bei IPS-Treffern sollte man Signatur, Policy und Regelkontext prüfen, bevor man eine breite Ausnahme setzt. Der passende Ablauf steht in Sophos Firewall IPS einrichten und sicher testen.

Bei Web- und TLS-Fällen sollte man auch QUIC prüfen. Wenn Browser über UDP 443 ausweichen, passen Webfilter- und TLS-Erwartungen nicht immer. Mehr dazu: Sophos Firewall QUIC und HTTP/3 richtig blockieren.

MTU, MSS oder Fragmentierung

Bei VPN, PPPoE, SD-WAN, Mobilfunk oder verschachtelten Tunneln kann ein Paket zu gross für den Pfad sein. Dann sieht man nicht immer einen klaren Firewall-Drop, sondern eher Verbindungsabbrüche, langsame Anwendungen oder einzelne Dienste, die hängen bleiben.

Für solche Fälle passt Sophos Firewall MTU und MSS bei VPN-Problemen prüfen.

Strukturierter Ablauf

Für die Praxis funktioniert diese Reihenfolge gut:

1. Testfall notieren: Source, Destination, Port, Protokoll, Uhrzeit.
2. Log Viewer prüfen: Firewall-Modul und passende Security-Module filtern.
3. Rule ID und NAT ID suchen: Prüfen, welche Regel tatsächlich getroffen wurde.
4. Packet Capture starten: Engen Filter setzen und Test reproduzieren.
5. Status prüfen: Incoming, Forwarded, Consumed, Generated oder Violation auswerten.
6. Rückrichtung prüfen: Kommt die Antwort zurück und über denselben Pfad?
7. Security-Module prüfen: Web, TLS, Application Control, IPS, ATR, WAF.
8. Service-Logs prüfen: Bei Dienstproblemen passende Logdatei unter /log prüfen.
9. Zentrale Logs prüfen: Central Reporting oder SIEM einbeziehen, wenn lokale Logs nicht reichen.

Die passenden Dienst- und Logdateien sind in Sophos Firewall Troubleshooting: Services und Logs zusammengefasst.

Wenn im Log Viewer nichts erscheint

Kein Logeintrag bedeutet nicht automatisch, dass die Firewall nicht beteiligt ist.

Mögliche Ursachen:

• Logging ist in der Firewall-Regel nicht aktiviert.
• Der relevante Logtyp ist unter System services > Log settings nicht aktiv.
• Die Verbindung wurde nicht sauber beendet und deshalb nicht geloggt.
• Der Traffic erreicht die Firewall gar nicht.
• Der Traffic wird von einem lokalen Dienst verarbeitet.
• Der Filter im Log Viewer ist zu eng.
• Der Logspeicher ist begrenzt oder alte Einträge wurden bereits überschrieben.

In solchen Fällen zuerst Packet Capture verwenden. Wenn Packet Capture ebenfalls keinen Eingang zeigt, liegt der Fokus eher auf Client, Switch, VLAN, Routing vor der Firewall oder falschem Testziel.

Wann tcpdump oder Logarchive nötig sind

Das WebAdmin Packet Capture ist gut für schnelle Analysen. Für längere Mitschnitte, PCAP-Dateien, sehr genaue Filter oder Supportfälle ist tcpdump über SSH oft besser geeignet. Das gilt besonders, wenn ein Problem nur sporadisch auftritt oder wenn der Mitschnitt später in Wireshark oder durch Sophos Support ausgewertet werden soll.

Für solche Fälle sollte man vor dem Mitschnitt klären:

• Welche Source-IP, Destination-IP und Ports müssen in den Filter?
• Wie lange darf der Mitschnitt laufen?
• Wo wird die PCAP-Datei abgelegt?
• Wer darf die Datei sehen?
• Wann wird die Datei nach der Analyse wieder gelöscht?

Der praktische Ablauf steht in Sophos Firewall tcpdump: Pakete per CLI mitschneiden. Wenn neben Paketen auch Dienstlogs benötigt werden, hilft Sophos Firewall Logs für Support und Analyse sichern.

Ausnahmen nur gezielt setzen

Bei Drops ist die Versuchung gross, schnell eine Ausnahme zu erstellen. Das kann kurzfristig helfen, verschlechtert aber oft die Sicherheit oder versteckt die Ursache.

Ausnahmen sollten nur gesetzt werden, wenn klar ist:

• welches Modul blockiert
• welcher Host, welche Domain oder welche Anwendung betroffen ist
• warum der Traffic legitim ist
• wie eng die Ausnahme sein kann
• wann die Ausnahme überprüft oder entfernt wird

Breite Ausnahmen für ganze Netze, Any-Regeln oder globale TLS-Ausnahmen sollten vermieden werden. Besser ist eine kleine, dokumentierte Ausnahme mit Review-Termin.

Befund dokumentieren

Ein guter Drop-Befund muss so dokumentiert sein, dass eine andere Person den Test nachvollziehen kann. Das ist wichtig für interne Reviews, Change-Dokumentation und Supportfälle.

Mindestens festhalten:

• Datum, Uhrzeit und Zeitzone des Tests.
• Source-IP, Destination-IP, Port, Protokoll und Benutzer.
• Erwartete Firewall-Regel und tatsächlich sichtbare Rule ID.
• Erwartete NAT-Regel und tatsächlich sichtbare NAT ID.
• Packet-Capture-Status: Allowed, Incoming, Forwarded, Consumed, Generated oder Violation.
• Relevante Reason- oder Modulmeldung.
• Getroffene Änderung oder bewusst keine Änderung.
• Falls eine Ausnahme gesetzt wurde: Owner, Zweck, Gültigkeit und Review-Termin.

Diese Dokumentation verhindert, dass aus einem kurzfristigen Troubleshooting-Schritt eine dauerhafte, unklare Sicherheitslücke wird.

Checkliste

• Source-IP, Destination-IP, Port und Protokoll bekannt.
• Uhrzeit des Tests dokumentiert.
• Log Viewer mit richtigem Modul und Zeitfilter geprüft.
• Rule ID und NAT ID ausgewertet.
• Bei fehlendem Drop-Eintrag geprüft, ob Firewall ID 0 oder die Default-Regel betroffen ist.
• Firewall-Regel und Regelreihenfolge geprüft.
• NAT-Regel und Rückroute geprüft.
• Packet Capture mit engem Filter durchgeführt.
• Status und Reason im Packet Capture bewertet.
• Hin- und Rückrichtung geprüft.
• Webfilter, TLS Inspection, Application Control, IPS und Active Threat Response geprüft.
• Bei VPN MTU, MSS und Route geprüft.
• Bei DNAT oder WAF Zielhost, Hosted address und Backend geprüft.
• Zentrale Logs oder Syslog geprüft, falls lokale Logs nicht reichen.
• Bei Supportbedarf tcpdump oder Logarchiv gezielt vorbereitet.
• Ausnahmen nur eng und dokumentiert gesetzt.
• Befund mit Rule ID, NAT ID, Status, Reason und Änderung dokumentiert.

Häufige Fragen