Systeme und ihr Umfeld

Applikationsserver

Sicherheit für Lotus Domino

Von Chris Ditze-Stephan, Bad Vilbel

Im Lieferzustand ist es bei Applikationsservern im Allgemeinen und auch bei Lotus Domino mit der Sicherheit nicht allzu weit her. Innerhalb der letzten Jahre kam es immer wieder zu Vorfällen und Meldungen über Sicherheitslücken oder Fehlverhalten. Bei korrekter Konfiguration und Administration kann Lotus Domino jedoch durchaus als sicher gelten.

Applikationsserver haben von Haus aus nur wenige Sicherheitsmechanismen implementiert und noch weniger auch aktiviert. Mit der wachsendem Anzahl von im Internet präsenten Applikationsservern steigen die Angriffsfläche und die damit verbundenen Risiken. Legt ein Unternehmen die eigenen Daten in einem offen zugänglichen Netz ab, muss es zu seiner eingesetzten Technik schon ziemliches Vertrauen haben. Nicht selten sind allerdings heute auch Konzernnetze ähnlich unsicher zu bewerten wie öffentliche Netze.

Jedes Applikations-System ist unterschiedlichsten Gefährdungen ausgesetzt. Das Unternehmen oder auch der im Internet befindliche Host sind durch eine oder mehrere Firewalls geschützt; die bloße Netzwerksicherheit ist scheinbar schnell gegeben. Mindestens ebenso viel Aufmerksamkeit benötigen aber auch die Systeme, welche wichtige Unternehmensdaten beherbergen – spätestens dann, wenn diese per Extra- oder Internet erreichbar sind. Entprechend der Funktionsvielfalt der Applikationsserver gilt es eine große Zahl an Einstellungen korrekt zu konfigurieren.

Ein Lotus-Domino-Administrator benötigt umfangreiches Know-how, um einen Großteil der möglichen Schwachstellen erkennen und schließen zu können. Zwar existiert ab R5.0 Lotus Domino Administrator als separates Programm zur Verwaltung eines Domino-Servers, doch fehlen nach wie vor fundamentale Eigenschaften und Tools, welche die Absicherung des Systems ermöglichen. Zwar ist durch eigene oder von Dritten entwickelte Werkzeuge nahezu alles möglich, ein mitgeliefertes Security Toolset wäre jedoch mehr als wünschenswert.

Der Domino-Administrator verwaltet Benutzer, Gruppen, Datenbanken und nicht zuletzt den Server mit zahlreichen Diensten wie SMTP, POP und WWW. Die Komplexität des Gesamtsystems ist hoch und die Verwaltung dadurch erschwert. Die folgenden Seiten möchten bei der Erkennung und Behebung von wesentlichen Risiken und Schwachstellen helfen.

Wie für andere Systeme, tauchen auch für Lotus Domino immer wieder neue Meldungen über Verwundbarkeiten auf. Buffer Overflows oder Autorisierungsumgehungen gehören genauso dazu wie Instabilitäten einzelner Tasks oder des gesamten Domino-Servers. Hier gilt es, die einschlägigen Quellen wie die Sicherheits-Mailingliste BugTraq ( www.securityfocus.com) zu verfolgen und umgehend Maßnahmen zu ergreifen.

names.nsf

Die Benutzerverwaltung in Lotus Domino findet ausschließlich über die Datenbank names.nsf statt. Diese wurde früher als öffentliches Namens- und Adressbuch bezeichnet. Seit Version 5.x macht die Bezeichnung Domino-Verzeichnis die Anlehnung an X.500-Strukturen deutlich. Die bislang notwendige domcfg.nsf, die für die Verwaltung der virtuellen Server zuständig war, wurde durch neue Masken und Ansichten im Domino-Verzeichnis ersetzt. Lediglich für Login-Masken beim Einsatz von Session Authentification und einigen Fehlermeldungsmasken ist die domcfg.nsf noch von Bedeutung.

Das Domino-Verzeichnis stellt aufgrund einiger Schwachstellen eine Angriffsfläche mit nicht unwesentlichen Risiken dar. Der Defekt oder Verlust einer names.nsf kann letztlich zum Totalausfall der Domino-Infrastruktur führen. In einem solchen Fall laufen keine Server und die Benutzer erhalten keinen Zugriff. Abgesehen davon, dass so mancher Administrator schon einmal versehentlich ein Dokument aus dem Directory gelöscht haben dürfte, handelt es sich beim Domino-Verzeichnis um eine sehr robuste Datenbank mit hoher Fehlertoleranz – sofern man alle notwendigen Vorkehrungen getroffen hat.

Das Kopieren einer Lotus Notes Datenbank wie der names.nsf über den Windows Explorer oder einen ähnlichen Dateimanager führt nicht immer zu einer Sicherung der Datenbank. Unerfahrene Domino-Administratoren, aber auch Entwickler, fallen häufig auf diesen Fehler herein: Sie kopieren mithilfe des Window Explorers die betreffende Datenbank als Backup in ein anderes Verzeichnis auf ihrem Domino-Server. Liegt das Zielverzeichnis unterhalb des Lotus Domino Datenverzeichnis (z. B. /data) sorgen Notes-Client oder Domino-Server jedoch "intelligent" für die notwendige Replikation. Der Server durchsucht beispielsweise seine Verzeichnisse nach Datenbanken mit gleicher Replikations-ID und repliziert diese sofort miteinander. Mögliche Fehler oder Löschungen werden dann ebenfalls repliziert und die eigentlich als Sicherung gedachte Datenbank-Kopie ist ebenfalls auf dem – eigentlich nicht gewünschten – neuesten Stand.

Offene Zugriffskontrollliste des Dominoverzeichnisses

Neben der Offenlegung der Struktur der betroffenen Site eröffnet eine mindestens lesbare names.nsf einem Datenspion eine Reihe von Möglichkeiten: So neigen einige Administratoren dazu, die ID-Dateien von Servern oder Personen in ihren Dokumenten zu lagern. Hat ein Angreifer Leserechte auf das Dominoverzeichnis, so kann er sich die IDs sogar mit einem Webbrowser einfach aneignen. Der Spion kann dann versuchen, mit einem Notes-Client das Passwort zu erraten. Immerhin befindet sich in dieser ID-Datei in vielen Fällen ein Standardpasswort, das im Unternehmen ohnehin jeder kennt.

Zugriff via LDAP

Sehr hilfreich für die Integration in Single-Sign-On-Systeme oder das Publizieren von Verzeichnissen ist Lotus Domino mit LDAP. Nicht selten wird dieser Dienst standardmäßig und ungeschützt auf einem neu installierten Server aktiviert. Anschließend kann jeder mit einem LDAP-Client auf die Einträge im Domino-Verzeichnis zugreifen und Adressinformationen auslesen. Zwar sind dies nicht alle verfügbaren Informationen und sicherlich auch nicht die wichtigsten, doch kann schon allein die Kenntnis der angelegten Benutzer interessante Rückschlüsse zulassen.

Weitere Datenbanken

Häufig findet man im Internet Domino-Server, die nur wenig vor neugierigen Augen geschützt sind. Systemdatenbanken liegen ungeschützt herum und können von jedermann gelesen werden. Eine der Hauptursachen sind ein fehlender "Anonymous User" in der Zugriffskontrollliste (ACL) und ein Default-User mit Leser-Rechten. Hin und wieder findet man sogar Schreibrechte für anonyme Benutzer – ein Umkonfigurieren oder der herkömmliche Datenklau sind dann für Angreifer kein Problem.

Ein Mausklick entscheidet bei Domino-Datenbanken über die Zugriffsrechte für Benutzer und Rollen. Oft wird übersehen, dass Autor-Recht auch Leserecht bedeutet.

Ähnlich wie das beinahe reflexartige Eintippen von dir oder ls an Rechnerkonsolen, versucht sich der Lotus-Domino-Profi per Webbrowser an URLs wie www.zentric.com/names.nsf oder www.lotus.com/catalog.nsf. Am elegantesten ist es für einen Datenspion, wenn er den Datenbankkatalog (catalog.nsf) lesen kann. Darin findet er eine Komplettübersicht über alle Datenbanken und ihre Zugriffsrechte. Nicht selten wurde vergessen, die catalog.nsf mit einem Anonymous-User zu versehen und der User Default regelt sämtlichen Webzugriff – in der Regel mit Leserechten.

Domino-Server-Logbücher (log.nsf und domlog.nsf) können personenbezogene Daten enthalten. Sind diese Datenbanken nicht entsprechend gesichert, so sind die Server-Zugriffe der letzten Tage bis Wochen für alle Welt sichtbar. Auch hieraus lässt sich einiges ableiten. Zum Beispiel: Wo liegen Datenbanken? Wo gibt es eventuell HTML-Seiten? Wer greift wann zu? Mit welchen anderen Servern wird repliziert?

In einer Internet-Umgebung sollte man zudem generell auf sämtliche Vorlagen (*.ntf) verzichten. Belassen Sie diese auf den internen Servern und aktualisieren Sie durch Replikation. Entfernen Sie außerdem sämtliche Hilfe-Datenbanken und alle sonst nicht benötigten Datenbanken (z. B. News Datenbanken, homepage.nsf, LDAP Schema usw.). Letztlich bedeutet jede unnötige Datenbank mehr Administrationsaufwand und weniger Übersichtlichkeit.

Passwörter

Der Lotus Notes-Client handhabt den Schutz vor Brute-Force-Passwort-Attacken, indem sich die Aufforderung zur Passworteingabe von Fehlversuch zu Fehlversuch exponentiell verzögert. Benutzt man für den Zugriff auf den Domino-Server einen Webbrowser, fehlt ein derartiger Widerstand vollständig. Man kann nach Herzenslust Passwörter probieren. Weder nach vier, fünf oder hundert kontinuierlichen Versuchen wird man davon abgehalten. Für Server, die sich per Webbrowser ansprechen lassen, ist daher eine Passwort-Policy empfehlenswert, die längere Passwörter mit mindestens einer Ziffer oder einem Sonderzeichen fordert.

Im Übrigen gehen Passworteingaben in Webbrowsern per HTTP unverschlüsselt durch das Netz und sind damit – im Intra- wie im Internet – durch Sniffer-Attacken gefährdet. Dabei können Angreifer durchaus auch Zugangsinformationen zu anderen Systemen auffangen: Mancher Anwender neigt dazu angesichts der Vielzahl von Passwörtern, die er sich einprägen muss, versehentlich auch falsche, in anderen Systemen aber gültige Passwörter einzugeben.

Für den Einsatz von Webbrowsern – sei es für anonyme oder autorisierte Benutzer – bietet sich der Einsatz von SSL an, um das Abhören von Passwörtern und übertragenen Informationen zu verhindern. Lotus Domino bietet zu diesem Zwecke die Nutzung und Verwaltung von Server- als auch Client-Zertifikaten an. Die hierfür notwendigen Zertifikate können sowohl von einem externen Dienstleister eingekauft als auch mit einem eigenen CA-Server erstellt werden. Der Lotus Domino-Server ist dazu durchaus in der Lage.

Bei sicherheitsrelevanten Datenbanken oder Zugangskennungen sollte die Kommunikation zwischen Server und Web-Client durch SSL geschützt werden.

Seit Version 5.x gibt es auch eine sessionbasierete Authentifikation. Diese ermöglicht die Nutzung einer Reihe von Eigenschaften, die sonst nicht möglich wären, beispielsweise Timeouts für HTTP-Verbindungen oder auch Session Tracking. Allerdings müssen hierfür im Webbrowser Cookies erlaubt werden.

Ein weiteres Problem in Verbindung mit der Passworteingabe in Browsern ist das Speichern von Passwörtern durch die Internet-Software. So bietet beispielsweise der Internet Explorer immer wieder an, Passwörter aus Komfortgründen lokal abzulegen. Hier sollte eine entsprechende Security Policy den Benutzern untersagen, diese Funktion zu verwenden – insbesondere wenn PCs mehreren Anwendern zur Verfügung stehen.

Die Internetpasswörter für Anwender lassen sich nur im Domino-Verzeichnis ändern. Auch wenn das lästige Mehrarbeit bedeutet, sollte man dort keinesfalls aus Bequemlichkeitsgründen den Anwendern Schreibrechte einräumen, um Änderungen selbst durchzuführen, sondern diese grundsätzlich dem Administrator vorbehalten.

Vertraulichkeit

Die Kommunikation zwischen Domino-Server und Notes-Client ist über das Internet per TCP/IP genauso möglich wie im lokalen Netz. In der Standardkonfiguration wird der Datenstrom allerdings nicht verschlüsselt – die entsprechende Option muss nachträglich aktiviert werden.

Die Verschlüsselung zwischen Notes-Client und -Server ist schnell aktiviert und sorgt für die notwendige Vertraulichkeit einer Verbindung.

Während die Kommunikation auf diese Art und Weise relativ einfach zu sichern ist, bleiben die Datenbanken an sich zunächst unverschlüsselt. Lokale Angreifer oder Eindringlinge, die per Internet Zugriff auf den Server-Computer erlangt haben, können sie gegebenenfalls mittels Hexeditor oder Zusatztools lesen oder manipulieren. Verschlüsseln Sie daher alle Datenbanken auf Ihrem Domino-Webserver.

Um Spionage oder Manipulationen über das Filesystem zu verhindern, sollte man Datenbanken verschlüsselt speichern.

Entwicklung

Lotus-Domino-Entwicklern können beim Erstellen und Pflegen von Datenbanken schnell eine Reihe von Fehlern unterlaufen. Nicht selten führen diese dazu, dass die Anwendungen unerwünscht lesbar und modifizierbar sind oder das Gesamtsystem durch leistungsfressende Agenten oder Ansichten in die Knie gezwungen wird. Jede neue Anwendung sollte daher einem strengen Freigaberitual unterliegen. Selbst bei einfachen Änderungen ist für die entsprechende Qualitätssicherung zu sorgen.

Typische Entwicklerfehler sind das "kurzfristige" testweise Öffnen der Zugriffskontrolliste (ACL), bei dem man dem Default- oder gar Anonymous-User Manager-Rechte einräumt. Es wird leicht vergessen, diese Änderung wieder zurückzunehmen.

URL als Passwort

Domino-URLs bieten dem Webbenutzer eine Reihe von Zugriffmöglichkeiten. Ganz ohne Navigationselemente kann ein erfahrener Anwender Inhalte und Elemente einer Datenbank via Browser aufdecken. Wie verhindert man also, dass ein Anonymous alle enthaltenen Daten einsehen oder verändern kann? Oft hilft hierbei die Anpassung der Ansichtendarstellung. Legen Sie immer eine Maske namens $$ViewTemplateDefault an. Nutzen Sie diese für nichts anderes als dazu, alle Ansichten, für die nichts anderes geregelt wurde, unsichtbar zu machen. Gegebenenfalls kann man diese Maske mit einem Text versehen, der auf den unberechtigten Zugriff hinweist. Das sonst in derartigen Masken notwendige Feld namens $$ViewBody wird hier nicht hinterlegt.

Leider gibt es seit einiger Zeit eine Möglichkeit, diese Einstellung zu umgehen: URLs in der Art http://www.zentric.com/test.nsf/sampleview?readviewentries sind eigentlich dazu gedacht, Ansichten als XML-Daten auszugeben. Da hier auch IDs von Dokumenten genannt werden, kann der Besucher diese mit ein bisschen Fantasie schnell erreichen. Damit ist das leere ViewDefaultTemplate keineswegs ein sicherer Schutz. Genauso wenig hilft das Verstecken von Ansichten, durch das "In-Klammern-Setzen" des Ansichtennamens, z. B. "($A11)". Mit einem Notes-Client kann man dies durch Drücken der Shift-Taste während des Öffnens der Datenbank umgehen, bei einer URL ist einfach möglich, die Klammern, die Bestandteil des Namens der Ansicht sind, mit einzugeben.

Eine Maske namens $$ViewTemplateDefault kann helfen, die Struktur eines Domino-Servers vor dem Ausforschen per URL zu verbergen.

URLs verraten Strukturen

Oft lassen Namensanteile in der URL Rückschlüsse auf deren Funktion und andere URLs zu. So lässt sich einfach folgern, dass neben einer URL http://www.zentric.com/test.nsf/entry?OpenForm zum Öffnen, die URL http://www.zentric.com/test.nsf/entry?EditForm das Bearbeiten ermöglicht. Außerdem sind die möglichen URLs kein Geheimnis und können im Internet und diversen Handbüchern nachgelesen werden. Von einem "Schutz" auf Basis von Unwissenheit ist dringend abzuraten.

Hierbei wird immer wieder übersehen, dass die Kenntnis der Datenbank-Struktur auch ohne Kenntnis der Inhalte für einige Probleme sorgen kann. Die URL http://www.zentric.com/test.nsf?OpenDatabase öffnet zum Beispiel die entsprechende Datenbank und zeigt, wenn nicht anders definiert, die Standard-Ansicht an. Im Zweifelsfalle wird die Default-Ansicht als Variable übergeben: http://www.zentric.com/test.nsf/$DefaultView?OpenView. Sie ermöglicht – zumindest – den Lesezugriff auf eine Datenbankansicht.

Eines der größten Risiken liegt in der Möglichkeit die URL http://www.zentric.com?OpenServer erfolgreich zum Server zu senden. Das Ergebnis ist eine Liste sämtlicher auf dem Server angelegten Datenbanken. Der Besucher kann in aller Ruhe die Verzeichnisse durchstöbern. Gegebenenfalls lassen bereits Verzeichnis- und Dateinamen wertvolle Rückschlüsse zu.

Suchmaske

Eine weitere Quelle für – eventuell unerwünschte – Informationspreisgabe sind Suchabfragen, die ein Domino-Server dem Besucher anbietet. Jede Domino-Datenbank ist von Haus aus mit einer Standardsuchmaske ausgestattet, die immer dann funktioniert, wenn die Datenbank volltextindiziert wurde. Über eine Eingabe in der Art von http://www.zentric.com/test.nsf/$defaultview/$searchform?SearchView erreicht man diese Suchmaske und ist in der Lage sie auch zu benutzen.

Um zu verhindern, dass hierdurch unerwünschter Zugriff möglich ist, verfährt man ähnlich wie mit den Ansichten und legt in sämtlichen Datenbanken eine Maske mit dem Namen $$SearchTemplateDefault als leere Maske an. Für die Anzeige der Suchergebnisse benutzt man hier eher Masken mit dem Namen "$$SearchTemplateDefault for Ansichtenname" (wobei Ansichtenname als Platzhalter für die exakte Bezeichnung der Ansicht steht).

Sofern Datenbanken volltextindiziert sind, liefert der Domino-Server über eine Standard-Suchmaske eventuelle unerwünschten Zugang.

Formeln

Entwickler hinterlegen für die Entscheidung, welche Dokumente in einer Ansicht dargestellt werden, gern eine Formel, die durch Vergleich von @UserName oder @ClientType mit dem angemeldeten Benutzer eine Anzeige erlaubt oder unterbindet – oder dazu sogar auf die CGI-Variable Referer zurückgreift. Das kann jedoch nicht als ernsthafte Sicherheitsvorkehrung gelten. Denn damit sind die Dokumente selbst nicht vor Zugriff geschützt. Erhält ein neugieriger Besucher Kenntnis über die Dokumenten-IDs, ist er in der Lage, die Dokumente dennoch zu finden und zu lesen.

Agenten

Per ?OpenAgent-URL können Web-User Agenten starten. Weiß ein Angreifer, dass Agents existieren und wie diese benannt sind, steht ihm ein weites Feld für Sabotage offen: Entweder er versucht, durch ständiges Ausführen der Agenten den Domino-Server zu überlasten oder er kann durch Rückschlüsse auf deren Funktionsweise den oder die Agenten missbrauchen. Ein Benachrichtigungs-Agent sendet dann möglicherweise unaufhörlich an bestimmte Benutzer oder ein Bestellagent wiederholt seine Bestellprozedur ganz nach Belieben des Besuchers.

Wie immer empfiehlt es sich, Agenten, die nicht zwingend benötigt werden, aus den Datenbanken zu entfernen. Ein wirksamer Schutz ist zudem, Agenten nur in einem bestimmten Kontext zu erlauben: Beispielsweise lässt sich die Ausführung von Agents von der CGI-Variable http_Referer oder dem DocumentContext des ursprünglichen Dokumentes abhängig machen.

Betriebssystem

Ein oft unterschätzter Angriffspunkt auf Applikations-Server sind auch die verwendeten Betriebssysteme. Hier sollte der Administrator sich der entsprechenden Werkzeuge und Checklisten bedienen, die ein Härten der jeweiligen Systeme vereinfachen. Ein klares und verständliches Ritual zur Planung und Freigabe von Systemanpassungen und Systempatches ist dringend empfehlenswert.

Chris Ditze-Stephan ist Geschäftsführer der Zentric GmbH & Co KG – IT Security & Groupware Applications.

© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 3/2001, Seite 68

Zurück zum Inhalt