Déployer Sophos Server Web Control sous Windows en toute sécurité

Server Web Control contrôle l’accès aux catégories de sites Web et aux listes de sites personnalisées sur les serveurs Windows. Pour commencer sans risque, créer une stratégie supplémentaire destinée à un seul serveur représentatif : recenser les accès nécessaires à son fonctionnement, définir une action limitée pour une catégorie, activer la journalisation des événements et n’étendre la stratégie à d’autres serveurs qu’après un test fonctionnel. La stratégie Endpoint sous My Products > Endpoint n’attribue aucune stratégie Server Web Control à un serveur.

Prérequis et choix de la méthode

Le serveur doit apparaître dans le bon tenant Sophos Fusion sous My Products > Server > Servers et disposer d’un mode de protection sous licence pour la fonction Web Control envisagée. Vérifier au préalable la licence et les composants effectivement installés dans le tenant : l’affichage d’un écran de stratégie ne prouve ni que la fonction est autorisée ni que l’agent l’applique. Ne pas présumer que Web Control fonctionnera avec un simple XDR Sensor sans protection contre les malwares. Avant toute modification, consigner avec le responsable de l’application les rôles du serveur et les connexions de navigateurs ou de services susceptibles d’être touchées. Le filtrage Web sur un serveur ne remplace pas les autorisations définies dans le proxy, la protection DNS ou le pare-feu réseau.

Sophos propose Classic settings et Web profile. Initialement, la Base Policy active Classic avec les paramètres recommandés et désactive Web profile. Chaque stratégie supplémentaire ne peut contenir qu’un seul de ces deux types. Un Web Filtering Profile est un ensemble réutilisable de catégories et de Site Lists, disponible sous Windows ; il n’est pas déployé automatiquement. La configuration commune des Web Filtering Profiles et Site Lists est expliquée dans l’article Endpoint existant ; le chemin de sa stratégie Endpoint ne s’applique pas aux serveurs. Sophos mentionne à un endroit « Sophos Endpoint 2026.1 ou version ultérieure » pour les stratégies Web profile, sans indiquer de version correspondante confirmée de l’agent Server. Cette version d’Endpoint n’est donc pas présentée ici comme une version minimale pour Server : avant d’attribuer un Web profile en production, vérifier dans le tenant sa prise en charge par l’agent du serveur concerné. En cas de doute, commencer avec Classic sur un serveur pilote.

Pour le pilote, choisir une catégorie sans enjeu métier et une URL de test inoffensive. Vérifier au préalable sa catégorie Sophos réelle avec SophosLabs Intelix : le bouton Site category lookup se trouve dans l’éditeur de Web Filtering Profile, sous Filter by category (Global Settings > Protection & Remediation > Web Settings > Web Filtering Profiles). Ne tester que si la catégorie correspond ; ne pas deviner le classement d’une URL et ne pas attribuer de profil au serveur pour effectuer cette recherche. Recenser les URL indispensables au serveur et les téléchargements automatisés avant de choisir Block. Pour un pilote HTTPS reproductible, commencer par Block et tester l’accès depuis un navigateur sur un chemin dont on a vérifié qu’il n’utilise pas QUIC : selon Sophos, QUIC peut permettre à certains sites d’échapper à l’inspection Web. Contrôler donc le transport QUIC du navigateur de test avant de valider le résultat et, si nécessaire, utiliser un chemin sans QUIC vérifié, uniquement pour ce navigateur de test. Block QUIC browser connections est désactivé par défaut dans la Server Threat Protection Policy effectivement appliquée ; ne pas activer ce réglage de la stratégie Threat Protection uniquement pour le pilote sans en évaluer les conséquences. Ne tester Warn comme avertissement HTTPS visible que si le déchiffrement HTTPS est autorisé dans la Server Threat Protection Policy effectivement appliquée et actif pour l’URL de test. Sinon, ne pas retenir l’affichage de l’avertissement comme critère de validation et reporter ce test. Ne pas activer le déchiffrement à la légère : il peut rendre accessibles les URL complètes et des contenus personnels ; examiner séparément la confidentialité, les certificats et les services concernés. Les principes généraux sont présentés dans la section « HTTPS et pages d’avertissement » de l’article Endpoint lié ; son réglage Endpoint ne constitue pas une instruction pour Server.

Créer une stratégie Server limitée

Sous My Products > Server > Policies, cliquer sur Add policy, sélectionner Web Control comme Feature et donner un nom identifiable, par exemple WC-Server-Pilot. Le nom est libre, mais doit indiquer le périmètre et l’objectif.
Sous Servers, déplacer uniquement le serveur pilote de Available Servers vers Assigned Servers. Ne pas sélectionner par erreur tout le groupe de serveurs.
Sous Settings, activer Web Control. Si la prise en charge de Web profile n’est pas confirmée pour le pilote, choisir Classic settings. Sous Filter website by category, définir d’abord Block pour la catégorie de test vérifiée ; ne tester Warn que si les conditions HTTPS ci-dessus sont réunies. Allow ne permet pas de vérifier un blocage. Ne pas durcir les autres catégories sans examen préalable.
Activer Log web control events et enregistrer la stratégie. Selon Sophos, sans cette option, seules les tentatives d’accès à des sites infectés sont journalisées, et non les tentatives ordinaires bloquées ou averties. Vérifier ensuite que la nouvelle stratégie est active et qu’aucune autre stratégie Web Control applicable, placée plus haut, ne prévaut sur elle pour le pilote.

Option pour les destinations nécessaires avec Classic : sous Global Settings > Protection & Remediation > Web Settings > Website Management > Add, attribuer à la destination précise un Tag nouveau ou existant, puis enregistrer. Avant de réutiliser un Tag, vérifier ses autres usages ; sinon, créer un Tag propre au pilote. Sous My Products > Server > Policies > Web Control > [Pilot-Policy] > Settings > Control sites tagged in Website Management > Add New, sélectionner le Tag et l’Action justifiée, puis cliquer sur Save dans la boîte de dialogue et à nouveau dans la stratégie. Tester de nouveau la destination et les services concernés sur le serveur pilote. Il s’agit d’une règle ciblée de stratégie Classic, et non d’une Website Exclusion globale ni d’une étape de stratégie Endpoint.

Si le serveur concerné prend en charge Web profile, choisir plutôt Web profile et attribuer un profil déjà créé. N’utiliser Apply different profiles at different times avec un calendrier vérifié que si le besoin métier le justifie. Risky File Types exige une décision distincte : examiner Recommended et View More avant de modifier ce réglage ; Allow pour tous les types risqués n’est pas un réglage initial anodin. Ce profil peut également servir dans d’autres stratégies : évaluer d’abord l’impact de toute modification sur les autres appareils et serveurs concernés. Une stratégie supplémentaire ne peut pas contenir à la fois Classic settings et Web profile ; la Base Policy peut contenir les deux et revenir à Classic lorsque les paramètres du profil ne sont pas applicables. Cela ne garantit pas un retour en arrière pour une stratégie supplémentaire mal choisie.

Vérifier l’effet et diagnostiquer les problèmes

Avant le changement, vérifier depuis le serveur pilote l’accessibilité de l’URL de test dont la catégorie a été confirmée et d’un accès indispensable aux mises à jour, à l’authentification ou à l’administration ; noter la destination, la catégorie relevée et l’action attendue. Avant la validation, s’assurer que l’URL de test n’est pas couverte par une Website Exclusion pour l’analyse des menaces ni, avec Web profile, par une Site List prioritaire ; avec Classic, vérifier également les règles de Tag existantes dans Website Management pour cette destination. Après synchronisation de la stratégie, contrôler le nom de la stratégie Web Control attendue sous My Products > Server > Servers > [Pilotserver] > Policies. Depuis le serveur pilote, accéder de nouveau à l’URL de test par le chemin sans QUIC préalablement vérifié, puis rechercher sous Events sur ce même serveur un événement Block correspondant à l’heure du test. Résultat attendu : la page est bloquée, l’événement correspond à la requête de test et les accès nécessaires fonctionnent toujours. Pour un test HTTPS Warn distinct et autorisé, vérifier à la fois l’affichage de l’avertissement et l’événement Warn ; un événement Warn journalisé ne prouve pas à lui seul qu’une page d’avertissement est visible. Reporter cette partie de la validation si le déchiffrement n’est pas autorisé et effectif. La vue Policies ne démontre pas à elle seule l’effet du filtrage ; l’absence d’événement lorsque la journalisation est désactivée ne prouve pas non plus l’absence d’effet.

Mauvaise stratégie : vérifier le serveur attribué, l’état d’activation et l’ordre des stratégies ; la page de détails du serveur indique la stratégie effectivement appliquée. Ne pas utiliser l’onglet des ordinateurs Endpoint comme preuve.
La catégorie attendue n’est pas bloquée ou l’événement Block manque : vérifier si le navigateur de test a chargé l’URL via QUIC plutôt que par le chemin sans QUIC vérifié ; QUIC peut permettre à certains sites d’échapper à l’inspection. Contrôler ensuite la catégorie Sophos relevée, la prise en charge des profils par le serveur concerné et le choix entre Classic et Web profile. Avec un profil, vérifier ses Site Lists : elles ont priorité sur les actions par catégorie. Avec Classic, vérifier aussi les Tags applicables de Website Management. Selon Sophos, les sites exemptés de l’analyse des menaces dans Threat Protection ne sont pas soumis à ces paramètres Web Control.
L’avertissement manque ou une page nécessaire ne charge pas : vérifier d’abord la Server Threat Protection Policy effectivement appliquée, l’autorisation et l’effet du déchiffrement HTTPS pour l’URL de test, la confiance dans les certificats et les éventuels blocages par un proxy ou un pare-feu en amont. Si ni page d’avertissement ni événement Warn n’apparaît, contrôler également la journalisation, la catégorie et la stratégie Web Control effective ; ne pas valider un test d’avertissement HTTPS visible sans déchiffrement effectif. Ne pas créer de Website Exclusion globale comme solution rapide. Si une application serveur est touchée, identifier les destinations précises dont elle a besoin et tester séparément une modification de stratégie strictement limitée.

Arrêt et retour en arrière : avant le pilote, noter le nom de la stratégie précédente, l’attribution du serveur concerné et les actions choisies pour les catégories. En cas d’incident, ne pas attribuer la stratégie à d’autres serveurs ; retirer le serveur pilote de Assigned Servers dans la stratégie supplémentaire ou désactiver la stratégie pilote, puis contrôler à nouveau sous Policies la stratégie désormais appliquée au serveur. Tester ensuite de nouveau les services concernés et les accès vérifiés avant le changement. Modifier le profil ou la Base Policy n’est pas une méthode de retour en arrière à faible risque, car d’autres appareils peuvent être touchés.