Sophos Firewall Web Exceptions sicher erstellen und prüfen

Eine Web Exception ist schnell erstellt, ihre Wirkung kann aber deutlich grösser sein als erwartet. Je nach Auswahl überspringt die Sophos Firewall nicht nur HTTPS-Decryption, sondern auch Zertifikatsprüfung, Malware- und Content-Scanning, Zero-Day-Analyse oder komplette Web-Policy-Prüfungen.

Die sichere Reihenfolge lautet deshalb: zuerst den betroffenen Flow und die wirklich störende Prüfung bestimmen, danach den Match eng begrenzen und erst dann die kleinste nötige Ausnahme aktivieren. Ein Positivtest allein reicht nicht. Ein ähnliches, nicht freigegebenes Ziel muss im Negativtest weiterhin normal geprüft werden.

Diese Anleitung bezieht sich auf SFOS 22.0. Die Bezeichnungen in WebAdmin bleiben bewusst auf Englisch, damit sie direkt in der Oberfläche auffindbar sind.

Web Exception in sieben Schritten

1. Betroffenen Client, Zielhost, URL-Pfad, Protokoll und Zeitpunkt dokumentieren.
2. Prüfen, ob DPI Mode oder Web Proxy Mode verwendet wird und welche Firewall-Regel sowie Web Policy tatsächlich greifen.
3. Entscheiden, ob nur TLS-Decryption oder eine konkrete Web-Schutzprüfung stört.
4. Unter Web > Exceptions > Add an exception ein enges URL-, Kategorie-, Quell- oder Zielkriterium definieren.
5. Nur die kleinste nötige Option unter Skip the selected checks or actions auswählen.
6. Exception aktivieren und denselben Flow mit einem neuen Browser- oder Anwendungsprozess erneut testen.
7. Einen Negativtest gegen ein ähnliches, nicht freigegebenes Ziel durchführen und Match, Wirkung, Owner sowie Review-Datum dokumentieren.

⚠️ HTTPS decryption ist keine harmlose Kompatibilitätsoption. Für den passenden Traffic entfallen auch davon abhängige Prüfungen, und die Firewall lässt dabei ungültige Serverzertifikate zu. Malware and content scanning überspringt automatisch auch die Zero-Day-Analyse. Eine breite Ausnahme darf deshalb nicht der erste Troubleshooting-Schritt sein.

Produktvoraussetzungen vor der Ausnahme klären

Für bestimmte verwaltete Produkte sind Port- und Domainfreigaben Voraussetzung für die jeweilige Funktion. Vor der Wahl einer Firewall-Regel, TLS Exclusion oder Web Exception werden deshalb Produkt, Funktion, Version und tatsächlicher Verbindungsweg mit dem Produkt-Owner geklärt. Die benötigten Ziele, Ports, Protokolle, Richtungen und ausdrücklich geforderten Inspection-Ausnahmen gehören ins Change-Ticket, nicht in eine pauschale Freigabe für alle Sophos-Produkte.

• Wireless: Der Wireless-Preflight trennt Managementnetz, DNS, Zeitdienst und regionale Zielanforderungen von der späteren WLAN-Konfiguration.
• ZTNA: Beim ZTNA-Gateway zuerst die lokale oder Cloud-Bereitstellung bestimmen; deren Verbindungsrichtungen und Inspection-Anforderungen sind nicht austauschbar.
• Switch-Registrierung: Das Switch-Onboarding führt durch DNS, Registrierungsziele und die Prüfung des Proxy-/TLS-Pfads.
• Endpoint, XDR und MDR: Die Netzwerk- und Proxy-Anforderungen unterscheiden Plattform, lizenzierte Funktionen und installationsspezifische Ziele. Eine Domainfreigabe ist keine pauschale No-Decrypt-Liste.
• NDR und Integration Appliances: Die Appliance-Planung behandelt ausgehende Port- und Domainanforderungen; der Betriebsablauf hilft, die tatsächlich gehosteten NDR- und Log-Collector-Funktionen getrennt zu prüfen.

Die interne Anleitung dient als Einstieg; der Produkt-Owner bestätigt die verbindlichen Anforderungen für die konkrete Bereitstellung vor der Änderung. Netzwerk-Erreichbarkeit und Inspection-Bypass bleiben getrennte Entscheidungen. Fehlt ein verifizierter Anforderungssatz oder widersprechen sich Angaben, wird die Ausnahme nicht auf Verdacht erweitert: Nachweise sichern und mit Produkt- und Firewall-Owner klären. Danach gelten weiterhin Pilot, Positiv-/Negativtest, Review und Rollback aus dieser Anleitung.

Web Exception oder TLS Exclusion wählen

Beide Werkzeuge können verhindern, dass HTTPS-Traffic entschlüsselt wird. Sie lösen aber nicht dieselbe Aufgabe.

Eine SSL/TLS Inspection Rule mit Action: Don’t decrypt passt, wenn im DPI Mode nur die Entschlüsselung für klar benannte Ziele ausgenommen werden soll. Eine URL Group in der Local TLS Exclusion List ist dafür besonders effizient, weil die Firewall den Server Name Indication, kurz SNI, als Text abgleicht.

Wie eine solche Domainliste erstellt, in eine Don't decrypt-Regel eingebunden und mit einem Negativziel geprüft wird, zeigt URL Groups erstellen und sicher verwenden.

Eine Web Exception passt, wenn zusätzlich oder stattdessen eine Web-Schutzprüfung gezielt übersprungen werden muss:

• HTTPS decryption
• HTTPS certificate validation
• Malware and content scanning
• Zero-day protection
• Policy checks

Im DPI Mode greift eine Web Exception nur, wenn für den Flow mindestens eine Web Policy, Malware and content scanning oder ATP aktiv ist. Im Web Proxy Mode gehört die Web Exception direkt zum Proxy-basierten Web-Schutzpfad.

Auch der erfasste Traffic unterscheidet sich: Im DPI Mode gelten Web Exceptions für SSL/TLS-Verbindungen auf beliebigen Ports, im Web Proxy Mode für SSL/TLS auf Port 443. SSL/TLS Exclusion Rules gelten nur im DPI Mode, dafür ebenfalls portunabhängig. Sie können neben URL Groups auch Zonen, Netzwerke, IP-Adressen, Services sowie Benutzer und Gruppen als Kriterien verwenden. Web Exceptions bieten URL-Patterns, Web-Kategorien sowie Quell- und Ziel-IP-Adressen beziehungsweise -Bereiche.

Eine aktive Web Exception kann die gewählten Schutzprüfungen für passende Web-Flows überschreiben; das ist keine Zusage, dass jede Systemblockade aufgehoben werden kann. Man kann ihren Geltungsbereich deshalb nicht durch eine vermeintlich spätere Web-Policy-Regel absichern. Entscheidend sind die Kriterien der Exception selbst; Firewall-, Web- und SSL/TLS-Regelreihenfolge werden trotzdem separat geprüft, weil sie bestimmen, welcher Schutzpfad den Flow überhaupt verarbeitet.

Dokumentierte Grenze und offener Widerspruch: Sophos beschreibt Exceptions allgemein als unabhängig von Policies und Regeln. Die Kategorie-Anleitung für SFOS 22.0 und 23.0 nennt jedoch highly objectionable criminal activity ausdrücklich als immer gesperrt: Keine Policy oder Ausnahme darf diese Seiten erlauben; Domainnamen werden in Logs und Reports absichtlich verborgen. Diese abweichenden Aussagen belegen keinen funktionierenden Bypass. Die sichere Vorgehensweise bleibt, diese Sperre nicht zu umgehen und den Widerspruch bei Bedarf mit Sophos Support zu klären. Tests verwenden ausschliesslich harmlose, freigegebene Ziele, niemals verbotene Inhalte.

Der geplante Aufbau von DPI oder Web Proxy, Decryption Rules und CA-Verteilung steht unter TLS Inspection richtig einführen. Die eigentliche Filterlogik erklärt Web Protection mit Web Policies einrichten.

Match eng und nachvollziehbar planen

Eine Ausnahme sollte nicht mit einer beliebigen Vendor-Domain beginnen. Zuerst wird der konkrete Request im Browser, im Log Viewer oder in den Anwendungslogs erfasst. Danach lässt sich entscheiden, ob Hostname, Pfad, Kategorie, Quell-IP oder Ziel-IP das stabilste Kriterium ist.

AND zwischen Typen, OR innerhalb eines Typs

Sophos Firewall verknüpft unterschiedliche Kriterientypen mit AND. Werden beispielsweise URL-Muster und Source IP addresses gesetzt, müssen beide Typen passen.

Mehrere Werte innerhalb desselben Typs werden mit OR ausgewertet. Zwei URL-Muster bedeuten also, dass eines der beiden Muster genügen kann. Zwei Source IP addresses bedeuten, dass eine der beiden Quellen genügen kann.

Diese Logik ist wichtig für die Fehlersuche. Eine Exception kann scheinbar korrekt aussehen und trotzdem nicht greifen, weil ein zusätzlicher Kriterientyp nicht zum realen Flow passt.

Regulären Ausdruck sicher verankern

Unter URL pattern matches sind reguläre Ausdrücke erlaubt. Ein nacktes Muster wie vendor.example ist ungeeignet. Es kann den Text auch an einer unerwarteten Stelle der URL treffen und unnötig viele Requests ausnehmen.

Für die reservierte Beispieldomain updates.vendor.example kann ein bewusst verankertes Hostmuster so aussehen:

^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/

Der Wert ist nur ein Muster. vendor.example ist eine reservierte Dokumentationsdomain und wird durch den echten, im Log oder Request bestätigten Zielhost ersetzt. Das optionale Präfix erlaubt Subdomains. Wenn nur exakt ein Host freigegeben werden soll, wird kein unnötiger Subdomain-Wildcard verwendet.

Nicht-ASCII-Zeichen werden im Pattern als Punycode angegeben. Nach jeder Regex-Änderung gehören ein erwarteter Treffer und mindestens ein bewusst ähnlicher Nicht-Treffer zum Test.

Hostname und URL-Pfad unterscheiden

Ausnahmen für HTTPS decryption und HTTPS certificate validation können den Hostnamen bereits aus dem TLS-Kontext auswerten. Ein Muster, das nur auf einen URL-Pfad zielt, funktioniert bei HTTPS dagegen erst, wenn die Verbindung bereits entschlüsselt wird.

Das führt zu einer wichtigen Grenze: Eine Exception kann nicht gleichzeitig die Entschlüsselung abschalten und danach einen nur im verschlüsselten HTTP-Pfad sichtbaren Teil zuverlässig als Auswahlkriterium verwenden. Für diesen Fall braucht es einen Host-basierten Scope oder ein anderes Design.

Web Exception erstellen

Das Beispiel nimmt einen einzelnen Pilotclient für einen bestätigten Vendor-Host aus der HTTPS-Decryption. Es ist keine universelle Ausnahmeregel.

1. Web > Exceptions öffnen.
2. Add an exception auswählen.
3. Einen sprechenden Namen setzen, zum Beispiel Vendor API no decrypt.
4. URL pattern matches aktivieren.
5. Das getestete, verankerte Pattern unter Search/Add einfügen und mit Add übernehmen.
6. Für den Pilot zusätzlich Source IP addresses aktivieren und die konkrete Client-IP eintragen.
7. Unter Skip the selected checks or actions ausschliesslich HTTPS decryption auswählen.
8. Save wählen.
9. In der Liste den Schalter der neuen Exception aktivieren.
10. Name, Matching URLs, Quellen und übersprungene Prüfung nochmals kontrollieren.

Die Source-IP ist im Beispiel bewusst gesetzt. Ohne sie würde die Ausnahme sofort für jeden Client gelten, dessen Request das URL-Muster trifft. Nach erfolgreichem Pilot kann der Scope kontrolliert auf die tatsächlich benötigten Quellen erweitert werden.

Für eine reine TLS-Ausnahme über viele Ziele ist eine URL Group in einer Don't decrypt-Regel meist wartbarer und effizienter. Viele FQDN Host Objects in Source oder Destination einer SSL/TLS Inspection Rule sind ungünstig, weil dafür bei neuen TLS-Verbindungen zahlreiche DNS-Lookups entstehen können.

Wirkung der Skip-Optionen verstehen

Vor dem Speichern muss klar sein, welche Schutzwirkung verloren geht.

HTTPS decryption

Die Firewall entschlüsselt den passenden HTTPS-Traffic nicht. Damit kann sie auch Prüfungen nicht durchführen, die den entschlüsselten Inhalt benötigen. Sophos dokumentiert zusätzlich, dass Traffic mit ungültigem Serverzertifikat für diesen Match zugelassen wird.

Wenn wirklich nur eine Zertifikatsbesonderheit stört, ist diese Option häufig zu breit. Dann wird zuerst geprüft, ob HTTPS certificate validation die präzisere Ausnahme ist.

HTTPS certificate validation

Die Firewall überspringt die Gültigkeitsprüfung des Serverzertifikats. Eine konfigurierte Entschlüsselung kann trotzdem weiterlaufen. Diese Ausnahme passt nur für ein bekanntes Ziel mit bewusst akzeptiertem Zertifikatsproblem und braucht ein kurzes Review-Datum.

Ein dauerhaft abgelaufenes, falsch benanntes oder nicht vertrauenswürdiges Zertifikat sollte möglichst am Zielsystem repariert werden. Die Verteilung der richtigen Inspection CA löst ein anderes Problem und wird unter CA-Zertifikat für TLS Inspection verteilen erklärt.

Malware and content scanning

Die Firewall überspringt Malware- und Content-Scanning für den Match. Dabei wird automatisch auch Zero-day protection übersprungen. Der einzelne Haken nimmt somit zwei Schutzebenen aus dem Datenpfad.

Vor dieser Ausnahme werden Dateityp, Scanlimit, Verschlüsselung, Fehleraktion und der tatsächlich matchende Download geprüft. Der vollständige Testablauf steht unter Malware-Scanning konfigurieren und testen.

Zero-day protection

Die Zero-Day-Analyse wird übersprungen. Für passende Dateien entstehen keine Analyseberichte, auch wenn der klassische Malware-Scan einen Fund meldet. Diese Option ist enger als das vollständige Überspringen von Malware and content scanning.

Policy checks

Web-Policy-Prüfungen werden für den passenden Request übersprungen. Eine solche Ausnahme kann Kategorien, Benutzer- oder Gruppenlogik und weitere Policy-Entscheide unwirksam machen. Sie sollte nur für einen klar belegten Policy-Fehler verwendet werden, nicht als pauschale Lösung für eine blockierte Webseite.

Dies erlaubt nicht, die oben dokumentierte absolute Sperre für highly objectionable criminal activity per Policy checks aufzuheben.

Wirkung mit Positiv- und Negativtest prüfen

Ein erfolgreicher Seitenaufruf beweist nur, dass sich etwas verändert hat. Er beweist noch nicht, dass die Ausnahme präzise ist.

1. Zeitpunkt, Pilotclient, Zielhost und erwartete Wirkung festhalten.
2. Bestehende Browser- oder Anwendungssession schliessen und eine neue Verbindung erzeugen.
3. Den betroffenen Request erneut ausführen.
4. Im Log Viewer Source IP, Zielhost, Web Policy, Firewall Rule ID und Action vergleichen.
5. Bei einer Decryption-Ausnahme das vom Client sichtbare Serverzertifikat mit dem Zustand vor der Änderung vergleichen.
6. Ein ähnliches, aber nicht freigegebenes Ziel aufrufen.
7. Prüfen, dass dieses Ziel weiterhin von der normalen Web Policy, Decryption Rule und Scan-Kette erfasst wird.
8. Exception kurz deaktivieren und den ursprünglichen Fehler reproduzieren, sofern dies im Wartungsfenster gefahrlos möglich ist.
9. Exception wieder aktivieren und den Erfolg erneut bestätigen.

Wenn QUIC oder HTTP/3 den erwarteten TCP-TLS-Pfad umgeht, kann der Test irreführend sein. Die Abgrenzung steht unter QUIC und HTTP/3 richtig blockieren. Welche Regel und Policy wirklich matched, zeigt Log Viewer, Policy Tester und Packet Capture.

Der Policy tester wird unter Diagnostics > Tools im Bereich Pop-out tools geöffnet. Mit der Testmethode Firewall, SSL/TLS, and web hilft er, die erwartete Firewall-Regel, SSL/TLS Inspection Rule und Web Policy zu bestimmen. Er testet Web-Traffic jedoch nur im Transparent Mode und bildet deshalb keinen expliziten Direct-Web-Proxy-Flow ab. Ob die Web Exception tatsächlich greift, wird immer mit einem neu erzeugten Request und echten Logs bestätigt.

Für den Lognachweis muss Log firewall traffic in der Firewall-Regel aktiv sein; bei einer SSL/TLS Inspection Rule wird Log connections ebenfalls eingeschaltet. Unter System services > Log settings müssen die passenden Logtypen für Local reporting aktiviert sein. Danach im Log Viewer den Testzeitpunkt und die Source IP eingrenzen und die Module Web filter sowie SSL/TLS inspection mit Firewall Rule ID, Policy und Action vergleichen. Die Bedienung erklärt Sophos Firewall Log Viewer richtig nutzen. Bleibt die gesamte Ansicht leer, folgt der Ablauf unter Log Viewer aktualisiert sich nicht, statt die Exception auf Verdacht zu verbreitern.

Fehler systematisch eingrenzen

Exception greift nicht

• Die dokumentierte absolute Kategoriesperre ist kein Match-Fehler. Ein absichtlich verborgener Domainname ist hier kein Logging-Defekt. Die Grenze erklären Web-Kategorien und Web Policies; keine breitere Ausnahme oder Tests gegen diese Inhalte versuchen.
• Der Schalter in Web > Exceptions ist nicht aktiv.
• Ein zusätzlicher Kriterientyp passt wegen der AND-Logik nicht.
• Das Regex ist nicht am Anfang verankert oder bildet den echten Hostnamen nicht ab.
• Bei einer HTTPS-Pfadausnahme wird der Traffic nicht entschlüsselt, deshalb ist der Pfad nicht sichtbar.
• Im DPI Mode ist weder eine Web Policy noch Malware and content scanning oder ATP für den Flow aktiv.
• Eine andere Firewall-Regel, Web Policy oder Betriebsart greift als erwartet.
• Eine bestehende Browser- oder Anwendungssession wurde nicht neu aufgebaut.

Exception greift zu breit

• Das Pattern enthält eine unkontrollierte Wildcard oder nur einen nackten Root-Domain-Text.
• Source IP addresses oder ein anderer Pilot-Scope fehlt.
• Mehrere URL-Muster innerhalb desselben Typs wirken wegen OR breiter als gedacht.
• Eine ganze Web category wurde statt des konkreten Hosts ausgenommen.
• Es wurden mehrere Skip-Optionen aktiviert, obwohl nur eine Prüfung stört.

Webseite funktioniert, Schutzwirkung ist aber unklar

Dann wird die Exception nicht weiter ausgeweitet. Zuerst werden Browserzertifikat, Web- und SSL/TLS-Inspection-Logs, Firewall Rule ID, Web Policy und ein kontrollierter Download gemeinsam geprüft. Fehlt dieser Nachweis, ist die Ausnahme nur ein Funktions-Workaround, aber noch kein sauber abgenommener Sicherheitsentscheid.

Wenn WebAdmin-Werkzeuge die Ursache nicht trennen, ordnet Sophos Firewall Service-Logs richtig zuordnen DPI, Proxy, Malware- und Zero-Day-Logs dem betroffenen Schutzpfad zu. Debug wird dabei nicht als erster Schritt aktiviert.

Review und Rollback

Jede produktive Web Exception erhält mindestens:

• technische Begründung und Ticket
• Owner für Anwendung und Firewall
• betroffene Hosts, Pfade, Quellen und Benutzergruppen
• exakt übersprungene Prüfungen
• Datum des Positiv- und Negativtests
• Review- oder Ablaufdatum
• dokumentierten Vorzustand

Für den Rollback wird die Exception zuerst deaktiviert, nicht sofort gelöscht. Danach werden ursprünglicher Fehler, normaler Schutzpfad und nicht betroffene Ziele erneut geprüft. Erst wenn keine Abhängigkeit mehr besteht, kann die Exception entfernt werden.

Standard- und Hersteller-Ausnahmen werden nicht unkontrolliert verändert. Bei einer eigenen Ausnahme bleibt klar erkennbar, warum sie existiert und wer sie später erneut beurteilt.

Betriebscheckliste

• DPI Mode oder Web Proxy Mode bestimmt.
• Tatsächlich matchende Firewall-Regel und Web Policy bestätigt.
• Hostname und gegebenenfalls URL-Pfad aus realem Traffic erfasst.
• Regex am Anfang verankert und gegen Nicht-Treffer getestet.
• AND zwischen Kriterientypen und OR innerhalb eines Typs berücksichtigt.
• Nur die kleinste nötige Skip-Option gewählt.
• Automatischen Zero-Day-Bypass bei Malware and content scanning berücksichtigt.
• Pilotquelle begrenzt.
• Positiv- und Negativtest durchgeführt.
• Log Viewer, Zertifikat und Schutzwirkung gemeinsam geprüft.
• Owner, Ticket, Review-Datum und Rollback dokumentiert.

Häufige Fragen