Processus, services et journaux système

Un ordinateur allumé n'est jamais « au repos » : des dizaines de programmes s'exécutent en arrière-plan, certains lancés par vous, la plupart par le système lui-même. Savoir lister ce qui tourne, arrêter ce qui ne devrait pas, et retrouver dans les journaux la trace de ce qui s'est passé : voilà les gestes qui séparent l'utilisateur de l'administrateur, et le défenseur de celui qui subit.

Dans les leçons précédentes, vous avez appris à vous déplacer dans les fichiers et à gérer les droits. Nous passons maintenant au « vivant » : les processus, les services et les traces qu'ils laissent. Ces notions seront indispensables pour comprendre plus tard comment on détecte une intrusion.

Les processus

Un processus est un programme en cours d'exécution. Chacun possède un numéro, le PID (Process ID), un propriétaire (l'utilisateur qui l'a lancé) et un processus parent. Le tout premier processus, lancé au démarrage, porte le PID 1 : il démarre ensuite tous les autres.

ps                    # processus de ce terminal
ps aux                # tous les processus du système, avec leur propriétaire
ps aux | grep ssh     # filtrer sur un nom
top                   # vue dynamique, rafraîchie (q pour quitter)
pstree                # l'arbre des processus, avec leurs parents

Dans la sortie de ps aux, repérez les colonnes USER (le propriétaire), PID, %CPU et %MEM (la consommation) et COMMAND (la commande lancée). Un défenseur regarde d'un œil critique : ce processus est-il attendu ? Tourne-t-il sous le bon utilisateur ? Pourquoi consomme-t-il autant ?

Arrêter un processus

La commande kill envoie un signal à un processus, par son PID. Le signal par défaut demande poliment l'arrêt ; le signal 9 force l'arrêt immédiat, sans laisser au programme le temps de se nettoyer.

kill 4321           # demande l'arrêt du processus 4321 (signal TERM)
kill -9 4321        # arrêt forcé, à réserver aux processus qui ne répondent plus
pkill nom-du-programme    # par nom (à manier avec prudence)

Un utilisateur ne peut arrêter que ses propres processus ; root peut arrêter n'importe lequel. On lance un programme en arrière-plan en ajoutant & à la fin de la commande, et jobs liste ces tâches.

Les services : des processus de longue durée

Un service (ou démon) est un programme qui tourne en permanence en arrière-plan pour fournir une fonction : serveur web, accès SSH, impression, planificateur de tâches… Sur la plupart des distributions modernes (Debian, Ubuntu, Kali, Fedora…), les services sont gérés par systemd, via la commande systemctl.

systemctl status ssh              # état du service SSH
sudo systemctl start ssh          # le démarrer maintenant
sudo systemctl stop ssh           # l'arrêter maintenant
sudo systemctl restart ssh        # le redémarrer
sudo systemctl enable ssh         # le lancer automatiquement au démarrage
sudo systemctl disable ssh        # ne plus le lancer au démarrage
systemctl list-units --type=service --state=running

Notez la différence entre start / stop (action immédiate) et enable / disable (comportement au prochain démarrage). Le nom exact d'un service varie parfois selon les distributions (ssh ou sshd par exemple) : systemctl list-units permet de le retrouver. Les services sont décrits par des fichiers de configuration appelés unités, dans /etc/systemd/system ou /lib/systemd/system.

Quels services sont à l'écoute ?

Un service qui écoute sur un port est une porte d'entrée potentielle. Pour un défenseur, la liste de ce qui écoute sur une machine est une information de base : on l'appelle la surface d'attaque réseau. Pour la voir :

sudo ss -tulpn

Les options : -t TCP, -u UDP, -l ceux qui écoutent (listening), -p le processus concerné, -n les numéros de ports plutôt que leurs noms. Dans le résultat, une adresse 127.0.0.1:port signifie que le service n'écoute que localement (inaccessible de l'extérieur), alors que 0.0.0.0:port (ou [::]:port en IPv6) signifie qu'il écoute sur toutes les interfaces. La règle de sécurité est simple : moins il y a de services à l'écoute, moins il y a de portes à surveiller. On désactive ce dont on n'a pas besoin.

Les journaux : la mémoire du système

Presque tout ce qui se passe sur un système laisse une trace dans des journaux (logs) : démarrages, connexions réussies ou échouées, erreurs de services, utilisation de sudo, redémarrages. Pour un défenseur, c'est une source de vérité ; pour un enquêteur, la base de toute investigation ; pour un attaquant, une trace à effacer, ce qui est lui-même suspect.

Deux mécanismes coexistent selon les distributions :

• Le journal de systemd (journald), consulté avec journalctl ;
• Les fichiers texte dans /var/log, alimentés par un service de journalisation traditionnel (rsyslog), dont la présence dépend de la distribution et de sa configuration.

journalctl -n 50                       # les 50 dernières entrées
journalctl -u ssh --since "1 hour ago" # entrées du service SSH, dernière heure
journalctl -p err                      # seulement les erreurs
journalctl -f                          # suivre en direct
ls /var/log                            # fichiers de journaux traditionnels

Dans /var/log, selon la distribution, vous pourrez trouver : auth.log (authentifications et usage de sudo), syslog (messages généraux), kern.log (noyau), apache2/ ou nginx/ (journaux d'accès et d'erreur des serveurs web). Pour les lire : less, tail -f et grep, que vous connaissez.

Lire une ligne d'authentification

Une ligne typique d'un journal d'authentification ressemble à ceci (exemple fictif) :

Jan 12 10:32:07 kali-labo sshd[2211]: Failed password for invite from 10.10.10.10 port 51022 ssh2

Elle se lit : date et heure, machine, service et PID, puis le message : un échec d'authentification pour l'utilisateur invite, depuis l'adresse 10.10.10.10. Un nombre élevé de lignes similaires en peu de temps est un signal classique de tentatives répétées de connexion ; c'est ce que les outils de supervision sont chargés de détecter. Pour une première analyse, grep "Failed password" fichier | wc -l donne un décompte immédiat.

Planifier des tâches

Le service cron exécute des commandes à intervalles réguliers (sauvegardes, nettoyages). La commande crontab -l affiche vos tâches planifiées. Pour un défenseur, la liste des tâches planifiées d'un système fait partie des endroits à vérifier lors d'un contrôle : on y repère les tâches inattendues.

À vous de jouer

Dans votre VM de laboratoire, exécutez les étapes suivantes (si le service SSH n'est pas installé, ajoutez-le avec sudo apt install openssh-server) :

1. Listez les services à l'écoute avec sudo ss -tulpn. Notez chaque port et son processus.
2. Démarrez le service SSH (sudo systemctl start ssh), vérifiez son état, puis relancez ss. Quel nouveau port apparaît ?
3. Depuis le terminal de la même machine, tentez une connexion avec un nom d'utilisateur qui n'existe pas : ssh inconnu@127.0.0.1 (échouez volontairement le mot de passe).
4. Consultez le journal : journalctl -u ssh -n 20. Retrouvez la tentative échouée.
5. Arrêtez et désactivez le service SSH s'il ne vous est pas utile.

Vous savez observer et contrôler un système Linux à la main. Pour terminer le chapitre, voyons comment éviter de refaire les mêmes gestes à chaque fois : en les automatisant avec un petit script.