Sophos Fusion : configurer et vérifier la protection contre les menaces pour les serveurs

Après l’installation d’un agent serveur, l’affichage d’une stratégie ne prouve pas que la protection fonctionne. Si l’installation et la validation de l’agent restent à faire, consultez le guide d’installation et de validation des serveurs Windows pour Windows Server ou le guide d’installation de SPL pour les serveurs Linux. Pour établir une base sûre dans Sophos Fusion (anciennement Sophos Central), vérifiez d’abord le serveur et sa plateforme, conservez ensuite les paramètres recommandés dans un petit groupe pilote et contrôlez enfin dans les onglets Policies, Status et Events du serveur ce qui a effectivement été appliqué. Les serveurs Windows et Linux partagent une interface de gestion des stratégies, mais pas toutes les fonctions de protection.

Avant toute modification : relever la plateforme et le périmètre

Notez le tenant, le nom du serveur, son système d’exploitation, l’agent installé, la licence et les fonctionnalités souscrites, le rôle du serveur et la stratégie actuelle. Comparez un serveur pilote Windows et un serveur pilote Linux présentant le même profil de production ; les serveurs de bases de données, les contrôleurs de domaine et les hôtes de conteneurs Linux nécessitent des tests distincts en raison de leurs charges et accès aux fichiers différents. Les exemples Pilot-Windows-App et Pilot-Linux-App sont des noms de groupes de serveurs librement choisis, et non des valeurs imposées par Sophos. Sous My Products > Server > Servers, ouvrez l’onglet Server Groups, puis choisissez Add Server Group. Créez un groupe pour chaque plateforme et affectez-y quelques serveurs. Un serveur ne peut appartenir qu’à un seul groupe : son affectation à un groupe pilote le retire de son groupe précédent et peut également modifier les autres stratégies effectives. Avant cette opération, consignez pour chaque serveur son ancien groupe, les stratégies appliquées ainsi que leur ordre, leurs affectations et leurs paramètres afin de disposer d’une base de retour arrière. Commencez par quelques serveurs représentatifs, pas par toute la production.

La Base Policy protège les serveurs lorsqu’aucune stratégie correspondante de priorité supérieure ne s’applique. Des stratégies supplémentaires permettent des dérogations ciblées. Sophos Fusion applique, pour chaque type de stratégie, la première stratégie active correspondante en partant du haut de la liste ; les paramètres de plusieurs stratégies Threat Protection ne sont pas combinés. Le guide des principes de gestion des stratégies explique ce mécanisme commun ; pour ce pilote, ce sont toutefois les stratégies Server et les groupes de serveurs qui comptent, et non les groupes d’ordinateurs Endpoint. Placez la stratégie spécifique du pilote au-dessus d’une stratégie générale et conservez le reste de la configuration de base recommandée. Toute modification d’une stratégie partagée touche tous les serveurs auxquels elle est affectée : vérifiez son affectation avant de cliquer sur Save.

Configurer Server Threat Protection pour le pilote

Ouvrez My Products > Server > Policies et choisissez Add Policy. Si un choix s’affiche, sélectionnez Threat Protection ; pour une stratégie existante, ouvrez d’abord le type de stratégie, puis son nom. Affectez la nouvelle stratégie au petit groupe pilote sous Assigned to et vérifiez Excluded from, si ce champ apparaît. Ne modifiez pas à votre insu la Base Policy de tous les serveurs.
Ouvrez Settings et laissez la stratégie activée. Sous Show filters > Operating System, sélectionnez d’abord Windows, cliquez sur Apply, puis recommencez avec Linux et cliquez à nouveau sur Apply. Ce filtre affiche les paramètres disponibles pour chaque plateforme ; il n’active aucune fonction sur l’agent. Les indications Recommended et Enabled/Disabled aident à repérer les écarts.
Conservez si possible les paramètres recommandés pour Live Protection, Deep Learning et Real-time Scanning - Local Files and Network Shares. Dans Real-time Scanning - Local Files and Network Shares, l’option Scan régit l’analyse en temps réel des fichiers locaux et des fichiers accessibles par le réseau ; Local limite l’analyse aux fichiers de l’appareil. Le passage à Local exige un cas d’usage justifié et un test des partages concernés.
Sous Linux, la protection à l’accès aux fichiers est désactivée par défaut. Pour protéger les accès aux fichiers dans un pilote Linux, le produit SPL antivirus, ou son plugin AV, doit être installé. Dans la stratégie Server Threat Protection effectivement appliquée, sous Real-time Scanning - Local Files and Network Shares, les deux options Scan et Enable scan for Server Protection for Linux Agent doivent être activées ; la seconde est désactivée par défaut. Vérifiez la présence du composant AV sur le serveur pilote en suivant le guide d’installation de SPL mentionné plus haut. Si le composant manque ou si l’une des deux options n’est pas activée, ne validez pas le pilote comme protégé à l’accès aux fichiers : consignez cette lacune et suspendez le déploiement. Une analyse planifiée ne remplace pas l’analyse en temps réel : elle s’exécute à heures fixes, et non lors de l’accès aux fichiers. Enable scheduled scan est disponible sur les deux plateformes ; si nécessaire, choisissez une plage horaire de faible charge. L’horaire suit l’heure locale de l’appareil. Sous Linux, l’analyse planifiée utilise Live Protection indépendamment du paramètre correspondant dans la stratégie.
Laissez si possible Enable event journals activé : en l’absence de ces journaux, les données nécessaires aux investigations ultérieures manqueront pour la période où l’option était désactivée ; Threat Graphs et, s’il est utilisé, Server File Integrity Monitoring ne fonctionneront pas non plus. Ne configurez pas ici de taille globale des journaux. Enregistrez la modification et vérifiez la stratégie effective sur l’appareil avant d’affecter d’autres serveurs.

Ne confondez pas les plateformes : l’analyse en temps réel du trafic Internet, le déchiffrement HTTPS, la protection CryptoGuard/contre les exploits, AMSI, Adaptive Attack Protection et Security Heartbeat sont documentés dans cette stratégie comme des fonctions Windows. Il ne faut en déduire aucune protection équivalente sous Linux. Linux runtime detections est une fonction Linux distincte, soumise à une licence appropriée ; la simple présence de l’option ne prouve ni que vous disposez des droits nécessaires ni que la détection à l’exécution est active. Vérifiez la licence concrète et le statut de l’agent et du tenant avant de prévoir son utilisation. Les options Linux d’analyse en temps réel et d’arrêt des processus malveillants associés ne sont pas non plus équivalentes aux modules de protection à l’exécution de Windows.

N’ajouter des exclusions qu’en cas de conflit démontré

Une exclusion d’analyse réduit la protection, même si d’autres vérifications peuvent continuer à s’appliquer à l’objet exclu. En cas de faux positif, recherchez dans l’onglet Events l’horodatage, la détection et le chemin concerné ; rapprochez ces éléments de la version de l’application, des recommandations de son éditeur et d’une erreur reproductible. Cependant, une application de base de données peut aussi subir une dégradation mesurable due aux analyses lors d’accès fréquents aux fichiers sans qu’un événement de détection soit généré : comparez de manière reproductible la durée d’exécution, la charge et les accès concernés avant et après un test limité dans le temps au sein du groupe pilote. La seule lenteur d’un service, sans lien établi avec l’analyse, ne justifie aucune exclusion.

Sous Settings > Exclusions > Add Exclusion, choisissez Exclusion Type et ne saisissez que l’objet précisément concerné. Pour File or folder, limitez Active for à Real-time Scanning ou Scheduled Scanning si les deux modes ne sont pas manifestement touchés. En cas de charge démontrée sur une base de données Windows, examinez d’abord Process (Windows) avec le chemin complet de l’application, conformément aux indications de l’éditeur : seuls les fichiers utilisés par ce processus sont exclus lors de ses accès, plutôt que d’exclure toute une arborescence pour les autres processus. Sous Linux, File or folder (Linux) accepte les chemins de fichiers et de dossiers ainsi que ? et * ; un chemin complet tel que /mnt/hgfs/excluded est un exemple de syntaxe tiré de la documentation Sophos, pas une recommandation générale d’exclure ce dossier. Remplacez-le uniquement par un chemin vérifié sur le serveur concerné. Ne transposez pas les exclusions de processus ou d’exploits Windows en prétendus équivalents Linux. N’utilisez pas les exclusions Detected Exploits ou de hachage comme solution générale aux problèmes d’analyse ; pour les exclusions de hachage, contactez d’abord le support Sophos. Une exclusion de stratégie ne s’applique qu’aux serveurs auxquels cette stratégie est appliquée ; une Global Exclusion, en revanche, couvre tout le tenant. Lors de l’examen des événements, ne créez pas d’exclusion globale de détection au moyen de Don’t detect this again. Le guide commun des exclusions Endpoint et Server explique les types, les périmètres et le retour arrière ; le choix effectué ici reste une décision propre à la stratégie Server. Consignez l’événement de détection ou les mesures de performance reproductibles, la recommandation de l’éditeur, le motif, les responsables, les serveurs concernés, le test et la date d’expiration prévue. Après l’enregistrement, vérifiez le fonctionnement du processus concerné et supprimez l’exclusion dès que la cause est résolue et que le retour arrière a été testé.

Démontrer l’effet sur chaque serveur

Ouvrez My Products > Server > Servers, sélectionnez le serveur pilote et contrôlez les points suivants :

Policies : sous Threat Protection, la stratégie attendue est-elle réellement affichée ? Sinon, vérifiez l’affectation, l’activation et l’ordre des stratégies. Un clic sur la stratégie ouvre ses paramètres ; toute modification affectera aussi les autres serveurs auxquels elle est attribuée.
Status : sur les serveurs Windows récents, Health status et les évaluations Communication, Operations, Services, System, Threat et Update signalent d’éventuels problèmes. Sur Linux et les serveurs Windows plus anciens, Security Health indique notamment le dernier contact avec Sophos Fusion et les services Sophos en cours d’exécution ; il ne s’agit pas de la même évaluation détaillée que sous Windows. Un indicateur vert ne prouve pas, à lui seul, que la protection contre les attaques a été testée.
Events : pour la période pertinente, vérifiez les messages, les mises à jour réussies et, le cas échéant, une détection préexistante via Details. L’absence d’événement lié à un logiciel malveillant ne constitue pas un test fonctionnel. Ne déclenchez pas d’action malveillante ou d’exploit dans le seul but de tester un serveur de production. L’indication Last active peut être antérieure à un événement, car elle est actualisée environ une fois par heure.

Pour Linux, vérifiez également sur place la présence du produit antivirus/plugin AV et l’application de la stratégie (les chemins de vérification figurent dans le guide d’installation de SPL). Les onglets Policies, Status et Events, ainsi qu’un indicateur de santé vert, ne prouvent à eux seuls ni que l’analyse à l’accès est active ni qu’elle détecte les menaces. Uniquement sur un système hors production autorisé, un test fonctionnel contrôlé avec le fichier de test inoffensif EICAR, conformément aux instructions Sophos, permet de vérifier la réaction lors de l’accès au fichier, l’entrée dans le journal AV et l’alerte dans Fusion ; supprimez ensuite le fichier de test et traitez l’alerte de test selon la procédure locale. Sans un tel test, la capacité de détection reste non confirmée ; aucun test de malware en production.

Account Health Check signale également les écarts des stratégies Server Threat Protection par rapport aux recommandations Sophos. En cas d’avertissement, ouvrez la stratégie désignée, examinez les paramètres marqués en rouge et corrigez-les de façon ciblée. Fix automatically rétablit les paramètres recommandés pour toutes les options des stratégies concernées et peut écraser des dérogations volontairement choisies pour le pilote ; vérifiez les serveurs concernés et la portée du changement avant de confirmer. Examinez séparément l’avertissement relatif aux Policy exclusions risquées : ce contrôle ne détecte que les exclusions particulièrement dangereuses ; un statut vert ne garantit pas que toutes les exclusions sont sans risque. Là encore, ne lancez aucune correction automatique sans examiner l’ensemble du périmètre des stratégies concernées : elle peut supprimer des exclusions de toutes ces stratégies. Le journal d’audit enregistre les changements automatiques. Après chaque correction, revérifiez la stratégie, le statut et les événements sur le serveur pilote.

Si les résultats ne correspondent pas à la configuration

Stratégie incorrecte ou attendue absente : vérifiez le tenant, le groupe du serveur, l’activation de la stratégie et sa priorité dans la liste. Relevez le nom effectif dans l’onglet Policies du serveur ; ne déduisez pas l’application d’une stratégie de sa seule présence dans la liste.
Analyse en temps réel Linux incertaine : dans la stratégie effective filtrée pour Linux, vérifiez Scan et Enable scan for Server Protection for Linux Agent sous Real-time Scanning - Local Files and Network Shares, ainsi que la présence locale du plugin AV SPL/produit antivirus. Si un élément manque ou si l’effet reste incertain, n’affirmez pas que le serveur est protégé à l’accès aux fichiers, ne déployez pas davantage le pilote et transmettez au support Sophos les détails de l’agent, de la licence et du diagnostic.
Avertissement ou évaluation de santé rouge : sous Windows, ouvrez l’évaluation précise de Communication, Services ou Update ; sous Linux, comparez la dernière activité dans Fusion, les services en cours d’exécution et les alertes. Résolvez d’abord les problèmes de communication ou de mise à jour, puis contrôlez de nouveau la réception de la stratégie.
Application lente ou fichier bloqué : en cas de blocage, vérifiez l’événement survenu au même moment et le chemin ; en cas de baisse de performance sans événement, recueillez des comparaisons reproductibles de la charge et des accès, accompagnées des recommandations de l’éditeur. N’excluez pas une arborescence entière ni tout le tenant sur la base d’un simple soupçon. Une exclusion restreinte au pilote n’est acceptable que si la cause est établie et qu’un retour arrière est prévu. Si l’écart persiste, documentez le constat, l’affectation de la stratégie et le statut de l’agent, puis remontez le problème.

Arrêter le pilote et revenir à l’état antérieur

Suspendez l’extension du déploiement si la protection Linux à l’accès aux fichiers manque, si la stratégie effective est incorrecte, si l’agent reste en mauvais état, si des blocages restent inexpliqués ou si une charge de travail critique subit une perturbation mesurable. Recensez les serveurs concernés et l’écart constaté ; coordonnez le retour arrière avec les responsables des charges de travail pendant la fenêtre de changement. Réaffectez chaque serveur déplacé à son groupe précédent ou retirez-le du groupe pilote s’il n’appartenait auparavant à aucun groupe. Si les modifications du pilote ont touché une stratégie existante, sa priorité ou son affectation, rétablissez également l’ordre, les affectations et les paramètres documentés : le simple retour dans l’ancien groupe ne répare pas une stratégie modifiée. Retirez de manière ciblée les exclusions du pilote après vérification de la charge de travail concernée : assurez-vous d’abord que le blocage ou la dégradation des performances ne réapparaît pas ; si nécessaire, recherchez la cause et documentez entre-temps tout besoin résiduel strictement limité et temporaire, plutôt que de supprimer les exclusions sans contrôle. Vérifiez ensuite sur chaque serveur concerné l’appartenance au groupe, les stratégies effectives, le statut/la santé, les événements et le processus précédemment perturbé. Sans validation concluante, le déploiement reste suspendu et l’incident est remonté.