Serveur Syslog

Principe et fonctionnement

Le démon rsyslogd a pour charge de collecter les messages de service provenant des applications et
du noyau puis de les répartir dans des fichiers de logs (habituellement stockés dans le répertoire
/var/log/). Il obéit au fichier de configuration /etc/rsyslog.conf.

Chaque message de log est associé à un sous-système applicatif (nommé facility dans la
documentation) :
 auth et authpriv : concernent l'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.

Valeur Facility Description

1 user user-level messages
2 mail mail system
3 deamon system daemons
4 auth security/authorization messages
5 syslog messages generated internally by syslogd
6 lpr line printer subsystem
7 news network news subsystem
8 uucp UUCP subsystem
9 cron clock daemon
10 authpriv security/authorization messages
11 ftp FTP daemon
12 ntp NTP subsystem
13 security log audit
14 console log alert
15 solaris-cron clock daemon
16 - 23 local0 - local7 locally used facilities (local0-local7)

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

Valeur Priority
0 Emergency
1 Alert
2 Critical
3 Error
4 Warning
5 Notice
6 Informational
7 Debug

Le fichier de configuration

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.

Syntaxe du 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 : 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.

Syntaxe des actions

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 : *) ;
 écrire le message sur une console texte (exemple : /dev/tty8).

Format Syslog

Les logs sont sauvegardés dans des fichiers textes au format syslog. Il comporte trois parties :
 Un timestamp qui est la date et heure du log. Il est au format "Mmm dd hh:mm:ss". « Mmm »
correspond aux trois premières lettres du mois, « dd » au numéro du jour du mois, puis l’heure qui
est constituée des heures (hh), minutes (mm) et secondes (ss) sur 24 heures.
 Un identifiant de la machine qui a généré le log. Cela peut être le nom de la machine (son
hostname) ou son adresse IPv4 ou IPv6.
 Le message, qui est un message texte comportant des informations.

Exemples :

Sep 26 19:42:20 10.0.0.146 sshd[438]: Server listening on 0.0.0.0 port 22.

Sep 26 19:42:20 10.0.0.146 sshd[438]: Server listening on :: port 22.

Configuration

Rsyslog est disponible dans les dépôts :

#yum install rsyslog
Ou
#rpm -ivh rsyslog………….rpm

Syslog en tant que client

Le fichier de configuration de Rsyslog se trouve dans /etc/rsyslog.conf. C’est le seul fichier que nous
allons éditer pour Rsyslog. Nous devons configurer Rsyslog en tant que client, il doit donc envoyer ses
logs à un serveur.
Nous pouvons tout simplement le configurer pour qu’il envoie tout en UDP et TCP :
#UDP
*.* @10.0.0.147
#TCP
*.* @@10.0.0.147
« *.* » Cette configuration signifie que nous envoyons tous les logs. C’est là qu’interviennent les
facilities et severity. La première étoile correspond à toutes les facilities et la deuxième à toutes les
severities, nous avons donc « facility.priority ». Ce paramètre nous permet de spécifier et de filtrer
les logs en amont que nous voulons envoyer.

Le « @ » correspond à UDP et le « @@ » à TCP. Il est préférable de se coordonner à la configuration

de son serveur pour n’envoyer qu’en UDP ou TCP. On écrira donc qu’une des deux lignes.
L’adresse IP « 10.0.0.147 » est celle du serveur.
Pour choisir les logs à envoyer. Exemple, pour envoyer seulement les logs du kernel, il faut se référer
au tableau, cela donne :
kern.* @10.0.0.147
Pour n’envoyer que les logs mail avec la priority alert :
mail.alert @10.0.0.147
Rsyslog en tant que serveur

La configuration du serveur ce fait dans le même fichier de configuration (/etc/rsyslog.conf ). Il

faudra décommettre certaines lignes pour que le serveur accepte les logs des clients.

$ModLoad imuxsock # provides support for local system logging

$ModLoad imklog # provides kernel logging support
#$ModLoad immark # provides --MARK-- message capability

# provides UDP syslog reception

#$ModLoad imudp
#$UDPServerRun 514

# provides TCP syslog reception

#$ModLoad imtcp
#$InputTCPServerRun 514
Nous pouvons voir qu’il est possible d’accepter les logs en UDP ou TCP, ce qui nous donne donc :
Pour accepter les logs en UDP:

# provides UDP syslog reception

$ModLoad imudp
$UDPServerRun 514
Pour accepter les logs en TCP :
# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

Vérification

Démarrer le serveur Rsyslog

#systemctl restart rsyslog.service
Dans le serveur
# tail -f /var/log/messages