In der Informatik ist Syslog ( ausgesprochen / ˈsɪslɒɡ / ) ein Standard für die Protokollierung von Meldungen . Er ermöglicht die Trennung der Software, die Meldungen generiert, des Systems , das sie speichert, und der Software , die sie auswertet und analysiert. Jede Meldung wird mit einem Facility-Code gekennzeichnet, der den Typ des Systems angibt, das die Meldung generiert, und ihr wird ein Schweregrad zugewiesen.

Systementwickler nutzen Syslog für Systemverwaltung und Sicherheitsüberprüfungen sowie für allgemeine Informations-, Analyse- und Debugging-Meldungen. Eine Vielzahl von Geräten, wie Drucker, Router und Message Receiver auf verschiedenen Plattformen, verwendet den Syslog-Standard. Dies ermöglicht die Zusammenführung von Protokolldaten verschiedener Systeme in einem zentralen Repository. Syslog-Implementierungen existieren für viele Betriebssysteme.

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

Geschichte

Syslog wurde in den 1980er Jahren von Eric Allman im Rahmen des Sendmail- Projekts entwickelt . [ 1 ] Es fand schnell Anklang bei anderen Anwendungen und ist seither die Standardlösung für die Protokollierung auf Unix-ähnlichen Systemen. [ 2 ] Auch für andere Betriebssysteme existieren diverse Implementierungen, und Syslog ist häufig in Netzwerkgeräten wie Routern zu finden . [ 3 ]

Syslog fungierte ursprünglich als De-facto-Standard ohne offizielle, veröffentlichte Spezifikation, und es existierten zahlreiche Implementierungen, von denen einige inkompatibel waren. Die Internet Engineering Task Force dokumentierte den Status quo im August 2001 in RFC 3164. Die Standardisierung erfolgte im März 2009 durch RFC 5424. [ 4 ]

Verschiedene Unternehmen haben versucht, Patente für spezifische Aspekte von Syslog-Implementierungen zu beanspruchen. [ 5 ] [ 6 ] Dies hatte jedoch nur geringe Auswirkungen auf die Nutzung und Standardisierung des Protokolls.

Nachrichtenkomponenten

Die vom Absender einer Syslog-Meldung bereitgestellten Informationen umfassen den Facility-Code und den Schweregrad. Die Syslog-Software fügt dem Informationsheader weitere Informationen hinzu, bevor der Eintrag an den Syslog-Empfänger weitergeleitet wird. Zu diesen Komponenten gehören die Prozess-ID des Absenders, ein Zeitstempel und der Hostname oder die IP-Adresse des Geräts.

Einrichtung

Ein Facility-Code dient zur Angabe des Systemtyps, der die Nachricht protokolliert. Nachrichten mit unterschiedlichen Facility-Codes können unterschiedlich behandelt werden. [ 7 ] Die Liste der verfügbaren Facility-Codes ist in der Norm beschrieben: [ 4 ] : 9

Anlagencode Stichwort Beschreibung
0KernKernelmeldungen
1BenutzerBenutzerbezogene Nachrichten
2PostPostsystem
3DämonSystemdienste
4AutorisierungSicherheits-/Authentifizierungsmeldungen
5syslogIntern von syslogd generierte Meldungen
6lprZeilendrucker-Subsystem
7NachrichtNetzwerk-Nachrichtensubsystem
8uucpUUCP- Subsystem
9CronCron-Subsystem
10AuthprivSicherheits- und Authentifizierungsmeldungen
11FTPFTP-Daemon
12ntpNTP-Subsystem
13SicherheitProtokollprüfung
14KonsoleProtokollwarnung
15solaris-cronScheduling-Daemon
16–23local0 – local7Lokal genutzte Einrichtungen

Die Zuordnung zwischen Anlagencode und Schlüsselwort ist in verschiedenen Betriebssystemen und Syslog-Implementierungen nicht einheitlich. [ 8 ]

Schweregrad

Die Liste der Schweregrade der Probleme ist ebenfalls in der Norm beschrieben: [ 4 ] : 10

WertSchwereStichwortVeraltete SchlüsselwörterBeschreibungZustand
0Notfallemergpanic[ 9 ]Das System ist unbrauchbar.Eine Panikattacke. [ 10 ]
1AlarmalertEs müssen unverzüglich Maßnahmen ergriffen werden.Ein Zustand, der umgehend behoben werden sollte, wie beispielsweise eine beschädigte Systemdatenbank. [ 10 ]
2KritischcritKritischer ZustandHardwarefehler. [ 10 ]
3Fehlererrerror[ 9 ]Fehlerbedingungen
4Warnungwarningwarn[ 9 ]Warnbedingungen
5BeachtennoticeNormale, aber signifikante ZuständeZustände, die keine Fehlerzustände darstellen, aber möglicherweise eine besondere Behandlung erfordern. [ 10 ] [ 11 ]
6InformationsinfoInformationsmitteilungenBestätigung, dass das Programm wie erwartet funktioniert.
7DebuggendebugDebug-MeldungenMeldungen, die Informationen enthalten, die normalerweise nur beim Debuggen eines Programms von Nutzen sind. [ 10 ]

Die Bedeutung der Schweregrade außer „Notfall“ und „Debug“ ist anwendungsabhängig. Wenn das System beispielsweise Transaktionen verarbeitet, um Kundenkontostände zu aktualisieren, sollte einem Fehler im letzten Schritt der Schweregrad „Warnung“ zugewiesen werden. Tritt hingegen ein Fehler beim Versuch auf, die Postleitzahl des Kunden anzuzeigen, kann ihm der Schweregrad „Fehler“ oder sogar „Warnung“ zugewiesen werden .

Der Serverprozess, der die Anzeige von Meldungen verarbeitet, schließt normalerweise alle niedrigeren (schwerwiegenderen) Stufen ein, wenn die Anzeige weniger schwerwiegender Stufen angefordert wird. Das heißt, wenn Meldungen nach ihrer jeweiligen Schwere getrennt sind, wird beim Filtern nach Meldungen der Stufen „Hinweis“ , „Info“ und „Debug“ auch ein Eintrag der Stufe „Warnung“ berücksichtigt . [ 12 ]

Nachricht

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

In RFC 5424 [ 4 ] wird beschrieben : „MSG entspricht dem, was in RFC 3164 als CONTENT bezeichnet wurde. Das TAG ist nun Teil des Headers, jedoch nicht mehr als einzelnes Feld. Das TAG wurde in APP-NAME, PROCID und MSGID aufgeteilt. Dies entspricht nicht vollständig der ursprünglichen Verwendung des TAGs, bietet aber in den meisten Fällen dieselbe Funktionalität.“ Gängige Syslog-Tools wie NXLog und Rsyslog entsprechen diesem neuen Standard.

Das Inhaltsfeld sollte im UTF-8- Zeichensatz kodiert werden, und Oktettwerte im traditionellen ASCII-Steuerzeichenbereich sollten vermieden werden. [ 13 ] [ 4 ]

Logger

Generierte Logmeldungen können an verschiedene Ziele gesendet werden, darunter Konsole , Dateien, entfernte Syslog-Server oder Relays. Die meisten Implementierungen bieten ein Befehlszeilenprogramm, oft als Logger bezeichnet , sowie eine Softwarebibliothek zum Senden von Meldungen an das Log. [ 14 ]

Zum Anzeigen und Überwachen der gesammelten Protokolle ist eine Client-Anwendung erforderlich oder man greift direkt auf die Protokolldatei im System zu. 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 beinhalten Berichtsprogramme zum Filtern und Anzeigen von Syslog-Meldungen.

Netzwerkprotokoll

Bei der Netzwerkprotokollierung verwendet Syslog eine Client-Server -Architektur, bei der der Server an einem bekannten oder registrierten Port auf Protokollanfragen von Clients wartet. Traditionell war das User Datagram Protocol (UDP) das am häufigsten verwendete Transportprotokoll für die Netzwerkprotokollierung, wobei der Server an Port 514 lauschte. [ 15 ] Da UDP keine Mechanismen zur Staukontrolle bietet, wird der Port 6514 des Transmission Control Protocol (TCP) verwendet. Transport Layer Security (TLS) ist in Implementierungen ebenfalls erforderlich und wird für die allgemeine Verwendung empfohlen. [ 16 ] [ 17 ]

Einschränkungen

Da jeder Prozess, jede Anwendung und jedes Betriebssystem unabhängig entwickelt wurde, gibt es kaum Einheitlichkeit im Inhalt der Log-Nachrichten. Daher werden keine Annahmen über deren Formatierung oder Inhalt getroffen. Eine Syslog-Nachricht ist formatiert (RFC 5424 definiert die erweiterte Backus-Naur-Form (ABNF)), ihr MSG-Feld jedoch nicht.

Das Netzwerkprotokoll ist eine Simplex-Kommunikation ohne Möglichkeit, den Empfang der Nachricht an den Absender zu bestätigen.

Ausblick

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

Vorschriften wie der Sarbanes-Oxley Act , PCI DSS , HIPAA und viele andere verpflichten Unternehmen zur Implementierung umfassender Sicherheitsmaßnahmen, die häufig das Sammeln und Analysieren von Protokollen aus verschiedenen Quellen beinhalten. Das Syslog-Format hat sich bei der Konsolidierung von Protokollen bewährt, da zahlreiche Open-Source- und proprietäre Tools für die Berichterstellung und Analyse dieser Protokolle verfügbar sind. Es existieren Dienstprogramme zur Konvertierung von Windows-Ereignisprotokollen und anderen Protokollformaten in das Syslog-Format.

Anbieter von Managed Security Services versuchen, mithilfe von Analyseverfahren und Algorithmen der künstlichen Intelligenz Muster zu erkennen und Kunden auf Probleme aufmerksam zu machen. [ 19 ]

Internet-Standarddokumente

Das Syslog-Protokoll ist in den von der Internet Engineering Task Force (IETF) veröffentlichten Request for Comments (RFC)-Dokumenten ( Internetstandards ) definiert . Nachfolgend eine Liste der RFCs, die das Syslog-Protokoll definieren: [ 20 ]

  • Das BSD-Syslog-Protokoll . IETF . RFC  3164 .(veraltet durch das Syslog-Protokoll . IETF . RFC 5424 .) )
  • Zuverlässige Zustellung für syslog . IETF . RFC  3195 .
  • Das Syslog-Protokoll . IETF . RFC  5424 .
  • TLS-Transportmapping für Syslog . IETF . RFC  5425 .
  • Übertragung von Syslog-Meldungen über UDP . IETF . RFC  5426 .
  • Textuelle Konventionen für die Syslog-Verwaltung . IETF . RFC  5427 .
  • Signierte Syslog-Meldungen . IETF . RFC  5848 .
  • Datagramm-Transportschichtsicherheit (DTLS)-Transportmapping für Syslog . IETF . RFC  6012 .
  • Übertragung von Syslog-Meldungen über TCP . IETF . RFC  6587 .

Siehe auch

Referenzen

  1. ^ „Eric Allman“ . Internet Hall of Fame . Abgerufen am 30.10.2017 .
  2. ^ „3 großartige Ingenieurstellen, auf die Sie sich diese Woche bewerben sollten“ . VentureBeat . 06.08.2021 . Abgerufen am 16.08.2021 .
  3. ^ Zhang, Shenglin; Liu, Ying; Meng, Weibin; Bu, Jiahao; Yang, Sen; Sonne, Yongqian; Pei, Dan; Xu, Jun; Zhang, Yuzhi; Lied, Lei; Zhang, Ming (2020). „Effizientes und robustes Syslog-Parsing für Netzwerkgeräte in Rechenzentrumsnetzwerken“ . IEEE-Zugriff . 8 : 30245–30261 . Bibcode : 2020IEEEA...830245Z . doi : 10.1109/ACCESS.2020.2972691 .
  4. ^ a b c d e Gerhards, Rainer. Das Syslog-Protokoll . IETF . doi : 10.17487/RFC5424 . RFC 5424 .
  5. ^ "LXer: Patent gefährdet IETF-Syslog-Standard" .
  6. ^ „IETF IPR-Offenlegung zu den Patentansprüchen von HUAWEI“ .
  7. ^ „Syslog Facility“ . Abgerufen am 22. November 2012 .
  8. ^ „Die Grundlagen der Systemprotokollierung mit Syslog“ . SANS Institute .
  9. ^ a b c „syslog.conf(5) – Linux-Manpage“ . Abgerufen am 29.03.2017 . Die Schlüsselwörter error, warn und panic sind veraltet und sollten nicht mehr verwendet werden.
  10. ^ a b c d e "closelog, openlog, setlogmask, syslog - Kontrollsystemprotokoll" . Abgerufen am 29.03.2017 . LOG_NOTICE: Zustände, die keine Fehlerzustände darstellen, aber möglicherweise eine Sonderbehandlung erfordern.
  11. ^ „Die GNU C-Bibliothek: syslog, vsyslog“ . Abgerufen am 19.07.2024 . LOG_NOTICE Die Meldung beschreibt ein normales, aber wichtiges Ereignis.
  12. ^ „Schweregrade für Syslog-Meldungen“ . cd.delphix.com . Abgerufen am 2024-10-02 .
  13. ^ „Übertragung von Syslog-Meldungen über TCP“ . www.ipa.go.jp. Abgerufen am 16.08.2021 .
  14. ^ „Logger-Befehl“ . www.ibm.com . Abgerufen am 16.08.2021 .
  15. ^ „Syslog-Server“ . www.howtonetwork.com . Abgerufen am 16.08.2021 .
  16. ^ Gerhards, Rainer (März 2009). „RFC 5424 – Das Syslog-Protokoll“ . tools.ietf.org . doi : 10.17487/RFC5424 .
  17. ^ Fuyou, Miao; Yuzhi, Ma; Salowey, Joseph A. (März 2009). Miao, F; Ma, Y; Salowey, J (Hrsg.). „RFC 5425 – TLS Transport Mapping für Syslog“ . tools.ietf.org . doi : 10.17487/RFC5425 .
  18. ^ „ATNA + SYSLOG ist ausreichend“ . Standards für den Gesundheitsaustausch . 2. Januar 2012. Abgerufen am 6. Juni 2018 .
  19. ^ Yamanishi, Kenji; Maruyama, Yuko (21.08.2005). „Dynamisches Syslog-Mining zur Überwachung von Netzwerkausfällen“ . Proceedings der elften ACM SIGKDD International Conference on Knowledge Discovery in Data Mining . KDD '05. Chicago, Illinois, USA: Association for Computing Machinery. S.  499–508 . doi : 10.1145/1081870.1081927 . ISBN 978-1-59593-135-1S2CID  5051532 .​
  20. ^ „Sicherheitsprobleme bei der Netzwerkereignisprotokollierung (syslog)“ . IETF.