Sophos Firewall Web Protection mit Web Policies einrichten

Sophos Firewall Web Protection steuert, welche Webseiten, Kategorien und Webinhalte Benutzer erreichen dürfen. In der Praxis ist Web Protection aber nicht einfach ein einzelner Haken. Eine Web Policy muss fachlich geplant, in einer passenden Firewall-Regel aktiviert und danach mit echtem Traffic getestet werden.

Viele Fehler entstehen, weil eine Web Policy zwar existiert, aber auf keine aktive Firewall-Regel angewendet wird. Andere Probleme hängen mit HTTPS, TLS Inspection, QUIC, Benutzererkennung, Regelreihenfolge oder zu groben Ausnahmen zusammen. Der sinnvolle Ablauf ist deshalb: Policy planen, Regel bauen, aktivieren, testen und im Betrieb überwachen.

Welcher Web-Protection-Artikel passt?

Web Protection überschneidet sich mit Firewall-Regeln, TLS Inspection, QUIC, Reporting und Ausnahmen. Je nach Aufgabe passt ein spezifischerer Artikel besser:

• Web Protection und Web Policies grundsätzlich einrichten: Dieser Artikel.
• Single oder Dual Engine, Scanfehler, Grössenlimits und einen echten Malware-Test verstehen: Sophos Firewall Malware-Scanning konfigurieren und testen.
• Web-Kategorien, URL-Gruppen und Instant Alerts auswerten: Sophos Firewall Web-Kategorien und Instant Alerts nutzen.
• HTTPS-Traffic entschlüsseln und prüfen: Sophos Firewall TLS Inspection richtig einführen.
• CA-Zertifikat für verwaltete Clients verteilen: Sophos Firewall CA-Zertifikat für TLS Inspection verteilen.
• QUIC und HTTP/3 bei Webfiltering-Problemen einordnen: Sophos Firewall QUIC und HTTP/3 richtig blockieren.
• Herausfinden, welche Firewall-Regel und Policy wirklich greift: Sophos Firewall Regel testen mit Log Viewer, Policy tester und Packet Capture.
• Web- und Security-Events länger auswerten: Central Firewall Reporting oder Syslog an SIEM senden.

So bleibt die Analyse sauber: Erst muss klar sein, ob die Firewall-Regel matcht. Danach prüft man Web Policy, Kategorie, Benutzerkontext, QUIC, TLS Inspection und Logging.

Was Web Protection kontrolliert

Web Protection besteht aus mehreren Bausteinen. Nicht jeder Baustein muss in jeder Umgebung genutzt werden, aber die Zusammenhänge sollten klar sein.

• Web Policy: Regeln für erlaubte, gewarnte, blockierte oder quota-basierte Webzugriffe.
• Web categories: Sophos-Kategorien und eigene Kategorien für Webseiten.
• URL groups: Eigene Domainlisten für gezielte Allow- oder Block-Regeln.
• File types: Steuerung bestimmter Download- oder Dateitypen.
• Content filters: Begriffe oder Muster für Inhaltskontrolle.
• Exceptions: gezielte Ausnahmen von Web-, TLS- oder Scan-Verhalten.
• Search engine enforcement: SafeSearch und YouTube Restrictions.
• Advanced settings: Google-Apps-Login-Domainrestriktionen und Microsoft Entra ID Tenant Restrictions.
• Logging und Reporting: Nachvollziehbarkeit im Log Viewer, Reporting, Central oder SIEM.

Web Protection ersetzt keine saubere Firewall-Regelbasis. Die Firewall-Regel entscheidet zuerst, welcher Traffic von welcher Zone zu welcher Zielzone erlaubt ist. Die Web Policy ergänzt diese Regel um Webkontrolle. Die Grundlagen zu Regelreihenfolge, Source, Destination, Services und Security-Profilen stehen in Sophos Firewall Regeln verstehen und sauber aufbauen.

Voraussetzungen

Vor dem Rollout sollten diese Punkte geklärt sein:

• Web Protection ist lizenziert oder im verwendeten Bundle enthalten.
• Die betroffenen Client-Netze haben eigene Firewall-Regeln.
• Logging ist in den relevanten Regeln aktiv.
• DNS und Uhrzeit der Firewall funktionieren korrekt.
• Benutzererkennung ist geklärt, falls Policies pro Benutzer oder Gruppe gelten sollen.
• TLS Inspection ist geplant, wenn HTTPS-Inhalte genauer geprüft werden sollen.
• QUIC/HTTP/3 wird bewusst erlaubt oder blockiert.
• Es gibt eine Pilotgruppe und einen Rückfallweg für geschäftskritische Seiten.

Besonders wichtig ist die Trennung nach Zielgruppen. Eine Web Policy für normale Clients, Server, Gäste, VPN-Benutzer und Management-Systeme sollte nicht dieselbe sein. Server brauchen oft weniger Browsing-Kontrolle, aber strengere Ziel- und Update-Listen. Gäste brauchen oft Kategorien und Bandbreitenbegrenzung, aber keinen Zugriff auf interne Ressourcen.

Wenn Web Policies auf Benutzer oder Gruppen reagieren sollen, muss die Benutzererkennung funktionieren. AD SSO, Captive Portal, STAS, SATC oder andere Verfahren sollten nicht erst beim Web-Policy-Rollout entdeckt werden. Im Log Viewer muss sichtbar sein, ob ein Request als bekannter Benutzer, als Gruppe oder als Anybody beziehungsweise unbekannter Benutzer bewertet wurde.

Benutzerkriterien der getroffenen Firewall-Regel haben Vorrang vor Users in der Web Policy. Deshalb zuerst sicherstellen, dass Benutzer oder Gruppen bereits zur Firewall-Regel passen; die Web Policy kann diesen Scope danach weiter differenzieren, aber keinen von der Firewall-Regel ausgeschlossenen Benutzer nachträglich einbeziehen.

Minimalpfad zur wirksamen Web Policy

Für einen ausführbaren ersten Pfad eine Web Policy unter Web > Policies erstellen und mindestens eine enge Allow-/Block-Entscheidung aktivieren. Danach unter Rules and policies > Firewall rules eine echte Regel mit Action: Accept, passender Source Zone und Source Network, Destination Zone und Destination Network sowie den benötigten Services bearbeiten. Log firewall traffic aktivieren und die Web Policy unter Web filtering zuweisen. Bestehendes NAT nur gegen den bisherigen Internetpfad prüfen; nicht allein für die Web Policy ein neues NAT-Verhalten erfinden.

Vor der Änderung Rule ID und Ergebnis einer bewusst erlaubten sowie einer bewusst blockierten URL als Baseline festhalten. Danach dieselben Requests von einem Client im echten Source- und Benutzerkontext wiederholen. Abgenommen ist die Änderung erst, wenn Log Viewer dieselbe erwartete Rule ID, die neue Web Policy und je einen echten Allow- und Blockentscheid zeigt.

Web Policy planen

Eine gute Web Policy beginnt nicht in der Oberfläche, sondern mit ein paar fachlichen Entscheidungen.

Zielgruppen definieren

Zuerst wird festgelegt, für wen die Policy gilt:

• Standard-Clients im LAN
• verwaltete Notebooks über VPN
• Gast-WLAN
• Schulungsräume oder Schulumgebungen
• Server mit ausgehendem HTTP/HTTPS-Zugriff
• privilegierte Admin-Arbeitsplätze

Wenn dieselbe Firewall-Regel mehrere sehr unterschiedliche Gruppen enthält, wird Web Protection schwer nachvollziehbar. Besser sind getrennte Regeln und Policies, zum Beispiel LAN_USERS_WEB, GUEST_WEB oder SERVER_UPDATES_WEB.

Kategorien und URL Groups festlegen

Sophos-Webkategorien sind gut für breite Steuerung: Malware, Phishing, Adult Content, Anonymizer, Streaming, Social Media oder Games. URL Groups sind besser, wenn einzelne Domains gezielt erlaubt oder blockiert werden sollen.

Die Kategorie highly objectionable criminal activity wird immer blockiert. Weder Web-Policy-Regeln noch Exclusions können sie freigeben; ausserdem verbirgt SFOS die betroffene Domain in Logs und Reports.

Typische Verwendung:

• Bekannte Risikokategorien blockieren: Web category.
• Bestimmte SaaS-Domains erlauben: URL group.
• Einzelne falsch kategorisierte Domain behandeln: URL group oder eigene Kategorie.
• Streaming zeitlich einschränken: Web Policy mit Schedule oder Quota.
• Warnseite statt harter Block: Web Policy mit Warn-Aktion.

URL Groups sollten nicht zur unsortierten Sammelliste werden. Wenn viele Domains eingetragen werden, braucht die Liste einen Owner, einen Zweck und ein Review-Datum. Für sehr grosse oder dynamische Listen sind Sophos Firewall Threat Feeds oder andere Architekturbausteine oft sinnvoller.

Wie gültige Domainwerte, OR-Logik, Web-Policy-Verwendung und TLS-Ausnahmen zusammengehören, erklärt URL Groups erstellen und sicher verwenden.

Für reine Domain-Matches sind URL Groups meistens besser als eigene Web Categories. Sophos weist selbst darauf hin, dass URL Groups performanter sind und weniger False Positives erzeugen können. Eigene Kategorien sind sinnvoll, wenn eine Domain zusätzlich zu ihrer Sophos-Standardkategorie in einer eigenen Policy-Logik auftauchen soll.

Bei eigenen Kategorien sollte man Keywords sehr vorsichtig verwenden. Keywords werden gegen die gesamte URL inklusive Pfad und Query geprüft. Ein Allow über ein Keyword kann dadurch ungewollt greifen, wenn das Wort in einem Query-Parameter vorkommt. Für Allow-Entscheidungen sind konkrete Domains oder URL Groups meist sauberer; Keyword-Regeln passen eher für enge Blockfälle.

Allow-Regeln vorsichtig setzen

Allow-Regeln in Web Policies sollten eng sein. Eine Allow-Regel weit oben kann spätere Blockregeln unwirksam machen, weil Sophos Web-Policy-Regeln von oben nach unten auswertet. Das ist besonders relevant, wenn eine URL Group, eine Dateityp-Regel oder eine Kategorieausnahme oberhalb anderer Regeln steht.

Praktisch bewährt sich:

1. Spezifische erlaubte Business-Ausnahmen nach oben.
2. Kritische Blockkategorien danach.
3. Warn- oder Quota-Regeln für Graubereiche.
4. Allgemein erlaubter Webtraffic erst am Ende.

Web Policy erstellen

Die Web Policy wird unter folgendem Menü erstellt:

Web > Policies

Grundablauf:

1. Add policy auswählen.
2. Sprechenden Namen vergeben, zum Beispiel LAN_USERS_STANDARD_WEB.
3. Regeln hinzufügen.
4. Search engine enforcement prüfen, zum Beispiel SafeSearch oder YouTube restrictions.
5. Policy quota status setzen, falls Quota-Aktionen verwendet werden.
6. Advanced settings prüfen, besonders Logging, Reporting, grosse Downloads, Google Apps und Microsoft Entra ID Tenant Restrictions.
7. Policy speichern.

Eine Regel innerhalb der Web Policy wird über Add rule erstellt. Die Firewall legt dabei zuerst eine deaktivierte Standardregel an, die HTTP für Anybody blockiert. Danach werden die Felder gezielt angepasst:

1. Users öffnen und Anybody, konkrete Benutzer oder Gruppen bewusst setzen.
2. Activities öffnen und All web traffic, User activities, Categories, URL Groups oder File types auswählen.
3. Für Inhaltsregeln im Dialog den separaten Tab Content filters wählen, den Filter auswählen und and with content aktivieren. Die HTTPS-Aktion bleibt dabei Use action.
4. Action für HTTP setzen: Allow, Warn, Block oder Quota.
5. HTTPS-Aktion prüfen: Use action, Allow HTTPS, Warn HTTPS, Block HTTPS oder Quota HTTPS.
6. Constraints setzen, wenn die Regel nur zu einem Schedule gelten soll.
7. Regelposition innerhalb der Policy prüfen.
8. Status der Regel einschalten.
9. Policy speichern.

Content-Filter-Listen sauber importieren

Content Filters werden unter Web > Content filters gepflegt und danach in der Web-Policy-Regel unter Activities ausgewählt. Für grössere Begriffslisten unterstützt Sophos eine einfache .txt-Datei. Die Datei darf höchstens 2,000 Zeilen enthalten; jeder Eintrag darf inklusive Leerzeichen und Satzzeichen maximal 80 Zeichen lang sein.

Die Importdatei enthält genau einen Begriff pro Zeile. Jede Zeile wird als exact match ausgewertet. Überschriften, Kommentare, Metadaten oder zusätzliche Spalten gehören nicht in die Datei. Bei Umlauten oder anderen Nicht-ASCII-Zeichen sollte sie als UTF-8 gespeichert werden.

Sicherer Ablauf:

1. Begriffe in einem Texteditor bereinigen und je Zeile genau einen Eintrag setzen.
2. Datei als .txt mit UTF-8 speichern.
3. Liste unter Web > Content filters importieren und einen sprechenden Namen vergeben.
4. Beim Bearbeiten von Activities den separaten Tab Content filters wählen, den Filter auswählen und and with content aktivieren; die HTTPS-Aktion auf Use action belassen.
5. Mit einem Pilotclient einen erlaubten und einen bewusst passenden Begriff testen und die Aktion im Log Viewer prüfen.

Wenn ein Import abgewiesen wird oder einzelne Begriffe nicht greifen, zuerst Zeilenzahl, Zeichenlänge, Kodierung und unsichtbare Zusatzzeichen prüfen. Die Liste sollte nicht durch eine breite Allow-Regel oberhalb der Content-Filter-Regel umgangen werden.

Eigene Web-Dateitypen erstellen

Sophos Firewall erkennt File types anhand von Dateiendungen oder MIME-Headern. Die eingebauten Typen sind nicht editierbar. Ein eigener Typ wird unter Web > File types > Add aus einer passenden Vorlage erstellt und um die benötigten Endungen ohne führenden Punkt oder um MIME-Header ergänzt. Dasselbe Objekt kann anschliessend in Web- und E-Mail-Schutzrichtlinien verwendet werden.

Im Dialog Add ist ein Name anzugeben. Template ist optional und übernimmt die üblichen Endungen und MIME-Header einer Kategorie; die Werte lassen sich für den eigenen Typ ergänzen. Danach wird mit Save gespeichert. Vor Dateiendungen gehört kein Punkt: pdf ist richtig, .pdf falsch. Eingebaute Typen dienen nur als Vorgabe und können nicht editiert werden; Änderungen erfordern einen eigenen Typ.

SFOS führt als eingebaute Kategorien All executable files, Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files und Web files. Die Detailansicht unter Web > File types ist die operative Quelle für die aktuell hinterlegten Endungen und MIME-Header. Zum Beispiel enthält Compressed files unter anderem 7z, gz, rar, tar.gz und zip, während Document files unter anderem docx, xlsx, pptx, odt, rtf und pdf umfasst. Vor einer Freigabe wird der konkrete eingebaute Typ deshalb in der eigenen SFOS-Version geöffnet und gegen den tatsächlichen Anwendungsfall geprüft, statt nur vom Kategorienamen auszugehen.

Der neue Dateityp bewirkt allein noch nichts. Er muss in der passenden Web-Policy-Regel unter Activities > File types ausgewählt werden. Danach werden Aktion, Regelstatus und Reihenfolge geprüft; ausserdem muss die Web Policy weiterhin der tatsächlich getroffenen Firewall-Regel zugewiesen sein.

Zur Abnahme dienen ein repräsentativer Download und eine bewusst ähnliche Datei, die nicht matchen soll. Im Log Viewer werden Web Policy und Aktion kontrolliert. Ein Match nach Endung oder MIME-Header ist eine Policy-Klassifizierung, aber kein Nachweis für Malware oder eine erfolgte Zero-Day-Analyse. Bei HTTPS hängt die nötige Sichtbarkeit zusätzlich vom TLS-Inspection-Pfad ab. Greift der Typ nicht, werden zuerst Regelstatus und -reihenfolge, der tatsächlich ausgewählte File Type, die vom Server gelieferte Content-Type-Antwort, die sichtbare Dateiendung und der TLS-Inspection-Status verglichen. Eine falsche oder generische MIME-Angabe des Servers kann dazu führen, dass ein Test anders als anhand des Dateinamens erwartet ausfällt.

User Activities sauber bündeln

Unter Web > User activities > Add fasst eine User activity Web Categories, File types und URL Groups zu einer wiederverwendbaren Aktivität zusammen. Diese Elemente werden mit OR ausgewertet; ein einzelner Treffer genügt. Der Name bezeichnet also keinen angemeldeten Benutzer, sondern eine Sammlung von Webkriterien.

Die User Activity wird danach in der Web-Policy-Regel unter Activities ausgewählt. Das passt, wenn dieselbe Kombination in mehreren Policies verwendet wird. Zur Abnahme wird mindestens je ein Treffer pro enthaltenem Objekttyp sowie ein ähnlicher Nicht-Treffer geprüft.

Regelreihenfolge und migrierte Policies prüfen

Web-Policy-Regeln werden von oben nach unten ausgewertet. Liegt beispielsweise eine Allow-Regel für den Dateityp .mdb oberhalb einer Kategorie-Blockregel, bleiben .mdb-Downloads auch aus dieser Kategorie erlaubt. Im DPI Mode kann die erste Verbindung zur Kategorie zunächst zugelassen werden, bis der Dateityp feststeht; passt die Datei danach nicht, verwirft die Firewall die Verbindung ohne Blockseite. Soll die Kategorie immer blockiert sein, gehört die Kategorie-Regel oberhalb der Dateityp-Freigabe.

Für migrierte Alt-Policies gilt zusätzlich ein hartes Limit von 128 Regeln pro Policy. Enthält die Quelle mehr Regeln, verwendet SFOS nur die ersten 128. Benachbarte Regeln für User Activities, Categories, URL Groups, File types und Dynamic Categories werden deshalb vor beziehungsweise nach der Migration bewusst zu kombinierten Activities zusammengeführt. Regelanzahl, Reihenfolge und echte Allow-/Blocktests sind Teil der Migrationsabnahme.

Wiederkehrende Zeitfenster werden als eigener Schedule angelegt. Der Ablauf und die Abgrenzung zur zeitgesteuerten Firewall-Regel stehen unter Sophos Firewall Zeitpläne für Regeln und Policies einrichten.

Eine Web Policy allein wirkt noch nicht. Die Policy muss danach in einer Firewall-Regel verwendet werden. Das ist einer der häufigsten Konfigurationsfehler.

Web Policy in Firewall-Regel aktivieren

Die Firewall-Regel liegt unter:

Rules and policies > Firewall rules

Für normalen Client-Internettraffic ist meistens eine Regel von LAN oder einer Client-Zone nach WAN zuständig. Dort wird im Bereich Web filtering die passende Web Policy ausgewählt.

Prüfpunkte in der Firewall-Regel:

• Source zone und Source networks passen zum Clientnetz.
• Destination zone ist in der Regel WAN.
• Services enthalten HTTP/HTTPS oder die gewünschten Webdienste.
• Log firewall traffic ist aktiv.
• Im Bereich Web filtering ist die richtige Web Policy gesetzt.
• Scan HTTP and decrypted HTTPS ist passend aktiviert, wenn Web-Malware- oder Content-Scanning wirken soll.
• Use Zero-day protection ist nur sinnvoll, wenn Dateien über HTTP oder entschlüsseltes HTTPS gescannt werden.
• Block QUIC protocol ist bewusst gesetzt.
• Auf dem transparenten Firewallregel-Pfad ist Use web proxy instead of DPI engine für SafeSearch, YouTube Restrictions und Google-Apps-Login-Domainrestriktionen aktiviert; für andere Funktionen und beim Direct Proxy wird der Modus bewusst nach Bedarf gewählt.
• TLS Inspection wird separat geplant und nicht mit Web Policy verwechselt.

Sophos Firewall setzt Block QUIC protocol standardmässig, wenn in der Regel eine Web Policy ausgewählt oder Scan HTTP and decrypted HTTPS aktiviert wird. Das ist oft sinnvoll, weil QUIC nicht wie klassischer HTTPS-Traffic gescannt werden kann. Trotzdem sollte man den Haken nicht nur hinnehmen, sondern bewusst testen: Browser, Google-Dienste, Collaboration-Tools und einzelne SaaS-Anwendungen können ihr Verhalten ändern, wenn QUIC blockiert wird.

Wenn in derselben Firewall-Regel zusätzlich Application Control eingesetzt wird, gibt es eine wichtige Überschneidung: Manche Micro Apps, zum Beispiel Uploads oder Downloads innerhalb von Dropbox oder Gmail, werden über URL-Details erkannt. In DPI-Umgebungen braucht diese Erkennung eine passende SSL/TLS-Inspection-Regel mit Decryption. Dann kann Application Control solche Micro Apps auch dann auswerten, wenn die Web Policy selbst nicht der eigentliche Entscheidungspunkt ist.

Wenn eine allgemeinere Regel oberhalb der gewünschten Web-Regel matcht, erreicht der Traffic die Web Policy nicht. In solchen Fällen hilft Sophos Firewall Regel testen mit Log Viewer und Packet Capture.

HTTPS, TLS Inspection und QUIC einordnen

Ein grosser Teil des Webtraffics ist HTTPS. Ohne TLS Inspection sieht die Firewall weniger Inhalt. Kategorien, SNI, Zertifikate, Ziel-IP, Domaininformationen und Metadaten helfen, ersetzen aber keine vollständige Inhaltsprüfung.

DPI oder Web Proxy?

Bei Web Protection muss man früh entscheiden, ob die betroffene Firewall-Regel den DPI Engine oder den Web Proxy verwendet. Diese Entscheidung beeinflusst, welche Funktionen wie greifen und welche Logs später relevant sind.

• DPI Mode: moderner Standard für viele Client-Internetregeln. TLS Inspection läuft über SSL/TLS inspection rules, Quota wird nicht unterstützt.
• Web Proxy Mode: passend für Umgebungen mit explizitem Proxy-Verhalten oder Policy Quota. Proxy-Verhalten, Browser-/Client-Kompatibilität und Proxy-Logs bewusst prüfen.

In vielen Installationen ist DPI Mode der bessere Startpunkt. Wenn aber Zeitkontingente über Quota benötigt werden, reicht eine reine DPI-Regel nicht. Dann muss Web Proxy Mode bewusst geplant und getestet werden. Diese Entscheidung sollte vor dem Rollout fallen, weil ein späterer Wechsel andere Fehlerbilder, Logs und Benutzererfahrungen erzeugen kann.

Der Transparent Web Proxy verarbeitet in der Firewall-Regel nur die klassischen Ports 80 und 443; auf anderen Ports prüft der DPI Engine weiter, sofern Regel und SSL/TLS-Inspection-Regeln passen. Der Direct Proxy ist dagegen ein eigener, explizit vom Client gewählter Pfad und benötigt den Firewallregel-Schalter Use web proxy instead of DPI engine nicht zwingend. Deshalb beim Test immer festhalten, ob der Client transparent oder über seine explizite Proxykonfiguration zugreift.

Die vollständige Funktionsentscheidung, Pilotmigration und modusspezifische Abnahme führt DPI Engine und Web Proxy sauber vergleichen zusammen.

Wie Listener, PAC-Datei, Device Access und die ausführbare Proxyregel zusammengehören, zeigt Direct Web Proxy mit PAC-Datei einrichten.

Für IPv6-only-Clients mit IPv4-only-Webzielen gilt ein eigener Zwei-Regeln-Pfad. NAT64 mit Direct Web Proxy trennt dabei die Web Policy in der IPv6-Regel von Application Control und IPS im IPv4-Egress.

Soll die Sophos Firewall ihre Web Requests an einen Parent Proxy weitergeben, führt Upstream Proxy im WAN oder LAN/DMZ einrichten durch den jeweils passenden Regel- und NAT-Pfad.

Teilen mehrere RDS-Benutzer dieselbe Server-IP, kann Per-Connection AD SSO für Multi-User-Hosts die einzelnen HTTP- und HTTPS-Proxyverbindungen unterscheiden. Das Verfahren gilt nicht für Non-Proxy-Traffic und muss deshalb bewusst gegen SATC abgegrenzt werden.

TLS Inspection

Wenn Downloads, Malware-Scanning, bestimmte Webkategorien oder Inhaltskontrollen zuverlässig geprüft werden sollen, muss TLS Inspection geplant werden. Dafür braucht es ein vertrauenswürdiges CA-Zertifikat auf den Clients, passende TLS-Regeln, Ausnahmen und einen sauberen Pilot.

Der Rollout steht in TLS Inspection auf Sophos Firewall schrittweise ausrollen. Für das Verteilen und Validieren des CA-Zertifikats passt Sophos Firewall CA-Zertifikat für HTTPS Scanning installieren.

QUIC und HTTP/3

Moderne Browser verwenden oft QUIC beziehungsweise HTTP/3 über UDP 443. Das kann Webfilter-, TLS-Inspection- und Scanning-Erwartungen stören, wenn man eigentlich klassischen HTTPS-Traffic über TCP prüfen möchte.

In vielen Unternehmensumgebungen ist es sinnvoll, QUIC in Client-Internetregeln zu blockieren, damit Browser auf HTTPS über TCP zurückfallen. Die Details stehen in Sophos Firewall QUIC und HTTP/3 richtig blockieren.

SafeSearch, YouTube und Tenant Restrictions

Sophos Firewall kann in Web Policies zusätzliche Such- und Cloud-Kontrollen setzen. SafeSearch und YouTube liegen in Search engine enforcement, Google-Apps-Login-Domainrestriktionen und Entra Tenant Restrictions in Advanced settings der jeweiligen Web Policy.

Typische Optionen:

• Enforce SafeSearch für Google, Yahoo und Bing.
• Enforce YouTube restrictions für eingeschränkte YouTube-Inhalte.
• Restrict login domains for Google Apps für erlaubte Google-Domains.
• Apply Microsoft Entra ID tenant restrictions für Microsoft-Cloud-Tenant-Steuerung.

Auf dem transparenten Firewallregel-Pfad muss für SafeSearch, YouTube Restrictions und Google-Apps-Login-Domainrestriktionen Use web proxy instead of DPI engine aktiviert sein; ein expliziter Direct Proxy kann diese Proxyfunktionen ohne diesen Firewallregel-Schalter bereitstellen. Für SafeSearch bei Bing und Yahoo über HTTPS ist zusätzlich HTTPS-Scanning erforderlich, und Google-Apps-Login-Restriktionen gelten nur für Google-gehostete Domains. Entra Tenant Restrictions sind davon getrennt zu betrachten, brauchen saubere Tenant-Werte und müssen mit realen Microsoft-Cloud-Anmeldungen statt nur mit einer Beispiel-URL geprüft werden. Diese Kontrollen ersetzen keine Identity- und Cloud-App-Governance in Microsoft 365 oder Google Workspace.

Quota und Warnseiten

Web Policies können nicht nur blockieren oder erlauben. Mit Warn- oder Quota-Aktionen kann man Benutzer bewusst informieren oder zeitlich begrenzten Zugriff erlauben.

Sinnvolle Beispiele:

• Benutzer dürfen eine Warnung für bestimmte Graubereiche bewusst bestätigen.
• Streaming oder Shopping ist nur zeitlich begrenzt erlaubt.
• Schul- oder Laborumgebungen erlauben bestimmte Kategorien nur während definierter Zeiten.

Wichtig: Policy Quota wird im DPI Mode nicht unterstützt. Wenn Zeitkontingente benötigt werden, muss Web Proxy Mode verwendet werden. Das sollte man früh entscheiden, weil DPI und Web Proxy unterschiedliche Eigenschaften und Grenzen haben.

Die Allowed time quota wird auf Web-Policy-Ebene gesetzt und gilt für alle Regeln in dieser Policy, die eine Quota-Aktion verwenden. Wenn zwei Kategorien unterschiedliche Zeitkontingente brauchen, sind getrennte Web Policies sauberer als eine einzelne Policy mit gemischten Quota-Erwartungen. Quotas werden lokal um Mitternacht zurückgesetzt und können nicht auf null gesetzt werden.

Policy Quota gilt nicht für Content filters oder Dynamic Categories. Änderungen am Kontingent greifen ausserdem nicht, wenn die Policy ungültig ist, keine Restzeit mehr vorhanden ist oder bereits eine Quota-Session aktiv ist. In diesen Fällen zuerst Policyzustand und Session prüfen, statt den Wert wiederholt zu ändern.

Diese Policy Quota gilt für Webkategorien und ist nicht die benutzerbezogene Surfing Quota. Die getrennte Erstellung, Zuweisung und Verbrauchskontrolle von Surfing Quota und Network Traffic Quota folgt einem eigenen Ablauf.

Policy Quota im Betrieb prüfen

Unter Web > Policy quota status zeigt SFOS für einzelne Benutzer die verbleibende Zeit in den betroffenen Web Policies innerhalb eines 24-Stunden-Zeitraums. Ein ausgewählter Benutzer kann dort mit Reset zurückgesetzt werden. Das ist eine bewusste Zustandsänderung und kein Diagnoseknopf: Benutzer, Policy, Restzeit, Grund und Zeitpunkt werden vorher dokumentiert.

Dieser Reset betrifft die zeitbasierte Policy Quota einer Webkategorie. Er ist nicht dasselbe wie Reset user accounting für Surfing- oder Network-Traffic-Quotas. Ein Reset korrigiert weder eine falsche Regelreihenfolge noch eine fehlende Benutzererkennung.

Warn- und Blockseiten anpassen

Unter Web > User notifications lassen sich eigene Bilder sowie Block-, Override-, Quota- und Warntexte hinterlegen. Die Platzhalter {category}, {user} und {url} fügen Webkategorie, Benutzername und blockierte URL ein. Die Preview prüft Darstellung und Text, aber nicht, ob die richtige Web Policy und Firewall-Regel den produktiven Request treffen.

Die Meldung soll knapp erklären, warum der Zugriff blockiert oder gewarnt wurde und wo ein legitimer Geschäftsfall gemeldet wird. Benutzernamen und URLs können sensible Informationen enthalten; die Seite erhält deshalb keine internen Geheimnisse, Passwörter oder unnötigen Kontaktdaten.

Policy Overrides sicher begrenzen

Policy Overrides sind ein anderes Werkzeug als Quotas. Mit Enable policy override können autorisierte Benutzer im User Portal temporären Zugriff auf normalerweise blockierte Webseiten erstellen. Authorized users and groups begrenzt die Berechtigten, Blocked websites and categories definiert Ziele, die nie übersteuert werden dürfen. Allow manual access code entry wird nur aktiviert, wenn selbst erstellte Codes zum Freigabeprozess passen.

Unter Web > General settings > Policy overrides zuerst den bisherigen Zustand und die Berechtigten dokumentieren. Der autorisierte Benutzer legt im User Portal für den Override Websites beziehungsweise Kategorien, einen begrenzten Zeitraum und einen Zugangscode fest. Beim Aufruf eines passenden blockierten Ziels enthält die Sperrseite ein zusätzliches Feld für diesen Code. Ist Allow manual access code entry aktiv, dürfen die festgelegten Benutzer eigene Codes erstellen; ist die Option aus, müssen sie generierte Codes verwenden. Diese Auswahl ist nicht mit der Eingabe eines bereits gültigen Codes auf der Sperrseite zu verwechseln.

Mit View overrides lassen sich vorhandene Overrides anzeigen, ein- oder ausschalten und löschen. Zur Abnahme mit einem berechtigten Testbenutzer ein passendes Ziel innerhalb des Zeitraums mit gültigem Code aufrufen; ohne Code, ausserhalb des Zeitraums sowie für ein nie freigebbares Ziel muss der normale Block weiterhin greifen. Benutzer, Rule ID, Web Policy, Aktion und Zeitpunkt im Log Viewer abgleichen. Bei HTTPS muss die Sperrseite überhaupt angezeigt werden können; ein reiner Verbindungsabbruch bietet kein Eingabefeld.

Für den Rückweg den Pilot-Override über View overrides deaktivieren und mit einer neuen Anfrage den ursprünglichen Block prüfen. Erst danach einen nicht mehr benötigten Override löschen und nur die im Pilot geänderten globalen Werte auf den dokumentierten Vorzustand setzen. Bestehende Overrides anderer Benutzer nicht pauschal entfernen.

Bei AD-Benutzern gilt My policy overrides nur für die Main Group und individuelle Benutzer, nicht für weitere Gruppenmitgliedschaften. Eine passende SSL/TLS-Inspection-Regel mit Action > Deny hat weiterhin Vorrang. Muss ein fachlich genehmigter Override dort funktionieren, wird eine enge Web Exception zum Überspringen der HTTPS-Entschlüsselung geplant und separat negativ getestet; die TLS-Regel wird nicht pauschal gelockert.

Web Exceptions und TLS-Ausnahmen

Web Exceptions sind mächtig und deshalb gefährlich, wenn man sie als schnelle Reparatur verwendet. Eine Exception unter Web > Exceptions kann Schutzprüfungen für passenden Traffic überspringen, unabhängig davon, welche Web Policy gerade greift. Wird HTTPS decryption übersprungen, entfallen die davon abhängigen Prüfungen und ungültige Serverzertifikate werden zugelassen. Malware and content scanning überspringt automatisch auch Zero-day protection.

Für DPI-Umgebungen gilt eine wichtige Einschränkung: Web Exceptions greifen nur, wenn eine Web Policy gesetzt ist, Malware and content scanning aktiv ist oder ATP aktiv ist. SSL/TLS Exclusion Rules sind dagegen der richtige Ort, wenn es nur darum geht, bestimmte TLS-Verbindungen nicht zu entschlüsseln. Der Unterschied ist betrieblich wichtig:

• SSL/TLS Exclusion Rule: nimmt TLS-Verbindungen gezielt aus der Entschlüsselung, typischerweise wegen Certificate Pinning oder Inkompatibilität.
• Web Exception: kann Web-Policy-Prüfungen, Malware-Scanning, Zero-Day-Analyse oder Zertifikatsprüfung überspringen.
• URL Group in Web Policy: steuert Allow, Warn, Block oder Quota innerhalb der normalen Policy-Logik; eine URL Group ist kein Kriterium für Web Exceptions.

Für Exceptions sollte man Root-Domains und zu breite URL-Regex-Muster vermeiden. Ein Muster wie example.com kann auch in Pfaden oder Query-Parametern anderer Domains auftauchen. Konkrete Hostname-Muster können bereits im TLS-Kontext greifen; reine URL-Pfade sind nur bei HTTP oder bei bereits entschlüsseltem HTTPS sichtbar. Besser sind deshalb konkrete Hostnames und ein klarer Scope nach Quelle, Ziel, Kategorie oder Benutzergruppe.

Exceptions kombinieren ihre unterschiedlichen Kriterien mit AND. Innerhalb eines Kriterientyps, zum Beispiel mehrere URL Patterns, gilt dagegen OR. Das ist praktisch, aber fehleranfällig: Eine Exception mit URL Pattern und Source IP greift nur, wenn beides passt. Eine Exception mit sehr vielen URL Patterns kann dagegen viel breiter wirken als gedacht.

Besonders vorsichtig sollte man bei Policy checks sein. Wenn eine Web Exception Policy Checks überspringt, kann das auch andere Regelentscheidungen indirekt schwächen. In Kombination mit Synchronized Security Heartbeat kann eine solche Ausnahme dazu führen, dass Web Requests nicht wie erwartet blockiert werden, obwohl Heartbeat-Kontrollen in der Firewall-Regel gesetzt sind.

Web Protection testen

Nach dem Speichern sollte man nicht nur prüfen, ob die Policy existiert. Entscheidend ist, ob sie für echten Traffic greift.

1. Policy Tester verwenden

Der exakte Pfad ist Diagnostics > Tools > Pop-out tools > Policy tester. Firewall, SSL/TLS, and web prüft den kombinierten transparenten Pfad; Web policy only isoliert die Web-Policy-Entscheidung. Der Tester bildet Webzugriffe nur transparent ab, berücksichtigt keine SD-WAN-Routen und akzeptiert keine Source Networks mit MAC-Adressen. Ohne Protokoll nimmt er HTTP an, ohne Port den Standardport des gewählten Protokolls.

Vor einer Änderung beide passenden Modi als Baseline ausführen und Ergebnis sowie erwartete Rule ID festhalten; danach identisch wiederholen. Der Policy Tester bleibt ein Vorcheck und ersetzt keinen echten Allow-/Block-Test vom Pilotclient: NAT, TLS Inspection, QUIC, Routing oder ein expliziter Direct-Proxy-Pfad können den realen Paketfluss anders behandeln.

2. Echttest mit Pilotclient

Mit einem Pilotclient prüfen:

• erlaubte Business-Seite
• blockierte Kategorie
• warnende Kategorie
• URL Group Allow
• URL Group Block
• HTTPS-Seite mit und ohne TLS Inspection
• Download eines ungefährlichen Testdateityps
• Verhalten mit QUIC aktiv oder blockiert

3. Log Viewer prüfen

Im Log Viewer sollte sichtbar sein:

• welche Firewall-Regel getroffen wurde
• welcher Benutzer erkannt wurde, falls relevant
• welche Web-Kategorie oder URL-Gruppe beteiligt war
• ob HTTPS, TLS Inspection oder Malware Scan beteiligt waren
• ob die Aktion erlaubt, gewarnt oder blockiert hat
• ob eine Web Exception oder TLS Exclusion gegriffen hat
• ob ein Download wegen Grösse, Malware-Scan-Fehler oder Zero-Day-Analyse anders behandelt wurde

Bei Syslog oder SIEM sollten nicht nur URL und Action exportiert werden. Für eine belastbare Analyse sind auch Firewall Rule ID, Benutzer, Kategorie, Web Policy, HTTP-Methode, Status, Scan-Ergebnis, Exception-Hinweis und SSL/TLS-Bezug wichtig. Wenn diese Felder im SIEM fehlen oder falsch normalisiert werden, sieht Web Protection im Reporting schnell unklarer aus, als sie auf der Firewall tatsächlich ist.

Für tieferes Troubleshooting sind auch Logdateien relevant. Die Zuordnung steht in Sophos Firewall Troubleshooting: Services und Logs.

Instant Alerts und Reporting

Wenn bestimmte Kategorien nicht nur blockiert, sondern aktiv gemeldet werden sollen, können Instant Alerts sinnvoll sein. Das ist besonders nützlich in Schulen, streng regulierten Umgebungen oder Bereichen mit klarer Internetnutzungsrichtlinie.

Die drei Auswertungswege beantworten unterschiedliche Fragen:

• Schnelle E-Mail bei wenigen sensiblen Web-Kategorien: Instant Alerts.
• Wiederkehrende Reports, Trends und Benutzer- oder Kategorieauswertungen: Central Firewall Reporting.
• Längere Aufbewahrung, Korrelation mit anderen Systemen oder SOC-Prozesse: Syslog oder SIEM.

Vor Instant Alerts sollte klar sein, wer die Meldung erhält, welche Kategorien wirklich eine Reaktion auslösen, wie False Positives behandelt werden und wann die Kategorieauswahl überprüft wird. Eine breite Alertliste ohne Owner erzeugt schnell E-Mail-Rauschen, aber keine bessere Sicherheit.

Für die technische Aktivierung und Triage steht Sophos Firewall Web-Kategorien und Instant Alerts nutzen. Für längerfristige Auswertungen sollten Central Firewall Reporting oder Sophos Firewall Syslog an SIEM senden geprüft werden.

Änderungen und Ausnahmen im Betrieb steuern

Web Protection verändert sich im Betrieb laufend. Neue SaaS-Dienste kommen dazu, einzelne Domains werden falsch kategorisiert, Fachbereiche brauchen kurzfristig Zugriff und Browser-Verhalten ändert sich. Ohne klaren Ablauf entstehen schnell breite Ausnahmen, die später niemand mehr erklären kann.

Für jede Änderung sollte man mindestens festhalten:

• Wer braucht den Zugriff? Das verhindert globale Ausnahmen für wenige Benutzer.
• Welche Domain, Kategorie oder Dateiart ist betroffen? So bleiben URL Group, Web Category und File Type sauber getrennt.
• Ist es eine temporäre oder dauerhafte Ausnahme? Das erzwingt Review statt dauerhafter Schattenfreigaben.
• Welche Firewall-Regel und Web Policy sind betroffen? Das verhindert Änderungen an der falschen Regel.
• Wie wird getestet? Der Erfolg muss im Log Viewer nachweisbar sein.

Bewährt hat sich ein kleiner Change-Ablauf:

1. Anfrage mit Benutzer, URL, Zeitpunkt, Business-Grund und Screenshot oder Fehlermeldung erfassen.
2. Im Log Viewer prüfen, welche Firewall-Regel, Web Policy, Kategorie und Aktion gegriffen haben.
3. Entscheiden, ob die Kategorie grundsätzlich falsch ist, ob nur eine einzelne Domain freigegeben werden soll oder ob die Anfrage abgelehnt wird.
4. Falls eine Ausnahme nötig ist, möglichst eng arbeiten: einzelne URL Group statt ganze Kategorie, einzelne Benutzergruppe statt ganzes LAN.
5. Änderung in einer Testregel oder Pilotgruppe prüfen.
6. Nach dem Speichern einen Echttest durchführen und Log Viewer, Kategorie, Rule ID und Benutzerkontext dokumentieren.
7. Review-Datum setzen, besonders bei temporären Business-Ausnahmen.

Temporäre Ausnahmen sollten klar benannt werden, zum Beispiel TMP_ALLOW_vendor-portal_until_2026-07-31. Dauerhafte Business-Ausnahmen brauchen ebenfalls einen Owner. Wenn niemand für eine Ausnahme verantwortlich ist, sollte sie nicht dauerhaft in der Policy bleiben.

Wenn viele einzelne Domains für denselben Dienst entstehen, ist oft nicht die Web Policy das Problem, sondern die Architektur des Dienstes. Dann sollte man prüfen, ob eine eigene Firewall-Regel, eine eigene Web Policy, eine sauber gepflegte URL Group oder ein anderer Kontrollpunkt besser passt. Für dynamische IOC- oder Blocklisten sind Web-Policy-Ausnahmen meistens der falsche Ort; dafür passen eher Sophos Firewall Threat Feeds.

Rollback und Notfallfreigabe

Eine Web-Policy-Änderung kann produktive Arbeit sofort beeinflussen. Deshalb sollte man vor grösseren Änderungen festlegen, wie der alte Zustand wiederhergestellt wird.

Praktische Rollback-Optionen:

• betroffene Web Policy vor der Änderung duplizieren oder dokumentieren
• Änderung zuerst in einer Pilotregel oder kleinen Benutzergruppe testen
• alte Firewall-Regel oder alte Web Policy nicht sofort löschen
• Zeitfenster, Testbenutzer und Rückfallkriterium definieren
• nach dem Speichern Log Viewer, Rule ID und Kategorieentscheidung prüfen

Für akute Blockierungen sollte nicht reflexartig eine breite Allow-Regel ganz oben eingefügt werden. Besser ist eine enge, zeitlich begrenzte Ausnahme mit klarer URL Group, Benutzergruppe und Review-Datum. Wenn der Druck hoch ist, kann eine temporäre Ausnahme den Betrieb stabilisieren, sie muss danach aber wieder bewertet werden.

Typische Fehler

Web Policy greift nicht

Meistens ist die Policy nicht in der richtigen Firewall-Regel aktiviert, die Regel wird nicht getroffen, eine Regel weiter oben erlaubt den Traffic oder der Benutzerkontext passt nicht. Zuerst Log Viewer und Rule ID prüfen.

HTTPS wird nicht wie erwartet blockiert

Ohne TLS Inspection sieht die Firewall weniger Details. Je nach Ziel kann eine Domain- oder Kategorieentscheidung funktionieren, während Inhaltsprüfung, Dateitypen oder bestimmte Suchfunktionen eingeschränkt bleiben.

Wenn die Verbindung nicht entschlüsselt wird, kann die Firewall trotzdem SNI- oder Domaininformationen für Policy-Entscheidungen nutzen. Für Blockseiten, Warnseiten, Dateitypen, Content Filters, Malware-Scanning und Zero-Day-Analyse braucht es aber mehr Sichtbarkeit. Deshalb sollte man im Log Viewer nicht nur die Web-Policy-Aktion, sondern auch den SSL/TLS-Inspection-Status prüfen.

QUIC umgeht die Erwartung

Wenn Browser UDP 443 verwenden, kann Traffic anders verarbeitet werden als klassisches HTTPS über TCP. In Clientregeln sollte bewusst entschieden werden, ob QUIC blockiert wird.

Allow-Regel ist zu weit oben

Eine breite Allow-Regel am Anfang der Web Policy kann spätere Blockregeln aushebeln. Regelreihenfolge innerhalb der Web Policy ist genauso wichtig wie Regelreihenfolge in der Firewall-Regelliste.

Zu viele Ausnahmen

Ausnahmen lösen schnell ein Einzelproblem, können aber Schutzwirkung abbauen. Jede Ausnahme braucht Zweck, Owner und Review-Datum. Wenn viele Ausnahmen entstehen, ist oft die Policy-Struktur falsch oder eine Geschäftsanwendung braucht eine eigene Regel.

Besonders riskant sind Web Exceptions, die Policy checks oder Malware and content scanning überspringen. Wenn nur HTTPS-Decryption stört, ist eine SSL/TLS Exclusion meistens enger und nachvollziehbarer.

Reporting zeigt nichts

Dann sind Logging, Reporting, Firewall-Regel, Policy-Auswahl oder Logweiterleitung zu prüfen. Eine Policy ohne Logging ist im Betrieb schwer zu bewerten.

Betriebscheckliste

• Web Protection Lizenzstatus geprüft.
• Client-, Server-, Gäste- und VPN-Traffic getrennt bewertet.
• Web Policy mit sprechendem Namen erstellt.
• Kritische Kategorien und URL Groups bewusst geplant.
• Regelreihenfolge innerhalb der Web Policy geprüft.
• Web Policy in der passenden Firewall-Regel aktiviert.
• Log firewall traffic, Web-Policy-Logging und Reporting aktiv.
• Web-Policy-Regeln sind eingeschaltet und in richtiger Reihenfolge.
• TLS Inspection und CA-Zertifikat für Pilotgruppe geprüft.
• QUIC-Strategie definiert.
• Web Exceptions und TLS Exclusions getrennt dokumentiert.
• Policy Tester und Echttests durchgeführt.
• Log Viewer und Reporting kontrolliert.
• Änderungsprozess für Web-Policy-Ausnahmen definiert.
• Temporäre Ausnahmen mit Ablaufdatum versehen.
• Ausnahmen mit Owner und Review-Datum dokumentiert.

FAQ