[Tuto] Centraliser les journaux d’événements Linux avec Rsyslog et LogAnalyzer (+ vidéo)

Afin de pouvoir gérer au mieux les événements système de ses serveurs, la meilleure solution est la centralisation des logs sur un serveur dédié.

Centraliser ses logs est un moyen de superviser son infrastructure et conserver un accès aux événements survenus sur les machines de son parc.

Dans cet article, nous verrons comment mettre en place une telle solution sous Debian en utilisant le logiciel Rsyslog couplé à l’interface graphique LogAnalyzer afin d’avoir une vue plus agréable de ces fichiers très importants !

Centralisation des logs Linux avec Rsyslog et l’interface web LogAnalyzer

Démonstration en vidéo disponible au lien suivant : Centraliser ses logs Linux
Avec en bonus, une démo de l’ajout des logs Windows et Cisco

Un peu de théorie avec de se lancer dans la pratique

Déjà, c’est quoi un log ?

Et bien ce qu’on appelle techniquement « logs », ce sont en réalité des fichiers texte qui recensent chronologiquement tous les événements qui se sont déroulés sur un système informatique, que ce soit au niveau du système d’exploitation ou des applications qu’il héberge.

On retrouvera dans des logs par exemples, les redémarrages des services, les connexions des utilisateurs, les erreurs rencontrées par le système ou les logiciels…

Ce sont des fichiers très précieux pour comprendre la source d’un problème, le déboguer et surveiller l’état de santé d’une machine.

C’est pourquoi, exporter les journaux événements de tous ses serveurs sur une seule et même machine dédiée, est une bonne pratique. Et en y ajoutant une interface graphique, ils pourront mieux être triés, classés et consultés, par source, par criticité etc…

Pour permettre cette centralisation des journaux, le protocole initialement utilisé est le protocole syslog. Le protocole syslog permet justement le transfert des informations sur le port UDP 514.

De nos jours, on préférera utiliser un protocole TCP qui accusera réception des données contrairement au protocole UDP qui lui ne se souciera pas de la bonne/mauvaise transmission des informations.

Le logiciel de gestion des logs que nous allons utiliser, Rsyslog, utilise justement son propre protocole réseau, le protocole RELP (Reliable Event Logging Protocol) qui, étant un protocole TCP, offre une meilleure garantie de réception des événements par le serveur.

Afin d’avoir un accès plus « graphique » des journaux d’événements, nous allons utiliser l’interface web LogAnalyzer qui va nous permettre de voir et analyser les logs en temps réel mais également de les trier selon ce que l’on souhaite.

Trier ses logs justement, syslog le fait déjà un peu pour nous…

En effet, lorsque l’on s’attaque à la configuration de logs, on est forcément confronté aux notions de “facilities” et de “severities“ (aussi appelées “priorities“). Ce sont des concepts importants dans la gestion des logs.

Ce qu’on appelle une “facility” est en fait une catégorie de logs qui correspond à un type de service. Les facilities permettent de filtrer les logs et les ranger selon leur type. Elles s’appliquent par un système de “code“, au nombre de 24, chaque code correspondant à une catégorie. Voici un tableau récapitulatif des facilities :

Quant aux “severities”, ce sont les niveaux de gravité des erreurs de logs. Ces niveaux sont au nombre de 8 et fonctionnent comme les facilites, avec un système de code couplé à un keyword. Il faut savoir que plus le niveau de gravité est proche de la valeur 0, plus l’erreur sera grave. On parle d’urgence absolue pour la machine concernée. Voici le tableau recensant les severities :

Attention, plus le niveau de gravité défini sera proche de 7, la valeur la moins « importante » donc, plus il y aura de logs générés, plus ou moins utiles selon ce que vous souhaitez. Si l’on définit sur une machine la severity 6 par exemple, cela signifie que TOUS les niveaux précédents seront aussi activés ! Si on définit une severity 3, on aura alors les logs de sévérité error + critical + alert + emergency.

Voilà pour la théorie ! Maintenant, comme d’habitude, une petite topologie de mon lab :

J’utilise ici :

Un serveur Debian (Stretch) destiné à recevoir les logs dans une base de données dédiée
Un serveur Debien (Stretch) avec le service web Apache2 installé pour envoyer ses logs
Un client pour accéder à l’interface graphique du serveur de logs.

Rsyslog est nativement implémenté dans les dernières versions de la distribution Debian utilisée dans ce tutoriel.

Allons-y ! La mise en place d’un tel service pour son infra Linux est plutôt simple et rapide.

Sur le futur serveur de logs, commençons par faire une petite vérification sur la présence d’éventuelles mises à jour et leur lancement si besoin :

apt-get update && apt-get upgrade -y

Ensuite, installez les services de base d’une pile « LAMP » (Linux Apache Mysql ou MariaDB PHP) et les modules de PHP nécessaires au bon fonctionnement de l’interface web Loganalyzer (attention à adapter à la dernière version de PHP disponible !):

apt-get install apache2 mariadb-server php7.0 php7.0-mysql php7.0-gd –y

Sécurisez l’installation de mysql (mariadb) en définissant au compte root un mot de passe. Ce n’est ici pas une étape obligatoire ou même utile mais c’est une bonne pratique en matière de sécurité à adopter !

mysql_secure_installation

Une série de question vous sera alors posée. La 1^ère vous demandera de saisir le mot de passe actuel pour root. Nous n’en avons pas, appuyez juste sur la touche Entrée.

Ensuite on vous demande « Set root password ? [Y/n] ». Appuyez de nouveau sur la touche Entrée pour répondre « Oui » (Y = Yes) et définir un mot de passe pour l’utilisateur root (2 fois).

Pour toutes les questions qui suivront, appuyez sur Entrée pour valider.

On termine la phase d’installation des services par le module mysql de rsyslog car nous allons héberger les journaux d’événements en base de données :

apt-get install rsyslog-mysql -y

Laissez le dbconfig-common configurer automatiquement la base de données en répondant “OUI” :

Le dbconfig-common va alors créer une base de données appelée “Syslog“ et les deux tables dont nous aurons besoin : “SystemEvents” et “SystemEventsProperties“. Attention à bien respectez la casse de ces noms par la suite !

Définissez un mot de passe pour l’utilisateur nommé “rsyslog” qui aura le contrôle total de la base de données Syslog :

La base de données est prête. Voici les informations importantes à retenir :

- Hôte Database : localhost
- Port Database : 3306
- Nom Database : Syslog
- Table Événements : SystemEvents
- User Database : rsyslog
- Mdp User Database : mdp que vous avez défini

Poursuivons en activant la réception des logs sur le serveur dédié. Modifiez le fichier de configuration de rsyslog :

nano /etc/rsyslog.conf

Décommentez les 2 lignes sous « provides TCP » (supprimez le # devant les lignes) et laissez le port 514 par défaut :

A la fin de ce même fichier, ajoutez la ligne suivante pour renvoyer les logs directement à la base de données en renseignant le password que vous avez défini à l’utilisateur rsyslog :

*.* :ommysql:localhost,Syslog,rsyslog,mdp_user_rsyslog

Redémarrez le service rsyslog pour prendre en compte les modifications :

service rsyslog restart

C’est tout pour la configuration de Rsyslog ! Passons maintenant à LogAnalyzer.

Placez vous dans le répertoire srv et téléchargez la dernière version de LogAnalyzer (4.1.8 à la rédaction de ce post. Allez voir sur : loganalyzer-news).

cd /srv
wget http://download.adiscon.com/loganalyzer/loganalyzer-4.1.8.tar.gz

Une fois le téléchargement terminé, décompressez les fichiers :

tar -zxvf /srv/loganalyzer-4.1.8.tar.gz

Créez un répertoire loganalyzer à la racine du serveur web:

mkdir /var/www/html/loganalyzer

Copiez les fichiers requis dans ce nouveau répertoire :

cp -a /srv/loganalyzer-4.1.8/src/* /var/www/html/loganalyzer

Rendez l’utilisateur www-data (l’utilisateur du service Apache) propriétaire du dossier et de son contenu :

chown -R www-data:www-data /var/www/html/loganalyzer

La suite de la configuration sera effectuée via l’interface web. Depuis le navigateur internet d’un poste client, rendez- vous à l’adresse suivante en remplaçant “srv-logs” par l’adresse ip ou le nom de votre serveur de logs à vous :

http://srv-logs/loganalyzer

Vous tomberez sur le message d’insulte suivant :

C’est NORMAL ! En effet nous n’avons pas encore initier l’installation de LogAnalyzer, il n’existe donc pas encore de fichier de configuration. Cliquez sur “here” pour lancer le setup.

A l’étape 1, on vous explique que le setup va vérifier si les pré-requis sont respectés. Cliquez sur “Next“.

L’étape 2 contrôle les permissions sur les fichiers placés dans /var/www/html/loganalyzer. S’il n’y a pas d’erreur, cliquez sur “Next“ sinon, relancez la commande “chown” précédemment décrite.

L’étape 3 est la configuration basique du logiciel. Cochez la case “Yes“ de la question “Enable User Database” pour renseigner les options de base de données.

Dans la partie inférieure, remplir les champs avec les informations de notre propre base de données Syslog comme sur la capture suivante :

Ces paramètres vont en réalité créer des tables supplémentaires dédiées à LogAnalyzer dans notre base de données Syslog. La partie “Table prefix” peut être laissée par défaut. Cliquez sur “Next“.

L’étape 4 indique que la connexion à la base de données définie à l’étape 3 a bien réussi et que les tables pour LogAnalyzer seront créées à l’étape suivante. Cliquez sur “Next“.

L’étape 5 valide la création des tables. Cliquez sur “Next“.

Créez un utilisateur pour se connecter à l’interface web de loganalyzer et définissez lui un mot de passe. Cliquez sur “Next“.

Il faut maintenant paramétrer la source des logs comme étant notre base de données. Renseignez le champ “Name of the Source” en indiquant par exemple “base de données svr-logs” ou ce que vous voulez.

Modifiez le champ “Source Type” en sélectionnant “MYSQL Native“ ce qui déroulera le menu inférieur des options de base de données.

Dans la partie inférieure justement, laissez le “table type” par défaut et remplissez les informations concernant notre base de données comme dans la capture suivante (attention à la casse pour le nom de la database et la table) :

Terminez l’installation en cliquant sur “Finish!“.

Connectez vous si nécessaire avec le compte précédemment créé.

Voici l’interface de LogAnalyzer où les événements du serveur de logs devraient déjà être remontés :

Pour obtenir des informations sur un événement, cliquez le message le concernant dans la colonne de droite ce qui ouvrira une fenêtre avec le message complet.

Pour effectuer un tri ou des recherches particulières, par nom d’hôte, par criticité, ou encore par service par exemples, vous pouvez utiliser la zone de recherche en saisissant un mot clé et appuyant sur le bouton « Search ». L’affichage vous montrera par exemple uniquement les événements se rapportant du service SSH.

Autre méthode, il suffit de cliquer sur le nom d’un host, d’une facility, d’une severity ou encore d’un syslogtag. LogAnalyzer va alors vous proposer d’appliquer un filtre uniquement avec la notion sur laquelle vous aurez cliquée ou au contraire, de tout afficher SAUF ce qui contient cette notion.

Pour avoir une page dynamique, vous pouvez définir l’auto actualisation dans le menu déroulant « set auto reload ». Vous pouvez également définir le nombre d’enregistrements par page que vous souhaitez avoir dans « Records per page ».

Ajoutons un autre serveur Debian, un serveur web par exemple.

Histoire de se compliquer la tâche, on va demander également que les journaux d’événements du site web soient transférés.

J’utilise le site par défaut créé à l’installation d’apache2, je vais donc modifier sa configuration :

nano /etc/apache2/sites-available/000-default.conf

Modifiez les lignes “ErrorLog” et “CustomLog“ (ou commentez les et ajoutez les nouvelles lignes) par les 2 lignes suivantes :

ErrorLog "|/usr/bin/logger -t APACHE -p local6.info"
CustomLog "|/usr/bin/logger -t APACHE -p local6.info" combined

Redémarrez le service apache pour prendre en compte les modifications :

service apache2 restart

Toujours sur le serveur web, modifiez le fichier de configuration de rsyslog pour indiquer que les logs devront être transférés à un serveur dédié :

nano /etc/rsyslog.conf

A la fin de ce fichier, ajoutez les lignes suivantes :

*.* @@192.168.10.10:514
local6.* @@192.168.10.10

La 1ère signifie que tous les logs locaux (*.*) seront envoyés en TCP (@@) au serveur de logs ayant pour IP 192.168.10.10, sur le port 514.

La 2nde ligne indique que les logs identifiés “local6” (ceux que nous avons déclaré pour le site web donc), seront envoyés vers l’adresse IP du serveur de logs.

Redémarrez le service rsyslog.

service rsyslog restart

Provoquez un peu d’action sur le serveur web. Connectez vous en ssh ou redémarrez un service par exemples.

Actualisez la page de LogAnalyzer.

Les événements du serveur web remontent bien. Si aucune information sur le serveur web ne remonte, redémarrez le service rsyslog sur le serveur de logs et actualisez de nouveau LogAnalyzer.

Vérifions si nous avons également des infos sur le trafic du site web. Je vous rappelle que l’on a modifié les logs pour les obtenir… allez sur le site web pour provoquer un peu de trafic. (adresse http://nom_ou_ip_du_serveur_web)

On réactualise LogAnalyzer. Si tout fonctionne correctement, on obtiendra des messages de ce type spécifiant que telle adresse IP a émis une requête de type « GET » sur le site web :

Notre système de centralisation des logs fonctionne parfaitement !

Info ++ : Attention, devant le grand flux d’événements générés dans une infrastructure, la table “SystemEvents” de la base de données peut vite être surchargée. Il est important d’archiver ses logs et de purger régulièrement cette table à l’aide d’un script automatisé. Plus d’informations au lien suivant : Purger sa base de données Syslog en bash

Ce tuto est maintenant terminé, vous avez toutes les cartes en main pour centraliser les journaux d’événements de votre infra sous Linux ! Je vous laisse explorer par vous-même toutes les possibilités qu’offre LogAnalyzer !

See U !