Sophos Linux Sensor : collecter les données de support en toute sécurité

En cas de problème avec Sophos Linux Sensor (SLS), collectez une archive de support et les journaux du capteur correspondants, si possible pendant l’incident ou immédiatement après. La collecte prend environ 30 secondes. Déterminez d’abord le type de déploiement : avec Helm, la collecte s’effectue pour chaque nœud concerné ; avec Docker, sur l’hôte Docker ; et dans le cas d’une installation directe, sur l’hôte Linux. Le téléchargement doit suivre immédiatement le signal de débogage ; la fenêtre de débogage temporaire dure 60 secondes.

Cette procédure s’applique exclusivement à Sophos Linux Sensor. SLS n’est ni Sophos Protection for Linux (SPL), ni son XDR Sensor, ni sa stratégie Linux Runtime Detection. Son classement dans la vue d’ensemble des serveurs sert à la navigation et ne rend pas ces produits équivalents. Pour SPL, consultez le guide d’installation et d’exploitation distinct ; les commandes SLS ci-dessous ne doivent pas y être appliquées.

Vérifier le système cible et les autorisations avant la collecte

Avant d’envoyer un signal ou de redémarrer, confirmez à partir de l’inventaire des déploiements et de l’instance en cours d’exécution que SLS est bien concerné. Consignez dans le dossier de support l’hôte ou le cluster, l’espace de noms, le pod, le nœud ou le conteneur, la version installée du capteur ainsi que l’heure de l’incident avec son fuseau horaire. Les informations de version contenues dans l’archive collectée ensuite complètent cette identification. Cette procédure suit le processus de support mis à jour le 5 octobre 2026 ; cela ne définit aucune version minimale et ne vaut pas validation pour toutes les anciennes versions du capteur, de Helm, de Kubernetes ou de Docker. Si les noms ou les ports diffèrent, ou si le point de terminaison de supervision est absent, clarifiez d’abord le déploiement réel avec le support.

Un répertoire de travail à accès restreint disposant de suffisamment d’espace libre est nécessaire. Les noms de fichiers indiqués ci-dessous sont relatifs à ce répertoire ; avant de recommencer, sauvegardez séparément les dossiers de diagnostic existants afin de ne pas les écraser. Limitez l’accès à l’archive, aux journaux et aux profils aux personnes responsables et définissez une durée de conservation. Pour les téléchargements, les adresses de supervision restent locales. Ne configurez aucun service public, Ingress ou port de débogage accessible à tous.

Les outils doivent déjà être approuvés et disponibles. Si curl est absent d’un hôte Linux sur lequel SLS est installé directement, la procédure documente les commandes d’installation suivantes :

# Systèmes basés sur Red Hat
sudo yum install curl

# Ubuntu
sudo apt-get install curl

Utilisez uniquement la commande adaptée à la distribution dans le cadre du processus approuvé de gestion des paquets. L’installation d’un paquet modifie l’hôte ; elle ne relève pas de la simple vérification de cet article. Pour Helm et Docker, tar et gzip sont également nécessaires. En l’absence des outils ou des autorisations requis, arrêtez-vous avant d’activer le débogage.

Helm : un dossier de diagnostic par nœud concerné

Sur le poste d’administration, kubectl doit être configuré pour le bon cluster. Les autorisations doivent permettre de répertorier les pods, de lire leurs journaux, de transférer leurs ports et d’ajouter un conteneur de débogage éphémère. Le moteur d’exécution des conteneurs doit également prendre en charge le ciblage de l’espace de noms des processus d’un autre conteneur. curl, tar et gzip sont nécessaires sur ce poste.

Le cluster doit pouvoir récupérer busybox:latest. Si ce registre n’est pas approuvé, copiez au préalable l’image dans un registre approuvé et accessible, puis remplacez uniquement la valeur de --image par cette référence d’image vérifiée. N’assouplissez pas les règles de sécurité des registres pour forcer la collecte. Le conteneur éphémère constitue une modification du pod ; il nécessite l’autorisation d’exploitation appropriée.

Choisir le pod et maintenir le transfert de port ouvert

Le chart Helm SLS déploie un pod de capteur par nœud Linux surveillé. Remplacez <namespace> par l’espace de noms de la release SLS :

kubectl --namespace <namespace> \
get pods \
--selector app=sophos-linux-sensor \
--output wide

La sortie doit permettre d’associer le pod du capteur au nœud concerné. <sensor-pod> désigne précisément ce pod, et <node-name> le nom de son nœud. N’utilisez pas un pod sain quelconque de la même release.

Dans le premier terminal, transférez le port de supervision :

kubectl --namespace <namespace> \
port-forward pod/<sensor-pod> 9010:9010

Ce terminal doit rester ouvert jusqu’à la fin du téléchargement. Si le port local est déjà occupé, arrêtez la procédure et résolvez le conflit au lieu de terminer un autre processus. N’ajoutez aucune liaison à des adresses accessibles publiquement. Si le transfert est interrompu, il doit être rétabli avant de relancer le téléchargement.

Envoyer le signal, télécharger immédiatement et ajouter les journaux

Dans le deuxième terminal, ciblez le conteneur SLS avec le conteneur de débogage. La commande envoie SIGUSR2 au processus du capteur ; elle ne demande pas d’arrêter le capteur :

kubectl --namespace <namespace> \
debug pod/<sensor-pod> \
--image=busybox:latest \
--target=sophos-linux-sensor \
--attach=false -- \
pkill -USR2 -f '[s]ophoslinuxsensor'

Le motif de recherche [s]ophoslinuxsensor empêche pkill de cibler sa propre ligne de commande. Si la récupération de l’image, les autorisations ou le ciblage du processus échouent, l’activation de la collecte n’est pas garantie. N’ajoutez pas aveuglément d’autres conteneurs de débogage ; clarifiez d’abord le message d’erreur.

Immédiatement après, lancez le téléchargement dans le deuxième terminal :

curl --fail --silent --show-error \
--max-time 120 \
http://127.0.0.1:9010/support.tar \
--output sophos-linux-sensor-support-<node-name>.tar

--max-time 120 limite la durée de l’appel HTTP, mais ne prolonge pas la fenêtre de débogage. Sauvegardez ensuite les journaux actuels du même conteneur et du même nœud :

kubectl --namespace <namespace> \
logs pod/<sensor-pod> \
--container sophos-linux-sensor \
--timestamps \
> sophos-linux-sensor-<node-name>.log

Répertoriez le contenu sans l’extraire :

tar -tf sophos-linux-sensor-support-<node-name>.tar

Après la vérification d’exhaustivité décrite ci-dessous, arrêtez le transfert de port dans le premier terminal avec Ctrl+C. Pour chaque autre nœud concerné, utilisez un pod distinct et un nom de fichier unique.

Docker : vérifier le conteneur en cours d’exécution et le port publié

Toutes les commandes suivantes s’exécutent sur l’hôte Docker avec les autorisations Docker qui y sont approuvées. Le conteneur SLS doit être en cours d’exécution ; son port de supervision doit déjà être publié sur l’hôte. Le port par défaut dans le conteneur est 9010. curl, tar et gzip doivent être disponibles. Cette procédure ne prescrit ni la publication ultérieure d’un port ni le redémarrage du conteneur comme mesure corrective.

docker ps
docker port <sensor-container> 9010/tcp

<sensor-container> est le nom ou l’identifiant du conteneur SLS confirmé. La deuxième sortie indique l’adresse et le port de l’hôte. Remplacez <host-port> par ce port, et non automatiquement par 9010. Le téléchargement suivant suppose que l’adresse publiée est accessible via 127.0.0.1 sur cet hôte Docker. Si la liaison utilise exclusivement une autre adresse ou si aucune sortie n’est affichée, vérifiez d’abord le déploiement ; n’ajoutez aucun port accessible publiquement.

La commande suivante modifie l’état de débogage pendant 60 secondes. docker kill ne doit pas être exécuté sans --signal=SIGUSR2 :

docker kill --signal=SIGUSR2 <sensor-container>

Immédiatement après, accédez au point de terminaison local publié :

curl --fail --silent --show-error \
http://127.0.0.1:<host-port>/support.tar \
--output sophos-linux-sensor-support.tar

Les journaux et la vérification de l’archive font partie du même dossier de diagnostic :

docker logs <sensor-container> \
> sophos-linux-sensor.log 2>&1

tar -tf sophos-linux-sensor-support.tar

Le mode débogage temporaire se termine automatiquement. Une nouvelle interrogation avec docker ps doit toujours afficher le conteneur prévu en cours d’exécution ; cela ne prouve toutefois pas à lui seul que la détection fonctionne.

Hôte Linux avec installation directe : utiliser le mode débogage temporaire

Cette branche s’applique à SLS exécuté directement sur l’hôte, et non à un conteneur ni à /opt/sophos-spl. Les privilèges root et l’accès au port de supervision local sont nécessaires. Pour une installation systemd, vérifiez au préalable avec journalctl -u sophoslinuxsensor que le journal correspond au service et à l’hôte attendus. Si le service est absent ou s’il existe plusieurs instances du capteur, clarifiez d’abord leur correspondance.

La commande hôte documentée cible tous les processus actifs correspondant au motif sophoslinuxsensor sur l’hôte. Elle ne se limite pas à une seule instance. Ne l’exécutez pas sans autorisation pour ces instances ou si les noms des processus sont incertains.

sudo pkill -SIGUSR2 -f sophoslinuxsensor

Le capteur fournit ensuite des informations de support et de débogage pendant 60 secondes sur le point de terminaison de supervision. Lancez immédiatement la collecte dans le répertoire de travail préparé :

curl -O http://localhost:9010/support.tar && gzip support.tar

La collecte prend environ 30 secondes. Après une compression réussie, le fichier support.tar.gz est disponible. Cet appel sur l’hôte ne comporte ni vérification des erreurs HTTP ni délai d’expiration ; la présence d’un fichier ou la réussite de l’appel gzip ne prouvent donc pas que l’archive est complète. Pour effectuer la vérification locale sans extraire l’archive :

tar -tzf support.tar.gz

Pour lire les journaux de l’hôte :

journalctl -u sophoslinuxsensor

Pour une observation en continu, l’appel suivant est également documenté :

journalctl -efu sophoslinuxsensor

Arrêtez l’observation avec Ctrl+C et sauvegardez les informations du journal nécessaires pour la période de l’incident via la méthode d’exportation approuvée. Ne considérez pas une sortie continue illimitée comme un ensemble complet de données de support.

Vérifier l’archive, cerner les erreurs et transmettre les données en toute sécurité

Une archive de débogage complète contient des entrées telles que runtimedetections.yaml, environment.json, goroutine.out et profile.out, ainsi que des informations sur les métriques et la version. Les entrées citées sont des exemples, et non une garantie de contenu identique pour chaque version. tar doit pouvoir répertorier le contenu de l’archive sans erreur. Une page d’erreur HTML, un dossier de diagnostic vide ou un téléchargement interrompu ne constituent pas un résultat exploitable.

Si le dossier de diagnostic contient uniquement metrics.txt et version.json, la collecte de débogage n’était pas active. Vérifiez l’instance cible, les erreurs d’envoi du signal et le délai écoulé. Envoyez ensuite à nouveau SIGUSR2 dans la branche correspondant au déploiement, puis relancez immédiatement le téléchargement. Dans la branche Helm, le transfert de port doit rester actif pendant toute la durée du téléchargement. En cas d’échecs répétés, faites remonter au support le message d’erreur exact, la version du capteur et l’heure de l’incident ; ne contournez pas le problème avec un mode débogage permanent ou un port réseau ouvert.

Les archives, journaux et profils peuvent contenir des éléments de configuration confidentiels, des variables d’environnement ainsi que des informations sur l’hôte et l’exécution. Même si certaines parties de la configuration sont automatiquement expurgées, le dossier de diagnostic n’est pas automatiquement anonymisé pour une diffusion publique.

Avant la transmission, vérifiez la liste des fichiers et, si nécessaire, leur contenu dans un environnement isolé afin de repérer les informations d’authentification, jetons, noms d’hôtes internes et données à caractère personnel. Utilisez une copie distincte pour les expurgations et documentez les modifications ; ne modifiez pas les profils binaires de manière incontrôlée. Clarifiez avec le support quels contenus doivent rester inchangés pour le diagnostic. Ne conservez l’original qu’avec un accès restreint et pendant la durée convenue.

Transmettez l’archive et les journaux associés exclusivement via le canal de support Sophos approuvé et confirmé dans le dossier de support. Vérifiez le destinataire et la destination de téléversement à partir du dossier existant, et non d’un message non sollicité. N’utilisez aucun ticket public, forum, dépôt Git ou espace de stockage de médias de la base de connaissances. Le dossier de diagnostic doit être accompagné du type de déploiement, des nœuds ou hôtes concernés, de la version du capteur, de l’heure de l’incident avec son fuseau horaire, du symptôme et des étapes de collecte déjà effectuées ; n’envoyez aucune information d’authentification dans le texte d’accompagnement.

Profils CPU et mémoire uniquement en cas de besoin ciblé

Pour une archive de support normale, le signal temporaire suffit. Les profils individuels suivants constituent une méthode distincte pour les problèmes de CPU ou de mémoire et utilisent le format pprof de Google. Avant toute activation permanente du débogage dans la configuration, il faut savoir comment le service SLS réel est démarré et comment rétablir sa configuration.

Sauvegardez d’abord le contenu existant de /etc/sophos/runtimedetections-rules.yaml, la valeur existante de debug ou son absence, ainsi que l’environnement de démarrage effectif. Vérifiez notamment si RUNTIMEDETECTIONS_DEBUG est déjà définie. Une sauvegarde de cette configuration est elle aussi confidentielle. Ne la confondez pas avec le fichier au nom similaire runtimedetections.yaml dans l’archive de support.

Choisissez l’une des méthodes d’activation documentées :

• Exécutez le capteur avec RUNTIMEDETECTIONS_DEBUG=true dans son environnement de démarrage réel. Un simple export dans un shell d’administration ne modifie pas l’environnement d’un service déjà en cours d’exécution.
• Définissez debug: true dans /etc/sophos/runtimedetections-rules.yaml, sans remplacer les autres règles ni créer une deuxième entrée contradictoire.

Un redémarrage interrompt le service SLS. L’autorisation de maintenance, la période d’interruption de la détection tolérable et l’accès à la configuration d’origine doivent être établis au préalable. Cet appel systemd s’applique à l’installation directe sur l’hôte ; il ne s’agit pas d’une procédure de redémarrage pour Helm ou Docker.

Avec les privilèges root, exécutez le redémarrage documenté :

systemctl restart sophoslinuxsensor

Contrôlez ensuite l’état du service et le journal. Ne collectez les profils nécessaires sur le point de terminaison local que lorsque le service est en cours d’exécution et que la configuration est valide :

curl -s http://localhost:9010/debug/pprof/heap > heap.out
curl -s 'http://localhost:9010/debug/pprof/profile?seconds=60' > profile.out

heap.out recueille des échantillons de l’occupation mémoire des objets vivants du tas ; profile.out recueille l’utilisation du CPU sur 60 secondes. Ces appels ne comportent aucune vérification des erreurs HTTP : la seule création d’un fichier ne prouve pas la validité du profil. N’interprétez pas des fichiers vides ou une réponse d’erreur comme des mesures ; vérifiez le point de terminaison et la configuration effective du débogage, puis faites valider le format avec le support si nécessaire. Ces fichiers restent eux aussi confidentiels.

Les métriques, en revanche, ne nécessitent ni mode débogage ni redémarrage lié au débogage :

curl -s http://localhost:9010/metrics > metrics.out

Rétablir l’état de débogage et l’état de fonctionnement

Pour la collecte temporaire, n’envoyez plus aucun signal après la fenêtre de 60 secondes. Laissez le capteur fonctionner et vérifiez, à l’aide de ses journaux ou de la supervision opérationnelle existante, qu’il continue à fonctionner normalement. Un processus en cours d’exécution ou un point de terminaison de métriques accessible ne constitue pas une preuve complète du bon fonctionnement de la détection et de la transmission des données. En cas de comportement anormal, travaillez avec le support.

Lorsque le débogage est configuré de manière permanente, il n’y a pas de retour automatique à l’état initial après 60 secondes. Rétablissez dans le fichier YAML la valeur de debug sauvegardée auparavant ou son absence d’origine, et remettez à son état précédent toute variable RUNTIMEDETECTIONS_DEBUG nouvellement définie pour ce diagnostic dans la configuration de démarrage réelle. N’écrasez pas globalement d’autres paramètres ni l’intégralité d’une configuration modifiée entre-temps. La modification précise de l’environnement dépend du mécanisme de démarrage existant ; sans état de référence connu, il n’existe aucune commande universelle de réinitialisation sûre.

Pour le service systemd installé directement, utilisez à nouveau, après cette restauration, la commande systemctl restart sophoslinuxsensor indiquée ci-dessus dans la fenêtre de maintenance approuvée. Vérifiez le service et le journal pour détecter les erreurs de démarrage ou de configuration, comparez le paramètre de débogage effectif à son état précédent et contrôlez qu’aucun accès aux profils nouvellement activé pour le diagnostic ne reste disponible. Si le débogage était déjà actif auparavant, sa désactivation constitue une décision d’exploitation supplémentaire et non une restauration.

Arrêtez le transfert de port Helm et confirmez que le processus exécuté dans le terminal est terminé. Le conteneur de débogage éphémère ne peut pas être supprimé du pod existant comme un conteneur normal ; ne supprimez aucun pod de capteur uniquement pour nettoyer ce diagnostic. Si la politique locale du cluster exige le renouvellement d’un pod, l’exploitant responsable doit le planifier séparément, en tenant compte de l’interruption de la détection et du contrôle du déploiement.

Après confirmation de la prise en charge par le support et expiration de la durée de conservation définie, supprimez les fichiers d’archive, de journaux et de profils effectivement créés, ainsi que les copies temporaires destinées à l’expurgation, conformément à la politique locale de suppression. N’effectuez aucune suppression par caractères génériques et ne supprimez ni règles du capteur, ni journaux du produit, ni fichiers d’autres dossiers de support. La suppression d’un fichier ne garantit pas l’écrasement des sauvegardes, des instantanés ou des blocs SSD ; leur conservation relève de la politique de stockage et de protection des données applicable.