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.
• 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.
• General settings: SafeSearch, YouTube Restrictions, Google Apps 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.

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.

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.

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, File types oder Content filters auswählen.
3. Bei Bedarf Content filters ergänzen. Bei Content filters verwendet die Firewall für HTTPS dieselbe Aktion wie für HTTP.
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.

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

Regeln in einer Web Policy werden von oben nach unten ausgewertet. Eine Allow-Regel für All web traffic oberhalb einer Blockregel macht die Blockregel praktisch wirkungslos. Deshalb sollte man nach jeder Änderung nicht nur den Inhalt der Regel prüfen, sondern auch die Reihenfolge und den Status-Schalter.

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.
• Use web proxy instead of DPI engine ist bewusst gesetzt oder bewusst deaktiviert.
• 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 Web Proxy filtert in der Firewall-Regel nur die klassischen Ports 80 und 443. Der DPI Engine kann HTTP- und SSL/TLS-Traffic auch auf anderen Ports prüfen, sofern die Regel und die SSL/TLS-Inspection-Regeln passen. Bei Direct-Proxy-Designs muss zusätzlich klar sein, ob Clients den Proxy explizit verwenden oder ob normaler transparenter Clienttraffic durch die Regel läuft. Sonst testet man leicht den falschen Pfad.

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.

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.

Diese Funktionen sind hilfreich, aber nicht magisch. Bei HTTPS hängt die Wirksamkeit teilweise von HTTPS Scanning beziehungsweise TLS Inspection ab. Ausserdem ersetzen sie keine Identity- und Cloud-App-Governance in Microsoft 365 oder Google Workspace. Für produktive Umgebungen sollte man die Wirkung mit echten Testbenutzern und den betroffenen Browsern prüfen.

Bei Bing und Yahoo kann SafeSearch auf HTTPS-Verbindungen nur erzwungen werden, wenn HTTPS-Scanning in der betroffenen Firewall-Regel aktiv ist. Google-Apps-Login-Restriktionen gelten nur für Google-gehostete Domains. Microsoft-Entra-ID-Tenant-Restrictions brauchen saubere Tenant-Werte und sollten mit realen Microsoft-Cloud-Anmeldungen geprüft werden, nicht nur mit einer Beispiel-URL.

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 Overrides sind ein anderes Werkzeug als Quotas. Damit können autorisierte Benutzer im User Portal temporären Zugriff auf normalerweise blockierte Webseiten erstellen. Das kann für Schulen oder Support-Szenarien nützlich sein, braucht aber klare Grenzen: nicht übersteuerbare Kategorien, berechtigte Personen, Zeitfenster und ein Review der Overrides.

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. Je nach Auswahl werden HTTPS decryption, HTTPS certificate validation, Malware and content scanning, Zero-day protection oder Policy checks übersprungen.

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.

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. Besser sind konkrete Hostnames, passende URL Groups 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

Unter Web > Policies steht der Policy tester zur Verfügung. Damit kann man prüfen, welche Policy-Entscheidung für Benutzer, URL und Kontext erwartet wird.

Der Policy Tester ist ein guter Vorcheck, ersetzt aber keinen echten Paketfluss. Eine Firewall-Regel, NAT, TLS Inspection, QUIC oder Routing kann trotzdem verhindern, dass die erwartete Policy im echten Traffic greift.

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