Centralisation et exploitation de logs : première ébauche des bonnes pratiques

Un des commandements majeurs en Administration Systèmes Réseaux repose sur l’importance et l’attention qu’il faut accorder aux logs, ces petits fichiers de trace des processes longs, lourds, illisibles, insolubles, car c’est eux qui vous remontent l’information. Surtout s’il s’agit d’une info que l’on souhaiterait cachée.

Cet article est donc consacré à l’exploitation de ces traces très ennuyeuses, très riches et qui peuvent révéler les pires indices d’une semaine bien chargée.

Première partie : CATH THEM ALL !!!

La première des choses qu’il faut penser avant toute démarche, avant de se prendre la tête sur les millions de lignes qui déroulent pour vos services, il vous faut d’abord une plateforme saine et unique pour les avoir tous sous la main et pour pouvoir automatiser leur exploitation.

Cette plateforme présente plusieurs avantages : déjà, comme vous venez de le lire, vous les avez tous sous la main, donc possibilité d’automatiser les traitements. Secundo, cela permet aussi, en cas de fracture majeure, d’intrusion et de compromission d’un de vos serveurs, d’avoir une base solide d’analyse des incidents, sans risquer de remettre online ou de modifier l’état de la machine compromise. Enfin, cela peut éventuellement servir à fournir, dans un contexte de loi, à fournir les infos packagées plus facilement.

RSyslog, pour vous servir !

Sous Linux et certains Unix-like, le daemon qui s’occupe de logguer pas mal de choses, dont notamment l’état du système, du hardware, les évènements et autres, s’appelle syslog. Syslog est un daemon un peu vieux, puisqu’il date des premiers noyaux, et, bien qu’il fasse correctement son travail, son remplaçant a déjà été désigné depuis longtemps. Il s’agit de RSyslog.

Mais au fait, qu’est-ce qu’il a de plus ?

Quand on parle de Syslog, on parle forcément de sa version libre, Syslog-ng. Il faut savoir que Syslog-ng n’est pas entièrement du côté de l’OpenSource et de la conception qu’ont les utilisateurs de Linux, dans le sens où il existe plusieurs versions du daemon, une version communautaire, mais surtout des versions Entreprises, donc payantes. L’existence même de cette distinction amène une contrainte de type commerciale qui entrave l’évolution du daemon. En effet, toutes les fonctionnalités destinées aux éditions payantes ne sont et ne seront jamais implémentées dans la version communautaire.

C’est en réaction à ce blocage que le projet RSyslog a vu le jour, en mars 2005. L’objectif étant d’apporter à la Communauté ce qui manquait à Syslog-ng, les résultats ne tardèrent pas à mettre RSyslog loin devant son concurrent et la liste des fonctionnalités proposées est longue.

Le projet jugé mature et solide, le package est depuis disponible sous la plupart des distributions, l’installation est donc on ne peut plus intuitive.

Grâce à RSyslog, vous avez au final tous les logs de tous vos clients centralisés sur votre serveur de log, avec possibilité -c’est même conseillé- de faire transiter les données par autre chose que de l’UDP. Voici quelques liens, pour vous mettre en bouche.

• La documentation officielle,
• Les exemples de configuration, toujours dans l’officiel,
• Un article de LinuxTechRes sur la mise en place d’une centralisation de logs

Seconde partie : process and notifications

Alors, maintenant que vous avez tout sous le coude, que faire ? Vous attelez à lire, tous les jours, chaque logs un par un, pour vérifier la solidité et l’état de vos serveurs ? Malheureux, vous n’y pensez pas !

Logwatch : résumé d’état et mailing

Logwatch est un outil qui travaille sur la base des fichiers de log, généralement en local, et qui fournit en sortie toutes les indications des évènements clés de la machine, de l’état des disque, de l’espace disponible, des tentatives d’authentification infructueuses, bref, un condensé d’information d’un coup d’oeil. Le tout est envoyé par mail à qui de droit.

On peut donc dire que Logwatch s’inscrit dans l’optique de centralisation puisqu’au lieu d’avoir à vous lire plusieurs logs, vous n’avez plus que le résumé produit par l’outil.

En soi, Logwatch est un outil adapté à de petites structures puisque d’une part il travaille en local, et d’autre part, après avoir parsé correctement ses fichiers journaux, il envoie le tout par mail. Ce fonctionnement devient vite embêtant lorsque l’on n’a pas mis en place de centralisation de log et implique des ajustements en amont dans le cas où on y aurait effectivement pensé.

Picviz – PGDL : visuel et analyse graphique des évènements

Picviz est un outil fabuleux permettant, de manière graphique, de parser et de traduire vos fichiers de log en éléments de script (via PGDL et notamment la fonction Perl syslog2picviz.pl), et de mettre tout ça sous forme d’un graphe multi axé. L’affichage du graphe facilite alors bien plus la compréhension et permet de mettre en lumière des évènements, liés ou non, et une corrélation qu’il aurait été difficile de trouver autrement.

Le site officiel offre une documentation très riche sur le fonctionnement de Picviz et laisse transparaître le potentiel de l’outil, et comme rien ne vaut la pratique pour se faire aux nouvelles technologies, je vous encourage à bouquiner la doc et à vous faire la main dessus.

Seulement voilà. Picviz est plus orienté audit réseau qu’utilisation quotidienne. Il apporte des éléments très tangibles concernant les connexions, les communications, les flux, les tentatives, les scans, mais il ne vous renseignera pas aussi complètement sur les problèmes internes de la machine. Normal, il n’a pas été conçu pour ça.

Et puis tous les autres…

Là, on touche le fond. Oui, je reconnais, je suis loin du compte, et j’entends déjà le dernier rang me crier des noms d’outils qui servent, vraiment.

C’est pour ça que ce blog existe ! Revendiquez vos outils ! Montrez vos compétences et ouvrez de nouvelles perspectives !!!

Et surtout, gardez-vous toujours un peu d’avance, histoire de parfaire les techniques et de tester d’autres alternatives -et pourquoi pas, de les développer.