Les journaux d'authentification aident à comprendre les tentatives de connexion, les changements de privilèges et l'activité des sessions. Ils constituent des preuves sensibles pour la sécurité, mais une seule ligne établit rarement l'intention d'un utilisateur ou la compromission d'un compte.
Journalisation · Leçon 5
Journalisation de l'authentification
Découvrez comment trouver, interpréter et corréler sans risque les enregistrements d'authentification de Linux.
Trouver les enregistrements d'authentification
Les configurations syslog de la famille Debian routent souvent les événements vers /var/log/auth.log, tandis que celles de la famille Red Hat emploient couramment /var/log/secure. Le journal systemd peut conserver les mêmes événements avec les métadonnées d'unités et de processus, et une journalisation centralisée peut détenir la copie faisant autorité.
Découvrez la destination locale et interrogez le service pertinent, par exemple :
$ sudo journalctl -u ssh.service --since '1 hour ago'
$ sudo less /var/log/auth.log
L'unité SSH peut s'appeler ssh.service ou sshd.service. Les permissions limitent généralement l'accès à ces enregistrements, car ils exposent des détails sur les comptes et les accès.
Où les événements d'authentification Linux doivent-ils toujours être stockés ?
Interpréter un événement
Un enregistrement traditionnel peut contenir :
Jan 31 10:37:50 icebox pkexec: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
Il identifie l'heure, l'hôte, le programme émetteur, le module et le service PAM, l'utilisateur demandé pour la session et l'UID d'origine. À lui seul, il n'identifie pas la personne derrière l'UID 1000 et ne prouve pas une action malveillante. Résolvez l'UID au moyen des données de comptes valides au moment de l'incident et corrélez le terminal, l'adresse distante, la session et les événements voisins.
Qu'établit uid=1000 dans cet enregistrement ?
Enquêter sur les réussites et les échecs
Recherchez les tentatives acceptées et rejetées dans un intervalle limité. Pour SSH, examinez également la source de la connexion, la méthode d'authentification, le compte cible, l'ouverture et la fermeture de la session ainsi que les redémarrages du service. Des échecs répétés peuvent provenir d'une erreur de l'utilisateur, d'une automatisation aux anciens identifiants, d'une analyse ou d'une attaque ; la fréquence seule ne permet pas de choisir l'explication.
last et lastb peuvent résumer les enregistrements de wtmp et btmp lorsqu'ils sont entretenus, mais ces bases binaires possèdent leurs propres limites de conservation et d'intégrité. Recoupez-les avec les enregistrements du journal ou de syslog et les sources centralisées.
Avec quoi faut-il corréler les échecs répétés de connexion ?
Préserver et intervenir
Si vous soupçonnez un incident, consignez l'heure et le fuseau de l'hôte, préservez les journaux originaux et leurs métadonnées, puis protégez toute copie exportée. Évitez de modifier les preuves sur place. Le verrouillage des comptes, les changements de pare-feu et la fin des sessions peuvent interrompre un accès légitime ou alerter un attaquant ; suivez donc la procédure de réponse aux incidents et conservez une voie de récupération.
Comment faut-il traiter les preuves d'authentification pendant une enquête ?
Leçon terminée
Vous avez terminé Journalisation de l'authentification
Vous savez maintenant examiner les événements d'authentification sans exagérer ce qu'un seul enregistrement prouve.
Découvrir la destination locale configurée des journaux d'authentification.
Interpréter l'identité, le service, la méthode et la session dans leur contexte.
Corréler les activités échouées et réussies entre les sources conservées.
Préserver les preuves et coordonner les mesures perturbatrices.
Conservez votre progression
Créez un compte gratuit pour enregistrer cette leçon et continuer sur n'importe quel appareil.
Créer un compte gratuit