Introduction
Dans les domaines de l'administration système et de la cybersécurité, l'analyse des journaux (logs) est une compétence essentielle. Les journaux système enregistrent un large éventail d'événements, des opérations de routine aux erreurs critiques et aux violations de sécurité potentielles. Être capable de naviguer et d'interpréter efficacement ces journaux est fondamental pour surveiller la santé du système, résoudre les problèmes et répondre aux incidents de sécurité.
Ce laboratoire vous présente journalctl, l'outil standard pour interroger et afficher les journaux du service journald sur les systèmes Linux modernes. Vous apprendrez à effectuer des tâches d'analyse de journaux de base qui constituent le fondement de la surveillance et de la réponse aux incidents.
Tout au long de ce laboratoire, vous allez :
- Examiner les journaux de démarrage du système.
- Filtrer les journaux pour trouver des événements spécifiques tels que les échecs d'authentification.
- Simuler et détecter un événement suspect.
- Exporter les journaux pour une analyse plus approfondie.
Examiner les journaux de démarrage du système avec Journalctl
Dans cette étape, vous apprendrez à utiliser la commande journalctl pour examiner les journaux système, en vous concentrant spécifiquement sur les messages générés lors du processus de démarrage le plus récent. C'est une première étape courante lors du diagnostic des problèmes de démarrage.
La commande journalctl vous permet d'interroger le contenu du journal systemd. Sans aucun argument, elle affiche tous les journaux, ce qui peut être écrasant.
Pour rendre la sortie plus gérable, nous pouvons utiliser l'option -b ou --boot pour afficher uniquement les journaux de la session de démarrage actuelle.
Exécutez la commande suivante dans votre terminal pour afficher les journaux du démarrage actuel :
journalctl -b
Vous verrez une sortie paginée commençant par les messages les plus anciens du processus de démarrage. Vous pouvez utiliser les touches fléchées Haut et Bas pour naviguer. Appuyez sur q pour quitter le pager et revenir à l'invite de commande.
-- Journal begins at Tue 2023-10-31 08:30:00 UTC, ends at Tue 2023-10-31 09:00:00 UTC. --
Oct 31 08:30:01 labex-vm kernel: Linux version 5.15.0-87-generic ...
Oct 31 08:30:01 labex-vm kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-87-generic ...
Oct 31 08:30:01 labex-vm kernel: KERNEL supported cpus:
Oct 31 08:30:01 labex-vm kernel: Intel GenuineIntel
Oct 31 08:30:01 labex-vm kernel: AMD AuthenticAMD
...
(END)
Cette commande est inestimable pour comprendre quels services ont démarré avec succès et pour identifier les erreurs qui se sont produites lors du démarrage du système.
Filtrer les journaux pour les échecs d'authentification
Dans cette étape, vous allez filtrer le journal pour trouver des événements spécifiques, tels que les tentatives d'authentification échouées, qui sont critiques pour la surveillance de la sécurité. Une cible courante pour les attaquants est le service SSH, donc la surveillance de ses journaux est une priorité élevée.
Nous pouvons utiliser l'option -u avec journalctl pour filtrer les journaux par une unité systemd spécifique. Pour le service SSH, l'unité est généralement ssh.service (sur Ubuntu/Debian) ou sshd.service (sur Red Hat/CentOS).
Filtrons les journaux pour voir uniquement les entrées relatives au démon SSH. Notez que vous devrez peut-être utiliser sudo pour afficher les journaux système :
sudo journalctl -u ssh
Cette commande affiche toutes les entrées de journal générées par le service sshd. Pour affiner notre recherche sur les problèmes de sécurité potentiels, nous pouvons rediriger cette sortie vers la commande grep pour rechercher des mots-clés tels que "Failed".
Exécutez la commande suivante pour trouver les tentatives de mot de passe échouées pour le service SSH :
sudo journalctl -u ssh | grep "Failed password"
S'il n'y a pas eu de tentatives de connexion échouées récentes, cette commande peut ne produire aucune sortie. C'est normal sur un système sécurisé. Dans l'étape suivante, nous allons générer nous-mêmes un tel événement pour voir comment il apparaît dans les journaux.
Simuler un événement suspect et analyser les journaux
Maintenant, simulons un événement suspect, puis utilisons nos compétences en analyse de journaux pour le détecter. Un signe courant d'une attaque par force brute est une série de tentatives de connexion échouées. Nous allons simuler une telle tentative en essayant de nous connecter en SSH à notre propre machine (localhost) avec un nom d'utilisateur qui n'existe pas.
Exécutez la commande suivante dans votre terminal. Il vous sera demandé un mot de passe ; vous pouvez entrer n'importe quoi car il est censé échouer.
ssh non_existent_user@localhost
Le système refusera la connexion, ce qui est le résultat attendu. Vous devriez voir un message comme celui-ci :
non_existent_user@localhost's password:
Permission denied, please try again.
non_existent_user@localhost's password:
Permission denied (publickey,password).
Maintenant que nous avons généré un événement de connexion échouée, réexécutons notre commande d'analyse de journaux de l'étape précédente pour voir si nous pouvons la trouver.
sudo journalctl -u ssh | grep "Failed password"
Cette fois, la commande devrait produire une sortie montrant la tentative échouée que nous venons de faire.
Oct 31 09:15:12 labex-vm sshd[1234]: Failed password for invalid user non_existent_user from 127.0.0.1 port 48492 ssh2
Ce simple exercice démontre la boucle principale de la réponse à incident : un événement se produit, il est consigné, et un administrateur ou un système automatisé analyse les journaux pour le détecter.
Exporter les journaux pour la simulation d'analyse centralisée
Dans un scénario réel, vous exporteriez souvent les journaux des machines individuelles vers un serveur de journalisation centralisé (comme un SIEM) pour le stockage à long terme et la corrélation. Dans cette étape, nous allons simuler cela en exportant nos journaux SSH récents vers un fichier.
journalctl peut produire des journaux dans différents formats. Le format json-pretty est particulièrement utile car il est à la fois lisible par l'homme et facilement analysable par d'autres outils.
Exportons tous les journaux SSH des 10 dernières minutes dans un fichier nommé ssh_logs.json dans votre répertoire courant (~/project).
sudo journalctl -u ssh --since "10 minutes ago" -o json-pretty > ~/project/ssh_logs.json
Vérifions maintenant que le fichier a été créé :
ls -l ~/project
Vous devriez voir ssh_logs.json dans la liste des fichiers.
total 4
-rw-r--r-- 1 labex labex 1234 Oct 31 09:20 ssh_logs.json
Enfin, visualisons le contenu de notre fichier de journal exporté.
cat ~/project/ssh_logs.json
La sortie sera un tableau JSON structuré, avec chaque entrée de journal comme un objet. Ce format est idéal pour l'ingestion dans d'autres plateformes d'analyse.
[
{
"__CURSOR" : "s=...",
"__REALTIME_TIMESTAMP" : "...",
"__MONOTONIC_TIMESTAMP" : "...",
"_BOOT_ID" : "...",
"_TRANSPORT" : "syslog",
"PRIORITY" : "6",
"SYSLOG_FACILITY" : "4",
"SYSLOG_IDENTIFIER" : "sshd",
"MESSAGE" : "Failed password for invalid user non_existent_user from 127.0.0.1 port 48492 ssh2",
"_PID" : "1234",
...
}
]
Vous avez réussi à simuler le processus de préparation des journaux pour une analyse centralisée.
Résumé
Dans ce laboratoire, vous avez acquis une expérience pratique avec journalctl, un outil puissant pour l'analyse des journaux sur les systèmes Linux modernes. Ce sont des compétences fondamentales pour tout administrateur système, ingénieur DevOps ou professionnel de la sécurité.
Vous avez appris à :
- Examiner les journaux système et de démarrage pour diagnostiquer les problèmes de démarrage.
- Filtrer les journaux par services spécifiques et contenu de message pour trouver les événements pertinents.
- Identifier les activités suspectes, telles que les échecs de connexion, à partir des entrées de journal.
- Exporter les journaux dans un format structuré comme JSON pour le stockage centralisé et une analyse plus approfondie.
La maîtrise de ces techniques vous permettra de mieux surveiller vos systèmes, de dépanner les problèmes plus efficacement et de faire les premiers pas dans la réponse aux incidents de sécurité.
