CIFS (Common Internet File System) ist die verbesserte, erweiterte Version von SMB (= Server Message Block). Dieses Protokoll dient dem File- und Printersharing sowie dem Netzwerk-Browsing.
CIFS bietet Dienste wie File öffnen, File schliessen, File schreiben, File löschen und File umbenennen. Der Client kann mit diesen Diensten Files auf dem entfernten Server manipulieren als wären sie lokal auf seiner Festplatte gespeichert.
CIFS ist im OSI-Modell auf der Präsentations/Applikationsschicht gelagert und stützt sich auf die Protokolle der unteren Schichten. Meistens ist dies NetBios over TCP (NBT). Dieses Protokoll wird später erläutert.
Wie arbeitet CIFS:
Der Client sendet CIFS-Pakete an den Server, wobei jedes Paket in der Regel eine Anfrage irgendeiner Art (Öffnen/Schliessen/Schreiben/Umbenennen/Löschen) beinhaltet. Der Server interpretiert das Paket, überprüft den Inhalt auf Legalität und Korrektheit, und führt eine Authentifizierung durch, dh, er prüft, ob der Client zugriffsberechtigt ist,sowohl auf die Datei als auch generell auf das Dateisystem (File permissions). Ist des Clients Anfrage in Ordnung, führt der Server die Operation durch und sendet ein Bestätigungspaket an den Client. Der Client interpretiert dieses Paket und kann daraus erkennen, ob seine Anfrage an den Server erfolgreich gewesen ist, oder ob ein Fehler passiert ist.
CIFS ist in der Lage andere Server im Netzwerk zu lokalisieren. Dies nennt man Netzwerk-Browsing. Ausserdem beherrscht CIFS Printer-Sharing und Authentifizierungstechniken. Im Folgenden wird hauptsächlich auf die File-Sharing Methoden von CIFS eingegangen.
Welche Betriebssysteme implementieren CIFS:
Das CIFS-Protokoll wird von allen Microsoft-Betriebssystemen implementiert und verwendet, welche es in Form von Client/Server-Diensten anbieten. Das CIFS-Protokoll wird von AppleMacIntosh Rechnern sowie von Unix-Derivaten (Linux,FreeBSD) ebenfalls unterstützt.
NETBIOS/WINS over TCP:
Netbios ist ein Protokoll, das über viele TransportLayer-Protokolle transportiert werden kann, hauptsächlich über TCP/IP. NetBios Transportiert die meisten CIFS-Protokoll-Pakete. Die genauen Spezifikationen sind in RFC1001/RFC1002 zu lesen.
NetBIOS ist auch eine Anwenderschnittstelle, die Progammierern eine API zum Zugriff auf niedrigere Dienste in einem LAN (File öffnen, schreiben, umbenennen, etc...). zur Verfügung stellt. NetBIOS steht für Network Basic Input/Output System.
Für CIFS stellt NETBios drei Services zur Verfügung:
1. Name Service
2. Session Service
3. Datagram Service
Ad 1 – Name Service:
NETBios erzeugt vom Menschen lesbare Namen. Jedem Computer wird ein einmaliger Name zugeordnet. Der NETBios-Namensraum ist unstrukturiert, das bedeutet, in NETBios gibt’s keine Hierarchien. NETBios Name Service wird entweder von einem Name Server für Netbios(WINS) oder via Broadcast durchgeführt. Das bedeutet:
Ist ein WINS-Server im Netzwerk vorhanden, werden NETBios Name-Resolving Anfragen vom jeweiligen Client an diesen Server gesandt. Ist kein WINS-Server im Netzwerk vorhanden, so wird die Namensauflösung via NetBios-Broadcast im Lokalen Netzwerk durchgeführt. Diese beiden Optionen können wahlweise miteinander kombiniert werden über eine UND/ODER Bedingung.
Der Administrator hat hierfür vier Konfigurationsmöglichkeiten für jeden Knoten im Netz, der NETBios-Namensauflösung verwenden soll:
1. Broadcast only (b-node)
2. NBNS only (p-node)
3. Broadcast zuerst und dann NBNS,wenn keine Antwort auf Broadcast(m-node)
4. NBNS, und dann Broadcast, wenn der Server nicht reagiert (h-node)
Zur Namensgebung unter NETBios: ein NETBios-Rechner registriert seine NAME/IP-Kombination dynamisch, während der Rechner hochfährt. Er kann den Namen auch verwerfen, sobald der Name nicht mehr gebaucht wird.
NETBios-Namen müssen einigen Regeln entsprechen, die in den entsprechenden RFC’s dokumentiert sind. Eine Regel sei hier angeführt: Jeder NetBIOS Name kann sich nur auf eine einzige Workstation beziehen, oder auf eine Gruppe von Rechnern, die alle Teil einer Workgroup sind -> Group Name.
Die Wichtigsten NetBios Name service Prozeduren sind Name registration und Name query:
Name registration verknüpft einen NetBIOS Namen mit einer IP-Adresse.
Name query bestimmt die mit einem NetBIOS Namen verknüpfte IP-Adresse.
Die Methoden der Namensauflösung im Detail:
Name registration (b-node):
Der Computer, der einen Namen registrieren möchte, erzeugt ein NetBIOS Name Registration Packet und sendet es über Port 137 als UDP-Broadcast-Paket ins Lokale Netz. Dieses Paket enthält den Namen den die Workstation registrieren möchte und die IP-Adresse dieser Workstation. Dies wird drei mal in Abständen von 250 Milli-Sekunden wiederholt. In dieser Zeit wartet der Computer, ob ein anderer Rechner im Netz ein Paket zurücksendet, das sagt, dass jener den Namen bereits registriert hat -> ein sog. Defense Packet. Kommt kein Defense Packet zurück nach Ablauf der Zeit, hat der Computer seinen Namen erfolgreich registriert. In Kurzen Worten: Der Computer fragt im Netz nach, ob bereits jemand den Namen, den er selbst haben möchte, bereits in Besitz genommen hat.
Name Registration (p-node):
Der Computer, der einen Namen registrieren möchte, erzeugt ein NETBIOS-Name registration Packet und sendet es als UDP-Paket an den NBNS-Server/Port 137. Der NBNS Server durchsucht seine interne Datenbank, ob bereits ein anderer Rechner diesen Namen in Besitz genommen hat. Hat ein anderer Rechner den Namen bereits registriert/in Besitz genommen, sendet der Server eine NEGATIVE NAME REGISTRATION RESPONSE. Hat noch niemand den Namen registriert, sendet der Server eine POSITIVE NAME REGISTRATION RESPONSE an den Rechner und dieser hat somit erfolgreich seinen Namen registriert.
Name Query (b-node):
Will ein Computer die IP-Adresse zu einem NetBIOS-Namen herausfinden, so bildet er zuerst ein name query request und sendet es auf Port 137 via UDP als BROADCAST ins lokale Netz. Dieses name request query packet enthält den Namen, zu dem der rechner die IP-Adresse wissen will. Er wiederholt den Vorgang dreimal, in Abständen von 5 Sekunden. Innert dieser Zeit erhält der rechner entweder eine positive name query response von dem Computer, dem der name gehört, oder er erhält keine antwort. Wenn der rechner eine positive Name query response erhält, dann ist in dem Antwort Paket die IP-Adresse, die zu dem fraglichen Namen gehört.
Name Query (p-node):
Will ein Computer die IP-adresse zu einem NetBIOS-Namen herausfinden, so bildet er zuerst ein name query request und sendet es via UDP DIREKT an den NBNS-Server/Port 137. Der NBNS-Server durchsucht seine interne Datenbank nach dem fraglichen Namen. Findet er den Namen, so sendet er an den Computer eine positive name query response zurück, die die IP-Adresse zu dem fraglichen NetBIOS Namen enthält. Findet der NBNS-Server nichts, so sendet er eine negative name query response an den computer.
Session Service:
Laut RFC1001 ist eine Session ein zuverlässiger Nachrichtenaustausch, der zwischen zwei NetBIOS Applikationen gesteuert wird. Die Session ist voll-Duplex mit in Sequenzen eingeteilten Nachrichten, und sie ist verlässlich. Das Session service von NetBIOS definiert den Nachrichtenaustausch zwischen zwei Rechnern. Die Nachrichten können beliebiger Art sein. Das Session service sorgt nur dafür, dass die Nachrichten sequentiell und verlässlich zwischen zwei Rechnern transportiert werden.
Kurz um: Das ganze funktioniert wie eine TCP/IP-Verbindung, nur mit etwas anderer und erweiterter Funktionalität.
Die Session Services werden via TCP/IP auf Port 139 emuliert. Das Session Service sendet nur eine Nachricht zu einem Zeitpunkt und empfängt auch nur eine Nachricht zu einem Zeitpunkt. Das heisst, Session service ist nachrichtenorientiert. TCP/IP jedoch ist Datenstrom-Orientiert, d.h. zwischen zwei Punkten wird ein Datenstrom hin und her transportiert. Um NetBIOS Session Pakete über TCP zu versenden, werden die Session Service Pakete in kleinere TCP-Pakete zerlegt, die zusätzlich noch einen Header haben, der anzeigt, wie gross die gesendete netBIOS-Nachricht ist
Das Session Service wird von CIFS benutzt um die essentiellen File-Operation- und Printer kommandos zu senden/empfangen. Zu diesem Zweck wird im CIFS Netzwerk eine NetBIOS Session zwischen Client und Server aufgebaut.
Das Session Service definiert einige grundlegende Netzwerkaktionen (network primitives), die über TCP/IP gelegt werden. Nachstehend wird kurz beschrieben, wie dies geschieht.
CALL: Eröffnen der NETBIOS Session. In TCP ist das: TCP-Connection eröffnen (3WHS, usw); senden des NetBios Call Paketes, das beinhaltet: Client NetBios Name, Server NetBios Name.
LISTEN: Auf NETBIOS Call warten. In Tcp: Server Socket auf port 139, wartend auf einlangende Verbindungsanfragen denen ein NetBIOS Call Paket folgt.
HANG UP: Die NetBIOS Session beenden. In TCP: Die Verbindung auflösen.
SEND: Eine Nachricht über die Netbios Session senden. In TCP: Die Nachricht zerkleinern, Header mit der URSPRÜNGLICHEN Nachrichtengrösse draufknallen und die kleinen Pakete über den TCP Datenstrom senden. – Pakete werden fragmentiert.
RECEIVE: Eine NETBIOS-Session Nachricht empfangen: In TCP: Nachrichtenfragmente vom TCP-Datenstrom empfangen, bis die gesamte Nachricht (deren grösse über den erwähnten Header bekannt ist) eingelangt ist.
Datagram Service:
Das Datagram Service ist nicht verlässlich, verbindungslos und garantiert weder das Ankommen noch die Reihenfolge der gesendeten Pakete.
Das Datagram Service wird über das UDP-Protokoll auf Port 138 implementiert.
Ein NetBIOS Datagram Paket enthält informationen über: Den NetBiosNamen des absenders. Ob das Datagram Paket vor dem Senden über UDP fragmentiert worden ist.
CIFS benutzt NetBIOS Datagramme, um das Netzwerk zu „browsen“, dh. Um eine Tabelle aller im Netzwerk vorhandenen Rechner aufzustellen und aktuell zu halten. (Zb. Die Netzwerkumgebung unter Windows).
CIFS – tiefergehende Erläuterung:
Das CIFS-Protokoll definiert eine Client Server Umgebung, in der Der Client dem Server Anfragen Schickt die dieser überprüft und beantwortet. Jedes gesendete Paket enthält einen header sowie zwei Felder von variabler Länge, die paketspezifische informationen enthalten. Jedes Paket/jeder header enthält auch ein COMMAND FIELD, welches Information über den Zweck des Pakets enthält.
Die Struktur:
Client/Server – anfrage/antwort:
CIFS baut auf einer Client-Server struktur auf. Das Protokoll kann mehrere simultane Anfragen gleichzeitig bearbeiten. Dies wird durch die MULTIPLEX ID (MID) erreicht. Der Client stellt sicher, dass jedes Paket, das er anden Server schickt, eine einzigartige MID besitzt. Die Server Antwort enthält dann die gleiche MID. Auf diese Weise kann der Client, wenn er Mehrere Anfragen an den Server geschickt hat, jeder Antwort die entsprechende Anfrage zuordnen
Kommandobasiert:
Jedes CIFS-Paket enthält das COMMANDFIELD, das 1 Byte lang ist. Derzeit existieren etwa 100 Kommandos. Die Funktionalität des Paketes hängt vom Kommando ab.
Protokoll Dialekte/Negotiation:
Da viele Versionen von CIFS existieren, hat jede Version einen eindeutig identifizierbaren string, um den Dialekt zu kennzeichnen. Wenn ein Client mit einem Server reden will, sendet er ihm zuerst ein NEGOTIATE PROTOCOL PACKET, in dem er alle Dialekte von CIFS auflistet, die er versteht. Der Server antwortet mit einem Paket in dem er den Cifs Slang angibt, in dem er plaudern möchte.
USER/SHARE Level security:
Ein Share ist eine freigegebene Ressource auf dem Server (i.e. ein freigegebener Ordner)
User: Der eingeloggte USER darf auf die freigegebene Ressource, auf die er zugriffsberechtigt ist, zugreifen.
Share: Die freigegebene Ressource ist passwortgeschützt. Jeder User, der die Ressource verwenden möchte, muss das Passwort kennen.
Encryption:
Die Passwörter werrden verschlüsselt zum Server gesandt. Verschlüsselungsmethode: Der Server sendet dem Client einen zufallsgenerierten String und erwartet von Client sowohl den Zufallsstring als auch das Passwort.
Command batching:
Viele CIFS-Pakete können andere CIFS-Pakete huckepack nehmen, um Antwortzeiten zu verringern sowie um die Netzwerkbandbreite besser auszunutzen.
Opportunistic Locking:
Wenn ein File vom Client in Beschlag genommen wird, garantiert der Server durch den OpLock, dass nur DIESER Client das File schreibend bearbeiten kann. Er muss die Änderungen, die er am File durchführt, aufgrund des OpLocks nicht gleich auf das am Server liegende File zurückschreiben, sondern kann dies erst am Ende der Transaktion durchführen.
Grafik 5: CIFS-Header
Beschreibung:
Der Header beginnt mit 4 Bytes: Das erste Byte enthält 0xff, die drei folgenden in dieser reihenfolge: ‘S’,’M’,’B’.
Command: Das Kommando feld beinhaltet einen ein Byte langen Code, der den Zweck des CIFS Paketes beschreibt. ZB: SMB_COM_READ_ANDX (0x2E), SMB_COM_TREE_CONNECT (0x70), SMB_COM_NEGOTIATE (0x72)
Error Class: Wenn die Anfrage erfolglos gewesen ist, gibt der Server eine Antwort mit der entsprechenden Fehlermeldung zurück. Normalerweise ist dieses Feld leer, wenn die Anfrage erfolgreich ist. Dieses Feld kann folgende Werte annehmen:
- ERRDOS (0x01) – Fehler des DOS
- ERRSRV (0x02) – Fehler generiert vom server
- ERRHRD (0x03) – Hardwarefehler
- ERRCMD (0xFF) – Das Kommando ist nicht korrekt gewesen
Error Code: 16 bit langes Feld, das die genaue Art des Fehlers angibt. Normalerweise ist dieses Feld leer, da die Anfrage erfolgreich gewesen ist. Ansonsten ergibt diese Nummer in Verbindung mit der Fehlerklasse einen Code, den man in den CIFS 1.0 Spezifikationen erheben kann zwecks Fehlerbeschreibung.
Flags: die meisten Bits dieses Bytes sind für bestimmte Optionen reserviert. Von Bedeutung ist Flag 3: Ist Flag 3 gesetzt, so werden alle Pfadangaben in diesem einen Paket caseless behandelt. Ist es nicht gesetzt, so werden die Pfadangaben des Paketes case sensitive behandelt (Gross kleinschreibung).
Flags2: dieses 16-bit lange Feld ermöglicht die Einstellung weiterer Optionen.
- Wenn Bit0 gesetzt ist, gibt dies an, dass der Server lange Filenamen in der Antwort zurückgeben kann.
- Wenn Bit6 gesetzt ist, gibt dies an, dass jeder pfadname in der Anfrage ein langer Filename ist
- Wenn Bit16 gesetzt ist, gibt dies an, dass die strings im betreffenden Paket in UNICODE kodiert sind.
Pad/security signature: Ein feld das normalerweise auf null gesetzt ist [ka weitere Erklärung dazu gfunden, sakra]
Tree ID (TID): die TID ist eine 16 bit lange Nummer die angibt, auf welche Ressource auf dem Server sich das Paket bezieht.
Will ein Client auf dem Server eine Ressource ansprechen, sendet er ihm erst mal ein Paket mit Kommando SMB_CON_TREE_CONNECT_ANDX. In diesem Paket ist die Ressource angegeben -> \\server\dir. Der Server überprüft Gültigkeit, Berechtigung des Clients und sendet ggfs eine Antwort an den Client zurück, die Erfolg bescheidet. In diesem Antwortpaket gibt der Server eine Nummer seiner Wahl als TID an. Diese Nummer kann der Client in seinen Anfragen als TID setzen, wenn er nochmal auf die gleiche Ressource zugreifen möchte.
Process ID (PID): Die PID ist eine 16 Bit lange nummer die angibt, welcher Prozess auf dem Client den Fraglichen Request erzeugt hat. Mittels dieserr Nummer überprüft der Server Konkurrenz (zb bei Transaktionen)
User ID (UID): Will ein Client eine Session mit dem Server eröffnen, so sendet er ein Paket, das einen usernamen und ein passwort enthält, an den Server. Der Server überprüft, ob Username und Passwort gültig san und ob der Client zugriffsberechtigt ist, und baut im positiven Fall die Session auf. Er übersendet dem Client eine Antwort, in der die erzeugte UID enthalten ist. Der Client übersendet in allen weiteren CIFS Paketen diese UID, und der Server checkt anhand der UID, ob der Client die jeweiligen Aktionen auf den Ressourcen durchführen darf.
Wenn ein Share via share level verteilt wird, ist die UID uninteressant.
Die UID ist 16 bit lang.
Multiplex ID (MID): Die MID ist eine 16 bit lange Nummer, die dem Client erlaubt, mehrere Nachrichten gleichzeitig zu senden, ohne Verwirrung zu erzeugen.
Word Count und parameter words: Diese beiden Felder werden verwendet, um kommando spezifische Daten im Paket mitzusenden. In word count steht drin, wieviele 16-bit words im parameterfeld stecken. Die Grösse des Parameterfeldes wird dynamisch festgelegt.
Bytecount und buffer: Diese beiden Felder enthalten eine Variable Menge an Daten die pro Paket festgelegt wird. Bytecount gibt an, wieviele bytes im Buffer stecken. Im Buffer kann eine grosse Menge an Daten Stecken (zb Filedaten). Das ist sowas ähnliches wie die nutzlast im TCP/IP-Paket.
Zukunftsperspektiven:
Der nächste Schritt im Dasein von CIFS wird das Verschwinden von NetBIOS sein. Die CIFS-Nachrichtenblöcke werden direkt über TCP/IP versandt werden, ohne den Umweg über NetBIOS, das auch im Session-Modus nur eine Nachricht zu einem Zeitpunkt entweder versenden oder empfangen kann, so dass SMB-Nachrichten nicht erst mit einem NetBIOS Header versehen und dann von TCPIP nochmal zerkleinert (fragmentiert) werden müssen, damit sie in den von TCP/IP versandten Datenstrom passen. Die Vorteile liegen auf der Hand: Schnellere Verarbeitung (Duplex betrieb in der TCP/IP Session: beide Seiten können senden & empfangen zur gleichen Zeit, da die Datenströme über Sockets auf beiden Hosts eindeutig zugeordnet werden können), kleinerer Protokolloverhead und noch mehr kompatibilität.
Ausprägungen von CIFS im täglichen Umgang mit Computern:
In der Microsoft-Windows-Umgebung ist CIFS nahtlos implementiert. Man bemerkt sein Vorhandensein erst, wenn das Netzwerkbrowsing in der Netzwerkumgebung nicht klappt oder man das gewünschte Netzlaufwerk nicht verbinden kann.
In Microsoft-Windows wird CIFS durch die „Netzwerkumgebung“ und die „Netzlaufwerke“ repräsentiert. Man kann mit diesen beiden Features wie mit normalen, auf der lokalen Umgebung befindlichen Laufwerken und Dateien (Ordnern) arbeiten, ohne sich Gedanken über Netzwerke u dgl machen zu müssen. Lediglich wenn man sich mit einem geschützten Ordner oder einem geschützten Netzlaufwerk verbinden will, schreit das Betriebssystem „Konnte Verbindung nicht herstellen: Zugriff verweigert“ oder ähnliches,da CIFS auch einen Authentifizierungsmechanismus includiert.
Die Netzwerkumgebung wird durch das bereits erwähnte Netzwerkbrowsing mit im Netz vorhandenen Windowsrechnern (lt. Spezifikation Servern) „gefüllt“.
Weshalb reite ich so auf diesen „Servern“ herum? Ganz einfach: Jeder Windows Rechner (zumindest die Rechner mit Win98 aufwärts) hat im Betriebssystem grundlegende Serverdienste bereitgestellt, die z.b. das Freigeben von Ordnern und Druckern ermöglichen, auf die andere, entfernte Rechner via Netzwerk zugreifen können. Daher ist jeder Windowsrechner (zumindest im Sinne von Windows-Browsing) ein Server, und nicht nur die EXPLIZIT für Serverdienste im Netzwerk bereitgestellten speziellen Servermaschinen.
Unter Linux/Unix kommt CIFS im SAMBA-Server von Andrew Tridgell zum Ausdruck. Ein Linuxrechner, der SAMBA installiert hat, kann Windowsrechnern Verzeichnisse zur Verfügung stellen respektive Verzeichnisse von Windowsrechnern über mount –t smb (?) //[unc-pfad] /[mountpoint] importieren.
Mittels SAMBA kann der Linux/Unix-Rechner den Windowsrechnern im Netzwerk auch Print-Server-Dienste zur Verfügung stellen, sowie als Masterbrowser und Wins-Server des Netzwerkes sowohl für die Windows-Serverliste als auch für die NetBIOS-Namensauflösung verantwortlich sein.
Für Apple MacIntosh-Rechner gibt es ein Programm namens DAVE, das die nahtlose Einbindung des Apple MacIntosh in die Windows Netzwerkumgebung ermöglicht, sodass dieser auf Windows-Verzeichnissen seine Dateien ablegen kann (oder umgekehrt, die Windowsrechner den Apple als Datenhort benutzen).