Semesterarbeit zur Vorlesung Betriebssysteme und Verteilte Systeme 2002 31. Juli 2002
Inhaltsverzeichnis 1 EINLEITUNG...3 2 GRUNDLAGEN VON NETZWERKDATEISYSTEMEN...4 2.1 Anforderungen und Eigenschaften... 4 2.2 Pufferverwaltung... 4 2.3 Zustand... 5 3 IT REALITÄT: GEMISCHTE UNIX- UND WINDOWS-UMGEBUNGEN...7 4 NFS UND CIFS...8 4.1 NFS... 8 4.1.1 Überblick... 8 4.2 CIFS...10 4.2.1 Überblick...10 4.3 Vergleich zwischen NFS und CIFS...11 4.3.1 Sicherheit...11 4.3.1.1 NFS Authentifizierung...11 4.3.1.2 CIFS Authentifizierung...12 4.3.2 Leistungsvergleich...14 4.3.2.1 NFS Caching...14 4.3.2.2 CIFS Caching...14 4.3.3 Namensauflösung...15 4.3.3.1 NFS Namensauflösung...15 4.3.3.2 CIFS Namensauflösung...15 4.4 Fazit...16 5 WEITERE NETZWERKDATEISYSTEME...17 5.1 AFS (Andrew File System)...17 5.1.1 Überblick...17 5.1.2 Volumes...17 5.1.3 Replikation...18 5.1.4 Caching...18 5.1.5 Sicherheit...19 5.1.6 Vergleich AFS mit NFS...19 5.2 Coda...21 5.3 DFS (Distributed File System)...21 2
1 Einleitung Netzwerkdateisysteme erlauben den transparenten Zugriff auf Ressourcen eines Dateiservers von einem entfernten Computer aus. Ziel ist es, vom Client auf Dateien des Servers zuzugreifen, als wären sie auf einem lokalen Dateisystem gespeichert. Dabei ergeben sich viele Probleme, die das Netzwerkdateisystem zu meistern hat. Z.B. Sicherheit, Geschwindigkeit, Fehlertoleranz, Cachekonsistenz, Namensauflösung und so weiter, um nur einige zu nennen. Im Folgenden werde ich auf einige Grundlagen von Netzwerkdateisystemen eingehen und einige mehr oder weniger bekannte Netzwerkdateisysteme vorstellen sowie ihre Vorund Nachteile miteinander vergleichen. 3
2 Grundlagen von Netzwerkdateisystemen 2.1 Anforderungen und Eigenschaften Dateisysteme dienen der Verwaltung permanent gespeicherter Daten. Eine Datei kann angesehen werden als ein logischer Behälter, in dem Daten in strukturierter (oder unstrukturierter) Form abgelegt sind. Sie kann ausserdem mit Typinformation versehen sein. Zur Verwaltung grosser Dateimengen gibt es so genannte Verzeichnisse (directories). Ein Netzwerkdateisystem erlaubt den Zugriff auf Dateien über Rechnergrenzen hinweg. Es beruht auf einer Dienstleistungsbeziehung (Client-Server-Struktur). Anforderungen Im Idealfall besitzt ein Netwerkdateisystem die folgenden Eigenschaften: - Zugriffstransparenz: Benutzer des Dateidienstes sollten nicht merken, dass sie auf ein entferntes System zugreifen. Der Zugriff soll sich nicht von lokalen Zugriffen unterscheiden, so dass Programme, die auf Dateien zugreifen, ohne Probleme auch mit entfernten Dateien arbeiten können. - Ortstransparenz: Den Benutzer soll die tatsächliche Lage der Datei nicht interessieren. Dateien können beliebig verlagert werden, ohne dass der Benutzer davon betroffen wird. - Nebenläufigkeitstransparenz: Simultane Zugriffe auf Dateien von verschiedenen Benutzern sollten keine Inkonsistenzen verursachen. - Fehlertransparenz: Es sollte sichergestellt sein, dass nach Ausfall eines Clients oder Servers der Dateibetrieb wieder korrekt weiterlaufen kann. - Leistungstransparenz: Verzögerungen infolge entfernten Zugriffs sollten so gering wie möglich und unabhängig von der aktuellen Last sein. 2.2 Pufferverwaltung Zur Leistungssteigerung wird in Dateisystemen das Pufferprinzip (Caching) verwendet. Im lokalen Fall bedeutet dies, dass Teile der Datei, die auf einem Plattenspeicher abgelegt ist, sich im Hauptspeicher befinden. Bei Netzwerkdateisystemen mit Client-Server-Struktur wird der Server ebenfalls grosse Teile des Hauptspeichers als Pufferplatz verwenden, um Festplattenzugriffe zu sparen. Bei entfernten Zugriffen sollten jedoch auch Datentransporte über das Netz minimiert werden. Dazu kann man auch auf Seite des Clients einen Cache einsetzen. Dieser Puffer kann auf der Festplatte oder im Hauptspeicher realisiert werden. 4
Cache-Konsistenz Bei Verwendung von clientseitigem Caching treten üblicherweise Konsistenzprobleme auf. Zur Reduktion der Netzbelastung werden folgende Massnahmen vorgeschlagen: - Write-Through: Der Puffer wird zum Lesen benutzt. Schreiboperationen werden sofort zum Server weitergegeben, d.h. auf das Original angewendet. - Verzögertes Schreiben: Schreiboperationen werden gesammelt und im Bündel an den Server weitergeleitet. - Write-on-Close: Dateiänderungen werden erst beim Schliessen der Datei an den Server weitergeleitet. 2.3 Zustand Bei lokalen Dateizugriffen wird beim Öffnen der Datei ein Dateiverwaltungsblock angelegt, in dem alle für die aktuelle Benutzung der Datei erforderlichen Daten verwaltet werden. Diese Daten kann man als den Status der Nutzung bezeichnen. Beim Schliessen der Datei wird er wieder gelöscht. Dadurch entsteht so etwas wie eine Sitzung oder Verbindung (Aufbau der Nutzungsbeziehung, die eigentliche Nutzung, sowie der Abbau der Nutzungsbeziehung). Bei Netzwerkdateisystemen mit Client-Server-Struktur wird nun danach unterschieden, ob der Server solche Statusinformationen führt oder nicht. Man spricht von zustandslosen und zustandsbehafteten Servern. Vorteile zustandsloser Server - Im Falle eines Server-Ausfalls geht die Statusinformation verloren. Ein zustandsloser Server ist darauf nicht angewiesen und kann nach Wiederanlauf sofort den Betrieb wiederaufnehmen. Auch ein Client-Ausfall bereitet keinen Aufwand - Open- und Close-Operationen entfallen und damit auch die dazugehörenden Nachrichten - Kein Speicherbedarf für Statusinformationen - Keine Beschränkung hinsichtlich der Zahl geöffneter Dateien 5
Vorteil zustandsbehafteter Server - Kürzere Auftragsnachrichten - Bessere Leistung - Idempotenz besser zu realisieren (Sequenznummer) - Möglichkeit, Sperren zu setzen Idempotenz bedeutet, dass eine Operation, auch wenn sie mehrmals nacheinander ausgeführt wird, zum gleichen Resultat führt, wie wenn sie nur einmalig ausgeführt wird. Beispielsweise kann eine Datei nur einmal gelöscht werden, auch wenn eine Anfrage vom Client mehrmals eintrifft. Die Aufgabe des Netzwerkdateisystems ist es, solche mehrmaligen Anfragen unter Kontrolle zu halten. 6
3 IT Realität: gemischte UNIX- und Windows-Umgebungen Ob Geschäft, Verwaltung oder Industrie, alle IT Abteilungen müssen sich für ein bestimmtes Betriebssystem entscheiden. Viele entscheiden sich für eine UNIX-Variante als Umgebung für ihre kritischen Applikationen. UNIX bietet die hohe Verfügbarkeit und Performance, welche für das Verwalten von grossen Datenbanken, das Bereitstellen von Informationen über das Internet und Intranet sowie für e-services-projekte gebraucht wird. Windows eher als weniger robust bekannt ist hingegen gut genug für den Einsatz im täglichen Gebrauch wie z.b. Textverarbeitung, Tabellenkalkulation, Grafikverarbeitung, Surfen, E-Mails lesen und vieles mehr. Windows wird ebenfalls häufig für Datei- und Druckdienste eingesetzt. Das einfach zu bedienende Windows wird fast überall gebraucht und ist auf der ganzen Welt in der einen oder anderen Form anzutreffen. Daraus resultiert, dass heute in sozusagen allen Unternehmen verschiedene UNIX- und Windows-Systeme zum Einsatz kommen. Es ist deshalb nötig, dass die beiden Systeme miteinander kommunizieren können. Benutzer wollen die Möglichkeit haben, ihre Windows- und UNIX-Systeme nahtlos zu verbinden, sie wollen Zugriff auf jede Datei, von jedem System und von irgendwoher haben. Die Lösung zum Bereitstellen dieser Kompatibilität ist ein Netzwerkdateisystem. Es stellt Dienste zur Verfügung, mit welchen die Benutzer transparent auf ihre Daten zugreifen können, unabhängig davon wo und auf welchem System diese gerade gespeichert sind. 7
4 NFS und CIFS Um ein Netzwerkdateisystem in einer Windows-UNIX Umgebung zu implementieren, hat man vor allem die Auswahl zwischen zwei weit verbreiteten Systemen: - NFS (Network File System): Das am weitesten verbreitete UNIX Netzwerkdateisystem - CIFS (Common Internet File System): Das am weitesten verbreitete Windows Netzwerkdateisystem, auch bekannt unter dem Namen SMB (Server Message Block). 4.1 NFS 4.1.1 Überblick 1984 kündigte SUN Microsystems das Network File System (NFS) an. NFS sollte ein Dateisystem werden, welches die Verbindung unterschiedlichster Rechner mit verschiedenen Betriebssystemen ermöglicht. 1985 wurde NFS auf einer Workstation von SUN vorgestellt. Die vorgestellte Version war aber schon bei Version 2 und enthielt neben NFS als Client/Server-Variante auch das Virtual File System (VFS) und Yellow Pages (YP) (später Network Information Service (NIS) genannt). Ungewöhnlicherweise veröffentlichte SUN die Spezifikation von NFS und stellte eine Referenzimplementierung auf UNIX zum lizenzpflichtigen Nutzen zur Verfügung. In dieser Zeit war es allgemein Üblich, dass eine Firma die Spezifikationen ihres Produktes geheim hielt, um ihre Kunden an ein System zu binden. Da jetzt aber jeder NFS in sein System einbinden konnte, wurde es in der UNIX-Welt zum de-facto-standard für den verteilten Dateizugriff. 1986 wurde von den Firmen The Instruction Set Ltd. und Lachman Associates, Inc. eine Portierung der Referenzimplementierung der NFS Version 2.0 nach System V Release 2 für eine DEC VAX durchgeführt. Diese Portierung war nötig, da Suns Referenzimplementierung auf 4.2BSD basierte, wovon auch SunOS abstammt. Durch die Portierung auf System V war die Möglichkeit geschaffen worden, NFS auf praktisch allen UNIX-Rechnern verfügbar zu machen. Im gleichen Jahr wurde von Sun mit der Version 3.0 eine neue Version von NFS ausgeliefert, die sich von ihrem Vorgänger vor allem durch ein verbessertes YP-Protokoll unterschied. Außerdem wurde von Sun in diesem Jahr die erste Implementierung auf NFS für PCs unter MS-DOS (PS-NFS) freigegeben. 1987 wurde Version 3 vorgestellt, die wichtigste Neuerung war die Möglichkeit, Dateien sperren zu lassen (File Locking), was von Anfang an von den Usern gefordert wurde. Ausserdem enthielt diese Version erstmals REX (Remote Execution), womit das ausführen von Programmen auf anderen Rechnern möglich wurde. Zusätzlich wurde auch die Unterstützung von Workstations ohne eigene Festplatte verbessert, um ihnen auch Zugriff auf Gerätedateien und Named Pipes zu ermöglichen. 8
NFSv4 ist die nächste Generation des Netzwerkdateisystems, das von Sun herausgegeben wird. Es beinhaltet starke Verschlüsselung sowie gute Performance auch mit langsamen Verbindungen dank grossen Cache-Speichern. NFSv4 befindet sich jedoch noch in Entwicklung. Da Yellow Pages in England verständlicherweise schon der Name für das Branchenbuch (Gelbe Seiten, im englischen Yellow Pages) ist, wurde YP aus rechtlichen Gründen umbenannt zu NIS (Network Information Service). NFS ist ein de-facto-standard, d.h. dass seine Implementierungen von Anbieter zu Anbieter leicht variieren können. Die Versionen ab 3 und 4 sind jedoch abwärtskompatibel zu älteren Versionen. Das NFS Client-Modul bietet ein API, das identisch ist zum API des lokalen Betriebssystems. Dieses virtuelle Dateisystem (Virtual File System (VFS)) bewirkt, dass der Zugriff auf Netzwerkressourcen transparent ist. Das NFS Protokoll basiert auf RPC (Remote Procedure Calls) über UDP oder TCP und ist zustandslos. Die meisten Operationen sind beliebig wiederholbar (idempotent, siehe Abschnitt 2.3). Da also keine permanente Verbindung zwischen Client und Server besteht, kann ein Client recht problemlos mit dem zwischenzeitlichen "Reboot" eines Servers umgehen. Diese recht effektive Fehlerbehandlung von NFS geht zu Lasten von Ausschliessungsmechanismen beim gleichzeitigen Zugriff mehrerer Benutzer auf dieselbe Datei. Hier zeigt sich NFS als sehr empfindlich, d.h. Dateien können bei einem konkurrierenden Zugriff leicht korrumpiert werden. Sowohl client- als auch serverseitig werden Cachingverfahren eingesetzt. Dadurch werden sehr gute Zugriffszeiten erreicht. Die Dateien auf dem NFS-Server werden zugänglich gemacht, indem sie zunächst exportiert werden. Die NFS-Clients greifen auf diese exportierten Dateisysteme oder Ausschnitte aus Dateisystemen zu, indem sie sie in das eigene Dateisystem einhängen. Dies wird "mounten" genannt. Die Bereitstellung der Zugriffsmöglichkeit erfolgt also nicht auf Veranlassung des zugreifenden Programms, sondern muss bereits vor dem Zeitpunkt des Zugriffs für lokale Systeme geschehen sein. Hierbei wird die Zugriffsmöglichkeit einem Client-Rechner gewährt und nicht einem Benutzer. Das Replizieren von Dateien wird von NFS nicht unterstützt. Aber man könnte einen NFS- Service implementieren, der dies unterstützen würde. Der Network Information Service (NIS) erlaubt z.b. die Replikation von einfachen Datenbanken. NFS bietet gute Performance in lokalen Netzen (LANs), für Weitstreckenverbindungen (WANs) wie Internet ist es jedoch weniger geeignet. 9
4.2 CIFS 4.2.1 Überblick Das Common Internet File System (CIFS) dient dem Fernzugriff von PCs unter einem Windows-Betriebssystem auf das Dateisystem eines anderen PCs unter Windows. Der zugrunde liegende Mechanismus ist seit den frühen achtziger Jahren besser unter dem Namen Server Message Block (SMB) bekannt. Erst die Öffnung dieses Standards unter dem Namen CIFS eröffnete diesem Konzept die Akzeptanz auf einer breiteren Basis. Seit 1996 fördert Microsoft die Verbreitung von CIFS aktiv durch offizielle Spezifikationen und Veröffentlichungen. Das CIFS stellt seine Daten Benutzern zur Verfügung, nicht Computern, wie dies z.b. bei NFS der Fall ist. Die Authentifikation des Benutzers wird dabei auf dem Server durchgeführt und nicht auf dem Client. Hierbei können auch spezielle netzwerkweite Authentifizierungs-Server wie z.b. Domänen-Controller oder Kerberos-Server eingesetzt werden. Der Zugriff auf die einzelnen Dateien wird dann durch Access Control Lists (ACL) kontrolliert. Ein CIFS-Server erlaubt einem Client den Zugriff über das Netzwerk auf seine lokalen Ressourcen, d.h. auf seine Netzwerkdateidienste. Diese so genannten "Shares" auf dem Server können von einem entfernten Benutzer an ihr lokales System angebunden werden. Hierbei werden keine Benutzer-IDs über das Netzwerk geschickt, sondern komplexe Anbindungssequenzen verwendet, die nur schwer angreifbar sind. Dies resultiert in einer erhöhten Sicherheit in Bezug auf den Benutzerzugriff. Weiterhin kann das CIFS sehr effektiv mit der Behandlung von gleichzeitigen Benutzerzugriffen auf Dateien umgehen. Dies wird insbesondere bei der relativ hohen Unempfindlichkeit eines NT-Systems bei konkurrierenden Zugriffen auf Systemdateien sichtbar. Jeder Server stellt dem Netzwerk eine eigenständige Dateistruktur zur Verfügung. In Bezug auf Speicher oder Dienste besteht keine Abhängigkeit zu anderen Servern. Eine Datei muss auf einem einzelnen Server vollkommen eigenständig vorhanden sein. Das Kernprotokoll für die Freigabe von Dateien erfordert die Server-Echtheitsbestätigung von Benutzern, bevor Dateizugriffe erlaubt werden. Jeder Server-Prozess bestätigt die Echtheit der eigenen Benutzer. Ein Benutzer muss sich immer an den Server anmelden, auf den er zugreifen möchte. Dieses Modell der Echtheitsbestätigung setzt voraus, dass autonome Systeme über das LAN miteinander verbunden sind, die einen Teil ihrer lokalen Dateien Benutzern im Netzwerk zur Verfügung stellen. CIFS ist ein Netzwerkdateisystem, das auf TCP/IP aufbaut. Es ist ein verbindungsorientiertes Protokoll, welches schnelle Verbindungen sowohl im LAN- als auch im WAN- Bereich bietet. Durch die Kopplung des Dateizugriffs an einen Benutzer reagiert das CIFS-Konzept jedoch recht empfindlich bei einem plötzlichen Verbindungsabbruch durch den Server. Dies fällt insbesondere beim Neustart eines Servers ins Gewicht, bei dem er die Informationen über Benutzer- und Gruppen-IDs von aktuell zugreifenden Benutzern verliert. Applikationen reagieren auf einen solchen Zustand zum Teil wie auf eine plötzlich ausgefallene lokale Festplatte. Oftmals genügt jedoch auch die erneute Authentifizierung des Benutzers für eine Weiterarbeit. 10
4.3 Vergleich zwischen NFS und CIFS 4.3.1 Sicherheit Ein sicheres Netzwerkdateisystem sorgt dafür, dass nur autorisierte Benutzer Informationen sehen und verändern können. Aber ein Sicherheitsproblem kann entstehen, sobald zwei verschiedenartige Betriebssysteme einander Zugriff auf ihre Ressourcen geben. Echte Sicherheit besteht nur dann, wenn der zugreifende Benutzer wirklich der Benutzer ist, als den er sich authentifiziert hat. Authentifizierung bedeutet, dass eine Benutzer-ID und Passwort in einer Datenbank, die vom Systemadministrator gewartet wird, auf Gültigkeit hin überprüft werden. In einer Umgebung, wo sowohl UNIX also auch Windows existieren, muss es eine Möglichkeit geben, Benutzer auf beiden Systemen zu identifizieren. Oft aber ist die UNIX- Windows-Authentifizierung aufgeteilt, da UNIX und Windows verschiedene Netzwerkauthentifizierungsmechanismen verwenden. Bei UNIX kommt meistens der Network Information Service (NIS) für Benutzeridentifikation zum Einsatz, während die Authentifizierung unter Windows über den NT LAN Manager (NTLM) läuft. Seit Windows 2000 wird auch noch Kerberos Authentifizierung unterstützt. Da Windows und UNIX verschiedene Authentifizierungsschemen verwenden, muss der Systemadministrator die Benutzer-IDs und Passwörter zweimal verwalten, einmal für jedes System. Der Unterhalt zweier verschiedener Authentifizierungsmechanismen für UNIX und Windows ist aufwändig und mit Kosten verbunden, und IT Unternehmen würden es bevorzugen, nur eine einzige Methode für beide Systeme zu haben. 4.3.1.1 NFS Authentifizierung Bei der einfachsten NFS-Implementierung wird nur eine UNIX User-ID (UID), ohne Überprüfung als Berechtigungsnachweis verlangt, um Zugriff auf das Dateisystem zu erhalten. Dieser Sicherheitsmangel erlaubt einem Eindringling auf einfache Weise, sich Zugang zum Filesystem zu verschaffen, z.b. durch Verwenden einer gültigen UID innerhalb eines NFS RPC (Remote Procedure Call). Es ist auch möglich, Zugriffsberechtigungen durch Abfragen der IP-Adresse zu regeln, dies ist aber insbesondere unsicher, da eine Arbeitsstation mit fixer IP-Adresse leicht z.b. durch einen Laptop ersetzt werden kann. Neuere NFS Versionen (Secure NFS, Kerberized NFS) beinhalten zwar sichere Authentifizierungsverfahren wie Kerberos oder Diffie-Hellman Public Key Exchange, diese werden jedoch selten angewendet. Dabei erfolgt die Authentifizierung nur beim Mount-Vorgang, da das Einfügen der Authentifizierungsdaten in jeden Request zu aufwändig wäre. User-ID und Client-Adresse werden in den Mount-Informationen beim Server gespeichert und bei jeder Zugriffsoperation überprüft. Dieses Verfahren ist ausreichend unter der Annahme, dass sich nur ein Benutzer auf einem Client einloggen kann. 11
4.3.1.2 CIFS Authentifizierung Im Gegensatz zu NFS, wo die Daten zum Client System übertragen werden und dann die Authentifizierung auf dem Client stattfindet, wird bei CIFS die Identifizierung des Benutzers durch einen Server vorgenommen. In einer NT Domänen Umgebung werden Authentifizierungsanfragen von dedizierten Servern vorgenommen, den Domänencontrollern. Pro Domäne muss mindestens ein aus Redundanzgründen jedoch meistens mehrere Domänencontroller vorhanden sein. Diese beherbergen eine Datenbank mit den Userinformationen (Security Account Manager (SAM)). Änderungen an dieser Datenbank werden auf alle Domänencontroller der Domäne repliziert. Domänencontroller sind eine Microsoft-spezifische Implementation der Spezifikationen über Key Management Server im CIFS-Standard. Es bestehen verschiedene Authentifizierungsmechanismen: - Schutz auf Freigabeebene - Unverschlüsselte Passwortübergabe - LanMan 1.2 Challenge/Response - NTLM 0.12 Challenge/Response - Kerberos V5 Wenn ein Client Ressourcen von einem Server anfordert, verhandeln die beiden zuerst über den zu verwendenden Authentifizierungsmechanismus. Es wird immer der höchst mögliche Mechanismus gewählt, um die grösste Sicherheit zu gewährleisten. Schutz auf Freigabeebene Bei diesem Verfahren gibt es keine Benutzerabhängigen Passwörter. Jede Freigabe (Share) hat ein zugewiesenes Passwort. Alle User, die darauf zugreifen wollen, müssen dieses Passwort kennen. Das Passwort wird unverschlüsselt zum Server übermittelt. Unverschlüsselte Passwortübergabe Dabei wird das zum Benutzer gehörende Passwort in unverschlüsselter Weise übertragen. Dieses Verfahren ist nicht sehr sicher, da das unverschlüsselte Passwort leicht abgehört werden kann. Seit Windows NT4 Service Pack 3 wird diese Methode nicht mehr unterstützt. LanMan 1.2 Challenge and Response Dies ist die erste Variante mit verschlüsselten Passwörtern. Die CIFS Spezifikation empfiehlt, dass diese Variante nur noch zu Zwecken der Abwärtskompatibilität eingesetzt wird und schlägt vor, nur noch NTLM 0.12 (siehe unten) als Authentifizierungsverfahren zu 12
verwenden. Es ist zu bemerken, dass der hier verwendete Verschlüsselungsalgorithmus nicht derselbe ist wie bei UNIX. Der Benutzername und das Passwort werden zwar nie unverschlüsselt über das Netzwerk übertragen, jedoch wird die erste Serveranfrage unverschlüsselt getätigt. Dadurch ist das System anfällig gegenüber Brute-Force-Attacken. Da die Passwortüberprüfung bei diesem Verfahren auch nicht zwischen Gross- und Kleinschrift unterscheidet, verkleinert sich die Zahl der möglichen Kombinationen, was die Chancen für einen erfolgreichen Angriff natürlich erhöht. NTLM 0.12 Challenge and Response Dies ist die empfohlene Authentifizierungsmethode für CIFS Clients mit Windows NT4. Es erlaubt Passwörter in Gross-/Kleinschrift und verwendet den MD4 Verschlüsselungsalgorithmus, was eine viel höhere Sicherheit bietet. Kerberos Version 5 Das Kerberos V5 Authentifizierungsprotokoll ist der Standard bei Windows 2000, das mit Active Directory konfiguriert ist. Dieses Protokoll ist flexibler, effizienter und sicherer als NTLM. Das Kerberos-Protokoll wurde am Massachusetts Institute of Technology (MIT) entwickelt und von der Internet Engineering Task Force (IETF) als offener Standard spezifiziert. Kerberos arbeitet mit verschlüsselten "Tickets". Nach der Authentifizierung bei einem Kerberos-Server erhält der Client einen "Fahrschein", der als eine Art Ausweis gegenüber den Diensten im Netzwerk fungiert, die der Client benutzen darf. Die Microsoft-Implementierung greift dabei auf ein Datenfeld innerhalb der Tickets zurück, das in der Kerberos-Spezifikation zwar enthalten ist, bislang jedoch nicht verwendet wurde. Der Inhalt dieses Feldes regelt den Zugriff auf Windows-Ressourcen im Netz. Da Microsoft seine Verwendung nicht offen gelegt hat, sind zurzeit lediglich Windows 2000- Server in der Lage, diese Information zu liefern. Stammt der Kerberos-Server nicht von Microsoft, fehlt den Tickets eine Angabe, die die Clients zum Zugriff auf Ressourcen benötigen. Betroffen davon sind nicht nur Kerberos- Server auf anderen Betriebssystemen, auch die Integration des unter UNIX und Linux bekannten freien Dateiservers Samba in eine Active-Directory-Struktur wird so erschwert. Dies bedeutet, dass die Authentifizierung eigentlich nur mit Windows 2000-Servern richtig funktioniert. Damit versucht Microsoft, einen de-facto-standard durchzusetzen. Das Vorgehen ist zwar nicht illegal, aber auch nicht im Sinne eines offenen Standards, wo man alle Details offen darlegt. 13
4.3.2 Leistungsvergleich Leistung ist neben Sicherheit ein weiterer wichtiger Punkt bei der Auswahl eines Netwerkdateisystems. Eine der besten Möglichkeiten, die Leistung zu verbessern, erfolgt mittels Caching. Clientseitiges Caching verbessert den Datendurchsatz eines Netzwerkdateisystems, indem es den Server entlastet und den Netzwerkverkehr vermindert. Wichtig dabei ist, dass die Dateien auf dem Server sowie im Cache des Clients konsistent sein müssen, d.h. Änderungen an den Dateien sollten so rasch als möglich allen betroffenen Clients mitgeteilt werden. 4.3.2.1 NFS Caching Das NFS Client-Modul hat einen Cache für Lese- und Schreiboperationen. Das Hauptproblem beim Caching ist, dass eine Kopie einer Datei im Cache veraltet sein kann, weil z.b. ein anderer Client die Datei verändert hat. Zur Lösung dieses Problems nutzt NFS das Timestamp-Verfahren. Die gepufferte Datei beinhaltet einen Zeitstempel, der anzeigt wann die Datei auf dem Server das letzte Mal verändert wurde. Jedes Mal wenn ein Client einen neuen Block vom Server anfordert, wird zugleich noch der Zeitstempel überprüft. Wenn eine Datei Clientseitig verändert wird, wird die Datei im Cache als "dirty" markiert und danach auf den Server übertragen. Da NFS-Clients nicht wissen, ob gleichzeitig mehrere Benutzer auf eine Datei zugreifen oder nicht, muss das Timestamp- Verfahren immer angewendet werden. 4.3.2.2 CIFS Caching CIFS Caching verwendet beim Lesen Read-Ahead-Caching. Dies erlaubt es einem Client, eine Datei nur einmal über das Netzwerk lesen zu müssen, auch wenn mehrere Zugriffe darauf stattfinden. Dies funktioniert nur solange gut, wie die Datei auf dem Server nicht verändert wird. Wird sie nämlich verändert, hat der Client eine veraltete Kopie in seinem Cache und es treten Inkonsistenzen auf. Bei Schreiboperationen kommt Write-Behind-Caching zum Einsatz. Dabei wird eine veränderte Datei nicht sofort zum Server übertragen, sondern erst später im Bündel mit anderen Dateien gesendet. Dieses Verfahren ist ebenfalls nur sicher, solange kein anderer Client auf die Datei zugreifen will. Die Caching-Verfahren sind im CIFS-Modul des Clients implementiert und unterliegen seiner Kontrolle. Es ist also ihm überlassen, wann er eine Datei puffern will und wann er Serveranfragen tätigt. Im CIFS Protokoll ist jedoch ein Kommunikationsmechanismus eingebaut, der es dem Server erlaubt den Clients mitzuteilen, wie viele Zugriffe gleichzeitig auf eine Datei stattfinden und ob es sich um lesende oder schreibende Zugriffe handelt. Mit diesen Informationen kann der Client entscheiden, ob er Caching benutzen will oder nicht. Nur wenn die Art der Zugriffe keine Probleme bereiten, wird Caching eingesetzt. 14
4.3.3 Namensauflösung 4.3.3.1 NFS Namensauflösung Da NFS intern mit RPC Funktionen arbeitet, wird zum Auflösen des Servernamens der normale DNS Dienst beansprucht. Dies geschieht normalerweise beim Mounten eines Verzeichnisbaumes. Anstelle des FQDN (Fully Qualified Domain Name) kann selbstverständlich auch eine IP-Adresse angegeben werden, dann entfällt die Namensauflösung via DNS. Zum Auflösen bzw. Navigieren innerhalb der Struktur des gemounteten Verzeichnisses wird der Befehl LOOKUP verwendet. Da solche LOOKUPs ziemlich oft vorkommen und relativ ineffizient sind, wird hier ein Namenscache eingesetzt. 4.3.3.2 CIFS Namensauflösung Die Auflösung von Namen kann auf zwei Arten erfolgen: "broadcast" oder "point-topoint". Ein Rechner kann eine oder beide dieser Methoden nutzen. Bei der Broadcast- Methode "ruft" ein Rechner, der einen Service sucht, ins Netz und wartet auf eine Antwort. Dies kann einigen Traffic verursachen, ist aber in einem kleinen Netz kein echtes Problem. Die zweite Methode benutzt einen NBNS (NetBIOS Name Service)-Server. Unter Windows ist dies als WINS (Windows Internet Name Service) bekannt. Dieser funktioniert wie folgt: Jeder Client sendet seinen NetBIOS-Namen und die IP-Adresse an den NBNS-Server, der die Informationen in einer Datenbank speichert. Wenn ein Client mit einem anderen Client kommunizieren möchte, sendet er den Namen des gewünschten Rechners an den NBNS-Server und dieser liefert die entsprechende IP-Adresse zurück. Clients in verschiedenen Subnetzen können einen gemeinsamen NBNS-Server benutzen. Somit ist die Broadcast-Methode nicht auf lokale Netze beschränkt. NBNS lässt sich in etwa mit dem DNS vergleichen, die Namensliste von NBNS ist allerdings komplett dynamisch und es gibt kaum Überprüfungen, ob ein Client zur Namesregistrierung autorisiert ist. Dies kann sehr schnell zu Konflikten führen. Zudem gibt es bei CIFS noch das "Browsing". Damit wird eine Liste der verfügbaren Laufwerke und Drucker zur Verfügung gestellt. In einem LAN gibt es zwischen allen Rechnern eine Abstimmung (Election) und der dominierende Rechner wird zum LMB (Local Master Browser) erklärt. Dieser LMB bekommt einen zusätzlichen Namen, seine Aufgabe ist es, eine Liste der verfügbaren Dienste zu unterhalten. Diese Liste erscheint beim Anklicken des Symbols "Netzwerk Umgebung". Als Ergänzung zu den LMBs gibt es noch DMBs (Domain Master Browsers). Diese koordinieren die Listen zwischen NT-Domänen und gerouteten Netzwerken. Über den NBNS kann ein LMB seinen DMB herausfinden und die Listen austauschen und ergänzen. Somit können die Listen an alle Teilnehmer in einer NT Domain verteilt werden. Leider dauert es bis zu einer Stunde, bis eine Änderung in einem Subnetz im Netz verbreitet ist. 15
Seit Windows 2000 mit Active Directory wird auch der bekannte DNS Dienst zur Namensauflösung verwendet, wodurch sich sehr viel vereinfacht und vor allem auch der Weg ins Internet geöffnet wird. WINS Server werden dann nur noch zur Einbindung von älteren Windows NT4/95/98-Geräten verwendet. 4.4 Fazit In vielen Unternehmen kommt Windows auf den Workstations zum Einsatz, und UNIX ist häufig im Serverbereich anzutreffen. Da in jedem Windows-Betriebssystem das Modul für CIFS bereits integriert ist, nicht jedoch das für NFS (das übrigens von einem Drittanbieter gekauft werden müsste), ist es nahe liegend, dass man die (meist wenigen) UNIX-Server mit CIFS ausrüstet, anstatt umgekehrt alle Windowsrechner mit NFS. Für UNIX und Linux ist z.b. der kostenlose Dateiserverdienst Samba erhältlich, mit welchem die UNIX-Ressourcen der Windows-Welt zugänglich gemacht werden können. Dieser kann sogar so konfiguriert werden, dass die Authentifizierung von einem Windows Domänencontroller vorgenommen wird. Somit entfällt das für Administratoren aufwändige Verwalten zweier Account-Datenbanken auf beiden Systemen. Der Haken dabei: die Benutzerkonten auf UNIX müssen trotzdem existieren, um eine Zuweisung von UNIX- Konten zu Windows-Konten zu ermöglichen. Dies geschieht aber nur einmalig und verlangt später keine Wartung mehr. Weiterhin bietet CIFS im Bereich der Sicherheit mehr Vorteile als NFS. 16
5 Weitere Netzwerkdateisysteme 5.1 AFS (Andrew File System) 5.1.1 Überblick Das Andrew File System wurde ursprünglich an der Carnegie-Mellon University (CMU) als gemeinsames Projekt mit IBM an dem hierzu gegründeten Information Technology Center der CMU entwickelt. Diese Entwicklung begann 1983 mit dem Ziel, den Mitgliedern der Universität durch grosszügige Bereitstellung von vielen Workstations und die Entwicklung dazugehöriger Software-Werkzeuge eine Arbeitsumgebung zur Verfügung zu stellen, von der man sich eine erhöhte Produktivität versprach. Dies war das Projekt Andrew, und AFS war die File-System-Komponente davon. Seit 1989 wird AFS von der Transarc Corporation in Pittsburgh weiterentwickelt und vertrieben. Die AFS-Verzeichnisstruktur wird über Links ins UNIX-System integriert. Jedes lokale Dateisystem bildet eine AFS-Zelle, die weltweit mit anderen Zellen zum globalen AFS- System kombiniert wird. Der Eigentümer eines Verzeichnisses definiert in einer Access- Control-List (ACL) die Zugriffsrechte für dessen Dateien. Nach erfolgreicher Anmeldung bei AFS erhält der Nutzer ein Token mit beschränkter Gültigkeitsdauer und kann dann die gewohnten UNIX-Befehle wie cd, ls oder cp innerhalb des gesamten Systems benutzen. Die Zelle ist die verwaltungsmässige Einheit von AFS, z.b. eine Universität, eine Firma oder eine Behörde. Zentral, nämlich von Transarc Corporation, wird nur die Einrichtung von Zellen verwaltet. Die Namen der Zellen folgen vereinbarungsgemäss den Konventionen des Internet Domain Systems. AFS ist ein verteiltes Filesystem, d.h. die in AFS enthaltenen Files sind über die Peripherie mehrerer Rechner, der so genannten Fileserver verteilt. Der Benutzer muss im Gegensatz etwa zu NFS eigentlich nicht wissen, auf welchem Fileserver die von ihm benutzten Files liegen. AFS ist bezüglich des Ortes der Daten transparent. Der Administrator hat sogar die Möglichkeit, Dateien während des Betriebes von einem Fileserver auf einen anderen zu verlagern. Der Benutzer merkt dies allenfalls an einer zeitlichen Verzögerung bei einem Zugriff während der Verlagerung. Skalierbarkeit ist eines der Hauptziele von AFS. Die Strategie dahinter ist, dass Dateien immer komplett übertragen und gepuffert werden. Nachdem eine Datei zum Client übertragen worden ist, finden alle Zugriffe nur noch lokal statt. Nach dem Modifizieren wird die ganze Datei wieder zurück zum Server geschickt. 5.1.2 Volumes Die Gesamtheit der AFS-Files wird unter AFS in Volumes eingeteilt. Ein Volume ist durch seinen Namen und den Mount-Point, unter dem seine Files im AFS-Dateibaum zu finden sind, charakterisiert. Typischerweise bildet etwa das Home Directory eines Benutzers ein Volume, oder alle Files eines Programmpaketes. 17
Das Volume ist ein organisatorischer Begriff, der Benutzer braucht den Namen eines Volumes nicht zu kennen, um dessen Files zu benutzen. Zwischen dem Namen eines Volumes und dem Pfadnamen seines Mount-Points besteht kein zwingender Zusammenhang. 5.1.3 Replikation Von Volumes (meistens von solchen, deren Files selten geändert, aber häufig gelesen werden, also etwa von Programmbibliotheken, aber nicht von Home Directories der Benutzer) können mehrere Kopien existieren, die dann auf unterschiedliche Platten und am besten auf verschiedenen Fileservern verteilt werden. Eine dieser Kopien ist das Original, die so genannte RW-Kopie (read-write), die anderen sind RO-Kopien (read-only). Lesende Clients greifen auf eine der RO-Kopien zu. Auf welche, entscheidet für jeden Client eine Präferenzliste. Dieses Verfahren der Replikation bietet eine gewisse Sicherheit gegenüber Ausfällen von Fileservern. Ausserdem entlastet es den Dateiserver, der die RW- Kopie enthält, sowie eventuell das Netz, wenn die RO-Kopie weniger weit entfernt liegt als die Originaldatei. 5.1.4 Caching Ein weiteres Verfahren von AFS zur Entlastung des Netzes und der Fileserver ist das Caching. Beim ersten Zugriff auf ein File wird dieses ganz zum Client übertragen und dort eine lokale Kopie angelegt. Wird die Datei geändert, so geschieht die Änderung nur an dieser Kopie, und erst beim Schliessen der Datei wird die Kopie an den Fileserver zurückgeschickt. Aber auch nach jedem Schliessen bleibt das File im Puffer, so dass bei wiederholter Benutzung kein erneutes Kopieren erforderlich ist. Der Fileserver besitzt Informationen über alle Cache-Kopien und benachrichtigt betroffene Clients im Falle einer Änderung des Files, d.h. davon, dass ihre Kopie nicht mehr gültig ist (Call-Back-Mechanismus). Bei weiterer Benutzung des Files müssen sich die betreffenden Clients eine neue Kopie holen. Das ganze Verfahren ist transparent für den Benutzer. Ihm ist es nicht einmal möglich herauszufinden, ob eine Datei gepuffert wird oder nicht. Wegen der zentralen Bedeutung des Caching trägt die AFS-Komponente, welche für alle Anforderungen auf dem Client verantwortlich ist, die Bezeichnung Cache Manager. Ein Problem dieses Caching-Verfahrens ist, dass die Pufferung auf der lokalen Festplatte des Clients durchaus eine beachtliche Grösse erreichen kann. 18
5.1.5 Sicherheit Da auf AFS viele Benutzer über das Netz Zugang haben, werden zwei Techniken des Datenschutzes benutzt: Authentifizierung und Access Control Lists (ACL). AFS benutzt zwei verwandte Methoden, um sicherzustellen, dass nur autorisierte Benutzer Zugang zum System haben: einfache Authentifizierung durch Passwörter und gegenseitige Authentifizierung ("mutual authentification"). Beide Methoden erfordern, dass ein Benutzer dem System seine Identität nachweist. Die erste Art der Authentifizierung ist der Gebrauch von Passwörtern, um Zugang zu AFS zu erhalten. Die Authentifizierung besteht darin, dass AFS nachprüft, ob der Benutzer das richtige Passwort angegeben hat. Wenn der Benutzer das richtige Passwort eingegeben hat, erhält der Cache Manager ein Token als Beweis dafür, dass er ein gültiger Benutzer ist. Ein Token ist ein Paket mit Information, das durch ein Authentifizierungsprogramm verschlüsselt worden ist, indem es das Passwort als Schlüssel benutzt hat. Der Cache Manager kann das Token entschlüsseln, da er das Passwort des Benutzers und die Verschlüsselungsmethode von AFS kennt. Wenn der Cache Manager das Token erfolgreich entschlüsseln und seine Information verwenden kann, ist der Benutzer authentifiziert als ein autorisierter AFS-Benutzer. Das Token ist für die AFS-File-Server der Beweis dafür, dass sich der Benutzer authentifiziert hat und das AFS-Filesystem benutzen darf. Dies dient als Grundlage für die zweite Methode, mit deren Hilfe AFS Datenschutz gewährleistet, die gegenseitige Authentifizierung. Damit beweisen sich zwei Partner, die über das Netz miteinander kommunizieren, gegenseitig ihre Authentifizierung. AFS fordert gegenseitige Authentifizierung, wann immer ein Server und ein Client (meistens der Cache Manager) miteinander kommunizieren. Auch hier wird, wie schon bei Kerberized NFS und CIFS, das Kerberosverschlüsselungsverfahren angewendet. Als Option können bei AFS die zu übertragenden Daten auch noch verschlüsselt werden, allerdings wird dies nicht von allen Clients unterstützt. Obwohl einige Sicherheitslücken im Bereich des lokalen Caches bekannt sind, kann AFS als sicheres Dateisystem eingestuft werden. 5.1.6 Vergleich AFS mit NFS NFS fehlt es vor allem an der Skalierbarkeit und den Leistungsmerkmalen, wie sie bei AFS zu finden sind. Auch gibt es unter NFS keinen gemeinsamen globalen Namensraum. Die folgende Tabelle zeigt die Unterschiede zwischen den beiden System auf: 19
AFS Dateiserver und Clients bilden eine logische administrative Einheit, Zelle genannt. Mehrere Dateien werden zu Volumes zusammengefasst und verwaltet. Architektur NFS Dateiserver und Clients. Jeder Server wird unabhängig verwaltet. Administration erfolgt auf Ebene der einzelnen Dateien. Gemeinsamer globaler Namensraum, der für alle Geräte sichtbar ist. Automatische Nachverfolgung von Dateien durch Volume Location Database. Namensraum ist nicht immer für alle Geräte gleich. Mountpoints der Verzeichnisse müssen vom Benutzer oder Administrator gesetzt werden. Zustandsbehaftet Robustes Festplatten-Caching reduziert die Serverund Netzwerkbelastung. Zustandslos Performance Hauptspeicher-Caching mit kleinen Puffergrössen. Durch Server-Call-Back garantierte Cache- Konsistenz. Attribute werden mehrere Stunden gepuffert. Netzwerkverkehr durch Call-Back-Mechanismus verringert, Verwendung grosser Puffer. Dateireplikate verteilen die Last auf mehrere Server. Hervorragende Leistungswerte in WANs (Weitstreckennetze wie z.b. Internet). Skalierbar. Die Leistung bleibt auch bei beliebig grossen Installationen gleich. Zeitbasierte Cache-Konsistenz, kann zu Inkonsistenzen führen. Attribute werden nur wenige Sekunden gepuffert. Netzwerkverkehr wird durch begrenzte Puffergrössen erhöht. Replikation wird nicht unterstützt. Ineffizient für WANs. Beste Ergebnisse im LAN- Bereich. Gut für kleine bis mittelgrosse Installationen. Verfügbarkeit Read-Only Replikationen von Volumes. Automatisches Umschalten zu verfügbaren Replikas. Standardmässig keine Replikation. Bei Serverausfall bleibt der Zugriff auf die Dateien erhalten. Verwaltungsaufgaben können von jedem Gerät aus getätigt werden. Disk Quotas (Mengenbeschränkungen) werden pro Volume vergeben. Übersichtlich für den Benutzer. Verwaltung Der Zugriff auf Dateien geht mit dem Abbruch der Verbindung verloren. Für Verwaltungszwecke wird meistens eine Telnetverbindung zu einem Server benötigt. Disk Quotas basieren auf der User-ID. Schwieriger zum Abfragen für den Benutzer. Keine Systemausfallzeit mit dem AFS Backup System. Wiederherstellung von Backups dank speziellem Verfahren durch Benutzer selbst möglich. Standard UNIX Backup geht nicht ohne Systemunterbrüche. Wiederherstellung kann nur von Administrator gemacht werden. 20
Sicherheit Kerberos Authentifizierung. Access Control Lists (ACL) für Zugriffsregelung auf Dateiebene. Gruppen können vom Benutzer erstellt werden. Gegenseitige Authentifizierung von Systemprozessen und Datenbanken. Verwendet wird immer Secure RPC. Unverschlüsselte User-IDs, vertrauenswürdige Benutzer und Geräte. Teils auch mit Kerberos- Verschlüsselung möglich. Zugriffsregelung im Standard-UNIX Stil. Gruppen können nur vom Administrator erstellt werden. Secure RPC kann verwendet werden, muss aber nicht. 5.2 Coda Eine Weiterentwicklung von AFS in den Punkten mobiles Rechnen, Server Replication und Disconnected Operation stellt das System Coda dar. Es wurde wie AFS an der Carnegie- Mellon University entwickelt und ist lediglich für die Betriebssysteme Linux, NetBSD, FreeBSD und Windows95 implementiert worden. Der Quelltext ist frei verfügbar. Coda enthält Strategien zur Konsistenzerhaltung der Daten bei den Clients und ermöglicht auch bei unterbrochener Verbindung eine Arbeit an den Dateien des Servers, z.b. bei nur zeitweise oder an verschiedenen Punkten angeschlossenen Laptops. Bei Wiederherstellung der Verbindung werden automatisch Updates der bearbeiteten Dateien durchgeführt. Bei der Reintegration entstehende Fehler oder Konflikte erkennt das System und löst sie auf. Es können Prioritäten für Dateien vergeben werden, um Files mit hoher Priorität bevorzugt im Cache zu halten. Coda ist skalierbar, benutzt Kerberos und hat etwa ein Viertel der Performance gegenüber einem lokalen Dateisystem. Dadurch, dass Coda nicht für alle Plattformen erhältlich ist, ist es in der Anwendung stark limitiert. 5.3 DFS (Distributed File System) DFS, das verteilte Dateisystem, führt im Netzwerk einen einheitlichen, logischen Namensraum ein. Hierarchisch strukturiert, bietet dieser den Benutzern einen wesentlich klareren, durchschaubareren Zugriff auf einzelne Freigaben. Dabei schirmt DFS die wirkliche Struktur vor dem Benutzer ab, der stattdessen klar nach Aufgaben oder Bereichen angeordnete Freigaben sieht unabhängig davon, auf welchen physikalischen Servern sich diese tatsächlich befinden. Selbst Änderungen an der tatsächlichen physikalischen Struktur von Ordnern führen nicht zu Fehlern dank der logischen Abstrahierung von DFS bleiben Ordner für Benutzer und Applikationen erhalten, so dass Zugriffe unverändert funktionie- 21
ren. DFS ist verfügbar für Windows 2000, sowie generell für Server, die mit den Protokollen CIFS (Windows NT), NCP (Netware) oder NFS (UNIX-Derivate) arbeiten, was eine hohe Flexibilität ermöglicht. DFS ist zunächst einmal aufgebaut wie AFS, allerdings teilweise mit neuen Bezeichnungen für bekannte Features. So heissen z.b. die Volumes jetzt Filesets. Es gibt aber auch Neuerungen, die über die Möglichkeiten von AFS hinausgehen. Vielleicht der bedeutendste Unterschied ist, dass DFS voll dem POSIX-Standard entspricht, also z.b. auch das Locken einzelner Byte-Bereiche möglich ist, so wie man es von einem lokalen UNIX-Filesystem kennt. Im Gegensatz zu AFS haben auch alle neun Mode-Bits wieder ihre Bedeutung, und ein chmod ändert auch die dazugehörige ACL (und umgekehrt). Allerdings reichen natürlich die drei Group-Bits nicht aus, um all das zu enthalten, was in den ACLs gesetzt werden kann, und das macht die Sache wieder etwas undurchsichtig. Vor allem aber kann man ACLs auf Files setzen, und nicht nur auf Directories. Eine sehr interessante neue Funktionalität im DFS ist die, dass man normale UNIX- Filesysteme ins DFS exportieren kann. Dies ist vergleichbar mit dem, was man bei NFS macht, aber mit DFS Technologie, aber mit besserer Cache-Unterstützung und Kerberos- Verschlüsselung. 22