Résumé

  • Dans le comportement décrit par le RFC 3164, un relais devait compléter un paquet dont l’horodatage manquait ou était invalide avec sa propre heure locale et, de préférence, une identité de machine déduite.
  • Le paquet complété devait toujours tenir dans 1 024 octets. Si les nouveaux champs le faisaient déborder, le relais devait couper la fin du contenu original.
  • Les normes ultérieures ont mieux séparé origine, relais, collecte et transport. Elles n’ont pas transformé un en-tête bien formé, un pair TLS ou un cadrage exact en preuve de provenance de bout en bout.

Une réparation qui consommait la preuve

Le syslog historique n’était pas d’abord un grand registre central. Des programmes produisaient de courts avis, des machines pouvaient les transmettre, et des collecteurs les rassemblaient. Le RFC 3164, publié en 2001, décrivait les pratiques BSD observées. Il nommait « device » la source, « relay » la machine qui recevait puis retransmettait, et « collector » celle qui recevait sans poursuivre la chaîne.

Cette chaîne devait fonctionner avec des émissions imparfaites. Le relais examinait d’abord PRI, la priorité encodée entre chevrons, puis la forme de TIMESTAMP. Si les deux étaient valides et que sa configuration ordonnait le transfert, il retransmettait le paquet sans le modifier. Il n’avait pas à vérifier que l’heure était juste ni que HOSTNAME correspondait à l’adresse de l’émetteur réseau. La correction syntaxique était un critère de traitement, pas un constat d’authenticité.

La branche intéressante commençait lorsque PRI était reconnaissable mais TIMESTAMP absent ou mal formé. Le relais devait insérer, juste après PRI, un horodatage et une espace. Cet horodatage n’était pas celui de l’événement retrouvé par magie : c’était l’heure locale courante du relais. Il devait aussi, de préférence, ajouter HOSTNAME, soit le nom de l’appareil tel qu’il le connaissait, soit son adresse IP si aucun nom n’était disponible. Tout ce qui avait été reçu ensuite devenait CONTENT.

Le paquet semblait désormais mieux situé. Pourtant le même RFC exigeait qu’il mesure au plus 1 024 octets. Après l’ajout de l’heure et du nom, le relais devait recompter. Si la nouvelle forme dépassait la limite, il devait la tronquer à 1 024 octets. Le texte précise que des informations vitales pouvaient ainsi être perdues à la fin du paquet original.

Ce n’était donc pas un simple nettoyage d’en-tête. Le relais échangeait des octets de contenu contre des octets de contexte. Une alerte terminée par le nom de l’objet affecté, le résultat d’une opération ou la cause détaillée pouvait conserver un préfixe impeccable et perdre précisément sa conclusion.

Le paquet sans priorité coûtait encore plus cher

Le RFC prévoyait une troisième branche. Si PRI manquait ou ne pouvait pas être identifié, le relais insérait la priorité par défaut 13, ajoutait son horodatage, ajoutait de préférence HOSTNAME, puis traitait tout le paquet d’origine comme contenu. Là encore, l’ensemble devait être ramené à 1 024 octets.

Cette réparation produisait une apparence régulière à partir d’un message irrégulier. Un relais suivant pouvait voir un PRI et un TIMESTAMP valides et transmettre l’ensemble sans nouveau changement. Le paquet ne portait pas nécessairement une confession disant quels champs provenaient de l’émetteur et lesquels avaient été fournis au premier passage. L’histoire de la transformation pouvait disparaître alors même que la syntaxe s’améliorait.

Le vieux TIMESTAMP ajoutait une autre ambiguïté. Il indiquait mois, jour et heure locale, mais ni année ni fuseau. Un collecteur pouvait essayer de compléter l’année selon le calendrier de ses fichiers, sans garantir que ce rattachement soit juste autour d’un changement d’année ou après un retard. L’heure ajoutée par un relais situait surtout l’observation de ce relais.

Standardiser les rôles ne revenait pas à certifier l’origine

Le RFC 5424, publié en 2009, a séparé plus nettement originator, relay, collector, transport sender et transport receiver. Son en-tête inclut VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID et MSGID, puis des données structurées. Il a aussi déplacé la taille vers les contrats de transport : tout récepteur devait accepter 480 octets, devait de préférence en accepter 2 048, et pouvait en accepter davantage.

Lorsqu’un message excédait sa capacité, le récepteur devait de préférence tronquer la charge ou pouvait la rejeter. S’il tronquait, il devait le faire à la fin. Ce choix protège le début, mais il ne rend pas la perte bénigne : l’UTF-8 ou les données structurées peuvent devenir invalides. Le RFC avertit même que la troncature peut servir à dissimuler une information vitale et recommande de placer tôt ce qui compte le plus.

La normalisation apporte donc une hiérarchie de survie, non une complétude garantie. Un transport approprié peut livrer au relais ou au collecteur une copie exacte du message remis par l’application précédente. Il ne prouve pas que cette application était l’origine déclarée ni qu’un relais antérieur n’avait rien retranché.

Le RFC 5425 illustre cette séparation avec syslog sur TLS. Chaque message est cadré par un nombre d’octets, une espace, puis le message. Le récepteur sait où il finit même s’il traverse plusieurs enregistrements TLS. Mais l’identité authentifiée du pair TLS n’est pas nécessairement celle de HOSTNAME. La sécurité est de saut en saut ; le cadrage ne signe pas le passé du contenu.

Sur UDP, le RFC 5426 exige un message par datagramme, lequel peut être complet ou tronqué. Sur TCP, le RFC 6587 documente le comptage d’octets et un ancien cadrage par caractère terminal. Savoir qu’un cadre contient exactement 763 octets dit où s’arrête le cadre. Cela ne dit pas si un relais précédent avait reçu 1 040 octets et en avait conservé 1 024.

Enfin, le registre IANA des paramètres syslog attribue les valeurs de facility, severity, version et identifiants de données structurées. Il permet de lire les nombres. Il ne certifie ni le déploiement, ni l’identité, ni la livraison, ni la conservation d’un suffixe.

Sources