Sophos Firewall Web Protection mit Web Policies einrichten

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

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

Welcher Web-Protection-Artikel passt?

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

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

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

Was Web Protection kontrolliert

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

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

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

Voraussetzungen

Vor dem Rollout sollten diese Punkte geklärt sein:

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

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

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

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

Minimalpfad zur wirksamen Web Policy

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

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

Web Policy planen

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

Zielgruppen definieren

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

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

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

Kategorien und URL Groups festlegen

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

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

Typische Verwendung:

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

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

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

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

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

Allow-Regeln vorsichtig setzen

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

Praktisch bewährt sich:

Eine Business-Freigabe oberhalb kritischer Blockregeln gilt nur für ihren eng definierten Scope. Soll eine Risikokategorie ausnahmslos blockiert bleiben, steht ihr Block oberhalb aller passenden Allow-Regeln. Die Reihenfolge wird mit einem erlaubten Business-Ziel und einem gesperrten Ziel innerhalb des Ausnahme-Scope geprüft; eine Domainfreigabe darf nicht versehentlich jede Dateiart oder jeden Inhalt dieses Ziels freigeben.

• Warn- oder Quota-Regeln für Graubereiche.
• Allgemein erlaubter Webtraffic erst am Ende.

Web Policy erstellen

Die Web Policy wird unter folgendem Menü erstellt:

Web > Policies

Grundablauf:

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

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

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

In Users > Add new item wird Anybody abgewählt, wenn nur bestimmte Benutzer oder Gruppen gemeint sind. In Activities > Add new item wird All web traffic abgewählt, bevor einzelne Activities ausgewählt werden. Jede Auswahl mit Apply selected items übernehmen. Sonst bleibt die Regel trotz zusätzlicher Einzelobjekte unnötig breit. Die HTTP-Aktionen heissen Allow HTTP, Warn HTTP, Block HTTP und Quota HTTP; Use action übernimmt für HTTPS dieselbe Entscheidung. Bei Content filters ist diese Kopplung fest und lässt sich nicht durch eine abweichende HTTPS-Aktion ersetzen.

Content-Filter-Listen sauber importieren

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

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

Sicherer Ablauf:

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

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

Für den Import konkret Add content filter wählen, den Namen eingeben, über Choose file etwa blocked.txt auswählen und Apply klicken. In der Web-Policy-Regel danach ausdrücklich Block HTTP und für HTTPS Use action kontrollieren, den Filter über Apply selected items übernehmen, Status einschalten und die Policy speichern. Das Importieren allein aktiviert keinen Block. Für den Pilot eignet sich eine eigene, zugewiesene Policy besser als eine unkontrollierte Änderung der gemeinsam verwendeten Default Policy.

Eigene Web-Dateitypen erstellen

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

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

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

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

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

Referenz der eingebauten Dateitypen

Die folgende Referenz ordnet die dokumentierten Endungen und MIME-Header den eingebauten Kategorien zu. Sie beschreibt eine Klassifizierung, keine erlaubte oder sichere Datei. Vor Änderungen die Werte der eigenen Installation gegenprüfen. All executable files deckt über zusätzliche MIME-Header auch Mac-/Linux-Ausführungsdateien ab; Executable files ist auf Windows ausgerichtet. Dynamic files erzeugen dynamische Webinhalte, Encoded files umfassen unter anderem verschlüsselte oder binär kodierte Inhalte. Kategorien können sich überschneiden: mdf steht beispielsweise bei Datenbanken und Disk Images, tar bei Dokumenten und tar.gz bei komprimierten Dateien. Insbesondere application/octet-stream bei Backup files ist ein generischer MIME-Wert, kein sicherer Nachweis für eine Backup-Datei.

All executable files

• Endungen: exe, cmd, bat, com.
• MIME-Header: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec, application/x-mach-binary, application/x-executable.

Audio files

• Endungen: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, ram, mp3, wmv.
• MIME-Header: audio/x-gsm, audio/vnd.qcelp, audio/x-midi, application/x-midi, audio/midi, audio/x-mid, x-music/x-midi, audio/basic, audio/x-adpcm, audio/aiff, audio/x-aiff, audio/x-mpequrl, audio/wav, audio/x-wav, application/vnd.rn-realmedia, audio/x-au, audio/x-pn-realaudio, audio/mpeg3, audio/x-mpeg-3, audio/x-ms-wmv, audio/ac3, audio/x-ape, audio/flac, audio/mpeg, audio/mp4, audio/ogg.

Backup files

• Endungen: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• MIME-Header: application/octet-stream.

Compressed files

• Endungen: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• MIME-Header: application/x-7z-compressed, application/x-alz, application/x-deb, application/x-gzip, application/x-newton-compatible-pkg, application/x-rar-compressed, application/sea, application/x-sea, application/x-sit, application/x-stuffit, application/gnutar, application/x-compressed, application/x-zip-compressed, application/zip, multipart/x-zip.

Configuration files

• Endungen: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• MIME-Header: application/pics-rules, application/vnd.ms-officetheme.

Database files

• Endungen: accdb, db, mdsn, mdb, mdf, pdb, sql, sqlite.
• MIME-Header: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Endungen: rb, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj, asc, cbl, cp, cpp, csproj, dev, fs, fsproj, fsx, ftl, gem, hpp, ise, ism, java, ocx, pas, pod, r.
• MIME-Header: text/pascal, application/x-bsh, application/x-sh, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl, application/x-shar.

Disk image files

• Endungen: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• MIME-Header: application/x-cdlink.

Document files

• Endungen: doc, docx, wbk, xls, xlsx, ppt, pptx, oft, pub, msg, one, xsf, xsn, grv, mpp, mpt, acl, pip, bld, blg, bvp, cdd, cdf, contact, csv, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vdb, odt, opml, pages, rtf, sig, tex, wpd, wps, pdf.
• MIME-Header: application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document, application/excel, application/vnd.ms-excel, application/x-excel, application/x-msexcel, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/mspowerpoint, application/powerpoint, application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/x-mspublisher, application/onenote, application/vnd.ms-project, application/x-project, application/cdf, application/x-cdf, application/x-netcdf, video/x-dv, application/x-hdf, application/mcad, application/x-mathcad, application/vnd.openxmlformats-officedocument.presentationml.slideshow, application/vnd.ms-powerpoint.presentation.macroEnabled.12, image/vnd.dwg, image/x-dwg, application/x-tar, text/x-vcard, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf, application/vnd.oasis.opendocument.graphics, application/vnd.oasis.opendocument.presentation, application/vnd.oasis.opendocument.formula, application/vnd.oasis.opendocument.text, application/vnd.oasis.opendocument.spreadsheet, application/vnd.ms-excel.addin.macroEnabled.12, application/vnd.ms-excel.sheet.binary.macroEnabled.12, application/vnd.ms-excel.sheet.macroEnabled.12, application/vnd.ms-excel.template.macroEnabled.12, application/vnd.ms-powerpoint.addin.macroEnabled.12, application/vnd.ms-powerpoint.slideshow.macroEnabled.12, application/vnd.ms-powerpoint.template.macroEnabled.12, application/vnd.ms-word.document.macroEnabled.12, application/vnd.ms-word.template.macroEnabled.12, application/vnd.openxmlformats-officedocument.presentationml.template, application/vnd.openxmlformats-officedocument.spreadsheetml.template, application/vnd.openxmlformats-officedocument.wordprocessingml.template.

Dynamic files

• Endungen: jsp, asp, php, cgi, shtml.
• MIME-Header: text/x-script.perl, text/asp.

Encoded files

• Endungen: bin, enc, hex, hqx, mim, mime, uue.
• MIME-Header: application/mac-binary, application/macbinary, application/x-binary, application/x-macbinary, application/binhex, application/binhex4, application/mac-binhex, application/mac-binhex40, application/x-binhex40, application/x-mac-binhex40, message/rfc822, www/mime, text/x-uuencode.

Executable files

• Endungen: exe, cmd, bat, com.
• MIME-Header: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec.

Image files

• Endungen: bmp, gif, jpeg, jpg, pcx, png.
• MIME-Header: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/jp2, image/vnd.adobe.photoshop, image/tiff.

Page layout files

• Endungen: idml, indd, inx, isd, mdi, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
• MIME-Header: application/x-mspublisher, application/vnd.ms-xpsdocument.

Plugin files

• Endungen: 8bi, arx, plugin, vst, xll.
• MIME-Header: application/x-visio.

System files

• Endungen: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, key, lnk, msp, prf, profile, scf, scr, sys.
• MIME-Header: application/vnd.ms-cab-compressed, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp.

Video files

• Endungen: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, rm, wmv, flv, swf.
• MIME-Header: application/x-troff-msvideo, video/avi, video/msvideo, video/x-msvideo, video/quicktime, application/smil, application/x-simile, Video/flc, video/fli, video/x-fli, video/mpeg, video/x-mpeg, video/x-mpeq2a, application/vnd.rn-realmedia, video/flv, application/x-shockwave-flash, video/x-flv, video/x-ms-asf, video/3gpp, video/mp4, video/mj2.

Web files

• Endungen: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• MIME-Header: application/atom+xml.

User Activities sauber bündeln

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

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

Im Dialog einen sprechenden Namen wie RISK_WEB_CONTENT setzen, über Add new item die benötigten Kategorien, Dateitypen oder URL Groups auswählen und mit Save speichern. Show: All begrenzt bei Bedarf die angezeigten Objekttypen. Beispielsweise kann eine Aktivität die Kategorie Spyware/Malware und eine eigene Liste gesperrter Testdomains bündeln: Schon eines dieser Kriterien löst die Block-Aktion der Policy-Regel aus. Für Tests harmlose, selbst kontrollierte Ziele verwenden, keine echte Malware-Seite öffnen.

Regelreihenfolge und migrierte Policies prüfen

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

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

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

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

Zusammengeführt werden nur benachbarte Regeln mit gleicher Benutzerzuordnung, HTTP-/HTTPS-Aktion und denselben zeitlichen Bedingungen. Unterschiede bei Content filters, Constraints oder Reihenfolge dürfen nicht verloren gehen. Vor dem Zusammenführen die Alt-Policy sichern beziehungsweise dokumentieren und repräsentative Treffer sowie Nicht-Treffer je Activity festhalten. Nach dem Zusammenführen diese Entscheidungen erneut prüfen; eine niedrigere Regelanzahl allein beweist keine gleichwertige Schutzwirkung.

Advanced settings gezielt setzen

Enable logging and reporting nimmt die Policy in Logs und Reports auf; zusätzlich bleibt Log firewall traffic in der getroffenen Firewall-Regel nötig. Prevent downloading of large files blockiert Downloads oberhalb der eingetragenen Grösse. Den Grenzwert nach den tatsächlich benötigten Business-Downloads wählen und mit harmlosen Dateien unterhalb und oberhalb des Werts prüfen; diese Download-Sperre ist nicht dasselbe wie ein Malware-Scan-Grössenlimit.

Add X-Forwarded-For header to outgoing HTTP requests gibt die IP-Adresse des ursprünglichen HTTP-Requests an das Ziel weiter. Das ist kein notwendiger Haken für Webfiltering. Nur bei einem begründeten Bedarf aktivieren, weil der Zielserver dadurch zusätzliche Clientinformationen erhält; Weitergabe interner Adressen und Datenschutzanforderungen vorher bewerten. Für den Pilot die bisherigen Werte dokumentieren und bei unerwünschten Effekten genau diese Änderungen zurücksetzen.

Web Policy in Firewall-Regel aktivieren

Die Firewall-Regel liegt unter:

Rules and policies > Firewall rules

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

Prüfpunkte in der Firewall-Regel:

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

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

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

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

HTTPS, TLS Inspection und QUIC einordnen

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

DPI oder Web Proxy?

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

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

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

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

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

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

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

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

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

TLS Inspection

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

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

QUIC und HTTP/3

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

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

SafeSearch, YouTube und Tenant Restrictions

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

Typische Optionen:

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

Die XML-API-Referenz für SFOS 22/23 beschreibt EnforceSafeSearch als nur anwendbar, wenn die Kategorien Adult Content, Nudity und Porn in der Web Policy verweigert werden. Diese Entscheidungen in der tatsächlich zugewiesenen Policy prüfen; der aktivierte Schalter sowie Proxy- und HTTPS-Scanning-Voraussetzungen allein belegen diese dokumentierte Bedingung nicht. Die Voraussetzungen können je Build abweichen. Falls die Hilfe des installierten Builds abweicht, die Abweichung klären, bevor man sich auf SafeSearch verlässt.

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

Unter Apply Microsoft Entra ID tenant restrictions enthält Restrict-Access-To-Tenants die erlaubten Tenants als kommagetrennte Liste von Domainnamen oder Domain-IDs, maximal 256 Zeichen insgesamt. Restrict-Access-Context enthält die Domain-ID des Tenants, der die Einschränkung festlegt, maximal 50 Zeichen. Diese Werte aus der eigenen Tenantverwaltung übernehmen, nicht aus einer fremden Beispielkonfiguration. Vorher die bestehenden Werte sichern; danach eine erlaubte und eine nicht erlaubte Tenant-Anmeldung im Pilot prüfen und bei Fehlern nur die geänderten Werte auf den Vorzustand setzen.

Quota und Warnseiten

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

Sinnvolle Beispiele:

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

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

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

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

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

Beim Aufruf eines Ziels mit Quota-Aktion erscheint zunächst die Quota-Seite. Der Benutzer wählt eine Dauer bis zum verfügbaren Kontingent und Proceed, oder verzichtet mit Return to previous page auf den Zugriff. Am Ende des gewählten Zeitraums erscheint die Seite erneut; bei aufgebrauchtem Kontingent wird keine Restzeit mehr angeboten. Ein Policy Override kann stattdessen temporären Zugriff ermöglichen; dabei gilt die Quota nicht. Die Override-Berechtigung darf deshalb nicht als beliebige Alternative für alle Benutzer aktiviert werden.

Eine passende SSL/TLS-Inspection-Regel mit Action > Deny blockiert weiterhin; mehr Quota oder ein Reset behebt diesen Konflikt nicht. Zuerst prüfen, ob der TLS-Block fachlich beabsichtigt ist. Nur für einen ausdrücklich genehmigten, eng begrenzten Fall eine Web Exception zum Überspringen der HTTPS-Entschlüsselung planen. Diese nimmt auch davon abhängige Prüfungen weg und kann ungültige Serverzertifikate zulassen; nicht als Standardreparatur einsetzen. Erlaubten Pilotzugriff, verbleibenden Block ausserhalb des Ausnahme-Scope und den Rückweg durch Deaktivieren der Pilot-Exception separat prüfen. Die tatsächliche Begrenzung der Web Exception muss durch ihre unterstützten Kriterien erfolgen, zum Beispiel durch die Quell-IP des Pilotclients zusammen mit dem bestätigten Hostname-Muster – nicht durch die Gruppe des Quota-Benutzers.

Policy Quota im Betrieb prüfen

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

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

Warn- und Blockseiten anpassen

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

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

Für Bilder Use custom images aktivieren und die gewünschten Bilder auswählen. Für Texte jeweils Use custom block message, Use custom override message, Use custom quota message oder Use custom warn message aktivieren und den Text eingeben. Den zugehörigen Preview-Link öffnen und danach mit einem echten Pilotrequest den passenden Meldungstyp prüfen. Keine echten Kundendaten in Testbildern verwenden.

Policy Overrides sicher begrenzen

Ein bereits vom Administrator autorisierter Benutzer erstellt seine Sitzung im User Portal so:

1. My policy overrides > Add öffnen und einen aussagekräftigen Sitzungsnamen vergeben.
2. Den vorgegebenen Zugangscode behalten oder über Generate access code einen neuen erzeugen. Ein eigener manuell erstellter Code ist nur bei ausdrücklich erteilter Berechtigung zulässig.
3. Die benötigten erlaubten Websites und Webkategorien auswählen; vom Administrator für Overrides gesperrte Ziele können nicht freigegeben werden.
4. Unter Restricted to time periods einen vorhandenen Schedule aus der Liste wählen. Hier wird ein Zeitplan ausgewählt, nicht ein beliebiger Zeitraum als Freitext eingegeben.
5. Mit Apply speichern. Den Zugangscode danach beim passenden blockierten Aufruf im Codefeld der Sperrseite eingeben.

Mit Status schaltet der Benutzer diese Override-Sitzung ein oder aus. Das ist nicht die administrative Verwaltung über View overrides: Der Administrator kann die vom Benutzer erstellte Sitzung unabhängig davon ein- oder ausschalten beziehungsweise löschen. Ohne Autorisierung ist dieser Benutzerablauf nicht verfügbar; die Einschränkung auf die AD-Main-Group und individuelle Benutzer bleibt bestehen.

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

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

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

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

Bei AD-Benutzern gilt My policy overrides nur für die Main Group und individuelle Benutzer, nicht für weitere Gruppenmitgliedschaften. Eine passende SSL/TLS-Inspection-Regel mit Action > Deny hat weiterhin Vorrang. Muss ein fachlich genehmigter Override dort funktionieren, wird eine enge Web Exception zum Überspringen der HTTPS-Entschlüsselung geplant und separat negativ getestet; die TLS-Regel wird nicht pauschal gelockert. Die Override-Berechtigung schränkt die Web Exception nicht ein; ihren eigenen Geltungsbereich anhand von Quell-IP und Hostname/Kategorie wie unten beschrieben definieren und mit Negativtests prüfen.

Web Exceptions und TLS-Ausnahmen

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

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

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

Für Web Exceptions sollten Root-Domains und zu breite URL-Regex-Muster vermieden werden: Ein einfaches Muster wie example.com kann auch auf Text im Pfad oder in den Query-Parametern einer anderen Domain passen. Konkrete Hostname-Muster können im TLS-Kontext greifen; reine URL-Pfade sind nur bei HTTP oder bereits entschlüsseltem HTTPS sichtbar. Die unterstützten Kriterien für Web Exceptions sind URL-Regex-Muster, Webkategorien, Quell-IP-Adressen und Ziel-IP-Adressen – nicht Benutzer, Benutzergruppen oder URL Groups.

Für eine auf eine Benutzergruppe begrenzte geschäftliche Freigabe die passende Firewall-Regel und Users in der Web Policy verwenden; für eine identitätsbezogene Entschlüsselungsausnahme im DPI Mode die entsprechende SSL/TLS-Inspection-Regel mit Don’t decrypt und expliziten Benutzer-/Gruppenkriterien verwenden. Diese Identitätskriterien werden nicht zu Kriterien einer separat angewendeten Web Exception und begrenzen deren Umgehung von Prüfungen nicht von sich aus.

Für einen Web-Exception-Pilot die konkreten Source IP addresses der Clients mit einem bestätigten Hostname-Muster oder einer begründeten Webkategorie kombinieren. Sowohl eine nicht freigegebene Quelle als auch ein Ziel ausserhalb des tatsächlichen Geltungsbereichs dieser Kriterien testen; eine IP-Adresse ist keine Benutzeridentität. Aus der allgemeinen AND-Logik nicht ableiten, dass Quell-IP- und Ziel-IP-Ausnahmen für einen TLS-Ausschluss kombiniert werden dürfen: Die beibehaltenen Hinweise zum TLS-Ausschluss besagen, dass sie nicht kombiniert werden können; ihr genauer Geltungsbereich ist unklar. Wenn beide IP-Einschränkungen erforderlich sind, abbrechen, ohne die Ausnahme zu aktivieren oder auszuweiten, und eine Klärung für den konkreten Build einholen. Das Vorgehen und die Grenzen der Kriterienabgleichung werden unter Web Exceptions sicher erstellen und testen erläutert.

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 über die XML API gezielt automatisieren

Die XML API ist sinnvoll, wenn dieselben geprüften Web-Objekte auf mehreren Firewalls gepflegt werden müssen. Sie ersetzt weder die Zuweisung der Web Policy zur tatsächlich passenden Firewall-Regel noch die Verkehrsprüfung. Vor dem Schreiben den aktuellen Objektbestand, seine Referenzen und die alte Policy sichern. Zugriff, Request-Aufbau, API-Version, XML-Status und Audit Trail werden in XML API Zugriff sicher konfigurieren und Antworten auswerten erklärt. Die folgenden Objektbeziehungen sind keine vollständige, ausführbare Anfrage. Bei den ausdrücklich genannten Quellenwidersprüchen zuerst API help des installierten Builds prüfen und ohne eindeutige Klärung nicht schreiben.

Objekte zuerst, Policy und Zuweisung danach

Ein überschaubarer Automationsfall ist eine eigene URL Group für Geschäftsziele, ein eigener File Type für Downloads und eine User Activity, die diese Kriterien zusammenfasst. Zuerst diese Objekte mit ihren tatsächlichen Namen lesen beziehungsweise anlegen, danach die Policy-Regeln auf diese Objekte verweisen lassen und zuletzt die Web Policy der vorhandenen, tatsächlich passenden Firewall-Regel kontrolliert zuweisen. Ein neues Objekt allein erlaubt oder blockiert noch keinen Verkehr.

• URL Group: WebFilterURLGroup enthält Name und wiederholte URL-Einträge unter URLlist. Die Schreibweise URLlist ist nicht dieselbe wie URLList einer externen Web Category. IsDefault kennzeichnet eine eingebaute URL Group; das Feld ist laut Referenz nur lesbar, Änderungen daran werden beim Update ignoriert. Es macht ein eigenes Objekt nicht zu einem bearbeitbaren Standardobjekt. Für geeignete Domainwerte und die UI-Pflege bleibt der URL-Group-Ablauf massgebend.
• File Type: FileType bündelt FileExtensionList mit wiederholten FileExtension-Werten und MIMEHeaderList mit wiederholten MIMEHeader-Werten. Der Kommentar im XML-Beispiel beschreibt Template so, dass die Erweiterungen und MIME-Header der Vorlage übernommen und separat genannte Einträge zusätzlich eingefügt werden. Deshalb nach dem Schreiben die effektive Gesamtliste prüfen, nicht nur die ergänzten Werte. Das Beispiel zeigt Blank, die Parametertabelle erläutert Template jedoch nicht; daraus keine universelle zulässige Template-Liste ableiten. Erweiterungen bleiben ohne führenden Punkt, etwa pdf.
• User Activity: UserActivity verwendet Name für den bestehenden Namen und NewName für eine beabsichtigte Umbenennung. Unter CategoryList stehen Category-Objekte mit Type und ID. Im Beispiel sind die Typbezeichnungen web category, file type und url group von der ID als Objektname getrennt. Kein Typwort als Objekt-ID einsetzen und keine numerische ID erfinden. Das Beispiel nennt den Beschreibungstag Desc, die Tabelle dagegen Description; den gültigen Tag build-spezifisch bestätigen. Die OR-Verknüpfung der Activity-Kriterien bleibt von der späteren HTTP-/HTTPS-Aktion getrennt.

Bei einem File-Type-Fehler sind diese XML-Antworten besonders relevant: Edit File Type 202 / Message.FileTypeUpdateWithRename, Add File Type oder Edit File Type 503 / Message.FileTypeSameDetailRecordExists und 505 / Message.FileTypeInvalidExtensionOrMIMEHeader. Das sind unveränderte Referenzsymbole, keine aufgelösten Meldungstexte und keine HTTP-Codes. Bei 202 alten und neuen Namen sowie Policy-Referenzen lesen; bei 503 die bereits vorhandenen Detailwerte vergleichen und bei 505 Erweiterungen/MIME-Header prüfen. Nicht einfach ein zweites Objekt mit anderem Namen anlegen.

Eigene Kategorien: Inhalt, Klassifikation und Bandbreite trennen

WebFilterCategory unterscheidet mit ConfigureCategory zwei Eingabewege: Local verwendet DomainList/Domain und KeywordList/Keyword; External verwendet URLList/URL für die externe Kategorienliste. Eine externe Listen-URL ist nicht automatisch ein freizugebender Geschäfts-Domainwert. Herkunft, Aktualisierung und Inhalt der externen Liste müssen nachvollziehbar sein. Nicht beide Wege ungeprüft in einen Request mischen.

Classification ordnet die Kategorie ein, entscheidet aber nicht über Allow oder Block. Die Beschreibung nennt teilweise andere Bezeichnungen als die Enum-Tabelle; diese nennt Productive, Unproductive, Acceptable und Objectionable. Auch ConfigureCategory ist nicht völlig konsistent: Das Beispiel zeigt Local/External, die Tabelle zusätzlich 0. Weder übersetzte Klassifikationsnamen noch 0 als ungeprüften Ersatz übertragen. QoSPolicy referenziert eine Bandbreitenrichtlinie, keine Web-Policy-Aktion; Auswahl und Wirkung werden im Traffic-Shaping-Ablauf geprüft. Erst eine passende Web-Policy-Regel macht aus der Kategorie eine Zugriffsentscheidung.

Die Kategorientabelle verlangt eine genaue Nachkontrolle der Details:

• Add Category 201 / Message.WFCCategoryDetailCannotAdded und Update Category 201 / Message.WFCCategoryDetailCannotUpdated: Nicht alle XML-2xx-Antworten als vollständig gespeicherte Domain-/Keyword-/Listenwerte behandeln. Objektkopf und jede benötigte Detailmenge getrennt zurücklesen. Add Category 202 verweist wie 200 auf Message.WFCAddSuccess; der gemeinsame Symbolname erklärt den Unterschied der Codes nicht.
• Add Category 522 / Message.WFCMaxFiveURL und 523 / Message.WFCMaxFiveKeyword, aber Update Category 503 / Message.WFCMaxFiveURL und 504 / Message.WFCMaxFiveKeyword: Operation und Code gemeinsam auswerten. Die Symbolnamen allein belegen keinen universellen aktuellen Grenzwert von fünf Einträgen; den tatsächlich zulässigen Umfang aus der Build-Hilfe klären.
• Delete WebFilter Category 201 / Message.WFCRelationExists und 203 / Message.WFCSomeCategoryCannotDeleted: Referenzen und verbleibende Kategorien prüfen, bevor gelöscht oder erneut versucht wird. Kein pauschaler Lösch-Erfolg für eine Auswahl aus mehreren Kategorien.

Alle Message.*-Symbole bleiben hier absichtlich unaufgelöst. Vor einem Retry den tatsächlichen gespeicherten Zustand und die Antwort sichern; insbesondere eine teilweise angewendete Kategorienänderung nicht blind wiederholen.

Content Condition Lists: Key ist nicht Name

Ein ContentConditionList-Objekt enthält den sichtbaren Name, die separate Identität Key und ContentList mit wiederholten ContentString-Werten. Die Referenz fordert Name und Key; für Delete Content Condition List ist ausdrücklich Key der Selektor. Beim Lesen und Dokumentieren deshalb beide Werte erhalten und niemals den angezeigten Namen ungeprüft als Löschschlüssel einsetzen.

Die API-Tabelle bezeichnet ContentString als rohe Regex-Werte und sagt, dass Duplikate nicht ignoriert werden. Der oben beschriebene UI-Import ist dagegen eine Textliste mit einem Exact Match pro Zeile. Ein UI-Import und eine API-Regex-Liste sind damit nicht als identisches Eingabeformat nachgewiesen. Vor einer Umstellung die Semantik mit der Build-Hilfe klären und harmlose Treffer sowie Nicht-Treffer testen; eine vorhandene Textliste nicht ungeprüft als Regex-Payload übertragen.

Besonders auffällig sind die widersprüchlichen Operations-/Meldungszuordnungen der Referenz:

Diese Zeilen belegen einen Dokumentationswiderspruch, nicht, dass ein Update löscht oder ein Delete aktualisiert. Operation, Key, Antwort und tatsächlich vorhandene Inhalte prüfen. Ohne eindeutige Build-Klärung keine zerstörerische Operation daraus ableiten und keinen automatischen Retry aus einem Symbolnamen starten.

WebFilterPolicy: Reihenfolge und Selektoren bewahren

WebFilterPolicy hält die Regeln unter RuleList/Rule. Jede Regel referenziert unter CategoryList/Category einen ID-Objektnamen und einen type-Selektor. Das Policy-Beispiel verwendet WebCategory, URLGroup, UserActivity, DynamicCategory und FileType; diese Tokens unterscheiden sich von den Typbezeichnungen im User-Activity-Beispiel und der Tag type ist dort kleingeschrieben. Schreibweise, Objektart und vorhandenen Namen aus dem gelesenen Objekt beziehungsweise der Build-Hilfe übernehmen, statt UI-Labels oder erfundene IDs zu serialisieren.

HTTPAction und HTTPSAction sind getrennte Entscheidungen; FollowHTTPAction beschreibt ihre Kopplung. Das API-Beispiel nennt Deny, Allow, Warn, Log und Quota. Diese Beispielwerte sind keine Bestätigung, dass alle davon auf jedem Build auswählbar sind, und Deny ist nicht einfach durch das UI-Wort Block zu ersetzen. PolicyRuleEnabled steuert die Regelaktivierung, Schedule den referenzierten Zeitplan und UserList/User den Benutzerbereich. CCLRuleEnabled und CCLList/CCL verknüpfen die Inhaltsfilter mit der Regel; das Beispiel referenziert dort einen CCL-Namen, während das Löschen der CCL ihren Key benötigt. Das HTTPS-Verhalten eines Content Filters muss weiterhin der oben erklärten UI-Kopplung entsprechen. Beim Update Reihenfolge, Benutzerbereich, Zeitplan, Inhaltsfilter und Default Action erhalten und die gesamte gespeicherte Policy vergleichen. Aus einem fehlenden Feld darf keine sichere Beibehaltung oder Löschung unterstellt werden.

Für die folgenden Eingaben liefert die Referenz keine widerspruchsfreie, ausführbare Vorlage:

• DefaultAction: Die Tabelle nennt maximal ein Zeichen, erlaubt aber zugleich Allow und Deny. Nicht auf ein Zeichen kürzen und keine numerische Ersatzcodierung erfinden. EnableReporting zeigt im Beispiel Enable/Disable, während die Tabelle nur Enable erlaubt; das Abschalten ist damit nicht ohne Build-Prüfung bestätigt.
• DownloadFileSizeRestriction: Der XML-Kommentar nennt 1 bis 1536 MB, die Parametertabelle 0 bis 1536. Die Bedeutung von 0 ist damit ungeklärt; weder als unbeschränkt noch als gültigen aktiven Grenzwert behandeln. Schalter DownloadFileSizeRestrictionEnabled und Grenzwert zusammen anhand der Build-Hilfe festlegen und mit harmlosen Dateien beiderseits der bestätigten Grenze prüfen. QuotaLimit wird in der API-Tabelle mit 1 bis 1440 angegeben. Den Bereich mit der Hilfe des installierten Builds abgleichen. DPI unterstützt die Policy Quota weiterhin nicht.
• Tenant Controls: Office365Enabled, Office365TenantsList und Office365DirectoryId gehören zur Microsoft-Tenant-Beschränkung. Für die Liste nennt die API-Tabelle 4096 Zeichen, die UI-Hilfe für Restrict-Access-To-Tenants dagegen 256; diese Grenzwerte nicht gleichsetzen und keinen längeren produktiven Wert aus der API-Angabe ableiten. Der Beispielsatz für Office365DirectoryId, 456ff232-35l2-5h23-b3b3-3236w0826f3d, enthält nichthexadezimale Zeichen und ist kein gültiger GUID-Beispielwert. Nicht stillschweigend reparieren, sondern die tatsächliche Directory-ID aus der eigenen Tenantverwaltung verwenden und erlaubte wie nicht erlaubte Tenant-Logins testen. Die UI-Feldzuordnung, Längen und Semantik im installierten Build bestätigen.

Add Policy 522 / Message.WebPoliciesLimit betrifft die Policy-Grenze; daraus kein Limit für Regeln oder Kategorien ableiten. Update Policy 503 / Message.WFPQuotaLimitInvalid verlangt die Prüfung der Quota-Eingabe. Die Referenz führt zusätzlich Update Policy from API als eigene Operationsbezeichnung auf; deren Antwortzeilen enthalten diesen 503-Eintrag nicht. Das belegt nicht, dass dieser Weg jede Quota akzeptiert. Status, gespeicherte Policy und reale Wirkung vor einem erneuten Schreiben prüfen.

Globale Schutzoptionen und Benachrichtigungen nicht vermischen

WebFilterSettings ist der globale Web-Filter-Einstellungsbereich, nicht eine einzelne WebFilterPolicy. Er enthält unter anderem PharmingProtection, Scanning, BlockUnscannableContent und PUAWhitelist mit wiederholten PUA-Namen. Ein PUA-Eintrag ist eine bewusst genehmigte Ausnahme, kein notwendiger Schritt für eine neue Web Policy. Scanner-Auswahl und Wirkung bleiben im verlinkten Malware-Scanning-Ablauf; eine Nachricht anzupassen ist kein Anlass, nebenbei globale Schutzoptionen oder die PUA-Liste zu ändern.

WebFilterProtectionSettings ist ein weiterer, eigener Scanner-/Schutzvertrag mit Feldern wie ScanMode und FileSizeThreshold. Ähnlich benannte Schutzfelder machen ihn nicht zum Synonym von WebFilterSettings oder WebFilterNotificationSettings; Payloads nicht zwischen diesen Objekten austauschen. Für einen reinen Hinweistext keine Scanner-, Grössen- oder Zertifikatsoptionen mitschreiben. Auch bei diesem Schutzobjekt muss der gültige Vertrag aus der Build-Hilfe stammen, nicht aus ungeprüft übernommenen Beispielwerten.

Auch hier widerspricht das Beispiel der Tabelle: BlockUnscannableContent zeigt Enable/Disable, die Tabelle erlaubt dagegen Allow und Block (Best Protection). Diese Enums nicht vereinheitlichen oder aus dem Feldnamen erraten. Vor jeder Änderung das bisherige Verhalten sichern und den exakten Build-Vertrag klären.

WebFilterNotificationSettings adressiert dagegen die Benutzerbenachrichtigungen. OverrideDefaultDeniedMessage gehört zu DefaultDeniedMessage, OverrideDefaultWarnedMessage zu DefaultWarnedMessage; benutzerdefinierte Texte werden nur mit dem passenden Override bewusst ausgewählt. Zusätzliche Override-/Quota-Felder stehen in der Tabelle, fehlen aber teilweise im Beispiel: OverrideDefaultOverrideMessage/DefaultOverrideMessage und OverrideDefaultQuotaMessage/DefaultQuotaMessage. Die Override-/Quota-Schalter nennen als zulässige Werte 0/1, zugleich aber Enable als Default. Das ist ein weiterer Quellenwiderspruch und kein Grund, alle Flags gleich zu codieren. Für einen reinen Textwechsel nur die vorgesehenen Text-/Override-Felder nach bestätigtem Build-Vertrag ändern und die passende Seite im Pilot prüfen.

DeniedMessageImage wählt Default oder Custom. Das Beispiel bindet TopImageFile und BottomImageFile an einen Dateinamen aus dem Multipart-Request; die Tabelle beschreibt jpg/jpeg. Bei den User Notifications nennt die Tabelle den oberen Parameter jedoch Top Image, während das Beispiel TopImageFile nutzt. Diese Angaben reichen nicht aus, um Part-Namen, Content-Disposition, Upload-Endpunkt oder Dateizuordnung sicher zu konstruieren. Die Dateiübertragung zuerst anhand der Build-Hilfe beziehungsweise einer dafür bestätigten offiziellen Collection klären. Ohne bestätigten Upload-Vertrag keine automatisierte Bildänderung ausführen. Die ähnlichen Nachrichten-/Bildfelder in WebFilterSettings machen die beiden Objekte nicht austauschbar.

DefaultWebFilterNotificationSettings ist nochmals getrennt: Es bietet benannte Standard-Nachrichtentexte, zum Beispiel WebsiteBlocked. Ein sinnvoller enger Anwendungsfall ist ein genehmigter Hinweis mit dem richtigen Supportkontakt. Dafür genau den betroffenen Originaltext sichern, nur den bestätigten Nachrichtenschlüssel ändern, die passende Vorschau und reale Pilotseite prüfen und bei Bedarf genau diesen Text zurücksetzen. Nachrichtentext ist weder eine Zugriffsfreigabe noch ein Beleg für einen Malware-/Zero-Day-Befund.

Jede Automationsänderung zurücklesen und abnehmen

Nach jeder Schreiboperation das exakt adressierte Objekt mit der API beziehungsweise in WebAdmin zurücklesen: Namen/Keys, wirksame Listen, Referenzen, Policy-Reihenfolge, Aktivierung und die tatsächliche Firewall-Zuweisung vergleichen. Danach dieselben erlaubten und blockierten Pilotrequests wie vor der Änderung ausführen und Rule ID, Benutzer, Web Policy und Aktion im Log Viewer korrelieren. Ein HTTP-Erfolg, ein XML-2xx-Code oder ein unaufgelöstes Message.*-Symbol allein genügt nicht. Bei Teiländerung oder unklarer Antwort zuerst Ist-Zustand und Audit Trail sichern, dann gezielt korrigieren; kein blindes Add-/Delete-Retry. Zurückgerollt werden nur die dokumentierten eigenen Änderungen, nicht andere vorhandene Policies, Overrides oder globale Schutzwerte.

Web Protection testen

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

1. Policy Tester verwenden

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

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

2. Echttest mit Pilotclient

Mit einem Pilotclient prüfen:

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

3. Log Viewer prüfen

Im Log Viewer sollte sichtbar sein:

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

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

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

Instant Alerts und Reporting

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

Die drei Auswertungswege beantworten unterschiedliche Fragen:

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

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

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

Änderungen und Ausnahmen im Betrieb steuern

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

Für jede Änderung sollte man mindestens festhalten:

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

Bewährt hat sich ein kleiner Change-Ablauf:

1. Anfrage mit Benutzer, URL, Zeitpunkt, Business-Grund und Screenshot oder Fehlermeldung erfassen.
2. Im Log Viewer prüfen, welche Firewall-Regel, Web Policy, Kategorie und Aktion gegriffen haben.
3. Entscheiden, ob die Kategorie grundsätzlich falsch ist, ob nur eine einzelne Domain freigegeben werden soll oder ob die Anfrage abgelehnt wird.
4. Wenn eine geschäftliche Freigabe erforderlich ist, diese in der passenden Firewall-Regel und Web Policy eng begrenzen: eine konkrete URL Group statt einer ganzen Kategorie und explizite Users statt des gesamten LAN. Wenn stattdessen eine Web Exception benötigt wird, deren eigene unterstützte URL-/Kategorie-/IP-Kriterien verwenden; eine Benutzergruppe oder URL Group ist kein Kriterium für eine Web Exception.
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

Bei akuten Blockierungen nicht reflexartig eine breite Allow-Regel ganz oben einfügen. Eine enge, zeitlich begrenzte geschäftliche Freigabe in der passenden Firewall-Regel und Web Policy bevorzugen, mit einer konkreten URL Group, expliziten Users und einem Review-Datum. Dies ist keine auf eine Benutzergruppe begrenzte Web Exception. Jede erforderliche Umgehung von Prüfungen benötigt eigene genehmigte, unterstützte Kriterien sowie separate Positiv- und Negativtests. Die temporäre Freigabe anschliessend erneut bewerten.

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