Tag 6: Sicherheitsmodi und Passwörter

Als ich nach meiner Woche Urlaub in Kapitel 4, »Installation und Testen der Konfiguration«, an meinen Arbeitsplatz zurückkam, nahm meine Chefin mich beiseite. »Diese Netzwerklaufwerksdinger, die du eingerichtet hast, sind großartig. Die Produktivität ist in ungeahnte Höhen geschnellt. Ich würde diese Methode gern unternehmensweit einsetzen, aber bevor ich sie dem Management empfehlen kann, brauche ich einige genaue Fakten zur Sicherheit des Ganzen. Kannst du mir erklären, wie Samba mein Passwort überprüft, wenn ich mich einlogge?«

Einen Moment stand ich da und dachte nach. Dann sagte ich: »Ich setze mich gerne hin und erkläre, wie das alles abläuft, aber erst brauche ich eine Stunde, um mir einen Kaffee zu holen und einige Dinge zu erledigen.«

»Hört sich gut an«, sagte meine Chefin. »Ich sehe dich dann in einer Stunde in meinem Büro.«

Ich ging den Flur hinunter zum Testlabor und versuchte mich daran zu erinnern, wo ich meine Lieblingstasse und meine Kopie dieses Buches gelassen hatte.

Konnte ich die Informationen rechtzeitig finden? Würde Samba unternehmensweit eingesetzt werden?

Bleiben Sie dabei und finden Sie es heraus!

Im vorangegangenen Kapitel habe ich den allgemeinen Aufbau der Samba-Konfigurationsdatei und einige der generellen und verschiedenen [global]-Parameter dargestellt. In diesem Kapitel geht es um die Parameter, die für die Authentifizierungsmethoden relevant sind, wenn sich Clients mit dem Samba-Server verbinden. Außerdem werde ich Ihnen etwas über Passwortsicherheit, Verschlüsselung und die Benutzung der IP-Adresse eines Clients für die Entscheidung, ob die Verbindung überhaupt authentifiziert wird, erzählen.

Sicherheitsmodi und der Parameter security

Das SMB-Protokoll bietet zwei grundsätzliche Modi für die Authentifizierung von Verbindungen. Der von Samba benutzte Modus wird durch die Einstellungen für den Parameter security im Abschnitt [global] der smb.conf definiert.

Der Eintrag für den Parameter security in der smb.conf-Manpage listet vier mögliche Eingaben auf, die verwendet werden können. Ich sprach aber von zwei grundlegenden Methoden, die das SMB-Protokoll für die Authentifizierung bietet. In der Realität sind von den vier Modi, die Samba unterstützt - share, user, server und domain - nur share und user fundamental unterschiedlich und stellen damit die zwei SMB-Sicherheitsmodi dar. Die anderen von Samba unterstützten Werte sind Variationen des User-Sicherheitsmodus:

Vor Version 2.0 war die Standardeinstellung für den Sicherheitsparameter share. Mit der Version 2.0 wurde diese Einstellung auf den User-Modus geändert.

Mit Samba 2.0 wurde ein Passwortdatenbank-API eingeführt, über das Entwickler durch Definition einer Sammlung von Funktionen verschiedene Authentifizierungsmethoden einbetten können. Das heißt, dass Sie mehrere Methoden zur Auswahl haben, wenn Sie entscheiden, wie Sie die Informationen zu Ihren Bentuzer-Accounts speichern wollen.

Abbildung 6.1 zeigt die möglichen Backends, die derzeit benutzt werden oder sich in der Entwicklungsphase befinden. Der Client verlangt eine Verbindung zum Server, und der Server kontaktiert die Account-Datenbank über ein definiertes Interface. Es ist nicht unbedingt notwendig zu wissen, welches Backend benutzt wird. Was Samba betrifft, bietet die Datenbank die benötigten Benutzerinformationen.

Derzeit wird experimentelle Unterstützung für den Zugriff auf NIS+-Tabellen und einen Lightweight-Directory-Access-Protocol-(LDAP-)Server entwickelt. Von den in Abbildung 6.1 dargestellten Möglichkeiten werden derzeit die Samba-private/smbpasswd-Datei und die Standard-Unix-/etc/passwd-Datei unterstützt. Beide Methoden werden später in diesem Kapitel ausführlich dargestellt. Jetzt sollten Sie nur wissen, dass beide Methoden für die Authentifizierung einen Benutzernamen und ein Passwort verlangen.

security = share

Im Share-Modus (Freigabeebene) sendet der Client während der Verbindungsanfrage ein Passwort. Ein zugehöriger Benutzername ist nicht erforderlich. Dies unterscheidet sich etwas von der Beschreibung, die ich in Kapitel 2, »Windows-Netzwerke«, gegeben habe, die eher auf den User-Modus zutrifft. Abbildung 6.2 verdeutlicht die zwei Schritte, die im Share-Modus für eine Verbindung zu einem SMB-Server benutzt werden.

Möglicherweise kennen Sie bereits ein Beispiel für einen SMB-Server im Share-Modus. Der Share-Modus ist die Standardeinstellung für einen Datei- oder Drucker-Server unter Windows 95 (siehe Abbildung 6.3). Abbildung 6.4 zeigt das Dialogfeld in der Netzwerkfreigabe, über das Sie den Sicherheitsmodus ändern können.

Vielleicht denken Sie mittlerweile: »Die Zugriffskontrolle auf Freigabeebene scheint dem Authentifizierungsmodell Benutzername/Passwort unter Unix zu widersprechen.« Sie haben Recht. Das Konzept des Share-Modus funktioniert in einer Multiuser-Umgebung wie Unix nicht gut, aber Samba versucht weitestgehend, das Unix-Sicherheitsmodell nicht zu beeinträchtigen.

Obwohl der Client erwartet, dass der SMB-Server im Share-Modus jeder Freigabe ein Passwort zuordnet, benutzt Samba das Standard-Unix-Benutzername/Passwort-Schema. Trotz der Tatsache, dass Clients der Verbindungsanfrage an einen Server im Share-Modus ein Passwort beifügen, übertragen viele Clients außerdem eine Sitzungsanfrage, die einen Benutzernamen enthält. Samba fügt diesen Namen einer Namensliste hinzu und versucht, ihn über das übertragene Passwort zu authentifizieren. Sie können andere Benutzernamen spezifizieren, die in die Liste aufgenommen werden sollen, indem Sie für die Freigabe den Parameter user definieren:

Samba versucht die Verbindung zu authentifizieren, indem es jeden Benutzernamen mit dem Passwort vergleicht, bis eine Entsprechung gefunden wird oder auch nicht; dann wird die Verbindung zur Freigabe abgelehnt. Da Samba sowieso immer versucht, eine Kombination aus Benutzername und Passwort zu authentifizieren, wird die Zugriffskontrolle im Share-Modus nicht empfohlen. Es ist generell besser, eine Form der Authentifizierung auf Benutzerebene, die ich im nächsten Abschnitt darstelle, zu verwenden.

security = user

In Kapitel 2 (im Abschnitt »Protokollüberblick«) versucht ein Client, sich mit einem Server im User-Modus zu verbinden. Werden unverschlüsselte Passwörter benutzt, überträgt der Client während der Sitzungsaufnahme einen Benutzernamen und ein Passwort.

Da es in diesem Buch um die Benutzung von Samba und nicht um die Entwicklung eines SMB-Servers geht, werde ich Sie nicht sehr oft mit Paketausgaben langweilen. Aber ich denke, es ist recht nützlich, die Account-Informationen zu sehen, die während dieser Phase der Verbindung übertragen werden. Nachfolgend finden Sie eine Sitzungsanfrage von einem Windows-95-OSR2-Client, der sich mit einem Samba-Server verbindet. Die Pakete wurden über eine SMB-aktivierte Version von tcpdump abgefangen:

tcpdump ist ein Netzwerkpaket-Sniffer, der mit Source-Code verteilt wird. Die SMB-aktivierte Version können Sie sich unter http://samba.org herunterladen. Weitere Informationen über Paket-Sniffer finden Sie in Kapitel 11, »Troubleshooting«.

Nach Ausführung des Befehls generiert tcpdump folgende Ausgabe:

Sie können erkennen, dass das Passwort testpass und der Benutzername boss während der Sitzungsanfrage übertragen werden. Wenn Sie genau hinsehen, werden Sie auch feststellen, dass der Benutzername und das Passwort in Großbuchstaben umgewandelt werden. Dies kann ärgerlich sein und wird im Abschnitt »Passwortverschlüsselung« später in diesem Kapitel dargestellt.

Im User-Modus akzeptiert Samba die übermittelte Kombination aus Benutzername und Passwort und versucht, diese unter Benutzung seiner Account-Datenbank zu authentifizieren. Dieser Prozess ist unabhängig vom Backend des Benutzer-Accounts (z.B. verschlüsselte Passwörter, LDAP und /etc/passwd) immer gleich, obwohl der Beweis der Identität auch ein abgeleiteter Wert statt des eigentlichen Passworts selbst sein kann. Bitte beachten Sie die Hinweise zur SMB-Challenge/Response-Verschlüsselung im Abschnitt »Passwortverschlüsselung« später in diesem Kapitel. Ist die Authentifizierung der Sitzungsanfrage erfolgreich, braucht der Client während nachfolgender Verbindungsanfragen keine Benutzer-Account-Informationen zu übertragen.

In Abbildung 6.5 sind die drei Schritte für eine Verbindung zu einem SMB-Server im User-Modus dargestellt. Zunächst wird der Protokolldialekt ausgewählt, dann eine Sitzung zwischen dem Client und dem Server aufgebaut und schließlich die Verbindung zur Ressource konfiguriert.

security = server

Der Server-Modus von Samba ist im Prinzip eine Variante des User-Modus. Samba teilt dem Client mit, dass es sich im User-Modus befindet, und der Client führt eine normale Sitzungsanfrage durch. Samba nimmt dann die Informationen und sendet eine Sitzungsanfrage an den Rechner, der als Passwort-Server fungiert. Befindet sich der Passwort-Server im User-Modus und akzeptiert die Sitzungsanfrage, akzeptiert Samba die ursprüngliche Sitzungsanfrage des Clients.

Abbildung 6.6 illustriert diesen Prozess. Die chronologische Reihenfolge des Diagramms ist von oben nach unten. Wenn Sie den Pfeilen folgen, sehen Sie, dass an dem Punkt, an dem der Client eine Sitzung mit dem Server verlangt, dieser eine Sitzungsanfrage an den Passwort-Server sendet. Erst wenn der Server eine Antwort vom Passwort-Server erhalten hat, wird die Anfrage des Clients akzeptiert oder abgelehnt.

Der Parameter password server hat folgende Syntax:

Sie können mehrere NetBIOS-Namen auflisten, z.B.

Mit dieser Einstellung kann Samba versuchen, jedem aufgelisteten Server nacheinander eine Sitzungsanfrage zu senden, bis ein Server antwortet. Das heißt, der nächste Rechner in der Liste wird nur dann kontaktiert, wenn der vorstehende Rechner nicht erreichbar war. Es heißt nicht, dass Samba versucht, die anderen aufgelisteten Rechner zu kontaktieren, wenn die Verbindungsanfrage an den ersten Rechner scheitert.

Sie müssen den NetBIOS-Namen des Passwort-Servers benutzen (nicht die IP-Adresse), und Samba muss eine Möglichkeit haben, den Namen in eine IP-Adresse aufzulösen, um eine Verbindungsaufnahme zu versuchen.

Sie können jeden SMB-Server im User-Modus als Passwort-Server verwenden, aber die Sicherheit Ihres Samba-Servers entspricht dann nur der des augewählten Passwort-Servers. Ich habe Sie gewarnt! Übliche Wahlen für einen Passwort-Server sind Ihr Windows NT Primary Domain Controller (PDC) oder ein anderer Samba-Rechner.

Der Server-Modus hat eine Besonderheit. Nachdem Samba die Sitzungsanfrage für den Client gewährt hat, muss es eine Methode haben, eine Unix-UID für den Benutzer zu bekommen, um den Zugriff auf Dateien kontrollieren zu können. Das heißt, dass zwar keine lokalen Accounts für die Authentifizierung der Verbindung verwendet werden, aber der Benutzer muss eine UID auf dem lokalen Server haben. Es gibt zwei mögliche Lösungen für dieses Problem:

• Sie können einen lokalen Account für alle Benutzer einrichten, die auf den Samba-Server zugreifen und einfach das Passwortfeld in der /etc/passwd (oder der Datei, in der die Passwörter gespeichert sind) deaktivieren. Normalerweise erreichen Sie dies, indem Sie das Sternchen (*) in das Feld password setzen.
• Sie können eine der Methoden benutzen, über die Benutzernamen innerhalb einer Freigabe zugeordnet werden, z.B. force user, die in Kapitel 7, »Dateifreigaben«, beschrieben werden. Oder verwenden Sie den Parameter username map, den ich später in diesem Kapitel darstelle.

Abbildung 6.7 sieht Abbildung 6.6 sehr ähnlich, da beide Abbildungen den gleichen Prozess darstellen. Abbildung 6.7 wurde aber um den Punkt erweitert, an dem Samba versucht, eine gültige Unix-UID für den in der Sitzungsanfrage angegebenen Benutzernamen zu erhalten. In einem gewissen Sinne transparent ist, dass die Suche nach dem Benutzernamen durch den Parameter username map gefiltert werden kann, bevor der Name tatsächlich in der /etc/passwd gesucht wird.

security = domain

Der Domain-Modus von Samba entspricht im Wesentlichen dem Konzept des Server-Modus, mit der Ausnahme, dass der Samba-Server Mitglied einer Windows-NT-Domäne wird. Das heißt, der Samba-Server kann an Dingen wie vertrauten Beziehungen teilnehmen. Es gibt einige weitere Vorteile für die Benutzung von security = domain statt security = server. Diese Darstellung möchte ich auf Kapitel 12, »Fallstudie: Einen NT-Datei- und Drucker-Server ersetzen«, verschieben, in dem ich beschreibe, wie ein Windows-NT-Datei- und Drucker-Server durch einen Samba-Rechner im Domain-Modus ersetzt wird. Bis dahin betrachten Sie bitte die zwei Modi als äquivalent.

Benutzernamen und Passwörter

Jetzt wissen Sie, wie smbd-Verbindungen authentifiziert werden, und können sich auf die Details von Benutzernamen und Passwörtern konzentrieren.

Username Level

Wie Sie bereits in der Paketausgabe von einer Sitzungsanfrage gesehen haben, übertragen einige Clients den Benutzernamen komplett in Großbuchstaben. Standardmäßig versucht Samba, diesen Benutzernamen klein geschrieben zu suchen und dann nur mit dem ersten Buchstaben groß geschrieben, z.B. boss und Boss. Wenn Sie einen seltsamen Unix-Benutzernamen haben, wie z.B. BobAcct, der Bob in der Abteilung Accounting zugewiesen ist, kann Samba mit dieser Methode den Benutzernamen nicht finden.

Darum gibt es einen Parameter, über den die maximale Anzahl von Großbuchstaben in dem Benutzernamen bestimmt werden kann. Samba versucht dann, über eine Brute-Force-Methode den Benutzernamen zu finden, indem es alle Abwandlungen mit Großbuchstaben von 1 bis zum definierten Wert ausprobiert.

Stellen Sie den Parameter username level auf 4 ein und wenden Sie diese Einstellung auf Bobs Account-Namen an:

Sie können voraussetzen, dass als Benutzername während der Sitzungsanfrage BOBACCT übertragen wird. Samba versucht, folgende Namen in der Systempasswortdatei (oder anderen benutzten Backends) zu finden:

Die Suche wird beendet, sobald der Benutzername gefunden ist. Je höher der Wert für username level, um so mehr Kombinationen von Groß-/Kleinbuchstaben werden ausprobiert und um so länger dauert es, bis die Suche erfolgreich oder auch nicht abgeschlossen ist. Sind alle Unix-Account-Namen im Standardformat klein geschrieben, wird dieser Parameter unnötig.

Username Map

Eines der Hauptprobleme bei der Integration von Unix- und PC-Betriebssystemen besteht in der Synchronisierung der Informationen zu den Benutzer-Accounts. Einige Unix-Varianten lassen nur die Benutzung von acht Zeichen oder weniger für den Benutzernamen zu, während einige Windows-Clients eine beliebige Zeichenkette mit Leerzeichen erlauben. Oft finden sich Administratoren mit der Aufgabe beschäftigt, zwei bereits etablierte Systeme mit existierenden Account-Namen zu integrieren. Mit dem Parameter username map können Sie eine Datei spezifizieren, die den während einer Verbindungsanfrage übertragenen Benutzernamen einem lokalen Benutzernamen zuordnet.

Diese Option ist standardmäßig nicht aktiviert.

Um Zuordnungen zu verwenden, müssen Sie den Standort der Datei spezifizieren, in der die Zuordnungen enthalten sind:

Jeder Eintrag in der Datei sieht so aus:

Unix Benutzername = Client-Benutzername ...

Wenn Sie z.B. den Benutzernamen Administrator oder Admin dem Account sysadmin zuordnen wollen, definieren Sie folgenden Eintrag:

Wenn ein Benutzer versucht, sich als Administrator mit einer Freigabe zu verbinden, muss er das Passwort für den Account sysadmin übermitteln.

Die Zuordnung wirkt sich auf alle Beispiele des Client-Benutzernamens aus, mit Ausnahme der Sitzungsaufnahme zu einem Passwort-Server, wenn securitiy = server gesetzt ist. Um bei obigem Beispiel zu bleiben: Wenn ein Benutzer versucht, sich mit dem Home-Verzeichnis von Administrator zu verbinden, würde er sich tatsächlich mit \\server\sysadmin verbinden.

Es ist möglich, Unix-Gruppen einem einzelnen Account zuzuordnen. Diese Zeile ordnet jeden Benutzer in der Gruppe staff dem Account staffsmb zu:

Es steht außerdem eine Wildcard zur Verfügung, über die Sie jeden vom Client übertragenen Namen zuordnen können. Dieser Eintrag ordnet alle Benutzer dem Account guest zu:

In Hinsicht auf Abbildungen gibt es einen Punkt, den Sie beachten sollten: smbd analysiert die Datei Zeile für Zeile und führt eventuelle Abbildungen bis zum Ende der Datei durch. Dies kann zu mehrfachen Zuordnungen führen, von Benutzername zu neuer_Benutzername1 zu neuer_Benutzername2. Wenn Sie die Analyse der Datei stoppen wollen, nachdem eine Zuordnung erfolgt ist, sollten Sie der Zeile ein Ausrufungszeichen (!) voranstellen. Wird keine Zuordnung in der Datei gefunden, benutzt Samba den ursprünglichen Benutzernamen.

Password Level

Werden für die Authentifizierung Klartextpasswörter benutzt, tauchen ähnliche Probleme auf wie die, die ich im Abschnitt über Benutzernamen in Bezug auf die Groß-/Kleinschreibung erwähnt habe. Dieser Ausschnitt aus der vorher gezeigten tcpdump-Ausgabe erinnert Sie daran, dass das Passwort, testpass, in Großbuchstaben übertragen wird:

Der Parameter password level hat in etwa die gleiche Funktion wie der Parameter username level. Der Unterschied liegt darin, dass standardmäßig zwei Möglichkeiten für die Verwendung des Passworts ausprobiert werden: so, wie es vom Client übertragen wird, und komplett klein geschrieben.

Wie der Parameter username level nimmt auch password level als Wert eine ganze Zahl an, die die maximale Anzahl von Großbuchstaben definiert, die für das Passwort zugelassen sind. Samba versucht dann, den Benutzernamen zu authentifizieren, indem es Abwandlungen der Großbuchstaben im Passwort benutzt.

Je größer der Wert und je mehr Kombinationen Samba ausprobiert, um so länger dauert die Authentifizierungsphase. Sie müssen bestimmen, was für Ihren Server akzeptabel ist. Ein password level = 8 bedeutet auf den meisten Systemen, dass beim Passwort nicht mehr zwischen Groß- und Kleinschreibung unterschieden wird. Ich habe festgestellt, dass die Einstellung 4 in der Regel akzeptabel ist und nicht allzu viele Umstände für existierende Passwörter macht. Es ist jedoch auch hilfreich, die Richtlinien für die Benutzung von Passwörtern dahingehend zu ändern, dass nicht mehr als vier Großbuchstaben verwendet werden dürfen.

Passwortverschlüsselung

Samba unterstützt sowohl die LanManager- als auch die Windows-NT-SMB-Passwort-Verschlüsselungsalgorithmen. Das heißt, Samba kann Benutzer auf die gleiche Art und Weise authentifizieren wie Microsoft-Server es können.

Wenn Sie mit der Verschlüsselung von Passwörtern unter Unix vertraut sind, erscheinen Ihnen einige Punkte vielleicht ähnlich. Z.B. sind die LanMan- und NT-Passwort-Hashwerte unwiderruflich, ebenso wie Unix-Passwörter, die in /etc/passwd (oder /etc/shadow) gespeichert sind. Unwiderruflich heißt, dass Sie nur dann feststellen können, ob ein Benutzer das korrekte Passwort eingegeben hat, wenn Sie das eingegebene Passwort verschlüsseln und diesen Wert mit der verschlüsselten Version vergleichen, die auf der Festplatte gespeichert ist. Es gibt keine Möglichkeit, einen LanMan/NT-Hash zu entschlüsseln außer über Brute-Force-Methoden, wie z.B. einen Wörterbuchangriff.

Sie sollten einen großen Unterschied zwischen den Unix- und LanMan/NT-Verschlüsselungsalgorithmen beachten. Der Algorithmus zur Erzeugung eines LanManager- oder NT-Passwort-Hashwerts produziert bei gleicher Eingabe immer das gleiche Resultat. Das heißt, wenn Sie das Passwort testpass zweihundertmal verschlüsseln, ist das verschlüsselte Passwort immer gleich. Dieser Prozess erzeugt, was als Klartextentsprechung bekannt ist.

Ich hoffe, dass das folgende Beispiel dies klarmacht. Sie können den Prozess in Abbildung 6.8 verfolgen.

1. Der Client sendet eine Anfrage für eine Protokollverhandlung an den Server.
2. Unterstützt der Server verschlüsselte Passwörter, wird das entsprechende Bit im Response-Paket übertragen, und der Server fügt dem Paket eine 8-Bit-Challenge hinzu. Diese Aufforderung wird zufällig erzeugt und ist für jeden Client verschieden.
3. Abbildung 6.9 illustriert die Generierung der Client-Antwort. Der Client benutzt das verschlüsselte Passwort, das dem verhandelten Protokolldialekt entspricht (entweder LanMan oder NT) und hängt fünf Null-Bytes an (dies erzeugt einen 168-Bit-Stream), um drei verschiedene 56-Bit-DES-Schlüssel zu erzeugen, die dann jeweils für die Verschlüsselung der 8-Byte-Challenge benutzt werden. Die drei 8-Byte-Resultate werden zusammengefasst und bilden die 24 Byte lange Antwort, die an den Server übertragen wird.
Abb. 6.9: Die 24 Byte lange Antwort generieren



4. Der Server führt dann unter Benutzung der verschlüsselten Version des Benutzerpassworts, die auf der Festplatte gespeichert ist, die gleichen Schritte durch. Das Resultat wird mit dem vom Client übertragenen Wert verglichen, um zu überprüfen, ob der Client das korrekte Passwort benutzt hat.
5. Stimmen der 24-Byte-Wert des Servers und die vom Client übermittelte Antwort überein, wird die Sitzungsanfrage (oder Freigabeverbindung im Falle des Share-Modus) akzeptiert. Stimmen sie nicht überein, hat der Client nicht das korrekte Passwort übertragen.

Machen Sie sich keine Gedanken, wenn Sie den Prozess nicht Wort für Wort wiederholen können. Ich habe ihn hier nur dargestellt, um einen Punkt zu beweisen. Das Passwort des Benutzers wird niemals über das Netzwerk übertragen. Das sorgt für erhöhte Sicherheit. Es werden nur die Daten übertragen, die aus dem Passwort generiert wurden.

Kommen wir nun zurück zu meinem vorangegangenen Kommentar über Klartextentsprechungen von Passwörtern. Der Server muss das verschlüsselte Passwort irgendwo speichern, damit er den 24-Byte-Wert generieren kann, um die Antwort des Clients zu authentifizieren. Denken Sie daran, dass das Passwort immer auf den gleichen Wert verschlüsselt wird. Wenn also jemand die verschlüsselte Version des Passworts kennt, kann diese Person an dem vorher beschriebenen Prozess teilnehmen, ohne das Passwort jemals kennen zu müssen!

Sind das zu viele Informationen auf einmal? Vielleicht können einige dieser Punkte helfen, sich für verschlüsselte oder Klartextpasswörter zu entscheiden:

• Mit Klartextpasswörtern kann Samba die gleiche Passwortdatenbank (d.h. die /etc/passwd) benutzen wie andere Unix-Dienste, z.B. login und FTP. Diese Dienste übermitteln Passwörter oft auch in Klartext über das Netzwerk. Samba überträgt also keine Benutzer-Account-Informationen, die nicht sowieso schon über das Netzwerk geschickt werden.
• Wenn Sie Klartextpasswörter benutzen, brauchen Sie nichts anderes als normale Unix-Systemdateien, die auf der Festplatte gespeichert werden.
• Windows NT ab SP3 mag keine Klartextpasswörter, und Sie können keinen Server browsen, der Verschlüsselung nicht unterstützt. NT fordert außerdem die Eingabe eines Passworts, wenn Sie sich mit nicht verschlüsselten Freigaben verbinden wollen, was bei häufigen Freigabeverbindungen extrem ärgerlich werden kann.
• Die Abstimmung zwischen smbpasswd und unix passwd kann schwierig sein. Weitere Informationen hierzu finden Sie in Kapitel 16, »Passwortsynchronisierung«.
• Verschlüsselte Passwörter können nicht von jemandem gelesen werden, der Zugriff auf die zwischen Client und Server übertragenen Pakete hat. Wenn Sie Klartextpasswörter benutzen, können die übertragenen Informationen über einfache Netzwerkanalyse-Tools wie tcpdump eingesehen werden.

Wenn Sie sich für verschlüsselte Passwörter entscheiden, die standardmäßig nicht aktiviert sind, können Sie die Funktion über folgende Einstellung in Ihrer smb.conf aktivieren:

Haben Sie die Verschlüsselung von Passwörtern aktiviert, müssen Sie nun eine zweite Benuter-Account-Datei im Auge behalten. In dieser Datei, die normalerweise smbpasswd genannt wird und sich in einem Unterverzeichnis namens private unterhalb des Samba-Installationsverzeichnisses befindet, speichert Samba die LanMan- und NT-Hashwerte der Benutzerpasswörter. Das Format ist dem von /etc/passwd sehr ähnlich:

Die Felder username und uid erklären sich von selbst. Die nächsten zwei Felder enthalten die zwei 16-Byte-Hashwerte des Benutzernamens, die von LanMan bzw. NT generiert wurden. Das Feld account flags bestimmt den Typ des Accounts wie z.B. Benutzer-Account oder Rechner-Account (Rechner-Accounts werden in Anhang A, »Experimentelle PDC-Unterstützung«, näher dargestellt). Das Feld lastset zeichnet den Zeitpunkt der letzten Passwortänderung auf.

Hier ein Beispieleintrag:

Wollen Sie die Datei, die die verschlüsselten Passwörter enthält, an einem anderen Ort speichern oder sie umbenennen, können Sie die neuen Werte über den Parameter smb passwd file definieren. Der Wert sollte ein absoluter Pfad zur SMB-Passwortdatei wie der folgende sein:

Das Erzeugen der ursprünglichen SMB-passwd-Datei und das Einrichten der Passwörter kann eine extrem erschreckende Aufgabe sein, wenn Sie viele existierende Unix-Accounts haben.

Es gibt hier zwei übliche Lösungen. Beide verlangen, dass Sie zunächst einen ersten smbpasswd-Eintrag für jeden Benutzer einrichten. Dies kann ganz einfach gemacht werden, wenn Sie eines der Skripte benutzen, die in der Samba-Distribution enthalten sind:

Erhält der Unix-Rechner Account-Informationen von NIS oder NIS+, können Sie den oben stehenden Befehl cat je nach System entweder durch ypcat oder niscat ersetzen. Das Shellskript mksmbpasswd.sh befindet sich im Unterverzeichnis source/script der Samba-Distribution. Die resultierende smbpasswd-Datei enthält alle Benutzer aus /etc/passwd mit ihren LanMan- und NT-Hash-Passwortwerten, die auf 32 X eingestellt sind. Samba authentifiziert einen Benutzer, dessen Passworteintrag auf diesen Wert eingestellt ist, nicht.

Wollen Sie den Wert auf ein leeres Passwort setzen, müssen Sie

durch

ersetzen.

Geben Sie als root den folgenden Befehl aus:

Ersetzen Sie Benutzername durch den entsprechenden Benutzernamen. Samba speichert die verschlüsselten Passwörter in einer Datei namens smbpasswd und fügt ein Utility hinzu, das ebenfalls smbpasswd heißt, um die Einträge in der Datei zu manipulieren. Lassen Sie sich durch den Namen nicht verwirren.

Alternativ können Sie die smbpasswd-Datei manuell über einen Texteditor bearbeiten und die Eingabe selber ändern. Wenn Sie die smbpasswd-Datei tatsächlich manuell bearbeiten, sollten Sie jedoch sicherstellen, dass die LanMan- und NT-Passwortfelder 32 Zeichen enthalten, nicht mehr und nicht weniger. Haben die Felder nicht genau 32 Zeichen, kann Samba diesen Benutzer niemals authentifizieren.

Nachdem Sie den smbpasswd-Eintrag geändert haben, müssen Sie den folgenden Parameter null passwords im Abschnitt [global] der smb.conf auf yes setzen:

Nach Erzeugen der smbpasswd-Datei bleibt die Frage: »Wie fülle ich das Passwortfeld für jeden Eintrag?«

Lösung 1

Wenn Sie Samba derzeit mit Klartextpasswörtern benutzen, können Sie die verschlüsselten Passwortfelder nach und nach für jeden Benutzer füllen, indem Sie den booleschen Parameter update encrypted benutzen. Der Standardwert für diesen Parameter ist no. Um die Unterstützung zu aktivieren, müssen Sie im Abschnitt [global] der smb.conf folgenden Eintrag einfügen:

Wenn Sie den Wert dieses Parameters auf yes setzen, müssen Sie sicherstellen, dass der Parameter encrypt passwords auf no gesetzt ist.

Ist der Parameter update encrypted auf yes gesetzt, schreibt Samba jedes Mal, wenn ein Benutzer erfolgreich eine Sitzungsaufnahme verlangt, die verschlüsselte Version des Klartextpassworts, das für diesen Benutzer übermittelt wurde. Die einzige Voraussetzung ist, dass der Benutzer einen gültigen Eintrag in der vorhandenen smbpasswd-Datei hat. Was immer der vorherige Wert des passwd-Felds war, es ist jetzt auf das aktuelle Passwort des Benutzers eingestellt. Natürlich hat diese Methode nur im User-Modus Sinn.

Mit dieser Lösung kann der Samba-Server einige Tage oder Wochen, wie lange auch immer er braucht, laufen, Passwörter abfangen und die smbpasswd-Datei ausfüllen. Enthält smbpasswd genügend Einträge, können Sie einfach die folgenden Parameter in smb.conf ändern und auf die Benutzung verschlüsselter Passwörter umschalten:

Die meisten Ihrer Benutzer werden niemals erfahren, dass sich etwas geändert hat.

Abbildung 6.10 verdeutlicht, wie der Parameter update encrypted funktioniert. Zunächst wählen der Client und der Server den Protokolldialekt, dann sendet der Client in seiner Sitzungsanfrage den Benutzernamen und das Passwort in Klartext. Kann der Benutzer erfolgreich über /etc/passwd authentifiziert werden, verschlüsselt der smbd das Passwort und schreibt die Informationen in die smbpasswd-Datei. Sie sollten wissen, dass der Eintrag des Benutzers in der smbpasswd an diesem Punkt des Authentifizierungsprozesses niemals benutzt wird. Das verschlüsselte Passwort wird hier nur aufbewahrt.

Lösung 2

Ich habe vorher schon erwähnt, dass Samba ein Utility namens smbpasswd enthält, mit dem Sie Einträge in der smbpasswd-Datei manipulieren können. Dieses Tool finden Sie im Unterverzeichnis /bin. Es ist die Entsprechung des Unix-Programms /bin/passwd.

Wenn ein Benutzer einen neuen Unix-Account erhält, weisen die meisten Unternehmen ein zufälliges Passwort zu und zeigen dann dem Benutzer, wie er das Passwort ändern kann, damit es persönlicher oder leichter zu merken ist. Wenn Sie eine neue Samba-Infrastruktur aufbauen - das Wort könnte doch glatt aus einem Dilbert-Comic stammen, oder? -, könnten Sie Benutzern ganz einfach gleichzeitig mit ihrem neuen Unix-Account auch ein SMB-Passwort zuweisen. Zusammen mit den Standardanweisungen für die Änderung ihres Unix-Passworts über /bin/passwd könnten Sie Ihren Benutzern gleich die Anweisungen für die Änderung ihres SMB-Passworts über den Befehl /usr/local/samba/bin/smbpasswd mitgeben. Dies ist sicher die einfachste Lösung, da so die Verantwortung an den Benutzer übergeben wird, die Passwörter synchron zu halten, wenn dies gewünscht ist. Dies könnte aber je nach Kaliber Ihrer Benutzer zu vermehrten Anrufen bei den Supportleuten führen. Es ist sehr leicht durcheinander zu bringen, welches Passwort zu welchem Logon gehört, wenn die Accounts nicht mehr synchron sind. Ein Benutzer kann sehr unnachgiebig in seinem Glauben sein, dass er das korrekte Passwort für seinen Account eingegeben hat! Sie müssen selber entscheiden, welche Lösung für Sie die beste ist.

Nachfolgend finden Sie eine Beispielsitzung, in der ich mein SMB-Passwort über den Befehl smbpasswd ändere. Ich habe Kommentare in spitzen Klammern eingefügt, die Ihnen erklären, was eingegeben werden muss. (Sie haben doch nicht wirklich gedacht, dass ich Ihnen mein Passwort verrate, oder?)

Windows-9x- und Windows-NT-Clients und verschlüsselte oder Klartextpasswörter

Ich möchte hier einen kurzen Hinweis zur Benutzung von Klartextpasswörtern und neueren Microsoft-Clients geben. Dieses und andere Themen, die für die Microsoft-32-Bit-Clients spezifisch sind, werden ausführlicher in Kapitel 14, »Windows 9x und Windows NT«, dargestellt.

Mit dem Service-Pack-3.0 für Windows NT 4.0 hat Microsoft den Standard geändert, so dass nur noch verschlüsselte Passwörter benutzt werden. Wenn Sie daher versuchen, sich mit einem nicht verschlüsselten Samba-Server zu verbinden, werden Sie folgende Fehlermeldung sehen:

Sie werden das gleiche Verhalten bei Windows-95-Clients feststellen, die das SMB Network Redirector Update (vrdrupd.exe) haben. Windows 95 wird Sie aber einfach weiterhin auffordern, ein Passwort einzugeben. Dieser Patch aktualisiert das System:

Es ist möglich, mit diesen Clients einen nicht verschlüsselten Samba-Server zu benutzen. Dafür müssen Sie nur einen Wert in der Windows-Systemregistrierung einstellen. Die Details für diese Lösung finden Sie in Kapitel 14.

Zugriffskontrollen

Samba bietet außer der Standardauthentifizierung über Benutzername/Passwort einige zusätzliche Optionen für die Kontrolle von Verbindungsanfragen. Über diese Optionen können Sie auf Basis der IP-Adresse des Clients die Verbindungen kontrollieren, was sehr hilfreich sein kann, wenn Ihr Netzwerk mit einem größeren LAN (oder dem Internet) verbunden ist.

hosts allow

Sie können den Parameter hosts allow benutzen, um eine Liste von Hosts zu definieren, die sich mit einer bestimmten Freigabe verbinden können. Wird der Parameter im Abschnitt [global] der smb.conf benutzt, gilt er unabhängig von den einzelnen Freigabeeinstellungen für alle Freigaben.

Der Parameter nimmt als Wert eine Liste von IP-Adressen in Dezimalschreibweise an, wobei die Adressen vollständige Adressen oder Subnetz-Netzwerkadressen sein können. So würde z.B. 192.168.1.73 einem bestimmten Host die Verbindung gestatten, während 192.168.1. Verbindungen von jedem Host im Class-C-Subnetz 192.168.1. zulassen würde. Sie können Hostnamen statt IP-Adressen benutzen, wenn Samba die Namen auflösen kann. Dies heißt gewöhnlich, dass Sie als Wert den Fully Qualified Domain Name (FQDN) angeben. Es ist ebenfalls möglich, über das Schlüsselwort EXCEPT Hosts auszuschließen. Standardmäßig werden Verbindungen von jeder IP-Adresse akzeptiert.

Hier sind einige Beispiele:

Diese Einstellung ermöglicht Verbindungen von zwei bestimmten Hosts, 192.168.1.73 und queso.my.net, sowie Verbindungen von jedem Host im Class-B-Subnetz 191.168. außer denen, die sich im Class-C-Subnetz 191.168.2. befinden.

Hier ist ein Beispiel, für das eine Kombination aus IP-Adresse und Subnetzmaske verwendet wird:

Dies ermöglicht Verbindungen von Hosts im Bereich 192.168.1.33 bis 192.168.1.63. Die Broadcast-Adresse für das Subnetz ist 192.168.1.64.

hosts deny

Der Parameter hosts deny ist die Ergänzung zum Parameter hosts allow. Er bietet die gleiche Funktion wie das Schlüsselwort EXCEPT innerhalb des Wertes von hosts allow, aber zu einem höheren Grad. Die Syntax ist die gleiche wie die von hosts allow. Standardmäßig werden keine Verbindungen abgelehnt:

hosts equiv und user hosts

Die nächsten zwei Parameter erwähne ich nur der Vollständigkeit halber und empfehle Ihnen, sie nicht zu benutzen, weil beide Methoden Möglichkeiten bieten, über die sich Benutzer mit Freigaben verbinden können und ohne Passwort authentifiziert werden. Dies kann ein ernsthaftes Sicherheitsloch in Ihrem Server darstellen. Seien Sie vorsichtig!

Über den Parameter hosts equiv können Sie den Standort einer Datei festlegen, die eine Liste von Hosts oder Benutzern, einen pro Zeile, enthält, die auf einen Dienst zugreifen können soll, ohne ein Passwort angeben zu müssen. Hier ein Beispiel:

Der boolesche Parameter user hosts veranlasst Samba, die Unix-Benutzerdatei ~/.rhosts zu verwenden, um spezielle Hosts zu bestimmen, die ohne Angabe eines Passworts auf Freigaben zugreifen können. Wie beim Parameter hosts equiv ist auch diese Option standardmäßig nicht aktiviert. Wollen Sie sie aktivieren, müssen Sie folgende Einträge in den Abschnitt [global] der smb.conf einfügen:

Verschiedenes

Die letzen zwei Parameter, die ich darstellen werde, haben einen Bezug zu Sicherheit, passen aber nicht zu den anderen bereits behandelten Themen.

map to guest

Ohne zu sehr ins Detail zu gehen, können Sie über den Parameter map to guest festlegen, was Samba tun soll, wenn eine Verbindungsanfrage ungültige Benutzerinformationen enthält (z.B. ein ungültiges Passwort). Es gibt drei mögliche Antworten:

• Never - Samba lehnt Verbindungsanfragen mit einem ungültigen Passwort ab. Dies ist die Standardeinstellung.
• Bad User - Wenn der Client ein ungültiges Passwort überträgt, wird die Verbindung abgelehnt, es sei denn, der Benutzername ist nicht bekannt. In diesem Fall wird die Verbindung akzeptiert, und der Benutzer wird in den guest account aufgenommen, der in smb.conf spezifiziert ist.
• Bad Password - Diese Einstellung führt dazu, dass Kombinationen aus falschem Benutzernamen und Passwort als Gastverbindungen akzeptiert werden. Der verbindende Benutzer merkt hiervon jedoch nichts und beschwert sich möglicherweise, dass er nicht auf seine Dateien zugreifen kann, weil er als guest account verbunden ist.

Ich empfehle Ihnen, die Standardeinstellungen bestehen zu lassen, es sei denn, Sie haben einen guten Grund, sie zu ändern. Wenn Ihnen selbst kein guter Grund einfällt, ist dies wahrscheinlich Grund genug, die Einstellungen in Ruhe zu lassen.

root directory

Dies ist ein weiterer Parameter, der nicht häufig benutzt wird. Er weist Samba an, ein chroot() zum angegebenen Verzeichnis auszuführen, ganz ähnlich wie es bei anonymen FTP-Verbindungen gehandhabt wird. Dies ist nicht unbedingt notwendig, da Samba standardmäßig Zugriff auf Dateien außerhalb der Freigabe ablehnt. Allerdings wird hiermit eine zusätzliche Sicherheitsebene eingefügt, aber sie müssen sicherstellen, dass sich alle notwendigen Skripte, Systemdateien und Binaries unterhalb des Root-Verzeichnisses befinden. Um das Standard-Root-Verzeichnis / zu überschreiben, können Sie ganz einfach das Verzeichnis Ihrer Wahl spezifizieren:

Abschließende Kommentare

Ich dachte, es wäre besser, mit diesem Punkt zu schließen, statt ihn innerhalb eines Kapitels zu vergraben. Wenn Sie durch eine Firewall von anderen Netzwerken getrennt sind und nicht wollen, dass Clients, die sich hinter der Firewall befinden, auf Ihre internen SMB-Server zugreifen können, sollten Sie die eingehenden Ports 137, 138 und 139 blockieren. Dies ist insbesondere dann wichtig, wenn Sie Benutzer haben, die gern ihre gesamte Festplatte freigeben, weil »es so praktisch ist«. Gerade Windows 95/98-Clients bieten dies per Voreinstellung an.

In Kapitel 7 kommen Sie zu den Details der Freigabenkonfiguration, so dass Ihre Benutzer tatsächlich auf ihre Dateien zugreifen können. Oh, ich habe vergessen, die kleine Geschichte zu beenden, die ich am Anfang dieses Kapitels begonnen habe, oder?

Nachdem ich etwas weniger als eine Stunde gebraucht hatte, trank ich den letzten Schluck von meinem Kaffee (der mittlerweile lauwarm geworden war) und machte mich auf den Weg zu meiner Chefin. Nachdem ich ihr meine Entscheidung für verschlüsselte Passwörter erklärt und einen Strategieplan - noch ein Dilbert-Wort - für die Änderung existierender Benutzerpasswörter in verschlüsselte Passwörter auf relativ harmlose Art und Weise definiert hatte, gratulierte sie mir zu einer weiteren gut erledigten Aufgabe. Dann unterschrieb sie einen Kaufvertrag für einen neuen Laptop, damit ich während meines von der Firma bezahlten Urlaubs mit ihr in Kontakt bleiben konnte. (Es könnte passieren!)

Zusammenfassung

Das SMB-Protokoll unterstützt zwei Modi für die Authentifizierung von Verbindungen. Samba unterstützt sowohl den Share-Modus (Freigabeebene) als auch den User-Modus (Benutzerebene). Zusätzlich bietet Samba zwei weitere Varianten der Authentifizierung auf Benutzerebene: Server-Modus und Domain-Modus.

Sie können für alle security-Optionen in Samba entweder Klartext- oder verschlüsselte Passwörter benutzen. Klartextpasswörter werden über die Standard-Unix-Account-Datenbank /etc/passwd (oder ihre Netzwerkentsprechung) authentifiziert. Die Passwortverschlüsselung dagegen verlangt, dass Samba eine separate Datei verwaltet, in der die Hashwerte der verschlüsselten Passwörter gespeichert werden.

Frage & Antwort

6. Brauche ich externe Libraries, um die Passwortverschlüsselung in Samba zu aktivieren?

1. Es ist richtig, dass der Administrator für ältere Versionen von Samba eine externe DES-Library besorgen musste, aber neuere Versionen von Samba benötigen diese nicht mehr. Der komplette benötigte Source-Code ist in der Samba-Distribution enthalten.

6. Kann ein Samba-Server so konfiguriert werden, dass er sowohl Klartext- als auch verschlüsselte Passwörter gleichzeitig unterstützen kann?

1. Nein. Ein einzelner Samba-Server kann nicht gleichzeitig Klartext- und verschlüsselte Passwörter für die Authentifizierung von Benutzern verwenden. Es gibt jedoch eine Methode über den Parameter netbios aliases, mit der Sie dies umgehen können. Die nötigen Funktionen für die Implementierung einer derartigen Lösung werden in Kapitel 10, »Automatisierung auf Server-Seite«, dargestellt.

6. Können einige Freigaben für den Share-Modus und andere auf dem gleichen Server für den User-Modus konfiguriert werden?

1. Nein. Der Samba-Parameter security ist eine [global]-Option.

Neue Begriffe

Klartextentsprechung eines Passworts - Diese wird generiert, wenn der benutzte Verschlüsselungsalgorithmus bei gleicher Eingabe immer den gleichen Byte-String erzeugt. Anders gesagt, ein Passwort wird immer zum gleichen Wert verschlüsselt. Kann ein Eindringling die verschlüsselte Version des Passworts abfangen, kann er erfolgreich am Challenge/Response-Authentifizierungsschema teilnehmen, das von SMB-Servern wie Samba und Windows NT benutzt wird.