Sophos Server Protection : valider les plateformes Windows et Linux en toute sécurité

Décision en bref : N’inclure un serveur dans la prochaine vague d’installation ou de mise à jour que si son système d’exploitation précis et son agent correspondent aux conditions de prise en charge actuelles de Sophos, si les fonctions nécessaires sont disponibles dans le tenant concerné et si un pilote représentatif reste sain. Une ligne dans d’anciennes notes de version prouve seulement que des composants ont existé pour une plateforme, pas que son système d’exploitation est encore pris en charge sans restriction. En l’absence de preuve fiable, exclure le serveur de la vague et soumettre la question de la plateforme au support Sophos.

Ce guide aide à décider de la validation avant une nouvelle installation, un changement de système d’exploitation ou une mise à jour de l’agent. Les procédures proprement dites pour Windows Server et Sophos Protection for Linux (SPL) figurent dans leurs guides d’installation respectifs.

Vérifier séparément la version publiée et la prise en charge

Lors de la vérification du 24 septembre 2026, les notes de version Sophos du Server Core Agent pour Windows indiquent 2026.2.2.1 (septembre 2026) comme version la plus récente, avec des sections de composants distinctes pour Windows Server 2016 et versions ultérieures, et pour les anciennes plateformes legacy. Les notes de version actuelles du Windows Server Core Agent font référence pour les changements de versions et de composants. Elles précisent également que le déploiement du logiciel peut s’étaler sur plusieurs semaines après leur publication. Une section de composants, ancienne ou récente, ne valide pas une édition ni un build Windows précis.

Selon les Windows Server System Requirements de Sophos (KBA-000003024, état au 7 mai 2026), Windows Server 2016, 2019, 2022 et 2025 sont des générations de serveurs entièrement prises en charge. Windows Server 2008 R2 ainsi que 2012 et 2012 R2 sont des plateformes legacy nécessitant une licence Extended Support ; certaines fonctions peuvent y manquer ou ne plus être prises en charge ou mises à jour. Sensor Mode n’est pas pris en charge sur les plateformes legacy. Ce relevé daté ne valide pas indistinctement toutes les éditions, architectures ou variantes de build. Avant la vague, inventorier l’édition exacte, le build complet du système, l’architecture, la version de l’agent, le mode de protection souhaité et, pour les hôtes legacy, le droit effectif à l’Extended Support. Pour la combinaison précise, vérifier les Windows Server System Requirements actuels de Sophos, les variantes Windows prises en charge et le calendrier de retrait. Si la page de support Sophos est inaccessible ou ne répond pas clairement, suspendre la validation et consulter le support Sophos. Un agent qui démarre ou une entrée dans les notes de version ne prouvent pas à eux seuls la prise en charge.

Vérifier les ressources selon la licence et le mode : Au 7 mai 2026, Sophos Endpoint – Server exige au minimum 8 Go d’espace disque libre, 8 Go de RAM et 2 cœurs. Pour Sophos EDR, XDR et MDR – Server, le minimum est de 10 Go d’espace disque libre, 8 Go de RAM et 2 cœurs ; les valeurs recommandées sont 10 Go d’espace disque libre, 16 Go de RAM et 4 cœurs. Ces exigences s’appliquent à Full Protection comme à Sensor Mode : le tableau des ressources n’annule pas l’interdiction de Sensor Mode sur les plateformes legacy. Sophos recommande vivement un SSD pour le disque de démarrage. Ces chiffres sont des repères généraux et non une garantie de performances pour toute charge serveur : détection et nettoyage de logiciels malveillants peuvent augmenter temporairement l’utilisation du processeur, de la RAM et du disque. Vérifier les marges et le comportement dans son propre pilote.

Pour Linux, les notes de version SPL indiquent 2026.3 (septembre 2026) comme version la plus récente à la même date de vérification. Là encore, sa mise à disposition dans le tenant peut intervenir après la publication des notes. Sous System requirements, les exigences actuelles comprennent au minimum 2,5 Go d’espace disque libre, 2 Go de mémoire vive disponible, une architecture x86_64 ou ARM64, systemd en cours d’exécution, Bash et glibc version 2.17 ou supérieure ; sur ARM64, il faut glibc version 2.18 ou supérieure et un noyau version 5.3 ou supérieure. Ces valeurs constituent une base de vérification datée, et non une validation permanente de toutes les distributions Linux et de tous les noyaux.

Les indications de Sophos sur les distributions et noyaux SPL renvoient, pour la liste actuelle des plateformes, à System requirements > Supported platforms dans les notes de version ; elles ne constituent pas une deuxième matrice de validation indépendante. Distribution, version majeure et mineure, architecture, noyau en cours d’exécution et prise en charge par l’éditeur doivent tous être compatibles. À la date de vérification indiquée, la liste des plateformes testées comprend notamment RHEL 8–10, Debian 11–13, Ubuntu 22.04/24.04 LTS et Ubuntu 26.04 ; une liste legacy distincte existe également, sans constituer une validation automatique. Sophos teste les dernières versions mineures actives ou les derniers Service Packs ; des versions minimales du noyau propres à chaque distribution peuvent s’appliquer à x86_64. Le noyau 5.3 ne constitue donc pas une validation générale pour x86_64. Un noyau au-dessus du minimum peut lui aussi poser problème : les notes actuelles signalent, de 5.10.133 à 5.10.142, un problème connu avec ftrace susceptible de bloquer le noyau. Ne pas valider cette combinaison sur la seule foi d’une installation sans incident ; vérifier au préalable le noyau et les recommandations Sophos.

Distinguer les exceptions avant le pilote : Si l’image Linux est immutable, ne pas valider SPL ici : Sophos indique que SPL n’est pas conçu pour les distributions immutables et oriente ces plateformes vers le produit distinct Sophos Linux Sensor (SLS). SLS n’est pas le capteur XDR de SPL ; ce guide ne décrit pas l’installation de SLS. Les distributions dérivées non répertoriées, les noyaux personnalisés ou minimaux et les systèmes durcis ne deviennent pas automatiquement des plateformes testées : Sophos prévoit dans ces cas un examen au mieux des efforts raisonnables et peut demander une reproduction sur une plateforme prise en charge ou une mise à niveau.

Pour un hôte Linux legacy existant, vérifier en outre son droit effectif à l’Extended Support ainsi que le package logiciel installé et celui attribué par Update Management. Au 24 septembre 2026, Sophos indique pour les versions legacy le package LTS pris en charge 2026.1.0.35 et recommande de l’attribuer via Update Management ; en cas de problème avec un package plus récent, un retour au package pris en charge peut être nécessaire pour l’analyse. Avant toute modification, vérifier les indications Sophos alors en vigueur et la disponibilité effective du package : l’annonce de SPL 2026.3 n’en fait pas automatiquement la cible d’un hôte legacy, et 2026.1.0.35 n’est ni une garantie permanente ni une procédure générale de rétrogradation.

Documenter la validation d’une vague précise

Un bref relevé de vérification évite de prendre une installation fonctionnelle pour une preuve de prise en charge. Consigner séparément pour chaque famille de serveurs, par exemple les serveurs applicatifs Windows et les serveurs de bases de données Linux :

État actuel et cible : rôle du serveur, édition du système d’exploitation ou distribution et version mineure, build complet ou résultat de uname -r, architecture, agent installé avec ses composants et version cible envisagée. Sous Windows, vérifier le type de licence (Endpoint – Server ou EDR/XDR/MDR – Server), Full Protection ou Sensor Mode, l’espace disque libre, la RAM, les cœurs et le disque de démarrage. Sous Linux, vérifier aussi le type d’image (immutable ou modifiable), la mémoire vive et l’espace disponibles sur le volume réel d’installation, l’exécution de systemd, Bash et glibc. Pour Linux legacy, relever séparément le package installé et le package attribué.
Justificatifs : consigner la date et la version des exigences système Windows et des notes de version Windows ou SPL, les exigences actuelles relatives au système d’exploitation et au noyau, le cycle de vie et l’Extended Support avec le droit effectif des hôtes legacy, ainsi que la licence et les fonctions requises dans le tenant. Pour Windows, sans preuve explicite pour l’édition, le build, l’architecture et le mode de protection, inscrire « à clarifier » et non « compatible ». L’annonce d’une nouvelle fonction dans les notes de version, par exemple Linux comme Update Cache ou Message Relay à partir de SPL 2026.3, ne remplace ni sa disponibilité réelle dans le tenant ni la vérification de ses prérequis propres.
Décision : « validé pour le pilote », « mettre d’abord à jour le système d’exploitation ou le noyau » ou « arrêter et consulter le support ». Désigner la personne qui valide, la fenêtre de changement, les machines pilotes et les critères d’arrêt. La première option exige une preuve positive de prise en charge de la plateforme ; un build dérivé non testé n’équivaut pas à une combinaison testée. Linux immutable reste exclu de la vague SPL ; pour Linux legacy, ne poursuivre qu’après confirmation du droit à la prise en charge, d’une attribution de package appropriée et d’une preuve actuelle de prise en charge.

Sur le pilote Linux, exécuter ces commandes en lecture seule sur le serveur cible, aussi près que possible de la fenêtre de changement, et conserver leurs sorties :

cat /etc/os-release
uname -r; uname -m
free -m
df -h -- /opt
ps -p 1 -o comm=; test -d /run/systemd/system && printf 'systemd läuft\n'
command -v bash; getconf GNU_LIBC_VERSION

Pour free -m, comparer la colonne available (et non total) aux 2 Go de mémoire disponible exigés. df -h -- /opt n’est pertinent pour une installation standard que si /opt se trouve sur le volume réellement utilisé ; en présence d’un montage distinct ou de l’option --install-dir, utiliser plutôt df -h -- <Pfad> avec un chemin déjà existant sur le volume réel d’installation et confirmer que 2,5 Go sont libres. Si ce volume ne peut pas encore être déterminé, ne pas valider les ressources. ps et le répertoire /run/systemd/system vérifient le système d’initialisation en cours d’exécution ; Bash doit être trouvé et la version de glibc affichée doit convenir à l’architecture. Vérifier en plus le caractère immutable d’après le type d’image ou de système d’exploitation dans l’inventaire de déploiement : os-release seul ne prouve pas que l’hôte est modifiable. Pour Windows, conserver les informations complètes sur le système et l’agent provenant de l’inventaire administré et des propriétés système, ainsi que les ressources correspondant à la licence et au mode de protection prévus. Répéter cette vérification si le système d’exploitation, le noyau, l’agent, la licence ou les exigences Sophos changent ; ne pas se fier uniquement à la date de cet article.

Pilote, état de santé et vague suivante

Choisir d’abord un serveur représentatif par combinaison de plateformes concernée : même version mineure du système, même architecture et même noyau, chemin réseau ou proxy similaire, rôle et charge comparables. Avant le pilote, vérifier les sauvegardes et la procédure de restauration, garantir un accès console ou hors bande et réserver une fenêtre de maintenance prévoyant un éventuel redémarrage. Une base de données sujette à des pics d’E/S particuliers nécessite un test de charge adapté ; démarrer une VM de test vide ne suffit pas.

Après installation ou mise à jour, dans My Products > Server > Servers du bon tenant, vérifier que le pilote apparaît une seule fois, communique régulièrement, possède les composants de protection attendus et le groupe de serveurs prévu, et ne présente pas d’alerte de santé persistante. Comparer les composants et versions installés sur la machine et dans Fusion ; vérifier la politique serveur effectivement appliquée à l’hôte, pas seulement son attribution à un groupe. Sous Linux, vérifier aussi sudo systemctl status sophos-spl. Uniquement si le plugin antivirus est installé, lire sudo cat /opt/sophos-spl/plugins/av/VERSION.ini pour le chemin standard (adapter ce chemin si --install-dir a été modifié) et comparer sa version à celle du composant Server Protection, et non du composant de base SPL, dans Central. Sur un capteur SPL-XDR dépourvu de plugin antivirus, vérifier plutôt dans Central les composants réellement installés, leurs versions et leur état de santé ; l’absence du fichier antivirus n’est alors pas une erreur. Un service en bonne santé ne confirme à lui seul ni une protection antimalware à jour ni l’application effective d’une politique. Uniquement si la protection antivirus est installée et après avoir vérifié que les options Real-time scanning - Local files and network shares et Enable scan for Server Protection for Linux Agent sont toutes deux actives dans la Server Threat Protection Policy effectivement appliquée, effectuer un test de détection à l’accès planifié et sans risque selon le guide d’installation Linux ; un simple capteur XDR n’est pas adapté à ce test.

Comparer ensuite le fonctionnement de l’application métier, les redémarrages, les connexions réseau et la charge habituelle à l’état antérieur. Pour une nouvelle fonction de l’agent, vérifier d’abord qu’elle est effectivement proposée au pilote dans le tenant. La vague suivante, de taille limitée, ne commence que lorsque la preuve de prise en charge de la plateforme, l’état de l’agent et de la politique, la santé et le test applicatif sont tous satisfaisants. Les notes de version peuvent paraître avant la mise à disposition du logiciel : si la version effectivement proposée diffère, vérifier la situation plutôt que de forcer un téléchargement.

Prévoir l’arrêt et le retour arrière

Avant la modification, noter les versions fonctionnelles du système d’exploitation, du noyau et de l’agent ; pour Linux legacy, relever aussi les packages installé et attribué, la sauvegarde, la fenêtre de maintenance, le mode de protection et la personne responsable. La présence d’une ancienne version de l’agent dans des notes de version historiques ne garantit pas la possibilité d’y revenir. Pour un retour arrière du système ou du noyau, vérifier séparément la capacité à démarrer, l’intégrité des données et la prise en charge de l’état cible. Même si Sophos peut demander, pour un incident sous Linux legacy, le retour au package pris en charge, les packages Sophos et les politiques de mise à jour ne sont pas un mécanisme universel de rétrogradation ; clarifier au préalable avec Sophos la procédure applicable à l’hôte concerné.

En cas d’échec d’enregistrement, d’état de santé durablement dégradé, de protection inadéquate, de redémarrages inattendus ou de perturbation d’une application serveur, arrêter immédiatement le déploiement et les nouvelles tentatives automatiques, isoler le périmètre des hôtes concernés et ne lancer aucune autre vague. Comparer d’abord au relevé le tenant, la connexion, la politique effectivement appliquée, la version de l’agent proposée et les écarts de système ou de noyau. Limiter toute correction de politique au pilote et la valider à nouveau ensuite ; ne pas désactiver la protection sur l’ensemble du tenant. Si un retour arrière s’impose, suivre la procédure de restauration du système définie et testée à l’avance ainsi que la procédure du support Sophos correspondant à la version précise de l’agent. Ne supprimer aucun composant ni pilote au hasard. Si la prise en charge de la plateforme ou une procédure de retour prise en charge reste incertaine, conserver les journaux et les données de plateforme et solliciter le support Sophos ; la vague de déploiement reste suspendue jusque-là.