Was ist Syslog? 

Syslog ist ein standardisiertes Protokoll und Nachrichtenformat für das System-Logging. Damit können Geräte, Anwendungen und Betriebssysteme Log-Daten zur zentralen Speicherung und Analyse an eine gemeinsame Stelle senden. Syslog wurde entwickelt, damit beispielsweise Router, Linux-Server, Firewalls und E-Mail-Anwendungen Events in einem einheitlichen Grundformat übermitteln können, unabhängig vom Hersteller oder der verwendeten Programmiersprache.

Eine Syslog-Nachricht enthält immer drei zentrale Informationen: 

• woher das Event stammt (Facility)
• wie schwerwiegend es ist (Severity)
• was passiert ist (Nachrichtentext)

Statt sich bei 40 verschiedenen Geräten anzumelden und dort jeweils einzelne Log-Dateien zu prüfen, können Administratoren alle Geräte ihre Logs an einen zentralen Syslog-Server senden lassen. Dort lassen sich die Daten zentral durchsuchen, filtern und für Alerts nutzen.

Syslog ist standardmäßig auf nahezu allen Unix-ähnlichen Systemen verfügbar. Auch Windows-Systeme, Netzwerkgeräte und die meisten Enterprise-Anwendungen unterstützen Syslog über integrierte Agents oder Forwarder von Drittanbietern.

Wie funktioniert Syslog?

Syslog überträgt Nachrichten über drei Ebenen: die Anwendung, die ein Event erzeugt, die Transportebene, über die die Nachricht übertragen wird, und die Erfassungsebene, die sie speichert und verarbeitet.

Sehen wir uns die einzelnen Schritte genauer an.

1. Anwendungsebene: Ein Programm, Service oder Gerät erzeugt ein Event, beispielsweise einen fehlgeschlagenen Anmeldeversuch, eine unterbrochene Verbindung oder eine Festplatte, deren Kapazitätsgrenze erreicht wird. Das Event wird über die lokale Syslog-Bibliothek, beispielsweise syslog() unter Linux, oder eine integrierte Logging-Funktion als Syslog-Nachricht formatiert.

2. Transportebene: Die Nachricht wird vom Quellgerät über UDP (User Datagram Protocol) oder TCP (Transmission Control Protocol), üblicherweise über Port 514, an einen Empfänger übertragen. In einigen Umgebungen wird die Übertragung über TLS auf Port 6514 verschlüsselt. Das ist insbesondere bei Nachrichten relevant, die beispielsweise Anmeldeversuche oder Konfigurationsänderungen enthalten.

3. Erfassungsebene: Ein Syslog-Server oder Daemon wie syslogd, rsyslogd oder syslog-ng empfängt die Nachricht, zerlegt sie in einzelne Felder und verarbeitet sie weiter. Je nach Konfiguration wird sie gespeichert, an ein anderes System weitergeleitet, für einen Alert verwendet oder an ein SIEM übergeben.

Lokales Logging vs. Network Logging

Nicht jede Syslog-Nachricht wird an ein externes System übertragen. 

• Lokales Logging schreibt Events in eine Datei auf demselben System. Bei vielen Linux-Distributionen sind das beispielsweise /var/log/syslog oder /var/log/messages. Für das Troubleshooting eines einzelnen Servers ist das ausreichend, lässt sich jedoch nur begrenzt skalieren. Wird ein Gerät kompromittiert oder gelöscht, können auch die darauf gespeicherten Logs verloren gehen.
• Network Logging sendet dieselben Nachrichten über UDP oder TCP an einen entfernten Syslog-Server. Dadurch existiert eine zusätzliche Kopie der Events außerhalb des Quellsystems. 

In Produktivumgebungen werden häufig beide Ansätze kombiniert: lokales Logging für schnelles Troubleshooting direkt auf dem System und Network Logging für langfristige Speicherung, Korrelation und die Sicherung von Log-Daten, selbst wenn das Quellsystem kompromittiert wird.

Was passiert nach dem Empfang einer Nachricht?

Der Empfang einer Syslog-Nachricht ist nur der erste Schritt. Ein Syslog-Server übernimmt typischerweise folgende Aufgaben:

• Parsing: Zerlegt die Nachricht in strukturierte Felder wie Zeitstempel, Host, Facility, Severity und Nachrichtentext.
• Speicherung: Speichert die Daten üblicherweise in einer Datenbank oder einem indexierten Dateisystem gemäß einer definierten Aufbewahrungsfrist.
• Weiterleitung Übermittelt die Daten an das jeweils vorgesehene Ziel, beispielsweise ein SIEM, eine Log-Analytics-Plattform, ein Langzeitarchiv oder mehrere Systeme gleichzeitig.
• Alert Löst einen Alert aus, wenn eine Nachricht eine definierte Bedingung erfüllt, beispielsweise bei ungewöhnlich vielen fehlgeschlagenen Anmeldeversuchen oder einem bestimmten Fehlercode.

Das reine Speichern von Nachrichten reicht also nicht aus. Damit Syslog-Daten tatsächlich nutzbar werden, müssen sie strukturiert, weitergeleitet und auf relevante Ereignisse geprüft werden.

Was ist ein Syslog-Server?

Ein Syslog-Server empfängt, indexiert und verwaltet Log-Nachrichten, die von anderen Geräten im Netzwerk gesendet werden. Im Wesentlichen besteht er aus zwei Komponenten: 

• einem Listener, der eingehende UDP- oder TCP-Verbindungen entgegennimmt
• einer Datenbank beziehungsweise einem Log Store, in dem die aufbereiteten Nachrichten für Suche und Aufbewahrung gespeichert werden

Nach dem Empfang einer Nachricht übernimmt der Syslog-Server weit mehr als nur die Speicherung:

Syslog Client, Relay oder Server: Was ist der Unterschied?

Die Begriffe werden häufig synonym verwendet, bezeichnen jedoch unterschiedliche Rollen innerhalb derselben Pipeline:

• Syslog Client: Das Quellgerät, das Events erzeugt und versendet. Router, Switches, Firewalls, Intrusion-Detection-Systeme und IoT-Geräte können beispielsweise als Syslog Clients fungieren.
• Syslog Relay: Ein zwischengeschaltetes System, das Nachrichten empfängt und weiterleitet, gegebenenfalls nachdem sie gefiltert oder neu formatiert wurden. Relays kommen häufig in segmentierten Netzwerken zum Einsatz, in denen Clients den zentralen Server nicht direkt erreichen können.
• Syslog Server: Das Zielsystem, das Nachrichten langfristig speichert und indexiert.

Warum zentrales Logging für die Sicherheit wichtig ist

Ein zentraler Syslog-Server speichert Logs außerhalb des ursprünglichen Geräts. Dadurch bleiben wichtige Informationen auch dann erhalten, wenn das Quellsystem kompromittiert wird. 

Erhält beispielsweise ein Angreifer Zugriff auf ein Gerät und löscht die lokalen Logs, um seine Aktivitäten zu verschleiern, bleiben die bereits an den zentralen Syslog-Server übertragenen Kopien erhalten. Deshalb spielen Syslog-Daten auch bei forensischen Untersuchungen und Compliance-Audits eine wichtige Rolle. Sie können eine der wenigen noch verfügbaren Aufzeichnungen darüber sein, was auf einem kompromittierten System passiert ist.

Wie ist eine Syslog-Nachricht aufgebaut?

Eine Syslog-Nachricht besteht aus einem Priority Value (PRI), einem Header und dem eigentlichen Nachrichtentext. Der PRI-Wert sowie die darin enthaltenen Facility- und Severity-Codes sind entscheidend, um Log-Daten strukturiert einordnen und auswerten zu können.

Den PRI-Wert entschlüsseln

Der PRI-Wert ist eine einzelne Zahl, in der sowohl Facility als auch Severity einer Syslog-Nachricht codiert sind.

Jede Syslog-Nachricht beginnt mit einem PRI-Wert in spitzen Klammern, beispielsweise . Dieser wird folgendermaßen berechnet:

PRI = (Facility × 8) + Severity

Nehmen wir als Beispiel. Teilt man 134 durch 8, ergibt sich 16 mit einem Rest von 6. Damit lautet der Facility-Code 16 (local0) und der Severity-Code 6 (Informational). Auf diese Weise können Network Engineers einen PRI-Wert auch direkt aus Raw Logs entschlüsseln, ohne dafür ein separates Lookup-Tool zu benötigen.

Facility-Codes (0–23)

Der Facility-Code gibt an, welcher Prozess beziehungsweise Systembereich die Nachricht erzeugt hat.

Severity Levels (0–7)

Der Severity Level gibt an, wie dringend eine Nachricht ist. Er bildet häufig die Grundlage für Alert-Regeln.

Aufbau einer Syslog-Nachricht

Hier sehen Sie ein Beispiel für eine Syslog-Nachricht nach RFC 5424:

1 2026-07-15T10:22:41.003Z web-app-03 nginx 8291 – [meta@32473 ip=”203.0.113.5″] Upstream timeout on /checkout

RFC 5424 vs. RFC 3164: Was hat sich geändert?

Syslog verwendet zwei weiterhin verbreitete Nachrichtenformate. Welches Format ein Gerät verwendet, beeinflusst, wie die Nachrichten verarbeitet und analysiert werden.

Der Zeitstempel von RFC 3164 ist eine der häufigsten Ursachen für Probleme bei der Verarbeitung. Da Jahr und Zeitzone fehlen, ist die Korrelation von Events über Zeitumstellungen oder verschiedene Regionen hinweg aufwendiger. In vielen Umgebungen kommen weiterhin beide Formate zum Einsatz, da ältere Netzwerkgeräte häufig kein RFC-5424-Format unterstützen.

Welche Syslog-Tools sollten Sie einsetzen?

Syslog-Tools lassen sich in fünf Kategorien einteilen. Die meisten Log-Pipelines kombinieren mindestens drei davon:

• Agents und Sender: Leichte Software auf dem Quellgerät, die Log-Daten formatiert und überträgt, beispielsweise rsyslog, syslog-ng oder NXLog.
• Collectors und Aggregatoren: Systeme, die Nachrichten aus vielen Quellen empfangen und zentral zusammenführen, bevor sie weitergeleitet werden.
• Relays: Zwischengeschaltete Forwarder, die vor allem in segmentierten oder verteilten Netzwerken eingesetzt werden.
• Analysetools: Lösungen, die Log-Daten indexieren, durchsuchen und visualisieren, beispielsweise Splunk, Elasticsearch oder LogicMonitor Logs.
• Alerting- und Automatisierungstools: Systeme, die auf Basis von Log-Inhalten Benachrichtigungen auslösen oder automatisierte Maßnahmen anstoßen.

Welches Tool eignet sich für welche Umgebung?

• Kleines Team, ein Rechenzentrum: Eine einzelne rsyslog- oder syslog-ng-Instanz für Erfassung, Filterung und lokale Speicherung ist meist ausreichend.
• Unternehmen mit mehreren Standorten: Relays an den einzelnen Standorten leiten die Nachrichten an einen zentralen Aggregator weiter. Darüber kann eine eigene Analytics-Ebene für Suche und Korrelation aufgebaut werden.
• Umgebungen mit mehreren Betriebssystemen: Achten Sie auf Agents mit nativer Unterstützung für Linux, Windows und verschiedene Network OS. Windows erzeugt Syslog nicht nativ und benötigt daher einen Forwarding-Agent wie NXLog oder eine Kombination aus Windows Event Forwarding und Syslog-Bridge.
• Netzwerkintensive Umgebungen: Wählen Sie einen Collector, der hohe Nachrichtenvolumen zuverlässig über UDP verarbeiten kann, ohne während eines Incidents relevante Nachrichten zu verlieren.

Rsyslog vs. Syslog-ng

Die beiden verbreiteten Open-Source-Syslog-Daemons unterscheiden sich vor allem bei Plattformunterstützung und Dokumentation.

1. Syslog-ng läuft auf AIX, HP-UX, Linux, Solaris, Tru64 und verschiedenen BSD-Varianten und eignet sich daher besonders für Umgebungen mit unterschiedlichen Betriebssystemen. Zudem unterstützt es die Klassifizierung und Kennzeichnung von Logs in Echtzeit. Der offizielle Administrator Guide beschreibt Filter, Quellen, Ziele und Log-Formate ausführlich, sodass sich die meisten Umgebungen ohne zusätzliche Informationsquellen konfigurieren lassen.
2. Rsyslog wurde hauptsächlich für Linux und Solaris entwickelt. Auf den meisten gängigen Linux-Distributionen ist es standardmäßig als Logging-Daemon installiert und damit besonders für reine Linux-Umgebungen eine naheliegende Wahl. Die Dokumentation ist allerdings weniger umfangreich. Bei Problemen mit bestimmten rsyslog-Modulen müssen Teams Konfigurationsdetails daher häufig aus verschiedenen Forenbeiträgen zusammentragen, statt sie direkt in der offiziellen Dokumentation zu finden.

Syslog und SIEM-Integration

Syslog-Daten bilden in der Regel nur eine Datenquelle innerhalb einer größeren Sicherheits- und Analyseumgebung. Die meisten SIEM- und XDR-Plattformen können Syslog neben anderen Quellen wie Endpoint-Telemetrie, Network Flow-Daten und Identity-Logs erfassen und miteinander korrelieren.

Ein Beispiel: Die Syslog-Meldung einer Firewall über einen blockierten Verbindungsversuch wird wesentlich aussagekräftiger, wenn sie mit einem Endpoint-Alert korreliert wird, der zeitgleich eine Malware-Ausführung auf demselben Host meldet. Genau diese Korrelation ist ein wesentlicher Mehrwert eines SIEM gegenüber einzelnen Syslog-Daten.

Checkliste für die Auswahl eines Syslog-Tools

Vor der Auswahl eines Syslog-Tools sollten Sie prüfen, ob es Folgendes unterstützt:

• Parsing-Support für RFC 3164 und RFC 5424
• Volltextsuche und strukturierte Suche über historische Log-Daten
• Regelbasierte Filterung zur Kontrolle des Nachrichtenvolumens vor der Speicherung
• Alerting nach Severity, Facility oder benutzerdefinierten Mustern
• Konfigurierbare Aufbewahrungsfristen nach Log-Quelle oder Log-Typ
• TLS für verschlüsselte Übertragung
• Multi-Vendor- und Multi-OS-Unterstützung

Was sind Best Practices und Herausforderungen bei Syslog?

Syslog einzurichten ist relativ einfach. Entscheidend ist, die Umgebung langfristig zuverlässig, sicher und nutzbar zu halten.

• Klare Verantwortlichkeiten für die Pipeline definieren: Eine Person oder ein Team sollte für die Syslog-Pipeline verantwortlich sein. Dazu gehören die Freigabe neuer Quellen, die Dokumentation von Änderungen an der Collector-Konfiguration und die Überprüfung, ob nach jeder Änderung weiterhin alle erwarteten Logs eintreffen. Ohne diese Verantwortung kann es passieren, dass eine Quelle über Wochen keine Logs mehr weiterleitet, ohne dass dies bemerkt wird.
• Datenvolumen kontrollieren: Ein einzelner ausgelasteter Switch kann täglich Tausende Log-Meldungen erzeugen, von denen viele keinen dauerhaften Mehrwert bieten. Filtern Sie deshalb möglichst bereits an der Quelle, vereinheitlichen Sie Nachrichtenformate und leiten Sie nur relevante Daten an kostenintensiven Langzeit-Storage weiter.
• Transportzuverlässigkeit berücksichtigen: UDP ist schnell und ressourcenschonend, garantiert aber keine Zustellung. Bei Traffic-Spitzen oder kurzen Netzwerkunterbrechungen können Nachrichten unbemerkt verloren gehen. TCP gewährleistet dagegen eine zuverlässigere Übertragung, verursacht aber zusätzlichen Overhead und kann sich stauen, wenn der Empfänger nicht schnell genug verarbeitet. In sicherheits- oder compliancekritischen Umgebungen werden kritische Quellen daher häufig über TCP oder TLS-verschlüsseltes TCP angebunden, während UDP für weniger kritische und volumenintensive Quellen eingesetzt wird.
• Die Erfassungsebene absichern: TLS auf Port 6514 schützt Log-Daten während der Übertragung, nicht aber den Syslog-Server selbst vor unbefugtem Zugriff oder Manipulation. Beschränken Sie daher, wer den Syslog-Server verändern oder Logs schreiben kann, und überwachen Sie die Pipeline auf unerwartete Lücken und Konfigurationsänderungen.
• Aufbewahrung als laufende Betriebskosten betrachten: Aufbewahrungsfristen werden häufig einmalig aufgrund von Compliance-Vorgaben festgelegt und später nicht mehr überprüft. Mit zunehmendem Log-Volumen können die Storage-Kosten jedoch deutlich steigen. Überprüfen Sie daher regelmäßig, welche Aufbewahrungsdauer tatsächlich für Untersuchungen und Compliance erforderlich ist.

Was sind typische Anwendungsfälle für Syslog?

Syslog kommt überall dort zum Einsatz, wo Geräte oder Anwendungen ihren Betriebszustand und relevante Events melden müssen. Das betrifft unter anderem Netzwerkgeräte, Betriebssysteme und Anwendungen.

Netzwerkgeräte wie Router, Switches und Firewalls erzeugen Syslog-Meldungen, mit denen Administratoren beispielsweise Nutzeraktivitäten nachvollziehen, Performance-Trends wie Latenz überwachen, verdächtigen Traffic wie Port Scans erkennen und unbefugte Konfigurationsänderungen identifizieren können.

Betriebssysteme wie Linux, Windows und macOS unterstützen Syslog-basiertes Logging zur Nachverfolgung von Nutzeraktivitäten, zur Prüfung von Kontozugriffen und zur Erkennung von Performance-Problemen wie hoher CPU-Auslastung oder Memory Leaks.

Anwendungen wie Datenbanken, Webserver und VPNs nutzen Syslog für Compliance Monitoring, Debugging und die Überwachung des Anwendungszustands. Ein praktisches Beispiel ist ein DevOps-Team, das einen Anstieg von HTTP-500-Fehlern mit einem kürzlich durchgeführten Deployment korreliert und daraus unmittelbar eine Maßnahme ableitet.

Woher kommt Syslog?

Syslog entstand in den 1980er-Jahren als Teil des Sendmail-Projekts von Eric Allman. Das Ziel war, Aktivitäten des Mailservers in einheitlicher Form zu protokollieren. Andere Unix-Tools übernahmen dieses Format, und Syslog entwickelte sich zu einem De-facto-Standard, lange bevor es formell dokumentiert wurde. Die IETF veröffentlichte Syslog 2001 als RFC 3164 und dokumentierte damit die bereits verbreitete Praxis. 2009 folgte RFC 5424 mit strukturierten Daten, präziseren Zeitstempeln und klarer definierten Feldern.

Diese Entwicklung erklärt, warum RFC-3164-Nachrichten auch heute noch in vielen Umgebungen vorkommen. Ältere Netzwerkgeräte und langlebige Unix-Daemons wurden für das ursprüngliche Format entwickelt und nie aktualisiert. Deshalb müssen viele Log-Pipelines weiterhin beide Formate verarbeiten können.

Syslog im großen Maßstab verwalten

Syslog ermöglicht es, Log-Meldungen von nahezu allen Geräten und Anwendungen einer IT-Umgebung zentral zu erfassen. Mit zunehmender Größe der Infrastruktur reicht das reine Sammeln von Logs jedoch nicht mehr aus. Teams müssen die Daten auch durchsuchen, korrelieren, für Alerts nutzen und gemeinsam mit Infrastrukturmetriken analysieren können. LogicMonitor führt diese Funktionen auf einer zentralen Plattform zusammen. Dadurch können Operations-Teams Syslog-Daten im Kontext der Ressourcen und Alerts analysieren, aus denen sie entstanden sind, und Probleme schneller untersuchen.

FAQs