Transfert Syslog SLES sécurisé avec rsyslog et TLS mutuel

Pour acheminer les journaux système de SUSE Linux Enterprise Server (SLES) de manière sécurisée, configurez rsyslog pour envoyer les messages via le port TCP 6514 protégé par TLS, vérifiez le nom du certificat du collecteur et confirmez la réception par un événement de test. SLES 15 SP7 a bénéficié d'une mise à jour optionnelle de rsyslog le 27 mars 2026, ajoutant un module TLS OpenSSL ; la configuration ci-dessous utilise délibérément le gtlsmodule GnuTLS existant.

Cette procédure concerne un expéditeur SLES 15 sles01.example.netet un collecteur rsyslog logs.example.net. Remplacez les noms et les chemins de certificat par vos valeurs. Elle utilise l'authentification TLS mutuelle : le collecteur authentifie l'expéditeur et l'expéditeur authentifie le collecteur.

1. Vérifiez rsyslog et le chemin de journalisation SLES

Sur les deux machines, installez le démon rsyslog et son module GnuTLS depuis vos dépôts SUSE enregistrés. Les installations existantes peuvent déjà contenir le premier paquet.

sudo zypper install rsyslog rsyslog-module-gtls
rpm -q rsyslog rsyslog-module-gtls
sudo systemctl enable --now rsyslog
rsyslogd -v

Veuillez vérifier /etc/rsyslog.confles extraits de code existants /etc/rsyslog.d/avant d'ajouter des règles. En particulier, désactivez toute *.* @@hostrègle de transfert non chiffrée plus ancienne pour la même destination ; sinon, les messages pourraient emprunter deux chemins, dont un sans TLS.

SLES utilise `rsyslog` systemd-journaldpour les événements du journal, tandis que `rsyslog` traite les entrées syslog. Assurez-vous que les événements souhaités parviennent bien à `rsyslog` via la configuration d'entrée existante. La documentation SUSE ForwardToSyslog=yesrelative /etc/systemd/journald.confau transfert des événements du journal vers syslog est disponible ; vérifiez votre déploiement avant toute modification, car l'activation séparée des lecteurs de journal peut engendrer des doublons. Cette procédure transfère les messages déjà traités par `rsyslog`, et non /var/logautomatiquement tous les fichiers du journal.

2. Préparer les certificats de serveur et de client de confiance

Utilisez une autorité de certification (AC) contrôlée par votre organisation pour émettre un certificat contenant le nom alternatif de sujet DNS logs.example.netpour le collecteur et un certificat distinct sles01.example.netpour l'expéditeur. Assurez-vous que les certificats sont valides pour leurs rôles respectifs de serveur ou de client TLS et que les deux machines font confiance à l'AC émettrice. Suivez votre procédure PKI pour la génération et le renouvellement ; ne réutilisez pas une même clé privée sur plusieurs hôtes.

Copiez les fichiers appropriés via un canal sécurisé approuvé par l'administrateur. Dans cet exemple, les deux machines utilisent /etc/rsyslog.d/tls/ca.pem. Le collecteur possède en plus server-cert.pemetserver-key.pem ; l'expéditeur possède client-cert.pemet client-key.pem.

sudo install -d -m 0750 /etc/rsyslog.d/tls
sudo chmod 0600 /etc/rsyslog.d/tls/*-key.pem
sudo chmod 0644 /etc/rsyslog.d/tls/ca.pem

Limitez l'accès aux certificats et aux clés du service rsyslog lorsque cela est nécessaire. Ne divulguez pas les clés privées dans les diagnostics, l'historique du shell, les dépôts Git ou le flux de journalisation exporté. Vérifiez que votre processus rsyslog peut lire sa clé avant de redémarrer le démon.

3. Activez un récepteur TLS authentifié sur le collecteur.

Ajoutez ensuite logs.example.netles lignes suivantes /etc/rsyslog.d/30-tls-listener.conf. Si imtcple module est déjà chargé ailleurs, ne conservez qu'une seule instruction de chargement. Le jeu de règles dédié place les messages reçus à distance dans un fichier séparé au lieu de les mélanger avec les messages du système local.

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/server-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/server-key.pem"
)
module(load="imtcp")
ruleset(name="remote_tls") {
  action(type="omfile" file="/var/log/remote-tls.log")
}
input(
  type="imtcp"
  port="6514"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"
  StreamDriver.AuthMode="x509/name"
  PermittedPeer="sles01.example.net"
  ruleset="remote_tls"
)

StreamDriver.Mode="1"Active le protocole TLS x509/nameet PermittedPeerrejette les clients ne possédant pas d'identité de certificat valide. L'autorisation d'un seul nom est intentionnelle ; l'ajout d'autres expéditeurs à la liste des pairs approuvés permet d'éviter d'affaiblir l'authentification.

sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo firewall-cmd --permanent --add-port=6514/tcp
sudo firewall-cmd --reload
sudo ss -ltn | grep ':6514'

Exécutez les commandes du pare-feu uniquement si le collecteur utilise firewalld. Limitez le trafic TCP entrant sur le port 6514 aux réseaux d'expéditeurs connus à l'aide de votre pare-feu hôte ou en amont ; l'ouverture du port ne remplace pas l'authentification par certificat. Vérifiez également qu'aucun écouteur en clair existant n'est exposé par inadvertance.

4. Ajoutez le transfert TLS et une file d'attente délimitée à SLES.

Assurez - sles01.example.netvous que le répertoire de travail rsyslog existe et est accessible en écriture par le service. Le répertoire indiqué ici est donné à titre d'exemple ; conservez celui déjà configuré workDirectorysi votre installation en fournit un. Ajoutez cet extrait de code comme suit/etc/rsyslog.d/60-tls-forward.conf :

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/client-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/client-key.pem"
)
*.* action(
  type="omfwd"
  target="logs.example.net"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="logs.example.net"
  queue.type="LinkedList"
  queue.filename="tls_forward"
  queue.size="10000"
  queue.maxDiskSpace="1g"
  queue.saveOnShutdown="on"
  action.resumeRetryCount="-1"
)

Les paramètres TLS authentifient le collecteur avant l'envoi. La file d'attente d'actions avec disque met en mémoire tampon les messages lors de brèves interruptions et relance les transferts ayant échoué. Cependant, sa capacité n'est pas illimitée et elle ne garantit pas l'absence totale de perte de messages : l'espace disque disponible, les limites de la file d'attente, le comportement à l'arrêt des processus et l'état du récepteur restent des facteurs importants. Avant d'utiliser la mise en mémoire tampon sur disque, vérifiez le répertoire de travail effectif de rsyslog et créez-le avec les droits d'accès appropriés.

Validez et redémarrez l'expéditeur :

sudo rsyslogd -N1
sudo systemctl restart rsyslog

En cas d'échec de la validation de la configuration, ne redémarrez pas ; corrigez la première erreur signalée. Dans un déploiement rsyslog existant, les directives de certificat globales peuvent affecter d'autres actions TLS. Examinez les autres actions sortantes et utilisez les paramètres de certificat spécifiques à chaque action si elles requièrent des informations d'identification différentes.

5. Vérifier la réception et enquêter sur un échec de poignée de main

Vérifiez d'abord que le collecteur écoute sur le port TCP 6514 et que l'expéditeur peut atteindre l'hôte à travers le pare-feu. Ensuite, exécutez la commande suivante sur l'expéditeur SLES :

logger -t sles-tls-check "TLS forwarding probe"

Sur le collecteur, recherchez le fichier journal distant configuré :

sudo grep 'TLS forwarding probe' /var/log/remote-tls.log
sudo journalctl -u rsyslog -n 50 --no-pager

La présence du marqueur /var/log/remote-tls.logconfirme que le chemin de redirection au niveau de l'application a fonctionné pour ce test. Cela ne prouve pas que tous les fichiers journaux spécifiques à l'application sont collectés. Pour tester l'authentification indépendamment, utilisez temporairement un certificat différent et non approuvé, ou un nom de pair différent, pendant une période de maintenance contrôlée, et vérifiez que la connexion TLS échoue ; rétablissez immédiatement la configuration d'origine.

Si le marqueur n'apparaît pas, suivez la procédure de défaillance dans l'ordre :

• Aucun écouteur ou connexion refusée : vérifiez systemctl status rsyslogles règles du pare-feu TCP/6514 et du collecteur.
• Échec TLS ou de certificat : comparez les SAN du certificat avec PermittedPeeretStreamDriverPermittedPeers ; vérifiez la chaîne CA, les dates d’expiration, les horloges système et les autorisations de clé privée.
• Connexion établie mais aucun événement : vérifiez les entrées de journal/syslog dupliquées ou manquantes, les actions de transfert suspendues et la capacité de la file d’attente du disque. Effectuez cette vérification journalctl -u rsyslogsur les deux hôtes.

Cette méthode suit le guide officiel de journalisation système SLES 15 SP7 , le guide du client rsyslog authentifié par certificat , la documentation de référence du listener imtcp et la documentation de référence du transfert omfwd . L'avis de mise à jour SUSE de mars 2026 documente l'ajout optionnel du module OpenSSL. Les configurations varient selon les Service Packs SLES ; il est donc recommandé de les valider sur votre installation rsyslog avant d'appliquer les modifications en production.