Sichere SLES-Syslog-Weiterleitung mit rsyslog und Mutual TLS

Um Systemprotokolle von SUSE Linux Enterprise Server (SLES) sicher weiterzuleiten, konfigurieren Sie rsyslog so, dass Meldungen über den TLS-geschützten TCP-Port 6514 gesendet werden. Überprüfen Sie anschließend den Zertifikatsnamen des Protokollsammlers und bestätigen Sie die Zustellung mit einem Testereignis. SLES 15 SP7 erhielt am 27. März 2026 ein optionales rsyslog-Update, das ein OpenSSL-TLS-Modul hinzufügte. Die untenstehende Konfiguration verwendet gtlsstattdessen bewusst das etablierte GnuTLS-Modul.

Dieses Verfahren beschreibt einen SLES 15-Sender mit dem Namen „sender“ sles01.example.netund einen rsyslog-Collector mit dem Namen „collector“ logs.example.net. Ersetzen Sie beide Namen und alle Zertifikatspfade durch Ihre eigenen Werte. Es wird Mutual TLS verwendet, sodass der Collector sowohl den Sender als auch den Collector authentifiziert.

1. Überprüfen Sie rsyslog und den SLES-Protokollierungspfad

Installieren Sie auf beiden Hosts den rsyslog-Daemon und sein GnuTLS-Modul aus Ihren registrierten SUSE-Repositories. Bestehende Installationen enthalten möglicherweise bereits das erste Paket.

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

Überprüfen Sie /etc/rsyslog.confdie vorhandenen Codeabschnitte, /etc/rsyslog.d/bevor Sie Regeln hinzufügen. Deaktivieren Sie insbesondere alle älteren, unverschlüsselten *.* @@hostWeiterleitungsregeln für dasselbe Ziel; andernfalls könnten Nachrichten zwei Wege nehmen, darunter einen ohne TLS.

SLES verwendet systemd-journaldJournalereignisse, während rsyslog Syslog-Eingaben verarbeitet. Stellen Sie sicher, dass die benötigten Ereignisse rsyslog über die bestehende Eingabekonfiguration erreichen. SUSE dokumentiert ForwardToSyslog=yesdie /etc/systemd/journald.confWeiterleitung von Journal- zu Syslog-Ereignissen; überprüfen Sie Ihre Bereitstellung, bevor Sie Änderungen vornehmen, da die separate Aktivierung von Journallesern zu doppelten Ereignissen führen kann. Dieses Verfahren leitet bereits von rsyslog verarbeitete Meldungen weiter, nicht /var/logautomatisch jede Datei.

2. Vertrauenswürdige Server- und Clientzertifikate vorbereiten

Verwenden Sie eine organisationsweite Zertifizierungsstelle (CA), um ein Zertifikat mit dem DNS-Subjekt-Alternativnamen logs.example.netfür den Sammler und ein separates Zertifikat zur Identifizierung sles01.example.netdes Absenders auszustellen. Stellen Sie sicher, dass die Zertifikate für ihre jeweiligen TLS-Server- oder Client-Rollen gültig sind und dass beide Rechner der ausstellenden CA vertrauen. Befolgen Sie Ihren PKI-Prozess zur Zertifikatserstellung und -erneuerung; verwenden Sie einen privaten Schlüssel nicht auf mehreren Hosts.

Kopieren Sie die entsprechenden Dateien über einen vom Administrator freigegebenen sicheren Kanal. In diesem Beispiel verwenden beide Rechner /etc/rsyslog.d/tls/ca.pem. Der Sammler verfügt zusätzlich über server-cert.pemund server-key.pem; der Sender verfügt über client-cert.pemund 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

Beschränken Sie den Zugriff auf Zertifikate und Schlüssel für die rsyslog-Dienstidentität gegebenenfalls. Geben Sie private Schlüssel nicht in Diagnosedaten, Shell-Verlauf, Git-Repositories oder im exportierten Log-Stream preis. Stellen Sie sicher, dass Ihr rsyslog-Prozess seinen Schlüssel lesen kann, bevor Sie den Daemon neu starten.

3. Aktivieren Sie einen authentifizierten TLS-Empfänger auf dem Collector.

Fügen logs.example.netSie am folgenden Eintrag hinzu /etc/rsyslog.d/30-tls-listener.conf: . Falls imtcpbereits an anderer Stelle geladen, behalten Sie nur eine Modulladeanweisung bei. Das zugehörige Regelwerk speichert extern empfangene Nachrichten in einer separaten Datei, anstatt sie mit lokalen Systemnachrichten zu vermischen.

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"Aktiviert TLS, während Clients ohne gültiges Zertifikat x509/nameabgelehnt PermittedPeerwerden. Der eine zulässige Name ist beabsichtigt; erweitern Sie die Liste der zugelassenen Absender, anstatt die Authentifizierung zu schwächen.

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

Führen Sie die Firewall-Befehle nur aus, wenn der Collector firewalld verwendet. Beschränken Sie eingehende Verbindungen über TCP/6514 mithilfe Ihrer Host- oder Upstream-Firewall auf bekannte Absendernetzwerke; das Öffnen des Ports ersetzt nicht die Zertifikatsauthentifizierung. Stellen Sie außerdem sicher, dass kein bereits vorhandener Klartext-Listener unbeabsichtigt offengelegt wurde.

4. Fügen Sie SLES TLS-Weiterleitung und eine begrenzte Warteschlange hinzu.

Stellen Sie sles01.example.netsicher, dass das Arbeitsverzeichnis von rsyslog existiert und vom Dienst beschreibbar ist. Das hier gezeigte Verzeichnis dient nur der Veranschaulichung; behalten Sie ein bereits konfiguriertes Verzeichnis bei, workDirectoryfalls Ihre Installationspakete eines bereitstellen. Fügen Sie diesen Codeausschnitt wie folgt hinzu /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"
)

Die TLS-Einstellungen authentifizieren den Collector vor dem Senden. Die festplattengestützte Aktionswarteschlange puffert Nachrichten bei kurzen Ausfällen und wiederholt fehlgeschlagene Weiterleitungen. Sie ist jedoch nicht unbegrenzt und bietet keine Garantie gegen Nachrichtenverlust: Verfügbarer Speicherplatz, Warteschlangenlimits, das Verhalten beim Beenden von Prozessen und der Zustand des Empfängers spielen weiterhin eine Rolle. Überprüfen Sie das effektive Arbeitsverzeichnis von rsyslog und erstellen Sie es mit den entsprechenden Berechtigungen, bevor Sie sich auf die Festplattenpufferung verlassen.

Sender prüfen und neu starten:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Schlägt die Konfigurationsprüfung fehl, starten Sie das System nicht neu, sondern beheben Sie den ersten gemeldeten Fehler. In einer bestehenden rsyslog-Bereitstellung können globale Zertifikatsanweisungen andere TLS-Aktionen beeinträchtigen. Überprüfen Sie andere ausgehende Aktionen und verwenden Sie die unterstützten aktionsspezifischen Zertifikatsparameter, falls diese unterschiedliche Anmeldeinformationen erfordern.

5. Empfangsbestätigung prüfen und fehlgeschlagenen Handshake untersuchen.

Prüfen Sie zunächst, ob der Collector auf TCP/6514 lauscht und ob der Sender den Host durch die Firewall erreichen kann. Führen Sie anschließend den folgenden Befehl auf dem SLES-Sender aus:

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

Suchen Sie auf dem Collector die konfigurierte Remote-Protokolldatei:

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

Das Auffinden des Markers /var/log/remote-tls.logbestätigt, dass der Weiterleitungspfad auf Anwendungsebene für diesen Test funktioniert hat. Es beweist jedoch nicht, dass alle anwendungsspezifischen Protokolldateien erfasst werden. Um die Authentifizierung unabhängig zu testen, verwenden Sie vorübergehend in einem kontrollierten Wartungsfenster ein anderes, nicht vertrauenswürdiges Zertifikat oder einen nicht übereinstimmenden Peer-Namen und überprüfen Sie, ob die TLS-Verbindung fehlschlägt. Stellen Sie anschließend umgehend die ursprüngliche Konfiguration wieder her.

Falls die Markierung nicht erscheint, gehen Sie der Fehlerbehandlung in der angegebenen Reihenfolge nach:

• Kein Listener oder verweigerte Verbindung: Überprüfen Sie systemctl status rsyslogTCP/6514 und die Firewall-Regeln des Collectors.
• TLS- oder Zertifikatsfehler: Vergleichen Sie die Zertifikats-SANs mit PermittedPeerund StreamDriverPermittedPeers; überprüfen Sie die CA-Kette, die Ablaufdaten, die Systemuhren und die Berechtigungen für den privaten Schlüssel.
• Verbindung besteht, aber keine Ereignisse: Prüfen Sie auf doppelte oder fehlende Journal-/Syslog-Einträge, angehaltene Weiterleitungsaktionen und die Festplattenwarteschlangenkapazität. Überprüfen Sie dies journalctl -u rsyslogauf beiden Hosts.

Die Methode folgt dem offiziellen SLES 15 SP7-Systemprotokollierungsleitfaden , dem Leitfaden für rsyslog-Zertifikat-authentifizierte Clients , der imtcp-Listener-Referenz und der omfwd-Weiterleitungsreferenz . Die SUSE-Update-Mitteilung vom März 2026 dokumentiert die optionale Hinzufügung des OpenSSL-Moduls. Da die Konfigurationen je nach SLES-Service-Pack variieren, sollten Sie die Einstellungen in Ihrer installierten rsyslog-Version überprüfen, bevor Sie Änderungen in der Produktionsumgebung anwenden.