TLS für die rsyslog-Weiterleitung mit dem gtls-Treiber und wann sich RELP zusätzlich lohnt

Worum es geht

Das TLS-Tutorial von rsyslog beschreibt Network Stream Driver für den verschlüsselten Syslog-Transport: gtls (GnuTLS) und seit rsyslog 8.36 ossl (OpenSSL). Beide verwenden dieselben Parameter für Modus und Authentifizierungsmodus. Für eine minimale Konfiguration braucht es auf beiden Seiten ein CA-Zertifikat sowie auf Sender und Empfänger je ein Zertifikat mit Schlüssel. Die Ablage richtet sich nach der TLS Certificate Summary von rsyslog, die das für jede Rolle nötige X.509-Material beschreibt. Die CA-Datei wird global gesetzt (global(DefaultNetstreamDriverCAFile=...), dazu DefaultNetstreamDriverCertFile/KeyFile). Auf der Senderseite wird eine omfwd-Action um StreamDriver="gtls" und StreamDriverMode="1" (nur TLS) ergänzt, ausserdem um StreamDriverAuthMode. Dafür kommt entweder x509/name in Frage (Zertifikatsprüfung plus Abgleich des Namens der Gegenstelle mit StreamDriverPermittedPeers="collector.example.org") oder x509/certvalid (jedes von der vertrauenswürdigen CA signierte Zertifikat wird akzeptiert; die Treiberdokumentation bezeichnet dies als schwach und nicht empfehlenswert).

RELP (Reliable Event Logging Protocol) ist ein eigenständiger Transport, den die Module omrelp/imrelp bereitstellen; die rsyslog-Dokumentation beschreibt sie als RELP-Ausgabe- und -Eingabemodule. Anders als reines omfwd über TCP oder TLS bestätigt RELP jede Nachricht auf Anwendungsebene. Der Sender weiss dadurch, dass der Empfänger eine Nachricht tatsächlich verarbeitet und nicht bloss der TCP-Stack sie entgegengenommen hat.

Warum es wichtig ist

Ein erfolgreicher Versand über reines TCP bedeutet nur, dass die Bytes an den Netzwerk-Stack übergeben wurden. Stürzt rsyslog auf dem Collector kurz nach dem Verbindungsaufbau ab oder läuft die Festplatte voll, können bereits «gesendete» Nachrichten verloren gehen, ohne dass der Sender davon erfährt. TLS über TCP übernimmt diese Eigenschaft: Verschlüsselung betrifft Vertraulichkeit und Authentifizierung, nicht die Zustellsemantik. RELP wurde gezielt dafür entworfen, diese Lücke zu schliessen.

So wird es angewendet

• TLS immer dann einsetzen, wenn Log-Verkehr ein Netz durchquert, das nicht vollständig unter eigener Kontrolle steht, auch innerhalb eines Rechenzentrums. StreamDriverAuthMode="x509/name" mit StreamDriverPermittedPeers, das den Collector benennt, bevorzugen und x509/certvalid nur als Notlösung betrachten.
• TLS mit omrelp/imrelp kombinieren (RELP kann selbst über TLS laufen), wenn Nachrichtenverluste bei einem Ausfall des Empfängers nicht hinnehmbar sind, etwa bei Audit-Logs oder Compliance-relevanten Ereignissen, und die zusätzliche Komplexität eines weiteren Modulpaars auf beiden Seiten vertretbar ist.
• Für alltägliche Anwendungs- oder System-Logs, bei denen gelegentlich eine verlorene Nachricht während eines Absturzes verkraftbar ist, genügt in der Regel reines TLS über TCP mit einer Disk-Assisted Queue auf dem Sender.
• Den Ablauf der Zertifikate überwachen: Seit rsyslog 8.2012.0 ist StreamDriver.PermitExpiredCerts standardmässig off. Ein abgelaufenes Zertifikat lässt daher den TLS-Handshake scheitern; die Weiterleitung stoppt (Fehler erscheinen im eigenen Log von rsyslog) und die Nachrichten stauen sich in der Queue.

Stolpersteine

• StreamDriverAuthMode nicht setzen (der Standardwert in omfwd hängt vom Treiber ab) oder anon verwenden: Laut Treiberdokumentation wird die Gegenstelle dabei nicht authentifiziert, was Man-in-the-Middle-Angriffe ermöglicht.
• Annehmen, TLS allein garantiere die Zustellung. Das tut es nicht; RELP ist die dokumentierte Lösung für genau diese Lücke.
• Übersehen, dass RELP einen eigenen Port und eine eigene Firewall-Regel benötigt, getrennt vom Port für reines Syslog über TCP/TLS.