Le 12 octobre 2026 à 14:32:18 UTC, le serveur Ubuntu ir-lab-ubuntu24 a accepté une connexion inattendue pour le compte ops. L’attaquant n’a eu besoin ni de modifier un programme ni de briser un chiffrement, car le compte ops disposait déjà d’un accès à des fichiers qui auraient dû appartenir exclusivement à socalyst ou à root. La question qui se pose pour la défense est concrète : quels chemins du système de fichiers permettent à un compte de lire, de modifier ou d’accéder à des éléments auxquels il ne devrait pas avoir accès ?
Toutes les observations ultérieures s’appuient sur les mêmes faits relatifs à l’incident. Le compte de l’analyste est socalyst, le compte suspect est ops, et la période de l’incident s’étend de 14:10:00 UTC à 15:10:00 UTC le 12 octobre 2026. Sous Linux, le nom du serveur est stocké dans /etc/hostname, les informations des comptes locaux dans /etc/passwd, les hachages de mots de passe protégés dans /etc/shadow, et les fichiers de chaque compte dans des répertoires tels que /home/socalyst et /home/ops. Un chemin ne désigne pas simplement un emplacement ; son propriétaire et ses permissions déterminent qui est autorisé à utiliser l’objet situé à cet endroit. L’hôte concerné par l’incident et les chemins d’accès aux éléments de preuve définissent le périmètre de notre inspection :
Ce diagramme montre que les enregistrements d’identité, la configuration de l’hôte, les répertoires personnels et les preuves d’authentification résident dans des chemins distincts. Une constatation concernant /home/ops ne prouve pas automatiquement que /etc/shadow a été modifié ; nous associons donc chaque affirmation à l’élément qui l’étaye.
La présence inattendue du nom d’utilisateur ops fait des permissions le point de contrôle suivant, car Linux évalue les droits d’accès avant qu’un processus ne puisse lire ou modifier un fichier, ou accéder à un répertoire. Un utilisateur correspond à un compte tel que socalyst ou ops. Un groupe est un ensemble nommé de comptes pouvant partager des droits d’accès, comme le groupe shadow utilisé pour restreindre l’accès aux enregistrements de hachage de mots de passe.
Chaque objet du système de fichiers possède un propriétaire, un groupe et trois ensembles de permissions. Les permissions du propriétaire s’appliquent au compte propriétaire, celles du groupe aux membres du groupe assigné, et les autres permissions à tous les autres utilisateurs. Les bits sont r pour la lecture du contenu, w pour la modification du contenu et x pour l’exécution d’un programme ou l’accès à un répertoire. Pour /home/ops, la permission x du répertoire détermine si un autre compte peut parcourir le chemin menant à ce répertoire.
Le contraste entre /etc/hostname et /etc/shadow met en évidence les choix en matière de sécurité. Les processus doivent lire le nom d’hôte ; ainsi, /etc/hostname est généralement lisible par tous les comptes, alors que seuls les composants système privilégiés doivent pouvoir lire les hachages de mots de passe contenus dans /etc/shadow. Un accès en écriture pour tous (c’est-à-dire lorsque l’ensemble « autres » inclut le bit w) permettrait à n’importe quel compte local de modifier un objet protégé. Un fichier /etc/shadow lisible par tous exposerait les hachages de mots de passe à des tentatives de devinette hors ligne. La structure attendue de ces chemins permet de repérer plus facilement les anomalies suspectes :
Ce tableau montre que les paramètres d’autorisation dépendent de la fonction du chemin d’accès. Les informations d’identité et de nom d’hôte lisibles par tous peuvent faciliter le fonctionnement normal du système, mais l’accès en écriture reste restreint, car la modification des enregistrements d’identité ou des paramètres de l’hôte pourrait induire en erreur une enquête ultérieure.
Règle relative aux autorisations Considérez un mode d’autorisation comme la preuve d’un accès autorisé, et non comme la preuve qu’un accès a effectivement eu lieu. Des journaux et des horodatages sont nécessaires pour étayer une affirmation concernant une action.
Comme les autorisations décrivent les accès actuels plutôt que les intentions, nous commençons par consigner les faits observables concernant ir-lab-ubuntu24. Les commandes hostnamectl, id, ls -l, stat et readlink -f permettent de répondre à diverses questions sans modifier les fichiers examinés. hostnamectl indique l’identité configurée de l’hôte. id ops et id socalyst permettent de déterminer l’identité numérique et l’appartenance aux groupes de chaque compte. Ces identités numériques sont importantes car Linux mémorise la propriété sous forme d’identifiants d’utilisateur et de groupe, même lorsque la sortie de la commande affiche des noms familiers.
Pour les chemins /etc/hostname, /etc/passwd et /etc/shadow, la commande ls -l fournit une vue synthétique des bits d’autorisation, du propriétaire, du groupe, de la taille et d’un horodatage. stat fournit des métadonnées plus précises, notamment le mode numérique et l’heure de modification. readlink -f résout un chemin d’accès jusqu’à sa cible finale ; cela empêche un lien symbolique — un objet du système de fichiers pointant vers un autre emplacement — de masquer l’endroit réellement inspecté. La session suivante consigne les faits du cas sans avancer d’explication quant à la présence d’un horodatage ou d’une autorisation spécifique :