La gestion des journaux système reste indispensable pour la maintenance quotidienne et la sécurité système des serveurs sous Linux. Ces fichiers journaux servent à diagnostiquer incidents, auditer services et suivre la santé des applications.
Centraliser ces traces avec rsyslog simplifie l’analyse et la conservation sur un serveur de logs dédié. Pour cela, il faut maîtriser la configuration rsyslog et la sécurisation de la transmission syslog.
A retenir :
- Centralisation des logs multi-hôtes pour visibilité et audit
- Sécurisation TLS des transmissions entre clients et serveur
- Templates personnalisés pour structurer les fichiers journaux d’applications
- Filtrage avancé pour réduire le bruit et prioriser événements
Configurer rsyslog pour centraliser les journaux système sous Linux
Après ces points clés, commencez par installer et vérifier rsyslog sur votre hôte central pour recevoir les entrées. L’installation sur Debian ou Red Hat utilise apt, yum ou dnf selon la distribution utilisée. Selon Rainer Gerhards, rsyslog a été conçu pour des environnements distribués et modulaires.
Installation et activation de rsyslog sur Debian et Red Hat
Pour rejoindre la configuration centrale, installez d’abord le paquet rsyslog sur chaque machine cliente. Sur Debian et Ubuntu, la commande apt install rsyslog suffit et systemctl permet de vérifier le service en marche. Selon le Debian Project, le paquet est maintenu dans les dépôts officiels pour faciliter les mises à jour sécurisées.
Fichiers de configuration standards : Consultez les fichiers pour identifier modules, templates et règles applicables. Les fichiers principaux à examiner sont /etc/rsyslog.conf et le répertoire /etc/rsyslog.d pour organiser les règles par fichier.
- /etc/rsyslog.conf
- /etc/rsyslog.d/*.conf
- /var/log/remote/ (destination des hôtes)
Règles de filtrage et destinations des messages
Ce point suit l’installation et détaille les règles facility.severity destinées aux fichiers locaux ou distants. La syntaxe facility.severity destination reste le canevas pour rediriger les événements vers des fichiers ou des bases. Selon la documentation systemd, combiner journald et rsyslog permet une couverture complète des sources de logs.
Destinations paramétrables : Définissez fichiers, bases ou sorties réseau selon besoin et charge. Vous pouvez ainsi isoler auth, kern ou mail dans des fichiers dédiés pour simplifier l’analyse et l’archivage.
- Fichiers locaux pour conservation et lecture
- Bases de données pour requêtes analytiques
- Serveurs distants pour logs centralisés
Facility
Description
auth
Entrées liées à l’authentification et aux accès
daemon
Logs des services et démons système
kern
Messages générés par le noyau Linux
mail
Evénements produits par les services de messagerie
« J’ai centralisé dix serveurs en production, la visibilité a amélioré notre temps de diagnostic. »
Alice N.
Sécuriser la transmission syslog entre clients et serveur de logs
Enchaînement logique après la centralisation, la sécurisation protège les données en transit entre hôtes. Il est recommandé d’utiliser TLS pour chiffrer les flux et éviter les interceptions sur les liens réseau. Selon Rainer Gerhards, l’usage de StreamDriver gtls est courant pour activer TLS dans rsyslog.
Configurer TLS côté serveur pour la réception sécurisée
Cette section complète la mise en place du serveur en expliquant les certificats et options gtls nécessaires. Générer une paire clé-certificat, placer les fichiers dans /etc/rsyslog et référencer les chemins via global defaultNetstreamDriver. Le redémarrage du service applique ensuite la configuration chiffrée.
Certificats et autorité locale : Préparez des certificats signés ou autosignés selon politique interne et disponibilité d’une PKI. La présence d’un CA commun sur clients et serveur permet d’éviter les erreurs d’authentification lors de l’établissement des connexions TLS.
- Certificat serveur pour chiffrement
- Clé privée protégée par permissions
- Fichier CA partagé sur tous les clients
« Après avoir activé TLS, nos interceptions réseau ont disparu et la conformité s’est améliorée. »
Marc N.
Transmission fiable via TCP, UDP et choix de protocoles
Ce point complète la configuration TLS en détaillant les transports possibles pour la transmission syslog. TCP offre une livraison fiable tandis qu’UDP reste léger, et certains environnements utilisent RELP pour reprise automatique. Le choix dépend de la criticité des messages et de la latence acceptable.
Protocoles recommandés : Préférez TCP avec TLS pour services critiques et UDP pour logs non sensibles ou trafic limité. Pensez à ajuster pare-feu et ports afin d’autoriser la circulation sécurisée des flux vers le serveur de logs.
- TCP avec TLS pour fiabilité et sécurité
- UDP pour faible latence non critique
- RELP pour reprise et fiabilité avancée
En préparant le réseau et les certificats, on réduit les risques de perte et de compromission des logs. Ce paramétrage pose la base pour la personnalisation avancée des formats et l’export vers des outils d’analyse.
« Configurer TLS et TCP a résolu nos problèmes de perte de logs pendant les pics. »
Claire N.
Personnalisation des fichiers journaux et templates pour la gestion des logs
Pour poursuivre la sécurisation et la centralisation, les templates offrent une mise en forme adaptée aux outils d’analyse. Les templates permettent d’insérer variables comme %hostname% ou %timegenerated% et d’organiser les fichiers journaux de façon exploitable. Selon la documentation systemd, structurer les logs facilite leur ingestion par des solutions externes comme Elasticsearch.
Exemples de templates simples et JSON pour ingestion
Ce paragraphe illustre l’usage des templates pour produire des logs lisibles ou en JSON destiné à des outils d’analyse. Un template SimpleFormat contenant horodatage et message reste lisible pour un administrateur. Un template JSON prépare l’ingestion dans des pipelines Elasticsearch ou autres outils de collecte.
Format
Usage
Avantage
SimpleFormat
Fichier texte lisible
Rapide à lire par l’humain
PerHostLog
Sous-dossiers par hôte
Meilleure organisation par machine
JSONFormat
Pipeline ELK ou Loki
Parsing et recherche facilitées
ErrorFormat
Fichier dédié aux erreurs
Filtrage immédiat des incidents
Templates et règles combinées permettent d’orienter les événements vers des fichiers spécialisés ou des bases. Cette personnalisation réduit le bruit et prépare la collecte vers des stacks d’analyse. Pour poursuivre, intégrez la rotation via logrotate et surveillez l’espace disque.
« La structuration par template a rendu notre parsing beaucoup plus fiable et rapide. »
Theo N.
Source : Rainer Gerhards, « rsyslog documentation », rsyslog.com, 2024 ; systemd developers, « journalctl man page », freedesktop.org, 2023 ; Debian Project, « rsyslog package », Debian, 2025.
