20.6. Utiliser des modules Rsyslog

En raison de son design modulaire, rsyslog offre une variété de modules qui fournissent des fonctionnalités supplémentaires. Remarquez que ces modules peuvent être écrits par des parties tierces. La plupart des modules fournissent des entrées supplémentaires (consultez les Modules d'entrée ci-dessous) ou des sorties (consultez les Modules de sortie ci-dessous). D'autres modules fournissent des fonctionnalités spéciales spécifiques à chaque module. Les modules peuvent également offrir des directives de configuration supplémentaires qui deviennent disponibles après le chargement d'un module. Pour charger un module, veuillez utiliser la syntaxe suivante :
$ModLoad MODULE
$ModLoad est la directive globale qui charge le module spécifié et MODULE représente le module souhaité. Par exemple, si vous souhaitez charger le module « Text File Input » (imfile) qui permet à rsyslog de convertir tout fichier texte standard en message syslog, spécifiez la ligne suivante dans le fichier de configuration /etc/rsyslog.conf :
$ModLoad imfile
rsyslog offre un certain nombre de modules qui sont divisés selon les catégories principales suivantes :
  • Modules d'entrée — les modules d'entrée collectent des messages provenant de différentes sources. Le nom d'un module d'entrée commence toujours par le préfixe im, comme imfile et imjournal.
  • Modules de sortie — les modules de sortie offrent la possibilité de remettre un message à différentes cibles, par exemple en l'envoyant à travers un réseau, en le stockant dans une base de données, ou le chiffrant. Le nom d'un module de sortie commence toujours par le préfixe om, comme omsnmp, omrelp, etc.
  • Modules d'analyse — ces modules sont utiles à la création de règles d'analyse personnalisées ou pour analyser des messages mal formés. Avec des connaissances modérées du langage de programmation C, il est possible de créer votre propre analyseur de messages. Le nom d'un module d'analyse commence toujours par le préfixe pm, comme pmrfc5424, pmrfc3164, et ainsi de suite.
  • Modules de modification de messages — les modules de modification de messages changent le contenu des messages syslog. Les noms de ces modules commencent par le préfixe mm. Les modules de modification de messages comme mmanon, mmnormalize, ou mmjsonparse sont utilisée pour l'anonymisation ou la normalisation des messages.
  • Modules générateurs de chaînes — les modules générateurs de chaînes génèrent des chaînes basées sur le contenu du message et coopèrent bien avec la fonctionnalité de modèle fournie par rsyslog. Pour obtenir davantage d'informations sur les modèles, veuillez consulter la Section 20.2.3, « Modèles ». Le nom d'un module générateur de chaînes commence toujours par le préfixe sm, comme smfile ou smtradfile.
  • Modules de bibliothèques — les modules de bibliothèques fournissent des fonctionnalités pour d'autres modules chargeables. Ces modules sont chargés automatiquement par rsyslog lorsque nécessaire et ne peuvent pas être configurés par l'utilisateur.
Une liste complète de tous les modules disponibles ainsi que leur description détaillée se trouve sur http://www.rsyslog.com/doc/rsyslog_conf_modules.html.

Avertissement

Remarquez que lorsque rsyslog charge des modules, il leur fournit accès à certaines de ses fonctions et données. Cela peut poser un problème de sécurité. Pour minimiser les risques de sécurité, veuillez utiliser les modules de confiance uniquement.

20.6.1. Importer des fichiers texte

Le module d'entrée de fichiers texte « Text File Input », abbrévié imfile, permet à rsyslog de convertir tout fichier texte en flux de messages syslog. Vous pouvez utiliser imfile pour importer des messages journaux d'applications qui créent leurs propres journaux de fichiers texte. Pour charger imfile, ajoutez ce qui suit au fichier /etc/rsyslog.conf :
$ModLoad imfile
$InputFilePollInterval int
Charger imfile une seule fois est suffisant, même pendant l'importation de multiples fichiers. La directive globale $InputFilePollInterval spécifie à quelle fréquence rsyslog recherche des changements dans les fichiers texte connectés. L'intervalle par défaut s'élève à 10 secondes, et pour le modifier, remplacez int par un intervalle spécifié en secondes.
Pour identifier les fichiers texte à importer, veuillez utiliser la syntaxe suivante dans le fichier /etc/rsyslog.conf :
# File 1
$InputFileName path_to_file
$InputFileTag tag:
$InputFileStateFile state_file_name
$InputFileSeverity severity
$InputFileFacility facility
$InputRunFileMonitor

# File 2
$InputFileName path_to_file2
...
Quatre paramètres sont requis pour spécifier un fichier texte d'entrée :
  • remplacez path_to_file par un chemin vers le fichier texte.
  • remplacez tag: par un nom de balise pour ce message.
  • remplacez state_file_name par un nom unique pour le fichier d'état. Les fichiers d'état, qui sont stockés dans le répertoire de travail de rsyslog, conservent les curseurs des fichiers surveillés et marquent less partitions déjà traitées. Si vous les supprimer, les fichiers entiers seront lus à nouveau. Assurez-vous de spécifier un nom qui n'existe pas déjà.
  • ajoutez la directive $InputRunFileMonitor qui active la surveillance de fichiers. Sans ce paramètre, le fichier texte sera ignoré.
À part les directives requises, plusieurs autres paramètres peuvent être appliqués à l'entrée texte. Paramétrez la sévérité des messages importés en remplaçant severity par un mot-clé approprié. Remplacez facilitypar un mot-clé permettant de définir le sous-système qui a produit le message. Le mots-clés pour la sévérité et le type sont les mêmes que ceux utilisés pour les filtres basés « facility/priorité », veuillez consulter la Section 20.2.1, « Filtres ».

Exemple 20.15. Importer des fichiers texte

Le serveur HTTP Apache crée les fichiers journaux en format texte. Pour appliquer les capacités de traitement de rsyslog aux messages d'erreur apache, commencez par utiliser le module imfile pour importer les messages. Ajoutez ce qui suit au fichier /etc/rsyslog.conf :
$ModLoad imfile

$InputFileName /var/log/httpd/error_log
$InputFileTag apache-error:
$InputFileStateFile state-apache-error
$InputRunFileMonitor

20.6.2. Exporter des messages sur une base de données

Le traitement de données de journal peut être plus rapide et plus convenable lorsqu'effectué dans une base de données, plutôt qu'avec des fichiers texte. Selon le type de DBMS utiliseé, choisissez l'un des divers modules de sortie, tel que ommysql, ompgsql, omoracle, ou ommongodb. Alternativement, utilisez le module de sortie générique omlibdbi qui repose sur la bibliothèque libdbi. Le module omlibdbi prend en charge les systèmes des bases de données Firebird/Interbase, MS SQL, Sybase, SQLite, Ingres, Oracle, mSQL, MySQL, et PostgreSQL.

Exemple 20.16. Exporter des messages Rsyslog sur une base de données

Pour stocker des messages rsyslog dans une base de données MySQL, ajoutez ce qui suit dans le fichier /etc/rsyslog.conf :
$ModLoad ommysql

$ActionOmmysqlServerPort 1234
*.* :ommysql:database-server,database-name,database-userid,database-password
Premièrement, le module de sortie est chargé, puis le port des communications est spécifié. Des informations supplémentaires, comme le nom du serveur et la base de données, ainsi que les données d'authentification sont spécifiées sur la dernière ligne de l'exemple ci-dessus.

20.6.3. Enabling Encrypted Transport

La confidentialité et l'intégrité des transmissions réseau peut être fournie par le protocole de chiffrement TLS ou GSSAPI.
Le protocole de chiffrement TLS (« Transport Layer Security ») est conçu pour sécuriser les communications sur un réseau. Lors de l'utilisation de TLS, les messages rsyslog sont chiffrés avant l'envoi, et une authentification mutuelle existe entre l'envoyeur et le destinataire.
GSSAPI (« Generic Security Service API ») est une interface de programmation d'application permettant aux programmes d'accéder aux services de sécurité. Pour l'utiliser en conjonction avec rsyslog, vous devez avoir un environnement Kerberos fonctionnant correctement.

TLS

Pour faciliter le transport codifié via TLS, vous devez configurer le serveur et le client. Tout d'abord, vous devez créer une clé publique, une clé privée, et un fichier de certificat, consultez Section 12.1.11, « Générer une nouvelle clé et un nouveau certificat »
Du côté serveur, configurez les options suivantes :
  1. Définir le pilote gtls netstream comme pilote par défaut :
    $DefaultNetstreamDriver gtls
    
  2. Fournissez les chemins menant aux fichiers de certificat :
    $DefaultNetstreamDriverCAFile path_ca.pem
    $DefaultNetstreamDriverCertFile path_cert.pem
    $DefaultNetstreamDriverKeyFile path_key.pem
    Remplacer path_ca.pem par le chemin qui mène à votre clé publique, path_cert.pem par le chemin qui mène au fichier de certificat, et path_key.pem par le chemin qui mène à la clé privée.
  3. Charger le module imtcp :
    $ModLoad imtcp
    
  4. Démarrer le serveur et définir les options de pilote :
    $InputTCPServerStreamDriverMode number
    $InputTCPServerStreamDriverAuthMode anon 
    $InputTCPServerRun port
    Vous pourrez, ici, définir le mode du pilote en remplaçant le nombre, inscrire 1 pour activer le mode TCP-only. Le paramètre anon signifie que le client n'est pas authentifié. Remplacer port pour démarrer un listener sur le port requis.
Côté client, veuillez utiliser la configuration suivante :
  1. Télécharger la clé publique :
    $DefaultNetstreamDriverCAFile path_ca.pem
    Remplacer path_ca.pem par le chemin qui mène à la clé publique :
  2. Définir le pilote gtls netstream comme pilote par défaut :
    $DefaultNetstreamDriver gtls
    
  3. Configurez le pilote et spécifier l'action à effectuer :
    $InputTCPServerStreamDriverMode number
    $InputTCPServerStreamDriverAuthMode anon 
    *.* @@server.net:10514
    
    Remplacer nombre et anon selon les configurations correspondantes du serveur. Sur la dernière ligne, un exemple d'action transfert les messages du serveur vers un port TCP indiqué.

Utiliser GSSAPI

Dans rsyslog, l'interaction avec GSSAPI est fournie par le module imgssapi. Pour activer le mode de transfert GSSAPI, utiliser la configuration suivante dans /etc/rsyslog.conf :
$ModLoad imgssapi
Cette directive charge le module imgssapi. Après cela, vous pourrez indiquer ce qui suit :
$InputGSSServerServiceName name
$InputGSSServerPermitPlainTCP on/off
$InputGSSServerMaxSessions number
$InputGSSServerRun port
Vous pouvez définir un nom de serveur GSS en remplaçant le nom. Activer le paramètre $InputGSSServerPermitPlainTCP pour permettre au serveur de recevoir également des messages TCP sur le même port. Cela n'est pas permis par défaut. Remplacer le nombre pour définir le nombre maximum de sessions prises en charge. Par défaut, ce nombre n'est pas limité. Remplacer port par un port que vous aurez sélectionné, et sur lequel vous souhaitez démarrer un serveur GSS.

Note

Le module imgssapi sera initié aussitôt que le lecteur de fichier de configuration rencontrera la directive $InputGSSServerRun dans le fichier de configuration /etc/rsyslog.conf. Les options supplémentaires configurées après $InputGSSServerRun sont donc ignorées. Pour que la configuration puisse avoir lieu, toutes les options de configuration d'imgssapi doivent être mises avant $InputGSSServerRun.

Exemple 20.17. Utiliser GSSAPI

La configuration suivante autorise un serveur GSS sur le port 1514, et permet également de recevoir des messages syslog tcp en texte brut sur le même port.
$ModLoad imgssapi
$InputGSSServerPermitPlainTCP on
$InputGSSServerRun 1514

20.6.4. Utiliser RELP

RELP (« Reliable Event Logging Protocol ») est un protocole réseau pour la journalisation de données dans les réseaux d'ordinateurs. Il est conçu pour fournir une remise fiable des messages d'événements, ce qui le rend utile dans les environnements où la perte de messages n'est pas acceptable.
De même que pour la configuration TLS de base, vous devez passer par trois étapes : créer des certificats, configurer le serveur et le client.
  1. Commencer par créer une clé publique, une clé privée et un fichier de certificat, voir Section 12.1.11, « Générer une nouvelle clé et un nouveau certificat »
  2. Pour configurer le client, télécharger les modules suivants :
    module(load="imuxsock")
    module(load="omrelp")
    module(load="imtcp")
    
    Configurer l'entrée TCP ainsi :
    input(type="imtcp" port="port″)
    
    Remplacer port pour démarrer un listener sur le port demandé.
    Avec le nouveau format de configuration, toutes les configurations de transport sont définies comme paramètres d'une action :
    action(type="omrelp" target="target_IP″ port="target_port″ tls="on"
    tls.caCert="path_ca.pem"
    tls.myCert="path_cert.pem"
    tls.myPrivKey="path_key.pem"
    tls.authmode="mode"
    tls.permittedpeer=["peer_name"]
    )
    
    Ici, target_IP et target_port sont utilisés pour identifier le serveur cible, le paramètre tls="on" active le protocole TLS. Passez les chemins de fichiers de certification par path_ca.pem, path_cert.pem, et path_key.pem. Pour définir le mode d'authentification de la transaction, remplacer le mode par "name" ou "fingerprint". Avec tls.permittedpeer, vous pourrez limiter la connexion à un groupe de pairs sélectionnés. Remplacer peer_name par une empreinte de certificat de pair autorisé.
  3. La configuration de serveur démarre par le chargement de module :
    module(load="imuxsock")
    module(load="imrelp" ruleset="relp")
    
    Configurer l'entrée TCP sur le modèle de la configuration client :
    input(type="imrelp" port="target_port″ tls="on"
    tls.caCert="path_ca.pem"
    tls.myCert="path_cert.pem"
    tls.myPrivKey="path_key.pem"
    tls.authmode="name"
    tls.permittedpeer=["peer_name","peer_name1","peer_name2"]
    )
    
    Ces paramètres d'entrée ont la même signification que les options de configuration du client qui sont expliquées dans la deuxième étape. Dans la dernière étape, configurez les règles et sélectionnez une action. Dans l'exemple suivant, les messages se trouvent à l'emplacement suivant :
    ruleset (name="relp") {
    action(type="omfile" file="log_path")
    }
    
    Remplacer ici log_path par un chemin menant à un répertoire où vous souhaitez stocker vos fichiers de journalisation.