TLS pour le transfert rsyslog avec le pilote gtls, et quand l'ajout de RELP en vaut la peine

Ce que c'est

Le tutoriel TLS de rsyslog décrit des pilotes de flux réseau (network stream drivers) pour le transport chiffré de syslog : gtls (GnuTLS) et, depuis rsyslog 8.36, ossl (OpenSSL), qui acceptent les mêmes paramètres de mode et de mode d'authentification. Une configuration minimale requiert un certificat d'autorité de certification (CA) des deux côtés, ainsi qu'un certificat et une clé sur l'émetteur et sur le récepteur, organisés comme dans le TLS Certificate Summary de rsyslog, qui détaille le matériel X.509 nécessaire à chaque rôle. Le fichier de CA se définit globalement (global(DefaultNetstreamDriverCAFile=...), avec DefaultNetstreamDriverCertFile/KeyFile). Côté émetteur, une action omfwd est complétée par StreamDriver="gtls", StreamDriverMode="1" (TLS uniquement) et StreamDriverAuthMode réglé sur x509/name (validation du certificat et vérification du nom du pair par rapport à StreamDriverPermittedPeers="collector.example.org") ou sur x509/certvalid (tout certificat signé par la CA de confiance, mode que la documentation du pilote qualifie de faible et déconseille).

RELP (Reliable Event Logging Protocol) est un transport distinct, fourni par les modules omrelp/imrelp, décrits dans la documentation de rsyslog comme les modules de sortie et d'entrée RELP. Contrairement à un simple omfwd sur TCP ou TLS, RELP acquitte chaque message au niveau applicatif : l'émetteur sait ainsi que le message a bien été traité par le récepteur, et pas seulement accepté par la pile TCP.

Pourquoi c'est important

Un envoi réussi sur TCP simple signifie seulement que les octets ont été remis à la pile réseau ; si rsyslog plante sur le collecteur ou si le disque se remplit juste après l'acceptation de la connexion, des messages déjà « envoyés » peuvent être perdus sans que l'émetteur en soit informé. Le TLS sur TCP hérite de cette propriété : le chiffrement agit sur la confidentialité et l'authentification, pas sur la sémantique de livraison. RELP a été conçu précisément pour supprimer cette lacune.

Comment l'appliquer

• Utilisez TLS dès que le trafic de journaux traverse un réseau que vous ne maîtrisez pas entièrement, même au sein d'un datacenter ; privilégiez StreamDriverAuthMode="x509/name" avec StreamDriverPermittedPeers désignant le collecteur, et ne considérez x509/certvalid que comme solution de repli.
• Associez TLS à omrelp/imrelp (RELP peut lui-même fonctionner sur TLS) lorsque la perte de messages pendant une panne du récepteur est inacceptable — journaux d'audit, événements pertinents pour la conformité — et que la complexité supplémentaire d'une paire de modules en plus de chaque côté est acceptable.
• Pour les journaux courants d'applications ou du système, où la perte occasionnelle d'un message lors d'un plantage est tolérable, le TLS simple sur TCP avec une file d'attente assistée par disque (disk-assisted queue) sur l'émetteur suffit généralement.
• Surveillez l'expiration des certificats : depuis rsyslog 8.2012.0, StreamDriver.PermitExpiredCerts vaut off par défaut, si bien qu'un certificat expiré fait échouer la négociation TLS ; le transfert s'arrête (des erreurs apparaissent dans le journal propre de rsyslog) et les messages s'accumulent dans la file d'attente.

Pièges

• Laisser StreamDriverAuthMode non défini (sa valeur par défaut dans omfwd dépend du pilote) ou utiliser anon, qui, selon la documentation du pilote, n'authentifie pas le pair et reste exposé aux attaques de l'homme du milieu.
• Supposer que TLS seul garantit la livraison ; ce n'est pas le cas, et RELP est la réponse documentée à cette lacune précise.
• Oublier que RELP nécessite son propre port et sa propre règle de pare-feu, distincts de ceux utilisés pour le syslog TCP/TLS simple.