Bundesamt für Sicherheit in der Informationstechnik

M 4.407 Protokollierung beim Einsatz von OpenLDAP

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, Fachverantwortliche

Da Open LDAP in der Regel eine zentrale Komponente eines Netzes darstellt, sind Aktivitäten in OpenLDAP zu protokollieren und zu überwachen, um beispielsweise technische Probleme oder Angriffsversuche frühzeitig zu bemerken. Für OpenLDAP bestehen mehrere Möglichkeiten, Protokolle von Ereignissen anzulegen und den aktuellen Zustand des Systems zu überwachen.

Die Protokolldaten müssen unter Beachtung organisationsinterner Vorgaben regelmäßig ausgewertet werden, um Missbrauch und Systemfehler zu erkennen. Bei der Protokollierung und Überwachung eines zur Benutzerverwaltung eingesetzten Verzeichnisdienstes fallen zwangsläufig personenbezogene Daten an, die zur Leistungs- oder Verhaltenskontrolle geeignet sind. Wenn Protokollierung und Überwachung eingerichtet werden, sollten deshalb der Datenschutzbeauftragte (siehe auch M 2.110 Datenschutzaspekte bei der Protokollierung ) und die zuständige Mitarbeitervertretung beteiligt werden. Die Auswertung kann manuell oder mit Unterstützung eines Tools erfolgen. Im Vorfeld sollten kritische Ereignisse definiert werden, also solche, bei deren Auftreten ein Administrator zu benachrichtigen ist.

Debug und Syslog

Der slapd-Server verfügt über eine Debug-Funktion, um insbesondere technische Fehler zu identifizieren. Diese Funktion wird verwendet, wenn der slapd-Server mit dem Parameter "-d" gestartet wird:

slapd -d [Loglevel] -d [Loglevel] ....

Beim Start des slapd-Servers mit dem Parameter "-d" wird der slapd-Server im Gegensatz zum Aufruf ohne Debug-Funktion nicht vom aufrufenden Terminal getrennt und weiter im Vordergrund ausgeführt. Die Debug-Meldungen werden über die Standard-Ausgabe ausgegeben, in der Regel ist dies das aufrufende Terminal.

Der slapd-Server ist auch in der Lage, die Debug-Ausgaben an den Systemdienst Syslog zu leiten, der auch anderen zentralen Überwachungswerkzeugen als Basis dient. Statt des Parameters "-d" ist dafür der Parameter "-s" beim Aufruf zu verwenden, die Zahlen und Aliase der Loglevel bleiben gleich. Das gleiche Ergebnis wird durch die Angabe der Loglevel in der globalen Direktive "logLevel" (slapd.conf) bzw. "olcLogLevel" (slapd-config) erreicht. Syslog oder andere zentrale Werkzeuge werden insbesondere für große Strukturen empfohlen, da eine manuelle Kontrolle von Ereignissen dort kaum noch darstellbar ist. Bei akuten technischen Problemen ist die Debug-Funktion in der Konsole allerdings hilfreicher, da Syslog bei steigender Belastung oft nur zeitverzögert aktuelle Ereignisse ausgibt oder bei zu zahlreichen Nachrichten einige nicht verarbeitet.

Neben der Suche nach einem akuten technischen Fehler sind die technischen Protokolle geeignet, Unzulänglichkeiten der Konfiguration aufzudecken, die bisher nicht bemerkt wurden. Ist zum Beispiel aus den Protokollen ersichtlich, dass häufig nach einem bestimmten Attribut gesucht wird, für das kein Index existiert (index_param failed), so sollte ein entsprechender Index erzeugt werden, um aufwändige Suchläufe zu vermeiden.

Die Debug-Funktion ist nicht dazu geeignet, die fachliche Nutzung des Verzeichnisdienstes zu protokollieren. Die Ausgaben sollten deshalb regelmäßig gelöscht werden, nachdem sie analysiert wurden.

Protokollierung durch auditlog

Über das Overlay "auditlog" (Audit Logging) können alle Veränderungen an einer Datenbank in eine Datei im Format LDIF geschrieben werden. Das Overlay kann nur Veränderungen aufzeichnen und ist schlecht anpassbar. Der Funktionsumfang ist wesentlich geringer als der des neueren Overlays "accesslog". Das Overlay "auditlog" wird gelegentlich eingesetzt, wenn keine Notwendigkeit besteht, erfolgte Zugriffe zu erfassen und dies zum Beispiel aus Datenschutzgründen sicher vermieden werden soll.

Protokollierung durch accesslog

Mit dem Overlay "accesslog" (Access Logging) können alle Zugriffe auf eine Datenbank erfasst werden. Das Overlay wird auch im Rahmen der Delta-Replikation verwendet. Es wird benötigt, um die geänderten Attribute aufzuzeichnen, damit nur diese im Rahmen der Replikation an den Consumer übermittelt werden müssen (siehe M 4.389 Partitionierung und Replikation bei OpenLDAP ).

Das Overlay zeichnet sich durch folgende Eigenschaften aus:

  • Es ist möglich, die Protokollierung durch die Sub-Direktive "logops" auf bestimmte Operationen wie ausschließlich Schreibzugriffe zu beschränken.
  • Es können auch nicht erfolgreiche Zugriffe aufgezeichnet werden (Sub-Direktive "logsuccess FALSE"). Treten erfolglose Zugriffsversuche gehäuft auf, sollte dies näher untersucht werden. Mögliche Gründe dafür sind:
    • Zugriffsrechte wurden fehlerhaft vergeben.
    • Anwender wurden unzureichend geschult.
    • Ein Angreifer versucht, unzulässige Operationen im Verzeichnisdienst durchzuführen.
    • Die Protokolldaten werden in einer anderen Datenbank abgelegt, die über die Sub-Direktive "logdb" festgelegt wird. Durch eine geschickte Rechtevergabe beziehungsweise Replikation der Datenbank besteht die Möglichkeit, die Aufzeichnungen von Zugriffen dem Einflussbereich der Administratoren zu entziehen.
    • Durch die Ablage der Zugriffe in einer LDAP-Datenbank sind die Einträge selbst via LDAP zugänglich. Entsprechend stehen komfortablere Auswertungsmöglichkeiten zur Verfügung, als dies bei einem normalen Protokoll in Form einer Textdatei der Fall ist.
    • Das Overlay kann über die Sub-Direktive "logpurge" angewiesen werden, Inhalte der Datenbank in bestimmten Intervallen zu löschen, zum Beispiel täglich alle Inhalte, die älter als zwei Wochen sind. So können unter anderem Vorgaben des Datenschutzes technisch unterstützt werden.

Das Overlay "accesslog" stellt die beste Möglichkeit dar, Protokolle über die fachliche Nutzung des Verzeichnisdienstes anzulegen. Dies ist insbesondere sinnvoll, um zum Beispiel regulatorische Anforderungen wie die Eingabekontrolle des Bundesdatenschutzgesetzes (BDSG) zu erfüllen.

Monitoring via back-monitor

In jedem Fall werden bei der Durchsicht von Protokollen relevante Ereignisse wie Sicherheitsvorfälle lediglich im Nachhinein betrachtet. Bei einer zentralen Software, wie dem Verzeichnisdienst einer Institution, ist der laufende Betrieb zu überwachen (Monitoring). OpenLDAP stellt dafür benötigte Funktionen über das Backend "back-monitor" zur Verfügung. Aufgrund der schützenswerten Daten des Monitorings sollte eine restriktive eigene ACL für das Backend in Betracht gezogen werden (siehe M 4.387 Sichere Vergabe von Zugriffsrechten auf OpenLDAP ).

Das Suffix ist im Gegensatz zu den meisten anderen Datenbanken in OpenLDAP fest vorgegeben. Es ist immer "CN=monitor". "back-monitor" gehört zur Klasse der dynamischen Backends, das heißt, eine Suche mittels ldapsearch oder ähnlichen Tools greift nicht auf einen geschriebenen Datenbestand zu, sondern generiert die Daten bei Anfrage. Für den Benutzer geschieht dies allerdings transparent, so dass das Backend "back-monitor" mit dem Werkzeug ldapsearch von OpenLDAP ebenso wie mit grafischen Oberflächen oder speziellen Anwendungen für Überwachungszwecke abgefragt werden kann.

Die durch das Backend "back-monitor" verfügbaren Informationen sind sehr umfangreich und wachsen proportional mit dem eingerichteten Funktionsumfang von OpenLDAP. Es wird deshalb empfohlen, eine Dokumentation anzulegen, welche Werte anzuschauen sind. Sinnvolle Objekte für das Monitoring sind beispielsweise:

CN=Backends, CN=Monitor

Dieses Suffix liefert Informationen über vorhandene Backends. Die Kindelemente enthalten Informationen zum jeweiligen Backend, seinem Status und unterstützten Funktionen.

CN=Databases, CN=Monitor

"Databases" gibt Informationen über eingerichtete Datenbanken aus. Die Kindelemente enthalten Informationen zur jeweiligen Datenbank.

CN=Overlays, CN=Monitor

Dieser Teilbaum liefert Informationen über genutzte Overlays. Die Kindelemente enthalten Informationen zur jeweiligen Datenbank.

CN=Connections, CN=Monitor

"Connections" enthält Informationen über bestehende Verbindungen. Die Kindelemente enthalten jeweils Details zu einer Verbindung. Daneben gibt es zwei besondere Kindelemente, die die Anzahl von allen (CN=Total, CN=Connections, CN=Monitor) sowie der bestehenden Verbindungen (CN=Current, CN=Connections, CN=Monitor) angeben. Die bestehenden Verbindungen sollten unter anderem vor dem Anhalten des Verzeichnisdienstes geprüft werden.

CN=Listener, CN=Monitor

Dieses Suffix enthält Angaben über IP-Adressen und Ports, an denen der slapd-Server auf Verbindungen wartet. Hier sollte regelmäßig überprüft werden, dass nur bewusst eingerichtete Verbindungsmöglichkeiten aktiv sind.

CN=Operations, CN=Monitor

"Operations" liefert Informationen über initiierte und abgeschlossene Operationen. Die mögliche Ausgabe ist sehr umfangreich. Sie sollte nur anlassbezogen erfolgen und dann nach den entsprechenden Operationen wie "bind", "add", "delete" gefiltert werden. Die aktuell durchgeführten Operationen sollten zum Beispiel vor dem Anhalten des Verzeichnisdienstes geprüft werden.

CN=Statistics, CN=Monitor

Der Teilbaum liefert statistische Angaben über die vom Server übermittelten Daten. Für die Ausgaben sollte eine Historie von Erfahrungswerten geführt werden, um dann regelmäßig auf Anomalien prüfen zu können.

Die Überwachung von OpenLDAP sollte mit einer Überwachung des IT-Systems, auf dem OpenLDAP betrieben wird, einhergehen. Die Funktionsfähigkeit von OpenLDAP hängt auch wesentlich von der verfügbaren Prozessorleistung und dem Speicherplatz für die Datenbank ab. Diese Größen werden jedoch nicht von den Überwachungsfunktionen von OpenLDAP abgedeckt.

Prüffragen:

  • Erfolgt eine Protokollierung der Aktivitäten von OpenLDAP?

  • Werden die Debug-Ausgaben von OpenLDAP lediglich zur technischen Problembehebung eingesetzt und regelmäßig gelöscht?

  • Wird der laufende Betrieb des slapd-Servers mit geeigneten Werkzeugen wie back-monitor überwacht?

  • Werden die OpenLDAP-Protokolle unter Beachtung organisationsinterner Vorgaben regelmäßig ausgewertet?

  • Ist die Überwachung des IT-Systems, auf dem OpenLDAP eingesetzt wird, gewährleistet?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK