Syslog: Schweregrade und zentrale Sammlung

Während SNMP dir Messwerte liefert („CPU bei 87 %"), liefert Syslog dir Ereignisse – einzelne Vorfälle mit Zeitstempel und Textbeschreibung. „User admin angemeldet von 192.168.1.42", „Disk-IO-Error auf /dev/sda3", „BGP-Nachbar 10.1.1.1 verloren". Solche Meldungen kommen von praktisch jedem System: Linux-Server, Switches, Router, Firewalls, Drucker, USVs. Das Syslog-Protokoll standardisiert seit 1980 (offiziell RFC 3164, modernisiert in RFC 5424), wie diese Meldungen formuliert, kategorisiert und verschickt werden. Ohne zentrale Sammlung sind sie nutzlos – wer durchsucht 60 Server einzeln? Mit einem zentralen Syslog-Server hast du einen Ort, an dem alles zusammenläuft – durchsuchbar, korrelierbar, langzeitarchivierbar. Diese Lektion zeigt dir den Aufbau einer Syslog-Nachricht, die acht Schweregrade und wie zentrale Sammlung in der Praxis aussieht.

1) Die acht Schweregrade (Severity Levels)

Jede Syslog-Nachricht trägt einen Schweregrad von 0 (am schlimmsten) bis 7 (am harmlosesten). Sie sind im RFC festgelegt und über alle Hersteller hinweg gleich – ein Cisco-Switch nutzt dieselben Stufen wie ein Linux-Server. Klick eine Stufe an, um zu sehen, was sie bedeutet und ein typisches Beispiel:

Syslog Severity Levels – 0 bis 7

0Emergency

1Alert

2Critical

3Error

4Warning

5Notice

6Info

7Debug

Merksatz aus dem Cisco-Umfeld: „Every Awesome Cisco Engineer Will Need Ice cream Daily" – die Anfangsbuchstaben sind die Severities von 0 bis 7. Die Stufen 0–3 sind Wachzimmer-Material: jemand sollte aktiv etwas tun. 4–7 sind ohne sofortigen Handlungsbedarf – aber wichtig für Audit, Trend-Analyse und Root Cause Analysis nach einem Incident.

2) Facility – woher kommt die Meldung?

Neben dem Schweregrad hat jede Meldung eine Facility – grob „der Quellbereich" der Meldung. Das ist eine Kategorie wie auth (Authentifizierungs-Events), mail (Mailserver), kern (Kernel), cron (Cron-Jobs) oder local0–local7 (frei für eigene Anwendungen). Damit kannst du auf dem zentralen Server filtern: „zeig mir nur Auth-Meldungen aller Server". Die Kombination aus Facility und Severity ergibt die PRI (Priority Value): PRI = Facility × 8 + Severity. Eine Auth-Error-Meldung (Facility 4, Severity 3) hat damit PRI = 35; im Header steht <35>. Das wirkt auf den ersten Blick kryptisch, ist aber pragmatisch: ein einziges Byte beschreibt Herkunft und Wichtigkeit.

3) Aufbau einer Syslog-Nachricht (RFC 5424)

Hier eine reale Beispielzeile. Hover oder klick die farbigen Teile an, um zu sehen, was jeder Block bedeutet:

Anatomie einer Syslog-Zeile

<34>1 2026-05-18T09:14:22.518Z srv-web01 sshd 29387 - Failed password for invalid user admin from 203.0.113.47

Klick auf die farbigen Teile, um zu sehen, was jeder Block bedeutet.

RFC 3164 ist die alte Variante (BSD-Style, ohne Versionsnummer, andere Zeitstempel-Form: „May 18 09:14:22"). RFC 5424 ist neuer, präziser und enthält Millisekunden plus ISO-8601-Zeitstempel. Beide kommen in der Praxis vor – moderne Tools können beide parsen.

4) Zentrale Sammlung – warum es zwingend nötig ist

Wenn jeder Server seine Logs nur lokal speichert, hast du drei Probleme: (a) du musst dich auf jedes System einzeln einloggen, um zu suchen – bei 60 Maschinen unrealistisch; (b) ein Angreifer, der einen Server kompromittiert, kann die lokalen Logs löschen und seine Spuren tilgen; (c) du kannst Ereignisse nicht korrelieren – wenn um 03:17 die Datenbank ausfällt, willst du gleichzeitig den Switch-Port-Status, die App-Server-Logs und die Firewall-Drops sehen.

Zentrale Log-Sammlung – live

🌐 web-server-01info

💾 db-masterwarn

🔥 firewall-01err

🔀 switch-corenotice

🖨️ printer-2ferr

→

📊 Syslog-Server

rsyslog · 10.0.0.10 : 514

Alle Quellen schicken parallel an Port 514

Beste Praxis: Logs nach Empfang sofort auf einen separaten, restriktiv zugänglichen Server spiegeln. Wer das produktive System hackt, sieht die Logs trotzdem nicht und kann sie nicht löschen. Aufbewahrungsfristen je nach Anwendung – mindestens 90 Tage, sicherheitsrelevante oft 1–2 Jahre. DSGVO und TOMs beachten: IPs sind personenbezogen.

5) Die typischen Tools im Linux- und Windows-Lager

Im Linux-Bereich konkurrieren historisch syslogd, rsyslog und syslog-ng – auf den meisten modernen Distributionen ist rsyslog Standard. Daneben gibt es journald (systemd-eigen, strukturiert, binär) – sieh dir das in Log-Analyse genauer an. Windows nutzt das proprietäre Event Log (siehe Ereignisanzeige) – um Events auf einen zentralen Server zu kriegen, brauchst du entweder einen Forwarder wie NXLog, WEC (Windows Event Collector) oder eine SIEM-Lösung. Für die Auswertung großer Mengen sind professionelle Stacks Standard: ELK / OpenSearch (Elasticsearch + Logstash + Kibana), Graylog, Splunk. Sie bringen Volltext-Suche, Dashboards und Alarme – Logs werden damit zum aktiv genutzten Werkzeug, nicht nur zur Pflicht.

6) Stolperfallen

UDP/514 ist Standard – unzuverlässig. Pakete können verloren gehen. Lösung: TCP-Variante (Port 6514 bei TLS) oder reliable RELP-Protokoll bei rsyslog.
Klartextübertragung. Wer den Netzwerkverkehr abhört, sieht alle Logs inklusive Auth-Versuche. In sicherheitskritischen Umgebungen Syslog über TLS verwenden.
Zeitstempel-Chaos. Wenn die Systeme uneinheitliche Uhren haben, sind korrelierte Auswertungen Wahrsagerei. Lösung: NTP auf allen Quellen, am besten gegen einen internen Zeitserver.
Logrotation vergessen. Ein vergessenes access.log kann die Disk in Wochen füllen. logrotate bzw. journalctl --vacuum-size sind Pflicht.
Personenbezogene Daten. IPs, User-Namen, Pfadangaben können personenbezogen sein – sieh DSGVO-Grundprinzipien. Aufbewahrungsfristen klären und in den TOMs dokumentieren.

Zusammenfassung

Syslog ist der älteste und nach wie vor weitestverbreitete Standard zum Verschicken von Ereignis-Meldungen. Jede Nachricht hat eine Facility (Quellbereich) und eine Severity (0=Emergency bis 7=Debug) – kombiniert zur PRI. Aufbau nach RFC 3164 (alt) oder 5424 (modern): Header mit Zeitstempel, Host, App, PID plus Klartext-Message. Zentrale Sammlung ist nicht optional – nur so kannst du suchen, korrelieren und vor Manipulation schützen. Standard-Port: UDP 514 (unzuverlässig, im Klartext), TCP/TLS auf 6514 für Sicherheitsumgebungen. Tools: rsyslog/syslog-ng/journald (Linux), Event Log + NXLog/WEC (Windows). Stolperfallen: Paketverlust bei UDP, Zeitsynchronisation per NTP, Logrotation, DSGVO.

Verwandte Lektionen: Log-Analyse: Eventlog & journald · SNMP · Monitoring-Konzept · und mehrWeitere relevante LektionenSchwellenwerte & Alerting Ereignisanzeige (Windows)systemd-Dienste NTP TOMs (DSGVO)Incident Management CIA-Triad