# Secure Logging: Rsyslog mit TLS-Verschlüsselung

TL;DR / Management Summary Standard-Syslog (UDP 514) überträgt Log-Daten im Klartext über das Netzwerk. Ein Angreifer kann diese Daten mitlesen (Sniffing) oder fälschen (Spoofing). In Enterprise-Umgebungen ist Verschlüsselung via TLS Pflicht. Wir nutzen rsyslog mit dem GnuTLS-Modul, um einen verschlüsselten Tunnel zwischen unseren Servern und dem zentralen Log-Host aufzubauen. Das Ziel: Jede Logzeile wird authentifiziert und verschlüsselt übertragen, um die Integrität unserer Audit-Trails zu garantieren.

# 1. Einführung & Architektur

Warum TLS für Logs?

Ohne Verschlüsselung sind Log-Daten ein offenes Buch. TLS bietet:

1. Vertraulichkeit: Niemand kann die Logs auf der Leitung lesen.
2. Integrität: Pakete können nicht unbemerkt verändert werden.
3. Authentizität: Der Log-Server weiß sicher, welcher Host die Daten sendet.

# Der Secure Logging Fluss (Mermaid)

graph LR
    A[Client: SLES / Arch] -->|1. TLS Handshake| B[Server: Central Log Host]
    B -->|2. Verify Cert| A
    A -->|3. Encrypted TCP 6514| B
    B -->|4. Store Securely| C[/var/log/remote/...]
    subgraph "Trust Anchor"
        D[Internal CA] --> A
        D --> B
    end

# 2. Server-Side: Den sicheren Empfänger aufbauen

Das Log-Zentrum.

# Schritt 1: GnuTLS Modul installieren

sudo apt install rsyslog-gnutls # Debian
sudo dnf install rsyslog-gnutls # RHEL

# Schritt 2: Zertifikate hinterlegen

Legen Sie Ihre CA-, Server-Cert und Private-Key Files nach /etc/rsyslog.d/certs/.

# Schritt 3: Konfiguration (/etc/rsyslog.d/tls_server.conf)

# GnuTLS Modul laden
module(load="imtcp" StreamDriver.AuthMode="x509/name" StreamDriver.Mode="1")

# TLS Parameter
$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile /etc/rsyslog.d/certs/ca.pem
$DefaultNetstreamDriverCertFile /etc/rsyslog.d/certs/server-cert.pem
$DefaultNetstreamDriverKeyFile /etc/rsyslog.d/certs/server-key.pem

# Auf Port 6514 (Standard für Syslog-over-TLS) lauschen
input(type="imtcp" port="6514")

# 3. Client-Side: Sicher senden

Die Daten verschlüsseln.

Datei: /etc/rsyslog.d/tls_client.conf

# TLS Parameter
$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile /etc/pki/ca-trust/source/anchors/ca.pem
$ActionSendStreamDriverMode 1
$ActionSendStreamDriverAuthMode x509/name

# Alles verschlüsselt an den Server senden
*.* @@(o)logserver.company.local:6514

• @@: Bedeutet TCP.
• (o): Bedeutet Octet-Counting (stabilerer Stream).

# 4. Day-2 Operations: Firewall & Monitoring

Den Tunnel schützen.

# Firewall anpassen (firewalld)

sudo firewall-cmd --permanent --add-port=6514/tcp
sudo firewall-cmd --reload

# Zertifikats-Monitoring

Überwachen Sie die Gültigkeit der Logging-Zertifikate. Wenn das Zertifikat am Log-Server abläuft, können hunderte Clients keine Logs mehr senden.

# 5. Troubleshooting & “War Stories”

Wenn der Tunnel nicht steht.

# Story 1: “Der hängende Client-Start”

Symptom: Nach Aktivierung von TLS startet der rsyslog-Dienst auf dem Client nicht mehr oder wirft Fehler im 5-Sekunden-Takt. Ursache: Das CA-Zertifikat auf dem Client ist ungültig oder der Hostname des Servers in der Config passt nicht zum Common-Name (CN) im Zertifikat. Lösung: Nutzen Sie rsyslogd -N1 für einen Syntax-Check. Prüfen Sie die Zertifikats-Kette mit openssl verify.

# Story 2: “Log-Verlust bei Netzwerk-Flapping”

Symptom: Bei instabilen VPN-Verbindungen fehlen große Teile der Logs auf dem Server. Ursache: TCP-Verbindungen blockieren bei Ausfall. rsyslog verwirft Daten, wenn der interne Puffer voll ist. Lösung: Nutzen Sie eine Disk-Assisted Queue auf dem Client. So werden Logs lokal auf die SSD geschrieben, wenn der Server nicht erreichbar ist, und später nachgesendet.

# 6. Fazit & Empfehlung

• Standard: Nutzen Sie niemals unverschlüsseltes Logging über Netzwerksegmente hinweg.
• Wahl: Nutzen Sie Port 6514 für TLS-Traffic, um ihn klar vom unsicheren Port 514 zu trennen.
• Wartung: Automatisieren Sie die Zertifikats-Verteilung via Ansible (Artikel 109).

# Anhang: Cheatsheet