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:

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

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:

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.

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. Benutzer, Gruppen oder Anybody bewusst wählen.
5. Activities, Categories, URL Groups, File types oder Content filters auswählen.
6. Aktion für HTTP und HTTPS festlegen: Allow, Warn, Block oder Quota.
7. Schedule setzen, falls die Regel nur zu bestimmten Zeiten gelten soll.
8. Regel aktivieren.
9. Regelposition innerhalb der Policy prüfen.
10. Logging und Reporting aktivieren.
11. 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.

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.
• Malware Scan ist passend aktiviert.
• Block QUIC protocol ist bewusst gesetzt.
• TLS Inspection wird separat geplant und nicht mit Web Policy verwechselt.

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.

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.

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.

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.

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

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:

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:

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.

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.

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 und Web-Logging aktiv.
• TLS Inspection und CA-Zertifikat für Pilotgruppe geprüft.
• QUIC-Strategie definiert.
• 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