RSyslog et Picviz : supervision de logs à grande échelle

GNU/Linux Magazine HS n° 042 | juin 2009 | Sebastien Tricaud
Creative Commons
  • Actuellement 0 sur 5 étoiles
0
Merci d'avoir participé !
Vous avez déjà noté cette page, vous ne pouvez la noter qu'une fois !
Votre note a été changée, merci de votre participation !
Dans le cas où vous possédez une plateforme à superviser, pour peu que vous ayez une dizaine de machines, il n'est pas évident de détecter sur une machine donnée les problèmes que vous avez ou pourrez avoir. Cet article a pour but de vous montrer comment, malgré un nombre important de machines à superviser, on peut arriver à une bonne gestion, améliorer la sécurité de son réseau et détecter d'éventuels problèmes. La première partie de cet article consiste à présenter une manière de centraliser les logs, puis, dans un deuxième temps, nous ferons un peu d'analyse.

Cet article porte, dans un premier temps, sur RSyslog, programme permettant de gérer les logs pour, par exemple, les centraliser de façon sécurisée, et qui, contrairement à la version libre de Syslog-ng, garantit la délivrance des logs (protocole RELP) et permet de les envoyer à travers un flux crypté (à l'heure actuelle uniquement avec Stunnel pour RELP, sinon avec une implémentation native GnuTLS ne permettant pas l'utilisation de RELP). Il est utile de centraliser les logs pour plusieurs raisons, par exemple, afin d'analyser les logs d'une machine à laquelle on n’a plus accès, surtout quand la raison de la coupure se trouve... dans les logs locaux.

La distribution Linux Debian est utilisée pour tout ce qui est décrit plus bas. Cela doit se transposer assez facilement sur Ubuntu et, pour les autres distributions, en dehors du nommage des paquets, tout le reste ne devrait pas changer.

Dans le cadre de cet article, nous allons mettre en place RSyslog sur 2 machines : le centraliseur (192.168.1.1), et un émetteur (192.168.1.42).

1. RSyslog

RSyslog est disponible sur http://www.rsyslog.com/, la documentation est assez claire et correspond à chacun des problèmes que vous pouvez rencontrer lorsque vous déployez ce genre de système.

Ce projet a été initié par Rainer Gerhards pour combler la non-volonté des développeurs de sysklogd (le syslog standard) de faire évoluer l'application Syslog. Ce qui est bien dommage parce que, par défaut, Syslog ne fonctionne qu'en UDP pour émettre les logs. RSyslog a pourtant tenu à garder la simplicité de Syslog. Si l'on regarde le bout de configuration de l'un et de l'autre pour émettre les logs à une machine centrale, dans le cas de Syslog, on mettra :

*.* @192.168.1.1

Tandis que, dans le cas de RSyslog, ce sera :

*.* @@(o)192.168.1.1:10514

Vous voyez que peu de différence existe. Par exemple, le 'o' entre parenthèses signifie que les logs seront envoyés octets par octets.

RSyslog offre des modules, des directives globales (permissions, choix de templates...), et, enfin, des règles (qui ressemblent de très près à ce que vous pouvez trouver dans /etc/syslog.conf par défaut).

1.1 Le protocole RELP

RELP pour Reliable Event Logging Protocol (protocole fiable de journalisation d'évènements) a été développé spécifiquement par le projet RSyslog afin de pouvoir assurer qu'un log émis est bien arrivé à destination.

Il s'agit d'une bibliothèque disponible librement sur http://www.librelp.com/, et elle peut bien sûr être utilisée en dehors de RSyslog.

Comme il est indispensable d'avoir l'assurance qu'un log émis est bien arrivé. Nous allons étudier un peu son fonctionnement.

RELP fonctionne sur un mode client->serveur, le client émet des commandes et attend la réponse du serveur pour savoir si celle-ci est bien passée. Sachant que plusieurs commandes peuvent être émises en même temps (avec une limite bien entendu), les réponses du serveur ne se feront pas forcément dans l'ordre.

La limite de ce modèle tient dans le fait que le serveur ne peut pas émettre de commandes. Ce qui nous va finalement très bien lorsque nous voulons journaliser sur une machine centrale.

1.2 Installation

Pour installer RSyslog, il suffit d'installer trois paquets : # apt-get install rsyslog rsyslog-gnutls rsyslog-relp.

RSyslog remplacera Sysklogd. Il n'est pas possible d'utiliser les deux en même temps. La configuration du syslog ne sera plus dans /etc/syslog.conf, mais dans /etc/rsyslog.conf.

Aussi, nous voulons que RSyslog soit lancé et géré par Init, afin d'éviter toute défaillance du démon sur un service aussi critique. Comme le démon ne se lancera pas tout seul, nous allons le désactiver depuis /etc/init.d/rsyslogd en ajoutant ceci au début du fichier :

#!/bin/bash

echo "Rsyslog se lance par inittab"

exit 0

Puis, dans /etc/inittab, nous ajoutons ceci :

RSYS:2345:respawn:/usr/sbin/rsyslogd -n

L'option -n permet de ne pas forker le processus afin qu'Init puisse le lancer sans problème.

On stoppe le démon actuellement en cours d'exécution :

kill $(pidof rsyslogd)

Et nous relançons Init :

telinit q

Pour finir, n'oublions pas le logrotate (sinon vos logs continuerons à être écrits dans le fichier qui a subi la rotation. Éditons /etc/logrotate.d/rsyslog pour remplacer :

invoke-rc.d rsyslogd restart > /dev/null

par :

kill -HUP $(pidof rsyslogd) > /dev/null

Une fois que tout ceci est fait, vérifiez en tuant le processus RSyslog qui tourne et en vérifiant ensuite qu'il tourne encore. Si c'est le cas, nous pouvons continuer.

1.3 Création d'une PKI

Nous allons utiliser le paquet gnutls-bin qui contient le binaire certtool et qui nous permettra de créer facilement notre PKI pour que les envois de nos logs soient chiffrés. Tout ce que nous faisons ici se passe sur le serveur qui centralise les logs, afin que tout ce que concerne la PKI ne soit pas éparpillé.

Par simplification, la PKI sera dans /etc/pki :

mkdir /etc/pki

chmod 700 /etc/pki

cd /etc/pki

Puis, nous allons créer la CA (Autorité de certificats) :

certtool --generate-privkey --outfile ca-key.pem

certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem

Country name (2 chars): FR

Organization name: Wallinfire

Organizational unit name: Security Visualization

Locality name: Paris

State or province name: Ile de France

Common name: logserver

UID:

Email: toady@wallinfire.net

Enter the certificate's serial number in decimal (default: 1023123142): 1023123142

The certificate will expire in (days): 3650

Does the certificate belong to an authority? (y/N): y

Path length constraint (decimal, -1 for no constraint): -1

Is this a TLS web client certificate? (y/N): N

Is this also a TLS web server certificate? (y/N): N

Enter the e-mail of the subject of the certificate: toady@wallinfire.net

Will the certificate be used to sign other certificates? (y/N): y

Will the certificate be used to sign CRLs? (y/N): y

Will the certificate be used to sign code? (y/N): N

Will the certificate be used to sign OCSP requests? (y/N): N

Will the certificate be used for time stamping? (y/N): N

Enter the URI of the CRL distribution point: http://localhost/crl.pem

Is the above information ok? (Y/N): Y

On continue avec la création du certificat serveur. Ceci restera uniquement sur le serveur :

# certtool --generate-privkey --outfile server-privkey.pem

# certtool --generate-request --load-privkey server-privkey.pem --outfile server-request.pem

Country name (2 chars): FR

Organization name: Wallinfire

Organizational unit name: Security Visualization

Locality name: Paris

State or province name: Ile de France

Common name: logserverreq

UID:

Enter a challenge password:

# certtool --generate-certificate --load-request server-request.pem --outfile server-cert.pem --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem

Enter the certificate's serial number in decimal (default: 1023123142): 1023123142

The certificate will expire in (days): 3650

Does the certificate belong to an authority? (y/N): N

Is this a TLS web client certificate? (y/N): N

Is this also a TLS web server certificate? (y/N): y

Enter the dnsName of the subject of the certificate: wallinfire.net

Will the certificate be used for signing (DHE and RSA-EXPORT cipersuites)? (y/N): N

Will the certificate be used for encryption (RSA cipersuites) ? (y/N): y

Is the above information ok? (Y/N): Y

Cela suffit. Pas besoin de générer de certificat client, car le certificat de la CA nous suffira largement. Seul le ca.pem devra être copié sur les serveurs clients.

1.4 Configuration

RSyslog se configure entièrement depuis /etc/rsyslog.conf et, par commodité, tout fichier se terminant par .conf placé dans /etc/rsyslog.d/ sera lu au démarrage. C'est de cette dernière méthode que nous allons user et abuser, tel un âne qui a soif !

1.5 Configuration TLS

Côté serveur, il nous suffit de remplir les chemins complets des certificats que nous avons crées dans le fichier de configuration /etc/rsyslog.d/tls-serveur.conf :

$DefaultNetstreamDriver gtls

$DefaultNetstreamDriverCAFile /etc/pki/ca.pem

$DefaultNetstreamDriverCertFile /etc/pki/server-cert.pem

$DefaultNetstreamDriverKeyFile /etc/pki/server-privkey.pem

$ModLoad /usr/lib/rsyslog/imtcp

$InputTCPServerStreamDriverMode 1 # TLS only mode

$InputTCPServerSTreamDriverAuthMode anon # client not authenticated

$InputTCPServerRun 10514

Nous n'authentifions pas les clients. Le serveur s'exécute sur le port tcp/10514. Seul le TLS est possible et nous utilisons le module gtls pour GnuTLS.

Côté client, il nous faut le ca.pem, puis remplir la connexion au serveur de log. On mettra ceci dans le fichier /etc/rsyslog.d/tls-client.conf :

$DefaultNetstreamDriverCAFile /etc/pki/ca.pem

$DefaultNetstreamDriver gtls

$ActionSendStreamDriverMode 1

$ActionSendStreamDriverAuthMode anon

*.* @@(o)192.168.1.1:10514

Et c'est fini. Il est possible de vérifier l'envoi des logs de manière sécurisée avec tcpdump :

# tcpdump -i any -n -s0 -X 'port 10514'

1.6 Configuration RELP

En parallèle à l'utilisation de GnuTLS pour l'envoi des logs, nous pouvons utiliser RELP. Comme dit plus haut, il n'est pas possible d'utiliser les deux en même temps. Le seul moyen reste d'utiliser RELP à travers Stunnel, mais cela dépasse le cadre de cet article. Cela dit, sur un réseau local cloisonné, il est préférable d'utiliser RELP.

Il suffit de charger le module imrelp, puis de spécifier le port sur lequel nous voulons que le serveur écoute. La configuration côté serveur se fait ainsi (on crée /etc/rsyslog.d/relp-serveur.conf) :

$ModLoad imrelp # needs to be done just once

$InputRELPServerRun 20514

im signifie Input Module ou module d'entrée. Du côté du client, nous allons configurer le module de sortie correspondant omrelp. Dans le fichier /etc/rsyslog.d/relp-client.conf, on met simplement :

$ModLoad omrelp

*.* :omrelp:192.168.1.1:20514;RSYSLOG_ForwardFormat

On redémarre RSyslog avec un bon kill, et on peut maintenant commencer à jouer.

2. Picviz

Une fois que tous les logs sont concentrés sur une seule machine, il est recommandé d'installer un programme d'analyse de logs automatique tel que Prelude LML ou OSSEC. Basé sur des signatures, ces programmes feront une correspondance entre ces dernières et les lignes de logs.

Cependant, il est très difficile de connaître des problèmes non décrits dans ces signatures. On se retrouve toujours à rechercher des motifs connus et on passe à côté de beaucoup de choses.

Picviz permet de créer une simple image en deux dimensions, mais représentant un nombre de dimensions particulièrement grand, et pouvant représenter une infinité d'évènements. Il s'agit d'une image assez technique, qui demande un peu de temps à appréhender, mais qui, au final, permet de trouver des choses intéressantes que l'on ne cherchait pas forcément.

2.1 Installation

À l'instant où j'écris ces lignes, la version 0.6 n'est pas encore sortie. Pourtant, c'est celle-ci que nous allons utiliser dans le cadre de cet article. Sa release étant imminente, il se peut qu'elle soit déjà sortie au moment où vous lisez cet article.

Picviz dépend de cmake, libpcre et cairo. Il est possible aussi de compiler les bindings Python et d'utiliser l'interface graphique en Python pour avoir une interaction directe avec les lignes. Comme nous sommes joueurs, nous allons rester sur l'utilisation du binaire pcv en ligne de commande.

Picviz peut se télécharger sur http://www.wallinfire.net/picviz/wiki/ReleasesDownload. Une fois l'archive récupérée et décompressée, il suffira de lancer make install, puis de vérifier que tout marche bien en tapant :

$ pcv -v

Picviz - (c) 2008-2009 Sebastien Tricaud

pcv version 0.4.5 ($Id: pcv.c 476 2009-04-06 21:50:23Z toady $)

2.2 Architecture

Picviz se découpe en quatre parties :

- libpicviz : bibliothèque sur laquelle s'appuient tous les composants (sauf les parseurs) ; c'est de loin la plus grosse partie de Picviz.

- picviz-cli : interface en ligne de commande minimale utilisant intensivement la bibliothèque.

- picviz-gui : interface graphique permettant de manipuler l'image de manière interactive.

- picviz-parsers : scripts en divers langages (Perl, Python, Bash, Awk...) pour transformer du log en langage PGDL.

En ce qui nous concerne, nous allons utiliser les parseurs pour transformer des logs d'authentification en PGDL, puis utiliser la ligne de commande pour générer un png correspondant à ce fichier.

2.3 Passons vite à la pratique

Nous ne connaissons pas ce qui est vraiment logué, et nous voulons savoir si nous n'avons pas des bizarreries dans le syslog. Nous allons donc créer une image du syslog. Il faut d'abord utiliser le script syslog2picviz.pl disponible dans le module picviz-parsers et créer un fichier de description de graphe Picviz : le PGDL pour Picviz Graph Description Language. Une fois que ceci est fait, on compte les lignes pour avoir une idée de la taille des logs à laquelle nous avons affaire, puis on utilise pcv pour créer l'image png.

$ sudo ./syslog2picviz.pl /var/log/syslog > syslog.pgdl

$ wc -l syslog.pgdl

52200 syslog.pgdl

$ pcv -Tpngcairo syslog.pgdl -o syslog.png

Comme vous pouvez le voir, l'image est très particulière : il s'agit d'une visualisation en coordonnées parallèles. C'est-à-dire que, sur une image 2D, nous faisons apparaître de multiples dimensions. Les axes sont séparés de manière équidistante. Malheureusement, il est difficile ici de décrire les théories mathématiques derrière ce type de graphe, mais, si vous voulez poursuivre dans cette voie, vous pouvez vous rendre sur le site web d'Alfred Inselberg, qui a utilisé cette technique pour résoudre la problématique de la collision d'avions dans les aéroports dans les années 70 : http://www.cs.tau.ac.il/~aiisreal/.

Sur chaque axe, on dépose une variable. Dans notre cas, le premier axe concerne le temps mis sur 24 heures : ainsi, on peut voir les heures auxquelles les machines font le plus de logs. Chaque axe contient la valeur minimale qui se situe tout en bas, et la valeur maximale (tout en haut) de chaque variable. Par exemple, sur notre premier axe désignant le temps sur 24 heures, le point le plus bas correspond à 00:00 et le plus haut à 23:59.

2.4 Le langage PGDL

Le langage PGDL est un langage proche du CSV, mais ayant besoin de fonctionnalités telles que les propriétés sur l'image, les axes ou les lignes. Il a été étendu pour avoir finalement une syntaxe assez proche de Graphviz (http://www.graphviz.org) et de son langage Dot.

Il existe 5 sections :

- header : en-tête du graphe dans laquelle on peut définir un titre, placer un logo, changer la couleur de fond, etc. ;

- engine : section pour les experts voulant modifier l'état du moteur ;

- axes : définition des axes, de leur variable, de leur placement et de leurs propriétés ;

- data : inclusion des données et de leurs propriétés ;

- layer : association des données à une couche pour pouvoir effectuer plus tard des sélections.

Si l'on prend un extrait du fichier généré depuis le syslog, on peut voir :

header {

title = "Syslog picviz analysis";

}

axes {

timeline t [label="Time"];

enum m [label="Machine"];

string a [label="Application",relative="true"];

string l [label="Log",relative="true"];

}

data {

t="06:25",m="quinificated",a="syslogd",l="1.5.0#5: restart.";

t="06:27",m="quinificated",a="NetworkManager:",l="info Supplicant state changed: 0 ";

}

Dans notre cas, nous avons une image en quatre dimensions. Il est possible de changer l'ordre d'apparition des axes, voire d'en rajouter uniquement en jouant sur ce que l'on a dans la section axes :

axes {

timeline t [label="Time"];

string l [label="Log",relative="true"];

string a [label="Application",relative="true"];

enum m [label="Machine"];

string l [label="Log",relative="true"];

}

Les axes peuvent recevoir les propriétés suivantes :

Propriété Description Exemple
label Texte à afficher label="toto"
relative Placement des points de manière relative aux autres relative = "true"
print Affichage ou non des données de cet axe print = "false"

Quant aux variables, il est possible de choisir parmi : timeline, years, integer, string, short, ipv4, ipv6, char, enum, ln ou port, selon le type de données que l'on souhaite afficher.

Essayez de générer depuis les scripts existants du PGDL afin de comprendre quelle est la meilleure manière de choisir le type de la variable.

En ce qui concerne les données contenues dans la section data, elles peuvent aussi recevoir des propriétés comme ceci :

data {

t="12:00", m="quinificated", a="syslogd",l="1.5.0#5: restart." [color="red"];

Il existe pour cette section les propriétés suivantes :

Propriété Description Exemple
color Couleur de la ligne label= "toto"
penwidth Épaisseur de la ligne label= "toto"
inlayer Inclusion de la ligne dans une couche (surpasse layer{}) label= "toto"

2.5 Les Filtres

Afin de ne sélectionner que certaines valeurs, il est possible de filtrer. Picviz permet de filtrer des valeurs, des fréquences ou des points de rendu (plot). Dans le cas de l'image que nous avons générée, si nous ne voulons que la ligne de log qui correspond à l'évènement qui se trouve en bas sur le troisième axe (celui des applications), nous pouvons taper :

$ pcv -Tpngcairo syslog.pgdl -a -o syslog-filtered.png 'plot < 5% on axis 3'

Picviz - (c) 2008-2009 Sebastien Tricaud

[+] Applying filter 'plot < 5% on axis 3'

Et obtenir l'image suivante :

L'ajout de l'option -a nous permet d'afficher le texte pour le lire. En haute résolution ou en utilisant la sortie texte de Picviz (-Ttext), il est possible de lire qu'il s'agit d'une commande CRON et que la ligne de log est :

(www-data) CMD ([ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf -a -r /var/log/apache/access.log ] /usr/lib/cgi-bin/awstats.pl -config=awstats -update /dev/null)

2.6 Analyse du syslog

Maintenant que nous avons vu le langage et le filtrage, nous allons pouvoir nous lancer dans une petite analyse grâce à la fréquence d'apparition des lignes pour repérer les logs qui apparaissent le plus souvent, et ceux qui apparaissent le moins.

Picviz permet de modifier le rendu en utilisant l'option -R et, grâce au plugin heatline, nous pouvons afficher une couleur dégradée pour chaque ligne, correspondant à sa fréquence d'apparition entre deux axes. Si l’on reprend le syslog :

$ pcv -Tpngcairo syslog.pgdl -o syslog-freq.png -Rheatline

Ce qui donne :

Si l'on s'intéresse aux évènements de plus haute fréquence, on peut lancer le filtre de fréquence :

$ pcv -Tpngcairo laptop.pgdl -o laptop-freq.png -Rheatline 'freq > 0.9'

Ce qui donne :

À nouveau, en utilisant le plugin de sortie texte, on retrouve les valeurs

Error: Driver 'pcspkr' is already registered, aborting...

ou encore :

convert: segfault at 0 ip b7dcf2c1 sp bfe47be8 error 4

Eh oui, je suis un utilisateur intensif d'Image Magick !

3. Conclusion

Même pour une installation locale, Syslog n'ayant jamais évolué, RSyslog permet de gérer les logs de manière plus efficace. Il n'y a pas de raison de continuer à garder le syslog traditionnel. Si cela est vrai pour une installation locale, cela l'est d'autant plus lorsque vous souhaitez centraliser vos logs. Il n'est pas acceptable de transporter des logs en clair sur UDP. RSyslog a beaucoup de qualités qui vous épargneront bien des problèmes.

Une fois que ces logs sont centralisés, une analyse graphique permet non seulement d'arriver à avoir une idée de ce que vos logs font à peu près, mais aussi d'aller jusqu'à trouver des problèmes que vos logiciels à base de signatures n'auraient pas trouvés. Il s'agit ici d'une petite introduction à Picviz, mais j'espère qu'elle suffit à vous éclairer sur de nouvelles manières de gérer vos logs et les problèmes qui peuvent survenir sur vos machines.