Auf dem Weg zum Logging-Standard, Teil II

Willkommen zum zweiten Teil meiner kleinen Geschichte der Entwicklung eines neuen Logging-Standards. Heute widme ich mich primär der Arbeit im Standardgremium. Heraus gepickt habe ich mit dabei wieder das Projekt "sichere Syslog".

Ganz ohne Technik wird es auch heute nicht abgehen. Ich bemühe mich, die Fachbegriffe im laufenden Text zu erklären, aber ansonsten haben wir ja die Kommentarfunktion.

Zur Rekapitulieren: die Entwicklung einer sicheren Meldungstragung via syslog war gefordert. Da das Herstellerübergreifend funktionieren musste, strebten wir die Standardisierung im Rahmen der IETF. Die Diskussion in den entsprechenden Arbeitsgruppen erfolgt primär per E-Mail.

Die Arbeiten begannen zunächst mit der Definition der Bedrohungsszenarien - schließlich muss man ja erst einmal wissen, wovor man sich überhaupt schützen muss. Schwierig war dabei insbesondere einen möglichst guten Kompromiss zwischen sinnvollen Mindeststandards sowie einer weiten Akzeptanz (sowohl bei Benuzern wie Herstellern) zu finden. In diesem Zusammenhang sei der Standard RFC3195 erwähnt, das zwar viele der gestellten Anforderungen bereits erfüllte, aber, scheinbar aufgrund seiner Komplexität, keine Akzeptanz bei den Soft-ware¬herstellern fand. Man mag vermuten, dass der Aufwand für die Programmierung einfach als zu hoch eingeschätzt wurde - insbesondere wohl, weil die Logging-Eigenschaften eines Produkts eher selten ganz vorne auf den Hochglanzprospekten stehen...

Als kritischer Punkt kristallisierte sich bereits in dieser Phase die gegenseitige Authentifizierung der Kommunikationspartner heraus. Bei der Authentifizierung machen sich die beiden Quasi miteinander bekannt, identifierzieren sich also gegenseitig. Man muss sich das weniger als ein lockeres Geplauder, sondern vielmehr als eine gegenseitigen Prüfung der Personalausweise vorstellen.

Nach den ursprünglichen Vorschlägen wäre für die Authentifizierung eine vollständige sogenannte "PKI-Infrastruktur" erforderlich gewesen. Darunter versteht man alle Systeme und Maßnahmen, die zu einer "globalen" "Ausweisprüfung" gehören. Man darf sich von diesem Wort auch getrost erschrecken lassen, der Aufwand für eine PKI ist im Regelfall recht hoch. Dies wäre daher auch aus Sicht vieler Installationen eine viel zu umfangreiche Lösung gewesen.

Man bedenke dabei, dass Syslog sowohl in Kleinumgebungen (Heimanwender mit DSL-Router und einem PC) wie auch in Großunternehmen eingesetzt wird. Für Heimanwender wäre der Aufbau einer solchen Sicherheitsinfrastruktur schlichtweg unzumutbar gewesen, viele große Anwender hingegen haben eigene, gut begründete,Vorstellungen davon, welche Zertifikatsverwaltungen (das Zertifikat entspricht hier dem Personalausweis) erforderlich sind. Eine vorgegebene "Standard-PKI" wäre nicht akzeptabel gewesen.

Die Hauptanforderung einer großen Anwendergruppe lag lediglich darin, dass niemand die Nachrichten abhören kann ("sicherer Kanal"). Der (im ersten Teil beschriebene) "Man in the Middle" wurde als nicht ganz so gefährlich angesehen (nun ja...). Es gelang, die Anforderungen an den zu erstellenden Standard dahingehend zu modifizieren, dass der Aufbau des sicheren Kanals auch ohne gegenseitige Identitätsprüfung ermöglicht wurde.

In der syslog-Arbeitsgruppe war uns bewusst, dass dies eine Einschränkung der Sicherheit bedeutet. Das wurde  allerdings in Kauf genommen, um die weite Verfügbarkeit einer Basissicherheit zu ermöglichen. Denn anderenfalls wären sehr viele Anwender wieder auf das gänzlich ungesicherte alte Protokoll ausgewichen, was noch schlechter wäre. Wir haben also bewusst eine Verschlechterung des Standards in Kauf genommen, um seine Verbreitung zu fördern.

Allerdings waren wir um möglichst gute Sicherheit bemüht: Der Kompromiss geht dahin, dass im Standard von konformen Anwendungen zwingend gefordert wird, sowohl authentifizierten als auch anonymen Zugriff auf zu ermöglichen, dem Anwender jedoch die Wahl bleibt, welche dieser Möglichkeiten er verwendet. Von der Nutzung des anonymen Zugriff wird abgeraten. Dies ist als starker Hinweis zumindest an größere Anwender gedacht.

Im Klartext bedeutet das, dass wir den weniger sicheren Modus zwar erlaubten, seine Benutzung aber keineswegs empfahlen. Nach zunehmender Verbreitung des Standards kann hier in Folgearbeiten restriktiver vorgegangen werden. Ich bin aber nach wie vor der Überzeugung, dass der gefundene Kompromiss ein guter ist, der gerade auch in Kleinunternehmen der Datensicherheit förderlich ist - weit mehr, als wenn man auf einer "perfekten" Lösung bestanden hätte, und die aber nicht eingesetzt wird.

Die genauen Details des Kompromisses sind wohl primär für Technikinteressierte von Bedeutung. Dennoch möchte ich im nächsten Posting einmal versuchen, diese doch etwas schwierige Materie  "greifbarer" zu machen. Das kann auch von daher interessant sein, weil viele der Fragen, die wir uns stellten, so oder in anderer Form immer wieder in sicherheitsrelevanten Umgebungen auftreten.