Présentation du protocole Syslog

Date de publication : 28 décembre 2009

Par ram-0000 (http://ram-0000.developpez.com)

Le protocole Syslog est un protocole réseau qui permet de transporter les messages de journalisation générés par les applications vers une machine hébergeant un serveur Syslog. Ce document a pour but de présenter le protocole Syslog.

Votre avis et vos suggestions sur ce tutoriel m'intéressent ! Alors après votre lecture, n'hésitez pas : 20 commentaires

1. Introduction
2. Les notions introduites par Syslog
2.1. Les notions de périphérique, de relais et de collecteur
2.2. Les notions de fonctionnalité, sévérité et priorité
2.2.1. Fonctionnalité
2.2.2. Sévérité
2.2.3. Priorité
3. Une trame de protocole Syslog
3.2. La partie PRI
3.3. La partie HEADER
3.2.1. Le champ TIMESTAMP
3.2.2. Le champ HOSTNAME
3.4. La partie MSG
3.5. Exemples de messages Syslog
4. Les limitations du protocole Syslog
4.1. Limitations UDP
4.2. Nombre de fonctionnalités
4.3. Différence de comportement entre TCP et UDP
4.4. Le champ TIMESTAMP
4.5. Le champ HOSTNAME
4.6. Jeu de caractères de la partie MSG
4.7. La sécurité du protocole
4.8. Le phénomène de boucle
5. Les serveurs Syslog
5.1. Exemple de fichier de configuration syslogd
5.2. Exemple de fichier de configuration syslog-ng
6. Les API Unix programmation Syslog
6.1. API Unix
6.2. Autres API
7. Conclusion

1. Introduction

Le protocole Syslog est un protocole très simple et très largement utilisé dans le monde Unix. Son but est de transporter par le réseau les messages de journalisation générés par une application vers un serveur hébergeant un serveur Syslog. Un autre but est aussi d'assurer la fonction de concentration des journaux, un serveur Syslog intermédiaire pouvant retransférer les messages Syslog qu'il reçoit vers un autre serveur Syslog.

Le but de ce document est de présenter :

Les différents concepts introduits par Syslog.
Le format d'une trame Syslog sur le réseau.
Les limitations du protocole Syslog.
Un petit inventaire des serveurs Syslog (gratuits ou payants) disponibles sur le marché.
Les API de programmation Syslog disponibles.

2. Les notions introduites par Syslog

2.1. Les notions de périphérique, de relais et de collecteur

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.

2.2. Les notions de fonctionnalité, sévérité et priorité

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.

2.2.1. Fonctionnalité

La fonctionnalité d'un message Syslog correspond au type d'application générant le message Syslog. Les 24 fonctionnalités existantes sont définies par la RFC 3164 :

Numéro de fonctionnalité	Usage
0	kernel messages
1	user-level messages
2	mail system
3	system daemons
4	security/authorization messages
5	messages generated internally by syslogd
6	line printer subsystem
7	network news subsystem
8	UUCP subsystem
9	clock daemon
10	security/authorization messages
11	FTP daemon
12	NTP subsystem
13	log audit
14	log alert
15	clock daemon
16	local use 0
17	local use 1
18	local use 2
19	local use 3
20	local use 4
21	local use 5
22	local use 6
23	local use 7

La définition et le contenu de ces fonctionnalités ne sont pas clairement définis par les RFC (il y a plusieurs fonctionnalités ayant trait à l'horloge ou à l'authentification par exemple). Parmi les 24 fonctionnalités différentes, l'usage courant de quelques-unes est indiqué, mais certaines sont maintenant obsolètes (UUCP par exemple).

Globalement, on peut dire que la fonctionnalité correspond au type d'application qui génère le message Syslog.

Quoi qu'il en soit, il faut bien retenir que c'est l'application et elle seule qui décide quelle fonctionnalité elle va utiliser. Le choix du numéro de fonctionnalité est de la responsabilité du projet et du développeur de l'application.

2.2.2. Sévérité

La sévérité d'un message Syslog correspond au degré d'urgence du message. Les 8 sévérités existantes sont définies par les RFC :

Numéro de sévérité	Usage
0	Emergency : system is unusable
1	Alert : action must be taken immediately
2	Critical : critical conditions
3	Error : error conditions
4	Warning : warning conditions
5	Notice : normal but significant condition
6	Informational : informational messages
7	Debug : debug-level messages

Comme on peut le voir, le contenu des messages en fonction de leur sévérité est mieux défini par les RFC.

Globalement, on peut dire que la sévérité d'un message Syslog correspond au degré d'importance ou d'urgence du message Syslog.

Quoi qu'il en soit, il faut bien retenir que c'est toujours l'application et elle seule qui décide quelle sévérité elle va utiliser. Le choix du numéro de sévérité est de la responsabilité du projet et du développeur de l'application.

2.2.3. Priorité

La priorité d'un message Syslog est définie par sa fonctionnalité et sa sévérité. Cette priorité est un nombre qui est le résultat de la multiplication de la fonctionnalité par 8 auquel est ajoutée la sévérité.

Ainsi un message de priorité 165 aura pour fonctionnalité 20 (c'est-à-dire local use 4) et pour sévérité 5 (c'est-à-dire Notice).

Il ne peut y avoir de priorité plus grande que 191 car la fonctionnalité la plus grande définie par les RFC est 23 et la sévérité la plus grande est 7 : (23 * 8) + 7 = 191.

Le mot priorité est certainement mal choisi car un message de priorité importante ne sera pas traité ou acheminé plus rapidement qu'un message de moindre priorité.

3. Une trame de protocole Syslog

Le protocole Syslog est défini par les RFC suivantes:

La RFC 3164.
La RFC 3195.

Le protocole Syslog est un protocole en mode "texte", c'est-à-dire qu'il utilise uniquement les caractères du code ASCII.

Il utilise le protocole UDP et le port 514 mais il faut savoir qu'il existe aussi des implémentations de Syslog en TCP ou même en SSL et sur d'autres numéros de port.

La longueur totale d'une trame Syslog doit être de 1024 octets ou moins. Il n'y a pas de longueur minimale mais une trame de 0 octet n'est pas très utile et ne devrait pas être transmise.

Une trame de protocole Syslog est composée de 3 parties :

La partie PRI.
La partie HEADER.
La partie MSG.

3.2. La partie PRI

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.

3.3. La partie HEADER

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

Le champ TIMESTAMP.
Le champ HOSTNAME.

3.2.1. Le champ TIMESTAMP

Le champ TIMESTAMP doit immédiatement suivre le caractère ">" de la partie HEADER.

Le format de date utilisé par le champ TIMESTAMP est "Mmm dd hh:mm:ss".

"Mmm" est l'abréviation anglaise pour le mois sur 3 caractères. Les seules valeurs admises sont : "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec".
Un caractère espace (" ") doit obligatoirement suivre la valeur du nom du mois.
"dd" représente le numéro de jour dans le mois. Ce numéro de jour doit toujours être représenté par 2 caractères. Si ce numéro de jour est inférieur à 10, il doit alors être précédé du caractère espace (" ").
Un caractère espace (" ") doit obligatoirement suivre la valeur numéro de jour.
"hh:mm:ss" est l'heure locale. L'heure est représentée en utilisant un format sur 24 heures. Les valeurs autorisées vont de "00" à "23". Les valeurs autorisées pour les minutes ("mm") et les secondes ("ss") vont de "00" à "59".

Un caractère espace (" ") doit obligatoirement suivre le champ TIMESTAMP.

3.2.2. Le champ HOSTNAME

Le champ HOSTNAME peut contenir :

Un nom de machine sans son nom de domaine. Un nom de machine ne doit pas contenir de caractère espace (" ").
Une adresse IP au format IPv4 (format décimal pointé 192.168.1.1 par exemple).
Une adresse IP au format IPv6 (voir la RFC RFC 2373 pour les différentes notations supportées).
Rien, le champ HOSTNAME est facultatif.

Un caractère espace (" ") doit obligatoirement suivre le champ HOSTNAME (même si ce champ est vide).

3.4. La partie MSG

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

3.5. Exemples de messages Syslog

Les exemples suivants sont des messages Syslog valides :

Exemple de 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

4. Les limitations du protocole Syslog

Le protocole Syslog est un protocole réseau très simple qui permet à une application de générer des messages au format Syslog à destination d'un serveur Syslog situé sur une autre machine. Il permet aussi à un serveur Syslog de retransférer les messages de log Syslog vers un autre serveur Syslog.

Comme tout protocole simple, celui souffre de limitations et de faiblesses :

Limitations UDP.
Un petit nombre de fonctionnalités disponibles.
La différence de comportement entre TCP et UDP.
Un champ TIMESTAMP incomplet.
Un contenu de champ HOSTNAME "flou".
Le jeu de caractères du message est limité au code ASCII.
Le manque de sécurité du protocole.
Le phénomène de boucle.

Il n'y a aucun critère de tri privilégié dans l'ordre de ces limitations.

4.1. Limitations UDP

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 2 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.

4.2. Nombre de fonctionnalités

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 à 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é.

4.3. Différence de comportement entre TCP et UDP

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. A 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 3 messages Syslog et la différence de comportement (possible, c'est un exemple) entre TCP et UDP :

En UDP, 3 messages sont reçus.
En TCP, seuls 2 messages sont reçus (mais la totalité des 3 messages est reçue). Le début du message 2 se retouve placé à la fin du message 1 et la fin du message 2 se retrouve au début du message 3. Au final, 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.

Envoi	Réception en UDP	Réception en TCP
<165>May 18 14:46:18 192.168.1.1 Message1 <165>May 18 14:46:18 192.168.1.1 Message2 <165>May 18 14:46:18 192.168.1.1 Message3	<165>May 18 14:46:18 192.168.1.1 Message1 <165>May 18 14:46:18 192.168.1.1 Message2 <165>May 18 14:46:18 192.168.1.1 Message3	<165>May 18 14:46:18 192.168.1.1 Message1<165>May 18 14:46:18 192.168.1.1 Message2<165>May 18 14:46:18 192.168.1.1 Message3

Le mécanisme de synchronisation nécessaire en TCP n'a pas été prévu par la RFC (puisque 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).

4.4. Le champ TIMESTAMP

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 2 machines différentes situées sur 2 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 reconstition du problème, des causes et des conséquences.

4.5. Le champ HOSTNAME

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.

4.6. Jeu de caractères de la partie MSG

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, ...).

4.7. La sécurité du protocole

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èce 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énement 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.

4.8. Le phénomène de boucle

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.

5. Les serveurs Syslog

Ce paragraphe a pour but de dresser un inventaire (pas forcément complet) des serveurs Syslog disponibles sur le marché. Le but de ce paragraphe n'est pas de présenter la configuration de ces différents serveurs, pour cela, on se reportera vers la documentation de ces programmes.

Le démon syslogd : ce serveur est installé par défaut ou installable nativement sur la plupart des distributions Unix (Solaris, AIX, Hp-Ux, Linux, ...). La configuration de ce serveur est très simple et les fonctionnalités offertes aussi. C'est le serveur vers lequel il faut se diriger pour commencer à manipuler une architecture Syslog.
Le serveur syslog-ng : devant les limitations du démon syslogd standard, l'éditeur BalaBit IT Security a redéveloppé un nouveau démon syslog appelé syslog-ng (comme New Generation). Ce serveur offre beaucoup de fonctionnalités au niveau de la sécurité et du filtrage. Ce serveur est directement disponible en package sur la plupart des distributions Unix. C'est la version vers laquelle il faudrait se diriger pour installer une véritable architecture Syslog. BalaBit IT Security possède une offre de base gratuite et une offre payante autour syslog-ng.
Le serveur Kiwi Syslog Server est un serveur payant qui fonctionne sous Microsoft Windows.
Syslog Server est un serveur Syslog gratuit (GPL) fonctionnant sous environnement Microsoft.
SyslogServer est une offre payante basée sur Microsoft Windows.
SysRose Syslog Desktop. Il s'agit d'une application bureau et pas d'un service qui peut être utile pour déboguer.
wsyslogd est un service Syslog pour environnement Windows.
3CSyslog est une application bureau capable de recevoir des messages Syslog. Cette application peut être utile pour déboguer.

Il existe probablement beaucoup d'autres solutions gratuites ou payantes, alors n'hésitez pas : 20 commentaires, ce document sera mis à jour.

5.1. Exemple de fichier de configuration syslogd

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).

Un complément d'aide sur la syntaxe et la signification du fichier syslog.conf peut être obtenu en entrant la commande man syslog.conf.
Afin de valider le fonctionnement de la configuration du serveur Syslog, il est possible d'utiliser l'utilitaire logger qui permet de générer des messages Syslog en spécifiant le texte du message, la fonctionnalité et la sévérité.

Fichier de configuration syslogd /etc/syslog.conf

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

22.

23.

24.

25.

26.

27.

28.

29.

30.

31.

32.

33.

34.

35.

36.

37.

38.

39.

40.

41.

42.

43.

44.

45.

46.

47.

48.

49.

50.

51.

52.

53.

54.

55.

56.

57.

58.

59.

60.

61.

62.

63.

64.

65.

66.

67.

68.

69.

70.

71.

72.

73.

74.

75.

76.

77.

78.

#  /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.

5.2. Exemple de fichier de configuration syslog-ng

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.

Un complément d'aide sur la syntaxe et la signification du fichier syslog-ng.conf peut être obtenu en entrant la commande man syslog-ng.conf.
Afin de valider le fonctionnement de la configuration du serveur Syslog, il est possible d'utiliser l'utilitaire logger qui permet de générer des messages Syslog en spécifiant le texte du message, la fonctionnalité et la sévérité.

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.

Fichier de configuration syslog-ng /etc/syslog-ng/syslog-ng.conf

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

22.

23.

24.

25.

26.

27.

28.

29.

30.

31.

32.

33.

34.

35.

36.

37.

38.

39.

40.

41.

42.

43.

44.

45.

46.

47.

48.

49.

50.

51.

52.

53.

54.

55.

56.

57.

58.

59.

60.

61.

62.

63.

64.

65.

66.

67.

68.

69.

70.

71.

72.

73.

74.

75.

76.

77.

78.

79.

80.

81.

82.

83.

84.

85.

86.

87.

88.

89.

90.

91.

92.

93.

94.

95.

96.

97.

98.

99.

100.

101.

102.

# 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);

};

6. Les API Unix programmation Syslog

Ce paragraphe présente les API disponibles pour une application pour lui permettre de générer des messages Syslog.

6.1. API Unix

Une application Unix désirant utiliser la journalisation Syslog devra utiliser les appels systèmes 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.

6.2. Autres API

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

Il existe probablement d'autres solutions gratuites ou payantes, alors n'hésitez pas : 20 commentaires, ce document sera mis à jour.

7. Conclusion

Ce rapide tour d'horizon du protocole Syslog est maintenant terminé. Pour conclure, le protocole Syslog possède bien sûr quelques limitations mais il entre en plein dans la fonctionnalité plus globale qu'est la journalisation. Cette journalisation permet :

De récupérer des traces utiles pour déboguer un problème sur le réseau ou dans une application.
De mettre en œuvre l'archivage légal de certaines informations (connexion des utilisateurs dans une entreprise, utilisation des ressources IT, correspondance IP/utilisateur pour les FAI, ...).
Une corrélation des différents événements de journalisation peut aussi mettre en évidence des scenarios d'intrusion.

Je tiens à remercier Melem, gorgonite et 3DArchi pour leurs conseils avisés lors de la relecture de ce document.

Les sources présentées sur cette page sont libres de droits, et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une oeuvre intellectuelle protégée par les droits d'auteurs. Copyright © 2008-2010 ram-0000. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.

Responsable bénévole de la rubrique Réseau : Djug -

Vos questions techniques : forum d'entraide Réseau - Publiez vos articles, tutoriels et cours
et rejoignez-nous dans l'équipe de rédaction du club d'entraide des développeurs francophones
Nous contacter - Hébergement - Participez - Copyright © 2000-2011 www.developpez.com - Legal informations.