Qu'est-ce que le syslog ? Facility, severity et port 514

Le syslog est le protocole qui permet à un équipement de consigner ce qui lui arrive sous forme de lignes de texte et de les envoyer à un serveur central. Switchs, pare-feu, serveurs, imprimantes et onduleurs le font depuis quarante ans presque à l’identique : un événement survient, l’équipement écrit une ligne, la ligne part sur le réseau. Il ne vous reste qu’à prévoir quelqu’un pour écouter.

Dans une salle d’audience, c’est le rôle du greffier. Le président parle, les parties parlent, un témoin parle ; le greffier consigne ce qui a été dit, tel que cela a été dit, avec l’heure. Il ne décide de rien et n’a même pas besoin de comprendre. Sa tâche est qu’un procès-verbal existe. Quand un recours arrive des mois plus tard, personne ne consulte les souvenirs : on consulte le procès-verbal.

Les équipements de votre réseau parlent en permanence. Le problème de la plupart des organisations n’est pas leur silence, mais l’absence de greffier. Cet article montre à quoi ressemble une ligne syslog, comment lire le nombre entre les premiers chevrons, pourquoi le protocole a choisi l’UDP 514 et ce qu’il ne transporte pas. Il examine ensuite de vraies entrées d’un switch de laboratoire et en vient à la question difficile : une fois les journaux arrivés, lesquels comptent ? C’est la porte d’entrée du guide supervision et alertes. Commandes et sorties proviennent du laboratoire de l’auteur et sont laissées telles qu’elles ont été enregistrées.

Qu’est-ce que le syslog, et quel problème résout-il ?

Le syslog sépare l’équipement qui produit les événements du serveur qui les conserve. L’équipement dit seulement « voilà ce qui s’est passé » et lâche la ligne ; où elle est écrite, combien de temps et qui la lit ne le regardent plus. Toute la force du protocole vient de cette séparation, et toutes ses lacunes aussi.

Un événement sans trace n’a pas eu lieu

La panne la plus coûteuse est celle qui ne laisse aucune trace. Un port tombe une minute à trois heures du matin puis revient. Le matin, personne ne remarque rien ; les utilisateurs disent « Internet a coupé un moment, je crois », vous vérifiez, tout est normal, et trois semaines plus tard cela recommence. Ce n’est pas une panne impossible à diagnostiquer, c’est une panne non consignée.

Pourquoi le journal de l’équipement ne suffit pas

Chaque switch et chaque pare-feu tient un journal interne. Le problème n’est pas qu’il existe, mais qu’il vous échappe de trois façons :

1. Il n’est pas persistant. La mémoire tampon peut être trop petite ou effacée à la coupure de courant.
2. Il est limité. Une fois plein, les plus anciennes lignes sont écrasées. Plus l’équipement est bavard, plus son historique est court.
3. Il est inaccessible pendant la panne. Au moment où vous en avez besoin, l’équipement ne répond pas.

J’ai mesuré le premier point sur le switch du laboratoire, et la preuve se trouve à un endroit intéressant. Après un redémarrage dû à une coupure de courant, la plus ancienne ligne du tampon était celle-ci :

<185> Aug 19 06:57:16 0.0.0.0-1 SIM[Cnfgr_Thread ]: sim_util.c(3804) 8 %% Switch was reset due to power disruption.

Rien avant. Tout l’historique antérieur est parti avec la coupure. L’équipement vous annonce qu’il a perdu la mémoire, depuis la mémoire qu’il a perdue.

Quand vous n’avez pas besoin du syslog

Dans un bureau de trois personnes avec un routeur et un switch, la centralisation des journaux est une couche inutile. Le seuil n’est pas le nombre d’équipements, mais le temps qu’il faut pour répondre à une question. Si vous ne pouvez pas répondre à « que s’est-il passé hier soir, et à quelle heure ? » sans vous connecter à chaque équipement, il vous faut une centralisation.

Une situation courante mérite d’être distinguée. Beaucoup d’organisations n’ont pas de journal central mais ont un enregistrement structuré : l’accounting RADIUS. Il arrive tout seul avec le Wi-Fi ou le 802.1X et s’accumule pendant des années. Mais il répond à une autre question : l’accounting RADIUS enregistre des sessions (qui, quand, combien de temps, combien de trafic), le syslog des événements (quel port est tombé, quel processus a échoué, quelle configuration a changé). L’un dit « qui est entré », l’autre « qu’est-ce qui a cassé ».

Un troisième canal est à ne pas confondre : SNMP va chercher des nombres, le syslog reçoit les phrases qu’écrit l’équipement. SNMP dit que le CPU est à 80 % ; le syslog, quel processus le charge. Le mécanisme est détaillé dans Qu’est-ce que le SNMP ?

Pourquoi Windows n’envoie pas de syslog de lui-même

C’est là que les projets de centralisation des réseaux mixtes calent le plus souvent. Switchs, pare-feu, imprimantes et serveurs Linux parlent syslog nativement ; Windows, non. Windows écrit dans l’Event Log, un système à part, fait d’objets structurés plutôt que de lignes de texte : un événement porte un numéro comme 4624 et son contenu est découpé en champs. Raccorder la plupart des équipements à un collecteur tient en un réglage ; les serveurs Windows exigent un agent de traduction. Planifiez les deux groupes séparément.

À quoi ressemble un message syslog ? Anatomie d’une ligne

Un message syslog est du texte brut en trois parties : champ de priorité, heure et source, contenu. Une vraie ligne du switch du laboratoire :

<189> Aug 19 06:57:33 sercebilisimsw01-1 TRAPMGR[trapTask]: traputil.c(735) 235 %% Link Up: Vl5

Le <189> initial n’est pas décoratif : c’est la seule information structurée que porte le protocole. Le milieu rattache l’entrée à qui et quand. Le texte final est écrit librement par le constructeur et ne suit aucune norme.

Le champ de priorité : le nombre entre chevrons

Le champ de priorité (PRI) loge deux informations dans un seul nombre : d’où vient le message et à quel point il est urgent.

PRI = (facility × 8) + severity

Décomposons 189 : 189 ÷ 8 = 23, reste 5. Le quotient 23 est la facility 23, soit local7 ; le reste 5 est la severity 5, soit notice. La ligne est une entrée normale mais notable, issue de local7. Plutôt que de me fier au calcul, j’ai interrogé l’équipement :

show logging

Logging is enabled
Console Logging: Level warnings. Messages : 85 logged, 315 ignored
Buffer Logging: Level informational. Messages : 210 logged, 190 ignored
File Logging: Level emergencies. Messages : 0 logged, 400 ignored
Logging facility level : local7

La dernière ligne indique local7. Le quotient correspond au réglage de l’équipement.

Heure, source et contenu

Après le champ de priorité vient la partie qui rattache l’entrée à un instant et à un équipement : Aug 19 06:57:33 est l’horodatage, sercebilisimsw01-1 le nom que l’équipement se donne. Ces deux champs viennent de l’équipement, et aucun ne mérite une confiance aveugle. L’horodatage vient de son horloge ; si elle dérive, l’entrée est archivée à la mauvaise heure. Le nom est accepté sans vérification par le collecteur. Le -1 final est le numéro d’unité dans une pile (stack).

Dans le contenu, la norme s’arrête. TRAPMGR[trapTask]: traputil.c(735) 235 %% Link Up: Vl5 comporte le processus et le thread, le fichier source et la ligne du firmware, le compteur d’événements de l’équipement, puis le vrai message destiné à un humain. Une autre marque signale le même événement avec une phrase totalement différente, car aucune norme ne régit cette partie. Le syslog normalise la façon dont un message voyage, pas ce qu’il dit.

RFC 3164 et RFC 5424 : deux formats, tous deux en service

Le switch du laboratoire écrit Aug 19 06:57:33, donc l’ancien format. L’absence d’année semble anodine mais nuit à la conservation longue : dans une archive de deux ans, de quel 19 août s’agit-il ? Le collecteur complète avec son heure de réception ; l’exactitude dépend alors de l’horloge du serveur, pas de celle de l’équipement.

À quoi ressemblent les données structurées sur le câble

L’original turc de cet article s’arrête au tableau ci-dessus. Voici à quoi ressemble réellement la seconde colonne, d’après une capture prise sur le collecteur du laboratoire pendant un test de transport en clair, et elle montre une chose que la RFC 3164 ne peut pas exprimer :

<13>1 2026-08-19T00:58:11.200471+00:00 sercesyslog gizli-test - - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="46500"] PAROLA=CokGizli123 duz metin gidiyor

1. <13> est de nouveau le champ de priorité : 13 = 1 × 8 + 5, facility user, severity notice, la valeur par défaut d’un message envoyé à la main avec logger.
2. Le 1 juste après est le numéro de version. Ce seul chiffre indique au collecteur qu’il lit du RFC 5424.
3. 2026-08-19T00:58:11.200471+00:00 est un horodatage complet avec année, microsecondes et fuseau. L’ambiguïté de la section précédente disparaît.
4. Les deux tirets sont des champs vides (identifiant de processus et de message) ; la RFC 5424 marque une valeur absente par -.
5. [timeQuality tzKnown="1" isSynced="1" syncAccuracy="46500"] est un élément de données structurées, et c’est la partie intéressante.

timeQuality est défini dans la RFC 5424 elle-même. L’émetteur y indique à quel point son horodatage est fiable : tzKnown="1" signifie qu’il connaît son fuseau ; isSynced="1", que son horloge est synchronisée sur une source externe ; syncAccuracy="46500" est la précision annoncée en microsecondes, ici 46,5 millisecondes. Le message porte donc une déclaration sur la fiabilité de sa propre horloge. Une ligne à l’ancien format ne le peut pas.

Deux réserves s’imposent. C’est une affirmation de l’émetteur, non vérifiée comme tout le reste du syslog : un équipement à l’horloge défaillante qui se croit synchronisé le dira. Et elle n’est utile que si votre collecteur conserve les données structurées au lieu de les aplatir. Là où les horodatages comptent, il est peu coûteux de garder ce champ et d’alerter sur isSynced="0" : on repère ainsi un émetteur qui dérive avant que ses entrées n’arrivent dans le mauvais ordre.

Le reste de la ligne explique pourquoi la capture existe : PAROLA=CokGizli123 duz metin gidiyor signifie en turc « MOTDEPASSE=TresSecret123 part en clair », une chaîne de test envoyée sur le port 514 pour montrer que n’importe qui peut la lire. Le même test en TLS sur le port 6514 a donné l’inverse : chercher PAROLA dans la capture n’a donné aucun résultat, seuls les en-têtes TCP étaient visibles.

Facility et severity : deux informations dans un nombre

La severity dit à quel point un message est urgent ; la facility, d’où il vient. Les deux sont indépendantes : une imprimante peut envoyer un message critique, le noyau un message d’information.

Les huit niveaux de gravité

La severity prend huit valeurs, et plus le nombre est petit, plus c’est urgent :

Deux lignes du même équipement rendent la différence concrète :

<189> Aug 19 06:57:33 sercebilisimsw01-1 TRAPMGR[trapTask]: %% Link Up: Vl5
<185> Aug 19 06:57:16 0.0.0.0-1 SIM[Cnfgr_Thread ]: %% Switch was reset due to power disruption.

189 = 23 × 8 + 5 donne local7.notice : une interface est montée, fonctionnement normal. 185 = 23 × 8 + 1 donne local7.alert : l’équipement a redémarré après une coupure de courant, la première ligne à lire le matin. Un seul caractère d’écart, mais c’est la différence entre « tout va bien » et « il s’est passé quelque chose cette nuit ».

24 facilities, et pourquoi local0 à local7 existent

Les 16 premières facilities ont un sens fixe, hérité de l’Unix des années 1980 (kern, mail, auth, lpr) ; les équipements réseau n’y figurent pas. Les huit restantes, local0 à local7, sont volontairement indéfinies : c’est vous qui leur donnez un sens. En pratique, on attribue une valeur par classe d’équipement, et le collecteur écrit chacune à son propre endroit :

Le piège : le switch du laboratoire utilise local7 par défaut, comme la plupart des constructeurs. Si vous n’attribuez rien, tous vos équipements tombent sur la même valeur, et la séparation qu’offre la facility n’existe jamais.

Comment fonctionne le seuil : « ce niveau et au-dessus »

Les équipements tiennent un seuil par destination et n’envoient rien en dessous. La sortie de show logging le montre en chiffres :

La troisième ligne est l’erreur de terrain la plus courante, mesurée : avec un seuil trop strict, la journalisation « fonctionne » et reste vide. Personne ne prévoit de produire des messages emerg ; ce niveau est réservé au moment où le système n’est plus là.

Pourquoi le syslog utilise le port 514 et l’UDP

Le syslog utilise par défaut l’UDP 514, et ce choix découle de sa raison d’être : un équipement ne doit pas ralentir pour rendre compte de lui-même. L’UDP n’établit pas de connexion et n’attend pas d’accusé de réception ; l’équipement dépose la ligne et poursuit son travail.

Le prix : l’UDP ne garantit pas la livraison et ne prévient personne quand elle échoue. Dans la salle d’audience, c’est une page de procès-verbal perdue ; le problème n’est pas la page, mais que personne n’ait noté combien il y en avait. Sur un réseau interne peu chargé, les pertes UDP sont négligeables. Elles comptent sur une liaison étroite et chargée entre équipement et collecteur, ou quand le collecteur ne suit pas un pic soudain, soit précisément quand vous avez le plus besoin des entrées. C’est une raison de placer le trafic d’administration dans son propre VLAN (voir Qu’est-ce qu’un VLAN ?).

Sur un émetteur Linux, le transport se choisit avec un seul caractère :

*.* @192.168.1.46:514
*.* @@192.168.1.46:514

Un @ signifie UDP, deux @@ TCP. Un caractère, et la différence est de savoir si les pertes restent silencieuses. Vérifiez-le en premier quand vous héritez d’une configuration.

TCP si vous devez détecter les pertes. TLS sur le port 6514 si les entrées ne doivent pas être lisibles en transit. Les deux si les journaux peuvent servir de preuve. Ne confondez pas ce que fait TLS ici : il chiffre le transport, il ne signe pas l’entrée. Une fois la ligne écrite sur disque, TLS a fini ; savoir si le fichier est modifié ensuite est une autre question.

Ce que le syslog ne transporte pas : identité, intégrité, ordre

Une adresse source n’est pas une identité. Le collecteur attribue une entrée à un équipement d’après l’adresse source du paquet, qui peut être falsifiée en UDP. La mesure pratique se situe autour du protocole : n’ouvrez le 514 qu’aux émetteurs connus.

Qui garantit qu’une entrée n’a pas été modifiée ? Pas le syslog. La ligne ne porte ni signature ni somme de contrôle ; chez le collecteur, c’est un simple fichier texte. L’intégrité est une couche à part : empreintes chaînées, droits d’écriture restreints, archive sur un support séparé. Selon le contenu de vos journaux, cette couche n’est pas facultative :

• Les journaux contiennent presque toujours des adresses IP et des noms d’utilisateur, que le RGPD traite comme des données personnelles. Votre archive relève donc du principe de limitation de la conservation de l’article 5, paragraphe 1, point e) (pas plus longtemps que nécessaire) et des exigences de sécurité de l’article 32.
• Si vous traitez des cartes de paiement, PCI DSS v4.0, exigence 10.5.1 impose au moins douze mois d’historique des journaux d’audit, dont les trois derniers immédiatement disponibles.

Si l’horloge dérive, que vaut le procès-verbal ? Si deux équipements ont dix minutes d’écart, leurs entrées côte à côte montrent les événements dans le mauvais ordre. La première étape d’une centralisation n’est donc pas le collecteur, mais la source de temps. L’élément timeQuality montré plus haut est la façon dont un émetteur RFC 5424 indique s’il dispose de cette source.

Le syslog sur le terrain : filtrer le bruit

Le vrai travail commence quand les journaux arrivent, car collecter n’est pas lire.

Laboratoire : combien un switch dit-il en une minute ?

La réponse habituelle : « un switch parle peu, un port tombe de temps en temps ». J’ai mesuré. J’ai raccordé le switch du laboratoire à un collecteur tout neuf, sans rien faire d’autre, et attendu soixante secondes :

60 satır / 8.670 bayt

C’est « 60 lignes / 8 670 octets » en turc ; le résumé de mesure a été noté en turc. À ce rythme, un seul switch produit environ 11 Mo par jour, environ 4,3 Go par an, alors qu’il ne se passe rien. Appliquez la fenêtre PCI DSS ci-dessus et un seul switch inactif occupe à lui seul environ 4 Go de conservation obligatoire ; multipliez par votre nombre de switchs avant de dimensionner le disque du collecteur.

Le chiffre n’est pas la surprise ; le contenu, si. Sur 149 lignes collectées, 148 venaient du programme DOT1S et une de CLI_WEB. La seule entrée utile représentait sept millièmes du volume :

<190> Aug 19 07:01:59 sercebilisimsw01-1 CLI_WEB[emWeb]: %% [CLI:ilker:192.168.1.115] User has succesfully logged in

Qui s’est connecté au switch en administrateur, quand et d’où : la première ligne que vous chercheriez pour une question de sécurité, enfouie sous 148 autres.

Une ligne répétée des centaines de fois signale une panne

Les 148 lignes de bruit étaient deux messages en alternance :

<187> DOT1S[dtlTask]: dot1s_txrx.c(306) %% dot1sBpduReceive(): Discarding the BPDU, since it is an invalid BPDU type
<189> DOT1S[dtlTask]: dot1s_txrx.c(1286) %% dot1sBpduReceive(): Invalid Forward Delay

Toutes les deux secondes, sans interruption. Le switch recevait des messages du protocole qui empêche les boucles (spanning tree) et les jetait faute de pouvoir les interpréter.

La règle : un message répété chaque seconde n’est pas une information, c’est un symptôme. La répétition ne le rend pas insignifiant ; elle montre qu’un problème non résolu tourne en arrière-plan. Mais la même règle dit qu’il ne doit pas entrer tel quel dans l’archive.

Que garder, que jeter ?

Le filtrage se fait en trois étapes : le seuil chez l’émetteur (laisser debug actif en permanence est la première source de bruit ; pour un pare-feu, décidez d’avance quels jeux de règles journaliser), la séparation chez le collecteur (fichiers par équipement et par processus ; avec DOT1S et CLI_WEB dans le même fichier, le second disparaît) et la suppression des répétitions et la conservation (regrouper les répétitions en une ligne, compresser et archiver les anciennes entrées selon votre règle de conservation). Sautez les trois et la fin est prévisible : le disque se remplit, la journalisation s’arrête, et vous le découvrez le jour où vous avez besoin des journaux.

Conclusion : sans greffier, l’audience n’a jamais eu lieu

Le syslog n’est pas compliqué. Un équipement écrit une ligne, loge deux informations dans le champ de priorité et l’envoie au port 514. Ce qu’il faut apprendre, ce n’est pas le protocole, mais ce qu’il ne garantit pas : ni la livraison, ni l’identité de l’émetteur, ni l’intégrité de l’entrée, ni l’exactitude de l’horloge. Chacun de ces points est une couche que vous construisez. La RFC 5424 aide à la marge, jusqu’à permettre à l’émetteur de déclarer la fiabilité de son horloge, mais c’est au collecteur de conserver et de vérifier cette déclaration.

Et la mesure l’a montré : un switch dit soixante lignes par minute alors qu’il ne se passe rien. Quatre-vingt-dix-neuf pour cent ne vous apprennent peut-être rien. Les sept millièmes restants sont la seule trace de qui s’est connecté à trois heures du matin. Si vous ne collectez pas cette entrée, l’événement n’a jamais eu lieu.