Présentation du protocole Syslog

Le protocole Syslog définit la notion de périphérique, de relais et de collecteur dans une architecture Syslog.

• Un périphérique est une machine ou une application qui génère des messages Syslog.
• Un relais est une machine ou une application qui reçoit des messages Syslog et les retransmet à une autre machine.
• Un collecteur est une machine ou une application qui reçoit des messages Syslog, mais qui ne les retransmet pas.

Tout périphérique ou relais sera vu comme un émetteur lorsqu'il envoie un message Syslog et tout relais ou collecteur sera vu comme un récepteur lorsqu'il reçoit un message Syslog.

Le protocole Syslog définit les notions de fonctionnalité, de sévérité et de priorité d'un message Syslog.
La RFC 3164 utilise les mots anglais facility, severity et priority.

II-B-1. Fonctionnalité▲

II-B-2. Sévérité▲

II-B-3. Priorité▲

La partie PRI d'un message Syslog est composée obligatoirement de 3, 4 ou 5 caractères.

Le premier caractère est toujours le caractère « < » suivi par un nombre qui représente la priorité (en base 10) du message et suivi par le caractère « > ».

La seule fois où le caractère « 0 » peut suivre le caractère « < » est pour coder une priorité dont la valeur est 0 justement. Dans tous les autres cas, le ou les caractères « 0 » de tête ne doivent pas être présents.

La partie HEADER d'un message Syslog contient deux champs :

• le champ TIMESTAMP ;
• le champ HOSTNAME.

III-B-1. Le champ TIMESTAMP▲

III-B-2. Le champ HOSTNAME▲

La partie MSG d'un message Syslog comprend le message texte à transférer.

Les exemples suivants sont des messages Syslog valides :

<165>May 18 14:46:18 192.168.1.1 Un message Syslog classique
<14>May  8 14:26:38  Un message Syslog sans champ HOSTNAME, jour de mois plus petit que 10
<0>May  8 04:06:08  Un message Syslog sans champ HOSTNAME, jour de mois, heure, minute et seconde plus petit que 10

Le protocole Syslog repose nativement sur la couche transport UDP. Le protocole UDP est un protocole très simple, mais celui-ci n'offre en contrepartie aucune garantie d'acheminement. Un paquet UDP peut très bien être envoyé par un émetteur et ne jamais être reçu ou traité par le récepteur. De plus, comme il n'y a pas de numérotation des messages Syslog, le récepteur ne saura jamais qu'il en a perdu un, il n'y a pas d'acquittement protocolaire au niveau de Syslog.

Une autre limitation liée à UDP est que le séquencement lors de la réception des messages n'est pas garanti. Un émetteur peut très bien envoyer deux paquets (1 puis 2) et le récepteur peut très bien les recevoir dans l'ordre inverse (2 puis 1). Encore une fois, l'absence de numérotation des trames Syslog empêche de découvrir ce genre de problème. L'inversion dans l'ordre de réception des trames Syslog peut perturber l'analyse des causes et des conséquences lors d'un incident.

Le nombre de fonctionnalités disponibles est limité à 24 valeurs différentes (de 0 à 23). Certaines de ces fonctionnalités ne correspondent plus à rien (UUCP par exemple), d'autres sont en doublon (tout ce qui a trait à l'horloge ou à l'authentification par exemple). Il est bien sûr possible d'utiliser la fonctionnalité 6 (line printer subsystem) pour générer les messages Syslog de son application « maison » ou d'utiliser les fonctionnalités « local use 0 à 7 ».

Une chose est sûre, c'est que sur un collecteur de messages Syslog qui reçoit des messages en provenance d'un grand nombre de machines, il y aura très vite des doublons dans les numéros de fonctionnalités utilisés. L'élément discriminant doit très vite devenir le couple émetteur/fonctionnalité.

UDP est un protocole orienté messages, Syslog est aussi un protocole orienté messages. En UDP (qui est la couche de transport native de Syslog), à un envoi sur le réseau (par l'appel système sendto() par exemple) correspond une et une seule réception réseau (par l'appel système recvfrom() par exemple). Ceci veut dire qu'une trame Syslog sur UDP est envoyée en un seul paquet IP et que ce paquet sera reçu en une seule fois. Il n'y a pas besoin de mécanisme de synchronisation entre l'émetteur et le récepteur.

TCP est un protocole orienté flux. Syslog étant orienté messages, la difficulté va être d'extraire du flux TCP les différents messages Syslog. En TCP, la mécanique mise en place est totalement différente. À un envoi (par l'appel système send() par exemple) peuvent correspondre plusieurs réceptions (par l'appel système recv() par exemple) et à plusieurs envois peut correspondre une seule réception. En TCP, il n'y a aucun lien entre le nombre d'envois et le nombre de réceptions et un mécanisme de synchronisation entre l'émetteur et le récepteur est nécessaire.

Le tableau suivant montre l'exemple de l'envoi de trois messages Syslog et la différence de comportement (possible, c'est un exemple) entre TCP et UDP :

• En UDP, trois messages sont reçus.
• En TCP, seuls deux messages sont reçus (mais la totalité des trois messages est reçue). Le début du message 2 se retrouve placé à la fin du message 1 et la fin du message 2 se retrouve au début du message 3. Finalement, on a reçu 2 messages Syslog et seul le premier est valide, mais le contenu n'est plus correct. Le second message quant à lui est invalide, car son entête Syslog n'est pas correct.

Le mécanisme de synchronisation nécessaire en TCP n'a pas été prévu par la RFC (puisqu’initialement, le protocole de transport de Syslog est UDP). Pour résoudre ce problème en TCP, il est nécessaire de définir un caractère terminal de trame Syslog afin que le récepteur puisse se resynchroniser. Il semble que les caractères couramment admis pour terminer une trame Syslog et, ainsi permettre une resynchronisation, soient les caractères CR, LF, CRLF et NULL.

La RFC 3195 - Reliable Delivery for syslog parle très clairement de la séquence de caractères CRLF (mais dans un contexte légèrement différent puisque le protocole mis en place dans cette RFC est basé sur du XML).

Le champ TIMESTAMP de la trame Syslog n'est pas complet. En effet, l'information « année » ne figure pas dedans. De plus, il n'y a aucune information concernant le fuseau horaire de la machine qui a généré l'information d'horodatage.

Il devient dès lors très compliqué d'analyser les messages Syslog de deux machines différentes situées sur deux fuseaux horaires différents. De plus, pour des fonctions d'archivage ou dans la nuit du 31 décembre au 1er janvier, l'absence de l'information « année » peut poser de gros problèmes.

La résolution du champ TIMESTAMP n'est souvent pas suffisante. Quand il y a un problème sur une machine ou sur un service, cela se traduit parfois par une dizaine de messages Syslog qui sont générés en moins d'une seconde. Une résolution du temps à la milliseconde permettrait d'aider à la reconstitution du problème, des causes et des conséquences.

Le contenu du champ HOSTNAME est variable ce qui va poser des problèmes dans les codes des serveurs Syslog, mais aussi dans l'interprétation du contenu des messages. Pour rappel, le contenu du champ HOSTNAME peut être :

• un nom de machine (sans son nom de domaine) ;
• une adresse IPv4 en notation décimale pointée (192.168.1.1) ;
• une adresse IPv6 (la notation utilisée est celle de la RFC 2373) ;
• vide.

Dans une architecture très hiérarchisée de concentration des messages Syslog, la présence d'un nom de machine sans son nom de domaine ne sert à rien. Un nom local dans une agence en province n'a aucune signification pour un administrateur au siège parisien.

Une adresse IP (v4 ou v6) est peu parlante au niveau fonctionnel même si elle a énormément de valeur pour un administrateur réseau. Par contre, cette information perd toute valeur dès lors qu'une translation d'adresse est mise en place.

Quant à l'absence autorisée de nom de machine, il s'agit d'une aberration.

Le jeu de caractères d'un message Syslog est limité au code ASCII (caractères dont les valeurs sont comprises entre 0 et 127). Ceci peut présenter des problèmes lors de l'envoi des caractères accentués pour les messages générés par Windows par exemple. De plus, même si l'on envoie des caractères accentués, rien n'est prévu pour indiquer le nom du jeu de caractères utilisé (UTF-8, ANSI-1252, OEM…).

Le protocole Syslog est un protocole qui s'appuie nativement sur UDP. Il hérite donc de toutes les faiblesses inhérentes à UDP.

• Il est possible de fabriquer de toutes pièces une trame Syslog et de l'envoyer à un serveur Syslog.
• Il est possible de fabriquer une trame Syslog en falsifiant l'adresse IP de l'émetteur de la trame. Ainsi il sera impossible ou très difficile de retrouver la machine qui a généré la trame.
• Il est possible de « bombarder » un serveur Syslog avec des trames Syslog de manière à noyer des événements réels parmi un grand nombre de messages falsifiés. Ces messages falsifiés peuvent avoir pour but de remplir le disque dur du serveur Syslog (ainsi la fonction archivage sera perdue). Ces messages falsifiés peuvent aussi avoir pour but d'occuper le serveur Syslog de manière à ce que celui-ci n'ait plus le temps de s'occuper des trames réelles (déni de service).

Toutes ces faiblesses disparaissent aussitôt que l'on utilise Syslog sur le protocole TCP.

Comme on a pu le voir dans le paragraphe 2, le protocole Syslog définit la notion de relais. C'est-à-dire qu'un serveur Syslog peut retransférer les messages Syslog reçus vers un autre serveur Syslog. Le piège de cette fonctionnalité est d'introduire une boucle dans la chaîne des relais Syslog. Cette boucle fait que tous les messages Syslog tournent indéfiniment. Ce phénomène met à rude épreuve le réseau ainsi que les serveurs Syslog qui forment cette boucle. Le protocole Syslog ne fournit aucun moyen (autres qu'humains) pour détecter et rompre cette boucle.

Le fichier qui suit est le contenu du fichier de configuration par défaut du serveur Syslog sur une machine Debian 5.0 (noyau en version 2.6.26-2).

#  /etc/syslog.conf    Configuration file for inetutils-syslogd.
#
#            For more information see syslog.conf(5) manpage.
 
#
# First some standard logfiles.  Log by facility.
#
 
auth,authpriv.*             /var/log/auth.log
*.*;auth,authpriv.none     -/var/log/syslog
#cron.*                     /var/log/cron.log
daemon.*                   -/var/log/daemon.log
kern.*                     -/var/log/kern.log
lpr.*                      -/var/log/lpr.log
mail.*                     -/var/log/mail.log
user.*                     -/var/log/user.log
uucp.*                      /var/log/uucp.log
 
#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info                  -/var/log/mail.info
mail.warn                  -/var/log/mail.warn
mail.err                    /var/log/mail.err
 
# Logging for INN news system
#
news.crit                   /var/log/news/news.crit
news.err                    /var/log/news/news.err
news.notice                -/var/log/news/news.notice
 
#
# Some `catch-all' logfiles.
#
*.=debug;                   \
    auth,authpriv.none;     \
    news.none;mail.none    -/var/log/debug
 
*.=info;*.=notice;*.=warn;  \
    auth,authpriv.none;     \
    cron,daemon.none;       \
    mail,news.none         -/var/log/messages
 
#
# Emergencies are sent to everybody logged in.
#
*.emerg                     *
 
#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
#daemon,mail.*;             \
#   news.=crit;             \
#   news.=err;              \
#   news.=notice;           \
#   *.=debug;*.=info;       \
#   *.=notice;*.=warn       /dev/tty8
 
# The named pipe /dev/xconsole is for the `xconsole' utility.  To use it,
# you must invoke `xconsole' with the `-file' option:
#
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
#      busy site..
#
daemon.*;                   \
    mail.*;                 \
    news.crit;              \
    news.err;               \
    news.notice;            \
    *.=debug;               \
    *.=info;                \
    *.=notice;              \
    *.=warn                 |/dev/xconsole

Les explications concernant la signification de ce fichier de configuration sont les suivantes.

• La ligne 10 signifie que tous les messages dont la fonctionnalité est auth ou authpriv, quelle que soit leur sévérité, sont archivés dans le fichier /var/log/auth.log.
• La ligne 11 signifie que tous les messages, quelle que soit leur sévérité, à l'exception de ceux dont la fonctionnalité est auth ou authpriv sont archivés dans le fichier -/var/log/syslog. Ce fichier n'est pas resynchronisé après écriture pour des raisons de performance (présence du caractère « - » avant le nom du fichier)..
• La ligne 12 (en commentaire) signifie que tous les messages dont la fonctionnalité est cron sont archivés dans le fichier /var/log/cron.log.
• La ligne 13 signifie que tous les messages dont la fonctionnalité est daemon sont archivés dans le fichier /var/log/daemon.log.
• La ligne 14 signifie que tous les messages dont la fonctionnalité est kern sont archivés dans le fichier /var/log/kern.log.
• La ligne 15 signifie que tous les messages dont la fonctionnalité est lpr sont archivés dans le fichier /var/log/lpr.log.
• La ligne 16 signifie que tous les messages dont la fonctionnalité est mail sont archivés dans le fichier /var/log/mail.log.
• La ligne 17 signifie que tous les messages dont la fonctionnalité est user sont archivés dans le fichier /var/log/user.log.
• La ligne 18 signifie que tous les messages dont la fonctionnalité est uucp sont archivés dans le fichier /var/log/uucp.log.
• La ligne 24 signifie que tous les messages dont la fonctionnalité est mail et dont la sévérité est inférieure ou égale à info sont archivés dans le fichier /var/log/mail.info.
• La ligne 25 signifie que tous les messages dont la fonctionnalité est mail et dont la sévérité est inférieure ou égale à warn sont archivés dans le fichier /var/log/mail.warn.
• La ligne 26 signifie que tous les messages dont la fonctionnalité est mail et dont la sévérité est inférieure ou égale à err sont archivés dans le fichier /var/log/mail.err.
• La ligne 30 signifie que tous les messages dont la fonctionnalité est news et dont la sévérité est inférieure ou égale à crit sont archivés dans le fichier /var/log/news.crit.
• La ligne 31 signifie que tous les messages dont la fonctionnalité est news et dont la sévérité est inférieure ou égale à err sont archivés dans le fichier /var/log/news.err.
• La ligne 32 signifie que tous les messages dont la fonctionnalité est news et dont la sévérité est inférieure ou égale à notice sont archivés dans le fichier /var/log/news.notice.
• Les lignes 37 à 39 signifient que tous les messages dont la sévérité est debug (présence du signe « = ») à l'exception des messages dont la fonctionnalité est auth, authpriv, news et mail sont archivés dans le fichier -/var/log/debug.
• Les lignes 41 à 44 signifient que tous les messages dont la sévérité est info, notice ou warn à l'exception des messages dont la fonctionnalité est auth, authpriv, cron, daemon, news ou mail sont archivés dans le fichier -/var/log/messages.
• La ligne 49 signifie que tous les messages dont la sévérité est emerg sont écrits dans tous les terminaux de tous les utilisateurs connectés.
• Les lignes 55 à 60 (en commentaire) signifient que tous les messages dont la fonctionnalité est daemon ou mail quelle que soit leur sévérité, les messages de fonctionnalité news et dont la sévérité est crit, err ou notice ainsi que tous les messages dont la sévérité est debug, info, notice ou warn sont écrits dans le terminal /dev/tty8.
• Les lignes 70 à 78 signifient que les messages daemon.*, mail.*, news.crit et inférieur, news.err et inférieur, news.notice et inférieur, *.=debug, *.=info, *.=notice et *.=warn sont envoyés dans le pipe nommé /dev/xconsole.

La documentation autour de syslog-ng est nombreuse et de bonne qualité. On peut trouver, entre autres, sur le site de l'éditeur le document The syslog-ng Administrator Guide. Ce document est la référence pour tout ce qui concerne la configuration et l'administration de syslog-ng.

Le fichier qui suit est le contenu d'un fichier de configuration pour syslog-ng que j'installe par défaut lorsque j'utilise syslog-ng. Il permet de recevoir toutes les sources de messages Syslog (kernel, TCP, UDP, interne). Les messages Syslog sont ensuite archivés dans les fichiers /var/log/syslog/$YEAR/$MONTH/$DAY/$FACILITY.log et /var/log/syslog/$SOURCEIP/$YEAR/$MONTH/$DAY/$FACILITY.log. Les macros $SOURCEIP, $YEAR, $MONTH, $DAY, $FACILITY (ainsi que beaucoup d'autres) sont gérées par syslog-ng. Ce fichier de configuration est ensuite adapté en fonction des besoins sur site.

#
# Configuration file for syslog-ng under Debian
#
 
######
# options
options
{
    # option to create directories if needed
    # new directories are crated if needed
    # new directories belong to user root(0) and group root(0)
    # new directories are created with the rights rwx------ (0700)
    create_dirs(yes);
    dir_group(root);
    dir_owner(root);
    dir_perm(0700);
 
    # option to create files if needed
    # new files are crated if needed
    # new files belong to user root(0) and group root(0)
    # new files are created with the rights rw------- (0600)
    group(root);
    owner(root);
    perm(0600);
 
    # disable the chained hostname format in logs
    # no DNS use (too much time consuming)
    # use short name and not FQDN
    chain_hostnames(0);
    use_dns(no);
    use_fqdn(no);
    keep_hostname(no);
    check_hostname(no);
 
    # the time to wait before a died connection is re-established
    # the time to wait before an idle destination file is closed
    time_reopen(10);
    time_reap(360);
    time_sleep(0);
 
    # the number of lines buffered before sent and written to file
    sync(0);
    flush_lines(0);
 
    # the number of lines fitting in the output queue
    # and maximum length of message in bytes
    log_fifo_size(100);
    log_msg_size(8192);
 
    # send a mark msyslog message every 20 minutes
    mark_freq(1200);
    stats_freq(1200);
};
 
 
######
# sources
source s_all
{
    # message generated by Syslog-NG
    internal();
 
    # standard Linux log source
    unix-stream("/dev/log");
 
    # messages from the kernel
    file("/proc/kmsg" log_prefix("kernel: "));
 
    # UDP messages from network
    udp(localip(0.0.0.0), localport(514));
 
    # TCP messages from network
    tcp(localip(0.0.0.0), localport(514));
};
 
 
######
# destinations
destination d_one_facility_per_file
{
    file("/var/log/syslog/$YEAR/$MONTH/$DAY/$FACILITY.log");
};
 
destination d_one_folder_per_ip_and_one_facility_per_file
{
    file("/var/log/syslog/$SOURCEIP/$YEAR/$MONTH/$DAY/$FACILITY.log");
};
 
######
# logs
log
{
    source(s_all);
    destination(d_one_facility_per_file);
};
 
log
{
    source(s_all);
    destination(d_one_folder_per_ip_and_one_facility_per_file);
};

Une application Unix désirant utiliser la journalisation Syslog devra utiliser les appels système suivant :

• openlog() permet d'ouvrir une connexion Syslog ;
• syslog() ou vsyslog() permettent de générer un message Syslog ;
• closelog() permet de fermer la connexion syslog.

• La bibliothèque WinLog permet de générer des messages de traces qui peuvent être transmis sur le réseau à serveur Syslog.