Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

State of syslog (2005)

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Nächste SlideShare
Schweben auf Wolke7
Schweben auf Wolke7
Wird geladen in …3
×

Hier ansehen

1 von 11 Anzeige

Weitere Verwandte Inhalte

Ähnlich wie State of syslog (2005) (20)

Anzeige

Weitere von Rainer Gerhards (14)

Aktuellste (20)

Anzeige

State of syslog (2005)

  1. 1. Version 1.0 Rainer Gerhards (rgerhards@adiscon.com) Copyright 2005 Rainer Gerhards Diese Dokument unterliegt der „UVM Lizenz für die freie Nutzung unveränderter Inhalte „ bzw. der „Creative Commons License „. Es darf unbeschränkt weitergegeben, jedoch nicht ohne schriftliche Genehmigung durch den Autor modifiziert werden. Syslog wird seit Jahren erfolgreich zur Überwachung des Systembetriebs eingesetzt. Interessanterweise ist das Protokoll nicht standardisiert und relativ leicht angreifbar. Die IETF hat die Probleme erkannt, eine Arbeitsgruppe beschäftigt sich mit der Standardisierung einer verbesserten Version. In diesem Papier wird die Entwicklung von syslog erklärt, Schwachstellen beschrieben und Lösungsmöglichkeiten im Rahmen der IETF-Standadisierung gezeigt. Was ist Syslog? Syslog ist ein gebräuchliches Protokoll zur Überwachung des Netzwerkbetriebs. Es wird sowohl zur Erkennung von Fehlerzuständen als auch zur Auditierung und Sicherheits-Überwachung eingesetzt. Darüber hinaus sind weitere An- wendungen bekannt. Anders als SNMP handelt es sich bei syslog um ein sehr einfaches, textba- sierendes Protokoll. Sowohl Nutzung als auch Implementierung von syslog- kompatiblen Programmen setzen keine Spezialkenntnisse voraus. Hieraus erklärt sich auch seine Popularität: viele Entwickler haben syslog-kompatible Tools erstellt, oft zur Lösung von Inhouse-Problemen gedacht. Diese Tools wur- den von der Community als sinnvoll angesehen und entsprechend weiter entwickelt und verbreitet. Die Einfachheit von syslog ist jedoch gleichzeitig seine größte Schwachstelle. Nachrichten werden via UDP übertragen, sind also nicht gegen Verlust gesichert. Darüber hinaus sind spoofing und replay-Attacken extrem leicht zu realisieren. Auch in der Anwendung gibt es einige gravierende Probleme: so existiert kein einheitliches Nachrichtenformat und nicht einmal eine Standardisierung des Protokolls selbst. Die IETF1 hat im Jahr 2000 diese Probleme aufgegriffen und eine Arbeitsgruppe ins Leben gerufen. Deren Aufgabe liegt in der: • Standardisierung des Formats • Sicherung des Nachrichtentransfers 1 Internet Engineering Task Force, www.ietf.org
  2. 2. Entwicklung Entstehung Syslog wurde von Eric Allman im Rahmen des sendmail Projekts in den frühen 1980er Jahren geschaffen. Ursprünglich war es lediglich als Protokollier- und Debug-Möglichkeit innerhalb von sendmail gedacht. Eine darüber hinaus- gehende Nutzung war weder geplant noch beabsichtigt. Aufgrund er einfachen Protokollanforderungen wurden als Filter-Kriterien lediglich die so gennanten „Facility“ und „Priority“ definiert. Die „Facility“ gibt dabei grob an, von welcher Funktion oder Applikation (z.B. Kernel oder Mail- Subsystem) die Nachricht erzeugt wurde. Die „Priority“ kennzeichnet den Schweregrad (von „Emergency“ bis „Debugging“). Nutzung Syslog hat sich in der Praxis rasch als universelles Hilfsmittel herausgestellt. Der syslog-daemon ist einfach, erfüllt aber offensichtlich weitgehend die Anforderungen an eine geordnete Systemprotokollierung. Die Implementierung von syslog-Sendern ist gleichfalls trivial. Es genügt, ein UDP-Paket an den Ziel- Port 514 zu senden. Zu Beginn der Meldung muss nur eine simple Kenn- zeichnung von Facility und Priority enthalten sein. Man kann getrost sagen, ein einfacher syslog-sender sollte von jedem geübten Programmierer binnen weniger Minuten erstellt werden können. Da alle Meldungen im Klartext vor- lagen und entsprechend der syslog-Philosophie für den Systemadministrator unmittelbar verständlich sein sollten, war auch die Interpretation der Meldungen zunächst vergleichsweise einfach. Aufgrund dieser Einfachheit begann syslog seinen Siegeszug. Neben diversen Applikationen wurden syslog-Sender auch in Geräte integriert. Heute findet sich nur schwerlich ein Router, Switch oder eine Firewall ohne Unterstützung für syslog (einige prominente Ausnahmen bestätigen die Regel). Darüber hinaus wurden syslog-daemons und -Sender auch auf nicht *NIX-Betriebssystemplatt- formen verfügbar. Die Grundidee von syslog wurde zunächst nicht modifiziert. Im Laufe der Zeit kamen aber einige wesentliche Ergänzungen hinzu. Prominentestes Beispiel für einen erweiterten syslog ist sicherlich syslog-ng. Darüber hinaus existieren jedoch noch eine Reihe weiterer Projekte mit erweiterten syslog-Features. Oftl wurden die Filter-Möglichkeiten dahingehend erweitert, dass auch der Meldungstext selbst durchsucht werden kann (meist sogar mit regulären Ausdrücken). Eine wesentliche, in der Praxis oft zu findende, Änderung ist der Wechsel des Transportprotokolls. Viele Implementierungen unterstützen syslog via TCP. Es existiert zwar kein geschriebener Standard für diesen Übertragungsmodus, die existierenden Implementierungen sind jedoch untereinander weitgehend interoperabel. Mit der Einführung von TCP-basierendem syslog wurde das Grundproblem des
  3. 3. Nachrichtenverlusts gelöst. Wie Marcus Ranum in seinen Tests darlegte und später von mir bestätigt wurde, können in Stress-Situation bis zu 90% der UDP- syslog-Meldungen verloren gehen. In meinen Tests verließen sie oftmals nicht einmal mehr die Quellmaschine. TCP löst dieses Problem, bzw. macht es zumindest bemerkbar2 . Auch bei TCP-Übertragung bleibt das Problem der fehlenden Vertraulichkeit, da die Nachrichten im Klartext übertragen werden. Einige Implementierungen lösen das Problem durch die Verwendung von SSL oder ähnlichen Mechanismen. Diese Implementierung sind im Regelfall nicht interoperabel. Mit Hilfe von TCP syslog lässt sich das Problem aber elegant lösen. Oftmals wird stunnel3 eingesetzt, um einen sicheren Kanal zwischen Sender und Empfänger aufzubauen. Diese Lösung wird häufig in syslog-ng Kaskaden eingesetzt. Sie ist auch in Verbindung mit anderen syslog-Implementierungen, auch auf anderen Plattformen, bekannt. Leider kann sie meines Wissens nach nicht in Verbindung mit Geräten wie Switches und Routern eingesetzt werden, da dort die stunnel Treiber nicht geladen werden können. Oft wird dies dadurch gelöst, dass das Gerät im Klartext Meldungen an eine syslog-daemon sendet und dabei ein privates Netz verwendet. Der syslog-daemon leitet die Nachricht dann über stunnel-geschützt an das eigentliche Ziel weiter. Stunnel ist heute eine gängige Lösung für den sicheren Transport von syslog Meldungen. Auch auf der Analyse-Seite hat sich syslog im Laufe der Zeit vom reinen Troubleshooting Protokoll zum Analysetool weiterentwickelt. Dabei helfen eine Reihe von Analyse und Alerting-Werkzeugen (z.B. swatch). Im Bereich der Analyse zeigen sich jedoch Probleme, die aus der fehlenden Standardisierung der Nachrichteninhalte resultieren. Damit sind nicht nur die Formate (Syntax), sondern auch die Bedeutung der Elemente gemeint (Semantik). Häufig wird dies anwendungsspezifisch durch Konvertierungsregeln gelöst. Oft sind auch bestimmte Tools nur für die Analyse bestimmter Syslog Quellen ausgelegt (beispielsweise nur für eine bestimmt Firewall). Beides ist nicht wünschenswert, momentan aber Stand der Technik. Standardisierung Bis zum Jahr 2000 gab es keine Standardisierungsbestrebungen für syslog. In diesem Jahr griff die IETF die Notwendigkeit auf, syslog zu einem gesicherten Protokoll fortzuentwickeln. Es wurde eine Arbeitsgruppe (Working Group, WG) gegründet. Vorsitzender war und ist Chris Lonvick. Als Mitarbeiter von Cisco verfügt er über gute Kontakte innerhalb der Networking Community und es ist ihm in den letzten Jahren gelungen, das Protokoll kontinuierlich zu standardi- sieren. Im August 2001 wurde RFC 3164 [1] fertig gestellt. Hierin wurde der „Status Quo“ beschrieben. Aufgrund der vielen unterschiedlichen Implementierung in 2 Eine Überlastung von Sender, Empfänger und Netzwerk kann natürlich auch mit TCP geschehen. Allerdings bemerkt der Sender nun, dass er die Meldungen nicht erfolgreich zustellen kann. Auch wird die Wahrscheinlichkeit des Verlusts einzelner Meldungen dramatisch reduziert. 3 www.stunnel.org
  4. 4. der Praxis deckt RFC 3164 leider nur einen Teil der real existierenden Formate ab. Dies wird im RFC selbst anerkannt, in dem jedes Paket als syslog-konform deklariert wird, sofern es nur an den UDP syslog port (514) gerichtet ist. Konsequenterweise hat RFC 3164 keinen normativen Charakter sondern ist nur informativ. Im Klartext: es ist kein Standard im eigentlichen Sinne. RFC 3164 ist jedoch ein wichtiger Zwischenschritt, dokumentiert er doch häufig auftretendes Verhalten von UDP-Syslog. Im November 2001 wurde dann RFC 3195 [2] publiziert. Dies ist ein echter Standard, in dem auch das Format der Syslog-Meldungen definiert wird. Allerdings erfolgt nach wie vor keine Normierung des eigentlichen Meldungstextes, sondern nur des Headers. RFC 3195 verspricht sowohl eine gesicherte Übertragung als auch die gegenseitige Authentifizierung von Sender und Empfänger. Damit wären die gravierendsten Schwächen von traditionellem syslog behoben. Leider bedient sich RFC 3195 als Transportmechanismus des BEEP Protokolls (Blocks Extensible Exchange Protocol, genormt in RFC 3080 [3]). Bei BEEP handelt es sich um ein mittels Profilen erweiterbares channel- multiplexing Protokoll, das sicherlich wohldesignt ist. Innerhalb der IETF gibt es starke Unterstützung für BEEP. Die syslog-Community nimmt BEEP jedoch mit großer Skepsis auf. Vielen Entwicklern erscheint es als zu große Abkehr vom Prinzip der „Einfachheit“ („simple spirit of syslog“). Erschwerend kommt hinzu, dass es für BEEP seinerzeit nur eine einzige Library4 gab, die noch dazu dem Entwickler ihr eigenes Threading-Modell aufzwang. Mittlerweile ist die weitere Pflege dieser Library übrigens fraglich. Kernpunkt war, dass BEEP sehr komplex erschien und in Teilen auch ist. Ich selbst habe in 2003 belegt, dass man einen simplen RFC 3195 Protokollhandler mit wenigen hundert Zeilen Code entwickeln kann. Auch habe ich im September 2003 eine vollständige Library5 für RFC 3195 syslog unter BSD Lizenz zur Verfügung gestellt. Das Interesse an diesen Entwicklungen ist jedoch verschwindend gering. RFC 3195 fand bis heute keinen Einzug in die Mainstream-Entwicklung im syslog-Bereich. Innerhalb der IETF ist leider keine Unterstützung für ein einfaches TCP basierendes syslog-Protokoll analog zu dem in der Praxis verwendeten vorhanden. Ansätze dieses doch zu unterstützen werden regelmäßig mit dem Hinweis auf die Unzulänglichkeit eines solchen Verfahrens abgewiesen. Diese technischen Einwendungen sind durchaus berechtigt, wie ich auch in Abschnitt 2.4 in einer solchen Spezifikation [4] darlege. Aus meiner Sicht wäre jedoch eine größere Offenheit der IETF in Bezug auf diese aus der Community sehr häufig vorgetragene Forderung hilfreich. In der Realität hat sich ja bereits ein Quasi-Standard etabliert. Parallel zu RFC 3195 wurde ein Internet-Draft6 (I-D) zur Einbettung von digitalen Signaturen in syslog-Meldungen begonnen (syslog-sign). Ebenfalls angegangen wurde ein I-D, der die internationale Zeichensätze innerhalb von syslog-Meldungen standardisieren sollte (syslog-international). 4 RoadRunner – http://rr.codefactory.se 5 Liblogging - http://www.monitorware.com/liblogging/ 6 Ein Internet-Draft (I-D) ist eine Diskussionsgrundlage innerhalb der IETF. Er ist quasi die Vorstufe zu einem RFC. Üblicherweise durchläuft ein Text mehrere Versionen als I-D um dann in eine „endgültigen“ Revision als RFC vorgeschlagen zu werden.
  5. 5. Im Zuge der IETF-Diskussionen stellt sich im Jahr 2003 heraus, dass die Herangehensweise an das syslog-Protokoll überdacht werden muss. Jeder RFC bzw. I-D definierte jeweils selbst sein eigenes Headerformat und „natürlich“ mit kleinen Differenzen. Nach einiger Diskussion entschied man sich, ein Schichtenmodell für syslog zu verwenden. Unglücklicherweise macht das zunächst einmal neue Basis-RFCs erforderlich, die Transport (syslog-transport-udp) und Format (syslog-protcol) der Meldungen definieren. Diese sind als I-D seit Dezember 2003 in Arbeit. Zum heutigen Zeitpunkt nähern sich diese Arbeiten der Fertigstellung. Erst danach kann auch die Arbeit an syslog-sign fortgesetzt werden. Ebenfalls danach ist eine Über- arbeitung von RFC 3195 erforderlich, da die darin getroffenen Formatde- finitionen mit den nun geplanten nicht übereinstimmen. Syslog – Probleme Syslog besitzt viele Vorteile, aber leider auch einige gravierende Ein- schränkungen. In diesem Abschnitt weise ich auf die gravierendsten Probleme hin. Diese Liste ist keinesfalls abschließend – soll aber andererseits auch nicht von der Nutzung von syslog abschrecken. Die Gefahren müssen aber erkannt werden, um sie zu „entschärfen“. Nachrichtenverlust Der größte Teil der syslog-Meldungen weltweit wird immer noch über gänzlich ungesichertes UDP übertragen. Wie bereits erwähnt, weisen Arbeiten von Marcus Ranum auf die Möglichkeit des massiven Meldungsverlustes hin. Neben dem massiven Verlust ist aber auch der Verlust weniger Einzelmeldungen zu betrachten. Gerade solche Verluste bleiben oft unbemerkt, können aber zu erheblichen Probleme bei einer späteren Analyse oder in einer gerichtlichen Beweisaufnahme führen. Problematisch an den Nachrichtenverlusten ist vor allem die simplex-Struktur der syslog-Übertragung, d.h. die fehlende Möglichkeit des Senders, Probleme zu erkennen und dann darauf zu reagieren. So können selbst simple Ereignisse wie der temporäre Aufsall einer Verbindung zum (unbemerkten) Verlust wichtiger Informationen führen. Sicherheit (Security) Gerade UDP-basierender syslog verfügt über eine Reihe von Sicherheits- problemen. So ist das spoofing von Absender-Adressen sehr einfach realisierbar. Auch Replay-Attacken können auf simpelste Weise realisiert werden, da nur ein unzureichender Zeitstempel in den Meldungen vorhanden ist und diese auch nicht kryptografisch signiert sind. Letztlich stellt die Übertragung im Klartext ein großes Problem dar. Oft werden wichtige Informationen wie z.B. Account-Namen und Systemzustände in den Meldungen übertragen. Dies bietet Angreifern, die solche Meldungen auffangen
  6. 6. und mitlesen können, große Vorteile. Formate Leider gibt es keinerlei einheitliches Format in syslog-Meldungen. Jeder Hersteller verwendet eigene Bezeichnung und eigene Syntax-Elemente für die zu übermittelnden Informationen. Teilweise unterscheiden sich sogar die Formate ansonsten inhaltsgleicher Meldungen, wenn diese nur von ver- schiedenen Software-Versionen erzeugt wurden. In [6], unter „Log Data“, gebe ich die etwas betrübliche Beschreibung von Log- Daten als – salopp ausgedrückt - „Haufen von ASCII-Zeichen innerhalb einer Zeile“. Tatsächlich lassen sich bei Vergleich von syslog-Meldungen aus verschiedenen Quellen oft nur geringe Gemeinsamkeiten finden. In [7] lege ich allerdings dar, dass sich mit Hilfe geeigneter Templates durchaus semantische Objekte aus den Meldungen extrahieren lassen. Allerdings bieten die momentanen Syslog-Implementierungen wenig Hilfestellung zur ein- deutigen Identifikation dieser semantischen Objekte. Auch ist keine eindeutiges Verzeichnis solcher Objekte vorhanden. Momentan werden im Analysebereich daher Insellösungen aufgebaut. Verbindungen zwischen den Tools sind schwer herzustellen. Selbst im weitgehend genormten Bereich des momentanen HEADER stecken Unzulänglichkeiten. So bietet der Zeitstempel keine Jahres- und Zeitzonen- Information und der Hostname ist oftmals nicht verwertbar, da die Domäne nicht mit angegeben werden soll. Diese an sich kleineren Irritationen können sich in der Praxis ja nach Anwendungsfall überaus unangenehm auswirken. Denkansatz der neueren IETF-Bestrebungen „Keep it simple“ Der Erfolg von syslog basierte auf seiner extrem einfachen Implementier- barkeit. Die Beibehaltung einer möglichst einfachen Implementierung wird auch innerhalb der IETF angestrebt. Allerdings ergibt sich durch die gestiegenen Anforderungen ein Interessenkonflikt. Wie RFC 3195 zeigt, ist hier nicht immer ein vollständiger Ausgleich zu erzielen. Es ist allerdings zu hoffen, dass die Probleme nur temporär sind und die Verfügbarkeit von Basis-Libraries unvermeidliche Komplexitäten vor den Entwicklern „verstecken“ kann. Aufteilung auf Schichten Alle erfolgreichen Protokolle basieren auf einem Schichtenmodell, in dem eine bestimmte Protokollebene nur bestimmt Funktionen übernehmen muss. Syslog als einfaches Protokoll erfordert auch nur eine einfache Strukturierung: • Transport
  7. 7. • Meldungs-Format (Container) • Applikationen (z.B. Signaturen) In 2003 stellten sich die diversen Standardisierungs-Bestrebungen aber noch wie folgt dar: Das heißt, jeder der (geplanten) Standards überspannte mehrere logische Schichten. In verschiedenen Standards wird die gleiche Schicht außerdem mehrfach – und teils unterschiedlich – beschrieben. Dies ist momentan Stand der Technik. Die künftigen Standards werden auf einem Schichtenmodell aufbauen: Wie aus der Grafik ersichtlich ist, wird nunmehr das Basisformat (Core) nur noch einmalig definiert (-protocol). Unterhalb des Core können dann ver- schiedene Transportprotokolle definiert werden. Oberhalb des Core werden verschiedene Anwendungen beschrieben. Kernpunkt ist, dass der Core einheitliche Definitionen sowohl nach „oben“ als auch nach „unten“ zur Verfügung stellt. Künftig sollte es deshalb möglich sein, den Transport auszutauschen, ohne die oberen Schichten davon überhaupt zu beeinflussen. Diese Prinzip klingt sinnvoll und altbekannt – ist bisher aber in syslog nicht gegeben. Strukturierung des Nachrichteninhalts Die aktuellen Syslog-Meldungen beinhalten lediglich Freitext. Strukturierte Informationen sind nicht vorgesehen. Sicherlich implementieren verschieden App Transport Protocol 3164 3195 -inter- national-sign App Transport syslog- transport- udp 3195bis (transport) -inter- national -sign 3195bis (metadata) -protocol
  8. 8. Applikationen verschiedene Mechanismen zur Übertragung strukturierter Informationen. Im Rahmen von syslog-protocol (Core) wird nun ein genereller Mechanismus zur Übertragung strukturierter Elemente definiert. Diese als „STRUCTURED- DATA“ beschriebene Methode soll den Grundstein zur späteren standar- disierten Abbildung semantischer Elemente legen. Dies deutet sich im aktuellen Standard bereits durch die Übernahme einiger aus SNMP bekannten Elemente (wie sysUpTime) an. Bis zu einer endgültigen Standardisierung semantischer Objekte ist es aber sicherlich noch ein weiter Weg. Dies ist momentan auch noch außerhalb der für die syslog-Arbeitsgruppe definierten Aufgabenstellung7 . Nachrichtenlänge Syslog-Meldungen sind traditionell kurz (maximal 1024 Zeichen). Manche Projekte beklagen diese Längenbeschränkung. Im Rahmen von syslog-protocol sollte die Beschränkung zunächst auf 16MB erweitert (also quasi aufgehoben) werden. Dies hat jedoch zu einigem Widerspruch geführt, nicht zuletzt wegen der sich für die Implementierung ergebenden Komplexitäten. Der momentane Vorschlag geht dahin, eine sehr kurze garantierte Nachrichten- länge zu definieren (480 Zeichen). Hintergrund ist, dass beim Netzwerk- Troubleshooting längere Nachrichten tendenziell weniger zuverlässig zugestellt werden8 . Darüber hinaus wird die Unterstützung größerer Nachrichtenlängen freigestellt, bzw. bis zu einer gewissen Grenze sogar empfohlen. Als für die Praxis relevante Grenze dürften 32 oder 64 KB angesehen werden – größere Nachrichtenlängen sind aber erlaubt. Der Sinn dieses Kompromisses liegt darin • die Implementierung für den extrem häufigen Regelfall simpel zu halten • in Ausnahmefällen dennoch eine Übertragung im Rahmen des Standards zu ermöglichen9 Konsequenterweise beinhalten die Standards Regeln, wie „zu lange“ Nachrichten abgeschnitten werden sollen. Wird abgeschnitten, wird diese Tat- sache auch im Header der Nachricht vermerkt. Es ist davon auszugehen, dass Systemadministratoren der geforderten und unterstützen Nachrichtenlänge Ihrer syslog-Komponenten künftig eine gewisse 7 Jede IETF-Arbeitsgruppe erhält bei Ihrer Gründung eine „Charter“. Diese definiert – und begrenzt – die Aufgabenstellung der Arbeitsgruppe. Diese Vorgehensweise ist notwendig, um die IETF-Aktivitäten untereinander zu koordinieren. Die Änderung der Charter ist ein nicht-trivialer Vorgang, der breiter Zustimmung innerhalb der IETF bedarf. 8 Die genaue Erklärung liegt in der Fragmentierung, der steigenden Wahrscheinlichkeit des Paketverlustes mit der Anzahl der Pakete sowie dem UDP-Protokoll. Dies genau auszuführen würde aber den Rahmen des Papiers sprengen. 9 Eine wichtige Anwendung ist „IHE“ - „Integrated Healthcare Environment“. In diesem Framework wird von einer Nachrichtenlänge von 32KB ausgegangen. Dies wird teilweise schon mit heute existierenden Implementierungen realisiert. IHE ist eine „Randanwendung“, aber eine kommerziell sehr bedeutende. Würde die geforderte Nachrichtenlänge nicht vom Standard unterstützt, wäre davon auszugehen, dass die Implementierungen den Standard in diesem Punkt ohnehin ignorieren würden.
  9. 9. Aufmerksamkeit widmen müssen. Neue Software-Projekte Es gibt sicherlich eine Unzahl von neuen, wichtigen und interessanten Projekten im syslog-Umfeld. Ich möchte hier jedoch nur kurz auf diejenigen eingehen, die in einem engeren Bezug zur Standardisierung stehen. syslog-sign Albert Mietus hat bereits auf der EuroBSDCon 2002 in [5] eine frühe Im- plementierung von syslog-sign vorgestellt. Die Arbeit kann leider durch die momentane „Warteposition“ von syslog-sign nicht vollendet werden. Sie bietet aber eine solide Grundlage, die eine schnelle Realisierung nach endgültiger Verabschiedung von syslog-sign ermöglichen dürfte. Herr Mietus hat zu erkennen gegeben, dass er weiterhin an der Fertigstellung seines syslog- daemons interessiert ist. RFC 3195 Zur Zeit existiert lediglich eine Implementierung von RFC 3195 als vollständiger daemon unter *NIX. Dies ist SDSC syslog10 , noch basierend auf der RoadRunner Library. SDSC syslog unterstützt auch „traditional syslog“ und erfreut sich einer gewissen Benutzerschaar (die ihn allerdings im Regelfall für „traditional syslog“ einsetzt). Unter Windows existieren darüber hinaus einige kommerzielle RFC 3195 Sender- und Empfänger-Applikationen. Meines Wissens nach wird jedoch auch hier die RFC 3195 Funktionalität in der Praxis (noch) nicht genutzt. Weitergehende Implementierungen als vollständige Applikation oder im Rahmen von Geräten (Router, Switch,...) sind nicht bekannt. Darüber hinaus existiert noch eine RFC 3195 Basislibrary (liblogging, zuvor schon genannt). Sie ermöglicht die Implementierung von syslog-Sendern und -Empfängern. Auch hier existiert nur eine verschwindend kleine Nutzergemeinde, Einsatz in der Praxis ist nicht bekannt. Ich habe Ende 2004 das rsyslog11 Projekt initiiert. Im Rahmen dieses Projekts entsteht ein alternativer syslog-daemon, der mittelfristig auch RFC 3195, wahrscheinlich basierend auf liblogging, unterstützen soll. Syslog-protocol Momentan ist noch keine Implementierung von syslog-protocol bekannt. Da die Implementierung jedoch vergleichsweise einfach ist, gehen ich davon aus, dass 10http://security.sdsc.edu/software/sdsc-syslog/ 11Http://www.monitorware.com/rsyslog/
  10. 10. solche relativ kurzfristig nach Verabschiedung des RFC erscheinen werden. Es ist geplant, dass das rsyslog-Projekt syslog-protocol unterstützen soll. Werden sich die neuen Standards durch- setzen? Wie immer bei neuen Standardisierungsbestrebungen ist eine gewisse Aus- dauer gefragt. Zum Einen werden wichtige Standards gerade erst erarbeitet. Zum Anderen funktioniert „traditional syslog“ in der Praxis recht gut. Ein akuter Handlungsbedarf besteht also nicht. Von daher gehe ich nicht davon aus, dass sich die neuen Standards binnen weniger Monate oder Jahre etablieren werden. So hat RFC 3195 zum Beispiel einen sehr schweren Start und erscheint momentan nicht wirklich erfolgver- sprechend. Diese Sicht ist aber wahrscheinlich zu kurzsichtig. RFC 3195 bietet Lösungen für viele der heute existierenden Problem. Sollte sich einer der „Major Player“ im Bereich der Netzkomponenten entscheiden, RFC 3195 zu unterstützen, so ist von einer rasch zunehmenden Bedeutung auszugehen. Für diese These spricht auch, dass das RFC 3195 zugrunde liegende BEEP Protokoll zwar kompliziert ausschaut, sich bei näherer Betrachtung aber doch verhältnis- mäßig einfach implementieren lässt. Weiterhin ist erkennbar, dass die syslog-Standardisierungsbestrebungen auch bei anderen Standardisierungsorganisationen und Industriekonsortien Aufmerk- samkeit gewinnen. So werden die sich abzeichnenden Standards im Rahmen des OIF (http://www.oiforum.com/) und innerhalb von IHE (siehe oben) genutzt, Auch für die Anwender bieten sie letztlich eine Lösung vieler der heutigen Probleme. Ich gehe daher davon aus, dass sich die neuen Standards mittel- fristig durchsetzen werden. Bis zu einer vollständigen Ablösung von „traditional syslog“ dürfte allerdings noch eine lange Zeit vergehen. Referenzen [1] Lonvick, Chris, RFC 3164, „The BSD syslog Protocol“, August 2001 [2] New, D und Rose, M., RFC 3195, „Reliable Delivery for syslog“, November 2001. [3] Rose, M., RFC 3080, "The Blocks Extensible Exchange Protocol Core", März 2001. [4] Gerhards, R, „The Simple Event Log Protocol (SELP)“, Februar 2003, http://www.monitorware.com/en/workinprogress/selp.txt [5] Mietus, A., „Securing syslog on FreeBSD“, November 2002, http://2002.eurobsdcon.org/papers/mietus_presentation.pdf [6] Gerhards, R. „Finding the needle in the Haystack“, Februar 2003, http://www.monitorware.com/en/workinprogress/Needle-in-Haystack.php
  11. 11. [7] Gerhards, R., „On the Nature of Syslog Data“, März 2004, http://www.monitorware.com/en/workinprogress/nature-of-syslog-data.php

×