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 sollten deshalb zurückhaltend verwendet werden, besonders für Allow-Regeln.

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.

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.

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.

Instant Alerts aktivieren

Instant Alerts werden auf Kategorieebene aktiviert.

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