Syslog

1 Pour quoi faire

Syslogd est un daemon qui journalise les événements du système. Il faut avoir le daemon syslogd qui tourne sur votre machine pour que cela marche. Lorsque vous lancez syslog sur votre machine vous démarrez en fait le daemon syslogd et klogd, qui logue plus précisément les messages d'erreur du noyau. Vous avez donc en fait deux daemon qui tournent qur votre machine.
Tous les programmes tournant sur votre machine n'utilisent pas syslog. Par exemple Squid qui place ses logs dans access.log, mais aussi  le serveur apache.   

2 Le principe

Par défaut les fichiers de log se trouvent dans /var/log. Le fichier de configuration de syslog est dans /etc/syslog.conf. Par mesure de sécurité, il est d'usage de mettre le répertoire /var/log dans une partition propre (afin d'éviter qu'une saturation de ce répertoire n'entraîne un arrêt du système tout entier).
Les fichiers de log sont les suivants :
/var/log/messages est le fichier système qui récupère tout. On trouve aussi les messages des programmes qui utilisent syslog, à savoir par exemple named, sendmail.
/var/log/secure Contient les informations de connexions. Chaque login y est enregistré.
/var/log/maillog Contient un enregistrement du trafic de courrier entrant et sortant.
/var/log/spooler Contient les messages d'erreur des daemons uucp et innd (news).

3 L'installation

Par défaut il est installé avec la plupart des distributions, mais au cas ou, peut probable ou il faut l'installer :
sysklogd-.....rpm utilisez la dernière version. Normalement il est lancé au démarrage de la machine.  Si cela n'est pas le cas vous pouvez le lancer avec la commande /etc/rc.d/init.d/syslog start.

4 Configuration

La configuration de syslog se fait dans le fichier /etc/syslog.conf. Pensez après toute modification à faire relire ce fichier de conf (killall -HUP syslogd).
Dans le fichier syslog.conf vous devez donc indiquer sur une ligne : le service, le niveau de gravité et le fichier vers lequel diriger les logs (cela peut être la console).
Les différentes catégories de service sont :

auth ou security	Messages de sécurité et d'authentification.
authpriv	La même chose que précédemment, mais logs plus privés
cron	Messages de crontab et de at
daemon	Messages systémes générés par le daemon
ftp	Messages du serveur ftp
kern	Messages du noyau
lpr	Messages du serveur d'impression
mail	Messages du serveur de messagerie
news	Messages du serveur de news
syslog	Messages de syslog lui-même
user	Messages générés par le programme en cours d'un utilisateur
uucp	Messages UUCP

Puis la liste de sévérité, classée de la  moins grave à la plus grave. Tous les messages de sévérité plus graves sont inclus, ainsi si vous choisissez sévérité err, vous avez aussi les messages crit, alert, et emerg.

7	debug	Messages de debogage
6	info	Messages d'information
5	notice	Messages un peu plus importants que les messages info
4	warning ou warn	Messages d'avertissement
3	err	Messages d'erreur
2	crit	Situation critique
1	alert	Situation critique nécessitant une intervention immédiate
0	emerg ou panic	Système inutilisable

6 Exemple 

# Log tous les messages du noyau vers la console.
# En plus de les envoyer sur la console je les dirige vers le fichier /var/log/kernel

kern.*                                           /dev/console
kern.*                                           /var/log/kernel 

# Log tous les messages dans le fichier messages à partir du niveau info 
# (il ne manque donc que debug par rapport au tableau précédent)
# Sauf les messages du mail, que l'on place dans un autre fichier et les messages authpriv

*.info;mail.none;authpriv.none          /var/log/messages

# Placer ici les messages que seul l'administrateur à le droit de voir. 
# authpriv donne les connexions infructueuses, les connexions avec la commande su.
authpriv.*                                         /var/log/secure

# Log tous les messages de mail et les place dans le fichier maillog..

mail.*                                                /var/log/maillog

# Log tous les messages d'urgence rendant le système instable dans tous les fichiers.

*.emerg                                                 *

# Log les messages uucp et news dans un fichier spécial

uucp,news.crit                                     /var/log/spooler

# Un truc que j'aime bien. Dirige tous les messages vers la console 12. On peut l'adapter.
# Avantage vous n'êtes pas obligé d'ouvrir une session pour avoir les messages à l'écran.
# Attention toutefois à la sécurité et confidentialité de cela.

          *.*                                                    /dev/tty12

7 Remarques divers

- Si vous indiquez un fichier qui n'existe pas, syslog ne sera pas en mesure de le créer. Faites un 
touch /var/log/mon_fichier pour créer le fichier avant.
- N'hésitez pas à utiliser plusieurs fichiers pour bien isoler les messages importants des messages normaux.
- Pensez à utiliser une partition spéciale pour placer vos fichiers de log, afin d'éviter de voir votre système s'arrêter en raison d'une saturation du disque.
- Pensez à vérifier que vos fichiers ne deviennent pas trop volumineux. Faites les tourner (logrotate) réguliérement.
- Rien ne sert de créer des fichiers de log si vous ne les lisez jamais. Il existe des outils pour en extraire les messages importants, voire se faire envoyer les messages importants, à savoir autobuse, logcheck, swatch.

8 Tester votre configuration 

Une fois votre fichier syslog.conf configuré, vous pouvez le tester  en utilisant la commande logger. Logger est un utilitaire fourni avec syslog, qui vous permet d'envoyer des messages directement à syslog.
logger -p ftp.info "Message pour voir".
L'option -p permet d'indiquer le niveau de priorité. Par défaut user.notice
L'option -f permet d'indiquer un fichier.
L'option -t permet d'indiquer un tag logger -t Test "Voici le message"

9 Exporter vos logs sur une autre machine

Il est possible avec syslog d'envoyer ou de concentrer les logs sur une machine distante.
Par exemple si vous souhaitez avertir les personnes connectées via un terminal (root, toto, moi) sur votre serveur linux, sur les messages d'erreur du noyau,  vous pouvez mettre :
kern.crit          root, toto, moi 
L'autre possibilité, et de loin la plus intéressante, est de pouvoir centraliser tous les messages de vos serveurs linux sur une seule machine. En cas d'attaque d'une de vos machines, les logs se trouvant sur une autre machine, cela vous laisse une chance qu'ils soient intacts, et donc de pister l'incident. Pour mettre cela en place il vous faut ajouter dans /etc/rc.d/init.d/syslog l'option -r derrière syslogd afin que celui-ci  sache qu'il faut qu'il écoute sur le port 514 UDP. Sur la machine qui doit envoyer les messages, indiquer dans le fichier /etc/syslog.conf 
kern.crit        @l'autre_machine.

Attention toutefois à ne pas permettre à la terre entière d'envoyer des messages sur cette machine.

TP 1 : Configurer syslog afin d'avoir les messages du noyau envoyés dans le fichier stage.
TP 2 : Ajouter une ligne afin de pouvoir voir les messages d'erreurs, à partir de la gravité "notice", arriver sur la console 12.
TP 3 : Si le serveur Squid tourne sur votre serveur pouvez vous faire apparaître les messages de connexion sur la console 11.     
TP 3 : Choisir la machine stage1 afin de faire arriver l'ensemble des messages sur cette machine. Tester en utilisant la commande logger. 

© Philippe Chadefaux - 10/10/2000 -