Comment exporter en toute sécurité les journaux système SLES vers un serveur Syslog distant

La méthode la plus sûre et pratique pour exporter les journaux système de SUSE Linux Enterprise Server (SLES) vers un collecteur syslog distant consiste à utiliser rsyslog via TCP avec TLS, à valider le certificat du collecteur par son nom et à allouer une file d'attente dédiée au transfert. L'utilisation de syslog UDP simple est simple, mais ne garantit ni la confidentialité ni l'authentification des pairs. Le protocole TCP simple améliore la rapidité de la distribution, mais expose néanmoins le contenu des journaux pendant leur transmission.

Ce guide utilise le pilote de flux réseau GnuTLS gtlset la syntaxe moderne des actions rsyslog. La procédure est destinée aux systèmes SLES 15 SP7, dont le guide d'administration a été mis à jour le 1er octobre 2026. Vérifiez toujours la version exacte des paquets et de rsyslog sur votre système avant de copier une configuration à l'identique. La documentation officielle de rsyslog recommande l'utilisation de TCP avec TLS pour les déploiements modernes et préconise une file d'attente d'actions pour le transfert TCP.

Références faisant autorité : documentation de SUSE Linux Enterprise Server 15 SP7 , documentation de rsyslog omfwd , configuration du client TLS rsyslog et RFC 5425 : mappage de transport TLS pour Syslog .

Guide de référence rapide

Avant de configurer le transfert

Vous avez besoin du nom de domaine complet du collecteur distant, du port TCP sur lequel il écoute et du certificat de l'autorité de certification (CA) qui signe le certificat du collecteur. Pour une authentification TLS mutuelle, vous avez également besoin d'un certificat client et d'une clé privée pour la machine SLES. Le certificat du collecteur doit être valide pour le nom d'hôte configuré dans rsyslog, de préférence via un nom alternatif de sujet (SAN). Ne résolvez pas une incompatibilité de nom en désactivant la vérification du certificat.

Le collecteur distant doit être configuré pour accepter les flux syslog TLS. Cet article se concentre sur l'émetteur SLES, car la configuration du récepteur varie selon les systèmes (rsyslog, syslog-ng, appliances SIEM, services de journalisation gérés, etc.). Si un pare-feu sépare les systèmes, autorisez l'hôte SLES à initier des connexions TCP vers le collecteur sur le port configuré. Une politique firewalld par défaut avec état ne requiert généralement pas l'ouverture d'un port entrant sur l'émetteur SLES.

Étape 1 : Vérifiez que rsyslog est installé et identifiez la version actuelle.

Commencez par vérifier la version du paquet et du démon. Cela évite toute confusion lorsque d'anciens exemples utilisent des directives non prises en charge par la version installée sur votre serveur.

rpm -q rsyslog
rsyslogd -v
systemctl status rsyslog --no-pager

Si rsyslog n'est pas installé, installez-le depuis vos dépôts SLES activés. Veillez à maintenir votre système à jour via la procédure de mise à jour SUSE habituelle avant d'établir une connexion de journalisation permanente.

Étape 2 : Installez le module rsyslog de GnuTLS

Sous SLES, le pilote réseau TLS est fourni séparément. Installez le module GnuTLS et conservez le paquet rsyslog de base :

sudo zypper install rsyslog rsyslog-module-gtls

Vous pouvez vérifier que les fichiers proviennent bien du paquet attendu avec rpm -ql rsyslog-module-gtls. Les noms de paquets étant spécifiques à chaque distribution, ne copiez pas les noms de paquets provenant de guides destinés à Debian ou RHEL.

Étape 3 : Mettez en lieu sûr les identifiants de l’autorité de certification et du client.

Utilisez les certificats émis par votre organisation ou votre plateforme de journalisation. Pour un système de production, évitez de créer une nouvelle autorité de certification privée sur le serveur d'envoi des journaux. Un environnement de laboratoire peut utiliser une autorité de certification de test, mais les certificats de confiance en production doivent respecter le processus PKI de votre organisation.

Créez un répertoire appartenant à l'utilisateur root, copiez-y les fichiers et restreignez l'accès à la clé privée. Remplacez les noms de fichiers d'exemple par les chemins d'accès fournis par votre équipe PKI :

sudo install -d -m 0755 /etc/rsyslog.d/certs
sudo install -m 0644 ca.pem /etc/rsyslog.d/certs/ca.pem
sudo install -m 0644 sles-client.crt /etc/rsyslog.d/certs/sles-client.crt
sudo install -m 0600 sles-client.key /etc/rsyslog.d/certs/sles-client.key
sudo chown root:root /etc/rsyslog.d/certs/*

Examinez le certificat de l'autorité de certification et le certificat client plutôt que de vous fier aux noms de fichiers :

openssl x509 -in /etc/rsyslog.d/certs/ca.pem -noout -subject -issuer
openssl x509 -in /etc/rsyslog.d/certs/sles-client.crt -noout -subject -issuer -dates

La documentation du client TLS rsyslog indique clairement que la clé privée de la machine doit être protégée. Si un autre utilisateur parvient à lire cette clé, il pourrait usurper l'identité du client de journalisation.

Étape 4 : Configurer le transfert TLS avec vérification du nom du serveur

Créez un dossier dédié, par exemple : /etc/rsyslog.d/60-remote-tls.conf. Le fait de séparer le transfert distant de la configuration du fournisseur facilite la vérification et la restauration.

global(
    DefaultNetstreamDriver="gtls"
    DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca.pem"
    DefaultNetstreamDriverCertFile="/etc/rsyslog.d/certs/sles-client.crt"
    DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/certs/sles-client.key"
)

action(
    type="omfwd"
    target="logs.example.com"
    port="6514"
    protocol="tcp"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.com"
    queue.type="linkedList"
)

StreamDriverMode="1"Il est important de noter que le choix d'un pilote compatible TLS ne suffit pas sur les configurations où le mode par défaut est TCP. Le StreamDriverAuthMode="x509/name"système vérifie ensuite le certificat distant et s'assure que l'identité du serveur correspond à celle du pair autorisé. Dans la mesure du possible, utilisez le nom exact du collecteur figurant dans le certificat plutôt qu'un caractère générique.

L'action ci-dessus transfère tous les messages qui la reçoivent. Si vous souhaitez uniquement transférer certains services ou priorités, ajoutez un filtre avant l'action. Par exemple, dans un environnement axé sur la sécurité, les événements d'authentification et de processus peuvent être transférés, tandis que les journaux de débogage des applications volumineuses peuvent être conservés localement. Le filtrage doit être guidé par les besoins de conservation, de réponse aux incidents et de conformité, et non par l'hypothèse systématique que chaque message doit quitter l'hôte.

Étape 5 : Valider, redémarrer, envoyer un événement de test et vérifier la livraison

Vérifiez la configuration complète de rsyslog avant de redémarrer le service. C'est le moyen le plus rapide de détecter les erreurs de syntaxe et les références de modules manquantes :

sudo rsyslogd -N1

Si la validation réussit, redémarrez rsyslog et envoyez un message de test unique :

sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager
logger -t sles-tls-test "remote syslog TLS test $(date -Is)"
sudo journalctl -u rsyslog -n 50 --no-pager

Sur le collecteur, recherchez l'étiquette sles-tls-testet le nom d'hôte de l'expéditeur. La réception réussie du message par le collecteur ne prouve pas à elle seule que la vérification du certificat a été correctement configurée. Pour une vérification plus fiable, il est recommandé de maintenir la vérification x509/nameactivée et de s'assurer qu'aucune erreur de négociation TLS ou de nom de pair n'est consignée dans le journal du service rsyslog.

En cas d'échec de la connexion, testez la résolution DNS logs.example.com, vérifiez que le port TCP 6514 est accessible, contrôlez la validité des certificats et assurez-vous que le certificat du collecteur contient le nom DNS attendu. Vérifiez également que le collecteur fait confiance à l'autorité de certification ayant émis le certificat client SLES lorsque le protocole TLS mutuel est activé.

Liste de vérification pour le dépannage

• Connexion refusée : le collecteur n’écoute pas sur l’adresse/le port configuré ou un pare-feu bloque la connexion.
• Délai d'attente dépassé : le routage, les listes de contrôle d'accès réseau ou un pare-feu bloquent silencieusement le trafic.
• Échec de la vérification du certificat : le fichier d’autorité de certification est incorrect, incomplet, expiré ou la chaîne de certificats du serveur est incomplète.
• Incohérence du nom du pair : le nom target/ StreamDriverPermittedPeersne correspond pas à l’identité du certificat du collecteur.
• Autorisation refusée sur la clé : le chemin d’accès ou les autorisations de la clé ne permettent pas au processus rsyslog de lire le fichier dans la configuration du service SLES.
• En cas de panne, les messages sont interrompus : vérifiez la conception et la capacité de la file d’attente des actions. La documentation omfwd en amont recommande spécifiquement une file d’attente pour le transfert TCP afin qu’une destination indisponible n’empêche pas le traitement normal.

Des consignes de sécurité faciles à manquer

Ne remplacez pas la validation des certificats par TLS anonyme à moins d'en comprendre parfaitement les risques. Le chiffrement sans authentification du serveur peut toujours exposer les journaux à une attaque de type « homme du milieu ». De même, n'ouvrez pas le port TCP 6514 entrant sur l'expéditeur SLES simplement parce que la destination utilise ce port ; le transfert de trafic constitue une connexion client sortante.

Protégez les clés privées des clients comme identifiants, renouvelez les certificats avant leur expiration et utilisez un nom d'hôte de collecteur stable malgré les changements d'adresse IP. Si vous avez besoin de garanties de livraison plus robustes que le protocole TCP/TLS classique, la documentation rsyslog recommande RELP comme alternative avec accusé de réception. Il s'agit d'un choix de conception distinct du chiffrement du transport.

Vérification finale

Un déploiement correct doit satisfaire quatre conditions observables : la validation de la configuration rsyslog doit être réussie, le service doit rester actif après redémarrage, le collecteur doit recevoir l’événement de test unique et le journal de l’expéditeur ne doit présenter aucune erreur de confiance TLS ni d’erreur de nom de pair. Une fois ces vérifications effectuées, documentez les dates d’expiration des certificats et la dépendance au collecteur distant afin que les opérations de maintenance ultérieures n’interrompent pas silencieusement la journalisation centralisée.