Sophos Firewall Bypass-Regel sicher verwenden

Eine Bypass-Regel auf der Sophos Firewall ist kein normales Allow-Objekt und kein Ersatz für eine saubere Firewall-Regel. Der definierte Traffic umgeht damit den normalen Stateful-Firewall-Pfad. Dadurch werden auch viele Funktionen umgangen, auf die man sich im Alltag bewusst verlässt: Firewall-Regeln, Log Viewer, IPS, Webfilter, Application Control, Malware-Scanning oder andere Security Features.

Bypass-Regeln sind deshalb nur für eng begrenzte Spezialfälle sinnvoll, zum Beispiel für ein kurzfristiges Troubleshooting unter Anleitung, für eine sehr spezifische Kompatibilitätsausnahme oder für einen klar dokumentierten Workaround. Für normale Freigaben, Performance-Probleme oder False Positives sollte man zuerst gezielte Regeln, Ausnahmen oder Policies prüfen.

⚠️ Eine Bypass-Regel reduziert die Sichtbarkeit und Schutzwirkung der Firewall massiv. Bypass-Regeln sollten immer eng begrenzt, dokumentiert, getestet und nach Abschluss wieder entfernt werden.

Typische echte Anlässe sind Sonderfälle mit asymmetrischem Routing, ungewöhnlichem Protokollverhalten oder einer kurzfristigen Herstelleranalyse. Sobald die Ursache klar ist, sollte die Lösung wieder in normale Firewall-Regeln, NAT, Routing, IPS-, Web- oder TLS-Ausnahmen überführt werden.

Welche Bypass-Art gemeint ist

Der Begriff “Bypass” taucht in Sophos-Umgebungen mehrfach auf. In diesem Artikel geht es ausschliesslich um bypass-stateful-firewall-config in der Device Console.

• Stateful-Firewall-Bypass: CLI-Konfiguration, die definierten Host- oder Netzwerktraffic am normalen Stateful-Firewall-Pfad vorbeiführt.
• DoS bypass rule: Ausnahme unter Spoof Protection und DoS Settings für DoS-Prüfungen, nicht dasselbe wie Stateful-Firewall-Bypass.
• IPS Bypass session: IPS-Regelaktion, bei der ein IPS-Treffer für die Session anders behandelt wird.
• FastPath / Firewall acceleration: normale Beschleunigung vertrauenswürdiger Flows auf unterstützten Appliances oder Plattformen. Das ist kein manueller Stateful-Firewall-Bypass und sollte nicht als Workaround für Regelprobleme verstanden werden.
• LAN bypass / fail-to-wire: Hardware-Funktion bestimmter Appliances oder Module, nicht eine SFOS-Regel.
• Normale Firewall-Ausnahme: Firewall-, NAT-, Web-, TLS-, IPS- oder Application-Control-Anpassung im WebAdmin.

Diese Trennung ist wichtig, weil die Massnahmen unterschiedliche Risiken haben. Eine DoS-Ausnahme oder eine IPS-Aktion ist nicht automatisch harmlos, aber sie ist enger auf eine Funktion bezogen. Ein Stateful-Firewall-Bypass kann dagegen Sichtbarkeit und Policy-Auswertung sehr breit umgehen, wenn Quelle oder Ziel zu gross gewählt werden.

Vorher bessere Alternativen prüfen

Bevor man eine Bypass-Regel setzt, sollte klar sein, warum normale Mechanismen nicht ausreichen.

• Firewall-Regel matcht nicht: Regelreihenfolge, Source/Destination, Services und Logs prüfen.
• IPS blockiert eine Anwendung: IPS-Policy, Signatur, Ausnahme oder False-Positive-Analyse prüfen.
• TLS Inspection stört eine App: SSL/TLS Inspection Rule oder TLS Exclusion gezielt anpassen.
• Webfilter blockiert eine URL: Web Policy, Kategorie, URL Group oder Web Exception prüfen.
• Application Control greift falsch: Application-Control-Policy und erkannte Anwendung prüfen.
• NAT oder Routing wirkt falsch: NAT-Regeln, Rückroute, SD-WAN und Packet Capture prüfen.

Für Regel- und Log-Analyse helfen Sophos Firewall Regel testen mit Log Viewer und Packet Capture, Firewall-Regel greift nicht: Ursachen prüfen und Sophos Firewall-Regeln verstehen und richtig konfigurieren.

Einsatzgrenzen

Eine Bypass-Regel sollte nur gesetzt werden, wenn alle Punkte erfüllt sind:

• Quelle und Ziel sind konkrete Netze oder Hosts, nicht Any.
• Richtung und Rückrichtung sind verstanden.
• Es gibt ein Ticket, einen Grund und eine verantwortliche Person.
• Ein Wartungsfenster oder Testfenster ist definiert.
• Vorher wurde die bestehende Konfiguration dokumentiert.
• Ein Rollback-Befehl liegt bereit.
• Nach dem Test wird geprüft, ob die Regel wieder entfernt wurde.

Nicht geeignet ist eine Bypass-Regel für dauerhaftes “schnelles Freischalten” zwischen Netzen. Wenn eine Verbindung dauerhaft erlaubt sein soll, gehört sie in eine normale Firewall-Regel mit Logging und passenden Security Features.

Besonders vorsichtig sollte man bei NAT-Pfaden sein. Wenn SNAT, DNAT, VPN-NAT oder eine andere Übersetzung für den Flow nötig ist, kann ein Stateful-Firewall-Bypass die eigentliche NAT-Entscheidung umgehen oder den Test verfälschen. In solchen Fällen sollte zuerst mit NAT Rule ID, Firewall Rule ID, Packet Capture und Routing geprüft werden, statt den Stateful-Pfad pauschal zu umgehen.

Verbindung zur Device Console

Die Befehle werden in der Device Console der Sophos Firewall ausgeführt. Dafür verbindet man sich per SSH mit dem Benutzer admin und öffnet im Konsolenmenü die Device Console.

Der SSH-Zugriff sollte nur aus einem vertrauenswürdigen Admin-Netz erlaubt sein. Die Vorbereitung steht in Sophos Firewall per SSH verbinden.

Vor jeder Änderung sollte man zuerst den aktuellen Zustand anzeigen und dokumentieren.

show advanced-firewall

Host oder Netzwerk richtig wählen

Sophos erlaubt Bypass-Einträge für einzelne Hosts oder Netzwerke. Für Troubleshooting ist ein einzelner Host fast immer besser als ein ganzes Subnetz, weil damit weniger Traffic unsichtbar wird.

• Einzelner Quellhost zu Zielhost: dest_host <Ziel-IP> source_host <Quell-IP>
• Quellnetz zu Zielhost: dest_host <Ziel-IP> source_network <Netz-IP> source_netmask <Maske>
• Quellhost zu Zielnetz: dest_network <Netz-IP> dest_netmask <Maske> source_host <Quell-IP>
• Quellnetz zu Zielnetz: dest_network <Netz-IP> dest_netmask <Maske> source_network <Netz-IP> source_netmask <Maske>

Breite Netze wie komplette Client-, Server- oder VPN-Zonen sind fast nie ein guter Startpunkt. Besser ist ein enger Test mit einem Quellhost, einem Zielhost und einem klaren Dienst. Erst wenn der Testfall wirklich mehrere Hosts betrifft, sollte man über ein kleines Netz sprechen.

Wichtig ist auch die Richtung. Sophos beschreibt, dass für vollständige Verbindungen häufig Einträge für beide Richtungen nötig sind. Das sollte aber bewusst geschehen: nicht automatisch Any-Logik nachbauen, sondern den konkreten Rückweg verstehen.

Sophos nennt für diese Bypass-Liste kein praktisches Limit für die Anzahl Hosts oder Netze. Genau das ist im Betrieb riskant: Viele kleine Einträge sind zwar technisch möglich, werden aber schnell unübersichtlich. Wenn mehrere Bypass-Einträge nötig erscheinen, ist das meist ein Zeichen, dass das eigentliche Routing-, NAT-, Policy- oder Applikationsproblem noch nicht sauber verstanden ist.

Änderungsrahmen vor dem Bypass festlegen

Eine Bypass-Regel sollte nie spontan aus einer laufenden Fehlersuche heraus gesetzt werden. Bevor der add-Befehl ausgeführt wird, sollte klar sein, welcher einzelne Test damit beantwortet werden soll und wie die Änderung wieder zurückgenommen wird.

Für ein sauberes Wartungs- oder Testfenster sollte man diese Punkte notieren:

• Testfrage: Funktioniert der definierte Traffic ohne Stateful-Firewall-Pfad?
• Betroffener Flow: zum Beispiel 192.168.33.0/24 zu 192.168.46.0/24
• Startzustand: Ausgabe von show advanced-firewall vor der Änderung.
• Geplanter Rückweg: passender del-Befehl für jede gesetzte Richtung.
• Abbruchkriterium: unerwarteter Traffic, neue Störung oder falscher Zielbereich.
• Nachkontrolle: show advanced-firewall, Packet Capture und Funktionstest ohne Bypass.

Besonders wichtig ist der Rücknahmebefehl. Er sollte vor dem Setzen vorbereitet werden, nicht erst nach dem Test gesucht werden. Dadurch bleibt die Änderung auch dann kontrollierbar, wenn während des Wartungsfensters Druck entsteht.

Beispiel: Bypass-Regel erstellen

Beispiel:

• Quellnetz: 192.168.33.0/24
• Zielnetz: 192.168.46.0/24
• Quell-Netzmaske: 255.255.255.0
• Ziel-Netzmaske: 255.255.255.0

Die Regel für die erste Richtung:

set advanced-firewall bypass-stateful-firewall-config add dest_network 192.168.46.0 dest_netmask 255.255.255.0 source_network 192.168.33.0 source_netmask 255.255.255.0

Für die Rückrichtung braucht es eine zweite Regel, wenn auch der Traffic vom Zielnetz zurück zum Quellnetz den Bypass nutzen soll.

set advanced-firewall bypass-stateful-firewall-config add dest_network 192.168.33.0 dest_netmask 255.255.255.0 source_network 192.168.46.0 source_netmask 255.255.255.0

Danach erneut prüfen:

show advanced-firewall

Wenn nur ein einzelner Client und ein einzelner Server getestet werden, sollte man statt Netzwerken lieber Hosts verwenden:

set advanced-firewall bypass-stateful-firewall-config add dest_host 192.168.46.20 source_host 192.168.33.10

Für die Gegenrichtung entsprechend:

set advanced-firewall bypass-stateful-firewall-config add dest_host 192.168.33.10 source_host 192.168.46.20

Wirkung prüfen

Nach dem Setzen sollte man nicht nur testen, ob die Anwendung funktioniert. Entscheidend ist, ob der Bypass wirklich nur den geplanten Traffic betrifft.

Prüfpunkte:

1. show advanced-firewall zeigt genau die erwarteten Netze.
2. Es gibt keine breiteren Netze als geplant.
3. Richtung und Rückrichtung sind bewusst gesetzt.
4. Testtraffic funktioniert nur zwischen den erwarteten Quellen und Zielen.
5. Unbeteiligte Netze nutzen den Bypass nicht.
6. Normale Firewall Logs für diesen Traffic werden nicht mehr als Entscheidungsgrundlage erwartet.
7. Packet Capture zeigt den Traffic nur während des geplanten Tests.
8. Die Rücknahme wurde unmittelbar nach dem Test durchgeführt.

Wenn Log Viewer und Regelzähler plötzlich keine Events mehr zeigen, kann das durch den Bypass selbst verursacht sein. In diesem Zustand ist Packet Capture hilfreicher als der Log Viewer.

Bei asymmetrischem Routing sollte zusätzlich geprüft werden, ob der Rückweg wirklich über die erwartete Firewall läuft. Ein Bypass kann Symptome überdecken, wenn die eigentliche Ursache ein falsches Default Gateway, eine unvollständige Route oder NAT auf der falschen Seite ist.

Bei Performance- oder Offloading-Verdacht sollte man Bypass nicht mit FastPath verwechseln. FastPath, Firewall acceleration, PKI acceleration und IPsec acceleration sind eigene Mechanismen. Je nach Traffic und Plattform kann normaler Traffic beschleunigt werden, ohne dass man eine Bypass-Regel setzt. Umgekehrt macht eine Bypass-Regel aus einem schlechten Design keine saubere Performance-Architektur.

Bypass-Regel löschen

Zum Entfernen verwendet man denselben Befehl mit del statt add.

Erste Richtung entfernen:

set advanced-firewall bypass-stateful-firewall-config del dest_network 192.168.46.0 dest_netmask 255.255.255.0 source_network 192.168.33.0 source_netmask 255.255.255.0

Rückrichtung entfernen:

set advanced-firewall bypass-stateful-firewall-config del dest_network 192.168.33.0 dest_netmask 255.255.255.0 source_network 192.168.46.0 source_netmask 255.255.255.0

Danach wieder prüfen:

show advanced-firewall

Die Ausgabe sollte keine unerwarteten Bypass-Einträge mehr enthalten.

Nach dem Test wieder sauber absichern

Eine entfernte Bypass-Regel löst noch nicht automatisch das ursprüngliche Problem. Der Test zeigt nur, dass der normale Firewall-Pfad für den getesteten Traffic wahrscheinlich beteiligt war. Danach sollte man die Ursache bewusst in eine unterstützte, sichtbare Konfiguration überführen.

Sinnvolle Anschlussfragen:

• War eine normale Firewall-Regel zu eng oder an der falschen Stelle? Regelreihenfolge, Zonen, Source, Destination, Service und Benutzerzuordnung prüfen.
• Hat IPS, Web Protection oder Application Control blockiert? Signatur, Kategorie, Policy oder gezielte Ausnahme dokumentieren.
• War TLS Inspection beteiligt? TLS-Regel, Zertifikat, Ausnahme und betroffene Anwendung sauber prüfen.
• War es ein Routing- oder NAT-Thema? NAT Rule ID, Rückroute, SD-WAN Route und Packet Capture vergleichen.
• Wird der Traffic künftig dauerhaft gebraucht? Normale Firewall-Regel mit Logging, Owner und Review-Datum erstellen.

Nach der Rücknahme sollte mindestens ein Kontrolltest ohne Bypass durchgeführt werden. Wenn der Traffic wieder nur mit Bypass funktioniert, ist der Fall noch nicht abgeschlossen. Dann braucht es eine saubere Regel-, Policy-, NAT- oder Inspection-Anpassung, die im Log Viewer sichtbar bleibt und später überprüft werden kann.

Für dauerhafte Änderungen sollte man zusätzlich dokumentieren, welche Security Features bewusst aktiv bleiben und welche Ausnahme wirklich nötig ist. Eine temporäre Bypass-Regel darf nicht stillschweigend zur Betriebsarchitektur werden.

Dokumentation

Jede Bypass-Regel sollte dokumentiert werden:

• Datum und Uhrzeit
• Administrator
• Grund
• Quellnetz und Zielnetz
• betroffene Anwendung
• geplante Dauer
• Testnachweis
• Zeitpunkt der Entfernung
• Folgeaufgabe, falls eine saubere Regel oder Ausnahme erstellt werden muss

Ohne Dokumentation bleiben Bypass-Regeln leicht unbemerkt bestehen. Das ist besonders gefährlich, weil der normale Blick in Firewall-Regeln oder Log Viewer nicht ausreicht, um die Schutzlücke zu erkennen.

Checkliste

Vor dem Bypass:

• Normale Firewall-Regel, NAT, Routing, IPS, Web, TLS Inspection und Application Control geprüft.
• Konkrete Testfrage definiert.
• Quelle, Ziel, Richtung und Rückrichtung dokumentiert.
• Engste mögliche Variante gewählt, bevorzugt Host statt Netz.
• Aktueller Zustand mit show advanced-firewall gesichert.
• del-Befehl für jede geplante Richtung vorbereitet.
• Ticket, Owner, Zeitfenster und Rückbauzeitpunkt festgelegt.

Während des Tests:

• Bypass nur für den geplanten Zeitraum aktiv.
• Testtraffic mit Source, Destination, Dienst und Uhrzeit dokumentiert.
• Packet Capture oder Zielsystem-Log als Nachweis verwendet.
• Keine zusätzlichen Netze oder Anwendungen unbeabsichtigt betroffen.

Nach dem Test:

• Alle Bypass-Einträge mit del entfernt.
• show advanced-firewall zeigt keine unerwarteten Bypass-Regeln.
• Test ohne Bypass wiederholt oder Folgeproblem dokumentiert.
• Dauerhafte Lösung als normale Regel, Policy, NAT-, Routing- oder Inspection-Anpassung geplant.
• Ticket und Betriebsdokumentation aktualisiert.

Typische Fehler

• Zu breite Netze verwendet: Mehr Traffic als geplant umgeht die Firewall.
• Rückrichtung vergessen: Die Anwendung funktioniert nur teilweise oder asymmetrisch.
• Regel nicht entfernt: Eine dauerhafte Schutzlücke entsteht.
• Kein Ticket oder Kommentar: Später ist unklar, warum der Bypass existiert.
• Log Viewer als Beweis erwartet: Der Traffic erscheint nicht wie normale Firewall-Entscheidungen.
• Bypass statt gezielter Ausnahme genutzt: Security Features werden unnötig ausgeschaltet.
• Änderung ohne Wartungsfenster: Fehler wirken sofort produktiv.

Häufige Fragen