Service systemd suspect : relier le changement à l’exécution réelle
Enquêtez sur un service systemd créé ou modifié en distinguant les fichiers, la configuration chargée, les processus observés et les effets à vérifier.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Une alerte signale la création ou la modification d’un service Linux. La première question utile est concrète : qu’est-ce qui a changé, et ce changement a-t-il été utilisé pour exécuter quelque chose ? Le nom du service, son emplacement ou sa description ne donnent pas, seuls, la réponse.
Notre méthode consiste à conserver trois vues distinctes : les fichiers présents sur disque, la configuration connue du gestionnaire et l’activité effectivement observée. Ce guide repose sur la documentation publique de systemd. Les options disponibles doivent être vérifiées avec la version installée.
1. Identifier la bonne unité et le bon gestionnaire
Commencez par noter la machine, l’heure de collecte, le nom complet de l’unité et le périmètre de l’observation. Une enquête sur une unité système ne couvre pas automatiquement les unités d’un utilisateur. Relevez aussi l’instance exacte lorsqu’un nom comporte un caractère « @ ».
Les unités systemd utilisent plusieurs chemins de recherche. Des fichiers complémentaires, appelés drop-ins, peuvent modifier la définition principale ; les unités modèles et leurs instances demandent également une lecture adaptée. Ne limitez donc pas l’examen au seul fichier qui a déclenché l’alerte. Source : configuration des unités systemd.
Notre recommandation : rattacher chaque pièce à la même identité technique avant de construire la chronologie. Un nom similaire sur un autre hôte, dans un conteneur ou sous un autre utilisateur reste une observation distincte jusqu’à vérification.
2. Capturer les trois vues avant de les rapprocher
systemctl cat affiche les fichiers sur disque, qui peuvent différer de la configuration chargée. systemctl show expose des propriétés du gestionnaire et de l’état courant. L’activation au démarrage et l’exécution sont également distinctes. Source : systemctl.
Exemple de lecture pour une unité système fictive, à adapter au périmètre autorisé :
systemctl --no-pager cat exemple.service
systemctl --no-pager show exemple.service \
-p Id -p FragmentPath -p DropInPaths \
-p LoadState -p ActiveState -p SubState \
-p MainPID -p ExecStart -p User
Ces commandes sont des exemples documentaires, pas des tests exécutés dans votre environnement. Le contenu d’une unité ou ses arguments peuvent contenir des informations sensibles : conservez les sorties dans le dossier d’enquête autorisé et expurgez les copies destinées à un partage plus large.
Ne rechargez pas la configuration simplement pour faire disparaître une différence pendant la collecte. Ce serait une intervention, à distinguer de l’observation. Notre recommandation est de sauvegarder d’abord les états utiles, puis de décider séparément des actions nécessaires selon l’urgence.
3. Examiner ce qui pourrait réellement être lancé
Les directives ExecStartPre, ExecStart, ExecStartPost et ExecStop décrivent différentes commandes du cycle de vie. L’état « active » ne garantit pas qu’un processus tourne encore : RemainAfterExit permet de maintenir cet état après la sortie d’une commande. Source : configuration des services.
Le contexte d’exécution compte aussi. User, WorkingDirectory, RootDirectory et les paramètres d’environnement peuvent modifier l’identité ou la vue des fichiers utilisée par le service. Source : environnement d’exécution systemd.
Nous recommandons de comparer la définition observée au déploiement attendu : propriétaire du service, paquet ou procédure d’installation, version prévue et changement approuvé. Vérifiez séparément les exécutables et scripts référencés. Une empreinte identifie un contenu ; elle ne démontre pas, à elle seule, son innocuité. De même, un compte légitime n’explique pas automatiquement toute commande exécutée sous son identité.
4. Reconstituer une exécution sans inventer l’historique
journalctl permet de filtrer par unité et période, et de présenter les heures en UTC. Une unité utilisateur exige le filtre et le contexte correspondants. Source : journalctl.
Pour une unité système fictive, le principe de collecte est :
journalctl --no-pager --utc -u exemple.service \
--since "2026-10-31 08:00:00 UTC" \
--until "2026-10-31 09:00:00 UTC" -o short-iso-precise
Adaptez les bornes à l’enquête ; cette fenêtre est purement illustrative. Conservez les heures originales et les identifiants utiles dans vos exports de preuve.
Le journal définit notamment des champs pour le démarrage du système et l’invocation d’une unité. Ils aident à séparer des exécutions que le même nom ou un PID réutilisé pourrait faire confondre. Source : champs du journal.
Rapprochez ensuite ces éléments des traces de processus, d’authentification, de déploiement et de réseau réellement disponibles. Documentez chaque lien. L’heure de modification d’un fichier n’identifie pas son auteur ; un état actuel ne reconstitue pas toute l’activité passée.
La conservation du journal dépend de sa configuration, notamment du stockage volatil ou persistant et des limites de rétention. Source : journald.conf. Une recherche vide doit donc être accompagnée de son périmètre et de ses limites, plutôt que transformée en preuve de non-exécution.
5. Décider de la réponse et vérifier son effet
Nous recommandons de formuler la décision à partir du comportement établi et de l’impact métier. Une modification expliquée par un déploiement vérifié, une exécution suspecte confirmée et une activité impossible à reconstituer ne demandent pas le même traitement.
Avant une intervention, définissez le résultat attendu : empêcher une nouvelle exécution, arrêter une activité en cours, restaurer une configuration ou préserver une preuve. Vérifiez les mécanismes qui peuvent relancer le service et les dépendances métier. Une commande administrative réussie ne prouve pas que tous les effets recherchés sont obtenus.
Après l’action autorisée, relisez les trois vues : fichiers, configuration chargée et activité observée. Confirmez aussi que la collecte fonctionne encore. Si l’historique reste incomplet, conservez cette limite dans le verdict.
Une conclusion utile tient en quelques lignes
La fiche finale devrait répondre à cinq questions : quel changement est établi, quelle exécution est prouvée, quelle explication reste hypothétique, quelle action a été réalisée et quel contrôle confirme son effet ? Ajoutez la prochaine décision, son responsable et les données manquantes.
Cette méthode reste valable quel que soit l’outil qui a émis l’alerte. Sa valeur vient de la continuité entre le signal initial, les observations et la décision, pas du nombre de captures accumulées.