Problématique

Le daemon syslog (syslogd) permet de capturer les messages émis par les différentes application et processus. Par défaut, ces informations sont écrites dans des fichiers ce qui signifie qu'un traitement du fichier pour en extraire des informations ne peut se faire qu'en décalé. Or, il peut être utile de traiter les informations en temps réel.

Solution

syslog autorise l'utilisation de files nommées comme fichier de sortie. Comme son nom l'indique, la file donne en premier ce qui est entré en premier.

Commençons par créer la file :

mkfifo /var/log/syslog.pipe

Ou bien :

mknod -p /var/log/syslog.pipe

Puis, redirigeons la sortie syslog vers la file créée en modifiant /etc/syslog.conf :

*.info                        |/var/log/syslog.pipe

enregistrons les modifications du fichier et redémarrons syslog :

kill -HUP `cat /var/run/syslogd.pid`

A présent, syslog alimente la file. Mais pour l'exploiter, il faut récupérer les données prisonnières de la file. Pour cela, il faudra créer un shell qui tournera en continu et sera lancé dès le démarrage en le plaçant dans rc.d.

Par exemple :

#!/bin/sh
cat /var/log/syslog.pipe | grep -v "UDP Packet" | while read LINE
do
echo $LINE >>/var/log/denied_update.log 
done

cet exemple ne fait que lire la sortie de la file (qui s'utilise comme un fichier) et le rediriger vers un fichier, ce qui, dans ce cas, n'a pas de sens réel (autant diriger la sortie directement dans un fichier). C'est juste pour montrer le mécanisme. Globalement, le script aura cette structure :

#!/bin/sh
cat /var/log/syslog.pipe | grep -v "UDP Packet" | while read LINE
do

      votre traitement

done

A quoi cela peut-il servir ?

cas des fichiers relatifs à la sécurité

Plutôt que de réaliser des analyses de logs (routeurs, pare-feu, snort, ...) avec un décalage, ce qui peut être pénalisant lorsque la sécurité est en jeu (attaque en cours, ...), ce qui oblige aussi à définir une fréquence d'analyse (cron), le traitement en continu permet de donner une réponse en temps réel (au temps d'analyse près). On peut générer une alerte pour l'administrateur sur le champ sans forcément avoir besoin de parcourir manuellement le log, de nombreuses opérations étant automatisables et de nombreuses informations non pertinentes.

intégration des informations dans une base de données

Pour faire des calculs de charge, de fréquentation, des rapports horaires, quotidiens, etc., il est souvent plus simple d'utiliser une base de données pour récupérer les données et les traiter.

En standard, syslog ne permet pas d'alimenter directement une base de données. Il faut souvent effectuer une recompilation.

Grâce à cette méthode, l'on peut écrire directement dans une base de données et lancer régulièrement des requêtes qui vont générer des rapports consultables (XML, HTML, ...).

daemon ou cron ?

L'on peut récupérer les données de la file nommée de deux façons, soit de façon synchrone en faisant tourner un programme (daemon) qui attend les données à traiter. Ce traitement (shell) est lancé au démarrage de la machine.

L'on peut aussi traiter les données de la file nommée en mode asynchrone, grâce à une entrée dans crontab qui va exécuter un shell de façon régulière.

Quelle est la meilleure méthode ?

Si le mode synchrone est quasi-instantané, en cas d'erreur du traitement, les données ne sont plus traitées. cron permet de compenser cette défaillance en relançant le traitement de façon régulière (un cron vérifie régulièrement que le service fonctionne). Mais dans ce cas, l'on perd la synchronisation. Le choix de la méthode doit donc se faire au mieux, en fonction du contexte, ou bien avec un daemon très sécurisé, qui est capable de se relancer automatiquement en cas de plantage (trap, ...). Mais dans ce cas, il ne faut pas oublier de prévoir une commande utilisateur pour l'interrompre manuellement en cas de problème.

Améliorations des performances

Traiter un fichier de log n'est pas focément une chose aisée. Les lignes ne sont pas toutes au même format, avec le même nombre de champs. Le simple fait de découper une ligne, de récupérer chaque champ peut pendre beaucoup de ressources et de temps à la machine, au point qu'elle ne soit capable que de traiter deux ou trois lignes par seconde.

Pour améliorer les performances, il faut au maximum :

C'est plus facile à dire qu'à faire !

La solution la plus simple consistant à repérer le nombre de champs possibles dans un fichier. En général, il n'y a que quelques possibilités. Il ne reste plus ensuite qu'à réaliser une file par type de ligne, de façon à n'avoir qu'une suite de awk et sed. Par exemple, pour un fichier de log possédant 3 types de lignes, il faudra demander à syslog de copier le même log dans 3 files :

*.info                        |/var/log/syslog1.pipe
*.info                        |/var/log/syslog2.pipe
*.info                        |/var/log/syslog3.pipe

chacune traitant un type de ligne.

Le plus simple restant aussi de ne traiter qu'un sous-ensemble des logs générés. Chercher à tout traiter peut être coûteux en temps de développement et en temps d'exécution. Le plus difficile est donc de bien choisir les motifs pertinants.

Ensuite, si de la ligne l'on peut extraire l'adresse IP de l'émetteur, l'on peut aussi ajouter une règle dynamique dans le routeur qui permettra de bloquer l'intrus.

Ce serveur fonctionne à l'énergie renouvelable
© 2008, Christopher Compagnon. Tous droits réservés.