Ldfa Posté(e) il y a 9 heures Posté(e) il y a 9 heures durée de lecture : 9 min Surveiller et comprendre les logs serveur Linux est une compétence essentielle pour tout administrateur système. Que ce soit pour diagnostiquer un problème au démarrage ou auditer les connexions SSH, les logs de démarrage Linux et les logs de connexion Linux offrent une mine d’informations précieuses. Grâce à des outils comme journalctl ou en consultant des fichiers tels que /var/log/auth.log, vous pouvez facilement repérer les tentatives de connexion échouées, détecter des comportements anormaux ou encore assurer la sécurité de votre serveur Linux. Dans ce tutoriel, nous allons voir comment analyser les logs de démarrage et de connexion, quels fichiers et commandes utiliser, et quelles bonnes pratiques adopter pour l’analyse des logs Linux. Que vous soyez débutant ou administrateur expérimenté, cet article vous donnera toutes les clés pour maîtriser l’analyse des logs sur un serveur Linux. Sommaire de l'article 1 Comprendre les logs serveur Linux et leur rôle essentiel 1.1 Importance des logs pour la sécurité et le diagnostic 1.2 Emplacement des fichiers de logs principaux 2 Analyser les logs de démarrage 2.1 Utilisation de journalctl pour les logs de démarrage 2.2 Commande Last et fichier wtmp 2.3 Interprétation des messages de démarrage 3 Sécuriser votre système grâce à l’analyse des logs serveur Linux 3.1 Analyse de /var/log/auth.log pour les connexions SSH 3.2 Détection des tentatives de connexion échouées 4 Mettre en place la rotation de fichier log 5 FAQ – Analyse des logs de démarrage et de connexion sur un serveur Linux Comprendre les logs serveur Linux et leur rôle essentiel Importance des logs pour la sécurité et le diagnostic Les logs système sous Linux jouent un rôle essentiel dans la gestion, le diagnostic et la sécurité d’un serveur. Ils permettent de retracer les événements du système, d’identifier des erreurs au démarrage, de surveiller l’activité des utilisateurs et de détecter d’éventuelles tentatives de connexion non autorisées. Une bonne maîtrise de l’analyse des logs permet de réagir rapidement face à un dysfonctionnement ou une menace de sécurité. En consultant régulièrement les logs de démarrage Linux et les logs de connexion Linux, un administrateur peut anticiper les problèmes et renforcer la sécurité du serveur Linux. Emplacement des fichiers de logs principaux Sous Linux, la majorité des fichiers de logs sont stockés dans le répertoire /var/log. Voici quelques-uns des fichiers les plus utilisés pour l’analyse : /var/log/syslog ou /var/log/messages : contiennent des informations générales sur le système. /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (CentOS/RHEL) : enregistrent les connexions SSH, les authentifications et les tentatives échouées. /var/log/dmesg : stocke les messages du noyau au démarrage. /var/log/boot.log : affiche les messages relatifs à la séquence de démarrage. /var/log/faillog et /var/log/lastlog : utiles pour suivre les échecs d’authentification et les dernières connexions. Pour une vision consolidée des événements, l’outil journalctl, utilisé avec systemd, permet de consulter l’ensemble des logs système de manière centralisée et filtrée, notamment ceux liés au démarrage et aux connexions utilisateur. Analyser les logs de démarrage Utilisation de journalctl pour les logs de démarrage Sous les distributions Linux utilisant systemd, la commande journalctl est l’outil principal pour consulter les logs de démarrage Linux. Elle permet d’extraire toutes les informations liées à la séquence de démarrage, depuis le moment où le noyau est chargé jusqu’au lancement complet du système. Pour visualiser les logs du dernier démarrage, on peut utiliser la commande : journalctl -b Vous pouvez également filtrer par niveau de gravité (erreur, avertissement, etc.) ou par unité systemd spécifique. Cela permet de diagnostiquer rapidement les lenteurs de démarrage ou les services défaillants sur votre serveur Linux. Commande Last et fichier wtmp Sous Linux, la commande last permet de lire le contenu des fichiers /var/log/wtmp et /var/log/btmp. Pour connaître les dates et heures ou la machine s’est arrêtée il suffit de taper la commande : #last –x shutdown --time-format iso Les différents shutdown, sont classés du plus récent au plus vieux. Le paramètre –time-format iso permet d’ajouter des informations comme l’année par exemple et à un format de date plus lisible, du moins pour ma part. Pour connaître les dates et heures ou la machine a rebooté, il suffit de taper la commande : #last –x reboot --time-format iso Nous voyons ici que le denier reboot date du 1 mai 2025 à 19h25. Information!!! Le paramètre –x permet d’afficher également les arrêts du système et les modifications de niveau d’exécution (run level). Le fichier wtmp contient une trace de toutes les connexion et déconnexions du système (arrêt, reboot). Le fichier btmp contient tous les échecs de connexions à votre système. Il est impossible de lire directement ces fichiers avec un éditeur de texte type vi ou vim. Voici un exemple avec le fichier btmp : Ah oui, pas facile pour récupérer les informations. Pour lire le fichier de façon plus agréable, vous devez utiliser la commande suivante (vous pouvez utiliser la même commande pour le fichier wtmp): #last –f /var/log/btmp 1: login utilisé pour se connecter à votre machine. 2: type de connexion utilisée, ici ssh 3: adresse ip du hackeur 4: date de tentative de connexion Comme vous pouvez le constater ici l’ip 185.227.152.113 effectue de la brute force pour récupérer un accès sur ma machine. Interprétation des messages de démarrage Les messages de démarrage fournissent des indications précieuses sur le bon fonctionnement des différents composants du système. Ils incluent notamment : Le chargement du noyau et des modules, La détection du matériel, Le montage des systèmes de fichiers, Le démarrage des services systemd. Il est essentiel d’identifier les messages d’erreur (souvent signalés par Failed ou Error) qui peuvent ralentir ou bloquer le démarrage du serveur. De même, les messages comme Job running, Timeout, ou Dependency failed indiquent des problèmes de dépendances ou de services mal configurés. Une analyse régulière des logs de démarrage permet de s’assurer que le système reste stable et performant, et d’intervenir rapidement en cas d’anomalie. Sécuriser votre système grâce à l’analyse des logs serveur Linux Analyse de /var/log/auth.log pour les connexions SSH L’un des fichiers les plus importants pour suivre l’activité des connexions SSH sur un serveur Linux est le fichier /var/log/auth.log (ou /var/log/secure sur CentOS/RHEL). Il enregistre toutes les tentatives d’authentification, qu’elles soient réussies ou échouées, ainsi que les élévations de privilèges via sudo. Pour examiner ces logs de connexion Linux, vous pouvez utiliser une commande comme : grep sshd /var/log/auth.log Cela vous permettra d’identifier quels utilisateurs se sont connectés, à quel moment, depuis quelle adresse IP, et s’ils ont été authentifiés avec succès. Cette analyse est essentielle pour auditer les connexions SSH et maintenir la traçabilité des accès sur votre serveur. Détection des tentatives de connexion échouées Les tentatives de connexion échouées sont des indicateurs clés d’une éventuelle tentative d’intrusion. Elles apparaissent souvent dans les logs sous la forme : Failed password for invalid user ... Pour extraire rapidement ces événements, vous pouvez utiliser : grep "Failed password" /var/log/auth.log ou, pour une vue plus synthétique : awk '/Failed password/ {print $(NF-3)}' /var/log/auth.log | sort | uniq -c | sort -nr Cela vous permet de repérer les adresses IP à l’origine de plusieurs échecs, et de mettre en place des contre-mesures (comme fail2ban ou des règles de pare-feu) pour renforcer la sécurité de votre serveur Linux. La surveillance proactive des logs SSH permet non seulement de détecter les attaques en cours, mais aussi d’identifier les failles potentielles dans la configuration du serveur ou dans les pratiques des utilisateurs. Mettre en place la rotation de fichier log Il vous est possible de définir la durée de conservation de ces logs. Pour ce faire vous devez éditer le fichier /etc/logrotate.conf. Ce qui nous intéresse ici se sont les lignes surlignées en jaune. Voici quelques explications de ces lignes : monthly : La rotation s’effectuera tous les mois. Nous pouvons aussi mettre daily pour tous les jours, weekly pour toutes les semaines. create 0664 root utmp : Les fichiers secondaire créés auront pour créateur root et appartienne au groupe utmp et auront les droits 664. minsize : demande la rotation des log si le fichier fait au minimum la taille définie par cette variable. size : les fichiers ne sont archivés que si leur taille dépasse la valeur définie ici. rotate 1 : Nous garderons 1 fichiers de log missingok : signifie que l’absence du/des fichier(s) log(s) n’est pas anormale. Si cette option n’est pas active alors l’administrateur recevra un mail si le/les log(s) est/sont manquant(s). D’autres paramètres existent comme : compress : Les fichiers logs secondaire c’est à dire tout ce qui n’est pas le fichier de log principal seront compressés. delaycompress : Reporte la compression du journal précédent au prochain cycle de permutation. Ceci n’a un effet qu’utilisé en combinaison avec l’option compress. Elle peut être utilisée quand il n’est pas possible de demander à un programme de fermer son journal et qu’il puisse par conséquent continuer à écrire pour un moment dans le journal précédent. notifempty : permet de ne pas permuter le journal lorsqu’il est vide prerotate, postrotate/endscript : Les lignes entre prerotate et endscript (chacun devant apparaître sur une ligne isolée) seront exécutées avant permutation du journal. Ces directives doivent apparaîtrent dans la définition d’un journal Pour connaître les autres options vous pouvez consulter le man à cette adresse : man logrotate. Afin d’avoir un peu d’historique, j’ai configuré la rotation de cette manière : Dans l’exemple ci-dessus, la rotation s’effectue au bout d’un an à moins que la taille du fichier atteigne les 15 Mo. Par défaut (les cinq premières lignes), la durée de rotation est d’une semaine et la conservation sur 1 mois (rotate 4). Une fois la configuration de votre logrotate terminé, vous pouvez forcer sont exécution de cette manière : #logrotate -f /etc/logrotate.conf ou pour débugger : #logrotate -d /etc/logrotate.conf Si vous souhaitez découvrir d’autres commandes ou astuces pratiques sous Linux, vous pouvez consulter ce tutoriel : Optimiser et dépanner un serveur Linux. FAQ – Analyse des logs de démarrage et de connexion sur un serveur Linux Comment accéder aux logs de démarrage sur un serveur Linux ? Vous pouvez consulter les logs de démarrage Linux en utilisant la commande journalctl -b. Cette commande affiche tous les messages du journal générés depuis le dernier démarrage du système. Pour analyser un démarrage précédent, utilisez journalctl -b. Où trouver les logs de connexion SSH sur Linux ? Les logs de connexion Linux, notamment ceux liés à SSH, sont généralement stockés dans le fichier /var/log/auth.log (sur les distributions Debian/Ubuntu) ou /var/log/secure (sur CentOS/RHEL). Ces logs permettent de suivre les connexions réussies et échouées. Comment détecter les tentatives de connexion échouées ? Vous pouvez utiliser la commande suivante pour repérer les tentatives échouées dans le fichier de log : grep "Failed password" /var/log/auth.log C’est utile pour auditer les connexions SSH et identifier d’éventuelles attaques par force brute. Quels outils permettent d’analyser les logs sous Linux ? En plus de journalctl, vous pouvez utiliser des outils comme : logwatch : pour générer des rapports quotidiens des logs. logrotate : pour gérer l’archivage des logs. Des solutions comme ELK Stack ou Loggly pour une analyse avancée des logs Linux avec visualisation. Pourquoi est-il important de surveiller les logs serveur Linux ? L’analyse régulière des logs permet de : Identifier rapidement des erreurs système ou des problèmes de configuration. Détecter des tentatives d’intrusion ou des connexions suspectes. Maintenir un haut niveau de sécurité sur le serveur Linux. Afficher l’article complet
Messages recommandés
Créer un compte ou se connecter pour commenter
Vous devez être membre afin de pouvoir déposer un commentaire
Créer un compte
Créez un compte sur notre communauté. C’est facile !
Créer un nouveau compteSe connecter
Vous avez déjà un compte ? Connectez-vous ici.
Connectez-vous maintenant