Novell NetWare in der Praxis, Teil 2: Rundum geschützt in NetWare
Artikel erschienen in Swiss IT Magazine 2001/18
Novell hat sich in den letzten Jahren wieder zunehmend auf seine Stärken besonnen. Nach all den missglückten Ausflügen in Bereiche wie Office-Anwendungen und Client-Betriebssysteme liegt der Schwerpunkt nun wieder auf zwei eng miteinander verzahnten Themenbereichen: Verzeichnisdienste und Sicherheit. Auch die E-Business-Strategie von Novell fokussiert schliesslich auf die Bereitstellung sicherer Infrastrukturen.
Die Grundlage dafür wird mit NetWare und NDS gelegt - und einer Vielzahl von Sicherheitsdiensten und -funktionen, die in diesen Systemen integriert sind. Mit NetWare 5.x sind insbesondere die Public-Key-Technologien in den Mittelpunkt gerückt. Diese spielen gerade auch im Zusammenhang mit der Positionierung des NDS eDirectory 8.x als Basis für LDAP-basierende Verzeichnisdienste im Internet eine wichtige Rolle. Die Basis für Sicherheit bei NetWare und NDS wird aber mit den klassischen Authentifizierungsfunktionen für Anwender im LAN gelegt.
Dabei wird allerdings schnell deutlich, dass Public-Key-Verfahren für Novell keineswegs Neuland sind. Sie werden auch bei der regulären Anmeldung mit einer Kombination aus Benutzername und Kennwort schon seit langem angewendet. Die Informationen für die Überprüfung der Anmeldung werden in den Benutzerobjekten der NDS abgelegt. Im Rahmen des Anmeldeprozesses wird nur der Benutzername an den NDS-Server übergeben, der die Authentifizierung durchführt. Dagegen wird das Kennwort selbst nie über das Netzwerk übertragen. Vielmehr wird, ähnlich wie bei Kerberos, vom Server eine decodierte Information übertragen, die nur mit dem korrekten Kennwort entschlüsselt werden kann. Dabei handelt es sich um den privaten Schlüssel des Benutzers, den dieser verwendet, wenn er auf Dienste zugreifen möchte. In diesem Fall bildet er einen Authenticator, den er mit seinem privaten Schlüssel codiert. Dadurch entsteht seine Signatur. Diese wird mit der Anforderung für die Authentifizierung und anderen Informationen zusammengefasst und über das Netzwerk übertragen. Der Server kann dann die Authentifizierung durchführen und übermittelt als Ergebnis eine Bestätigung.
Dieses Verfahren bietet ein hohes Mass an Sicherheit, da keine kritischen Informationen in unverschlüsselter Weise übermittelt werden. Wichtig für den Anwender ist auch, dass alle Authentifizierungsschritte nach der ersten Anmeldung am System im Hintergrund erfolgen und für ihn damit transparent sind.
Eine weitere wichtige NetWare-Basistechnologie sind die Paketsignaturen, mit denen NCP-Pakete versehen werden können. NCP ist das NetWare Core Protocol. Es wird für die gesamte Kommunikation zwischen Clients auf der einen und File- und Print-Servern auf der anderen Seite eingesetzt. Diese Signaturen können für eine permanente Authentifizierung von Clients und Servern genutzt werden, so dass auch keine Man-in-the-Middle-Angriffe in einer erst einmal aufgebauten Verbindung durchgeführt werden können. Das Level kann bei den Clients lokal gesteuert werden. Auf dem Server wird dafür ein SET-Befehl oder die Option set ncp packet signature options in servman.nlm verwendet.
Innerhalb der NDS wird mit einem mehrstufigen Konzept für die Vergabe von Zugriffsberechtigungen gearbeitet. Für Administratoren, die beispielsweise mit NDS eDirectory arbeiten, aber keine längere NetWare-Vergangenheit haben, sind dabei einige Begriffe etwas irritierend, da sie über die Jahre im Novell-Umfeld entstanden sind und keine Analogien in anderen Systemen haben.
Nach der Authentifizierung erfolgt beim Zugriff auf die NDS beziehungsweise auf NetWare-Server jeweils eine objektbezogene Analyse darauf hin, ob auch tatsächlich Zugriffsberechtigungen bestehen. Diese können sowohl für die NDS als auch für Dateien und Verzeichnisse auf NetWare-Servern detailliert konfiguriert werden. Dabei gibt es eine Reihe von Konzepten, die miteinander in engem Zusammenhang stehen.
Grundsätzlich können Zugriffsberechtigungen direkt einzelnen Objekten zugeordnet werden. Wenn für ein Containerobjekt Berechtigungen vergeben werden, vererben sich diese immer auch auf die untergeordneten Containerobjekte und auf Blattobjekte in diesen Containern. Die Berechtigungen können dabei sowohl für das Objekt als auch für einzelne Eigenschaften eines Objekts gesteuert werden.
Trustee Assignments - der Trustee bezeichnet einen Treuhänder - geben an, dass einem Objekt explizite Rechte für den Zugriff und die Verwaltung eines anderen Objekts gegeben wurden. Es können also beispielsweise einer Benutzergruppe Rechte für die Verwaltung anderer gegeben oder auch von NDPS-Druckerobjekten gegeben werden.
Auf gleicher Ebene steht die Security Equivalence. Mit dieser wird festgelegt, dass ein Objekt die gleichen Berechtigungen wie ein anderes Objekt besitzt. Damit kann beispielsweise konfiguriert werden, dass ein Benutzer die gleichen Rechte hat wie der standardmässig definierte Administrator Admin.
Diese Rechte vererben sich dann im NDS-Baum respektive im Dateisystem. Grundsätzlich gilt dabei, dass Berechtigungen durch den kompletten Baum fliessen. Das kann allerdings ab der NetWare 5 über ein Dialogfeld gesteuert und damit gegebenenfalls auch unterbunden werden. Um die Vererbung zu unterbrechen, können ansonsten Inherited Rights Filters (IRFs) eingesetzt werden. Diese sind allerdings unter dem Aspekt der Sicherheit nicht unproblematisch. Sie erlauben einerseits eine sehr differenzierte Steuerung der Vererbung. Andererseits müssen sie sehr gut geplant sein, um sicherzustellen, dass nachher wirklich jeder Benutzer genau die effektiven Rechte hat, die er benötigt. Ausserdem ist es prinzipiell möglich, dass durch eine fehlerhafte Konfiguration von IRFs Bereiche in der NDS oder im NetWare-Dateisystem entstehen, die nicht mehr administriert werden können, weil NetWare nicht durchsetzt, dass immer zumindest ein Administrator vollen Zugriff auf alle Systembereiche hat. Diese Konzepte gelten analog für Dateisystem und NDS.
Mit NetWare 5 hat Novell erstmals PKI-Dienste als Standardfunktionalität bei seinen Produkten eingeführt. Die Novell Certificate Services, die seit diesem Zeitpunkt noch einmal grundlegend überarbeitet worden sind, sind damit auch eine der wichtigsten Erweiterungen im Bereich der Sicherheit, die bei NetWare 5.x im Vergleich zu den 4.x-Versionen zu finden sind.
In engem Zusammenhang damit steht auch NICI (Novell International Crypthographic Infrastructure). NICI wurde zunächst primär deshalb als eigenständige Schicht entwickelt, um einerseits in Nordamerika mit 128-Bit-Verschlüsselung arbeiten zu können und andererseits den Exportbeschränkungen der USA nachkommen zu können. Mittlerweile sind diese Beschränkungen weitgehend aufgehoben worden. NICI spielt aber als Infrastrukturdienst, der Verschlüsselungsfunktionen anbietet, auch für Anwendungen, die solche Funktionen nutzen wollen, mittlerweile eine wichtige Rolle.
Darüber hinaus hat Novell mit den NMAS (Novell Modular Authentication Services) und Novell Single Sign-on auch zwei wichtige Add-ons im Bereich der Sicherheit auf den Markt gebracht.
So gut die Basis auch ist - Sicherheitsrisiken gibt es auch bei NetWare und NDS. Das grösste Problem ist dabei, wie eigentlich immer im Zusammenhang mit dem Thema Sicherheit, der Mensch. Allerdings sind für NetWare und NDS vergleichsweise wenig Sicherheitsprobleme publik geworden. Das hat seine Ursache einerseits sicherlich in den durchdachten Konzepten. Ein anderer Grund ist aber zweifelsohne auch die vergleichsweise geringe Verbreitung auf gegenüber dem Internet exponierten Servern. Die Angriffe gegen Windows-Systeme und zunehmend auch gegen Linux machen deutlich, dass auch eine gewisse kritische Masse erforderlich ist, bevor Sicherheitslücken in grösserem Umfang zutage treten.
Die Basis für sichere Server ist immer ein physischer Schutz. Diese Notwendigkeit ist bei NetWare-Servern besonders ausgeprägt, da das Betriebssystem über keine nennenswerten lokalen Sicherheitsmechanismen verfügt. Im Dateisystem ist die Basis für Sicherheit von der technischen Seite gegeben. Empfehlenswert ist, so weit wie möglich auf die Verwendung von IRFs zu verzichten. Wie oben ausgeführt, führen IRFs dazu, dass die Berechtigungsstrukturen in Systemen tendenziell unübersichtlich werden.
In den NDS gilt das Hauptaugenmerk dem Benutzerkonto Admin. Dieses sollte - ebenso wie Konten mit äquivalenten Rechten - nicht für die tägliche Administrationsarbeit eingesetzt werden. Hier gilt es, Operatorenmodelle zu entwickeln, bei denen Benutzer genau die Berechtigungen bekommen, die sie für das administrative Tagesgeschäft benötigen. Wichtig ist insbesondere, dass nur ausgewählte Benutzer volle administrative Berechtigungen erhalten und die Kennwörter der dafür verwendeten Benutzerkonten nach dem Weggang solcher Benutzer unbedingt geändert werden. Ein weiterer Schritt kann sein, das Objekt Admin in einen Container zu legen, in dem keine anderen Benutzer verwaltet werden.
Grundsätzlich sollten auch Benutzerkonten, die über einen längeren Zeitraum nicht verwendet werden, deaktiviert werden. Damit kann eine missbräuchliche Nutzung durch andere Anwender, die zufällig das Kennwort kennen, vermieden werden.
Um überhaupt zu erreichen, dass Benutzer mit einigermassen langen Kennwörtern arbeiten, kann - am sinnvollsten auf der Ebene von Containerobjekten - konfiguriert werden, welche Anforderungen an Kennwörter gestellt werden. Im Register Restrictions der Eigenschaften eines Containers lassen sich die Password Restrictions definieren und für die Kennwörter kann hier unter anderem die Mindestlänge festgelegt werden.
In engem Zusammenhang damit steht auch die Erkennung von Angriffsversuchen, die im Register General und dort unter Intruder Detection konfiguriert werden kann. Dort wird auch festgelegt, wie viele fehlerhafte Anmeldeversuche innerhalb eines definierten Zeitraums zulässig sind. Benutzerkonten, bei denen die definierten Bedingungen erfüllt sind, können dann auch automatisch deaktiviert werden. Wenn hier zu niedrige Werte gewählt werden, entsteht aber schnell ein unnötig hoher administrativer Aufwand, da sich dann auch immer wieder Benutzer aus Versehen "aussperren".
Ein Auditing der Zugriffe kann nur bei NetWare erfolgen. Es wird bei NDS-Versionen für andere Betriebssysteme derzeit nicht unterstützt. Allerdings ist auch Auditcon, das bei NetWare für diesen Zweck eingesetzte Werkzeug, nicht für seine einfache Bedienbarkeit berühmt. Dafür bieten eine Reihe von Drittherstellern wie beispielsweise BindView oder BlueLance spezialisierte Lösungen an, um solche Überwachungsprozesse durchzuführen.
Wenn es um das Thema Sicherheit geht, ist schliesslich auch noch ein Blick auf die schon weiter oben angesprochenen Zertifikatsdienste von NetWare interessant. Mit den Novell Certificate Services 2.0 hat Novell eine insgesamt recht leistungsfähige Basis für PKI-Dienste geschaffen. Es gibt allerdings auch noch einige funktionale Lücken. So wird bisher nur eine vergleichsweise geringe Zahl an Zertifikatstypen unterstützt. Darüber hinaus fehlt auch die Unterstützung für CRLs (Certificate Revocation Lists), mit denen ungültige Zertifikate bekannt gemacht werden. Dafür kann die Lösung durch ihren hohen Integrationsgrad mit den NDS glänzen.
Insgesamt stellt Novell ein sehr umfassendes Portfolio an Sicherheitsdiensten bereit. Zusammen mit der guten Basis, die NDS und NetWare ohnehin bieten, lassen sich damit sehr gut sichere IT-Infrastrukturen aufbauen. Wie sicher diese Umgebung letztlich ist, ist dann aber immer eine Frage der Administration. Denn hier können auch bei NDS und NetWare gravierende Fehler gemacht werden. Und die Konzepte, die Novell verwendet, sind hier nicht immer ganz einfach zu verstehen.