Foxency
Administration Système et Infrastructure

Analyse et gestion des journaux système

Les journaux racontent ce qui s'est passé sur vos systèmes, à condition d'être collectés, horodatés et conservés correctement. Syslog, journald, Windows et centralisation : les bonnes pratiques d'exploitation.

Par Rédaction Foxency Publié le 5 min de lecture

Journaux de serveurs et d'équipements réseau centralisés vers un serveur syslog pour analyse

Lorsqu'un service s'arrête, qu'un lien tombe ou qu'un utilisateur ne parvient pas à se connecter, les journaux (logs) sont souvent la seule trace objective de ce qui s'est passé. Encore faut-il qu'ils existent, qu'ils soient correctement horodatés, conservés assez longtemps et consultables rapidement.

Objectif : comprendre les formats et outils de journalisation sous Linux, Windows et sur les équipements réseau, mettre en place une centralisation et analyser efficacement. L'exploitation à des fins de sécurité (corrélation, SIEM) est traitée dans Journalisation et supervision des événements de sécurité.

Syslog : le format historique

Syslog est le standard de fait pour transporter des messages de journalisation, aujourd'hui décrit par la RFC 5424. Chaque message comporte notamment une facilité (origine) et une gravité :

Code Gravité Exemple
0 Emergency Système inutilisable
1 Alert Action immédiate requise
2 Critical Défaillance matérielle
3 Error Erreur d'un service
4 Warning Avertissement
5 Notice Événement normal mais notable (lien qui change d'état)
6 Informational Information
7 Debug Débogage

Les facilités distinguent les sources : kern, auth/authpriv, daemon, mail, local0 à local7 (souvent utilisées par les équipements réseau).

Transport : UDP 514 historiquement (rapide mais sans garantie), TCP pour la fiabilité, et TLS (port 6514, RFC 5425) pour la confidentialité et l'intégrité.

Linux : journald et rsyslog

Les distributions modernes utilisent systemd-journald, qui collecte les journaux du noyau, des services et des applications dans un format binaire indexé. rsyslog (ou syslog-ng) est souvent présent en parallèle pour écrire des fichiers texte et transférer les journaux.

Interroger journald

journalctl -u ssh --since "2026-10-29 08:00" --until "2026-10-29 10:00"
journalctl -p err -b              # erreurs depuis le dernier démarrage
journalctl -k                     # messages du noyau
journalctl -f -u nginx            # suivi en temps réel
journalctl --disk-usage

Par défaut sur certaines distributions, journald ne conserve les journaux qu'en mémoire (/run/log/journal), perdus au redémarrage. Pour les rendre persistants :

# /etc/systemd/journald.conf
[Journal]
Storage=persistent
SystemMaxUse=2G

Fichiers texte classiques

  • /var/log/syslog (Debian, Ubuntu) ou /var/log/messages (RHEL) : journal général ;
  • /var/log/auth.log ou /var/log/secure : authentifications ;
  • journaux applicatifs : /var/log/nginx/, /var/log/apache2/, etc.

Rotation

logrotate fait tourner, compresse et supprime les anciens fichiers pour éviter qu'ils ne remplissent le disque :

# /etc/logrotate.d/application
/var/log/application/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
}

Windows : l'Observateur d'événements

Windows organise ses journaux en canaux : Système, Application, Sécurité, ainsi que de nombreux journaux applicatifs et de services. Chaque événement possède un identifiant.

Get-WinEvent -LogName System -MaxEvents 50
Get-WinEvent -FilterHashtable @{ LogName='System'; Level=2; StartTime=(Get-Date).AddHours(-24) }
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4625 } -MaxEvents 20    # échecs d'ouverture de session

Quelques identifiants utiles : 4624 (ouverture de session réussie), 4625 (échec), 4740 (compte verrouillé), 6005/6006 (démarrage/arrêt du journal des événements, utile pour repérer les redémarrages), 41 dans le journal Système (redémarrage inattendu, source Kernel-Power).

La centralisation native se fait par Windows Event Forwarding (WEF), ou via un agent qui transfère vers un serveur syslog ou un SIEM.

Équipements réseau

Les routeurs et commutateurs envoient leurs messages en syslog. Exemple Cisco IOS (laboratoire) :

service timestamps log datetime msec localtime show-timezone
logging buffered 64000 informational
logging source-interface Vlan99
logging host 10.10.99.30 transport tcp port 514
logging trap notifications
  • logging buffered conserve les messages localement (show logging) ;
  • logging trap fixe la gravité minimale envoyée au serveur ;
  • logging source-interface garantit une adresse source stable, facilitant le filtrage et l'identification.

Centraliser les journaux

Conserver les journaux sur chaque machine pose trois problèmes : ils sont dispersés, perdus si la machine est détruite, et modifiables par un attaquant qui la compromet. La centralisation répond à ces trois problèmes.

Exemple avec rsyslog (serveur)

# /etc/rsyslog.d/10-reception.conf
module(load="imtcp")
input(type="imtcp" port="514")
template(name="ParHote" type="string" string="/var/log/distants/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log")
if $fromhost-ip startswith '10.10.' then {
    action(type="omfile" dynaFile="ParHote")
    stop
}

Exemple avec rsyslog (client)

# /etc/rsyslog.d/90-envoi.conf
*.* action(type="omfwd" target="10.10.99.30" port="514" protocol="tcp"
           queue.type="LinkedList" queue.filename="envoi" queue.saveOnShutdown="on"
           action.resumeRetryCount="-1")

La file d'attente sur disque conserve les messages si le serveur central est momentanément injoignable.

Pour des volumes importants et des recherches avancées, on utilise une plateforme dédiée (pile Elastic/OpenSearch, Graylog, Loki, ou un SIEM).

L'horodatage : un prérequis absolu

Corréler des journaux provenant de plusieurs systèmes n'a de sens que si leurs horloges sont synchronisées. Un écart de quelques minutes rend la reconstitution d'un incident très difficile. Synchronisez tous les équipements sur NTP, et privilégiez un horodatage avec fuseau horaire explicite (ou UTC). Voir NTP et synchronisation horaire des infrastructures.

Méthode d'analyse

  1. Délimiter la période : heure du symptôme, plus une marge avant.
  2. Filtrer par gravité et par source pour réduire le volume.
  3. Chercher le premier événement anormal, pas le dernier : la cause précède souvent de loin les conséquences visibles.
  4. Corréler : un lien qui tombe sur le commutateur, une perte de voisin OSPF sur le routeur, des erreurs de connexion sur les serveurs.
  5. Comparer avec une période normale pour distinguer le bruit habituel de l'anomalie.

Outils simples mais efficaces :

grep -i "link down" /var/log/distants/sw-acces-02/2026-10-29.log
awk '{print $5}' /var/log/auth.log | sort | uniq -c | sort -rn | head
journalctl -u nginx --since "-1h" | grep -c " 502 "

Conservation

Définissez une durée de conservation par type de journal, en fonction des besoins d'exploitation, de sécurité et des obligations légales ou contractuelles applicables à votre organisation. Les journaux pouvant contenir des données personnelles (adresses IP, identifiants), leur conservation doit respecter le principe de minimisation et une durée justifiée.

Erreurs courantes

  • Journaux non persistants perdus au redémarrage.
  • Horloges désynchronisées entre équipements.
  • Disque saturé par des journaux sans rotation.
  • Gravité de débogage activée en production, noyant l'information utile.
  • Centralisation en UDP sans file d'attente, avec perte silencieuse de messages.

Conclusion

Des journaux utiles sont persistants, horodatés précisément, centralisés de manière fiable et conservés selon une politique définie. Avec ces fondations, l'analyse d'un incident devient une enquête méthodique plutôt qu'une recherche à l'aveugle.

Références