Wie läuft das eigentlich ab, bis sich etwas zum Standard entwickelt? Wenn Sie sich diese Frage auch schon gestellt haben, dann sind Sie hier - und in den nächsten Postings - wahrscheinlich richtig.

Ich habe seit geraumer Zeit an einer neuen Standardfamilie für die Systemprotokollierung mitgearbeitet. Das Ganze erfolgte im Rahmen der IETF, einer Organisation, die für die Standards (RFCs) des Internet verantwortlich zeichnet. Die Systemprotokollierungist dabei natürlich eher ein Thema für einen kleineren Kreis von Spezialisten. Man kann sie aber mit Schlagworten wie "Vorratsdatenspeicherung" verbinden, und dann wird das Thema auf einmal für sehr viel mehr Menschen relevant.

Ich möchte Ihnen gerne einen kurzen Einblick darin geben, wie man sich die Arbeit an so einem Standard, und die anschließende Implementierung in konkreten Produkten so "anfühlt". Natürlich könnte man darüber ein Buch schreiben - das möchte ich aber nicht, und Sie würden es wahrscheinlich nicht lesen wollen.

Ich habe daher einmal versucht, einige wesentliche Punkte zu vermerken und werde das auf einige wenige Blog Postings (zwei? drei?) aufteilen, damit das einzelne nicht zu lange wird. Dabei werden sich naturgemäß auch einige technische Begriffe mit einschleichen, ich hoffe, der Text bleibt trotzdem verständlich.

Fangen wir einfach 'mal an. Wie gesagt, es geht um "syslog", ein Protokoll, das zur Nachrichtenübertragung gilt. Ach ja: ein "Protokoll" ist nichts anderes als eine Vereinbarung darüber, wie zwei verschiedene technische Systeme miteinander "sprechen" können. Stellen Sie sich vor, der eine spricht nur Italienisch, der andere nur Deutsch. Das klappt nicht. Im Protokoll einigt man sich auf die "Sprache", z.B. Englisch (um im Beispiel zu bleiben).Das Wort "Protokoll" wird bestimmt häufiger fallen. Und falls Sie dabei an die Regeln für einen Staatsbesuch (auch "das Protokoll") denken, liegen Sie auch nicht so ganz falsch...

Also, warum fängt man überhaupt mit einer Standardisierung an? Weil man nichts besseres zu tun hat? Nun, im Regelfall dürfte es wohl handfestere Gründe geben. Also:

Im Rahmen meines Projektes galt es, eine gesicherte Übertragung von Syslog-Meldungen zu realisieren. Syslog ist ein auf vielen Betriebssystemen verfügbares Protokoll, das sowohl zum Systemmanagement, zur Überwachung von Anwendungen wie auch zur Auditierung verwendet wird. Eine große Schwachstelle des traditionellen Protokolls liegt darin, dass Nachrichten im Klartext und mittels unzuverlässiger Übertragung übermittelt werden. In unserem Softwarehaus stellen wir verschiedene Anwendungen mit syslog-Integration her. Wir sind mehrfach von Kunden angesprochen wurden, die eine sicherere Variante des Syslog-Protokolls wünschten.

Gefordert wurde vor allem die Vertraulichkeit der Daten auf dem Übertragungsweg. Darüber hinaus wurden auch Forderungen nach Sicherstellung der Authentizität der Kommunikations-partner (Peers) gestellt. Dies jedoch nur von einer kleineren Zahl von Kunden, was wir darauf zurückführen, dass syslog-Anwendungen sehr oft in speziell gesicherten Bereichen des Intranet abgewickelt werden, die beteiligten Systeme somit quasi transitiv die Authentizität von diesen Bereichen erben. Es sei hier angemerkt, dass eine wirkliche Vertraulichkeit ohne gegenseitige Authentifizierung der Peers nicht gewährleistet werden kann. In diesem Falle könnte die verschlüsselte Kommunikation nämlich mittels einer Man-in-the-Middle Attacke abgefangen werden. Dabei stellt sich quasi ein "Dritte" in die Mitte der eigentlichen Kommunikationsparter und tut so, als sei er der jeweils andere. Die beiden kommunizieren dann nur noch über den "Man in the Middle" und merken gar nicht, dass sie ihre Geheimnisse ausplappern.

Dies bliebe den eigentlichen Partnern verborgen, da ja die jeweilige Gegenstelle nicht authentifiziert ist, d.h. man weiss schlichtweg nicht, wer die Gegenstelle eigentlich ist. Man beachte ferner, dass der Kernvorteil von syslog seine nahezu universelle Verfügbarkeit in allen Betriebssystemen aber auch Netzwerkgeräten wie Routern, Firewalls und Switches ist. Mit der Entwicklung eines herstellerspezifischen (nicht-standard!) gesicherten syslog-Protokolles wäre das Kundenbedürfnis somit nicht zu befriedigen. Wichtig war somit eine Lösung, die weitreichende Akzeptanz auch bei anderen Herstellern fand.

In 2005 habe wir uns daher entschlossen, dieses Problem in zwei Schritten anzugehen: zum Einen versuchten wir eine Standardisierung im Rahme der IETF zu erreichen. Zum Anderen sollte eine erste Implementierung ("Proof of Concept") im Rahmen meines Open Source Projekts "rsyslog"[2] erfolgen. Gut traf es sich da, dass ich bereits seit 2003 der entsprechenden IETF "syslog"-Arbeitsgruppe im Bereich "Sicherheit" angehörte. Eine Besonderheit der IETF sei noch erwähnt. Anders als viele andere Standardorganisationen findet die Arbeit hier großteils via E-Mail-diskussionen statt. Das hat nebenbei bemerkt den großen Vorteil, dass die entsprechenden Diskussionen von jedem interessierten auch online abgerufen werden können. Der geneigte Leser kann sich also selbst ein Bild machen, wie es dort so zugeht...

Von der Idee zum Standard war es natürlich ein weiter Weg, doch dazu mehr im nächsten Blogpost.

Ähnliche Artikel:

• Wanderer zwischen den Blogs...
• Auf dem Weg zum Logging-Standard, Teil II
• Software-Evolution...
• DNS - was ist das?
• Bloggen ... wie?