Centralisation des logs avec rsyslog

Mise à jour : 06/11/2024

Dans la suite du guide sur journald, découvrons Rsyslog, un outil complémentaire qui offre une plus grande souplesse dans la gestion des logs sous Linux. Si journald permet une centralisation des journaux sur les systèmes systemd, Rsyslog apporte des fonctionnalités avancées pour filtrer, rediriger, et centraliser les logs dans des environnements hétérogènes ou distribués.

Un peu d’Histoire

Rsyslog a vu le jour pour répondre aux besoins grandissants en matière de centralisation et de gestion des logs dans des environnements Linux. Historiquement, c’est Syslog, un protocole développé dans les années 1980, qui servait de base pour collecter et transmettre les logs. Bien que Syslog ait été un pionnier dans le domaine, ses fonctionnalités limitées et son manque de flexibilité ont rapidement posé problème face aux infrastructures modernes, de plus en plus complexes et sécurisées.

Pour pallier ces insuffisances, des alternatives comme Syslog-ng et Rsyslog ont vu le jour au début des années 2000. Créé par Rainer Gerhards, Rsyslog a apporté des améliorations notables en termes de modularité, de performance et de gestion des logs à distance. Il a rapidement gagné en popularité grâce à sa capacité à gérer des protocoles avancés (comme TCP, UDP, et RELP) et à offrir une grande flexibilité dans le filtrage et la personnalisation des logs.

Au fil des années, Rsyslog a évolué pour devenir un outil modulaire et extensible, capable de s’intégrer dans des environnements modernes de gestion des logs. Son adoption s’est étendue, et il est aujourd’hui couramment utilisé dans des infrastructures variées pour compléter ou remplacer journald dans la collecte et la transmission des logs. Grâce à ses nombreuses fonctionnalités avancées, Rsyslog reste un choix privilégié pour les administrateurs système cherchant une solution de gestion des logs flexible et performante.

Fonctionnalités principales

Rsyslog se distingue par une gamme de fonctionnalités qui le rendent très flexible pour la gestion avancée des logs. Voici les principales :

Centralisation des logs : Rsyslog permet de centraliser les logs de plusieurs systèmes, simplifiant ainsi la gestion et l’analyse centralisée des données.
Filtrage avancé des logs : Grâce à un système de règles, il est possible de filtrer les logs en fonction de critères spécifiques (source, niveau de sévérité, contenu, etc.).
Support multi-protocole : Il peut transmettre les logs en utilisant plusieurs protocoles, comme TCP, UDP, et RELP, offrant une plus grande flexibilité selon les besoins de l’infrastructure.
Modularité : Rsyslog est extensible via des modules, ce qui permet d’ajouter facilement des fonctionnalités supplémentaires pour gérer des sources de logs spécifiques ou des formats particuliers.
Personnalisation des formats de logs : Avec les templates, il est possible de personnaliser les formats des logs en sortie pour répondre aux exigences spécifiques des systèmes de surveillance ou des applications d’analyse.
Gestion des gros volumes de données : Conçu pour être performant, Rsyslog peut gérer de grandes quantités de logs sans compromettre la stabilité du système.
Compression et rotation des logs : Il inclut des options pour compresser, archiver et faire la rotation automatique des logs, réduisant ainsi l’espace disque nécessaire.
Support des bases de données : Rsyslog peut envoyer des logs vers des bases de données (MySQL, PostgreSQL), facilitant ainsi le stockage et la recherche des logs dans des environnements plus sophistiqués.
Sécurité avancée : Il permet de sécuriser les transmissions des logs par chiffrement (SSL/TLS), offrant une protection accrue contre les interceptions et les accès non autorisés.
Gestion des logs d’applications spécifiques : Rsyslog peut être configuré pour surveiller des fichiers spécifiques ou des logs d’applications particulières, comme les serveurs web ou les bases de données, via des modules dédiés comme imfile.

Installation de Rsyslog

L’installation de Rsyslog est relativement simple et dépend de la distribution Linux utilisée. Voici les étapes d’installation sur les principales familles de distributions : Debian/Ubuntu et Red Hat/CentOS.

Installation sur Debian/Ubuntu

Sur les distributions basées sur Debian (comme Ubuntu), Rsyslog est généralement inclus dans les dépôts officiels, ce qui simplifie l’installation.

Mettre à jour les dépôts :
Terminal window
```
sudo apt update
```
Installer Rsyslog :
Terminal window
```
sudo apt install rsyslog -y
```
Vérifier le statut de Rsyslog : Par défaut, Rsyslog démarre automatiquement après l’installation. Pour vérifier que le service est actif :
Terminal window
```
sudo systemctl status rsyslog
```
Activer Rsyslog au démarrage (si nécessaire) : Bien que Rsyslog soit généralement configuré pour démarrer automatiquement, vous pouvez vous assurer qu’il est activé au démarrage avec la commande suivante :
Terminal window
```
sudo systemctl enable rsyslog
```

Installation sur Red Hat/CentOS

Sur les distributions de type Red Hat (comme CentOS, Fedora, et RHEL), Rsyslog est également inclus dans les dépôts de base. L’installation suit un processus similaire.

Mettre à jour les dépôts :
Terminal window
```
sudo yum update
```
ou pour les distributions plus récentes utilisant dnf :
Terminal window
```
sudo dnf update
```

Installer Rsyslog :

sudo yum install rsyslog -y

ou avec dnf :

sudo dnf install rsyslog -y

Vérifier le statut de Rsyslog : Après l’installation, vous pouvez vérifier que Rsyslog est bien actif en exécutant :
Terminal window
```
sudo systemctl status rsyslog
```
Activer Rsyslog au démarrage : Pour garantir que Rsyslog démarre automatiquement à chaque redémarrage du système, activez-le avec la commande suivante :
Terminal window
```
sudo systemctl enable rsyslog
```

Configuration de Rsyslog

Maintenant que tout est en place, nous allons configurer Rsyslog plus finement. Commencons par comprendre la structure du fichier de configuration.

Le fichier /etc/rsyslog.conf est divisé en plusieurs sections :

Modules : chargement des modules pour ajouter des fonctionnalités spécifiques.
Global Directives : paramètres globaux qui affectent le fonctionnement de Rsyslog.
Rules : règles de filtrage qui définissent quelles données sont collectées et où elles sont envoyées.

Chargement des modules nécessaires

Rsyslog utilise des modules pour étendre ses fonctionnalités de base. Certains modules sont essentiels pour des fonctionnalités spécifiques, comme la réception des logs via le réseau ou la lecture des logs de journald.

Pour charger un module, utilisez la directive module(load="nom_du_module"). Par exemple :

module(load="imuxsock")    # Pour recevoir les logs locaux via le socket syslog
module(load="imjournal")      # Pour récupérer les logs de journald

Définir les directives globales

Les directives globales permettent de configurer des aspects importants de Rsyslog, comme le format des logs et les options de queueing. Voici quelques directives globales courantes :

Réglage du format de timestamp : Par défaut, Rsyslog utilise le format de date standard RFC 3164, mais vous pouvez opter pour un format plus précis.
Paramètres de sécurité : Pour activer un chiffrement ou des autorisations spécifiques, il est possible de configurer des règles globales de sécurité dans cette section.

Configuration des règles de filtrage de base

Les règles de filtrage permettent de décider où envoyer les logs en fonction de leur type, de leur niveau de gravité, ou de leur origine. Une règle de base de Rsyslog suit la syntaxe :

facility.severity destination

facility : spécifie le type de log (exemples : auth, mail, daemon, kern, etc.).
severity : spécifie le niveau de gravité du log (debug, info, notice, warn, err, crit, alert, emerg).
destination : détermine où le log doit être envoyé (fichier, base de données, serveur distant, etc.).

Voici un tableau listant toutes les facilities disponibles dans Rsyslog. Ces facilities représentent différents types de logs et permettent de catégoriser les événements générés par le système et les applications.

Facility	Description
`auth`	Logs d’authentification et de sécurité
`authpriv`	Logs d’authentification privés
`cron`	Logs des services de planification (ex : cron)
`daemon`	Logs des services et démons système
`kern`	Logs du noyau (kernel)
`lpr`	Logs du système d’impression
`mail`	Logs liés aux services de messagerie (mail)
`news`	Logs pour les services d’actualités et de diffusion
`syslog`	Logs générés par le daemon syslog
`user`	Logs des utilisateurs
`uucp`	Logs liés au protocole UUCP (Unix-to-Unix Copy Protocol)
`local0`	Facilities locales personnalisables pour des applications spécifiques
`local1`	Facilities locales personnalisables pour des applications spécifiques
`local2`	Facilities locales personnalisables pour des applications spécifiques
`local3`	Facilities locales personnalisables pour des applications spécifiques
`local4`	Facilities locales personnalisables pour des applications spécifiques
`local5`	Facilities locales personnalisables pour des applications spécifiques
`local6`	Facilities locales personnalisables pour des applications spécifiques
`local7`	Facilities locales personnalisables pour des applications spécifiques

Chaque facility peut être utilisée pour définir des règles de filtrage dans Rsyslog, ce qui permet de rediriger ou de catégoriser les logs en fonction de leur origine ou de leur type. Par exemple, les logs de auth peuvent être envoyés dans un fichier spécifique pour faciliter le suivi des événements de sécurité.

Exemple de règles de base

Rediriger les logs du noyau vers un fichier spécifique :
```
kern.* /var/log/kern.log
```
Enregistrer uniquement les erreurs système :
```
*.err /var/log/syslog-errors.log
```
Envoyer les logs d’authentification vers un fichier dédié :
```
auth.* /var/log/auth.log
```

Configuration des destinations de log

Rsyslog permet de rediriger les logs vers différents types de destinations, notamment :

Fichiers locaux : La destination la plus courante est un fichier local. Pour enregistrer les logs système dans /var/log/syslog :
```
*.* /var/log/syslog
```
Bases de données : Pour des configurations avancées, Rsyslog peut envoyer les logs vers une base de données, comme MySQL ou PostgreSQL, en utilisant un module de sortie dédié.

Rotation et compression des logs

Rsyslog ne gère pas directement la rotation des fichiers de log. Il est conseillé d’utiliser des outils comme logrotate pour automatiser la rotation, la compression, et la suppression des anciens fichiers de log.

Configurer logrotate pour Rsyslog : Le fichier de configuration de logrotate pour Rsyslog se trouve généralement dans /etc/logrotate.d/rsyslog. Vous pouvez y définir des règles pour gérer l’archivage et la suppression automatique des fichiers de log.

Redémarrer Rsyslog pour appliquer les modifications

Une fois les modifications apportées au fichier de configuration /etc/rsyslog.conf, redémarrez Rsyslog pour qu’elles soient prises en compte :

sudo systemctl restart rsyslog

Vérification de la configuration

Pour tester si les règles sont correctement appliquées, vous pouvez utiliser la commande logger pour générer un message de log de test :

logger "Message de test pour vérifier la configuration de Rsyslog"

Ensuite, vérifiez dans les fichiers de log configurés si le message est bien redirigé comme prévu dans le fichier /var/log/syslog.

2024-11-04T18:27:11.032829+01:00 bastion root: Message de test pour vérifier la configuration de Rsyslog

Centralisation des logs avec Rsyslog

Centraliser les logs est une pratique courante pour simplifier leur gestion, renforcer la sécurité, et faciliter l’analyse dans des environnements contenant plusieurs serveurs. Rsyslog est particulièrement adapté pour la centralisation grâce à sa capacité à recevoir des logs provenant de plusieurs hôtes et à transmettre les logs vers un serveur central. Ce chapitre vous guide dans la configuration de Rsyslog pour centraliser les logs et assurer une transmission sécurisée entre les machines clientes et le serveur central.

Objectifs de la centralisation des logs

La centralisation des logs offre plusieurs avantages :

Visibilité globale : Possibilité d’analyser les logs de toutes les machines depuis un point unique.
Sécurité accrue : Les logs sont stockés en un seul endroit, rendant leur protection plus facile.
Détection des anomalies : L’analyse centralisée permet de repérer rapidement des incidents potentiels sur plusieurs systèmes.
Facilité d’audit : Simplifie les audits en regroupant tous les logs dans un emplacement unique.

Configuration du serveur Rsyslog central

Installer Rsyslog sur le serveur central (voir le chapitre sur l’installation).
Configurer le serveur Rsyslog pour recevoir les logs : Ouvrez le fichier de configuration principal /etc/rsyslog.conf et activez les modules nécessaires pour recevoir les logs via le réseau.
- Activer le module UDP (facultatif, moins sécurisé) :
```
module(load="imudp")    # Charge le module UDP
input(type="imudp" port="514")    # Configure le port UDP 514 pour recevoir les logs
```
- Activer le module TCP (recommandé pour plus de fiabilité) :
```
module(load="imtcp")    # Charge le module TCP
input(type="imtcp" port="514")    # Configure le port TCP 514 pour recevoir les logs
```
Note : Il est préférable d’utiliser TCP pour sa fiabilité, surtout dans des environnements critiques.
Définir un fichier de destination pour chaque client : Vous pouvez configurer Rsyslog pour stocker les logs de chaque client dans des fichiers distincts. Par exemple, en utilisant le nom d’hôte pour différencier les fichiers :
```
template(name="RemoteLogs" type="string" string="/var/log/remote/%HOSTNAME%.log")
*.* ?RemoteLogs
```
Cette configuration crée un fichier log séparé pour chaque client dans le dossier /var/log/remote, basé sur leur nom d’hôte.
Redémarrer le serveur Rsyslog : Après avoir modifié la configuration, redémarrez Rsyslog pour appliquer les modifications :
Terminal window
```
sudo systemctl restart rsyslog
```

Configuration des clients Rsyslog

Les machines clientes doivent être configurées pour envoyer leurs logs vers le serveur central.

Ouvrir la configuration de Rsyslog sur chaque client : Sur chaque machine cliente, éditez le fichier /etc/rsyslog.conf.
Configurer l’envoi des logs au serveur distant : Ajoutez la configuration suivante pour envoyer tous les logs au serveur central.
- Envoi via UDP :
```
*.* @serveur-central-ip:514
```
- Envoi via TCP :
```
*.* @@serveur-central-ip:514
```
Remplacez serveur-central-ip par l’adresse IP du serveur central.
Redémarrer le client Rsyslog : Après avoir configuré chaque client, redémarrez le service Rsyslog pour prendre en compte la nouvelle configuration :
Terminal window
```
sudo systemctl restart rsyslog
```

Sécuriser les transmissions de logs avec SSL/TLS

Pour éviter que les logs soient interceptés lors de la transmission, il est recommandé de sécuriser les connexions entre les clients et le serveur central en utilisant SSL/TLS.

Installer OpenSSL (si nécessaire) : Assurez-vous que OpenSSL est installé sur le serveur et les clients pour gérer les certificats SSL.
Générer un certificat et une clé privée : Sur le serveur central, générez un certificat et une clé privée. Vous pouvez utiliser OpenSSL pour créer un certificat auto-signé :
Terminal window
```
sudo openssl req -x509 -newkey rsa:2048 -keyout /etc/rsyslog/rsyslog.key -out /etc/rsyslog/rsyslog.crt -days 365 -nodes
```

Configurer Rsyslog pour utiliser SSL/TLS :

Sur le serveur, ouvrez /etc/rsyslog.conf et configurez les options suivantes :

module(load="imtcp" StreamDriver.Name="gtls" StreamDriver.Mode="1" StreamDriver.AuthMode="anon")
input(type="imtcp" port="514" StreamDriver="gtls")

Ajoutez ensuite les chemins vers le certificat et la clé privée :

global(
  defaultNetstreamDriverCAFile="/etc/rsyslog/rsyslog.crt"
  defaultNetstreamDriverCertFile="/etc/rsyslog/rsyslog.crt"
  defaultNetstreamDriverKeyFile="/etc/rsyslog/rsyslog.key"
)

Redémarrez le serveur Rsyslog pour appliquer la configuration SSL/TLS.

Configurer les clients pour utiliser SSL/TLS : Sur chaque client, ouvrez le fichier /etc/rsyslog.conf et configurez l’envoi des logs vers le serveur avec SSL/TLS :
```
$DefaultNetstreamDriverCAFile /etc/rsyslog/rsyslog.crt
$ActionSendStreamDriver gtls
$ActionSendStreamDriverMode 1
$ActionSendStreamDriverAuthMode anon
*.* @@serveur-central-ip:514
```
Remplacez serveur-central-ip par l’adresse IP de votre serveur central. Assurez-vous également que le fichier de certificat rsyslog.crt est présent sur chaque client.
Redémarrer les clients : Redémarrez Rsyslog sur chaque client pour appliquer la configuration SSL/TLS.

Vérifications et tests

Après avoir configuré les clients et le serveur :

Envoyer un message de test : Utilisez la commande suivante sur une machine cliente pour générer un log de test :
Terminal window
```
logger "Test de centralisation des logs avec Rsyslog"
```
Vérifier sur le serveur central : Connectez-vous au serveur central et vérifiez le fichier de log dédié pour voir si le message de test apparaît correctement.

Utilisation des templates pour personnaliser les logs

Rsyslog propose un système de templates très flexible, permettant de formater et personnaliser la sortie des logs. Les templates peuvent être utilisés pour modifier l’apparence des logs, les diriger vers des fichiers spécifiques, ou pour organiser les logs dans des répertoires particuliers selon leur origine, leur niveau de gravité, ou d’autres critères. Cette capacité de personnalisation est particulièrement utile dans des environnements où des exigences spécifiques de format de logs ou des besoins d’analyse avancée sont nécessaires.

Pourquoi utiliser des templates ?

Les templates permettent de :

Personnaliser le format des logs : ajouter ou enlever des informations spécifiques (date, heure, nom d’hôte, programme, etc.).
Organiser les logs par hôte ou par application : les logs peuvent être redirigés vers des fichiers et dossiers spécifiques en fonction de leur source.
Rendre les logs plus lisibles pour des outils d’analyse en adaptant leur structure.

Syntaxe des templates

Les templates dans Rsyslog sont définis avec la syntaxe suivante :

template(name="nom_du_template" type="string" string="contenu_du_template")

Le contenu_du_template est une chaîne de caractères contenant les variables qui définissent la structure du log. Voici quelques variables courantes :

%timegenerated% : horodatage de génération du log.
%hostname% : nom d’hôte de la machine source.
%syslogtag% : programme ou service à l’origine du log.
%msg% : message du log.
%pri-text% : priorité du log.

Chaque variable est entourée de % et permet d’insérer des informations spécifiques dans le format final du log.

Exemple de template simple

Prenons un exemple simple où nous souhaitons afficher l’horodatage, le nom de l’hôte, et le message du log dans chaque entrée de log. Voici comment définir un tel template :

template(name="SimpleFormat" type="string" string="%timegenerated% %hostname% %msg%\n")

Avec ce template, chaque log sera formaté avec l’horodatage, le nom de l’hôte, et le message.

Utilisation des templates dans les règles

Une fois le template défini, vous pouvez l’appliquer dans les règles de Rsyslog pour lier les logs à des fichiers spécifiques.

Exemple d’utilisation de template dans une règle

Pour rediriger tous les logs système dans un fichier en utilisant le template défini, vous pouvez ajouter la règle suivante dans /etc/rsyslog.conf :

*.* /var/log/custom_syslog.log;SimpleFormat

Dans cet exemple, tous les logs sont enregistrés dans /var/log/custom_syslog.log en utilisant le template SimpleFormat que nous avons défini précédemment.

Utilisation avancée des templates

Les templates peuvent également être utilisés pour créer des structures de fichiers dynamiques, ce qui est particulièrement utile lorsque vous gérez les logs de plusieurs machines ou applications.

Exemple : Organisation des logs par nom d’hôte

Vous pouvez définir un template pour stocker les logs de chaque hôte dans des sous-dossiers spécifiques en fonction du nom d’hôte. Par exemple :

template(name="PerHostLog" type="string" string="/var/log/%hostname%/%programname%.log")

Avec cette configuration, chaque log sera dirigé vers un fichier unique basé sur le nom de l’hôte et le programme source.

Ensuite, vous pouvez utiliser ce template dans une règle pour centraliser tous les logs dans ces sous-dossiers :

*.* ?PerHostLog
& stop

Cette configuration permet d’organiser les logs dans des répertoires basés sur le nom d’hôte, ce qui simplifie l’analyse des logs dans des environnements avec de nombreux systèmes.

Exemple : Format JSON pour l’analyse avancée

Si vous utilisez un outil d’analyse de logs qui prend en charge JSON, vous pouvez définir un template JSON pour organiser les logs dans ce format. Cela permet de structurer chaque log comme un objet JSON, ce qui facilite l’ingestion par des outils comme Elasticsearch ou Splunk.

Voici un exemple de template JSON :

template(name="JSONFormat" type="list") {
  property(name="timereported" format="jsonf")
  property(name="hostname" format="jsonf")
  property(name="syslogtag" format="jsonf")
  property(name="msg" format="jsonf")
}

Ensuite, vous pouvez utiliser ce template dans une règle pour stocker les logs dans un fichier JSON :

*.* /var/log/json_logs.log;JSONFormat

Avec cette configuration, chaque log sera enregistré en JSON dans /var/log/json_logs.log, facilitant ainsi son analyse par des outils compatibles JSON.

Exemple : Filtrage par niveau de gravité et template

Vous pouvez également combiner les templates avec des filtres pour rediriger les logs en fonction de leur niveau de gravité. Par exemple, pour enregistrer uniquement les logs de niveau error dans un fichier spécifique avec un format personnalisé :

Définir un template pour le format des logs d’erreurs :

template(name="ErrorFormat" type="string" string="%timegenerated% %hostname% %syslogtag%: %msg%\n")

Créer une règle de filtrage utilisant ce template :
```
*.err /var/log/errors.log;ErrorFormat
```

Dans cet exemple, tous les logs d’erreurs seront stockés dans /var/log/errors.log en utilisant le format défini dans ErrorFormat.

Conclusion

On en reste là pour le moment, mais je complèterai ce guide avec d’autres exemples et bonnes pratiques au fur et à mesure. N’hésitez pas à me poser des questions ou à suggérer des sujets à aborder !