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. good

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 – La vidéo peut différer de l’article (versions différentes)
Il est préférable de vous référez à l’article mis à jour récemment (05/25)

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

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 12.10 (Bookworm) destiné à recevoir les logs dans une base de données dédiée
  • Un serveur Debian 12.10 (Bookworm) 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. bb

 

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 update && apt 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 :

apt install apache2 mariadb-server php php-mysql php-gd -y

Info + : La version de PHP installée sera automatiquement celle disponible dans les dépôts de Debian, à savoir 8x en ce moment. PHP en version 8 est parfaitement fonctionnelle avec rsyslog donc par pitié arrêtez de vouloir utiliser une version de PHP en v7 qui est obsolète ! 

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 install rsyslog-mysql -y

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

Le dbconfig-common va alors s’occuper de créer une base de données appelée « Syslog » dont l’utilisateur « rsyslog » recevra les permissions adéquates pour interagir avec cette base.

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 (/!\ Notez ce nom précis, il faudra respecter la casse par la suite !)
    • 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 à la place de « mdp_user_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 de votre choix, pour moi ça sera /tmp, et téléchargez la dernière version stable de LogAnalyzer disponible (4.1.13 à la rédaction de ce post. Allez voir sur : loganalyzer-news).

cd /tmp
wget http://download.adiscon.com/loganalyzer/loganalyzer-4.1.13.tar.gz

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

tar -zxvf /tmp/loganalyzer-4.1.13.tar.gz

Créez un répertoire « loganalyzer » à la racine du serveur web, vous pouvez mettre le nom que vous voulez du moment que vous adaptez la suite de ce tuto :

mkdir /var/www/html/loganalyzer

Copiez les fichiers requis dans ce nouveau répertoire :

cp -a /tmp/loganalyzer-4.1.13/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 par l’adresse ip ou le nom de votre serveur de logs à vous :

http://IP-seveur-syslog/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 ci-dessous. Attention, pour le nom de la base de données il faut bien mettre un S majuscule. L’utilisateur sera « rsyslog » et le mot de passe que vous avez vous même défini au début.

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« .

Info ++ : Si après avoir cliqué sur Next à l’étape 4 vous avez un message d’insulte de votre navigateur évoquant une erreur interne du serveur, commencez par vérifier si les mots de passe déclarés dans dbcommon et dans le fichier rsyslog.conf sont similaires avec ces 2 commandes : « grep pass /etc/dbconfig-common/rsyslog-mysql.conf » et « grep Syslog /etc/rsyslog.conf », le plus souvent, c’est une erreur de mot de passe (ahhh la couche 8 laugh )…
Vérifiez également dans le fichier rsyslog.conf que vous n’avez pas laissé trainer un espace à la fin de la ligne. Relancez le service avec la commande « service rsyslog restart » et si l’erreur persiste, redémarrez complètement votre serveur. Veillez à utiliser la dernière version stable de LogAnalyzer.

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 ce que vous voulez, ici j’ai mis un nom de serveur par exemple.

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 qui suit. Attention à la casse pour le nom de la database, on oublie pas le S majuscule et pour le champ Database Tablename, il faut mettre un S et un E majuscules.

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

Et là, c’est le drame ! Une page blanche WTF! unknw

On ne panique pas ! C’est un bug connu de colonnes manquantes dans certaines tables de la base de données de syslog. Retournez sur votre serveur Debian, dans un terminal.

Connectez vous au service de base de données (juste écrire « mysql » si vous n’avez pas fait la sécurisation) :

mysql -u root -p

Saisissez les commandes suivantes (vous pouvez copier/coller tout le bloc d’un seul coup) qui vont ajouter les colonnes manquantes à la table SystemEvents :

USE Syslog;
ALTER TABLE SystemEvents
ADD COLUMN checksum INT NOT NULL DEFAULT 0,
ADD COLUMN processid VARCHAR(60) NOT NULL DEFAULT 'UNKNOWN';
EXIT;

Retournez sur l’interface web de LogAnalyzer. Actualisez la page qui était blanche.

Si vous n’êtes pas automatiquement connecté, utilisez les identifiants définis lors de l’étape 6 de l’installation de LogAnalyzer. Vous aurez accès l’Admin Center uniquement si vous vous connectez (bouton « Login » une fois dans LogAnalyzer)

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. laugh

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, installez rsyslog s’il ce n’est pas déjà fait :

apt install rsyslog -y

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) et actualisez LogAnalyzer vous voir vos remontées de LOCAL6.

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 ! drinks

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

Articles pouvant vous intéresser