Das Dokument beschreibt die Entwicklung, Nutzung und die Probleme des Syslog-Protokolls, das zur Überwachung von Netzwerkoperationen eingesetzt wird, jedoch aufgrund seiner einfachen Implementierung und fehlenden Standardisierung einige Schwachstellen aufweist. Die IETF arbeitet an der Standardisierung des Protokolls, um Sicherheits- und Übertragungsprobleme zu beheben, während gleichzeitig die einfache Handhabung von Syslog beibehalten werden soll. Historisch gesehen wurde Syslog in den 1980er Jahren entwickelt, hat sich aber ohne einheitliche Standards in der Praxis umfassend verbreitet.

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. 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. 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. 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. 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. 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. • 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. 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. 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. 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. [7] Gerhards, R., „On the Nature of Syslog Data“, März 2004,
http://www.monitorware.com/en/workinprogress/nature-of-syslog-data.php