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.

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.

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.

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.

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.

Fehler systematisch eingrenzen

Exception greift nicht

• 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.

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