Sophos Firewall Web-Kategorien und Instant Alerts nutzen

Web-Kategorien steuern, welche Webseiten Benutzer aufrufen dürfen. Instant alerts ergänzen diese Kontrolle um E-Mail-Meldungen für wenige, bewusst überwachte Kategorien. Damit beides zuverlässig funktioniert, müssen Kategorie, Web Policy, Firewall-Regel, Logging und Mailversand zusammenpassen.

Das ist besonders nützlich in Schulen, sensiblen Unternehmensbereichen oder Umgebungen, in denen bestimmte Webzugriffe nicht erst im Monatsreport auffallen sollen.

Eine Kategorie allein verändert den Datenverkehr nicht. Erst eine Web Policy verwendet sie für eine Aktion, und erst die Zuordnung dieser Policy zu einer passenden Firewall-Regel bringt die Aktion in den produktiven Datenpfad. TLS Inspection, QUIC-Behandlung und Logging bestimmen zusätzlich, was die Firewall erkennen und später ausweisen kann.

Für die allgemeine Web-Policy-Planung passt zuerst Sophos Firewall Web Protection mit Web Policies einrichten. Für die Regelbasis hilft Sophos Firewall-Regeln verstehen und richtig konfigurieren. Dieser Artikel konzentriert sich auf den operativen Web-Teil: Kategorien, URL-Gruppen, Instant Alerts, Auswertung und Reaktion.

Orientierung und Voraussetzungen

Zuerst sollte klar sein, welche Web-Funktion welche Aufgabe übernimmt. Dadurch vermeidet man, dass Kategorien, URL-Gruppen, Web Policies und Instant Alerts später durcheinander geraten.

Begriffe sauber trennen

Sophos verwendet mehrere Web-Objekte, die im Alltag leicht vermischt werden.

• Web category: Kategorie für Domains, URLs oder Keywords. Viele Kategorien kommen von Sophos, eigene Kategorien sind möglich. Das passt, wenn Webzugriffe nach Risiko oder Inhalt erlaubt, blockiert, begrenzt oder gemeldet werden sollen.
• URL group: Liste mit Domains, die in Web Policies oder TLS-Ausnahmen verwendet werden kann. Das passt für explizite Allow- oder Blocklisten, wenn konkrete Domains wichtiger sind als Kategorien.
• Web policy: Regelwerk für Benutzer, Gruppen, Kategorien, URL-Gruppen, File types, Content filters und Aktionen. Damit werden Webzugriffe gesteuert und mit einer Firewall-Regel verbunden.
• Instant alerts: E-Mail-Benachrichtigung für Zugriffe auf überwachte Kategorien. Das passt für schnelle Meldungen bei besonders sensiblen oder risikoreichen Kategorien.
• Log Viewer und Reports: Auswertung der tatsächlichen Entscheidung. Damit kontrolliert man, ob Kategorie, Policy, Benutzer und Firewall-Regel wie erwartet greifen.

Eine Web Policy wirkt erst, wenn sie in einer passenden Firewall-Regel unter Security features > Web filtering ausgewählt ist. Die Web Policy allein ist also noch keine produktive Regel.

Wann Web-Kategorien sinnvoll sind

Web-Kategorien sind besonders nützlich, wenn Webzugriffe nicht nur allgemein erlaubt oder blockiert werden sollen. Typische Szenarien:

• Malware-, Phishing- und Betrugskategorien blockieren.
• Anonymizer, Proxies und Umgehungsdienste einschränken.
• Command-and-Control- oder Spyware-Kategorien besonders überwachen.
• Kategorien wie Adult content, Gambling oder Controlled substances je nach Umfeld sperren.
• Geschäftskritische Cloud-Anwendungen erlauben, aber private Cloud- oder Filesharing-Dienste einschränken.
• In Schulen oder betreuten Umgebungen besonders sensible Kategorien mit Instant Alerts überwachen.
• Bandbreite für bestimmte Web-Kategorien per Traffic shaping begrenzen.

Kategorien sollten nicht wahllos alle auf Block oder Alert gesetzt werden. Sonst entstehen viele Treffer, die niemand sinnvoll prüfen kann. Besser ist ein kleines, klares Set mit Owner, Reaktionsweg und Review.

Voraussetzungen

Vor der Konfiguration sollten diese Punkte geklärt sein:

• Web Protection oder ein passendes Sophos Firewall Bundle ist lizenziert.
• Es gibt eine Client- oder Benutzerregel, die Web Filtering verwenden soll.
• Benutzer- oder Gruppenmatching ist geplant, falls Policies benutzerbasiert greifen sollen.
• Log firewall traffic ist in der relevanten Firewall-Regel aktiv.
• Unter System services > Log settings ist mindestens Content filtering für Local reporting aktiviert; für Central Reporting oder Syslog wird derselbe Logtyp in der jeweiligen Zielspalte ausgewählt.
• E-Mail-Benachrichtigungen funktionieren, wenn Instant Alerts genutzt werden sollen.
• Das eingesetzte Modell unterstützt Instant Alerts; XGS 87 und XGS 88 unterstützen diese Funktion nicht.
• Für langfristige Auswertung ist Central Firewall Reporting oder Syslog geplant.
• QUIC und TLS Inspection sind bewusst entschieden.

Für zentrale Auswertung passt Central Firewall Reporting aktivieren. Wenn Logs an ein eigenes SIEM gehen sollen, ist Sophos Firewall Syslog an SIEM senden der bessere Anschlussartikel.

Policy-Design planen

Vor der technischen Konfiguration sollte feststehen, welche Kategorien wirklich gesteuert werden, welche nur gemeldet werden und wer auf Alerts reagiert. Ein kleines, sauberes Policy-Design ist meist besser als ein maximaler Katalog.

Kategorien und URL-Gruppen planen

Für Admins ist wichtig, wann eine eigene Web-Kategorie und wann eine URL-Gruppe besser passt.

Eine eigene Web-Kategorie ist sinnvoll, wenn:

• Domains oder Keywords als Kategorie in mehreren Web Policies verwendet werden sollen.
• die Kategorie in Reports und Logs bewusst sichtbar sein soll.
• ein Traffic-shaping-Konzept nach Kategorie geplant ist.
• eine überwachte Kategorie für Instant Alerts entstehen soll.

Eine URL-Gruppe ist meist besser, wenn:

• nur konkrete Domains gesammelt werden.
• eine kleine Allowlist oder Blocklist gebraucht wird.
• die Liste auch für TLS-Ausnahmen verwendet werden soll.
• Keyword-Matching vermieden werden soll.

URL-Gruppen sind bei reinen Domain-Matches direkter und leichter nachvollziehbar als Kategorien mit Keywords. Keyword-Kategorien nur in Blockregeln verwenden, nicht in Allow-Regeln: Query-Parameter können sonst eine unerwünschte Freigabe erzwingen.

Eine URL-Gruppe enthält gültige Domains. Reguläre Ausdrücke sind nicht erlaubt; die Einträge werden mit OR ausgewertet, ein einzelner Treffer genügt also. Die aktuelle SFOS-22-Hilfe nennt keine feste Maximalzahl. Das ist keine Zusage für unbegrenzte Listen. Wer grosse oder dynamisch gepflegte Listen benötigt, sollte prüfen, ob eine importierte Kategoriedatenbank oder ein Threat Feed fachlich besser passt.

Den vollständigen Erstellungs-, Web-Policy-, TLS- und Testablauf zeigt URL Groups erstellen und sicher verwenden.

Feste, dynamische und fehlende Kategorien unterscheiden

Die meisten integrierten Kategorien beruhen auf einem URL-Lookup. ActiveX, Applets, Cookies und HTTPUpload sind dagegen dynamische Kategorien: Die Firewall ordnet sie anhand der Inhaltsprüfung zu. Ein URL-Lookup allein bestätigt deshalb nicht, ob eine solche Inhaltsregel beim realen Zugriff greift. ALLWebTraffic bezeichnet sämtlichen HTTP-Traffic, nicht nur bisher unbekannte Webseiten.

None und Uncategorized sind unterschiedliche Ergebnisse: Bei None war der Lookup erfolgreich, die URL-Datenbank enthält aber keine Kategorieinformation. Bei Uncategorized ist der Lookup fehlgeschlagen. Vor einer Ausnahme wird deshalb geprüft, ob eine fehlende Datenbankzuordnung oder ein Kategorisierungsproblem vorliegt; keines der beiden Ergebnisse belegt eine ungefährliche Webseite.

Kategorien nach ihrer Bedeutung auswählen

Eine Kategorie ist kein allgemeines Sicherheitsurteil über alle Inhalte eines Dienstes. Für die Policy-Auswahl sind insbesondere diese Unterschiede wichtig:

• CRL and OCSP betrifft Zertifikatssperrprüfungen, Software updates die Aktualisierung gängiger Software. Diese Zugriffe werden normalerweise benötigt. Download freeware & shareware schliesst Betriebssystem-, Antivirus- und andere geschäftskritische Update-Seiten ausdrücklich nicht ein. Eine Download-Sperre darf Updates nicht versehentlich verhindern.
• Content delivery umfasst meist nachgeladene oder eingebettete Inhalte anderer Webseiten. Eine pauschale Sperre kann erlaubte Seiten beschädigen; vor einer Ausnahme den tatsächlichen Zielhost und die Hauptseite im Log prüfen.
• Command & control bezeichnet bekannte Malware-Steuerungsserver, Spyware & malware Seiten mit schädlichen Inhalten und Phishing & fraud unter anderem Betrugs- und Phishing-Seiten. Newly registered websites und Parked Domain sind dagegen Risikosignale, kein Beweis für Malware.
• Business cloud apps, Personal cloud apps und Personal network storage trennen geschäftliche Anwendungen, persönliche Cloud-Dienste und privaten Netzwerkspeicher. Freigaben nach Datenabflussrisiko und Geschäftsbedarf entscheiden, nicht allein nach dem Wort „Cloud“.
• Anonymizers und Translators können Filter umgehen; Image search, Portal sites und Suchmaschinen können Inhalte anderer Kategorien zugänglich machen. Eine erlaubte Hauptseite bedeutet daher nicht, dass alle eingebetteten Ziele erlaubt sein sollen.
• Live audio, Live video, Video hosting, Surveillance und Voice & video calls unterscheiden Streaming, Abrufvideo, Überwachung und Kommunikation. Ob Traffic shaping oder eine Sperre passt, hängt vom benötigten Dienst ab. Casino-, Hotel- und Resort-Webseiten fallen unter Travel, wenn sie weder Online-Glücksspiel noch Glücksspiel- oder Spieltipps anbieten. Der Hotelname allein belegt die Zuordnung nicht.

Kompaktes Glossar für Diagnose und sensible Umgebungen

• HTTPUpload betrifft HTTP-Upload-Beschränkungen und ist dynamisch; IPAddress betrifft Webseiten, die über IP-Adressen aufgerufen werden. Das sind verschiedene Regelfälle, keine Synonyme für fehlende Klassifizierung.
• Gambling umfasst Online-Glücksspiel und Lotterien mit echtem oder virtuellem Geld; Informationen und Ratschläge zu Wetten, Lotterieteilnahme, Glücksspiel und Zahlenwetten; virtuelle Casinos und Offshore-Glücksspielangebote; Sportwetten-Tipps und Wettpools sowie virtuelle Sport- und Fantasy-Ligen mit hohen Gewinnen oder erheblichen Wetteinsätzen. Games umfasst Seiten zum Spielen oder Herunterladen von Spielen, zum Hosten von Spielen oder Wettbewerben, mit Spieltipps und Cheat-Codes sowie Zeitschriften und Magazine zum Online-Spielen. Glücksspielangebote nicht mit allgemeinen Spielangeboten gleichsetzen; für Casino-, Hotel- und Resort-Seiten gilt weiterhin die oben beschriebene Travel-Abgrenzung.
• Pro-suicide & self-harm bezeichnet Seiten, die Suizid oder Selbstverletzung fördern. Schulen können mögliche Gefährdungen damit überwachen. Psychische Gesundheit, Hilfe und Unterstützung gehören nicht allein wegen des Themas hierher. Ein Treffer braucht menschliche Prüfung, keine automatische Incident-Feststellung.
• Sex education umfasst Bild- und Textinformationen zur sachgerechten Anwendung von Verhütungsmitteln, etwa Pille und Spirale, sowie Diskussionen darüber, wie man mit dem Partner über Krankheiten, Schwangerschaft und die Achtung persönlicher Grenzen spricht. Kommerzielle Seiten mit Sexualprodukten sind ausgenommen und gehören typischerweise zu Sexually explicit. Sexually explicit umfasst Erwachsenenprodukte wie Sexspielzeug, CD-ROMs und Videos; Darstellungen sexuellen Kindesmissbrauchs und pädophile Inhalte einschliesslich der IWF-Liste; Erwachsenendienste wie sexuelle Videokonferenzen, Escortdienste und Stripclubs; erotische Geschichten und Beschreibungen sexueller Handlungen; explizite Zeichentrickbilder und Animationen; sexuell explizite Gruppen und Foren; sexuell ausgerichtete oder erotische Seiten mit vollständiger oder teilweiser Nacktheit; Darstellungen sexueller Handlungen, auch mit Tieren oder sexuell verwendeten Gegenständen; sexuell ausbeuterische oder gewalttätige Texte und Bilder; Bondage, Fetische und Intimpiercings; Naturistenseiten mit Nacktheit sowie erotische oder Fetischfotografie mit Nacktheit. Informationen zu sexueller Gesundheit, Brustkrebs und sexuell übertragbaren Krankheiten sind ausgenommen, ausser wenn sie grafische Beispiele enthalten.
• Intolerance & hate umfasst Seiten, die zur Herabwürdigung oder zu Angriffen auf Bevölkerungsgruppen oder Institutionen wegen Religion, rassistischer Zuschreibungen, Nationalität, Geschlecht, Alter, Behinderung oder sexueller Orientierung aufrufen oder diese befürworten. Dazu gehören politische oder gesellschaftliche Programme, die eine Überlegenheit bestimmter Gruppen behaupten und andere anhand dieser Merkmale ausschliessen; Holocaustleugnung und andere hassfördernde Geschichtsrevisionen; Zwang oder Anwerbung zur Mitgliedschaft in kriminellen Banden oder Sekten; militante und extremistische Seiten sowie unverhohlen verletzende oder beleidigende Inhalte, auch solche ohne Respekt für andere Meinungen und Überzeugungen. Als Bande gilt hier eine Gruppe mit gemeinsamem Namen oder Erkennungszeichen, deren Haupttätigkeit schwere Straftaten sind und deren Mitglieder einzeln oder gemeinsam im Namen der Gruppe kriminell handeln. Als Sekte gilt hier eine ausserhalb der Gesellschaft stehende Gruppe, die Anhänger durch Täuschung, Manipulation und unzulässige Einflussnahme anwirbt und bindet, dadurch Persönlichkeit und Verhalten verändert und den Willen des Einzelnen einer allmächtigen Führung und einer allumfassenden Ideologie unterordnet. Nachrichten, historische Darstellungen und Presseberichte über solche Sachverhalte sind ausgenommen, ausser bei grafischen Beispielen. Berichterstattung ist nicht automatisch Befürwortung.
• Radio & audio hosting umfasst legitime Audio- und Musikinhalte auf Abruf; Spotify und Pandora sind Beispiele für solche Angebote, keine Zusage ihrer aktuellen URL-Klassifizierung. Live audio betrifft dagegen Live-Streams von Veranstaltungen oder Programmen. Online Chat umfasst webbasierten Chat und Instant Messaging; Voice & video calls betrifft Internettelefonie und Videoanrufe. Nach benötigter Kommunikationsform auswählen.
• Unauthorized software stores umfasst fragwürdige Software- und App-Verteilung für Computer und Mobilgeräte mit potenziell schädlichen oder mit Trojanern versehenen Downloads. Nicht jeder unfreigegebene Store ist nachweislich schädlich. Von benötigten, genehmigten Software updates für gängige Produkte unterscheiden.

Für sensible Kategorien nur harmlose, genehmigte Testfälle und kontrollierte Testressourcen verwenden, niemals illegale oder belastende Inhalte besuchen. Kategorie, Kontext und Fehlklassifizierung menschlich prüfen, bevor eine Eskalation erfolgt. Gewöhnliche thematische Katalogdefinitionen und historische Dienstbeispiele bleiben aus redaktionellen Gründen ausserhalb dieses Artikels; sie sind keine reine Navigation und werden nicht als vollständig übersetzte Taxonomie beansprucht.

Vor breiten Änderungen die bisherige Policy sichern und mit harmlosen, genehmigten Zielen sowohl den gewünschten Treffer als auch notwendige Updates und Zertifikatssperrprüfungen testen. Bei Ausfällen die betroffene Kategorieaktion zurücksetzen und die Tests wiederholen, statt Web Filtering insgesamt auszuschalten.

Generative AI als Web-Kategorie in SFOS 23.0

SFOS 23.0 dokumentiert Generative AI als integrierte Web-Kategorie für Webseiten und Dienste, mit denen Benutzer Inhalte durch Prompts erstellen oder umwandeln. Webseiten, deren Hauptzweck nicht generative KI ist, sind ausdrücklich ausgenommen. Eine zusätzliche KI-Funktion in einem anderen Dienst reicht deshalb nicht aus, um dessen Zuordnung zu dieser Kategorie vorauszusetzen. Die Kategorie ist keine Garantie, sämtliche KI-Nutzung zu erkennen.

Diese Sophos-URL-Klassifizierung wird über eine Web Policy genutzt. Sie ist von Anwendungssignaturen und der Anwendungskategorie Generative AI in Application Control zu unterscheiden. Eine eigene Web-Kategorie gleichen Namens synchronisiert sich nicht automatisch mit dem Anwendungskatalog. Auch eine selbst gepflegte Domainliste in einer URL-Gruppe oder eigenen Kategorie bleibt ein separates Objekt mit eigenem Owner und Review-Datum; sie ist nicht die integrierte Kategorie.

Vor einer breiten Sperre wird die Wirkung auf der eingesetzten Version in einem begrenzten Pilot geprüft:

1. Unter Web > Categories die Kategorie prüfen und für eine freigegebene, unbedenkliche Test-URL Diagnostics > URL category lookup verwenden. Der Lookup zeigt nur die Zuordnung, nicht den realen Policy-Entscheid; eine eigene Kategorie kann das angezeigte Ergebnis bestimmen.
2. Unter Web > Policies Kategorie, HTTP-/HTTPS-Aktion und Reihenfolge prüfen. Die Policy muss in der passenden Firewall-Regel unter Security features > Web filtering ausgewählt sein. Enable logging and reporting, Log firewall traffic und Content filtering unter System services > Log settings > Local reporting kontrollieren.
3. Den Policy tester mit einem kontrollierten realen Clientaufruf ergänzen und im Log Viewer verwendete Kategorie, Web Policy, Firewall-Regel und Aktion prüfen. Application-Control-Entscheide getrennt auswerten. Bei Abweichungen zuerst eigene Kategorien, Regelreihenfolge, Ausnahmen sowie TLS-/QUIC-Pfad prüfen, statt vollständige KI-Erkennung anzunehmen.

Die Auswahl zwischen Web-Kategorie, Application Filter und ergänzender Domainliste sowie den Pilotablauf erklärt Generative AI kontrollieren.

Block, Alert oder nur Reporting?

Nicht jede Kategorie braucht dieselbe Behandlung. Ein gutes Web-Protection-Design trennt harte Sicherheitsentscheidungen von Hinweisen und reiner Auswertung.

• Block: Sinnvoll für Malware, Phishing, bekannte Umgehungsdienste und klar verbotene Kategorien. Risiko: Eine legitime Seite kann blockiert werden, wenn die Kategorie falsch ist.
• Warn: Sinnvoll für Graubereiche, Schulungsumgebungen oder bewusst erlaubbare Kategorien. Risiko: Benutzer gewöhnen sich an Warnungen und klicken reflexartig weiter.
• Instant Alert: Sinnvoll für wenige Kategorien mit echter Reaktionspflicht. Risiko: Zu viele Alerts führen zu Alarmmüdigkeit.
• Reporting only: Sinnvoll für Trendanalyse, Nutzungsberichte und schwache Signale. Risiko: Treffer werden erst später sichtbar.

Für produktive Umgebungen ist oft eine kleine, klare Auswahl besser als ein maximaler Katalog. Wenn niemand einen Alert bewertet, sollte die Kategorie nicht als Instant Alert laufen. Wenn eine Kategorie immer blockiert werden soll, ist ein Alert zusätzlich nur dann sinnvoll, wenn daraus ein konkreter Follow-up entsteht.

Eine feste Systemgrenze gilt für Webseiten, die Sophos als besonders schwere kriminelle Inhalte einstuft: Die Firewall blockiert sie unabhängig von Web Policy oder Ausnahme und blendet den Domainnamen in Logs und Reports aus. Ein fehlender Domainname ist in diesem Fall daher kein Logging-Fehler.

Konfiguration

Die Konfiguration besteht aus vier Teilen: Kategorie oder URL-Gruppe, Web Policy, Firewall-Regel und optional Instant Alerts. Erst wenn diese Teile zusammenpassen, sieht man eine Wirkung im produktiven Traffic.

Web-Kategorie erstellen oder anpassen

Der Menüpfad lautet:

Web > Categories

Grundablauf:

1. Bestehende Kategorie bearbeiten oder Add wählen.
2. Namen vergeben.
3. Classification auswählen.
4. Optional eine Traffic shaping policy auswählen.
5. Configuration type wählen.
6. Domains oder Keywords hinzufügen.
7. Optional Instant alerts aktivieren.
8. Speichern.

Bei eigenen Kategorien sollte der Name den Zweck klar beschreiben. Namen wie Custom1 oder Blocklist helfen später kaum. Besser sind Namen wie Alert_Self_Harm, Block_Proxy_Anonymizer oder Allow_Business_Cloud_Exceptions.

Domains werden gegen den Domainnamen in der URL geprüft und umfassen automatisch Subdomains. Keywords werden dagegen gegen die vollständige URL inklusive Pfad und Query geprüft. Das kann hilfreich sein, erzeugt aber leichter falsche Treffer.

Wenn eine externe URL-Datenbank verwendet wird, prüft die Firewall diese Liste alle 48 Stunden auf Updates. Dieses Intervall kann nicht geändert werden. Für öffentliche Blocklisten sollte man trotzdem prüfen, ob Sophos Firewall Threat Feeds einrichten und sicher betreiben fachlich besser passt.

Eine eigene Kategorie ersetzt die Sophos-Standardkategorie einer URL nicht. Eine URL kann mehreren Kategorien angehören. Die Firewall wertet Kategorien in der Reihenfolge der Kategorienliste aus; Logs und Reports zeigen die Kategorie, die für den konkreten Policy-Entscheid verwendet wurde. Nach Änderungen an Einträgen oder Reihenfolge wird deshalb der reale Zugriff erneut geprüft.

Bei Local database sind höchstens 2,000 Einträge möglich. Eine lokale .txt-Datei enthält einen Eintrag pro Zeile, eine .csv-Datei die Einträge kommagetrennt in einer Zeile. External URL database akzeptiert eine per HTTP oder FTP erreichbare .txt-, .csv-, .tar-, .gz- oder .bz2-Datei, jedoch keine Anmeldung am Quellserver. Ungültige Einträge werden ignoriert.

Die Grösse des externen Caches hängt vom Arbeitsspeicher der Firewall ab. Sophos nennt für die meisten Modelle mit mehr als 4 GB RAM bis zu 122,880 Einträge. Die tatsächlich verfügbare Grenze wird in /log/nSXLd.log geprüft, bevor eine grosse Liste produktiv verwendet wird.

Einträge und Importe kontrollieren

Classification hilft beim Filtern und Verwalten der Kategorien. Traffic shaping policy legt Nutzungsgrenzen und die Bandbreite für Upload und Download fest; ohne gewünschte Begrenzung bleibt die Auswahl None. Der Configuration type ist zunächst Local. Unter Search/Add einen Eintrag eingeben und Add wählen oder mit Browse eine lokale Datei importieren. Für eine externe Datenbank wird dort stattdessen die Quell-URL hinzugefügt.

Domain-Einträge dürfen einen Pfad oder eine Query enthalten, etwa example.com/research oder example.com/search?q=report; ein Protokollpräfix wie https:// gehört nicht in den Domain-Eintrag. Das sind Syntaxbeispiele, keine freigegebenen Testziele. Keywords müssen mit einem Buchstaben, einer Ziffer oder _ beginnen. Ungültige Zeichen, ungültige Domain-Einträge und leere Zeilen werden verworfen. Bei mehr als 2,000 lokalen Einträgen werden nur die ersten 2,000 importiert. Archive für externe Datenbanken müssen Textdateien enthalten. Die externe Datenbank hat keine feste Eintragsobergrenze; das bedeutet ausdrücklich nicht, dass der RAM-abhängige Cache unbegrenzt ist.

Keine Keyword-Allowlist erstellen: Keyword-Prüfungen sind weniger effizient und erfassen auch Query-Parameter. Eine Allow-Kategorie mit dem Keyword research kann beispielsweise auch bei blocked.example/?tag=research treffen, obwohl die Domain selbst gesperrt sein sollte. Deshalb Keyword-Kategorien nur für Blockregeln verwenden, nicht als Freigabe. Für reine Domain-Freigaben passt eine URL-Gruppe besser. Vor dem Import Einträge und bisherige Policy dokumentieren; danach die gespeicherte Liste sowie einen erwarteten Treffer und Nichttreffer prüfen. Bei falschen Treffern die vorherigen Einträge wiederherstellen, statt die Sperren breit zu lockern.

Kategoriespezifische Blockseite

Unter Advanced settings > Override default notification page kann eine eigene Nachricht die Standardmeldung ersetzen, wenn diese Kategorie eine Webseite blockiert. Die Platzhalter {category}, {user} und {url} zeigen Kategorie, Benutzername und blockierte URL. Nur notwendige Angaben verwenden: Benutzer und URLs können sensible Informationen enthalten. Vorherige Nachricht und Einstellung sichern, anschliessend mit einem unbedenklichen, kontrolliert blockierten Testziel prüfen. Bei unpassender Anzeige den vorherigen Text oder die Standardseite wiederherstellen; die Änderung an der Meldung ist keine Freigabe der Webseite.

Web Policy konfigurieren

Der Menüpfad lautet:

Web > Policies

Eine Web Policy enthält Regeln für Benutzer, Gruppen, Aktivitäten, Kategorien, URL-Gruppen, File types, Content filters, Aktionen und Zeitpläne.

Grundablauf:

1. Neue Web Policy erstellen oder bestehende Policy bearbeiten.
2. Regel hinzufügen.
3. Benutzer oder Gruppen auswählen, falls die Policy benutzerbasiert sein soll.
4. Kategorien oder URL-Gruppen auswählen.
5. Aktion für HTTP festlegen.
6. Separate Aktion für HTTPS prüfen.
7. Zeitplan festlegen, falls nötig.
8. Unter Advanced settings die Option Enable logging and reporting aktivieren, wenn die Policy in Logs und Reports erscheinen soll.
9. Status der Regel aktivieren.
10. Regelposition prüfen.
11. Speichern.

Enable logging and reporting in der Web Policy und Log firewall traffic in der Firewall-Regel erfüllen unterschiedliche Aufgaben. Für eine nachvollziehbare Auswertung sollte man beide bewusst prüfen.

Die Reihenfolge innerhalb der Web Policy ist entscheidend. Regeln werden von oben nach unten ausgewertet. Eine breite Allow-Regel oberhalb einer spezifischen Blockregel kann dazu führen, dass die Blockregel nie greift.

Wenn Benutzer in der Firewall-Regel und in der Web Policy gesetzt sind, muss man die Wirkung bewusst testen. Benutzer in Firewall-Regeln können Vorrang vor Benutzern in Web Policies haben. Bei unklaren Treffern sollte man deshalb nicht nur die Web Policy, sondern auch die Firewall-Regel prüfen.

Web Policy in Firewall-Regel aktivieren

Der Menüpfad lautet:

Rules and policies > Firewall rules > [Rule] > Security features > Web filtering

Grundablauf:

1. Relevante Client- oder Serverregel öffnen.
2. Source zone, Source network, Destination zone und Services kontrollieren.
3. Log firewall traffic aktivieren.
4. Unter Web filtering die gewünschte Web Policy auswählen.
5. Block QUIC protocol bewusst aktivieren oder begründet deaktivieren.
6. Malware Scan und HTTPS-Scan-Einstellungen prüfen.
7. Speichern.
8. Mit Policy tester, Log Viewer und realem Clienttraffic testen.

QUIC ist für Webfiltering ein häufiger Störfaktor. Wenn Browser über UDP 443 kommunizieren, passen Logik und Sichtbarkeit nicht immer zur Erwartung an klassisches HTTPS über TCP. Für Details passt Sophos Firewall QUIC und HTTP/3 richtig blockieren.

Wenn HTTPS-Inhalte oder vollständige URL-Pfade relevant sind, reicht Web-Kategorisierung allein nicht immer aus. Dann muss TLS Inspection geplant werden. Das sollte nicht nebenbei passieren, weil Zertifikate, Ausnahmen, Datenschutz, Performance und Supportprozesse betroffen sind. Der Rollout ist in Sophos Firewall TLS Inspection richtig einführen beschrieben.

Beispiel: Kategorien nur für eine Forschungsgruppe freigeben

Eine begrenzte Gruppenausnahme ist sicherer als eine allgemeine Allow-Regel. Vorher die bestehende Policy, Firewall-Regelposition und Gruppeneinstellungen dokumentieren und sicherstellen, dass die Testbenutzer korrekt erkannt werden. Die Namen Research, Web categories und Web research group sind frei wählbare Beispiele.

1. Unter Authentication > Groups > Add die Gruppe Research anlegen. Surfing quota und Access time bewusst wählen und Save klicken. Unlimited internet access und Allowed all the time sind mögliche Beispielwerte, aber keine Voraussetzung für eine Kategorieausnahme: Unbegrenzte Nutzung und ganztägiger Zugriff benötigen eine eigene Freigabe.
2. Unter Web > Policies > Add policy eine Policy Web categories anlegen und Add rule wählen. Die neue Regel steht oben, ist zunächst ausgeschaltet und würde mit ihrer Voreinstellung sämtlichen HTTP-Traffic für alle Benutzer blockieren. Vor dem Aktivieren die Auswahl ändern.
3. Im Feld Activities auf All web traffic > Add new item gehen, All web traffic abwählen und unter Show only > Web category nur die freigegebenen Kategorien wählen. Mit Apply selected items übernehmen.
4. Im Feld Action Allow HTTP wählen, die separate HTTPS-Aktion bewusst prüfen, Status einschalten und speichern. Logging und die übrigen Regeln dürfen nicht versehentlich entfallen.
5. Unter Rules and policies > Firewall rules die passende IP-Familie IPv4 oder IPv6 wählen und Add firewall rule verwenden. Die Regel Web research group auf die benötigten Quellnetze, Zonen, Ziele und Services begrenzen. Bei der Benutzer-/Gruppenauswahl Add new item verwenden, Any abwählen, Research wählen und Apply selected items klicken. Die Policy unter Security features > Web filtering zuordnen.
6. Nach Save die Regel mit dem Drag-Handle vor die allgemeine Arbeitsplatzregel verschieben, nicht ungeprüft vor andere Sicherheitsregeln. Mit einem Gruppenmitglied und einem Nichtmitglied testen: Nur die freigegebene Gruppe soll die genehmigte Kategorie erreichen; andere Kategorien und Benutzer müssen weiter der vorgesehenen Grundpolicy folgen. Regel-ID, Kategorie und Aktion im Log Viewer bestätigen.

Bei unerwarteten Freigaben die neue Gruppenausnahmeregel deaktivieren und die dokumentierte Reihenfolge beziehungsweise Policy-Zuordnung wiederherstellen. Anschliessend beide Benutzertests wiederholen. Gruppenzugehörigkeit allein ist kein Nachweis, dass auch die richtige Firewall-Regel getroffen wurde.

Die dokumentierte Schritt-für-Schritt-Anleitung bezeichnet die Benutzerzuordnung als Identity und die Policy-Auswahl als Advanced. Die Abschnittsnamen können je nach Oberfläche abweichen. Entscheidend sind die eingeschränkte Benutzer-/Gruppenauswahl und die Web-Policy-Zuordnung unter Web filtering auf der eingesetzten Version; bei unklarer Zuordnung die Ausnahme nicht aktivieren.

Instant Alerts aktivieren

Instant Alerts werden auf Kategorieebene aktiviert. Sie sind standardmässig für alle Kategorien ausgeschaltet. Das Filtersymbol neben Instant alerts in Web > Categories hilft, die überwachten Kategorien gezielt anzuzeigen und zu kontrollieren.

Der Menüpfad lautet:

Web > Categories

Grundablauf:

1. Kategorie bearbeiten.
2. Kategorie bewusst für die Überwachung auswählen.
3. Instant alerts aktivieren.
4. Speichern.
5. System services > Notifications list öffnen.
6. Oben Email notifications aktivieren.
7. Web – Instant alerts suchen.
8. Checkbox unter Email aktivieren.
9. Unter Administration > Notification settings Mailserver, Absender und Empfänger prüfen.
10. Testzugriff erzeugen und die nächste Fünf-Minuten-Sammelmail kontrollieren.

Die Firewall sendet E-Mail-Benachrichtigungen für überwachte Kategorien in Batches alle fünf Minuten. Dieses Intervall kann nicht geändert werden. Ein Alert ist deshalb kein sekundengenauer Echtzeit-Alarm, sondern eine schnelle E-Mail-Benachrichtigung im Vergleich zu rein nachgelagerten Reports.

Auf XGS 87 und XGS 88 stehen Instant Alerts nicht zur Verfügung. Fehlt die Funktion auf einem dieser Modelle, ist das daher keine fehlerhafte Mail- oder Notification-Konfiguration.

Instant Alerts sollten nur für Kategorien aktiviert werden, bei denen ein definierter Empfänger tatsächlich reagieren kann. Eine grosse Alertliste ohne Verantwortlichkeit führt meistens zu Alarmmüdigkeit.

Auswertung und Betrieb

Nach der Aktivierung zählt nicht nur, ob die Policy technisch greift. Entscheidend ist auch, wer Treffer sieht, wie Alerts bewertet werden und ob Logs für spätere Analyse verfügbar sind.

Datenschutz und interne Zuständigkeit

Web-Kategorie-Alerts können Benutzer, Quell-IP, Zeitpunkt, Kategorie und je nach Sichtbarkeit auch Zielinformationen enthalten. Das ist für Sicherheit und Betrieb nützlich, kann aber je nach Organisation arbeitsrechtliche oder datenschutzbezogene Fragen auslösen.

Vor produktivem Einsatz sollte deshalb geklärt sein:

• Wer darf Web-Alerts sehen?
• Welche Treffer werden nur technisch geprüft und welche werden als Sicherheitsfall behandelt?
• Wie lange werden Alert-E-Mails, Reports oder SIEM-Events aufbewahrt?
• Wird die Auswertung mit HR, Datenschutz oder internen Richtlinien abgestimmt?
• Wie verhindert man, dass einzelne harmlose Treffer überinterpretiert werden?

Technisch ist die Einstellung schnell aktiviert. Operativ sollte sie aber wie ein kleiner Monitoring-Prozess behandelt werden: Empfänger, Zweck, Reaktionsweg und Aufbewahrung müssen zusammenpassen.

Alert-Triage festlegen

Instant Alerts sollten nicht alle gleich behandelt werden. Ein einzelner Kategorie-Treffer kann ein harmloser Fehlklick, ein falsch klassifizierter Dienst, ein Policy-Problem oder ein echter Sicherheitsfall sein. Deshalb sollte vorab definiert werden, welche Treffer sofort geprüft werden und welche nur in den normalen Review gehen.

Eine einfache Triage hilft:

• Hoch: Malware, Phishing, Command-and-Control, Exploit- oder Spyware-Kategorien. Zeitnah Log Viewer, Benutzer, Endpoint-Status und weitere Security-Logs prüfen.
• Mittel: Anonymizer, Proxy, Filesharing, private Cloud-Speicher oder wiederholte Policy-Umgehung. Muster prüfen, Benutzerkontext klären und Policy nachschärfen.
• Niedrig: Einzelne Graubereiche ohne Wiederholung. In Reporting oder Wochenreview aufnehmen, nicht sofort eskalieren.
• Fehlalarm: Geschäftlich notwendige Seite ist falsch kategorisiert. Gezielte URL-Gruppe oder Kategorieanpassung prüfen, keine breite Allow-Regel setzen.

Diese Einordnung sollte nicht nur im Kopf eines Admins existieren. Sinnvoll ist eine kurze Betriebsnotiz: überwachte Kategorien, Empfänger, Reaktionszeit, Eskalationsweg, erlaubte Ausnahmen und Review-Datum. Dadurch bleibt klar, ob ein Alert nur dokumentiert, technisch korrigiert oder als Incident behandelt werden soll.

URL Category Lookup vor dem Policy-Test verwenden

Mit einer aktiven Web-Protection-Subscription zeigt Diagnostics > URL category lookup, welcher Kategorie Sophos eine konkrete URL zuordnet. Dazu trägt man die vollständige Test-URL unter Search URL ein und klickt auf Search. Das Ergebnis nennt Kategoriename und Beschreibung. Gehört die URL gleichzeitig zu einer eigenen und einer Standardkategorie, zeigt die Suche die eigene Kategorie an.

Der Lookup bestätigt nur die Kategorisierung. Er beweist nicht, welche Firewall-Regel oder Web Policy ein realer Client trifft, ob eine Ausnahme greift oder wie TLS, QUIC und der tatsächliche Traffic-Pfad wirken. Nach dem Lookup folgen deshalb Policy tester, ein kontrollierter Clientaufruf und die Auswertung im Log Viewer.

Testen und auswerten

Nach jeder Änderung sollte man nicht nur speichern, sondern die Wirkung prüfen.

Sinnvolle Prüfschritte:

1. Diagnostics > Tools > Pop-out tools > Policy tester öffnen. Alternativ führt Web > Policies > Policy tester zum selben Werkzeug.
2. URL, Benutzer, Zeitpunkt, Source IP und Source zone angeben und Firewall, SSL/TLS, and web testen. Web policy only prüft dagegen bewusst keine Firewall-Regel.
3. Auf einem Testclient eine passende Webseite aufrufen.
4. Log viewer öffnen.
5. Webfilter-, Firewall-, SSL/TLS-inspection- und Application-Control-Logs prüfen.
6. In der Firewall-Regel kontrollieren, ob der Treffer auf der erwarteten Regel liegt.
7. Bei Instant Alerts den E-Mail-Eingang prüfen.
8. In Sophos Fusion (ehemals Sophos Central) oder SIEM kontrollieren, ob die Ereignisse dort ankommen.

Der Policy tester arbeitet mit transparentem Web-Traffic und berücksichtigt keine SD-WAN-Routen. Er ersetzt deshalb keinen echten Paketfluss. Wenn eine Regel nicht matcht, eine SD-WAN-Route anders entscheidet oder TLS/QUIC den Pfad verändert, sieht man das oft erst im Log Viewer oder Packet Capture. Für solche Fälle passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Für die Zuordnung der Logdateien hilft Sophos Firewall Troubleshooting: Services und Logs. Dort sind unter anderem awarrenhttp.log, webproxy.log und nSXLd.log für Web- und Kategorisierungsfragen eingeordnet.

Reaktion auf Instant Alerts festlegen

Ein Instant Alert ist nur hilfreich, wenn danach klar ist, was passieren soll. Sonst entsteht zusätzlicher E-Mail-Verkehr, aber keine bessere Sicherheit. Vor der Aktivierung sollte deshalb ein einfacher Reaktionsablauf definiert werden.

Für jeden überwachten Kategorie-Typ sollte mindestens feststehen:

• Wer erhält den Alert? Das verhindert Verteiler ohne Verantwortlichkeit.
• Wie schnell muss reagiert werden? Das trennt kritische Treffer von reiner Nachbearbeitung.
• Welche Logs werden geprüft? Log Viewer, Central Reporting, Syslog oder Service-Logs liefern unterschiedliche Tiefe.
• Wann ist ein Treffer ein Incident? Nicht jeder Kategorie-Treffer ist automatisch ein Sicherheitsvorfall.
• Wer darf eine Ausnahme freigeben? Das verhindert schnelle, breite Allow-Regeln ohne Risikoabwägung.
• Wann wird die Kategorieauswahl überprüft? Das reduziert Alarmmüdigkeit durch zu breite Alert-Sets.

Ein pragmatischer Ablauf sieht so aus:

1. Alert mit Benutzer, Quell-IP, Kategorie, URL oder Domain und Zeitpunkt erfassen.
2. Im Log Viewer kontrollieren, welche Firewall-Regel und Web Policy gegriffen haben.
3. Wenn vorhanden, Central Reporting oder SIEM zur zeitlichen Einordnung nutzen.
4. Einordnen, ob es ein Einzelfall, ein wiederholtes Muster oder ein Fehlalarm ist.
5. Bei Fehlkategorisierung nur gezielt mit URL-Gruppe oder Kategorieanpassung arbeiten.
6. Bei auffälligem Muster Benutzerkontext, Endpoint-Status und weitere Security-Logs auswerten.
7. Entscheidung dokumentieren: ignorieren, beobachten, blockieren, Ausnahme, Incident.

Für technische Detailanalyse helfen Sophos Firewall Troubleshooting: Services und Logs, Central Firewall Reporting aktivieren und Sophos Firewall Syslog an SIEM senden. Wenn unklar ist, ob die richtige Firewall-Regel getroffen wurde, passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Betriebsempfehlung

Für produktive Umgebungen ist ein dreistufiges Modell sinnvoll:

1. Blockieren: Malware, Phishing, Betrug, Command-and-Control, Anonymizer und andere klar riskante Kategorien blockieren.
2. Überwachen: wenige sensible Kategorien mit Instant Alerts versehen.
3. Auswerten: Web-Reports, Central Reporting oder SIEM regelmässig prüfen.

Die wichtigste Grenze ist organisatorisch: Ein Alert braucht einen Empfänger, eine Reaktionszeit und eine Entscheidung, was mit Treffern passiert. Sonst wird aus Instant Alerts nur zusätzlicher E-Mail-Lärm.

Checkliste

• Web Protection Lizenz geprüft.
• Relevante Firewall-Regel identifiziert.
• Web Policy erstellt oder angepasst.
• Web Policy in der Firewall-Regel ausgewählt.
• Log firewall traffic in der Regel aktiviert.
• Block QUIC protocol bewusst entschieden.
• TLS Inspection bewusst geplant oder bewusst nicht eingesetzt.
• Kritische Kategorien definiert.
• Instant Alerts nur für wenige klare Kategorien aktiviert.
• System services > Notifications list > Web – Instant alerts per E-Mail aktiviert.
• Test mit Policy tester durchgeführt.
• Test mit echtem Clienttraffic durchgeführt.
• Log Viewer geprüft.
• Central Reporting oder Syslog geprüft, falls zentrale Auswertung erwartet wird.
• Owner und Reaktionsweg für Alerts dokumentiert.

Änderungen sicher zurücknehmen

Vor dem Umbau sollte man den bisherigen Kategorienstatus, die Web Policy und die Zuordnung in der Firewall-Regel dokumentieren. Dann lässt sich gezielt zurückrollen, statt Web Filtering pauschal abzuschalten.

1. Soll nur die Benachrichtigung enden, unter Web > Categories bei der betroffenen Kategorie Instant alerts deaktivieren. Email notifications nicht global ausschalten, wenn andere Systemmeldungen diesen Kanal verwenden.
2. Wurden Kategorieeinträge oder die Policy-Reihenfolge geändert, die dokumentierten Einträge und Positionen wiederherstellen.
3. Wurde die Web Policy in der Firewall-Regel neu zugeordnet, unter Rules and policies > Firewall rules > [Rule] > Security features > Web filtering die vorherige Policy wieder auswählen.
4. Den ursprünglichen Test im Policy tester und auf dem Testclient wiederholen und die erwartete Aktion im Log Viewer bestätigen.

Eine bereits erzeugte Sammelmail kann wegen des Fünf-Minuten-Intervalls noch nach der Rücknahme eintreffen. Entscheidend ist, dass ein neuer kontrollierter Zugriff wieder die dokumentierte Policy-Aktion erhält. Wurde Instant alerts deaktiviert, darf er keine weitere Web-Instant-Alert-Sammelmail auslösen.

Troubleshooting

Wenn Web-Kategorien oder Instant Alerts nicht wie erwartet funktionieren, liegt die Ursache meistens bei der Zuordnung zwischen Firewall-Regel, Web Policy, Benutzererkennung, QUIC, TLS Inspection oder Benachrichtigung.

Typische Fehler

• Web Policy greift nicht: Die Policy ist nicht in der Firewall-Regel ausgewählt. Firewall-Regel unter Web filtering prüfen.
• Kategorie wird erlaubt, obwohl sie blockiert sein sollte: Eine breite Allow-Regel steht oberhalb der Blockregel. Reihenfolge in Web Policy und Firewall-Regeln prüfen.
• Kein Instant Alert: Kategorie ist nicht überwacht, Email notifications ist global aus oder beim Ereignis fehlt die Checkbox unter Email. Web > Categories, System services > Notifications list und danach Administration > Notification settings prüfen.
• Keine Benutzerangabe im Log: Benutzer wird nicht erkannt oder die Regel matcht nicht benutzerbasiert. Authentifizierung, STAS, Captive Portal oder Clientless User prüfen.
• HTTPS wird unerwartet erlaubt: Es fehlt eine passende TLS Inspection oder HTTPS-Aktion. Web Policy, SSL/TLS inspection rules und Decryption prüfen.
• Webfilter wirkt unvollständig: QUIC oder ein falscher Traffic-Pfad kann die Ursache sein. Block QUIC protocol, Services und Log Viewer prüfen.
• Zu viele Alerts: Kategorien sind zu breit gewählt. Alertliste reduzieren und Owner festlegen.
• Domain in Log/Report fehlt: Besonders kritische Kategorie wird anonymisiert. Kategorie und Sophos-Verhalten prüfen.

Sophos blockiert Webseiten der Kategorie highly objectionable criminal activity grundsätzlich und blendet den Domainnamen in Logs und Reports aus. Wenn ein Eintrag in diesem Bereich anonymisiert erscheint, kann dies also beabsichtigt sein.

FAQ