So exportieren Sie SLES-Systemprotokolle sicher an einen Remote-Syslog-Server

Die sicherste und praktischste Methode, Systemprotokolle von SUSE Linux Enterprise Server (SLES) an einen entfernten Syslog-Collector zu exportieren, ist die Verwendung von rsyslog über TCP mit TLS, die Validierung des Collector-Zertifikats anhand des Namens und die Zuweisung einer eigenen Warteschlange für die Weiterleitung. Einfaches UDP-Syslog ist zwar unkompliziert, bietet aber weder Vertraulichkeit noch Peer-Authentifizierung. Einfaches TCP verbessert zwar das Übertragungsverhalten, lässt die Protokollinhalte jedoch während der Übertragung weiterhin ungeschützt.

Diese Anleitung verwendet den GnuTLS-Netzwerkstreamtreiber gtlsund die moderne rsyslog-Aktionssyntax. Das Verfahren richtet sich an SLES 15 SP7-Systeme, deren Administrationshandbuch am 1. Oktober 2026 aktualisiert wurde. Überprüfen Sie vor dem unveränderten Kopieren einer Konfiguration immer die genauen Pakete und die rsyslog-Version auf Ihrem Host. Die offizielle rsyslog-Dokumentation empfiehlt für moderne Bereitstellungen TCP mit TLS und eine Aktionswarteschlange für die TCP-Weiterleitung.

Zulässige Referenzen: SUSE Linux Enterprise Server 15 SP7 Dokumentation , rsyslog omfwd Dokumentation , rsyslog TLS Client Setup und RFC 5425: TLS Transport Mapping für Syslog .

Kurzübersicht

Bevor Sie die Weiterleitung konfigurieren

Sie benötigen den vollqualifizierten Domänennamen des Remote-Collectors, den TCP-Port, an dem er lauscht, und das Zertifikat der Zertifizierungsstelle (CA), die das Collector-Zertifikat signiert hat. Für Mutual TLS benötigen Sie außerdem ein Client-Zertifikat und einen privaten Schlüssel für den SLES-Rechner. Das Collector-Zertifikat muss für den in rsyslog konfigurierten Hostnamen gültig sein, idealerweise über einen Subject Alternative Name (SAN). Beheben Sie Namenskonflikte nicht durch Deaktivieren der Zertifikatsprüfung.

Der Remote-Collector muss bereits für die Annahme von TLS-Syslog konfiguriert sein. Dieser Artikel konzentriert sich auf den SLES-Sender, da die Empfängerkonfiguration je nach rsyslog, syslog-ng, SIEM-Appliances und verwalteten Protokollierungsdiensten variiert. Wenn die Systeme durch eine Firewall getrennt sind, muss der SLES-Host TCP-Verbindungen zum Collector über den konfigurierten Port initiieren können. Eine standardmäßige zustandsbehaftete Firewalld-Richtlinie erfordert in der Regel keine Öffnung eines eingehenden Ports auf dem SLES-Sender.

Schritt 1: Prüfen Sie, ob rsyslog installiert ist und ermitteln Sie die aktuelle Build-Version.

Prüfen Sie zunächst die Paket- und Daemon-Version. Dadurch vermeiden Sie Verwirrung, wenn ältere Beispiele Direktiven verwenden, die von der auf Ihrem Server installierten Version nicht unterstützt werden.

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

Falls rsyslog nicht installiert ist, installieren Sie es aus den aktivierten SLES-Repositories. Halten Sie das System über Ihren regulären SUSE-Updateprozess auf dem neuesten Stand, bevor Sie eine dauerhafte Protokollierungsverbindung herstellen.

Schritt 2: Installieren Sie das GnuTLS rsyslog-Modul

Unter SLES ist der TLS-Netzwerktreiber separat verpackt. Installieren Sie das GnuTLS-Modul und lassen Sie das Basispaket rsyslog weiterhin vorhanden.

sudo zypper install rsyslog rsyslog-module-gtls

Sie können mit überprüfen, ob die Dateien aus dem erwarteten Paket stammen rpm -ql rsyslog-module-gtls. Paketnamen sind distributionsspezifisch, kopieren Sie daher keine Paketnamen aus Debian- oder RHEL-orientierten Anleitungen.

Schritt 3: CA- und Client-Anmeldeinformationen sicher aufbewahren

Verwenden Sie Zertifikate, die von Ihrer Organisation oder Ihrer Protokollierungsplattform ausgestellt wurden. Vermeiden Sie in einem Produktivsystem die Erstellung einer neuen privaten Zertifizierungsstelle (CA) auf dem Host, der die Protokolle sendet. In einer Testumgebung kann eine Test-CA verwendet werden, aber für vertrauenswürdige Materialien im Produktivbetrieb muss der PKI-Prozess Ihrer Organisation eingehalten werden.

Erstellen Sie ein Verzeichnis im Besitz des Root-Benutzers, kopieren Sie die Dateien hinein und beschränken Sie den privaten Schlüssel. Ersetzen Sie die Beispieldateinamen durch die Pfade, die Ihnen Ihr PKI-Team bereitgestellt hat:

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/*

Prüfen Sie das Zertifizierungsstellen- und Clientzertifikat, anstatt Dateinamen zu vertrauen:

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

Die Dokumentation des rsyslog-TLS-Clients weist ausdrücklich darauf hin, dass der private Schlüssel des Rechners geschützt werden muss. Wenn ein anderer Benutzer den privaten Schlüssel lesen kann, könnte er sich möglicherweise als der Protokollierungsclient ausgeben.

Schritt 4: TLS-Weiterleitung mit Servernamensprüfung konfigurieren

Erstellen Sie eine dedizierte Drop-in-Instanz, z. B. /etc/rsyslog.d/60-remote-tls.conf. Die Trennung der Remote-Weiterleitung von der Herstellerkonfiguration vereinfacht die Überprüfung und das Rollback.

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"Wichtig ist: Die alleinige Auswahl eines TLS-fähigen Treibers reicht bei Konfigurationen, in denen der Modus standardmäßig auf unverschlüsseltes TCP eingestellt ist, nicht aus. StreamDriverAuthMode="x509/name"Anschließend wird das Remote-Zertifikat überprüft und sichergestellt, dass die Serveridentität mit dem zulässigen Peer übereinstimmt. Verwenden Sie nach Möglichkeit den exakten Collector-Namen aus dem Zertifikat anstelle eines allgemeinen Platzhalters.

Die obige Aktion leitet jede eingehende Nachricht weiter. Um nur bestimmte Funktionen oder Prioritäten zu berücksichtigen, fügen Sie vor der Aktion einen Filter hinzu. Beispielsweise kann eine sicherheitsorientierte Umgebung Authentifizierungs- und Daemon-Ereignisse weiterleiten, während umfangreiche Anwendungs-Debug-Protokolle lokal gespeichert werden. Die Filterung sollte sich an Aufbewahrungs-, Incident-Response- und Compliance-Anforderungen orientieren und nicht an der pauschalen Annahme, dass jede Nachricht den Host verlassen muss.

Schritt 5: Validieren, neu starten, ein Testereignis senden und die Zustellung prüfen.

Überprüfen Sie die vollständige rsyslog-Konfiguration, bevor Sie den Dienst neu starten. Dies ist der schnellste Weg, Syntaxfehler und fehlende Modulverweise zu erkennen:

sudo rsyslogd -N1

Wenn die Validierung erfolgreich ist, starten Sie rsyslog neu und senden Sie eine eindeutige Testnachricht:

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

Suchen Sie auf dem Collector nach dem Tag sles-tls-testund dem Hostnamen des Absenders. Ein erfolgreiches Remote-Erscheinen beweist zwar, dass die Nachricht den Collector erreicht hat, aber nicht automatisch, dass die Zertifikatsprüfung korrekt konfiguriert wurde. Eine zuverlässigere Prüfung besteht darin, die Zertifikatsprüfung x509/nameaktiviert zu lassen und sicherzustellen, dass im rsyslog-Dienstprotokoll keine TLS-Handshake- oder Peer-Name-Fehler auftreten.

Falls die Verbindung fehlschlägt, testen Sie die DNS-Auflösung logs.example.com, prüfen Sie die Erreichbarkeit von TCP-Port 6514, überprüfen Sie die Gültigkeitsdaten der Zertifikate und stellen Sie sicher, dass das Collector-Zertifikat den erwarteten DNS-Namen enthält. Vergewissern Sie sich außerdem, dass der Collector der Zertifizierungsstelle vertraut, die das SLES-Clientzertifikat ausgestellt hat, wenn Mutual TLS aktiviert ist.

Checkliste zur Fehlerbehebung

• Verbindung abgelehnt: Der Collector lauscht nicht an der konfigurierten Adresse/dem konfigurierten Port oder eine Firewall blockiert die Verbindung.
• Zeitüberschreitung: Routing, Netzwerk-ACLs oder eine Firewall verwerfen stillschweigend den Datenverkehr.
• Die Zertifikatsprüfung ist fehlgeschlagen: Die CA-Datei ist falsch, unvollständig oder abgelaufen, oder die Serverzertifikatskette ist unvollständig.
• Namenskonflikt beim Peer: Der Name target/ StreamDriverPermittedPeersstimmt nicht mit der Identität des Sammlerzertifikats überein.
• Zugriff auf den Schlüssel verweigert: Der Schlüsselpfad oder die Berechtigungen erlauben dem rsyslog-Prozess unter der SLES-Dienstkonfiguration nicht, die Datei zu lesen.
• Bei einem Ausfall werden keine Nachrichten mehr zugestellt: Überprüfen Sie die Konzeption und Kapazität der Aktionswarteschlange. Die zugehörige Dokumentation von omfwd empfiehlt ausdrücklich die Verwendung einer Warteschlange für die TCP-Weiterleitung, damit ein nicht verfügbares Ziel die normale Verarbeitung nicht blockiert.

Sicherheitshinweise, die man leicht übersehen kann

Ersetzen Sie die Zertifikatsvalidierung nicht durch anonymes TLS, es sei denn, Sie verstehen die damit verbundenen Nachteile vollständig. Verschlüsselung ohne Serverauthentifizierung kann Protokolle weiterhin einem aktiven Man-in-the-Middle-Angreifer zugänglich machen. Öffnen Sie außerdem nicht den eingehenden TCP-Port 6514 auf dem SLES-Sender, nur weil das Ziel diesen Port verwendet; die Weiterleitung ist eine ausgehende Client-Verbindung.

Schützen Sie die privaten Schlüssel Ihrer Clients als Anmeldeinformationen, rotieren Sie Zertifikate vor deren Ablauf und verwenden Sie einen Collector-Hostnamen, der auch bei IP-Adressänderungen stabil bleibt. Falls Sie stärkere Zustellungsgarantien als die normale TCP/TLS-Weiterleitung benötigen, verweist die rsyslog-Dokumentation auf RELP als Alternative mit Empfangsbestätigung. Dies ist eine separate Designentscheidung, die unabhängig von der Transportverschlüsselung ist.

Abschließende Überprüfung

Eine korrekte Bereitstellung sollte vier beobachtbare Bedingungen erfüllen: Die Validierung der rsyslog-Konfiguration ist erfolgreich, der Dienst bleibt nach einem Neustart aktiv, der Collector empfängt das eindeutige Testereignis und das Senderprotokoll weist keine TLS-Vertrauens- oder Peer-Namensfehler auf. Sobald diese Prüfungen erfolgreich abgeschlossen sind, dokumentieren Sie die Ablaufdaten der Zertifikate und die Abhängigkeit vom Remote-Collector, damit zukünftige Wartungsarbeiten die zentrale Protokollierung nicht unbemerkt beeinträchtigen.