Sophos Server Web Control unter Windows sicher einführen

Server Web Control steuert den Zugriff auf Website-Kategorien und eigene Websitelisten auf Windows-Servern. Der sichere Einstieg ist eine zusätzliche Policy für einen einzelnen, repräsentativen Server: Betriebszugriffe erfassen, eine begrenzte Kategorieentscheidung treffen, Ereignisprotokollierung aktivieren und erst nach einem Funktionstest auf weitere Server ausweiten. Die Endpoint-Policy unter My Products > Endpoint weist einem Server keine Server-Web-Control-Policy zu.

Voraussetzungen und Entscheidung

Der Server muss im richtigen Sophos-Fusion-Tenant unter My Products > Server > Servers erscheinen und einen für die beabsichtigte Web-Control-Funktion lizenzierten Schutzmodus haben. Lizenz und tatsächlich installierte Komponenten vorab im Tenant prüfen; aus einer sichtbaren Policy-Maske allein folgt keine Berechtigung oder wirksame Agent-Funktion. Bei einem reinen XDR Sensor ohne Malware-Schutz die Web-Control-Wirkung nicht voraussetzen. Welche Serverrolle, Browser- oder Dienstverbindungen betroffen sein können, vor der Änderung mit dem Anwendungsverantwortlichen festhalten. Ein Webfilter auf einem Server ist kein Ersatz für die Freigaben in Proxy, DNS-Schutz oder Netzwerk-Firewall.

Sophos bietet Classic settings und Web profile an. Die Base Policy hat zunächst Classic mit empfohlenen Einstellungen aktiviert und Web profile deaktiviert. Zusätzliche Policies enthalten jeweils nur einen der beiden Typen. Ein Web Filtering Profile ist eine wiederverwendbare, unter Windows verfügbare Sammlung aus Kategorien und Site Lists; es wird nicht automatisch bereitgestellt. Die gemeinsame Einrichtung von Web Filtering Profiles und Site Lists ist im bestehenden Endpoint-Artikel erklärt; dessen Endpoint-Policy-Pfad gilt nicht für Server. Sophos nennt für Web-Profile-Policies an einer Stelle «Sophos Endpoint 2026.1 oder neuer», aber keine gesicherte entsprechende Server-Agent-Version. Deshalb wird diese Endpoint-Versionsangabe hier nicht als Server-Mindestversion übernommen: Vor einer produktiven Web-Profile-Zuweisung die Unterstützung für den konkreten Server-Agenten im Tenant prüfen. Ist sie ungeklärt, mit Classic auf einem Pilotserver beginnen.

Für den Pilot eine geschäftlich unkritische Kategorie und eine harmlose Test-URL wählen. Deren tatsächliche Sophos-Kategorie vorab mit SophosLabs Intelix prüfen: Die Schaltfläche Site category lookup ist im Web-Filtering-Profile-Editor unter Filter by category erreichbar (Global Settings > Protection & Remediation > Web Settings > Web Filtering Profiles). Nur bei passender Kategorie testen, keine URL-Kategorie-Zuordnung raten; für diesen Lookup keine Profilzuweisung am Server vornehmen. Benötigte Server-URLs und automatisierte Downloads vor einer Block-Entscheidung erfassen. Für einen reproduzierbaren HTTPS-Pilot zunächst Block wählen und den Browserzugriff auf einem nachweislich nicht über QUIC laufenden Testpfad prüfen: QUIC kann laut Sophos bei manchen Websites die Website-Prüfung umgehen. Den QUIC-Transport des Testbrowsers daher vor der Abnahme kontrollieren und gegebenenfalls nur für diesen Testbrowser einen verifizierten Nicht-QUIC-Pfad verwenden. Block QUIC browser connections in der wirksamen Server Threat Protection Policy ist standardmässig aus; diese Threat-Protection-Policy-Einstellung nicht allein für den Pilot ungeprüft einschalten. Warn erst als sichtbaren HTTPS-Warntest einsetzen, wenn die HTTPS-Entschlüsselung in der wirksamen Server Threat Protection Policy freigegeben und für die Test-URL wirksam ist. Ohne diese Voraussetzung die sichtbare Warnung nicht als Abnahmekriterium verwenden, sondern den Warntest zurückstellen. Entschlüsselung nicht beiläufig einschalten: Sie kann vollständige URLs und personenbezogene Inhalte zugänglich machen; Datenschutz, Zertifikate und betroffene Dienste gesondert prüfen. Die allgemeinen Hintergründe stehen im Abschnitt «HTTPS und Warnseiten» des verlinkten Endpoint-Artikels; dessen Endpoint-Schalter ist keine Server-Anweisung.

Eine kleine Server-Policy erstellen

1. Unter My Products > Server > Policies auf Add policy klicken, als Feature Web Control wählen und einen erkennbaren Namen wie WC-Server-Pilot vergeben. Der Name ist frei wählbar und sollte Geltungsbereich und Zweck erkennen lassen.
2. Auf Servers den einzelnen Pilotserver von Available Servers nach Assigned Servers verschieben. Nicht versehentlich die gesamte Servergruppe auswählen.
3. Auf Settings Web Control einschalten. Für einen Pilot ohne bestätigte Web-Profile-Unterstützung Classic settings wählen. Unter Filter website by category für die geprüfte Testkategorie zunächst Block festlegen; Warn nur mit den oben genannten HTTPS-Voraussetzungen testen. Allow ist keine Sperrprüfung. Die anderen Kategorien nicht ohne Prüfung verschärfen.
4. Log web control events aktivieren und die Policy speichern. Ohne diese Option werden laut Sophos nur Versuche für infizierte Websites protokolliert, nicht die gewöhnlichen Block- und Warnversuche. Anschliessend prüfen, ob die neue Policy aktiv ist und ob eine höher angeordnete, ebenfalls passende Web-Control-Policy den Pilot übersteuert.

Option für benötigte Ziele in Classic: Unter Global Settings > Protection & Remediation > Web Settings > Website Management > Add das konkret benötigte Ziel mit einem neuen oder bestehenden Tag versehen und speichern; bei einem bestehenden Tag dessen weitere Verwendungen vorher prüfen, sonst einen eigenen Pilot-Tag wählen. Dann unter My Products > Server > Policies > Web Control > [Pilot-Policy] > Settings > Control sites tagged in Website Management > Add New den Tag und die begründete Action wählen, im Dialog und anschliessend in der Policy Save klicken. Ziel und betroffene Dienste auf dem Pilotserver erneut testen. Dies ist eine gezielte Classic-Policy-Regel, keine globale Website Exclusion und kein Endpoint-Policy-Schritt.

Falls der konkrete Server Web profile unterstützt, stattdessen Web profile wählen und ein bereits erstelltes Profil zuweisen. Nur wenn fachlich benötigt, Apply different profiles at different times mit einem überprüften Zeitplan verwenden. Risky File Types sind eine zusätzliche Entscheidung: Recommended und View More vor einer Änderung prüfen; Allow für alle riskanten Typen ist keine harmlose Grundeinstellung. Dieses Profil kann auch in anderen Policies verwendet werden: Änderungen daran vorab auf weitere betroffene Geräte und Server prüfen. Eine zusätzliche Policy kann Classic settings und Web profile nicht gleichzeitig enthalten; die Base Policy kann beides enthalten und bei nicht anwendbaren Profileinstellungen auf Classic zurückfallen. Das ist kein zugesicherter Rückweg einer fehlerhaft gewählten zusätzlichen Policy.

Wirkung prüfen und Fehler eingrenzen

Vor dem Wechsel die geprüfte Test-URL und einen benötigten Update-, Login- oder Verwaltungszugriff vom Pilotserver aus auf Erreichbarkeit prüfen; Ziel, ermittelte Kategorie und erwartete Aktion notieren. Vor der Abnahme sicherstellen, dass die Test-URL nicht von einer Website Exclusion für die Bedrohungsprüfung erfasst wird und, bei Web profile, nicht von einer vorrangigen Site List; bei Classic auch bestehende Website-Management-Tag-Regeln auf das Ziel prüfen. Nach der Policy-Synchronisierung unter My Products > Server > Servers > [Pilotserver] > Policies den erwarteten Web-Control-Policy-Namen kontrollieren. Vom Pilotserver aus die Test-URL über den zuvor verifizierten Nicht-QUIC-Pfad erneut aufrufen und auf demselben Server unter Events nach Testzeitpunkt und Block-Ereignis suchen. Erwartet: Die Seite ist gesperrt, das Ereignis passt zur Testanfrage und benötigte Zugriffe funktionieren weiterhin. Beim separaten, freigegebenen HTTPS-Warn-Test sichtbare Warnmeldung und Warnereignis prüfen; ein protokolliertes Warnereignis allein bestätigt keine sichtbare Warnseite. Ohne freigegebene und wirksame Entschlüsselung diesen Teil der Abnahme zurückstellen. Die Policies-Ansicht allein belegt keine Filterwirkung; ein fehlendes Event ohne eingeschaltetes Logging beweist keine fehlende Wirkung.

• Falsche Policy: Zugewiesenen Server, Aktivstatus und Reihenfolge prüfen; die Server-Detailseite zeigt die tatsächlich angewendete Policy. Nicht den Endpoint-Computer-Tab als Nachweis verwenden.
• Erwartete Kategorie wird nicht gesperrt oder Block-Ereignis fehlt: Prüfen, ob der Testbrowser die URL über QUIC statt über den verifizierten Nicht-QUIC-Pfad abgerufen hat; QUIC kann bei manchen Websites die Prüfung umgehen. Danach die ermittelte Sophos-Kategorie, die Profil-Unterstützung des konkreten Servers und die gewählte Classic-/Profilvariante kontrollieren. Bei einem Profil dessen Site Lists prüfen: Sie haben Vorrang vor Kategorieentscheidungen. In Classic auch passende Website-Management-Tags prüfen. Websites, die in Threat Protection von der Bedrohungsprüfung ausgenommen sind, unterliegen laut Sophos nicht diesen Web-Control-Einstellungen.
• Warnung fehlt oder eine benötigte Seite lädt nicht: Zuerst die tatsächlich wirksame Server Threat Protection Policy, freigegebene HTTPS-Entschlüsselung für die Test-URL, Zertifikatsvertrauen sowie mögliche vorgelagerte Proxy- oder Firewall-Sperren prüfen. Wenn weder Warnseite noch Warnereignis erscheinen, auch Logging, Kategorie und wirksame Web-Control-Policy kontrollieren; ohne wirksame Entschlüsselung keinen sichtbaren HTTPS-Warntest abnehmen. Keine globale Website Exclusion als schnellen Reparaturversuch anlegen. Bei einer betroffenen Serveranwendung die konkret benötigten Ziele feststellen und eine eng begrenzte Policy-Änderung separat testen.

Abbruch und Rückweg: Vor dem Pilot den bisherigen Policy-Namen, die betroffene Serverzuweisung und die gewählten Kategorieaktionen notieren. Bei Störung keine weiteren Server zuweisen; den Pilotserver aus Assigned Servers der zusätzlichen Policy entfernen oder die Pilot-Policy deaktivieren und am Server unter Policies die danach wirksame Policy erneut kontrollieren. Danach die betroffenen Dienste und die zuvor getesteten Zugriffe wiederholen. Eine Profiländerung oder eine Änderung an der Base Policy ist dafür kein risikoarmer Rückweg, weil weitere Geräte betroffen sein können.