Was ist Syslog? Facility, Severity und Port 514

Syslog ist das Protokoll, mit dem ein Gerät aufschreibt, was ihm widerfährt, als einfache Textzeilen, und sie an einen zentralen Server schickt. Switches, Firewalls, Server, Drucker und USVs tun das seit vierzig Jahren fast unverändert: Etwas passiert, das Gerät schreibt eine Zeile, die Zeile geht ins Netz. Sie müssen nur für jemanden sorgen, der zuhört.

Im Gerichtssaal übernimmt genau das der Protokollführer. Die Richterin spricht, die Parteien sprechen, ein Zeuge spricht; der Protokollführer schreibt auf, was gesagt wurde, wie es gesagt wurde, mit Uhrzeit. Er entscheidet nichts und muss nicht einmal verstehen, worum es geht. Seine Aufgabe ist, dass ein Protokoll existiert. Kommt Monate später ein Rechtsmittel, schaut niemand in Erinnerungen, sondern ins Protokoll.

Die Geräte in Ihrem Netz reden ständig. Das Problem der meisten Organisationen ist nicht, dass sie schweigen, sondern dass es keinen Protokollführer gibt. Dieser Artikel zeigt, wie eine Syslog-Zeile aussieht, wie die Zahl in den ersten spitzen Klammern zu lesen ist, warum das Protokoll UDP 514 gewählt hat und was es nicht transportiert. Dann schaut er sich echte Einträge eines Laborswitches an und kommt zur eigentlich schwierigen Frage: Wenn die Logs fließen, welche davon zählen? Er ist der Einstieg in den Leitfaden Monitoring und Alarme. Befehle und Ausgaben stammen aus dem Labor des Autors und sind so belassen, wie sie aufgezeichnet wurden.

Was ist Syslog, und welches Problem löst es?

Syslog trennt das Gerät, das Ereignisse erzeugt, vom Server, der sie aufbewahrt. Das Gerät sagt nur „das ist passiert“ und lässt die Zeile los; wo sie gespeichert wird, wie lange und wer sie liest, ist nicht mehr seine Sache. Die ganze Stärke des Protokolls kommt aus dieser Trennung, und alle seine Lücken ebenso.

Ein Ereignis ohne Eintrag hat nicht stattgefunden

Die teuerste Störung ist die, die keine Spur hinterlässt. Ein Port fällt um drei Uhr nachts für eine Minute aus und kommt wieder. Am Morgen merkt es niemand; Benutzer sagen „das Internet war kurz weg, glaube ich“, Sie prüfen, alles normal, und drei Wochen später wiederholt es sich. Das ist keine undiagnostizierbare Störung, sondern eine unprotokollierte.

Warum das Log auf dem Gerät nicht reicht

Jeder Switch und jede Firewall führt intern ein Log. Das Problem ist nicht, dass es existiert, sondern dass es Ihnen auf drei Arten entgleitet:

1. Es ist nicht dauerhaft. Der Puffer im Speicher kann zu klein sein oder beim Stromausfall gelöscht werden.
2. Es ist begrenzt. Ist er voll, werden die ältesten Zeilen überschrieben. Je gesprächiger das Gerät, desto kürzer die Geschichte.
3. Es ist im Störfall unerreichbar. Genau dann, wenn Sie es brauchen, antwortet das Gerät nicht.

Den ersten Punkt habe ich am Laborswitch gemessen, und der Beweis steckt an einer interessanten Stelle. Nach einem Neustart durch Stromausfall war die älteste Zeile im Puffer diese:

<185> Aug 19 06:57:16 0.0.0.0-1 SIM[Cnfgr_Thread ]: sim_util.c(3804) 8 %% Switch was reset due to power disruption.

Davor nichts. Die gesamte Vorgeschichte ging mit dem Ausfall verloren. Das Gerät teilt Ihnen mit, dass es sein Gedächtnis verloren hat, aus dem Gedächtnis heraus, das es verloren hat.

Wann Sie kein Syslog brauchen

In einem Drei-Personen-Büro mit einem Router und einem Switch ist zentrale Protokollierung eine überflüssige Schicht. Die Schwelle ist nicht die Geräteanzahl, sondern wie lange die Antwort auf eine Frage dauert. Können Sie „was ist gestern Abend wann passiert?“ nicht beantworten, ohne sich an jedem Gerät einzeln anzumelden, brauchen Sie zentrale Protokollierung.

Eine verbreitete Situation verdient Trennung. Viele Organisationen haben kein zentrales Log, aber einen strukturierten Datensatz: RADIUS-Accounting. Es kommt von selbst mit WLAN oder 802.1X und sammelt sich jahrelang an. Es beantwortet aber eine andere Frage: RADIUS-Accounting zeichnet Sitzungen auf (wer, wann, wie lange, wie viel Verkehr), Syslog Ereignisse (welcher Port fiel aus, welcher Prozess scheiterte, welche Konfiguration änderte sich). Das eine sagt „wer kam herein“, das andere „was ging kaputt“.

Ein dritter Kanal ist nicht zu verwechseln: SNMP holt Zahlen vom Gerät, Syslog empfängt die Sätze, die das Gerät schreibt. SNMP sagt, dass die CPU bei 80 % liegt; Syslog, welcher Prozess sie belastet. Die Mechanik steht in Was ist SNMP?

Warum Windows nicht von sich aus Syslog sendet

Hier bleiben Protokollierungsprojekte in gemischten Netzen am häufigsten stecken. Switches, Firewalls, Drucker und Linux-Server sprechen Syslog nativ, Windows nicht. Windows schreibt ins Event Log, ein eigenes System mit strukturierten Objekten statt Textzeilen: Ein Ereignis hat eine Nummer wie 4624, sein Inhalt ist in Felder aufgeteilt. Die meisten Geräte an einen Collector anzubinden ist eine Einstellung; Windows-Server brauchen einen übersetzenden Agenten. Planen Sie beide Gruppen getrennt.

Wie sieht eine Syslog-Nachricht aus? Anatomie einer Zeile

Eine Syslog-Nachricht ist Klartext in drei Teilen: Prioritätsfeld, Zeit und Quelle, Inhalt. Eine echte Zeile des Laborswitches:

<189> Aug 19 06:57:33 sercebilisimsw01-1 TRAPMGR[trapTask]: traputil.c(735) 235 %% Link Up: Vl5

Das führende <189> ist keine Verzierung, sondern die einzige strukturierte Information des Protokolls. Die Mitte bindet den Eintrag an wer und wann. Der Text am Ende ist frei vom Hersteller geschrieben und folgt keinem Standard.

Das Prioritätsfeld: die Zahl in den Klammern

Das Prioritätsfeld (PRI) packt zwei Angaben in eine Zahl: woher die Nachricht stammt und wie dringend sie ist.

PRI = (facility × 8) + severity

Zerlegen wir 189: 189 ÷ 8 = 23, Rest 5. Der Quotient 23 ist Facility 23, also local7; der Rest 5 ist Severity 5, also notice. Die Zeile ist ein normaler, aber beachtenswerter Eintrag aus local7. Statt der Arithmetik zu vertrauen, habe ich das Gerät gefragt:

show logging

Logging is enabled
Console Logging: Level warnings. Messages : 85 logged, 315 ignored
Buffer Logging: Level informational. Messages : 210 logged, 190 ignored
File Logging: Level emergencies. Messages : 0 logged, 400 ignored
Logging facility level : local7

Die letzte Zeile sagt local7. Der Quotient stimmt mit der Einstellung des Geräts überein.

Zeit, Quelle und Inhalt

Nach dem Prioritätsfeld folgt der Teil, der den Eintrag an einen Moment und ein Gerät bindet: Aug 19 06:57:33 ist der Zeitstempel, sercebilisimsw01-1 der Name, den sich das Gerät selbst gibt. Beide Felder stammen vom Gerät, und keinem ist blind zu trauen. Den Zeitstempel liest es aus der eigenen Uhr; geht sie falsch, wird der Eintrag zur falschen Zeit archiviert. Den Namen übernimmt der Collector ungeprüft. Das angehängte -1 ist die Einheitennummer im Stack.

Im Inhalt endet der Standard. TRAPMGR[trapTask]: traputil.c(735) 235 %% Link Up: Vl5 besteht aus Prozess und Thread, Quelldatei und Zeile der Firmware, dem Ereigniszähler des Geräts und schließlich der eigentlichen Nachricht für Menschen. Ein anderer Hersteller meldet dasselbe Ereignis in einem völlig anderen Satz, denn diesen Teil regelt kein Standard. Syslog standardisiert, wie eine Nachricht reist, nicht was sie sagt.

RFC 3164 und RFC 5424: zwei Formate, beide im Einsatz

Der Laborswitch schreibt Aug 19 06:57:33, also das alte Format. Das fehlende Jahr wirkt nebensächlich, schadet aber bei langer Aufbewahrung: Welcher 19. August ist es in einem zwei Jahre alten Archiv? Der Collector ergänzt aus seinem Empfangszeitpunkt, die Genauigkeit hängt also an der Uhr des Servers, nicht des Geräts.

Wie strukturierte Daten auf der Leitung aussehen

Das türkische Original dieses Artikels endet bei der Tabelle oben. Wie die zweite Spalte wirklich aussieht, zeigt ein Mitschnitt am Labor-Collector, aufgenommen beim Test unverschlüsselter Übertragung, und er zeigt etwas, das RFC 3164 gar nicht ausdrücken kann:

<13>1 2026-08-19T00:58:11.200471+00:00 sercesyslog gizli-test - - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="46500"] PAROLA=CokGizli123 duz metin gidiyor

1. <13> ist wieder das Prioritätsfeld: 13 = 1 × 8 + 5, Facility user, Severity notice, der Standard für eine von Hand mit logger gesendete Nachricht.
2. Die 1 direkt danach ist die Versionsnummer. Diese eine Ziffer sagt dem Collector, dass er RFC 5424 liest.
3. 2026-08-19T00:58:11.200471+00:00 ist ein vollständiger Zeitstempel mit Jahr, Mikrosekunden und Zeitzone. Die Mehrdeutigkeit von oben ist weg.
4. Die zwei Bindestriche sind leere Felder (Prozess-ID und Nachrichten-ID); RFC 5424 markiert fehlende Werte mit -.
5. [timeQuality tzKnown="1" isSynced="1" syncAccuracy="46500"] ist ein Structured-Data-Element, und es ist der interessante Teil.

timeQuality ist in RFC 5424 selbst definiert. Der Absender gibt damit an, wie sehr seinem Zeitstempel zu trauen ist: tzKnown="1" heißt, er kennt seine Zeitzone; isSynced="1", seine Uhr ist mit einer externen Quelle synchronisiert; syncAccuracy="46500" ist die angegebene Genauigkeit in Mikrosekunden, hier 46,5 Millisekunden. Die Nachricht trägt also eine Aussage über die Verlässlichkeit ihrer eigenen Uhr. Eine Zeile im alten Format kann das nicht.

Zwei Vorbehalte gehören dazu. Es ist eine Behauptung des Absenders, wie alles in Syslog ungeprüft: Ein Gerät mit kaputter Uhr, das sich für synchronisiert hält, sagt genau das. Und sie nützt nur, wenn Ihr Collector strukturierte Daten behält, statt sie zu verflachen. Wo Zeitstempel zählen, lohnt es sich, dieses Feld zu behalten und bei isSynced="0" zu alarmieren; so fällt ein driftender Absender auf, bevor seine Einträge in falscher Reihenfolge landen.

Der Rest der Zeile ist der Grund, warum der Mitschnitt existiert: PAROLA=CokGizli123 duz metin gidiyor heißt auf Türkisch „PASSWORT=SehrGeheim123 geht als Klartext“, ein Teststring, der über Port 514 gesendet wurde, um zu zeigen, dass jeder Mitschneidende ihn lesen kann. Ein entsprechender Test über TLS auf Port 6514 ergab das Gegenteil: Die Suche nach PAROLA im Mitschnitt fand null Treffer, sichtbar waren nur TCP-Header.

Facility und Severity: zwei Angaben in einer Zahl

Die Severity sagt, wie dringend eine Nachricht ist; die Facility, woher sie kommt. Beide sind unabhängig: Ein Drucker kann eine kritische Nachricht senden, der Kernel eine informative.

Die acht Schweregrade

Severity hat acht Werte, und eine kleinere Zahl ist dringender:

Zwei Zeilen desselben Geräts machen es greifbar:

<189> Aug 19 06:57:33 sercebilisimsw01-1 TRAPMGR[trapTask]: %% Link Up: Vl5
<185> Aug 19 06:57:16 0.0.0.0-1 SIM[Cnfgr_Thread ]: %% Switch was reset due to power disruption.

189 = 23 × 8 + 5 ist local7.notice, eine Schnittstelle kam hoch, normaler Betrieb. 185 = 23 × 8 + 1 ist local7.alert, das Gerät startete nach einem Stromausfall neu: die erste Zeile, die man morgens liest. Ein Zeichen Unterschied, aber es trennt „alles in Ordnung“ von „hier ist nachts etwas passiert“.

24 Facilities, und warum es local0 bis local7 gibt

Die ersten 16 Facilities haben feste Bedeutungen aus dem Unix der 1980er (kern, mail, auth, lpr); Netzwerkgeräte kommen darin nicht vor. Die übrigen acht, local0 bis local7, sind bewusst undefiniert: Die Bedeutung legen Sie fest. In der Praxis vergeben Sie einen Wert pro Geräteklasse, und der Collector schreibt jeden an einen eigenen Ort:

Die Falle: Der Laborswitch nutzt standardmäßig local7, und die meisten Hersteller wählen denselben Standard. Weisen Sie nichts zu, landen alle Geräte auf demselben Wert, und die Trennung, die Facility bieten soll, entsteht nie.

Wie der Schwellenwert wirkt: „diese Stufe und dringender“

Geräte führen je Ziel einen eigenen Schwellenwert und senden nichts darunter. Die Ausgabe von show logging oben zeigt es in Zahlen:

Die dritte Zeile ist der häufigste Fehler im Feld, gemessen: Ist die Schwelle zu eng, „funktioniert“ die Protokollierung und bleibt leer. Niemand plant, emerg-Meldungen zu erzeugen; diese Stufe ist für den Moment, in dem das System weg ist.

Warum Syslog Port 514 und UDP nutzt

Syslog nutzt standardmäßig UDP 514, und das folgt aus seinem Zweck: Ein Gerät soll nicht langsamer werden, um über sich zu berichten. UDP baut keine Verbindung auf und wartet auf keine Zustellung; das Gerät legt die Zeile ins Netz und macht weiter. Für einen Switch heißt das: Protokollierung stört nie seine eigentliche Arbeit.

Der Preis: UDP garantiert keine Zustellung und sagt niemandem, wenn sie scheitert. Im Gerichtssaal ist das eine fehlende Protokollseite; das Problem ist nicht die fehlende Seite, sondern dass niemand notiert hat, wie viele Seiten es waren. In einem schwach ausgelasteten internen Netz sind UDP-Verluste vernachlässigbar. Sie zählen bei einer vollen, schmalen Leitung zwischen Gerät und Collector oder wenn der Collector einem plötzlichen Ansturm nicht folgt, also genau dann, wenn Sie die Einträge am dringendsten brauchen. Deshalb gehört Management-Verkehr in ein eigenes VLAN (siehe Was ist ein VLAN?).

Auf einem Linux-Sender wird der Transport mit einem einzigen Zeichen gewählt:

*.* @192.168.1.46:514
*.* @@192.168.1.46:514

Ein @ heißt UDP, zwei @@ TCP. Ein Zeichen, und der Unterschied ist, ob Verluste still bleiben. Prüfen Sie das zuerst, wenn Sie eine Konfiguration übernehmen.

TCP, wenn Sie Verluste bemerken müssen. TLS auf Port 6514, wenn Einträge unterwegs nicht lesbar sein dürfen. Beides, wenn Logs Beweiskraft haben sollen. Verwechseln Sie nicht, was TLS hier leistet: Es verschlüsselt den Transport, es signiert den Eintrag nicht. Liegt die Zeile auf der Platte, ist TLS fertig; ob die Datei später verändert wird, ist eine andere Frage.

Was Syslog nicht transportiert: Identität, Integrität, Reihenfolge

Eine Absenderadresse ist keine Identität. Der Collector ordnet einen Eintrag anhand der Quelladresse einem Gerät zu, und über UDP lässt sie sich fälschen. Die praktische Maßnahme liegt um das Protokoll herum: Öffnen Sie 514 nur für bekannte Absender.

Wer garantiert, dass ein Eintrag nicht verändert wurde? Nicht Syslog. Die Zeile trägt weder Signatur noch Prüfsumme; beim Collector ist sie eine gewöhnliche Textdatei. Integrität ist eine eigene Schicht darüber: verkettete Hashes, eingeschränkte Schreibrechte, getrennter Archivspeicher. Je nachdem, was Ihre Logs enthalten, ist diese Schicht nicht optional:

• Logs enthalten fast immer IP-Adressen und Benutzernamen, die die DSGVO als personenbezogene Daten behandelt. Damit gelten für Ihr Log-Archiv der Grundsatz der Speicherbegrenzung nach Art. 5 Abs. 1 lit. e (nicht länger als nötig) und die Sicherheitsanforderungen nach Art. 32.
• Verarbeiten Sie Zahlungskarten, verlangt PCI DSS v4.0, Anforderung 10.5.1 mindestens zwölf Monate Audit-Log-Historie, die letzten drei Monate sofort verfügbar.

Driftet die Uhr, was taugt das Protokoll dann? Liegen zwei Geräte zehn Minuten auseinander, erscheinen ihre Einträge nebeneinander in falscher Reihenfolge. Deshalb ist der erste Schritt zentraler Protokollierung nicht der Collector, sondern die Zeitquelle. Das oben gezeigte Element timeQuality ist die Art, wie ein RFC-5424-Absender meldet, ob er diese Quelle hat.

Syslog in der Praxis: das Rauschen filtern

Die eigentliche Arbeit beginnt, wenn die Logs fließen, denn Sammeln ist nicht Lesen.

Labor: Wie viel sagt ein Switch in einer Minute?

Die übliche Antwort lautet: „Ein Switch sagt kaum etwas, ab und zu fällt ein Port aus.“ Ich habe gemessen. Den Laborswitch an einen frisch aufgesetzten Collector angeschlossen, sonst nichts getan, sechzig Sekunden gewartet:

60 satır / 8.670 bayt

Das ist türkisch für „60 Zeilen / 8.670 Byte“; die Messzusammenfassung wurde auf Türkisch notiert. Bei dieser Rate erzeugt ein einziger Switch rund 11 MB am Tag, rund 4,3 GB im Jahr, während nichts passiert. Legen Sie das PCI-DSS-Fenster von oben an, füllt ein einziger untätiger Switch allein rund 4 GB Pflichtaufbewahrung; multiplizieren Sie mit Ihrer Switch-Anzahl, bevor Sie die Platte des Collectors dimensionieren.

Überraschend ist nicht die Zahl, sondern der Inhalt. Von 149 gesammelten Zeilen stammten 148 vom Programm DOT1S und eine von CLI_WEB. Der eine aussagekräftige Eintrag war sieben Promille des Volumens:

<190> Aug 19 07:01:59 sercebilisimsw01-1 CLI_WEB[emWeb]: %% [CLI:ilker:192.168.1.115] User has succesfully logged in

Wer sich wann von wo als Administrator am Switch angemeldet hat: die erste Zeile, nach der Sie bei einer Sicherheitsfrage suchen, begraben unter 148 anderen.

Eine hundertfach wiederholte Zeile ist ein Störungszeichen

Die 148 Zeilen Rauschen waren zwei abwechselnde Meldungen:

<187> DOT1S[dtlTask]: dot1s_txrx.c(306) %% dot1sBpduReceive(): Discarding the BPDU, since it is an invalid BPDU type
<189> DOT1S[dtlTask]: dot1s_txrx.c(1286) %% dot1sBpduReceive(): Invalid Forward Delay

Alle zwei Sekunden, ohne Pause. Der Switch empfing Nachrichten des Protokolls, das Netzschleifen verhindert (Spanning Tree), und verwarf sie, weil er sie nicht deuten konnte.

Die Regel: Eine sekündlich wiederholte Meldung ist keine Information, sondern ein Symptom. Wiederholung macht sie nicht unwichtig; sie zeigt, dass im Hintergrund etwas Ungelöstes läuft. Dieselbe Regel sagt aber auch, dass sie nicht unverändert ins Archiv gehört.

Was behalten, was verwerfen?

Filtern geschieht in drei Stufen: Schwellenwert beim Absender (debug dauerhaft an ist die größte Rauschquelle; bei Firewalls vorab festlegen, welche Regelsätze protokolliert werden), Trennung beim Collector (Dateien nach Gerät und Prozess; mit DOT1S und CLI_WEB in einer Datei verschwindet die zweite) und Wiederholungsunterdrückung und Aufbewahrung (Wiederholungen zu einer Zeile zusammenfassen, ältere Einträge nach Ihrer Aufbewahrungsregel komprimieren und archivieren). Überspringen Sie alle drei, ist das Ende absehbar: Die Platte läuft voll, die Protokollierung stoppt, und Sie merken es an dem Tag, an dem Sie die Logs brauchen.

Fazit: ohne Protokollführer hat die Verhandlung nie stattgefunden

Syslog ist nicht kompliziert. Ein Gerät schreibt eine Zeile, packt zwei Angaben ins Prioritätsfeld und sendet sie an Port 514. Lernen muss man nicht das Protokoll, sondern was es nicht garantiert: weder Zustellung noch Absenderidentität, weder Unverändertheit noch eine richtige Uhr. Jedes davon ist eine Schicht, die Sie bauen. RFC 5424 hilft an den Rändern, bis dahin, dass ein Absender die Verlässlichkeit seiner Uhr angeben kann, aber der Collector muss diese Angabe behalten und prüfen.

Und die Messung zeigte: Ein Switch sagt sechzig Zeilen pro Minute, während nichts passiert. Neunundneunzig Prozent sagen Ihnen vielleicht nichts. Die restlichen sieben Promille sind der einzige Beleg dafür, wer sich um drei Uhr nachts angemeldet hat. Wenn Sie diesen Eintrag nicht sammeln, hat das Ereignis nie stattgefunden.