Syslog steht für System Logging Protocol und ist ein Standard-Protokoll, das verwendet wird, um Systemprotokoll- oder Ereignismeldungen an einen spezifischen Server zu senden, der als Syslog-Server bezeichnet wird. Es wird in erster Linie verwendet, um unterschiedliche Geräteprotokolle von mehreren verschiedenen Computern an einem zentralen Standort für Überwachungs- und Kontrollzwecke zu sammeln.
Das Protokoll ist an den meisten Netzwerkgeräten wie Routern, Switches, Firewalls und sogar an manchen Druckern und Scannern aktiviert. Darüber hinaus ist Syslog an Unix- und Linux-basierten Systemen und vielen Webservern wie Apache verfügbar. An Windows-Systemen, die Ihr eigenes Windows-Ereignisprotokoll verwenden, ist Syslog standardmäßig nicht installiert. Diese Ereignisse können über Hilfsprogramme von Drittanbietern oder andere Konfigurationen mit dem Syslog-Protokoll weitergeleitet werden.
Syslog ist in RFC 5424, dem Syslog-Protokoll, definiert, das die frühere Version RFC 3164 ersetzt.
Syslog-Komponenten
An jedem bestimmten Gerät werden vom System verschiedene Ereignisse als Reaktion auf sich ändernde Bedingungen generiert. Diese Ereignisse werden gewöhnlich lokal protokolliert, wo sie von einem Administrator überprüft und analysiert werden können. Die Überwachung vieler Protokolle über eine ebenso große Anzahl von Routern, Switches und Systemen wäre jedoch zeitaufwendig und unpraktisch. Um dieses Problem zu lösen, leitet Syslog diese Ereignisse an einen zentralisierten Server weiter.
Syslog-Übertragung
Traditionell verwendet Syslog das UDP-Protokoll an Port 514, kann aber für jeden Port konfiguriert werden. Darüber hinaus verwenden manche Geräte TCP 1468 zum Senden von Syslog-Daten, um eine Bestätigung der Meldungszustellung zu erhalten.
Die Syslog-Paketübertragung erfolgt asynchron. Was zur Generierung einer Syslog-Meldung führt, wird im Router, Switch oder Server selbst konfiguriert. Anders als bei anderen Überwachungsprotokollen wie SNMP gibt es keinen Mechanismus zum Abfragen der Syslog-Daten. Bei manchen Implementierungen kann SNMP verwendet werden, um Syslog-Parameter remote einzustellen oder zu ändern.
Eine Syslog-Meldung besteht aus drei Teilen: PRI (ein berechneter Prioritätswert), HEADER (mit Informationen zur Identifizierung) und MSG (die eigentliche Meldung).
Die über das Syslog-Protokoll gesendeten PRI-Daten setzen sich aus zwei numerischen Werten zusammen, die bei der Kategorisierung der Meldung helfen. Der erste ist der Ursprungswert. Dieser Wert ist einer von 15 vordefinierten Werten oder verschiedenen lokal definierten Werten (die Werte von 16 bis 23). Sie kategorisieren den Meldungstyp oder das System, das das Ereignis erzeugt hat.
| Zahl | Beschreibung des Meldungstyps/Systems |
| 0 | Kernel-Meldungen |
| 1 | Meldungen auf Benutzerebene |
| 2 | E-Mail-System |
| 3 | System Daemons |
| 4 | Sicherheits-/Autorisierungsmeldungen |
| 5 | Von Syslog generierte Meldungen |
| 6 | Zeilendrucker-Subsystem |
| 7 | Netzwerk-News-Subsystem |
| 8 | UUCP-Subsystem |
| 9 | Clock Daemon |
| 10 | Sicherheits-/Autorisierungsmeldungen |
| 11 | FTP Daemon |
| 12 | NTP-Subsystem |
| 13 | Protokollüberwachung |
| 14 | Protokollwarnung |
| 15 | Clock Daemon |
| 16 - 23 | Lokale Verwendung 0 - 7 |
Der zweite Wert einer Syslog-Meldung kategorisiert die Wichtigkeit bzw. den Schweregrad der Meldung mit einem numerischen Code von 0 bis 7.
| Code | Schweregrad | Beschreibung |
| 0 | Notfall | Das System ist nicht verwendbar |
| 1 | Alarm | Es müssen sofortige Maßnahmen ergriffen werden |
| 2 | Kritisch | Kritische Zustände |
| 3 | Fehler | Fehlerzustände |
| 4 | Warnung | Warnzustände |
| 5 | Hinweis | Normaler, aber signifikanter Zustand |
| 6 | Information | Informationsmeldungen |
| 7 | Debug | Meldungen auf Debugebene |
Für beide Werte gibt es keine unumstößlichen Definitionen. Es ist daher Sache des Systems oder der Anwendung zu bestimmen, wie ein Ereignis protokolliert werden soll (zum Beispiel als Warnung, Hinweis oder etwas anderes) und für welchen Meldungstyp/welches System dies geschehen soll. Innerhalb derselben Anwendung bzw. desselben Dienstes sollten niedrigere Werte schwerwiegenderen, den spezifischen Prozess betreffenden Problemen entsprechen.
Die beiden Werte werden zu einem Prioritätswert kombiniert, der zusammen mit der Meldung gesendet wird. Um den Prioritätswert zu berechnen, wird der Ursprungswert mit acht multipliziert und dann wird der Schweregrad zum Ergebnis addiert. Je niedriger der PRI, desto höher die Priorität.
(Ursprungswert x 8) + Schweregrad = PRI
Auf diese Weise erhält eine Kernel-Meldung einen niedrigeren Wert (höhere Priorität) als eine Protokollwarnung, unabhängig vom Schweregrad der Protokollwarnung. Zusätzliche Bezeichner im Paket sind Hostname, IP-Adresse, Prozess-ID, App-Name und Zeitstempel der Meldung.
Der eigentliche Wortlaut bzw. Inhalt der Syslog-Meldung wird vom Protokoll nicht definiert. Manche Meldungen bestehen aus einfachem, lesbarem Text, andere dagegen sind eventuell nur maschinenlesbar.
Syslog-Meldungen sind gewöhnlich nicht länger als 1024 Bytes.
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com - ID47 [exampleSDID@32473 iut="3" eventSource=" eventID="1011"] BOMAn application log entry...
Teile der Syslog-Meldung:
| Part | Value | Information |
| PRI | 165 | Ursprung = 20, Schweregrad = 5 |
| VERSION | 1 | Version 1 |
| TIMESTAMP | 2017-05-11T21:14:15.003Z | Meldung erstellt am 11. Mai 2017 um 21:14:15 Uhr plus 3 Millisekunden |
| HOSTNAME | mymachine.example.com | Die Meldung kam vom Host "mymachine.example.com" |
| APP-NAME | su | App-Name: "su" |
| PROCID | - | PROCID unbekannt |
| MSGID | ID47 | Meldungs-ID: 47 |
| STRUCTURED-DATA | [exampleSDID@32473 iut="3" eventSource=" eventID="1011"] | Strukturiertes Datenelement mit nicht durch die IANA geregelter SD-ID vom Typ „exampleSDID@32473“ mit drei Parametern |
| MSG | BOMAn application log entry... | BOM gibt die UTF-8-Codierung an, die Meldung selbst ist „An application log entry...“ |
Der Syslog-Server ist auch als Syslog-Sammler oder -Empfänger bekannt.
Syslog-Meldungen werden vom generierenden Gerät zum Sammler gesendet. Die IP-Adresse des Syslog-Zielservers muss am Gerät selbst konfiguriert werden, entweder durch eine Befehlszeile oder mit einer Konfigurationsdatei. Sobald sie konfiguriert ist, werden alle Syslog-Daten zu dem betreffenden Server gesendet. Es gibt keinen Mechanismus innerhalb des Syslog-Protokolls, anhand dessen ein anderer Server Syslog-Daten anfordern könnte.
Während die meisten Unix-Implementierungen und Netzwerkanbieter wie Cisco ihre eigenen Syslog-Basisserver haben, sind auch einige andere erhältlich.
Paesslers PRTG Monitoring-Software enthält einen eingebauten Syslog-Empfängersensor. Der Empfänger sammelt alle übermittelten Syslog-Meldungen. Um die Funktion verwenden zu können, muss der Administrator den Syslog-Empfänger hinzufügen und dann die IP-Adresse dieses Servers als Zielserver für Syslog-Daten an allen überwachten Geräten konfigurieren.
Nach Sammlung der Meldungen zeigt das Dashboard Folgendes an:
- Die Anzahl empfangener Syslog-Meldungen pro Sekunde
- Die Anzahl der als „Warnung“ kategorisierten Meldungen pro Sekunde
- Die Anzahl der als „Fehler“ kategorisierten Meldungen pro Sekunde
- Die Anzahl verworfener Pakete pro Sekunde
Das Syslog-Protokoll kann viele Meldungen generieren. Syslog leitet Meldungen einfach genauso schnell weiter, wie es sie generiert. Infolgedessen besteht die wichtigste Fähigkeit eines Syslog-Servers darin, eingehende Syslog-Daten richtig zu filtern und auf sie zu reagieren.
Der PRTG Syslog-Empfängersensor bietet dem Benutzer die Möglichkeit, Filterregeln einzustellen. Anhand dieser Regeln können Syslog-Meldungen als Warnungen oder Fehler ein- oder ausgeschlossen werden, unabhängig davon, wie sie ursprünglich im Gerät generiert worden sind. Durch diese Filterung wird sichergestellt, dass Administratoren über alle Fehler informiert werden, die für sie wichtig sind, ohne von weniger wichtigen Fehlern überflutet zu werden.
Das Syslog-Protokoll enthält keinen Sicherheitsmechanismus. Es gibt keine eingebaute Authentifizierung, um sicherzustellen, dass Meldungen tatsächlich von dem Gerät kommen, das vorgibt, sie zu senden. Es gibt keine Verschlüsselung, die verbergen könnte, welche Informationen an den Server gesendet werden. Das Protokoll ist besonders anfällig für sogenannte „Wiedergabeangriffe“, bei denen ein Angreifer einen vorherigen Strom von Warnungen generiert, um eine Antwort hervorzurufen.
Gerätekonfiguration
Die meisten Syslog-Implementierungen sind dahingehend konfigurierbar, welche Meldungstypen/Systeme und welche Schweregrade Syslog-Ereignisse generieren, die an den Syslog-Server weitergeleitet werden. Es ist wichtig, diese Konfiguration richtig durchzuführen, um eine Überflutung des Servers (und des Netzwerks) mit unnötigem Datenverkehr zu vermeiden. Zum Beispiel sollte Debug außer für Tests niemals zum Senden von Meldungen eingestellt werden.
Es ist ratsam, die Syslog-Parameter so einzustellen, dass der höchstmögliche Meldungstyp und Schweregrad (d. h. der niedrigste Wert) erforderlich sind, damit der Datenverkehr minimal gehalten wird. Während ein Routerfehler darauf hinweisen könnte, dass eine Schnittstelle ausgefallen ist, was auf jeden Fall gemeldet werden muss, könnte ein weniger wichtiger Netzwerkdrucker so konfiguriert werden, dass nur für kritische Ereignisse Syslog-Meldungen generiert werden müssen.
Windows
Windows-Systeme implementieren Syslog nicht innerhalb des standardmäßigen Ereignisprotokollsystems. Die innerhalb des Windows-Protokollierungssystems generierten Ereignisse können mit Hilfsprogrammen von Drittanbietern gesammelt und an einen Syslog-Server weitergeleitet werden. Diese Hilfsprogramme überwachen das Ereignisprotokoll, benutzen die Informationen, um ein formatiertes Syslog-Ereignis zu erzeugen und leiten die Ereignisse mit dem Syslog-Standardprotokoll weiter.
Einschränkungen
Eine hauptsächliche Einschränkung des Syslog-Protokolls besteht darin, dass das überwachte Gerät eingeschaltet und mit dem Netzwerk verbunden sein muss, damit ein Syslog-Ereignis generiert und gesendet werden kann. Es ist möglich, dass bei einem kritischen Fehler des Kernels nie eine Fehlermeldung gesendet wird, wenn das System offline geht. Mit anderen Worten – Syslog ist keine gute Methode, um den ein- oder ausgeschalteten Zustand von Geräten zu überwachen.
Während Syslog eine gute Methode zur Statusüberwachung von Netzwerkgeräten darstellt, kann es auch eine gute Möglichkeit sein, den Gesamtzustand der Netzwerkausrüstung zu überwachen. Obwohl Netzwerküberwachungssoftware wie PRTG eine Suite von Hilfsprogrammen zur Beobachtung eines Netzwerks bereitstellt, wird ein Administrator durch nichts schneller auf ein Problem aufmerksam gemacht als durch ein Ereignisprotokoll, das sich mit Warnungen füllt. Durch richtig konfigurierte Syslog-Überwachung wird der plötzliche Anstieg des Volumens und Schweregrads von Ereignissen erkannt und es besteht die Möglichkeit, dass eine Meldung erfolgt, bevor ein vom Benutzer erkennbares Problem auftritt.
Sicherheit/Autorisierung/Überprüfung
Ein durchschnittliches Unternehmensnetzwerk enthält zahlreiche Geräte, auf die an einem normalen Tag niemand versuchen sollte zuzugreifen. Wenn ein Remote-Switch, an dem nur einmal pro Überwachungszyklus eine Anmeldung erfolgt, plötzlich tägliche Anmeldeversuche aufweist (erfolgreich oder nicht), sollte das überprüft werden. Bei dieser Art von Geräten kann Syslog eingestellt werden, um Authentifizierungsereignisse an einen Syslog-Server weiterzuleiten, ohne dass dafür extra ein vollständiger Überwachungs-Agent installiert und konfiguriert werden muss.
Syslog bietet auch eine Methode, durch die vermieden werden kann, dass kritische Ereignisse auf dem ursprünglichen Server protokolliert und gespeichert werden. Nachdem ein Angreifer ein System beeinträchtigt hat, versucht er als Erstes, seine Spuren im Protokoll zu verbergen. Ereignisse, die über Syslog weitergeleitet werden, sind außerhalb seiner Reichweite.
Anwendungsüberwachung
Es gibt viele Möglichkeiten zu monitoren, wie eine Anwendung auf einem Server läuft. Bei diesen Überwachungsarten kann jedoch übersehen werden, wie die Anwendung andere Prozesse auf dem Server beeinträchtigt. Während sich hohe CPU- oder Speicherauslastung mit anderen Überwachungsarten leicht genug erkennen lassen, können protokollierte Ereignisse weitere mögliche Probleme aufzeigen. Versucht eine Anwendung ständig, Zugriff auf eine gesperrte Datei zu erhalten? Liegt ein Schreibversuch in einer Datenbank vor, wodurch ein Fehler generiert wird? Ereignisse wie diese können unerkannt bleiben, wenn sie von Anwendungen verursacht werden, die geschickt um Fehler herum arbeiten können, sie sollten jedoch nicht ignoriert werden. Durch Syslog wird sichergestellt, dass diese protokollierten Ereignisse die Aufmerksamkeit erhalten, die sie verdienen.
Syslog als Teil der Netzwerk-Gesamtüberwachung
Für eine vollständige Netzwerküberwachung sind mehrere Tools erforderlich. Syslog ist ein wichtiger Bestandteil der Netzwerküberwachung, weil es dafür sorgt, dass Ereignisse, die ohne dramatische Auswirkungen stattfinden, nicht unbemerkt bleiben. Dabei hat sich Software bewährt, in der alle Tools kombiniert werden, damit immer eine Übersicht über die Geschehnisse im Netzwerk beibehalten wird.
