Syslog

Syslog ist ein standardisiertes Protokoll zur Übertragung von Log-Nachrichten in IP-Netzwerken. Es ermöglicht Betriebssystemen, Netzwerkgeräten und Anwendungen, ihre Ereignismeldungen zentral zu sammeln und auszuwerten. Das Protokoll wurde ursprünglich in den 1980er Jahren für das BSD-Unix-System entwickelt und ist heute in RFC 5424 standardisiert.

In modernen IT-Infrastrukturen ist Syslog unverzichtbar für die Überwachung, Fehleranalyse und Sicherheitsüberwachung. Server, Router, Switches, Firewalls und Anwendungen senden ihre Log-Nachrichten über Syslog an einen zentralen Log-Server. Dort werden sie gespeichert, analysiert und können bei Problemen oder Sicherheitsvorfällen ausgewertet werden.

Geschichte und Entwicklung

Syslog wurde in den frühen 1980er Jahren von Eric Allman als Teil des Sendmail-Projekts entwickelt. Ursprünglich war es nur für die Protokollierung von E-Mail-Servern gedacht, doch schnell erkannten Entwickler den Nutzen eines einheitlichen Logging-Mechanismus. Das Protokoll verbreitete sich rasch in der Unix-Welt und wurde zum De-facto-Standard für System-Logging.

Lange Zeit existierte keine offizielle Spezifikation. Erst 2001 dokumentierte RFC 3164 das bestehende Verhalten (BSD Syslog). Da diese Version einige Schwächen aufwies, wurde 2009 mit RFC 5424 ein komplett überarbeiteter Standard veröffentlicht. Dieser führte ein strukturiertes Nachrichtenformat, UTF-8-Unterstützung und verbesserte Zeitstempel ein.

Funktionsweise von Syslog

Das Syslog-Protokoll basiert auf einer einfachen Client-Server-Architektur. Geräte und Anwendungen (Originatoren) generieren Log-Nachrichten und senden sie an einen Syslog-Server (Collector). Optional können Relays dazwischengeschaltet werden, die Nachrichten empfangen und weiterleiten.

Die Übertragung erfolgt standardmäßig über UDP auf Port 514. Da UDP keine Zustellgarantie bietet, können bei Netzwerkproblemen Nachrichten verloren gehen. Für zuverlässige Übertragung wird TCP verwendet. Bei erhöhten Sicherheitsanforderungen kommt TLS-Verschlüsselung zum Einsatz (Port 6514).

Rollen im Syslog-System

RFC 5424 definiert drei Rollen für Syslog-Teilnehmer. Der Originator erzeugt die Log-Nachricht, etwa ein Linux-Server oder ein Netzwerkgerät. Der Collector empfängt und speichert die Nachrichten. Relays fungieren als Zwischenstationen und leiten Nachrichten weiter, etwa um Nachrichten aus verschiedenen Netzwerksegmenten zu bündeln.

• Originator: Erzeugt Log-Nachrichten (Server, Router, Anwendungen)
• Relay: Empfängt und leitet Nachrichten weiter
• Collector: Endpunkt, der Nachrichten speichert und auswertet

Aufbau einer Syslog-Nachricht

Eine Syslog-Nachricht nach RFC 5424 besteht aus einem Header mit Metadaten und einem optionalen Nachrichtentext. Der Header enthält wichtige Informationen wie Priorität, Zeitstempel, Hostname und Prozess-ID. Das strukturierte Format ermöglicht die automatisierte Verarbeitung und Filterung von Nachrichten.

<PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [STRUCTURED-DATA] MSG

Ein praktisches Beispiel verdeutlicht den Aufbau. Hier meldet ein SSH-Dienst einen fehlgeschlagenen Login-Versuch:

<34>1 2024-01-15T14:32:01.003Z webserver01 sshd 2847 - - Failed password for root from 192.168.1.50

Facility und Severity

Die Priorität (PRI) einer Syslog-Nachricht setzt sich aus zwei Werten zusammen: der Facility (Quelle) und der Severity (Schweregrad). Die Facility gibt an, welcher Systemteil die Nachricht erzeugt hat. Die Severity beschreibt die Dringlichkeit der Meldung. Aus beiden Werten wird ein Priority-Wert berechnet: PRI = Facility × 8 + Severity.

Die wichtigsten Facility-Codes sind:

Die acht Severity-Level reichen von 0 (Emergency) bis 7 (Debug). Emergency bedeutet, dass das System nicht mehr nutzbar ist. Alert erfordert sofortige Handlung. Critical, Error und Warning beschreiben verschiedene Fehlergrade. Notice und Informational sind normale Betriebsmeldungen. Debug enthält detaillierte Informationen zur Fehlersuche.

Structured Data

RFC 5424 führte das Konzept der Structured Data ein. Damit können zusätzliche maschinenlesbare Informationen in die Nachricht eingebettet werden. Diese Daten bestehen aus SD-Elements mit einer ID und Schlüssel-Wert-Paaren. Typische Anwendungen sind Sequenznummern, Zeitqualitätsinformationen oder anwendungsspezifische Metadaten.

<165>1 2024-01-15T14:32:01Z server01 myapp 1234 ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] User login successful

Syslog-Implementierungen unter Linux

Unter Linux gibt es verschiedene Syslog-Implementierungen mit unterschiedlichen Funktionsumfängen. Die Wahl der richtigen Software hängt von den Anforderungen ab. Für einfache Szenarien reicht der klassische syslogd, während Unternehmensumgebungen meist auf rsyslog oder syslog-ng setzen.

rsyslog

rsyslog ist der Standard-Syslog-Daemon in den meisten Linux-Distributionen wie Debian, Ubuntu und Red Hat. Er unterstützt TCP und TLS, kann Nachrichten filtern, umschreiben und an verschiedene Ziele weiterleiten. Durch sein modulares Design lässt sich rsyslog flexibel erweitern, etwa um Logs direkt in Datenbanken oder Elasticsearch zu schreiben.

# Beispiel: rsyslog-Konfiguration für Remote-Logging
# /etc/rsyslog.d/50-remote.conf
*.* action(
  type="omfwd"
  Target="syslog.example.com"
  Port="514"
  Protocol="tcp"
)

syslog-ng

syslog-ng bietet eine leistungsfähige Alternative zu rsyslog. Die Software punktet mit einer übersichtlichen Konfigurationssyntax und umfangreichen Parsing-Möglichkeiten. Nachrichten können nach verschiedenen Kriterien gefiltert und an unterschiedliche Ziele verteilt werden.

# Beispiel: syslog-ng Grundkonfiguration
source s_local { system(); internal(); };
destination d_messages { file("/var/log/messages"); };
log { source(s_local); destination(d_messages); };

systemd-journald

Moderne Linux-Systeme mit systemd verwenden journald als primäres Logging-System. Journald speichert Logs in einem binären Format und bietet mächtige Abfragemöglichkeiten über den Befehl journalctl. Für die Weiterleitung an Syslog-Server wird journald typischerweise mit rsyslog oder syslog-ng kombiniert.

# Logs der letzten Stunde anzeigen
journalctl --since "1 hour ago"

# Nur Fehler und kritische Meldungen
journalctl -p err

# Logs eines bestimmten Dienstes
journalctl -u sshd

Syslog bei Netzwerkgeräten

Netzwerkgeräte wie Router, Switches und Firewalls unterstützen Syslog nativ. Als Fachinformatiker für Systemintegration konfigurierst du diese Geräte so, dass sie ihre Logs an einen zentralen Syslog-Server senden. Das ermöglicht die einheitliche Überwachung der gesamten Netzwerkinfrastruktur.

! Cisco IOS - Syslog-Konfiguration
logging host 192.168.1.10
logging trap informational
logging facility local7
logging source-interface Loopback0

Bei der Konfiguration ist es wichtig, den richtigen Severity-Level zu wählen. Ein zu niedriger Level (z.B. Debug) kann den Syslog-Server mit Nachrichten überfluten. Ein zu hoher Level übersieht möglicherweise wichtige Warnungen. Als Faustregel gilt: Für den normalen Betrieb reicht Informational (6), bei der Fehlersuche wird temporär auf Debug (7) umgestellt.

Syslog und IT-Sicherheit

Im Bereich IT-Sicherheit ist Syslog ein zentrales Werkzeug. Security Information and Event Management (SIEM)-Systeme sammeln Syslog-Nachrichten aus der gesamten Infrastruktur und analysieren sie auf verdächtige Muster. Fehlgeschlagene Login-Versuche, ungewöhnliche Zugriffe oder Konfigurationsänderungen werden erkannt und lösen Alarme aus.

Für die revisionssichere Protokollierung sind einige Aspekte wichtig: Die Übertragung sollte verschlüsselt erfolgen (TLS). Der Syslog-Server muss vor Manipulation geschützt sein. Zeitstempel müssen synchronisiert sein, damit Ereignisse zeitlich korrekt zugeordnet werden können. In regulierten Umgebungen gelten zusätzliche Aufbewahrungsfristen für Log-Daten.

Vergleich: RFC 3164 vs. RFC 5424

Obwohl RFC 5424 der aktuelle Standard ist, begegnet dir in der Praxis noch häufig das ältere BSD-Syslog-Format (RFC 3164). Viele ältere Geräte und Anwendungen unterstützen nur das klassische Format. Moderne Syslog-Server wie rsyslog können beide Formate verarbeiten.

Bei der Einrichtung eines Syslog-Servers solltest du beide Formate akzeptieren können. Neue Systeme sollten RFC 5424 verwenden, da es präzisere Zeitstempel und strukturierte Daten bietet. Das erleichtert die automatisierte Auswertung erheblich.

Best Practices für Syslog

Beim Aufbau einer Syslog-Infrastruktur solltest du einige bewährte Praktiken beachten. Eine durchdachte Architektur erleichtert die Fehlersuche und spart langfristig Zeit.

• Zeitsynchronisation: Nutze NTP, damit Zeitstempel netzwerkweit übereinstimmen
• TCP statt UDP: Verwende TCP für zuverlässige Übertragung, besonders über WAN-Strecken
• TLS-Verschlüsselung: Schütze sensible Log-Daten bei der Übertragung
• Log-Rotation: Verhindere, dass Log-Dateien die Festplatte füllen
• Redundanz: Setze mindestens zwei Syslog-Server ein
• Filterung: Reduziere Rauschen durch gezielte Filter
• Dokumentation: Halte fest, welche Geräte wohin loggen

Syslog in der Praxis

Als Fachinformatiker für Systemintegration wirst du regelmäßig mit Syslog arbeiten. Die Einrichtung zentraler Log-Server, die Konfiguration von Netzwerkgeräten und die Analyse von Log-Daten gehören zu den typischen Aufgaben. Auch bei der Fehlersuche in komplexen Umgebungen sind Syslog-Kenntnisse unverzichtbar.

In größeren Unternehmen werden Syslog-Daten oft in SIEM-Systeme wie Splunk, Elastic Stack (ELK) oder Graylog eingespeist. Diese Werkzeuge ermöglichen die Korrelation von Ereignissen aus verschiedenen Quellen und helfen bei der Erkennung von Sicherheitsvorfällen. Das Verständnis von Syslog ist die Grundlage für die Arbeit mit diesen fortgeschrittenen Systemen.

Quellen und weiterführende Links

• RFC 5424 - The Syslog Protocol - Offizielle Spezifikation
• RFC 3164 - BSD Syslog Protocol - Ursprünglicher BSD-Standard
• rsyslog Dokumentation - Populärer Syslog-Daemon
• syslog-ng - Alternative Syslog-Implementierung
• Linux man page: syslog(3) - Programmierschnittstelle
• Wikipedia: Syslog - Übersicht und Geschichte