THEME : SYSLOG

TABLE DES MATIERES

INTRODUCTION..........................................................................................................................2
I. PRESENTATION GENERALE ..........................................................................................3
1. Historique ..........................................................................................................................3
2. Présentation ......................................................................................................................3
II. PRINCIPE DE FONCTIONNEMENT ..........................................................................4
1. Le sous –système (facility) ...........................................................................................4
2. Le niveau (level) ...............................................................................................................5
3. L’action à réaliser ............................................................................................................5
III. VARIABLE DU MODELE ...............................................................................................5
1. Syntaxe de sélecteur .......................................................................................................5
2. Syntaxe des actions .........................................................................................................6
IV. SECURITE ..........................................................................................................................7
V. FONCTIONNEMENT PRATIQUE ................................................................................8
VI. LES IMPLEMENTATIONS EXISTANTES DU PROTOCOLES .......................... 10
1. Syslog-ng...........................................................................................................................10
2. Rsyslog ..............................................................................................................................11
VII. AVANTAGES ET INCONVENIENTS ......................................................................... 12
1. Avantages .........................................................................................................................12
2. Inconvénients .................................................................................................................12
CONCLUSION .............................................................................................................................14

1
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

INTRODUCTION

La journalisation qui est un enregistrement dans un journal des opérations

informatiques effectuées dans un système. Elle est une part extrêmement importante
de la sécurité et c’est un des seuls outils à notre disposition pour la surveillance du
système. Elle est un complément à la protection et c’est un des piliers de la détection
d’intrusion. C’est le principal outil dont dispose l’administrateur. Il faut toutefois
trouver le bon compromis, car la journalisation utilise des ressources CPU et disque.
Une journalisation importante est parfois nécessaire lors de l’implantation d’un
nouveau service, mais il faut bien vérifier qu’elle est nécessaire par la suite. On notera
également que la journalisation des événements sert également à des fins de
statistiques ou de facturation. Sur les systèmes UNIX/Linux il existe un démon
principal gérant la journalisation d’événement. C’est le démon Syslogd communément
appelé Syslog)... Ce démon reçoit des messages événementiels de la part de clients
(locaux ou distants) Syslog ou du démon Klogd qui est chargé d’écouter les messages
du noyau et de les envoyer au démon Syslogd pour que celui-ci les journalise suivant
son fichier de configuration. Dans les lignes qui suivent, nous ferons une présentation
générale de syslog, puis nous donneront son principe de fonctionnement, nous
donnerons un aperçu de son installation et de sa configuration, et enfin nous
présenterons ses avantages et ses inconvénients.

2
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

I. PRESENTATION GENERALE

1. Historique
Syslog a été développé dans les années 1980 par Eric Allman dans le cadre du
projet Sendmail5, et n'était initialement prévue que pour Sendmail. Il s'est avéré si
utile que d'autres applications ont commencé à l'utiliser. Syslog est depuis devenu la
solution de journalisation standard sur les systèmes Unix et Linux6, il y a également
une variété d'implémentations syslog sur d'autres systèmes d'exploitation (Windows
notamment) et est généralement trouvé dans les périphériques réseau tels que les
commutateurs ou routeurs.

2. Présentation
En tant que protocole, Syslog se compose d'une partie cliente et d'une partie
serveur. La partie cliente émet les informations sur le réseau, via le port UDP 514. Les
serveurs collectent l'information et se chargent de créer les journaux. Il utilise un
socket afin de transmettre ses messages.

L'intérêt de Syslog est donc de centraliser les journaux d'événements,

permettant de repérer plus rapidement et efficacement les défaillances d'ordinateurs
présents sur un réseau.

Il existe aussi un logiciel appelé Syslog, qui est responsable de la prise en charge des
fichiers de journalisation du système. Ceci inclut un démon klogd, responsable des
messages émis par le noyau Linux.

Un journal au format Syslog comporte dans l'ordre les informations suivantes :

la date à laquelle a été émis le log, le nom de l'équipement ayant généré le log
(hostname), une information sur le processus qui a déclenché cette émission, le niveau
de priorité du log, un identifiant du processus ayant généré le log et enfin un corps de
message.

Exemple : Sep 09 14:09:09 machine_de_test dhcp service [warning] 110 corps du message

Certaines de ces informations sont optionnelles.

3
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

II. PRINCIPE DE FONCTIONNEMENT

Afin de simplifier la programmation de la journalisation et de laisser un meilleur

contrôle à l’administrateur, de nombreux démons ne font pas la journalisation eux-
mêmes mais effectuent des appels système au démon syslog (openlog (), syslog (),
closelog()).

Les évènements qu’un programme envoie au démon syslog sont identifiés par 3
éléments :

Le sous-système (facility)
Le niveau (level)
L’action à réaliser

1. Le sous –système (facility)

Chaque message de log est associé à un sous-système applicatif .Le sous-système
permet d’identifier quelle partie du système d’exploitation envoie le message. Les
valeurs possibles sont :

Auth : concerne l’authentification

authpriv : concernent les messages privées d'authentification ;
cron : provient des services de planification de tâches, cron et atd ;
daemon : concerne un démon sans classification particulière (serveur DNS,
NTP, etc.) ;
ftp : concerne le serveur FTP ;
kern : message provenant du noyau ;
lpr : provient du sous-système d'impression ;
mail : provient de la messagerie électronique ;
news : message du sous-système Usenet (notamment du serveur NNTP —
Network News Transfer Protocol, ou protocole de transfert des nouvelles sur le
réseau — gérant les forums de discussion) ;
syslog : message du serveur syslogd lui-même ;
user : messages utilisateur (générique) ;
uucp : messages du sous-système UUCP (Unix to Unix Copy Program, ou
programme de copie d'Unix à Unix, un vieux protocole employé pour faire
circuler entre autres des messages électroniques) ;
local0 à local7 : réservés pour les utilisations locales.
4
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

2. Le niveau (level)
À chaque message est également associé un niveau de priorité. En voici la liste par
ordre décroissant :

emerg : « Au secours ! » le système est probablement inutilisable ;

alert : vite, il y a péril en la demeure, des actions doivent être entreprises
immédiatement ;
crit : les conditions sont critiques ;
err : erreur ;
warn : avertissement (erreur potentielle) ;
notice : condition normale mais message significatif ;
info : message informatif ;
debug : message de débogage.

3. L’action à réaliser

Après avoir défini une facilité et ses niveaux, il faut y ajouter une action :

Fichier : Ecrire les traces dans fichier (par exemple /var/log/messages)

Machine : Rediriger les traces du vers la machine (nom ou adresse IP)
User : Envoyer les messages vers l'écran de l'utilisateur s’il est connecté
* : Envoyer les messages vers tous les utilisateurs connectés

III. VARIABLE DU MODELE

La syntaxe complexe du fichier /etc/rsyslog.conf est détaillée dans la page de manuel
rsyslog.conf(5) mais aussi dans la documentation HTML disponible dans le paquet
rsyslog-doc (/usr/share/doc/rsyslog-doc/html/index.html). Le principe global est
d'écrire des paires « sélecteur » et « action ». Le sélecteur définit l'ensemble des
messages concernés et l'action décrit comment le traiter.

1. Syntaxe de sélecteur
Le sélecteur est une liste (ayant pour séparateur le point-virgule) de couples sous-
système.priorité (exemple : auth.notice;mail.info). L'astérisque peut y représenter
tous les sous-systèmes ou toutes les priorités (exemples : *.alert ou mail.*). On peut
regrouper plusieurs sous-systèmes en les séparant par une virgule (exemple :

5
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

auth,mail.info). La priorité indiquée recouvre aussi les messages de priorité supérieure

ou égale : auth.alert désigne donc les messages du sous-système auth de priorités alert
ou emerg. Préfixée par un point d'exclamation, elle désignera au contraire les priorités
strictement inférieures : auth.!notice désignera donc les messages issus de auth et de
priorité info ou debug. Préfixée par un signe égal, elle correspondra exactement à la
seule priorité indiquée (auth.=notice ne concernera donc que les messages de auth de
priorité notice).

Au sein du sélecteur, chaque élément de la liste surcharge les éléments précédents. Il

est donc possible de restreindre un ensemble ou d'en exclure certains éléments. À titre
d'exemple, kern.info;kern.!err définit les messages du noyau de priorité comprise entre
info et warn. La priorité none désigne l'ensemble vide (aucune des priorités) et peut
servir pour exclure un sous-système d'un ensemble de messages. Ainsi,
*.crit;kern.none désigne tous les messages de priorité supérieure ou égale à crit ne
provenant pas du noyau.

2. Syntaxe des actions

Un tube nommé est un type particulier de fichier fonctionnant comme un tube
traditionnel (le pipe que l'on crée à l'aide du symbole « | » sur la ligne de commande),
mais par l'intermédiaire d'un fichier. Ce mécanisme a l'avantage de pouvoir mettre en
relation deux processus n'ayant aucun rapport de parenté. Toute écriture dans un tube
nommé bloque le processus qui écrit jusqu'à ce qu'un autre processus tente d'y lire des
données. Ce dernier lira alors les données écrites par l'autre partie, qui pourra donc
reprendre son exécution.

Un tel fichier se crée avec la commande mkfifo.

Les différentes actions possibles sont :

ajouter le message à un fichier (exemple : /var/log/messages) ;

envoyer le message à un serveur syslog distant (exemple : @log.falcot.com) ;

envoyer le message dans un tube nommé préexistant (exemple :

|/dev/xconsole) ;

envoyer le message à un ou plusieurs utilisateurs s'ils sont connectés (exemple :

root,rhertzog) ;

envoyer le message à tous les utilisateurs connectés (exemple : *) ;

6
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

écrire le message sur une console texte (exemple : /dev/tty8).

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

La première des règles de sécurité est d’avoir les démons mis à jour pour
corriger d’éventuels bugs. En effet, si un démon plante, on a un défaut de
disponibilité de service (la disponibilité étant un des piliers de la sécurité). De
la même manière, les programmes étant conçu par des humains ne sont pas
exempt de failles qu’un individu maicieux pourra exploiter (nous en donnerons
une liste non exhaustive dans la suite de cette documentation). Ainsi pour
réaliser la mise a jour d’un démon, on peut utiliser la commande :

Apt-get install sysklogd

Si le paquet est la dernière version disponible, le résultat de la commande le notifiera

sinon le paquet sera mis a jour. Pour connaitre la version d’un paquet on peut taper la
commande : aptitude show sysklogd. On peut ensuite comparer la version de son
paquet avec ce qui se trouve sur internet par exemple.

Il y une possibilité que le démon syslogd soit utilisé comme passage pour une
attaque de déni de service. Un programme(ur) malicieux pourrait très
simplement noyer le démon syslogd avec des messages, ce qui conduirait les
journaux à remplir toute la place restante du système de fichiers. Activer la
journalisation à travers la socket de domaine internet exposera le système à des
risques extérieurs vis-à-vis des programmes ou des utilisateurs de la machine
locale.
C'est une bonne idée que d'enregistrer les logs les plus importants sur une
machine séparée (voire dédiée), car cela empêchera un éventuel intrus de
supprimer les traces de son passage (sauf à compromettre également cet autre
serveur). Par ailleurs, en cas de problème majeur (tel qu'un plantage du noyau),
disposer de logs sur une autre machine augmente les chances de retrouver le
déroulement des événements.
Pour accepter les messages de log envoyés par d'autres machines, il faut reconfigurer
rsyslog : dans la pratique il suffit d'activer des directives prêtes à l'emploi qui sont déjà
présentes dans /etc/rsyslog.conf ($ModLoad imudp et $UDPServerRun 514).

7
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

V. FONCTIONNEMENT PRATIQUE

Installation

Syslog-ng est disponible dans les dépôts :

apt-get install syslog-ng

Syslog-ng en tant que client

Le fichier de configuration de Syslog-ng se trouve dans /etc/syslog-ng/syslog-

ng.conf et il sera le seul fichier que nous toucherons. Syslog-ng doit envoyer ses
logs à un serveur. Il va falloir choisir ce que nous voulons envoyer et à qui. Par
exemple, si nous voulons tout envoyer au serveur
destination d_serveur {
tcp("10.0.2.15");
udp("10.0.2.15");
};
log { source(s_src); destination(d_serveur); };
Ici, l’adresse IP du serveur est 10.0.2.15. Nous avons créé une destination qui se
nomme d_serveur et qui envoie tous ses logs au serveur en TCP et UDP. Nous
pouvons donc choisir d’envoyer les logs à une adresse IP ou à un nom de machine
(hostname), mais aussi de choisir entre TCP et UDP. Puis la fonction log envoie
les logs de la machine avec la fonction source (source(s_src);) à la destination
spécifiée (destination(d_serveur);). Nous pouvons aussi choisir le port de
destination, il suffit de le préciser dans les parenthèses de TCP ou UDP :
udp(ip(192.168.0.20) port(1000));
La source s_src correspond aux logs de la machine cliente. C’est une ligne qui est
présente par défaut :
source s_src {
system();
internal();
};

8
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

Si vous ne voulez pas envoyer tous les logs au serveur, il faudra utiliser la
fonction filter (filtre). Grâce aux sources et au filtre présent dans Syslog-ng, nous
choisissons les logs que nous voulons envoyer au serveur. Il y a des filtres qui
existent déjà dans le fichier par défaut de syslog-ng en dessous de la bannière
Filters. Il faut ajouter dans la fonction log un filtre. Par exemple, si nous voulons
filtrer par facility, il existe des filtres par défaut. Dans ce cas, la facility est error
:
log { source(s_src); destination(d_serveur); filter(f_err); };
Il est possible d’utiliser plusieurs filtres, par exemple, seulement les messages du
kernel avec la facility critique :
log { source(s_src); destination(d_serveur); filter(f_crit); filter(f_kern); };

Syslog-ng en tant que serveur

Toujours dans le même fichier de configuration, mais sur le serveur, nous

allons créer une nouvelle source (s_all) sur le serveur afin de récupérer les logs
du client.
source s_all {
tcp();
udp();
};
Cette configuration peut être dangereuse si votre serveur est accessible via une
adresse IP publique. Il sera donc plus pertinent, afin de sécuriser le service, de
spécifier l’adresse IP du client à écouter :
source s_all {
tcp( network(ip(10.0.2.15));
udp( network(ip(10.0.2.15));
};
Si nous avons précisé un port spécifique dans la configuration du client, il faudra
aussi le mettre dans la configuration du serveur :
udp(network(ip(10.0.2.15) port(514));
Il nous faut aussi une destination. Cette destination sera l’emplacement des logs
:
destination d_local {
file("/var/log/host/$HOST.log" create_dirs(yes)};

9
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

Cette destination enregistrera les logs dans /var/log/host/. Chaque machine

aura son fichier de logs qui aura pour nom son adresse IP ou hostname. Le
paramètre « create_dirs(yes) » autorise Syslog-ng à créer des dossiers, par
défaut cette option est bloquée. Nous pouvons customiser ce chemin afin de
ranger ses logs plus proprement. Par exemple :
/var/log/host/$HOST/$FACILITY/$FACILITY.${YEAR}.${MONTH}.log
Nous aurons un dossier par machine qui lui aura un dossier par facility. Chaque
fichier de logs comportera les logs de sa facility et il y aura un fichier de log par
mois. Nous pouvons faire en sorte qu’il y est un fichier de logs par jour en
ajoutant « .${DAY} », ce qui donne :

VI. LES IMPLEMENTATIONS EXISTANTES DU PROTOCOLES

1. Syslog-ng
Le projet syslog-ng a débuté en 1998. syslog-ng est une implémentation open-
source du protocole syslog pour les systèmes Unix et Unix . Il étend le modèle syslogd
d'origine avec un filtrage basé sur le contenu, des fonctionnalités de filtrage riches, des
options de configuration flexibles et ajoute des fonctionnalités importantes à syslog,
comme l'utilisation de TCP pour le transport. À partir d'aujourd'hui, syslog-ng est
développé parBalabit IT Security Ltd. Il a deux éditions avec une base de code
commune. Le premier s'appelle syslog-ng Open Source Edition (OSE) avec la licence
LGPL. Le deuxième s'appelle Premium Edition (PE) et possède des plugins
supplémentaires (modules) sous licence exclusive . syslog-ng fournit un certain
nombre de fonctionnalités en plus de transporter les messages syslog et de les stocker
dans des fichiers journaux texte brut:

La capacité de formater des messages de journalisation à l'aide d'une extension

de variables Unix (peut interrompre la compatibilité du format de connexion
entre plates-formes)

L'utilisation de cette extension de variable en forme de shell lors de la

nomination de fichiers, couvrant plusieurs fichiers de destination avec une seule
instruction

Possibilité d'envoyer des messages de journal vers des applications locales

10
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

Prise en charge du contrôle des flux de messages dans le transport réseau

Connexion directement à une base de données (depuis syslog-ng OSE 2.1)

Réécris des portions du message syslog avec des primitives définies et de

remplacement (depuis syslog-ng OSE 3.0)

Classer les messages de journal entrants et, en même temps, extraire des
informations structurées à partir du message syslog non structuré (depuis
syslog-ng OSE 3.0)

Prise en charge générique de la valeur nominale: chaque message est juste un

ensemble de paires nom-valeur, qui peut être utilisé pour stocker des
informations supplémentaires (depuis syslog-ng OSE 3.0)

La capacité de traiter des formats de messages structurés transmis sur syslog,

comme extraire des colonnes à partir de lignes formatées CSV (depuis syslog-ng
OSE 3.0)

La capacité de corréler plusieurs messages entrants pour former un événement

plus complexe et corrélé (depuis syslog-ng OSE 3.2); [5]

2. Rsyslog
Rsyslog est un logiciel libre utilisé sur des systèmes d'exploitation de type
Unix (Unix, Linux) transférant les messages des journaux d'événements sur un
réseau IP. Rsyslog implémente le protocole basique syslog - qui centralise les journaux
d'événements, permettant de repérer plus rapidement et efficacement les défaillances
d'ordinateurs présents sur un réseau. Il présente la particularité d'en étendre les
fonctionnalités en permettant, notamment, de filtrer sur des champs, de filtrer à l'aide
d'expressions régulières et l'utilisation du protocole TCP de la couche transport.

11
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

VII. AVANTAGES ET INCONVENIENTS

1. Avantages
Comme avantage de syslog nous pouvons citer :
centralisation de la répartition des informations dans les differents fichiers de
logs dans un seul fichier de configuration,
sécurité: seul l'utilisateur sous lequel tourne le daemon syslog à besoin d'avoir
accès en écriture au fichier de log, ainsi en cas de faille ou de compromission du
service, ce dernier ne sera pas dans la possibilité d'effacer ses propres logs,
l'on peut configurer syslog pour retransmettre directement les logs à une autre
machine sur le réseau, utile pour garder des traces en cas de compromission de
la machine,
grosse simplification de la gestion des droits sur les fichiers de logs ;
2. Inconvénients

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

Limitations 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).
Un petit nombre de fonctionnalités disponibles : 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".
La différence de comportement entre TCP et UDP : une trame Syslog sur
UDP est envoyée en un seul paquet IP et que ce paquet sera reçu en une seule

12
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

fois. Il n'y a pas besoin de mécanisme de synchronisation entre l'émetteur et le

récepteur. Par contre, 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.
Un champ TIMESTAMP incomplet : 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.
Un contenu de champ HOSTNAME "flou" : 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, une
adresse IPv4 , une adresse IPv6 , le vide.
Le jeu de caractères du message est limité au code ASCII : 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.
Le manque de 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è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. Toutes ces
faiblesses disparaissent aussitôt que l'on utilise Syslog sur le protocole TCP
Le phénomène de boucle : 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.

13
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA
 THEME : SYSLOG

CONCLUSION

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.

14
Rédigé et présenté par : NGUENG, SARA, MBANE, YOMBA