Qu'est-ce que Syslog ? Un guide complet 

Syslog est un protocole de journalisation système et un format de message standardisés qui permettent aux appareils, aux applications et aux systèmes d'exploitation d'envoyer des données de journal vers un emplacement central pour le stockage et l'analyse. Il a été conçu pour qu'un routeur, un serveur Linux, un pare-feu et une application de messagerie puissent tous signaler des événements dans le même format de base, indépendamment de leur fabricant ou de leur langage de programmation.

Un message syslog comporte toujours trois éléments : 

• d'où provient l'événement (établissement)
• quel est son degré de gravité (sévérité)
• que s'est-il passé (le texte du message)

Au lieu de se connecter à quarante appareils pour consulter quarante fichiers journaux, un administrateur peut diriger tous les quarante vers un seul serveur syslog et rechercher, filtrer et configurer des alertes sur l'ensemble depuis un seul écran.

Syslog s'exécute par défaut sur presque tous les systèmes de type Unix et est pris en charge sous Windows, sur le matériel réseau et dans la plupart des applications d'entreprise via des agents intégrés ou des transmetteurs tiers.

Comment fonctionne Syslog ?

Syslog fonctionne en faisant transiter un message par trois couches : l'application qui génère l'événement, le transport qui l'achemine, et la couche de collecte qui le stocke et le traite.

Examinons chaque étape plus en détail.

1. Couche applicativeUn programme, un service ou un appareil génère un événement tel qu'une tentative de connexion infructueuse, une connexion interrompue ou un disque proche de sa capacité maximale, et le formate en message syslog à l'aide de la bibliothèque syslog locale (syslog() sous Linux, par exemple) ou d'une fonction de journalisation intégrée.

2. Couche de transport: Le message quitte le périphérique source via le protocole UDP (User Datagram Protocol) ou TCP (Transmission Control Protocol), généralement sur le port 514, et est acheminé vers un destinataire. Dans certains environnements, ce trajet est chiffré à l'aide du protocole TLS sur le port 6514, ce qui est important pour les messages contenant des tentatives d'authentification ou des modifications de configuration.

3. Couche de collecte: Un serveur ou un démon syslog (syslogd, rsyslogd, syslog-ng) reçoit le message, le décompose en champs et décide de la suite à lui donner : l'enregistrer sur le disque, le transférer vers un autre système, déclencher une alerte ou l'acheminer vers un SIEM.

Journalisation locale vs. Journalisation réseau

Tous les messages syslog ne proviennent pas nécessairement du périphérique d'origine. 

• Journalisation locale enregistre les événements dans un fichier sur la même machine ; comme c'est le cas sur la plupart des distributions Linux, il s'agit de /var/log/syslog ou /var/log/messages. Cela fonctionne bien pour le dépannage d'un serveur isolé, mais ce n'est pas évolutif : si un appareil est compromis ou effacé, ses journaux locaux sont perdus.
• Journalisation réseau envoie les mêmes messages à un serveur syslog distant via UDP ou TCP, de sorte qu'une copie de chaque événement se trouve à un endroit inaccessible au périphérique d'origine. 

La plupart des environnements de production utilisent les deux : la journalisation locale pour un dépannage rapide sur la machine, et la journalisation réseau pour la conservation, la corrélation et des preuves qui persistent même si la source est compromise.

Ce qui se passe après la réception d'un message

La première étape consiste à recevoir un message. Un serveur syslog qui fonctionne correctement procède généralement comme suit :

• Analyser le message en champs structurés (horodatage, hôte, installation, niveau de gravité, corps du message)
• Boutique il, généralement dans une base de données ou un système de fichiers indexés à plat, avec une période de rétention définie
• Route vers la destination appropriée, par exemple un SIEM, une plateforme d’analyse des journaux, une archive à long terme, ou plusieurs de ces destinations à la fois
• Alerte si cela correspond à une règle (une hausse soudaine des tentatives de connexion infructueuses, par exemple, ou un code d'erreur spécifique)

Le stockage du message n'est qu'une partie du travail. Pour être utile, un serveur doit également l'analyser, l'acheminer et émettre une alerte.

Qu'est-ce qu'un serveur Syslog ?

Un serveur syslog est le système qui reçoit, indexe et gère les messages de journalisation envoyés par d'autres périphériques du réseau. Il se compose de deux éléments principaux : 

• un écouteur qui accepte les connexions UDP ou TCP entrantes
• une base de données (ou un référentiel de journaux) qui stocke les messages analysés à des fins de recherche et de conservation.

Une fois qu'un message est reçu, le rôle du serveur ne se limite pas à son stockage. Les fonctions généralement assurées par un serveur syslog sont les suivantes :

Client, relais ou serveur Syslog : quelle est la différence ?

Ces trois rôles sont souvent utilisés de manière imprécise, mais ils désignent des fonctions différentes au sein d'un même pipeline :

• Client Syslog est le périphérique d'origine. Les routeurs, les commutateurs, les pare-feu, les systèmes de détection d'intrusion et les appareils IoT agissent tous en tant que clients, en transmettant leurs propres événements vers l'extérieur.
• Relai Syslog est un système intermédiaire qui reçoit des messages et les transmet, parfois après les avoir filtrés ou reformatés. Les relais sont courants dans les réseaux segmentés où un client ne peut pas atteindre directement le serveur central.
• Serveur Syslog est le point de terminaison qui stocke et indexe les messages à long terme.

Pourquoi la journalisation centralisée est importante pour la sécurité

Un serveur syslog qui stocke les journaux en dehors de l'appareil d'origine offre aux équipes de sécurité quelque chose qu'un fichier journal local ne peut pas fournir : des preuves qui survivent à l'incident. 

Si un pirate parvient à accéder à un appareil et supprime ses journaux locaux pour effacer ses traces, les copies déjà envoyées au serveur syslog central restent intactes. C’est l’une des raisons pour lesquelles les données syslog sont utilisées dans le cadre d’enquêtes informatiques et d’audits de conformité. Elles constituent souvent la seule trace disponible de ce qui s’est passé sur un hôte compromis.

Quel est le format des messages Syslog ?

Un message syslog se compose d'une valeur de priorité, d'un en-tête et d'un corps de message. La plupart des gens négligent de comprendre la valeur de priorité — ainsi que les codes de « facility » et de « severity » qui la sous-tendent —, alors que c'est justement ce qui rend les données de journalisation exploitables, et pas seulement lisibles.

Déchiffrer la valeur PRI

La valeur PRI est un nombre unique qui code à la fois la source et la gravité d'un message dans un seul champ.

Chaque message syslog commence par une valeur PRI entre crochets angulaires, par exemple <134>. Ce nombre est calculé comme suit :

PRI = (Installation × 8) + Gravité

Prenons comme exemple. Divisez 134 par 8 : le résultat est 16 avec un reste de 6. Cela signifie que le code de la facilité est 16 (local0) et que le code de gravité est 6 (Informational). Un ingénieur réseau analysant des journaux bruts peut décoder n'importe quelle valeur PRI de la même manière, sans avoir besoin d'un outil de recherche.

Codes d'établissement (0–23)

Le code d'installation identifie le type de processus qui a généré le message.

Niveaux de gravité (0–7)

La criticité indique l'urgence d'un message, et c'est le champ que la plupart des équipes utilisent pour créer des règles d'alerte.

Anatomie d'un message Syslog

Voici un message RFC 5424 annoté :

1 2026-07-15T10:22:41.003Z web-app-03 nginx 8291 – [meta@32473 ip=”203.0.113.5″] Délai d'attente amont dépassé sur /checkout

RFC 3164 vs. RFC 5424 : Ce qui a changé

Syslog utilise actuellement deux formats de messages concurrents, et le fait de savoir lequel est envoyé par un périphérique influe sur la manière dont vous l'analysez.

L'horodatage de la RFC 3164 est la source la plus courante de difficultés d'analyse : en l'absence d'année ou de fuseau horaire, la mise en corrélation d'événements entre les changements d'heure d'été ou entre plusieurs régions nécessite un travail de normalisation supplémentaire. La plupart des environnements actuels reçoivent encore un mélange des deux formats, car les anciens équipements réseau ne peuvent souvent pas être mis à niveau pour prendre en charge la sortie au format RFC 5424.

Quels outils Syslog devez-vous utiliser ?

Les outils Syslog se répartissent en cinq catégories, et la plupart des pipelines de journaux en combinent au moins trois.

• Agents et expéditeurs: Il s'agit d'un logiciel léger installé sur le périphérique source, qui assure le formatage et la transmission des données de journalisation (rsyslog, syslog-ng, NXLog).
• Collecteurs et agrégateurs: systèmes qui reçoivent des messages provenant de nombreuses sources et les regroupent avant de les transmettre
• Relais: il s'agit de relais intermédiaires utilisés dans les réseaux segmentés ou multisites
• Analyseurs: il s'agit des outils qui indexent, recherchent et visualisent les données de journaux (Splunk, Elasticsearch, LogicMonitor Logs)
• Outils d'alerte et d'automatisation: il s'agit de systèmes qui déclenchent des notifications ou exécutent des scripts de correction en fonction du contenu des journaux

Quel outil correspond à quel environnement

• Petite équipe, un seul centre de données : Une seule instance de rsyslog ou de syslog-ng chargée de la collecte, du filtrage et du stockage local suffit généralement.
• Entreprise, multi-sites : Les relais de chaque site transmettent les données à un agrégateur central, surmonté d'une couche d'analyse dédiée permettant la recherche et la corrélation.
• Environnements multi-systèmes d'exploitation : Recherchez des agents prenant en charge nativement Linux, Windows et les différentes variantes de systèmes d'exploitation réseau — Windows ne génère pas de syslog de manière native ; il nécessite donc un agent de transfert (comme NXLog ou Windows Event Forwarding avec un pont syslog) pour pouvoir participer.
• Environnements à forte intensité réseau : Donnez la priorité à un collecteur capable de gérer un volume élevé de messages sur UDP sans perte de paquets, car les routeurs et les commutateurs en charge peuvent générer des milliers de messages par minute lors d'un incident.

Rsyslog contre Syslog-ng

Les deux démons syslog open-source les plus courants diffèrent principalement par la prise en charge des plates-formes et la profondeur de la documentation.

1. Syslog-ng fonctionne sur AIX, HP-UX, Linux, Solaris, Tru64 et plusieurs variantes de BSD, ce qui en fait un meilleur choix pour les environnements mixtes sous divers systèmes d'exploitation. Il prend également en charge la classification et le balisage des journaux en temps réel, et son Guide de l'administrateur officiel détaille les filtres, les sources, les destinations et les formats de journaux de manière suffisamment approfondie pour configurer la plupart des installations sans aide externe.
2. Rsyslog est principalement conçu pour Linux et Solaris. Il est installé par défaut comme démon de journalisation sur la plupart des principales distributions Linux, ce qui en fait la solution de moindre résistance pour les environnements exclusivement Linux, mais sa documentation est plus succincte. Les équipes qui dépannent un module rsyslog spécifique finissent souvent par assembler des détails de configuration à partir de fils de discussion sur des forums plutôt que de la documentation officielle.

Intégration Syslog et SIEM

Les données Syslog alimentent généralement un système plus vaste plutôt que de constituer une finalité en soi. La plupart des plateformes SIEM and XDR ingèrent le syslog comme l'une des nombreuses sources de données, le corrélant avec la télémétrie des points de terminaison, les données de flux réseau et les journaux d'identité pour brosser un tableau plus complet d'un incident.

La sortie syslog d'un pare-feu montrant une tentative de connexion bloquée a plus de sens lorsqu'elle est corrélée avec une alerte de point de terminaison montrant l'exécution d'un logiciel malveillant sur le même hôte en même temps — cette corrélation est ce qu'un SIEM ajoute aux données syslog brutes.

Liste de contrôle pour la sélection d'outils Syslog

Avant de choisir un outil syslog, vérifiez-le par rapport à :

• Prise en charge de l'analyse pour RFC 3164 et RFC 5424
• Recherche en texte intégral et structurée sur les données historiques
• Filtrage basé sur des règles pour contrôler le volume des messages avant stockage
• Alerte sur la gravité, l'établissement ou des correspondances de motifs personnalisés
• Rétention configurable par source ou type de journal
• Prise en charge de TLS pour le transport chiffré
• Prise en charge d'appareils multi-fournisseurs et multi-OS

Quelles sont les meilleures pratiques et les défis liés à Syslog ?

Mettre en place syslog est facile. Le rendre fiable, sécurisé et utile sur le long terme pose problème dans la plupart des environnements.

• Attribuer une responsabilité claire pour le pipelineQuelqu'un doit être responsable du pipeline syslog de la même manière qu'une équipe est responsable d'un service de production, par exemple en décidant quelles sources sont approuvées, en documentant les modifications apportées à la configuration des collecteurs et en vérifiant après chaque changement que les journaux continuent d'arriver de chaque source attendue. Sans cela, il est fréquent qu'une source cesse silencieusement de transférer des journaux pendant des semaines avant que quelqu'un ne s'en aperçoive, généralement au moment précis où ces journaux sont nécessaires pour une enquête.
• Maîtrisez le volume avant qu'il ne vous maîtriseUn seul commutateur occupé peut générer des milliers de lignes de journal par jour, et la plupart d'entre elles ne valent pas la peine d'être conservées. Filtrez à la source dans la mesure du possible, normalisez les formats de message afin que des événements similaires ne se fragment pas en dizaines de variantes, et acheminez uniquement les signaux pertinents vers un stockage coûteux à longue durée de rétention.
• Plan pour les compromis sur la fiabilité des transportsUDP est rapide et léger mais ne garantit pas la livraison ; une rafale de trafic ou un bref problème de réseau peut entraîner la perte silencieuse de messages. TCP garantit la livraison mais ajoute de la surcharge et peut ralentir si le récepteur prend du retard. Les environnements à haute sécurité ou axés sur la conformité migrent généralement les sources de journaux critiques vers TCP ou TCP chiffré par TLS, et réservent UDP aux sources à volume élevé et à faible enjeu telles que les vérifications de santé de routine.
• Sécuriser la couche de collecte elle-mêmeLe chiffrement en transit (TLS sur le port 6514) protège les données de journalisation sur le réseau, mais il ne protège pas le collecteur contre les accès non autorisés, les altérations ou l'insertion par un attaquant de fausses entrées de journal pour effacer ses traces. Restreignez les accès en écriture et en modification sur le serveur syslog, et surveillez le pipeline lui-même pour détecter les interruptions imprévues ou les modifications de configuration.
• Considérez la conservation des données comme un coût d'exploitation, et non pas simplement comme une case de conformité à cocherLes durées de conservation sont souvent définies une seule fois pour satisfaire à une exigence d'audit et ne sont jamais remises en question, même lorsque le volume des journaux augmente. Réexaminer la conservation par rapport aux besoins réels d'investigation et de conformité, plutôt que de choisir par défaut de “ tout conserver pour toujours ”, permet de maintenir des coûts de stockage prévisibles à mesure que l'environnement évolue.

Quels sont les cas d'utilisation courants de Syslog ?

Syslog apparaît partout où un appareil ou une application a besoin de signaler ce qu'il fait, par exemple sur les équipements réseau, les systèmes d'exploitation et les applications.

Appareils de réseau tels que les routeurs, les commutateurs et les pare-feu génèrent des messages syslog qui permettent aux administrateurs de suivre l'activité des utilisateurs, de surveiller les tendances de performance telles que la latence, de détecter le trafic suspect tel que les scans de ports et de signaler les modifications de configuration non autorisées.

Systèmes d'exploitation tels que Linux, Windows et macOS prennent tous en charge la journalisation basée sur syslog pour suivre l'activité des utilisateurs, auditer l'accès aux comptes et détecter les problèmes de performance tels qu'une utilisation élevée du processeur ou des fuites de mémoire avant qu'ils ne provoquent une panne.

Applications comme les bases de données, les serveurs web et les VPN utilisent syslog pour faciliter le contrôle de conformité, le débogage et le suivi de l'état des applications. Une équipe DevOps corrélant un pic d'erreurs HTTP 500 avec un déploiement récent est un exemple concret et direct de données syslog guidant une décision, plutôt que de simplement enregistrer l'historique.

D'où vient le syslog ?

Syslog a vu le jour dans les années 1980 dans le cadre du projet Sendmail d'Eric Allman, conçu pour permettre au serveur de messagerie de journaliser sa propre activité de manière cohérente. D'autres outils Unix ont adopté le même format parce qu'il fonctionnait, et il est devenu un standard de fait des années avant d'être formellement documenté. L'IETF l'a publié en tant que RFC 3164 en 2001 — codifiant une pratique existante plutôt que d'inventer quelque chose de nouveau — puis a suivi avec la RFC 5424 en 2009 pour y ajouter des données structurées, des horodatages précis et des définitions de champs plus claires.

C'est cette histoire qui explique pourquoi les messages de type RFC 3164 (ancien format) apparaissent encore dans les environnements modernes : le matériel réseau plus ancien et les démons Unix de longue date ont été conçus selon le format d'origine et n'ont jamais été mis à jour. Par conséquent, la plupart des pipelines de journaux doivent encore analyser les deux formats.

Gestion de Syslog à grande échelle

Syslog permet de collecter des messages de journalisation provenant de pratiquement tous les appareils et applications de votre environnement. Cependant, à mesure que l'infrastructure se développe, la simple collecte des journaux ne suffit plus. Les équipes ont également besoin de rechercher, corréler, configurer des alertes et analyser ces journaux en même temps que les métriques d'infrastructure. LogicMonitor rassemble ces fonctionnalités sur une seule et même plateforme, aidant les équipes d'exploitation à enquêter plus rapidement sur les problèmes en visualisant les données syslog en contexte avec les ressources et les alertes qui les ont générées.

FAQ