Syslog - Syslog

Syslog
Originalautor(en) Eric Allman
Erstveröffentlichung 1980er Jahre
Betriebssystem Unix-ähnlich
Typ Systemprotokollierung
Webseite datatracker .ietf .org /wg /syslog /charter / Bearbeiten Sie dies auf Wikidata

In der Berechnung , syslog / s ɪ s l ɒ ɡ / ist ein Standard für die Nachrichtenprotokollierung . Es ermöglicht die Trennung zwischen der Software, die Nachrichten generiert, dem System, das sie speichert, und der Software, die sie meldet und analysiert. Jede Nachricht ist mit einem Einrichtungscode gekennzeichnet, der den Typ des Systems angibt, das die Nachricht generiert, und wird einem Schweregrad zugewiesen.

Computersystemdesigner können syslog für die Systemverwaltung und Sicherheitsüberprüfung sowie für allgemeine Informations-, Analyse- und Debugging-Nachrichten verwenden. Eine Vielzahl von Geräten wie Drucker, Router und Nachrichtenempfänger auf vielen Plattformen verwenden den Syslog-Standard. Dies ermöglicht die Zusammenführung von Logging-Daten aus unterschiedlichen Systemtypen in einem zentralen Repository. Implementierungen von syslog existieren für viele Betriebssysteme.

Beim Betrieb über ein Netzwerk verwendet Syslog eine Client-Server- Architektur, bei der ein Syslog-Server auf Nachrichten von Clients lauscht und diese protokolliert.

Geschichte

Syslog wurde in den 1980er Jahren von Eric Allman im Rahmen des Sendmail- Projekts entwickelt. Es wurde leicht von anderen Anwendungen übernommen und ist seitdem die Standard-Logging-Lösung auf Unix-ähnlichen Systemen. Es gibt auch eine Vielzahl von Implementierungen auf anderen Betriebssystemen und wird häufig in Netzwerkgeräten wie Routern gefunden .

Syslog funktionierte ursprünglich als De-facto-Standard ohne eine maßgebliche veröffentlichte Spezifikation, und es gab viele Implementierungen, von denen einige inkompatibel waren. Die Internet Engineering Task Force dokumentierte den Status Quo in RFC 3164. Er wurde durch RFC 5424 standardisiert.

Verschiedene Unternehmen haben versucht, Patente für bestimmte Aspekte von Syslog-Implementierungen zu beanspruchen. Dies hatte wenig Auswirkungen auf die Verwendung und Standardisierung des Protokolls.

Nachrichtenkomponenten

Die vom Absender einer Syslog-Nachricht bereitgestellten Informationen umfassen den Einrichtungscode und den Schweregrad. Die Syslog-Software fügt dem Informationsheader Informationen hinzu, bevor sie den Eintrag an den Syslog-Empfänger weiterleitet. Zu diesen Komponenten gehören eine Absenderprozess-ID, ein Zeitstempel und der Hostname oder die IP-Adresse des Geräts.

Einrichtung

Ein Einrichtungscode wird verwendet, um den Systemtyp anzugeben, der die Nachricht protokolliert. Nachrichten mit unterschiedlichen Einrichtungen können unterschiedlich behandelt werden. Die Liste der verfügbaren Einrichtungen wird durch die Norm definiert:

Einrichtungscode Stichwort Beschreibung
0 kern Kernel-Nachrichten
1 Benutzer Nachrichten auf Benutzerebene
2 mail Mailsystem
3 Dämon System-Daemons
4 auth Sicherheits-/Authentifizierungsnachrichten
5 syslog Intern von syslogd generierte Nachrichten
6 lpr Zeilendrucker-Subsystem
7 Nachrichten Subsystem für Netzwerknachrichten
8 uucp UUCP-Subsystem
9 cron Cron-Subsystem
10 authentifiziert Sicherheits-/Authentifizierungsnachrichten
11 ftp FTP-Daemon
12 ntp NTP-Subsystem
13 Sicherheit Log-Audit
14 Konsole Protokollwarnung
fünfzehn solaris-cron Planungs-Daemon
16–23 local0 – local7 Lokal genutzte Einrichtungen

Die Zuordnung zwischen Einrichtungscode und Schlüsselwort ist in verschiedenen Betriebssystemen und Syslog-Implementierungen nicht einheitlich.

Schweregrad

Die Liste der Schweregrade wird ebenfalls durch die Norm definiert:

Wert Schwere Stichwort Veraltete Keywords Beschreibung Zustand
0 Notfall emerg panic System ist unbrauchbar Ein Panikzustand.
1 Alarm alert Es muss sofort gehandelt werden Eine Bedingung, die sofort korrigiert werden sollte, z. B. eine beschädigte Systemdatenbank.
2 Kritisch crit Kritische Bedingungen Hardwarefehler.
3 Fehler err error Fehlerbedingungen
4 Warnung warning warn Warnbedingungen
5 Notiz notice Normale, aber signifikante Bedingungen Bedingungen, die keine Fehlerbedingungen sind, aber möglicherweise eine besondere Behandlung erfordern.
6 Information info Informationsnachrichten
7 Debuggen debug Meldungen auf Debug-Ebene Nachrichten, die Informationen enthalten, die normalerweise nur beim Debuggen eines Programms verwendet werden.

Die Bedeutung anderer Schweregrade als Emergency und Debug bezieht sich auf die Anwendung. Wenn der Zweck des Systems beispielsweise darin besteht, Transaktionen zu verarbeiten, um die Kontostandsinformationen von Kunden zu aktualisieren, sollte einem Fehler im letzten Schritt die Warnstufe zugewiesen werden. Doch ein Fehler bei dem Versuch auftritt , die angezeigt werden Postleitzahl kann zugewiesen des Kunden Fehler oder sogar Warnung Ebene.

Der Serverprozess, der die Anzeige von Nachrichten handhabt, umfasst normalerweise alle niedrigeren (schwerwiegenderen) Stufen, wenn die Anzeige von weniger schwerwiegenden Stufen angefordert wird. Das heißt, wenn Nachrichten nach individuellem Schweregrad getrennt sind, wird beim Filtern nach Hinweis- , Info- und Debug- Nachrichten auch ein Eintrag für die Warnstufe hinzugefügt .

Nachricht

In RFC 3164 wurde die Nachrichtenkomponente (bekannt als MSG) mit folgenden Feldern angegeben: TAG , der der Name des Programms oder Prozesses sein sollte, der die Nachricht generiert hat, und CONTENT, der die Details der Nachricht enthält.

In RFC 5424 beschrieben: "MSG ist das, was in RFC 3164 als CONTENT bezeichnet wurde. Das TAG ist jetzt Teil des Headers, aber nicht als einzelnes Feld. Das TAG wurde in APP-NAME, PROCID und MSGID aufgeteilt. Dies ist nicht der Fall ähneln völlig der Verwendung von TAG, bieten aber in den meisten Fällen die gleiche Funktionalität." Beliebte Syslog-Tools wie Rsyslog entsprechen diesem neuen Standard.

Das Inhaltsfeld sollte in einem UTF-8- Zeichensatz kodiert sein und Oktettwerte im traditionellen ASCII-Steuerzeichenbereich sollten vermieden werden.

Logger

Generierte Protokollnachrichten können an verschiedene Ziele geleitet werden, einschließlich Konsole , Dateien, entfernte Syslog-Server oder Relays. Die meisten Implementierungen bieten ein Befehlszeilendienstprogramm, das oft als logger bezeichnet wird , sowie eine Softwarebibliothek zum Senden von Nachrichten an das Protokoll.

Um die gesammelten Protokolle anzuzeigen und zu überwachen, muss man eine Client-Anwendung verwenden oder direkt auf die Protokolldatei auf dem System zugreifen. Die grundlegenden Befehlszeilentools sind tail und grep . Die Protokollserver können so konfiguriert werden, dass sie die Protokolle (zusätzlich zu den lokalen Dateien) über das Netzwerk senden. Einige Implementierungen umfassen Berichtsprogramme zum Filtern und Anzeigen von Syslog-Meldungen.

Netzwerkprotokoll

Beim Betrieb über ein Netzwerk verwendet syslog eine Client-Server- Architektur, bei der der Server an einem bekannten oder registrierten Port auf Protokollanforderungen von Clients lauscht . In der Vergangenheit war das gebräuchlichste Transportschichtprotokoll für die Netzwerkprotokollierung das User Datagram Protocol (UDP), bei dem der Server auf Port 514 lauscht. Da UDP keine Überlastungskontrollmechanismen besitzt, ist die Unterstützung für Transport Layer Security in Implementierungen erforderlich und wird für die allgemeine Verwendung bei Übertragung empfohlen Control Protocol (TCP)-Port 6514.

Einschränkungen

Da jeder Prozess, jede Anwendung und jedes Betriebssystem unabhängig geschrieben wurde, ist die Nutzlast der Protokollnachricht wenig einheitlich. Aus diesem Grund werden keine Annahmen über deren Formatierung oder Inhalt gemacht. Eine Syslog-Nachricht wird formatiert (RFC 5424 gibt die Definition des Augmented Backus-Naur-Formulars (ABNF) an), das MSG-Feld jedoch nicht.

Das Netzwerkprotokoll ist Simplex-Kommunikation , ohne die Möglichkeit, die Zustellung an den Absender zu bestätigen.

Ausblick

Verschiedene Gruppen arbeiten an Normenentwürfen, die die Verwendung von syslog für mehr als nur die Protokollierung von Netzwerk- und Sicherheitsereignissen detailliert beschreiben, wie beispielsweise die vorgeschlagene Anwendung im Gesundheitswesen.

Vorschriften wie der Sarbanes-Oxley Act , PCI DSS , HIPAA und viele andere verlangen von Unternehmen die Implementierung umfassender Sicherheitsmaßnahmen, zu denen häufig das Sammeln und Analysieren von Protokollen aus vielen verschiedenen Quellen gehört. Das Syslog-Format hat sich bei der Konsolidierung von Protokollen als effektiv erwiesen, da es viele Open-Source- und proprietäre Tools für die Berichterstellung und Analyse dieser Protokolle gibt. Es gibt Dienstprogramme für die Konvertierung vom Windows-Ereignisprotokoll und anderen Protokollformaten in Syslog.

Managed Security Service Provider versuchen, analytische Techniken und Algorithmen der künstlichen Intelligenz anzuwenden, um Muster zu erkennen und Kunden auf Probleme aufmerksam zu machen.

Internet-Standarddokumente

Das Syslog-Protokoll wird durch Request for Comments (RFC)-Dokumente definiert, die von der Internet Engineering Task Force ( Internet Standards ) veröffentlicht wurden. Im Folgenden finden Sie eine Liste von RFCs, die das Syslog-Protokoll definieren:

  • Das BSD-syslog-Protokoll . RFC  3164 .(veraltet durch The Syslog Protocol . RFC  5424 .)
  • Zuverlässige Lieferung für Syslog . RFC  3195 .
  • Das Syslog-Protokoll . RFC  5424 .
  • TLS-Transport-Mapping für Syslog . RFC  5425 .
  • Übertragung von Syslog-Meldungen über UDP . RFC  5426 .
  • Textkonventionen für die Syslog-Verwaltung . RFC  5427 .
  • Signierte Syslog-Nachrichten . RFC-  5848 .
  • Datagram Transport Layer Security (DTLS)-Transportzuordnung für Syslog . RFC-  6012 .
  • Übertragung von Syslog-Meldungen über TCP . RFC  6587 .

Siehe auch

Verweise

Externe Links