Choisir, installer et vérifier Sophos Linux Sensor

Sophos Linux Sensor (SLS) collecte des événements d’exécution Linux et les traite avec le Detection Content pour produire des alertes ou des réponses configurées. Il peut s’intégrer à une infrastructure existante de journalisation et d’alertes. SLS est un capteur distinct : ce n’est ni Sophos Protection for Linux (SPL), ni son XDR Sensor, ni une stratégie SPL de détection à l’exécution.

Pour un premier pilote, on vérifie plateforme et droit d’utilisation, choisit la méthode d’installation et déploie capteur et contenu. On suit ensuite une alerte de test jusqu’au destinataire réellement prévu. Un service actif ne suffit pas. Cette procédure décrit le déploiement direct sur un hôte systemd ; les conteneurs et Kubernetes suivent une autre méthode.

Clarifier licence et modèle d’exploitation

L’aide Sophos vérifiée le 27 octobre 2026 cite Sophos XDR Powered by Secureworks (Server), Sophos MDR (Server) ou Sophos MDR Plus (Server) comme produits donnant accès à SLS. Les licences d’évaluation ne sont pas éligibles. Une licence endpoint quelconque ou la simple présence d’un serveur Linux ne prouve pas ce droit.

SLS est licencié par appareil. Pourtant, selon Sophos, ses instances ne figurent ni dans la liste des serveurs Fusion ni dans la vue Devices ou son décompte de licences. On tient donc un inventaire séparé des capteurs installés. Fusion peut recevoir les détails de détection et alertes SLS, mais ne gère pas le capteur. L’absence d’une entrée serveur SLS n’équivaut donc pas à un échec d’enregistrement SPL.

Pour un agent serveur géré classique avec les composants SPL souhaités, on utilise Sophos Protection for Linux. L’adéquation de SLS aux images immuables ou aux plateformes de conteneurs particulières se vérifie séparément : citer un tel usage n’autorise pas toutes les combinaisons distribution/noyau/runtime.

Préparer la plateforme et le pilote

Au moment de la vérification, les notes SLS demandent au minimum 2 Go d’espace disque libre, 2 Go de mémoire libre et x86_64 ou ARM64. ARM64 exige un noyau 5.3 ou ultérieur. La distribution précise, son niveau mineur actuel et le noyau en cours doivent aussi correspondre à la liste des plateformes testées. Le minimum d’une autre distribution n’est pas une autorisation générale. Les plateformes legacy ont des conditions de support distinctes.

Avant le pilote, on relève rôle de l’hôte, distribution, architecture, noyau, protection existante, profil de charge et destinataire des alertes. L’installation directe nécessite les droits root/de gestion des paquets, un fonctionnement systemd adapté et le sous-système de débogage Linux requis par SLS disponible ou autorisé. On n’affaiblit pas préventivement un système durci pour faire avancer un script.

Sophos propose une méthode Helm dédiée à Kubernetes ; Docker, CRI-O et containerd ont aussi leurs instructions. Accès au registre, visibilité sur l’hôte, droits, image de contenu et runtime font partie des vérifications. Une commande de paquets de cet exemple hôte ne se transpose pas telle quelle dans un conteneur capteur.

Préparer le token de registre dans le bon tenant

SLS utilise un Package Registry API Token distinct dont la valeur commence par SLS-. Ce n’est ni l’access token OAuth de courte durée ni le Client Secret d’une identité API.

La procédure SLS actuelle exige un Super Admin dans le tableau de bord Fusion Admin du client, pas celui d’un Partner ou Enterprise. Sous Global Settings > Administration > API Credentials Management > Add Credential, on crée l’identité nécessaire avec Service Principal Super Admin. Le responsable autorise d’abord cette exigence étendue du fabricant ; elle ne devient pas la règle pour tout projet API. Le Client ID et le Client Secret, visible une seule fois, sont conservés de façon sûre.

Le processus d’identifiants API et OAuth permet d’obtenir le bearer token et, avec whoami/v1, l’identifiant unique du tenant client. Ici, idType doit confirmer ce tenant. Un identifiant partenaire ne convient pas. On effectue ensuite un POST vers /accounts/v1/access-tokens sur l’hôte API global Sophos, avec authentification Bearer, X-Tenant-ID et ce JSON :

{
  "label": "SLS Pilot",
  "type": "sophosLinuxSensor"
}

label est un nom de gestion libre ; type est une valeur API fixe. Dans la réponse, le champ token, et non l’identifiant de l’objet, sert à accéder au registre. Un expiresAt facultatif est choisi selon le plan d’accès ; Sophos indique qu’une date dépassant l’expiration de la licence serveur est ramenée à cette expiration. Un exemple éloigné dans le temps ne donne pas un droit permanent.

On vérifie statut et contenu de la réponse HTTP. Tokens et secrets ne doivent pas apparaître dans l’historique du shell, les diagnostics proxy, tickets ou captures. Les erreurs de tenant, de droit ou de token sont clarifiées avant toute autre action ; on ne modifie pas à l’aveugle protections ou permissions de tout le tenant.

Installer sur un hôte par le gestionnaire de paquets

On prépare d’abord l’accès au registre SLS dans le processus de paquets approuvé. Sophos documente packages.sophos.com/sophos-linux-sensor/release/ et la clé sophos-linux-sensor-archive-keyring.gpg. On obtient cette clé par la voie fabricant authentifiée et l’enregistre sous /etc/sophos-linux-sensor.gpg. Avant utilisation, provenance et empreinte actuelle sont vérifiées par la chaîne de confiance autorisée. gpg --list-packets montre seulement un paquet de clé lisible ; cela ne prouve pas sa provenance fiable.

Hôtes Debian pris en charge

Dans un fichier .list approprié sous /etc/apt/sources.list.d/, on ajoute :

deb [signed-by=/etc/sophos-linux-sensor.gpg] https://packages.sophos.com/sophos-linux-sensor/release/ stable main

Le token associé est stocké dans un fichier .conf à accès restreint sous /etc/apt/auth.conf.d/ :

machine packages.sophos.com login <SLS-REGISTRY-TOKEN>

Le paramètre fictif est remplacé par le token effectivement reçu. Seuls les processus privilégiés nécessaires à la gestion des paquets doivent pouvoir lire ce fichier ; on ne place pas en plus le token dans l’URL du dépôt. Après vérification de la confiance de signature, de la source et des droits du fichier, on exécute pendant la fenêtre autorisée :

sudo apt-get update
sudo apt-get install sophoslinuxsensor-systemd sophoslinuxcontent

Hôtes RPM pris en charge

La méthode RPM emploie un fichier .repo distinct sous /etc/yum.repos.d/. Le nom de section et le nom affiché ci-dessous sont des exemples libres ; URL, contrôle de signature et chemin de clé suivent la méthode documentée :

[sls]
name=Sophos Linux Sensor
baseurl=https://<SLS-REGISTRY-TOKEN>@packages.sophos.com/sophos-linux-sensor/release/
gpgcheck=1
enabled=1
gpgkey=file:///etc/sophos-linux-sensor.gpg

On remplace le paramètre fictif par le token reçu. L’accès au fichier contenant le token est restreint. Son URL ne doit pas apparaître dans les journaux de diagnostic, tickets ou captures. Les dépôts existants ne sont pas remplacés et les vérifications de signature ne sont pas désactivées. Le nom affiché ne valide pas une distribution ou version précise.

Une fois la source correctement configurée, Sophos indique les paquets suivants :

sudo yum install sophoslinuxsensor-systemd sophoslinuxcontent

Seule la méthode adaptée à la distribution réellement prise en charge est utilisée. Capteur et contenu sont nécessaires. Le message Zero policies configured signifie que le contrôle du fonctionnement de la détection a échoué, même si le processus fonctionne. D’anciens numéros de version dans les exemples du fabricant ne sont pas des versions à installer aujourd’hui.

Configurer tenant et sortie des alertes

Dans /etc/sophos/runtimedetections.yaml, on définit customer_id avec le tenant vérifié. On complète les paramètres YAML existants de façon ciblée, sans remplacer le fichier par un exemple complet. Finalité et autorisation des données de télémétrie et des destinations d’alertes sont vérifiées avant le démarrage. Sophos décrit une sortie vers stdout par défaut ; cela ne connecte pas automatiquement chaque destinataire souhaité.

Pour le contrôle initial, on consigne la destination réelle : journal local, système de logs existant ou destinataire Sophos explicitement configuré. Identifiants, cible et format sont configurés pour cette sortie. L’enregistrement d’un token ne prouve pas la transmission des alertes.

Pour l’hôte systemd direct, on démarre puis vérifie :

sudo systemctl start sophoslinuxsensor
sudo systemctl status sophoslinuxsensor
sudo journalctl -u sophoslinuxsensor

En cas d’échec au démarrage, on examine d’abord plateforme, paquets, YAML effectif et droits signalés dans le journal. L’installation fabricant décrit les Linux Capabilities requises ; on ne les remplace pas par des conteneurs globalement privilégiés ou un setcap non vérifié sur des fichiers quelconques.

Valider la détection jusqu’au destinataire

Avec le Default Content installé et le capteur actif, l’alerte de test documentée peut être déclenchée sur un pilote autorisé. Vérifier d’abord la syntaxe pour la version installée : l’installation montre à un endroit -test-alert, alors que l’aide de test dédiée utilise --test-alert. La commande suivante n’est employée que si cette version accepte cette écriture :

sophoslinuxsensor --test-alert

Ce test génère volontairement un événement. Il est coordonné avec l’équipe destinataire, jamais lancé discrètement en production. On attend Alert Tester à la sortie configurée. Hôte, heure et destinataire doivent correspondre ; le succès de la commande ou un journal local ne prouve pas la réception distante.

Si cette syntaxe n’est pas prise en charge ou si l’alerte manque, on ne remplace pas le test par un véritable code malveillant ou une attaque incontrôlée.

La réception documente au minimum versions capteur/contenu, règles effectives, démarrage sans erreur, alerte de test et réception réelle. Ce test confirme ce chemin, pas chaque détection, situation de charge ou droit à une investigation MDR. Charge du pilote et applications sont ensuite comparées à l’état initial.

Règles, mises à jour et incidents d’exploitation

Le contenu standard réside dans /var/lib/sophos/content/runtimedetections-content.yaml et est remplacé lors des mises à jour. Les adaptations vont dans /etc/sophos/runtimedetections-rules.yaml, pas dans le fichier du fabricant. Selon l’aide de détection, Sophos prend en charge le contenu standard non modifié ; l’assistance pour les règles modifiées ou personnalisées est à clarifier séparément.

Les détections Core et Enhanced diffèrent par leur profondeur et leur impact sur la charge. Davantage de contenu n’est pas automatiquement meilleur pour toutes les charges serveur sans pilote. Capteur et contenu sont mis à jour par le déploiement de paquets ou de conteneurs approprié, puis revérifiés ; un contrôle unique d’installation ne remplace pas la gestion des mises à jour.

Si des alertes manquent, on examine séparément contenu, règles chargées, événement, sortie et transmission. Collecter les données de support SLS en sécurité détaille journaux et diagnostics, ainsi que les méthodes Helm, Docker et hôte. Un retrait planifié utilise les valeurs initiales documentées, le besoin de protection restant et la procédure de désinstallation fabricant adaptée. On ne supprime pas les services ou identifiants d’autres hôtes.