Installer et déployer Sophos Protection for Linux

Limite importante du produit : la page d’onboarding Sophos intitule certes cette section Deployment to Linux dans le guide Endpoint. Ses liens Linux renvoient toutefois à Server Protection et Sophos Protection for Linux (SPL) dans Sophos Fusion (anciennement Sophos Central). Linux n’utilise donc pas le programme d’installation Endpoint pour Windows et macOS décrit dans les chapitres voisins, mais un agent Linux Server distinct, avec ses propres stratégies, exigences, notes de version et procédures d’installation.

Le parcours complet, de la préparation du tenant à l’exploitation, est décrit dans le parcours d’onboarding Endpoint. Le présent article couvre exclusivement son volet Linux Server.

Pour un seul serveur Linux, choisissez d’abord le mode de protection sous My Environment > Installers : Download Linux Server Installer pour une protection antimalware complète ou Download XDR Sensor Linux Server Installer pour un XDR Sensor sans protection antimalware propre. Rendez exécutable le fichier SophosSetup.sh téléchargé pour le tenant et le mode choisis, puis lancez-le avec les privilèges root. Pour plusieurs systèmes, distribuez ce programme d’installation dans un processus contrôlé et commencez par le tester avec --test. Si SPL doit déjà être présent dans le modèle de VM, suivez la procédure Linux Gold Image documentée afin que chaque clone reçoive sa propre identité d’appareil. Sophos recommande d’envisager cette méthode pour les environnements d’Auto Scaling, de Load Balancing ou comportant un grand nombre de VM.

Avant le premier appareil pilote

N’autorisez l’installation qu’après avoir vérifié les points suivants :

• Licence et niveau de protection souhaité : deux téléchargements Linux distincts sont proposés sous Server Protection. Le XDR Sensor nécessite une licence XDR et, d’après Sophos, ne protège pas lui-même contre les menaces ; une protection tierce doit donc être présente. Vérifiez le mode souhaité et la licence disponible avant le téléchargement.
• Plate-forme prise en charge : la distribution, la version, l’architecture et le noyau doivent correspondre à la matrice de prise en charge SPL actuelle. Sophos répertorie dans les notes de version les plates-formes testées et la configuration système requise. Des limites de support particulières s’appliquent aux variantes non répertoriées, renforcées, minimales, personnalisées ou héritées. SPL n’est pas imposé aux distributions immuables ; Sophos renvoie dans ce cas au Sophos Linux Sensor distinct.
• Configuration de base requise : lors de la révision du contenu du 14 septembre 2026, les notes de version SPL exigeaient 2,5 Go d’espace disque disponible, 2 Go de mémoire disponible, une architecture x86_64 ou ARM64, un systemd pris en charge et actif, Bash, ainsi que glibc 2.17 ou version ultérieure, ou 2.18 ou version ultérieure sur ARM64. ARM64 exigeait en outre un noyau 5.3 ou ultérieur. Le programme d’installation nécessitait curl ; le plug-in AV nécessitait setcap, fourni par libcap2-bin, libcap ou libcap-progs. Cette base datée ne remplace pas le contrôle d’approbation actuel.
• Accès réseau : pendant et après l’installation, l’appareil doit pouvoir joindre Sophos Fusion. Testez DNS, HTTPS, le proxy, l’inspection TLS et, le cas échéant, Message Relay et Update Cache depuis chacun des réseaux de serveurs concernés conformément aux exigences réseau et proxy.
• Protection existante : Sophos Anti-Virus for Linux ne peut pas fonctionner en parallèle avec SPL. Supprimez SAV au préalable ou migrez-le en appelant le programme d’installation avec --uninstall-sav. Avec un XDR Sensor seul, conservez au contraire une protection tierce active, car le capteur n’assure aucune protection antimalware. Pour la protection antimalware SPL complète, évaluez séparément avant le pilote toute cohabitation avec un autre antivirus en vous fondant sur les recommandations des éditeurs concernés.
• Cadre du déploiement : consignez avant le lancement le groupe cible, le groupe Central, le périmètre produit, la taille du pilote, les critères d’arrêt, la fenêtre de maintenance et la procédure de retour arrière.

Maintenir les informations de version, de plate-forme et de réseau

Cet article constitue la base de contrôle interne des exigences propres à Linux. Le responsable vérifie les notes de version SPL et la matrice de prise en charge des distributions et noyaux dans le portail Sophos tous les mois ainsi qu’avant chaque pilote et chaque vague de déploiement. Consignez dans le changement la date du contrôle, la personne responsable, la version de SPL, la distribution, sa version, l’architecture, le noyau, les ressources minimales, les écarts et la décision d’approbation. Si les informations actuelles diffèrent de la base datée ci-dessus, mettez à jour les critères du pilote et cet article avant la vague suivante ; les anciennes valeurs ne valent pas approbation.

Le guide réseau lié est le référentiel du processus commun de liste d’autorisation et de proxy, y compris pour les destinations propres à Linux et à la licence. Pour les packages logiciels, les mises à jour échelonnées, Update Cache et Message Relay, suivez également Sophos Endpoint : mises à jour, cache et Message Relay. Le pilote Linux doit néanmoins valider le chemin réel et la version SPL installée depuis chaque réseau de serveurs prévu.

Vérifier d’abord les systèmes de fichiers et les ressources

Uniquement pour la protection antimalware complète avec le produit antivirus installé : SPL ne peut analyser et mettre en quarantaine de manière fiable que les fichiers placés sur des systèmes de fichiers explicitement pris en charge. Lors du contrôle des sources du 20 septembre 2026, Sophos indiquait bfs, btrfs, cifs, devtmpfs, ecryptfs, ext2, ext3, ext4, fuse, fuseblk, iso9660, jfs, jfs2, msdos, nfs, nfs4, overlay, squashfs, tmpfs, udf, vfat, xfs et zfs. Vérifiez à nouveau cette liste dans la documentation SPL actuelle avant chaque vague. Sur le serveur pilote doté de l’AV, affichez toutes les cibles montées et leur type :

findmnt -rn -o TARGET,FSTYPE

En mode AV, contrôlez non seulement / et le chemin d’installation, mais aussi tous les montages contenant des données métier, des conteneurs, des partages réseau ou des cibles d’analyse prévues. Un système absent de la liste n’est pas approuvé parce qu’un premier test semble fonctionner. Sophos recommande de l’exclure de l’analyse ; le plug-in AV exclut automatiquement les systèmes présentant des problèmes connus et le consigne dans soapd.log. Pour un XDR Sensor seul, les cibles d’analyse, la quarantaine et ce journal AV ne sont pas des critères de validation.

SPL gère les limites de processeur et de mémoire avec les cgroups Linux. D’après Sophos, les valeurs par défaut conviennent à la plupart des environnements : n’ajoutez donc pas de limites globales avant le pilote. Si une contrainte d’exploitation l’exige, mesurez d’abord la charge et la tolérance de l’application, puis lisez le fichier installé localement /opt/sophos-spl/base/etc/cgroup-resource-limits-README.txt. Il fait foi, car les options, composants et valeurs valides peuvent évoluer. Les valeurs personnalisées vont dans /opt/sophos-spl/base/etc/cgroup-limits.conf ; le processeur est exprimé en pourcentage avec %, la mémoire en Mo ou en pourcentage selon l’option. SPL ignore une valeur hors plage et applique sa valeur par défaut. Cet article ne prescrit donc aucun chiffre universel.

Après l’installation ou une modification, effectuez les contrôles suivants selon le mode réellement installé :

1. Uniquement avec antivirus : findmnt indique un type actuellement pris en charge pour chaque cible d’analyse prévue.
2. Si les limites cgroup ont été personnalisées : /opt/sophos-spl/logs/base/watchdog.log confirme la configuration appliquée aux composants réellement installés et ne contient aucune erreur de configuration.
3. Si les limites cgroup ont été personnalisées : le journal système ne contient aucun arrêt de processus provoqué par le cgroup SPL. Tous les systèmes Linux ne conservant pas les journaux après un redémarrage, configurez leur conservation persistante selon la politique d’exploitation locale si l’historique des erreurs doit être préservé.

Installation individuelle depuis Sophos Fusion

1. Dans Sophos Fusion, accédez à My Environment > Installers.
2. Dans la section Server Protection, choisissez le téléchargement Linux adapté : Download Linux Server Installer pour une protection antimalware complète ou Download XDR Sensor Linux Server Installer pour un XDR Sensor seul (licence XDR et protection tierce active requises). N’utilisez pas le programme d’installation Endpoint pour Windows ou macOS. Le Sophos Linux Sensor (SLS) proposé séparément n’est pas le SPL XDR Sensor.
3. Transférez SophosSetup.sh vers le serveur Linux cible par un canal protégé contre les accès non autorisés.
4. Accédez au répertoire de téléchargement et accordez le droit d’exécution :

chmod +x SophosSetup.sh

5. Commencez par exécuter les contrôles préalables sans installer le produit :

sudo ./SophosSetup.sh --test

6. Si les contrôles réussissent, lancez le programme d’installation :

sudo ./SophosSetup.sh

Sans --install-dir, SPL s’installe dans /opt/sophos-spl/. La fin sans erreur du processus shell ne constitue pas encore une validation du déploiement ; vérifiez ensuite l’enregistrement, les composants réellement installés, les stratégies appropriées et l’état d’intégrité dans Central et localement. Les contrôles AV décrits plus bas ne s’appliquent pas à un XDR Sensor seul.

Télécharger le programme d’installation directement sur le serveur

Pour un téléchargement manuel depuis le shell, copiez dans Sophos Fusion l’adresse du lien du programme d’installation Linux choisi au préalable (protection complète ou XDR Sensor) et utilisez-la à la place du paramètre fictif dans la commande suivante :

wget '<LINUX-INSTALLER-LINK>' -O SophosSetup.sh
chmod +x SophosSetup.sh
sudo ./SophosSetup.sh --test
sudo ./SophosSetup.sh

Remplacez <LINUX-INSTALLER-LINK> par l’adresse copiée depuis votre tenant pour le mode choisi. Ne placez ni cette URL ni le fichier téléchargé dans des dépôts de scripts publics, des tickets ou des partages librement accessibles. Pour les déploiements reproductibles, distribuez l’artefact d’installation par le mécanisme protégé de gestion des packages ou des secrets de votre plate-forme.

Déployer plusieurs systèmes Linux par script

Commencez un déploiement de masse par quelques serveurs représentatifs. Le pilote doit couvrir les différences de distribution, noyau, architecture, durcissement, chemin proxy, site, charge de travail et logiciel de sécurité existant. Ne passez à la vague limitée suivante qu’après validation du pilote.

Le script suivant est uniquement un exemple pour la protection antimalware complète avec XDR sous licence supplémentaire, et non pour un XDR Sensor seul. Il utilise le Linux Server Installer téléchargé pour ce mode, affecte l’appareil au sous-groupe LinuxServers\Pilot et demande les composants antivirus et xdr :

#!/usr/bin/env bash
set -euo pipefail

if (( EUID != 0 )); then
  printf 'Ce script de déploiement doit être exécuté en tant que root.\n' >&2
  exit 1
fi

installer='/var/tmp/SophosSetup.sh'
chmod 700 "$installer"

"$installer" --test
"$installer" \
  --group='LinuxServers\Pilot' \
  --products=antivirus,xdr \
  --tag=Rollout:wave-0 \
  --tag=ManagedBy:automation

Adaptez le chemin de groupe à votre structure Central. Si le groupe ou sous-groupe indiqué n’existe pas encore, le programme d’installation le crée. Vérifiez donc le chemin au caractère près avant le déploiement : une faute de frappe peut créer un groupe indésirable. Avec --products, les produits sans licence ne sont pas installés ; selon la page CLI actuelle, les valeurs autorisées sont antivirus, mdr et xdr. Plusieurs arguments --tag=<key>:<value> ajoutent des tags à l’appareil. Si une clé est répétée, Central n’affiche que la dernière valeur transmise.

Dans cet exemple, set -euo pipefail évite que le script poursuive silencieusement son exécution comme si elle avait réussi après l’échec d’un contrôle préalable ou de l’installation. La solution de distribution logicielle doit reprendre le véritable code de sortie et ne pas relancer indéfiniment l’installation sur les hôtes en échec. Sophos ne publiant pas de tableau permanent des codes de sortie numériques sur la page CLI, la décision repose sur la validation locale et dans Central, et non sur une correspondance de codes inventée.

Principales options du programme d’installation

Les variables d’environnement se placent avant l’appel du programme d’installation, les options de ligne de commande après celui-ci.

Les options --user-ids-to-configure et --group-ids-to-configure permettent d’imposer les UID et GID des comptes et groupes créés par SPL. Utilisez-les uniquement si les règles locales d’identité ou de durcissement exigent des identifiants fixes ; Sophos limite explicitement leur effet aux comptes et groupes SPL documentés.

Avec --install-dir=<basis>, SPL se trouve sous <basis>/sophos-spl. Adaptez en conséquence tous les chemins de journaux, de version, d’enregistrement et de désinstallation indiqués plus loin ; les chemins /opt/sophos-spl/... de cet article correspondent à l’installation par défaut. Les chemins du plug-in AV ne concernent en outre que les hôtes sur lesquels le produit antivirus est installé.

Imposer Message Relay et Update Cache

En règle générale, SophosSetup.sh contient les Relays et Caches configurés dans Central. Le programme d’installation les classe selon la proximité numérique avec l’adresse IP de l’appareil et utilise le service accessible le plus proche ; si aucun ne l’est, il contacte directement Central. Vous pouvez remplacer explicitement cette sélection pour l’installation :

sudo ./SophosSetup.sh \
  --message-relays=192.0.2.10:8190 \
  --update-caches=192.0.2.10:8191

192.0.2.10 est une adresse réservée à la documentation et doit être remplacée. Sophos indique le port 8190 pour Message Relay et 8191 pour Update Cache. La valeur none force la connexion directe à Central pour l’option concernée. Cette substitution s’applique à l’installation ; ensuite, l’agent utilise de nouveau les services configurés les plus proches, sauf si l’appareil est affecté manuellement dans Central.

Gold Image pour les systèmes Linux virtuels

Ne clonez pas tel quel un système Linux déjà installé et enregistré. Avant d’enregistrer le modèle, désenregistrez la VM Gold Image de Sophos Fusion. Chaque clone lancé à partir de celle-ci s’enregistre ensuite automatiquement avec une identité propre dès son démarrage et son accès au réseau.

1. Préparez entièrement le système d’exploitation et les applications de la VM maître.
2. Sous My Environment > Installers, téléchargez Linux Server Installer ou XDR Sensor Linux Server Installer, selon le mode de protection prévu.
3. Installez SPL comme décrit plus haut, puis vérifiez son état.
4. Accédez au répertoire d’enregistrement et désenregistrez la VM maître :

cd /opt/sophos-spl/base/bin/
sudo ./registerCentral --deregister

5. Arrêtez immédiatement la VM et enregistrez l’image lorsqu’elle est hors tension.
6. Ne redémarrez pas la VM maître après son désenregistrement. Un redémarrage l’enregistre de nouveau ; vous devrez alors la désenregistrer une nouvelle fois avant d’enregistrer l’image.
7. Démarrez au moins deux clones à partir de l’image enregistrée et vérifiez qu’ils apparaissent comme deux appareils distincts dans Central.

Si l’emplacement d’installation a été modifié avec --install-dir, le répertoire sophos-spl se trouve sous le chemin indiqué. Exécutez alors la commande Gold Image depuis le répertoire base/bin correspondant de cette installation.

Valider l’installation

Le pilote n’est validé que si tous les contrôles suivants réussissent :

1. Sous My Products > Server > Servers, chaque hôte apparaît exactement une fois avec l’objet appareil attendu. Sur la page de détails du serveur, l’état d’intégrité, la dernière activité et les composants installés doivent être cohérents.
2. L’appareil se trouve dans le groupe prévu et reçoit les stratégies Server correspondant aux composants réellement installés. Pour la protection antimalware complète, cela inclut la stratégie Server Threat Protection effective ; pour les stratégies de mise à jour, la première stratégie correspondante s’applique.
3. Le service fonctionne localement :

sudo systemctl status sophos-spl

4. Uniquement si le produit antivirus est installé : la version de Server Protection affichée dans Central correspond à la version locale :

sudo cat /opt/sophos-spl/plugins/av/VERSION.ini

Sophos désigne précisément ce fichier du plug-in AV pour comparer les versions. Pour un XDR Sensor seul, ne présumez pas qu’il existe : comparez plutôt, sur la page de détails du serveur, les composants réellement installés, leurs versions affichées, l’état d’intégrité et la dernière activité avec le mode capteur choisi. Vérifiez localement la connexion à Sophos Fusion dans le journal MCS/de gestion adapté à la version installée : /opt/sophos-spl/logs/base/sophosspl/management.log ou, éventuellement pour les packages LTS, les anciens journaux mcsrouter.log et sophos_managementagent.log. Vérifiez les noms et chemins des journaux sur le package installé ; ne déduisez pas le fonctionnement du capteur de la seule présence ou absence d’un journal ou d’un chemin AV.

5. Uniquement si le produit antivirus est installé : pour le test EICAR On-Access, les options Real-time scanning - Local files and network shares et Enable scan for Server Protection for Linux Agent doivent être activées dans la stratégie Server Threat Protection effective ; l’option propre à Linux est désactivée par défaut. Vérifiez ensuite la détection dans /opt/sophos-spl/plugins/av/log/av.log et sur la page Server Summary. Un XDR Sensor seul ne fournit ni cette détection antimalware ni d’analyses à la demande ; vérifiez séparément que la protection antimalware tierce reste active, suivant la procédure documentée par son éditeur.

Arrêtez le déploiement élargi si des appareils sont absents, apparaissent en double, restent en mauvais état, ne reçoivent pas les composants ou stratégies attendus, ou si des charges de travail critiques sont perturbées.

Arrêter, annuler ou supprimer le déploiement

Le retour arrière commence par l’arrêt de la distribution. Interrompez les nouvelles affectations de cibles et les nouvelles tentatives automatiques, isolez la vague touchée et conservez le dernier état fonctionnel de la VM, des packages ou de la configuration. Une désinstallation ne restaure pas automatiquement les logiciels de protection tiers supprimés ou remplacés.

Pour la procédure complète de suppression locale, de nettoyage des cgroups, de vérification, de traitement de l’enregistrement Central et de restauration, consultez Désinstaller complètement Sophos Protection for Linux. Conservez les commandes de suppression dans ce runbook au lieu de les copier dans une tâche d’installation ou de déploiement.

Tamper Protection n’est pas disponible pour Sophos Protection for Linux et ne s’applique donc pas à ce retour arrière. Vérifiez néanmoins les stratégies Server restantes, rétablissez la protection prévue et décidez du traitement de l’enregistrement de l’appareil dans Central avant de clôturer le changement.

Dépannage par symptôme

Échec de --test ou de l’installation

Conservez la commande exacte, la distribution, le noyau, l’architecture et la sortie. Lorsqu’il détecte un échec d’installation, Thin Installer lance automatiquement Sophos Diagnostic Utility (SDU) et crée un fichier sophos_diagnose.tgz dans son propre répertoire. Cette archive contient les journaux d’installation et des informations système destinées au support Sophos.

N’exécutez la commande suivante qu’à la demande du support Sophos ou pour une reproduction contrôlée. Elle relance le programme d’installation, active les traces du shell et conserve le répertoire d’installation temporaire :

sudo OVERRIDE_INSTALLER_CLEANUP=1 \
  DEBUG_THIN_INSTALLER=1 \
  bash -x ./SophosSetup.sh 2>&1 | tee install.log

OVERRIDE_INSTALLER_CLEANUP=1 conserve le répertoire temporaire /tmp/SophosCentralInstall_<uuid>. Les journaux peuvent contenir des noms d’hôtes, des chemins internes et des informations réseau ; contrôlez-les avant de les transmettre.

/tmp est monté avec noexec

Ne réduisez pas durablement la protection de /tmp. Créez un chemin temporaire exécutable approprié et définissez TMPDIR uniquement pour le programme d’installation :

sudo TMPDIR=/var/tmp ./SophosSetup.sh --test
sudo TMPDIR=/var/tmp ./SophosSetup.sh

TMPDIR modifie uniquement l’emplacement temporaire, pas la destination d’installation standard /opt/sophos-spl.

L’appareil n’apparaît pas dans Sophos Fusion

Vérifiez d’abord DNS, TCP 443, le proxy, l’inspection TLS et la liste actuelle des domaines autorisés. Recherchez ensuite le chemin de connexion retenu et la confirmation d’une connexion réussie dans le journal MCS/de gestion adapté à la version installée : /opt/sophos-spl/logs/base/sophosspl/management.log ou, éventuellement pour les packages LTS, les anciens journaux mcsrouter.log et sophos_managementagent.log. Vérifiez les noms et chemins des journaux sur le package installé. Sophos affiche par exemple dans le management.log actuel Successful connection via environment proxy et Connection method: Proxy.

Si un appareil Linux qui n’est pas encore géré ne peut pas obtenir la configuration proxy de Central, Sophos documente comme solution d’amorçage un fichier contenant http_proxy=https://<PROXY_ADDRESS>:<PROXY_PORT> : sous /etc/default/sophos-spl sur les systèmes basés sur Debian et sous /etc/sysconfig/sophos-spl sur RHEL, CentOS et Amazon Linux. Exécutez ensuite :

sudo systemctl restart sophos-spl
sudo systemctl status sophos-spl

Contrôlez ensuite le journal MCS/de gestion adapté à la version installée (éventuellement mcsrouter.log et sophos_managementagent.log pour les packages LTS).

La protection antimalware complète est installée, mais Real-Time Scanning ne fonctionne pas

Uniquement si le produit antivirus est installé : sous My Products > Server > Policies, ouvrez la stratégie Threat Protection effective. Les options Real-time scanning - Local files and network shares et Enable scan for Server Protection for Linux Agent doivent toutes deux être activées. Pour le diagnostic local, Sophos indique les fichiers de stratégie /opt/sophos-spl/base/mcs/policy/CORC_policy.xml et /opt/sophos-spl/plugins/av/var/on_access_policy.json, ainsi que le journal /opt/sophos-spl/plugins/av/log/soapd.log. Ce symptôme ne concerne pas un XDR Sensor seul : sa protection antimalware doit être assurée par un tiers.

Échec d’un chemin d’installation personnalisé avec SELinux Enforcing

Ne contournez pas le problème avec --notest ou en désactivant globalement SELinux. Le nouveau répertoire de base ne doit être ni un lien symbolique ni contenir déjà un sous-répertoire sophos-spl. Après sa création, appliquez-lui le contexte SELinux de /opt :

sudo semanage fcontext -a -e /opt <PFAD_ZUM_NEUEN_INSTALLATIONSVERZEICHNIS>

Lancez ensuite le programme d’installation avec la valeur --install-dir vérifiée. Si semanage manque, installez d’abord le package de gestion SELinux adapté à la distribution ; ne désactivez pas ce contrôle de sécurité.

Une cible d’analyse AV n’est pas analysée ou des processus sont arrêtés

Uniquement si le produit antivirus est installé : pour une cible d’analyse manquante, vérifiez d’abord le type et le point de montage avec findmnt -rn -o TARGET,FSTYPE. Recherchez is not supported and will be excluded from scanning dans /opt/sophos-spl/plugins/av/log/soapd.log. Ne forcez pas avec --notest un système exclu automatiquement ou non documenté ; laissez-le hors analyse jusqu’à l’utilisation d’un type actuellement pris en charge ou à la confirmation de Sophos Support pour cette configuration précise.

En cas d’arrêt inattendu, consultez /opt/sophos-spl/logs/base/watchdog.log, puis le journal du noyau :

sudo journalctl -k -b

Conservez les messages oom-kill, Memory cgroup out of memory ou de valeurs rejetées avec la cgroup-limits.conf effective et la charge au moment de l’incident. Ne remplacez pas un chiffre à l’aveugle : une limite SPL trop large peut évincer l’application, tandis qu’une limite trop stricte peut arrêter les processus de protection. Modifiez pendant une fenêtre de maintenance selon le README local ; Sophos exige l’arrêt de sophos-spl.service avant l’édition, puis son redémarrage. Revérifiez l’état du service, watchdog.log, le journal, l’état Central et l’application critique.

Les clones partagent une identité ou le modèle réapparaît

Arrêtez le provisionnement. Vérifiez que la VM maître a bien été arrêtée après registerCentral --deregister et que l’image a été enregistrée hors tension. Si elle a redémarré, désenregistrez-la de nouveau avant d’enregistrer l’image. N’utilisez pas un clone défectueux comme nouveau modèle ; recréez-le depuis la Gold Image correctement préparée.

Questions fréquentes