Qui a obtenu root : repérer une escalade de privilèges dans les logs Linux
Le défi
Quelque chose sur cette machine Linux est passé root. Les vrais administrateurs utilisent sudo toute la journée, donc cela seul n'est pas suspect. Mais un compte qui ne devrait jamais faire que des sauvegardes a été ajouté au groupe sudo puis a immédiatement lancé un shell root. Lisez le journal d'authentification, séparez l'activité admin normale, et soumettez le compte qui est passé root.
Ce que tu vas apprendre
- Lire les événements des logs auth et sudo Linux comme une chronologie de comportement
- Distinguer l'usage sudo administratif courant d'une escalade anormale
- Reconnaître la chaîne usermod vers sudo puis shell root
- Utiliser le rôle d'un compte comme référence de ce qui est normal
- Attribuer une escalade de privilèges à un compte précis
Compétences testées
Prérequis
- Connaissance des utilisateurs, groupes et de sudo sous Linux
- Compréhension de la différence entre comptes de service et comptes interactifs
- Notions sur su et les shells root
Comment ça marche
Sur un hôte Linux, l'escalade vers root est normale : les administrateurs le font des dizaines de fois par jour avec sudo. Vous ne pouvez donc pas signaler chaque action privilégiée ; vous devez savoir ce que chaque compte est censé faire et repérer celui dont le comportement s'écarte de sa référence. Cette référence est l'idée clé : un compte de service comme svc_backup existe pour exécuter une seule tâche (backup.sh) selon une planification. Il ne devrait jamais se connecter de façon interactive, jamais être ajouté à un groupe privilégié, et jamais ouvrir un shell root.
En lisant le journal comme une chronologie, la chaîne pour svc_backup se démarque : il s'authentifie en SSH avec un mot de passe depuis une IP externe (203.0.113.45) au lieu de s'exécuter depuis cron, puis root exécute usermod -aG sudo svc_backup pour lui accorder sudo, et quelques secondes plus tard il exécute sudo /bin/su - pour ouvrir une session root interactive complète. Dans cette session, il lit /etc/shadow, crée un nouvel utilisateur, puis télécharge et exécute un script : une activité clairement post-escalade. Pendant ce temps, alice, bob, carol et dave n'utilisent sudo que pour des tâches routinières à commande unique et n'obtiennent jamais de changement de groupe ni de shell root.
C'est pourquoi event:usermod et event:session sont les filtres à forte valeur. L'escalade n'est pas un seul événement : c'est la combinaison d'une connexion atypique, d'un ajout à un groupe, et d'un shell root, le tout sur le même compte non-admin.
Erreurs fréquentes
- Signaler le premier compte utilisant sudo que vous voyez. Le sudo admin est un bruit de fond constant ici ; l'escalade est le compte qui ne devrait jamais l'avoir.
- Soumettre root.
rootapparaît dans les lignes usermod et session, mais la question demande quel compte a escaladé vers root : c'estsvc_backup. - S'arrêter à la ligne usermod. Être ajouté à sudo n'est que la moitié de l'histoire ; la confirmation est le shell root
su -qui suit. - Ignorer le rôle du compte. Sans savoir que
svc_backupest un compte de service dédié aux sauvegardes, l'activité ressemble à celle d'un admin comme un autre.
Comment s'en protéger
L'escalade de privilèges est détectable si vous alertez sur les changements de qui peut devenir root, pas seulement sur l'activité root elle-même. Établissez une référence pour chaque compte et surveillez les écarts.
- Alertez immédiatement sur tout
usermodou changement de groupe qui ajoute un compte àsudoouwheel, en particulier un compte de service. - Interdisez les connexions SSH interactives et par mot de passe pour les comptes de service : restreignez-les à une commande spécifique via une commande forcée ou une unité systemd.
- Alertez lorsqu'un compte non-admin ouvre un shell root (
su -ousudo -i). - Appliquez le principe du moindre privilège : n'accordez au compte de sauvegarde que les capacités strictement nécessaires, jamais sudo sans restriction.