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.

Die SSL/TLS Exclusion List arbeitet mit Domainnamen im Klartext und schliesst deren Subdomains ein, nicht mit regulären Ausdrücken. SSL/TLS-Ausnahmen können neben der Entschlüsselung auch die Zertifikats- und Protokollvorgaben ausnehmen. Sie sind deshalb nicht mit einer Web Exception für ausschliesslich HTTPS certificate validation gleichzusetzen. Bestätigte Domains lassen sich im Control Center oder Log Viewer zur Local TLS exclusion list hinzufügen; alternativ wird die URL Group unter Web > URL groups oder die SSL/TLS Inspection Rule bearbeitet. Auch Web-Kategorien können Kriterien einer SSL/TLS Inspection Rule sein.

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.

Punkte, Hostgrenze und unerwünschte Pfadtreffer prüfen

In einem Regex steht ein unmaskierter Punkt für ein beliebiges Zeichen. Die Punkte eines festen Hostnamens werden deshalb als \. geschrieben. Das ^ bindet den Match an den Anfang; der abschliessende / begrenzt den Host gegenüber ähnlich beginnenden Namen wie updates.vendor.example.attacker.example. Sophos Firewall akzeptiert / und \/. Für genau einen Host lautet das engere Muster:

^updates\.vendor\.example/

Die Beispiele beziehen sich auf die Host-/URL-Darstellung, auf die diese Sophos-Muster angewendet werden, ohne vorangestelltes https://. Ein Testwerkzeug muss dieselbe Darstellung verwenden. Bei abweichenden Ports oder einer anderen Darstellung nicht auf Verdacht .* ergänzen, sondern den tatsächlich ausgewerteten Wert und den Schutzpfad klären. Die HTTPS-Grenze im folgenden Abschnitt bleibt bestehen.

Für das exakte Hostmuster gelten folgende Erwartungen. Beim vorhandenen optionalen Subdomain-Muster ist zusätzlich cdn.updates.vendor.example/file ein gewünschter Treffer; die übrigen Negativfälle bleiben Nicht-Treffer.

Gerade die letzten beiden Fälle sind wichtig: Der Abgleich kann die gesamte URL einschliesslich Pfad und Query betreffen. Ein unverankerter Domaintext kann dadurch auf einem fremden Host die Ausnahme auslösen. Der Test prüft nur das Matching; ob tatsächlich Schutzprüfungen entfallen, wird später mit einem neuen Request und Logs geprüft.

Lange Nicht-Treffer lokal testen

Viele unverankerte Muster können zusätzliche Sucharbeit verursachen, besonders wenn HTTPS-Decryption den vollständigen URL-Text verfügbar macht. Eine pauschale Schrittzahl oder eine immer konstante, lineare oder exponentielle Laufzeit lässt sich daraus nicht für jedes Muster ableiten. Verankerung ersetzt auch keine Prüfung komplexer Quantifizierer. Für Hostnamen keine pauschale .*-Wildcard verwenden.

Ein 1000-Zeichen-Test ergänzt die kurzen Fälle. Auf einem lokalen Admin-Rechner mit Python 3 erzeugt dieses Beispiel einen rein fiktiven URL-Text mit langem Pfad und der Zieldomain erst in der Query. Es prüft beide hier gezeigten Muster, ohne eine Firewall anzusprechen:

import re
from time import perf_counter

prefix = "other.example/"
suffix = "?next=updates.vendor.example/file"
value = prefix + "a" * (1000 - len(prefix) - len(suffix)) + suffix
assert len(value) == 1000
patterns = [
    r"^updates\.vendor\.example/",
    r"^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/",
]
for pattern in patterns:
    regex = re.compile(pattern)
    start = perf_counter()
    for _ in range(100):
        assert regex.search(value) is None
    print(pattern, "Nicht-Treffer, Sekunden:", perf_counter() - start)

Erwartet werden zwei Nicht-Treffer. Weitere synthetische Fälle sollten lange, fast passende Hostnamen und lange Pfade abdecken; Vorher-/Nachher-Muster werden mit denselben Eingaben verglichen. Bei verdächtigen komplexen Mustern ein lokales Werkzeug mit Zeitlimit verwenden und einen hängenden Test abbrechen. Python-Zeiten und Schrittzähler anderer Regex-Engines sind keine SFOS-Messung und kein Leistungsversprechen. Keine produktiven URLs, Tokens, Benutzernamen oder Kundendaten in externe Regex-Webseiten kopieren; für solche Tests genügen fiktive Daten.

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. Bei unverschlüsseltem HTTP ist der URL-Pfad ohne TLS-Decryption sichtbar.

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, die konkrete Client-IP eintragen und mit Add übernehmen.
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.

Neue Host-Ausnahme in Config Studio vorbereiten

Config Studio kann eine neue Web Exception aus einem Domainnamen erzeugen, ohne zuerst eine bestehende Ausnahme zu importieren. Das ist ein eigener Ablauf; Bad regex und Apply Fix dienen dagegen der weiter unten beschriebenen Reparatur vorhandener Einträge. Die neue Ausnahme wird zunächst nur lokal vorbereitet und erst durch den TAR-Import auf die Firewall übernommen.

Vorher ein vollständiges Firewall-Backup und einen unveränderten selektiven Export von WebFilterException derselben Firewall geschützt ablegen. Der Abschnitt WebFilterException exportieren und mit Config Studio prüfen beschreibt den Export von Entities.xml, die Dateibehandlung und den späteren Download. Im Change-Ticket einen noch nicht verwendeten Namen, den bestätigten Zielhost, die nötige Skip-Option und den vorgesehenen Clientumfang festhalten. Ein vorhandener Name ist kein sicherer Weg, einen zusätzlichen Eintrag anzulegen: Der Import aktualisiert passende bestehende Ausnahmen. Ein geänderter Name erzeugt dagegen einen neuen Eintrag und entfernt den alten nicht.

1. Config Studio über den unten verlinkten Zugang öffnen, Configuration editor wählen und zu Rules > Web exceptions wechseln.
2. Add wählen und den neuen, eindeutigen Namen eingeben, etwa Vendor API exact host no decrypt.
3. Unter Skip these checks nur die fachlich notwendige Option einschalten. Für das Decryption-Beispiel ist dies Skip HTTPS decryption. Die weiteren Optionen heissen Skip policy check, Skip cert validation, Skip malware scan und Skip zero-day protection. Die oben beschriebenen Schutzfolgen gelten auch bei der Erstellung im Editor; nicht vorsorglich mehrere Optionen auswählen.
4. Unter Match by URL/Domain den Geltungsbereich wählen: Exact host only für genau den bestätigten Host oder Domain + all subdomains, wenn dessen sämtliche Subdomains ausdrücklich benötigt und genehmigt sind. Für updates.vendor.example bleibt im Beispiel Exact host only gewählt; cdn.updates.vendor.example soll nicht mit erfasst werden.
5. Den bestätigten Domainnamen in das Textfeld eingeben, ohne URL-Pfad, zum Beispiel updates.vendor.example. Diesen Dokumentationswert durch den realen Zielhost ersetzen. Das erzeugte Regex und die Vorschau erscheinen automatisch; beide mit dem geplanten Scope und den oben beschriebenen Positiv-/Negativfällen prüfen.
6. Add to URL Regex list wählen. Das Muster muss danach unter URL Regex Patterns stehen. Ein sichtbarer Vorschauwert allein ist noch kein übernommener Listeneintrag.
7. Optional kann unter URL Regex Patterns über + Add URL regex ein bereits geprüftes eigenes Muster direkt ergänzt werden. Für die Domain-Erstellung ist dies nicht nötig; zusätzliche Muster erweitern wegen OR den möglichen Match.
8. Abschliessend Add unten im seitlichen Formular wählen. Erst damit ist die neue Ausnahme im Editor angelegt.

Vor dem Download unter Preview die Import-XML mit dem gesicherten Vorzustand und dem Change-Ticket vergleichen. Es darf nur die genehmigte neue Ausnahme hinzukommen; keine bestehenden Namen, Kriterien, Aktivierungszustände oder Skip-Optionen dürfen unbeabsichtigt geändert werden. Auch der Clientumfang muss stimmen: Exact host only begrenzt das Ziel, nicht die Quellen. Ist eine erforderliche Pilotquelle in der erzeugten Konfiguration nicht nachweisbar enthalten, nicht importieren; stattdessen den oben beschriebenen WebAdmin-Ablauf mit Source IP addresses verwenden. Die XML nicht durch ungeprüfte zusätzliche Felder ergänzen.

Danach Download > Download TAR wählen und das Archiv geschützt ablegen. Für Importmeldungen, Vorher-/Nachher-Vergleich unter Web > Exceptions, Aktivierungsprüfung sowie neue Verbindungen mit Positiv-/Negativtest gilt Import, Wirkungskontrolle und Rückweg. Der XML-Preview oder ein erfolgreicher Import ersetzt diesen Schutzwirkungstest nicht. Bei einem unerwarteten Ergebnis den neuen Eintrag kontrolliert deaktivieren und den normalen Schutzpfad erneut prüfen. Ein Rückimport des ursprünglichen selektiven Exports entfernt die neu angelegte Ausnahme nicht automatisch; erst nach geklärten Abhängigkeiten wird sie gezielt entfernt. Bestehende Ausnahmen bleiben dabei unangetastet.

Kategorie statt einzelner Domain ausnehmen

Wenn vertrauliche Finanzdaten nicht entschlüsselt werden sollen, kann die Kategorie Financial services das passende Kriterium sein. Eine Kategorieausnahme umfasst jedoch mehr Ziele als ein einzelner Host; die Klassifizierung muss zum beabsichtigten Scope passen.

1. Unter Web > Exceptions > Add an exception einen Namen wie Financial services no decrypt setzen.
2. Web site categories aktivieren, Add new item wählen und Financial services auswählen.
3. Mit Apply selected items übernehmen und für den Pilot zusätzlich Source IP addresses mit der Client-IP und Add setzen.
4. Nur HTTPS decryption auswählen, Save wählen und den Schalter in der Liste aktivieren.
5. Einen freigegebenen Finanzdienst und ein harmloses Ziel ausserhalb der Kategorie mit neuen Verbindungen prüfen. Die Pilotquelle und Kategorie müssen wegen AND beide passen.

Für passende HTTPS-Verbindungen entfallen Entschlüsselung und davon abhängige Inhaltsprüfungen; auch die oben beschriebene Zertifikatsfolge gilt. Das ist keine pauschale Freigabe der Kategorie und keine Aussage, dass jede andere Schutzfunktion abgeschaltet wird.

Malware-Ausnahme für einen bestätigten Downloadhost

Ein als risikoarm eingestufter Anbieter ist allein kein Grund, Scanning abzuschalten. Wenn eine fachlich begründete Ausnahme erforderlich ist, wird der Ablauf oben mit einem eigenen Namen wie Vendor download scan exception, dem bestätigten Hostmuster und der Pilotquelle verwendet. Statt HTTPS decryption wird Malware and content scanning ausgewählt. Zero-day protection wird automatisch mit ausgewählt; auch ältere Ausnahmen, die Malware-Scanning überspringen, überspringen die Zero-Day-Analyse. Danach Save wählen und den Schalter aktivieren. Für passende Downloads entfallen Malware-/Content-Scanning und Zero-Day-Analyse einschliesslich ihrer Analyseberichte. Die übrigen Prüfungen werden nicht zusätzlich abgewählt. Mit einem harmlosen, kontrollierten Download auf dem freigegebenen Host und einem nicht ausgenommenen Vergleichsziel wird der vorgesehene Schutzpfad geprüft; ein erfolgreicher Download allein genügt nicht.

Weitere Kriterien und bestehende Ausnahmen bearbeiten

Destination IP addresses wird mit der bestätigten Website-IP und Add befüllt, nicht mit der Client-IP. Bei zulässigen Kombinationen des Zielkriteriums mit URL oder Kategorie müssen alle gewählten Typen passen. URL-Patterns bestehen aus ASCII-Zeichen; internationale Domainnamen werden als Punycode eingesetzt. Matching URLs der Standardausnahme Apple Update kann als Syntaxbeispiel dienen, nicht als ungeprüfte Freigabevorlage.

TLS-Ausschluss: widersprüchliche Angaben zum Geltungsbereich. Die Seiten Add an exception für SFOS 22.0 und 23.0 beschreiben allgemein die AND-Verknüpfung verschiedener Kriterientypen. Exclude a website from TLS inspection sagt jedoch ausdrücklich, dass Quell- und Zielausnahmen nicht kombiniert werden können. Der genaue Geltungsbereich dieser Einschränkung ist unklar; die allgemeine Matching-Logik belegt keine Zulässigkeit. Die Kombination von Source IP addresses und Destination IP addresses ist daher kein verifiziert zulässiges Vorgehen. Vor der Aktivierung eines TLS-Ausschlusses werden der tatsächliche SFOS-Build, der DPI-/Proxy-Pfad, die notwendige Prüfungsumgehung und der enge Host-/Kategorieumfang geklärt. Die oben beschriebene Pilotquelle mit bestätigtem Hostnamen oder bestätigter Kategorie bleibt bestehen, ohne ein Ziel-IP-Kriterium hinzuzufügen. Ziel plus bestätigter Hostname/Kategorie ist nur dann eine separate Option, wenn der Clientumfang unabhängig begrenzt und genehmigt ist. Die vorgesehene Begrenzung darf nicht durch eine reine Quellausnahme ersetzt oder ein Kriterium einfach entfernt werden, damit die Ausnahme passt: Das erweitert die Prüfungsumgehung. Sind sowohl Quell- als auch Ziel-IP-Begrenzungen erforderlich, wird der Ausschluss weder aktiviert noch erweitert; gemeinsam mit dem Firewall-Verantwortlichen ist eine buildbezogene Klärung durch Sophos Support einzuholen.

Die Standardausnahmen unterstützen Softwareupdates und andere wichtige Website-Funktionen. Unter Web > Exceptions öffnet Edit eine vorhandene Ausnahme; Clone erstellt eine Kopie. Vor deren Aktivierung werden sämtliche übernommenen Kriterien und Skip-Optionen geprüft. Für die allgemeine HTTPS-Zertifikatsprüfung ist Web > General settings zuständig; eine einzelne Zertifikatsausnahme ersetzt diese Grundeinstellung nicht.

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.

Hohe CPU und langsame Webzugriffe nach Regex-Änderungen

Unter Diagnostics > System graphs zunächst Zeitpunkt und Lastverlauf mit den langsamen Requests und letzten Exception-Änderungen vergleichen. In Web > Exceptions die Selection criteria beziehungsweise Matching URLs aller aktiven Ausnahmen prüfen: Fehlen ^, maskierte Hostpunkte oder eine klare Hostgrenze? Gibt es breite Wildcards oder viele unverankerte Domaintexte?

Mit autorisiertem Konsolenzugang wird unter Device Management > Advanced Shell der folgende lesende Befehl ausgeführt. Er zeigt die aktuelle Prozesslast, ändert aber keine Konfiguration; mit q wird die Anzeige beendet.

top

Stehen awarrenhttp oder snort bei der CPU-Nutzung oben, können Web-Exception-Regex zur Last beitragen. Das ist ein Indiz, kein Beweis für die alleinige Ursache: Beide Prozesse erledigen weitere Prüfungen. Last, Requests und Muster deshalb gemeinsam untersuchen, nur eine begrenzte Änderung durchführen und danach unter vergleichbarer Verkehrslast erneut messen. Bleibt die CPU hoch, die übrigen Ursachen im betroffenen Schutzpfad weiter eingrenzen; nicht zum Gegenversuch pauschal Inspection oder alle Exceptions abschalten.

Bestehende Regex selektiv reparieren

Für wenige Ausnahmen ist Web > Exceptions > Edit der übersichtlichste Weg. Vorher Namen, Aktivierungszustand, Kriterien und Skip-Optionen sichern; danach ausschliesslich das geprüfte URL-Muster korrigieren. Für viele Einträge lässt sich stattdessen das Modul WebFilterException exportieren. Dieser Export umfasst die ausgewählten Web-Exception-Konfigurationen, nicht automatisch nur die eine fehlerhafte Ausnahme. Auch unveränderte Einträge müssen im Vorher-/Nachher-Vergleich erhalten bleiben.

Vor beiden Importvarianten ein aktuelles Firewall-Backup und einen unveränderten selektiven Export sicher ablegen. Rückweg, Wartungsfenster und Admin-Zugang müssen vor dem Import geklärt sein. Ein selektiver Export ist kein Ersatz für ein vollständiges Backup. Originaldatei, Arbeitskopie und freigegebenes Ergebnis getrennt aufbewahren; Konfigurationen und erzeugte Reports enthalten interne Details und gehören nur auf einen freigegebenen, zugriffsgeschützten Admin-Rechner.

WebFilterException exportieren und mit Config Studio prüfen

1. Auf derselben Firewall Backup & firmware > Import export öffnen und Export selective configuration wählen.
2. Über Add new item nach WebFilterException suchen und mit Apply selected items übernehmen. Include dependent entity nicht auswählen: Es sollen keine anderen Konfigurationsbereiche mitbearbeitet werden.
3. Mit Export beziehungsweise Download das Archiv API-[timestamp].tar speichern. Eine Arbeitskopie entpacken; darin liegt Entities.xml.
4. Sophos Firewall Config Studio öffnen. Configuration editor und Rules > Web exceptions wählen, dann über Import die selektive Entities.xml laden.
5. In Config Analysis auf Bad regex achten. Den betroffenen Eintrag mit Edit öffnen, den Vorschlag über Apply Fix prüfen und mit Update übernehmen. Namen nicht ändern; bei einem geänderten Namen erstellt der Firewall-Import eine neue Ausnahme statt die bestehende zu aktualisieren.
6. Den Vorschlag mit den Positiv-/Negativfällen und langen Nicht-Treffern prüfen. Für neue Hostmuster unterscheiden Exact host only und Domain + all subdomains den gewünschten Scope; eine Subdomainfreigabe darf nicht beiläufig durch die Reparatur entstehen. Eine automatische Korrektur ersetzt weder diese Entscheidung noch den Schutzwirkungstest.
7. Unter Preview die Import-Konfiguration kontrollieren und mit dem Original vergleichen: Nur freigegebene Regex sollen sich ändern, nicht Namen, Quellen, Zielkriterien, Aktivierung oder Skip-Optionen. Über Download > Download TAR das freigegebene Archiv speichern.

Config Studio verarbeitet die Konfigurationsdaten im Browser auf dem Endgerät; Parsing, Analyse und Reporterstellung laden diese Daten nicht nach aussen hoch. Trotzdem bleiben lokale Dateien, Downloads und HTML-Reports vertraulich. Keine Konfigurationen in andere Online-Analysewerkzeuge übertragen. Das Bearbeiten oder Herunterladen in Config Studio ändert noch nichts an der Firewall.

Alternative: Entities.xml kontrolliert bearbeiten

Ohne Config Studio wird dieselbe selektiv exportierte Arbeitskopie in einem Texteditor bearbeitet. Nur die betroffenen URL-Muster ändern; keine pauschale Ersetzung aller Punkte in der XML-Datei durchführen. XML-Struktur, Objektbezeichnungen und übrige Felder bleiben unverändert. Vor dem Packen XML-Wohlgeformtheit und den vollständigen Diff prüfen. Bei unklarer Syntax oder unerwarteten Zusatzdateien nicht importieren.

Die Datei weiterhin exakt Entities.xml nennen und die Dateien in ein neues TAR-Archiv mit derselben Struktur wie beim Original packen, nicht in ZIP und nicht unter einen zusätzlichen Verzeichnisordner. Enthält das Original weitere Dateien, werden diese nicht still verworfen. Der einfache Web-Exception-Ablauf darf nicht auf fremde Module oder sensible, voneinander abhängige Objekte übertragen werden.

Import, Wirkungskontrolle und Rückweg

Der Import überschreibt passende vorhandene Einstellungen. Ein erfolgreich hochgeladenes Archiv beweist weder einen engen Match noch eine unveränderte Schutzwirkung. Erst den Diff freigeben, dann im vereinbarten Wartungsfenster importieren.

Unter Backup & firmware > Import export > Import mit Browse das geprüfte .tar wählen und Import ausführen. Importmeldungen auf Fehler prüfen; anschliessend unter Web > Exceptions Namen und Anzahl der Einträge, Aktivierungszustand, Matching URLs, Kriterien und Skip-Optionen mit dem Sollzustand vergleichen. Einstellungen ohne passenden Import-Eintrag bleiben bestehen; der Import räumt unerwünschte zusätzliche Ausnahmen nicht automatisch auf.

Danach neue Verbindungen erzeugen, die vorhandenen Positiv-/Negativtests mit Logs wiederholen und bei einer Performance-Reparatur CPU-Verlauf und Prozesslast mit der Baseline vergleichen. Bei Fehlern den Rollout stoppen und die betroffene Ausnahme kontrolliert deaktivieren, sofern die Anwendungsfolge vertretbar ist. Zum gezielten Wiederherstellen kann der unveränderte selektive Export derselben Firewall importiert werden; vorher zwischenzeitliche Änderungen ausschliessen, da sonst auch diese überschrieben würden. Einen nachweislich zu breiten Vorzustand nicht ungeprüft wieder aktivieren. Ein vollständiges Backup-Restore bleibt der separat geplante Notfallweg, nicht der erste Rückschritt für ein einzelnes Regex. Nach jedem Rückweg Konfiguration und Schutzpfad erneut prüfen.

WebFilterException über die XML API planen

Der selektive Import von Entities.xml oben ist kein allgemeines XML-API-Rezept. Die Objektreferenzen für SFOS 22.0 und 23.0 beschreiben Add Web Filter Exception / Update Web Filter Exception mit dem Objekt WebFilterException. Die folgenden Zuordnungen helfen beim Prüfen einer geplanten Automation; sie sind kein vollständiger, sendefertiger Request. Zugang, geschützte Zugangsdaten, explizite Operation, versionsbezogene Request-Hülle und sichere Antwortauswertung gehören zum zentralen Ablauf XML API sicher verwenden. Ohne buildbezogen bestätigte Syntax wird nicht geschrieben.

Aktivierung, Skip-Flags und DomainList unterscheiden

Enabled aktiviert die Ausnahme und erlaubt on oder off. Die fünf Skip-Flags erlauben ebenfalls on oder off, bezeichnen aber das Überspringen einer Prüfung, nicht deren Aktivierung: HttpsDecrypt für HTTPS-Decryption, VirusScan für Malware-Scanning, PolicyCheck für Web-Policy-Prüfungen, ZeroDayProtection für Zero-Day-Schutz und CertValidation für HTTPS-Zertifikatsprüfung. on beim Skip-Flag bedeutet daher Schutzumgehung. Die oben erklärten Schutzfolgen gelten weiterhin, insbesondere der automatische Zero-Day-Bypass beim Überspringen des Malware-Scans. Nicht aus einem gesetzten Skip-Flag auf einen bereits aktiven oder passenden Eintrag schliessen.

Die Referenz zeigt unter DomainList wiederholbare Kriterien und separate Schalter am Objekt:

• EnableSrcIP mit SrcIp: Quell-IP-Prüfung; der Client gehört hierhin.
• EnableDstIP mit DstIp: Ziel-IP-Prüfung; die Website-Adresse gehört hierhin.
• EnableURLRegex mit URLRegex: URL-Muster-Prüfung, keine Domainliste mit automatisch eingeschlossenen Subdomains.
• EnableWebCat mit WebCategory: Web-Kategorie-Prüfung.

Die vier Schalter sind skalare yes/no-Werte, nicht on/off. Die vier Kriterien sind String-Arrays mit mehreren zulässigen Werten; für jeden Eintrag von SrcIp und DstIp nennt die Referenz höchstens 43 Zeichen. Ein bloss befülltes Array ersetzt keinen bestätigten Aktivierungsschalter. Unterschiedliche aktivierte Kriterientypen müssen gemäss der Matching-Logik mit AND passen, Werte innerhalb eines Typs mit OR. Zusätzliche URL-Muster können den Match daher verbreitern. Die oben dokumentierte ungeklärte TLS-Beschränkung für kombinierte Quell- und Ziel-IP-Ausnahmen bleibt bestehen: Das Vorhandensein beider API-Felder belegt keine zulässige Kombination. Nicht durch Weglassen eines Kriteriums einen breiteren Bypass erzeugen.

Für URLRegex bleiben Anfangsanker, maskierte Hostpunkte, klare Hostgrenze, ASCII/Punycode sowie Positiv-, Negativ- und lange Nicht-Treffer-Tests erforderlich. Das Muster der API-Referenz ist keine freigegebene Allowlist und ersetzt weder diese Tests noch die HTTPS-Pfadgrenze. XML-Syntaxprüfung allein beweist keinen sicheren Match.

Name ist der einzige als obligatorisch markierte Parameter: ein skalarer String mit höchstens 60 Zeichen; ausgeschlossen sind ^, ;, ', " und \. Das optionale NewName dient dem Umbenennen und hat dieselben Grenzen. Es ist nicht mit dem Anlegen eines neuen Eintrags durch einen geänderten Namen beim selektiven Import gleichzusetzen. Desc ist ein optionaler skalarer String mit höchstens 250 Zeichen; IsDefault kennzeichnet eine Standardausnahme mit skalarem yes/no und ist keine Berechtigung, Standardobjekte zu verändern. Die übrigen Parameter sind optional, ihre Default-Spalten leer. Daraus folgt weder ein konkreter Default noch eine Zusage, dass weggelassene Werte beim Update erhalten bleiben. Vorher den gespeicherten Zustand sichern und den vollständigen Soll-/Ist-Vergleich festlegen.

Antworten nach Operation, Code und Symbol einordnen

Beide Objektreferenzen enthalten genau diese Zuordnungen. Die Operationsbezeichnungen und Symbole bleiben bewusst unverändert:

Diese XML-Codes sind keine HTTP-Statuscodes. Message.* bleibt ein nicht aufgelöstes Dokumentationssymbol, keine verifizierte Laufzeitmeldung oder eindeutige Fehlerursache. Insbesondere darf aus Message.WebExceptionsLimit kein numerisches Maximum abgeleitet werden. Add und Update besitzen unterschiedliche Erfolg-/Fehlersymbole; die Add-Zuordnungen für 502 und 522 werden nicht auf Update übertragen.

Die tatsächliche Antwort mit Operation und XML-Code geschützt sichern, auch bei Timeout oder unklarem Ergebnis. Vor jedem erneuten Schreibversuch den tatsächlich gespeicherten Eintrag über eine buildbezogen bestätigte lesende Abfrage oder unter Web > Exceptions prüfen: alter und gegebenenfalls neuer Name, Anzahl, Aktivierung, sämtliche Kriterien und Skip-Flags. Auch ein gemeldeter Erfolg ersetzt diesen Vergleich nicht. Bei einem vorhandenen Eintrag nicht blind erneut anlegen, umbenennen, überschreiben oder Kriterien entfernen. Bei unklarem beziehungsweise teilweise verändertem Zustand stoppen und mit dem Firewall-Owner anhand von Antwort, Vorzustand und Sollzustand klären. Nach einer bestätigten Änderung neue Verbindungen und die vorhandenen Positiv-/Negativtests durchführen; erst sie prüfen die Schutzwirkung. Die zentrale API-Anleitung erklärt ergänzend Warnungen, Teilerfolge und das sichere Vorgehen ohne blinde Retries.

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