Your SlideShare is downloading. ×
  • Like
  • Save
State of syslog (2005)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

State of syslog (2005)

  • 81 views
Published

Paper from the LinuxTag 2005 proceedings describing the (then-)current state of syslog. In German.

Paper from the LinuxTag 2005 proceedings describing the (then-)current state of syslog. In German.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
81
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Version 1.0Rainer Gerhards (rgerhards@adiscon.com)Copyright 2005 Rainer GerhardsDiese Dokument unterliegt der „UVM Lizenz für die freie Nutzungunveränderter Inhalte „ bzw. der „Creative Commons License „. Esdarf unbeschränkt weitergegeben, jedoch nicht ohne schriftlicheGenehmigung durch den Autor modifiziert werden.Syslog wird seit Jahren erfolgreich zur Überwachung des Systembetriebseingesetzt. Interessanterweise ist das Protokoll nicht standardisiert und relativleicht angreifbar. Die IETF hat die Probleme erkannt, eine Arbeitsgruppebeschäftigt sich mit der Standardisierung einer verbesserten Version. Indiesem Papier wird die Entwicklung von syslog erklärt, Schwachstellenbeschrieben und Lösungsmöglichkeiten im Rahmen der IETF-Standadisierunggezeigt.Was ist Syslog?Syslog ist ein gebräuchliches Protokoll zur Überwachung des Netzwerkbetriebs.Es wird sowohl zur Erkennung von Fehlerzuständen als auch zur Auditierungund 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. Hierauserklärt sich auch seine Popularität: viele Entwickler haben syslog-kompatibleTools erstellt, oft zur Lösung von Inhouse-Problemen gedacht. Diese Tools wur-den von der Community als sinnvoll angesehen und entsprechend weiterentwickelt und verbreitet.Die Einfachheit von syslog ist jedoch gleichzeitig seine größte Schwachstelle.Nachrichten werden via UDP übertragen, sind also nicht gegen Verlustgesichert. Darüber hinaus sind spoofing und replay-Attacken extrem leicht zurealisieren. Auch in der Anwendung gibt es einige gravierende Probleme: soexistiert kein einheitliches Nachrichtenformat und nicht einmal eineStandardisierung des Protokolls selbst.Die IETF1hat im Jahr 2000 diese Probleme aufgegriffen und eine Arbeitsgruppeins Leben gerufen. Deren Aufgabe liegt in der:• Standardisierung des Formats• Sicherung des Nachrichtentransfers1 Internet Engineering Task Force, www.ietf.org
  • 2. EntwicklungEntstehungSyslog wurde von Eric Allman im Rahmen des sendmail Projekts in den frühen1980er Jahren geschaffen. Ursprünglich war es lediglich als Protokollier- undDebug-Möglichkeit innerhalb von sendmail gedacht. Eine darüber hinaus-gehende Nutzung war weder geplant noch beabsichtigt.Aufgrund er einfachen Protokollanforderungen wurden als Filter-Kriterienlediglich die so gennanten „Facility“ und „Priority“ definiert. Die „Facility“ gibtdabei grob an, von welcher Funktion oder Applikation (z.B. Kernel oder Mail-Subsystem) die Nachricht erzeugt wurde. Die „Priority“ kennzeichnet denSchweregrad (von „Emergency“ bis „Debugging“).NutzungSyslog hat sich in der Praxis rasch als universelles Hilfsmittel herausgestellt.Der syslog-daemon ist einfach, erfüllt aber offensichtlich weitgehend dieAnforderungen an eine geordnete Systemprotokollierung. Die Implementierungvon 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, eineinfacher syslog-sender sollte von jedem geübten Programmierer binnenweniger Minuten erstellt werden können. Da alle Meldungen im Klartext vor-lagen und entsprechend der syslog-Philosophie für den Systemadministratorunmittelbar verständlich sein sollten, war auch die Interpretation derMeldungen zunächst vergleichsweise einfach.Aufgrund dieser Einfachheit begann syslog seinen Siegeszug. Neben diversenApplikationen wurden syslog-Sender auch in Geräte integriert. Heute findet sichnur schwerlich ein Router, Switch oder eine Firewall ohne Unterstützung fürsyslog (einige prominente Ausnahmen bestätigen die Regel). Darüber hinauswurden syslog-daemons und -Sender auch auf nicht *NIX-Betriebssystemplatt-formen verfügbar.Die Grundidee von syslog wurde zunächst nicht modifiziert. Im Laufe der Zeitkamen aber einige wesentliche Ergänzungen hinzu. Prominentestes Beispiel füreinen erweiterten syslog ist sicherlich syslog-ng. Darüber hinaus existierenjedoch noch eine Reihe weiterer Projekte mit erweiterten syslog-Features. Oftlwurden die Filter-Möglichkeiten dahingehend erweitert, dass auch derMeldungstext selbst durchsucht werden kann (meist sogar mit regulärenAusdrücken).Eine wesentliche, in der Praxis oft zu findende, Änderung ist der Wechsel desTransportprotokolls. Viele Implementierungen unterstützen syslog via TCP. Esexistiert zwar kein geschriebener Standard für diesen Übertragungsmodus, dieexistierenden Implementierungen sind jedoch untereinander weitgehendinteroperabel.Mit der Einführung von TCP-basierendem syslog wurde das Grundproblem des
  • 3. Nachrichtenverlusts gelöst. Wie Marcus Ranum in seinen Tests darlegte undspä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 nichteinmal mehr die Quellmaschine. TCP löst dieses Problem, bzw. macht eszumindest bemerkbar2.Auch bei TCP-Übertragung bleibt das Problem der fehlenden Vertraulichkeit, dadie Nachrichten im Klartext übertragen werden. Einige Implementierungenlösen das Problem durch die Verwendung von SSL oder ähnlichenMechanismen. Diese Implementierung sind im Regelfall nicht interoperabel.Mit Hilfe von TCP syslog lässt sich das Problem aber elegant lösen. Oftmals wirdstunnel3eingesetzt, um einen sicheren Kanal zwischen Sender und Empfängeraufzubauen. Diese Lösung wird häufig in syslog-ng Kaskaden eingesetzt. Sie istauch in Verbindung mit anderen syslog-Implementierungen, auch auf anderenPlattformen, bekannt. Leider kann sie meines Wissens nach nicht in Verbindungmit Geräten wie Switches und Routern eingesetzt werden, da dort die stunnelTreiber nicht geladen werden können. Oft wird dies dadurch gelöst, dass dasGerät im Klartext Meldungen an eine syslog-daemon sendet und dabei einprivates Netz verwendet. Der syslog-daemon leitet die Nachricht dann überstunnel-geschützt an das eigentliche Ziel weiter. Stunnel ist heute eine gängigeLösung für den sicheren Transport von syslog Meldungen.Auch auf der Analyse-Seite hat sich syslog im Laufe der Zeit vom reinenTroubleshooting Protokoll zum Analysetool weiterentwickelt. Dabei helfen eineReihe von Analyse und Alerting-Werkzeugen (z.B. swatch). Im Bereich derAnalyse zeigen sich jedoch Probleme, die aus der fehlenden Standardisierungder 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. Oftsind auch bestimmte Tools nur für die Analyse bestimmter Syslog Quellenausgelegt (beispielsweise nur für eine bestimmt Firewall). Beides ist nichtwünschenswert, momentan aber Stand der Technik.StandardisierungBis zum Jahr 2000 gab es keine Standardisierungsbestrebungen für syslog. Indiesem Jahr griff die IETF die Notwendigkeit auf, syslog zu einem gesichertenProtokoll fortzuentwickeln. Es wurde eine Arbeitsgruppe (Working Group, WG)gegründet. Vorsitzender war und ist Chris Lonvick. Als Mitarbeiter von Ciscoverfügt er über gute Kontakte innerhalb der Networking Community und es istihm in den letzten Jahren gelungen, das Protokoll kontinuierlich zu standardi-sieren.Im August 2001 wurde RFC 3164 [1] fertig gestellt. Hierin wurde der „StatusQuo“ beschrieben. Aufgrund der vielen unterschiedlichen Implementierung in2 Eine Überlastung von Sender, Empfänger und Netzwerk kann natürlich auch mit TCPgeschehen. Allerdings bemerkt der Sender nun, dass er die Meldungen nicht erfolgreichzustellen kann. Auch wird die Wahrscheinlichkeit des Verlusts einzelner Meldungendramatisch reduziert.3 www.stunnel.org
  • 4. der Praxis deckt RFC 3164 leider nur einen Teil der real existierenden Formateab. Dies wird im RFC selbst anerkannt, in dem jedes Paket als syslog-konformdeklariert wird, sofern es nur an den UDP syslog port (514) gerichtet ist.Konsequenterweise hat RFC 3164 keinen normativen Charakter sondern ist nurinformativ. Im Klartext: es ist kein Standard im eigentlichen Sinne. RFC 3164 istjedoch ein wichtiger Zwischenschritt, dokumentiert er doch häufig auftretendesVerhalten von UDP-Syslog.Im November 2001 wurde dann RFC 3195 [2] publiziert. Dies ist ein echterStandard, in dem auch das Format der Syslog-Meldungen definiert wird.Allerdings erfolgt nach wie vor keine Normierung des eigentlichenMeldungstextes, sondern nur des Headers. RFC 3195 verspricht sowohl einegesicherte Übertragung als auch die gegenseitige Authentifizierung von Senderund Empfänger. Damit wären die gravierendsten Schwächen von traditionellemsyslog behoben. Leider bedient sich RFC 3195 als Transportmechanismus desBEEP 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 esstarke Unterstützung für BEEP.Die syslog-Community nimmt BEEP jedoch mit großer Skepsis auf. VielenEntwicklern erscheint es als zu große Abkehr vom Prinzip der „Einfachheit“(„simple spirit of syslog“). Erschwerend kommt hinzu, dass es für BEEPseinerzeit nur eine einzige Library4gab, die noch dazu dem Entwickler ihreigenes Threading-Modell aufzwang. Mittlerweile ist die weitere Pflege dieserLibrary übrigens fraglich. Kernpunkt war, dass BEEP sehr komplex erschien undin Teilen auch ist. Ich selbst habe in 2003 belegt, dass man einen simplen RFC3195 Protokollhandler mit wenigen hundert Zeilen Code entwickeln kann. Auchhabe ich im September 2003 eine vollständige Library5für RFC 3195 syslogunter BSD Lizenz zur Verfügung gestellt. Das Interesse an diesenEntwicklungen ist jedoch verschwindend gering. RFC 3195 fand bis heutekeinen Einzug in die Mainstream-Entwicklung im syslog-Bereich.Innerhalb der IETF ist leider keine Unterstützung für ein einfaches TCPbasierendes syslog-Protokoll analog zu dem in der Praxis verwendetenvorhanden. Ansätze dieses doch zu unterstützen werden regelmäßig mit demHinweis auf die Unzulänglichkeit eines solchen Verfahrens abgewiesen. Diesetechnischen Einwendungen sind durchaus berechtigt, wie ich auch in Abschnitt2.4 in einer solchen Spezifikation [4] darlege. Aus meiner Sicht wäre jedocheine größere Offenheit der IETF in Bezug auf diese aus der Community sehrhäufig vorgetragene Forderung hilfreich. In der Realität hat sich ja bereits einQuasi-Standard etabliert.Parallel zu RFC 3195 wurde ein Internet-Draft6(I-D) zur Einbettung vondigitalen Signaturen in syslog-Meldungen begonnen (syslog-sign). Ebenfallsangegangen wurde ein I-D, der die internationale Zeichensätze innerhalb vonsyslog-Meldungen standardisieren sollte (syslog-international).4 RoadRunner – http://rr.codefactory.se5 Liblogging - http://www.monitorware.com/liblogging/6 Ein Internet-Draft (I-D) ist eine Diskussionsgrundlage innerhalb der IETF. Er ist quasi dieVorstufe zu einem RFC. Üblicherweise durchläuft ein Text mehrere Versionen als I-D umdann in eine „endgültigen“ Revision als RFC vorgeschlagen zu werden.
  • 5. Im Zuge der IETF-Diskussionen stellt sich im Jahr 2003 heraus, dass dieHerangehensweise an das syslog-Protokoll überdacht werden muss. Jeder RFCbzw. I-D definierte jeweils selbst sein eigenes Headerformat und „natürlich“ mitkleinen Differenzen. Nach einiger Diskussion entschied man sich, einSchichtenmodell 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 Meldungendefinieren. Diese sind als I-D seit Dezember 2003 in Arbeit. Zum heutigenZeitpunkt nähern sich diese Arbeiten der Fertigstellung. Erst danach kann auchdie 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 – ProblemeSyslog besitzt viele Vorteile, aber leider auch einige gravierende Ein-schränkungen. In diesem Abschnitt weise ich auf die gravierendsten Problemehin. Diese Liste ist keinesfalls abschließend – soll aber andererseits auch nichtvon der Nutzung von syslog abschrecken. Die Gefahren müssen aber erkanntwerden, um sie zu „entschärfen“.NachrichtenverlustDer größte Teil der syslog-Meldungen weltweit wird immer noch über gänzlichungesichertes UDP übertragen. Wie bereits erwähnt, weisen Arbeiten vonMarcus Ranum auf die Möglichkeit des massiven Meldungsverlustes hin. Nebendem massiven Verlust ist aber auch der Verlust weniger Einzelmeldungen zubetrachten. Gerade solche Verluste bleiben oft unbemerkt, können aber zuerheblichen Probleme bei einer späteren Analyse oder in einer gerichtlichenBeweisaufnahme führen.Problematisch an den Nachrichtenverlusten ist vor allem die simplex-Strukturder syslog-Übertragung, d.h. die fehlende Möglichkeit des Senders, Problemezu erkennen und dann darauf zu reagieren. So können selbst simple Ereignissewie der temporäre Aufsall einer Verbindung zum (unbemerkten) Verlustwichtiger 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 einfachrealisierbar. Auch Replay-Attacken können auf simpelste Weise realisiertwerden, da nur ein unzureichender Zeitstempel in den Meldungen vorhandenist und diese auch nicht kryptografisch signiert sind.Letztlich stellt die Übertragung im Klartext ein großes Problem dar. Oft werdenwichtige Informationen wie z.B. Account-Namen und Systemzustände in denMeldungen übertragen. Dies bietet Angreifern, die solche Meldungen auffangen
  • 6. und mitlesen können, große Vorteile.FormateLeider gibt es keinerlei einheitliches Format in syslog-Meldungen. JederHersteller verwendet eigene Bezeichnung und eigene Syntax-Elemente für diezu übermittelnden Informationen. Teilweise unterscheiden sich sogar dieFormate 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 einerZeile“. Tatsächlich lassen sich bei Vergleich von syslog-Meldungen ausverschiedenen Quellen oft nur geringe Gemeinsamkeiten finden.In [7] lege ich allerdings dar, dass sich mit Hilfe geeigneter Templates durchaussemantische Objekte aus den Meldungen extrahieren lassen. Allerdings bietendie momentanen Syslog-Implementierungen wenig Hilfestellung zur ein-deutigen Identifikation dieser semantischen Objekte. Auch ist keine eindeutigesVerzeichnis solcher Objekte vorhanden. Momentan werden im Analysebereichdaher Insellösungen aufgebaut. Verbindungen zwischen den Tools sind schwerherzustellen.Selbst im weitgehend genormten Bereich des momentanen HEADER steckenUnzulänglichkeiten. So bietet der Zeitstempel keine Jahres- und Zeitzonen-Information und der Hostname ist oftmals nicht verwertbar, da die Domänenicht mit angegeben werden soll. Diese an sich kleineren Irritationen könnensich 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 wirdauch innerhalb der IETF angestrebt. Allerdings ergibt sich durch diegestiegenen Anforderungen ein Interessenkonflikt. Wie RFC 3195 zeigt, ist hiernicht 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-Librariesunvermeidliche Komplexitäten vor den Entwicklern „verstecken“ kann.Aufteilung auf SchichtenAlle erfolgreichen Protokolle basieren auf einem Schichtenmodell, in dem einebestimmte Protokollebene nur bestimmt Funktionen übernehmen muss. Syslogals einfaches Protokoll erfordert auch nur eine einfache Strukturierung:• Transport
  • 7. • Meldungs-Format (Container)• Applikationen (z.B. Signaturen)In 2003 stellten sich die diversen Standardisierungs-Bestrebungen aber nochwie folgt dar:Das heißt, jeder der (geplanten) Standards überspannte mehrere logischeSchichten. In verschiedenen Standards wird die gleiche Schicht außerdemmehrfach – und teils unterschiedlich – beschrieben. Dies ist momentan Standder Technik.Die künftigen Standards werden auf einem Schichtenmodell aufbauen:Wie aus der Grafik ersichtlich ist, wird nunmehr das Basisformat (Core) nurnoch einmalig definiert (-protocol). Unterhalb des Core können dann ver-schiedene Transportprotokolle definiert werden. Oberhalb des Core werdenverschiedene Anwendungen beschrieben. Kernpunkt ist, dass der Coreeinheitliche Definitionen sowohl nach „oben“ als auch nach „unten“ zurVerfügung stellt. Künftig sollte es deshalb möglich sein, den Transportauszutauschen, ohne die oberen Schichten davon überhaupt zu beeinflussen.Diese Prinzip klingt sinnvoll und altbekannt – ist bisher aber in syslog nichtgegeben.Strukturierung des NachrichteninhaltsDie aktuellen Syslog-Meldungen beinhalten lediglich Freitext. StrukturierteInformationen sind nicht vorgesehen. Sicherlich implementieren verschiedenAppTransportProtocol3164 3195-inter-national-signAppTransportsyslog-transport-udp3195bis(transport)-inter-national-sign3195bis(metadata)-protocol
  • 8. Applikationen verschiedene Mechanismen zur Übertragung strukturierterInformationen.Im Rahmen von syslog-protocol (Core) wird nun ein genereller Mechanismuszur Ü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 einigeraus SNMP bekannten Elemente (wie sysUpTime) an. Bis zu einer endgültigenStandardisierung semantischer Objekte ist es aber sicherlich noch ein weiterWeg. Dies ist momentan auch noch außerhalb der für die syslog-Arbeitsgruppedefinierten Aufgabenstellung7.NachrichtenlängeSyslog-Meldungen sind traditionell kurz (maximal 1024 Zeichen). MancheProjekte beklagen diese Längenbeschränkung. Im Rahmen von syslog-protocolsollte die Beschränkung zunächst auf 16MB erweitert (also quasi aufgehoben)werden. Dies hat jedoch zu einigem Widerspruch geführt, nicht zuletzt wegender 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 zugestelltwerden8. Darüber hinaus wird die Unterstützung größerer Nachrichtenlängenfreigestellt, bzw. bis zu einer gewissen Grenze sogar empfohlen. Als für diePraxis relevante Grenze dürften 32 oder 64 KB angesehen werden – größereNachrichtenlä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 zuermöglichen9Konsequenterweise 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 undunterstützen Nachrichtenlänge Ihrer syslog-Komponenten künftig eine gewisse7 Jede IETF-Arbeitsgruppe erhält bei Ihrer Gründung eine „Charter“. Diese definiert – undbegrenzt – die Aufgabenstellung der Arbeitsgruppe. Diese Vorgehensweise ist notwendig,um die IETF-Aktivitäten untereinander zu koordinieren. Die Änderung der Charter ist einnicht-trivialer Vorgang, der breiter Zustimmung innerhalb der IETF bedarf.8 Die genaue Erklärung liegt in der Fragmentierung, der steigenden Wahrscheinlichkeit desPaketverlustes mit der Anzahl der Pakete sowie dem UDP-Protokoll. Dies genau auszuführenwürde aber den Rahmen des Papiers sprengen.9 Eine wichtige Anwendung ist „IHE“ - „Integrated Healthcare Environment“. In diesemFramework wird von einer Nachrichtenlänge von 32KB ausgegangen. Dies wird teilweiseschon mit heute existierenden Implementierungen realisiert. IHE ist eine „Randanwendung“,aber eine kommerziell sehr bedeutende. Würde die geforderte Nachrichtenlänge nicht vomStandard unterstützt, wäre davon auszugehen, dass die Implementierungen den Standard indiesem Punkt ohnehin ignorieren würden.
  • 9. Aufmerksamkeit widmen müssen.Neue Software-ProjekteEs gibt sicherlich eine Unzahl von neuen, wichtigen und interessantenProjekten im syslog-Umfeld. Ich möchte hier jedoch nur kurz auf diejenigeneingehen, die in einem engeren Bezug zur Standardisierung stehen.syslog-signAlbert Mietus hat bereits auf der EuroBSDCon 2002 in [5] eine frühe Im-plementierung von syslog-sign vorgestellt. Die Arbeit kann leider durch diemomentane „Warteposition“ von syslog-sign nicht vollendet werden. Sie bietetaber eine solide Grundlage, die eine schnelle Realisierung nach endgültigerVerabschiedung von syslog-sign ermöglichen dürfte. Herr Mietus hat zuerkennen gegeben, dass er weiterhin an der Fertigstellung seines syslog-daemons interessiert ist.RFC 3195Zur Zeit existiert lediglich eine Implementierung von RFC 3195 alsvollständiger daemon unter *NIX. Dies ist SDSC syslog10, noch basierend aufder RoadRunner Library. SDSC syslog unterstützt auch „traditional syslog“ underfreut sich einer gewissen Benutzerschaar (die ihn allerdings im Regelfall für„traditional syslog“ einsetzt). Unter Windows existieren darüber hinaus einigekommerzielle RFC 3195 Sender- und Empfänger-Applikationen. Meines Wissensnach wird jedoch auch hier die RFC 3195 Funktionalität in der Praxis (noch)nicht genutzt. Weitergehende Implementierungen als vollständige Applikationoder im Rahmen von Geräten (Router, Switch,...) sind nicht bekannt.Darüber hinaus existiert noch eine RFC 3195 Basislibrary (liblogging, zuvorschon genannt). Sie ermöglicht die Implementierung von syslog-Sendern und-Empfängern. Auch hier existiert nur eine verschwindend kleineNutzergemeinde, Einsatz in der Praxis ist nicht bekannt.Ich habe Ende 2004 das rsyslog11Projekt initiiert. Im Rahmen dieses Projektsentsteht ein alternativer syslog-daemon, der mittelfristig auch RFC 3195,wahrscheinlich basierend auf liblogging, unterstützen soll.Syslog-protocolMomentan ist noch keine Implementierung von syslog-protocol bekannt. Da dieImplementierung jedoch vergleichsweise einfach ist, gehen ich davon aus, dass10http://security.sdsc.edu/software/sdsc-syslog/11Http://www.monitorware.com/rsyslog/
  • 10. solche relativ kurzfristig nach Verabschiedung des RFC erscheinen werden. Esist 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 akuterHandlungsbedarf besteht also nicht.Von daher gehe ich nicht davon aus, dass sich die neuen Standards binnenweniger Monate oder Jahre etablieren werden. So hat RFC 3195 zum Beispieleinen sehr schweren Start und erscheint momentan nicht wirklich erfolgver-sprechend. Diese Sicht ist aber wahrscheinlich zu kurzsichtig. RFC 3195 bietetLösungen für viele der heute existierenden Problem. Sollte sich einer der„Major Player“ im Bereich der Netzkomponenten entscheiden, RFC 3195 zuunterstützen, so ist von einer rasch zunehmenden Bedeutung auszugehen. Fürdiese These spricht auch, dass das RFC 3195 zugrunde liegende BEEP Protokollzwar kompliziert ausschaut, sich bei näherer Betrachtung aber doch verhältnis-mäßig einfach implementieren lässt.Weiterhin ist erkennbar, dass die syslog-Standardisierungsbestrebungen auchbei anderen Standardisierungsorganisationen und Industriekonsortien Aufmerk-samkeit gewinnen. So werden die sich abzeichnenden Standards im Rahmendes 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 heutigenProbleme. Ich gehe daher davon aus, dass sich die neuen Standards mittel-fristig durchsetzen werden. Bis zu einer vollständigen Ablösung von „traditionalsyslog“ 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“, November2001.[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. [7] Gerhards, R., „On the Nature of Syslog Data“, März 2004,http://www.monitorware.com/en/workinprogress/nature-of-syslog-data.php