Sie befinden sich hier: Themen. IT-Grundschutz. IT-Grundschutz-Kataloge. Dokument: M 5.82 Sicherer Einsatz von SAMBA - IT-Grundschutz-Kataloge - 10. EL Stand 2008
direkt zu der Navigation Servicebereich. direkt zu der Hauptnavigation. direkt zur Themennavigation. direkt zum Seiteninhalt.

M 5.82 Sicherer Einsatz von SAMBA

Verantwortlich für Initiierung: Leiter IT, Administrator

Verantwortlich für Umsetzung: Administrator

SAMBA ist ein freies Programmpaket für Unix-Betriebssysteme, das unter anderem Datei-, Druck- und Authentisierungsdienste über das SMB (Server Message Block) bzw. CIFS (Common Internet File System) Protokoll zur Verfügung stellt. Wichtigste Beispiele für SMB/CIFS-Clients sind sicherlich die Betriebssysteme der Microsoft Windows-Familie. Hierdurch ist es beispielsweise möglich, dass Windows 9x- oder Windows NT-Rechner direkt auf freigegebene Dateien auf einem Unix-Server zugreifen können. Ein Umweg über die Protokolle FTP oder NFS und die Installation zusätzlicher Software auf Client-Seite entfallen. In der aktuellen Version bildet SAMBA eine ganze Reihe der Funktionen eines Windows NT Servers nach, sodass ein Unix-System mit SAMBA in vielen Fällen einen solchen Server ersetzen kann.

Falls in der Behörde bzw. im Unternehmen SAMBA zum Einsatz kommt, sollten folgende Empfehlungen berücksichtigt werden:

In älteren Versionen von SAMBA sind Programmfehler entdeckt worden, die unter Umständen zu Sicherheitslücken führen können. Es sollte eine aktuellere Version verwendet werden, in der möglichst alle bekannten sicherheitsrelevanten Fehler beseitigt wurden.

Die Datei smb.conf ermöglicht eine äußerst flexible und detaillierte Konfiguration des SAMBA-Servers. Dies bedingt jedoch gleichzeitig eine gewisse Komplexität. Vor dem Einsatz von SAMBA sollte daher die Dokumentation gründlich gelesen werden. Die Konfiguration ist sorgfältig zu planen, zu dokumentieren und durch entsprechende Parameter in der Datei smb.conf umzusetzen. Eine umfangreiche Beschreibung der einzelnen Parameter kann beispielsweise durch den Befehl man smb.conf angezeigt werden. Bei Änderungen an der Konfiguration ist anhand der Dokumentation und durch entsprechende Tests sicherzustellen, dass die Konfigurationsänderung nicht zu unerwünschten Seiteneffekten führt.

Die folgenden Parameter sind in Bezug auf mögliche Sicherheitsrisiken besonders problematisch. Sie sollten daher nur nach gründlicher Prüfung aller möglichen Auswirkungen auf die IT-Sicherheit des Servers verwendet werden:

[...] command
add user script
delete user script
fake oplocks
ldap [...]
panic action
passwd program

 

postexec
preexec / exec
root postexec
root preexec
smbrun
unix password sync

 

Mit Hilfe des Programms testparm kann geprüft werden, ob die Einstellungen in der Datei smb.conf zulässig sind.

Selbstverständlich kann hierdurch keine Aussage darüber gemacht werden, ob die Einstellungen den gewünschten Effekt oder sicherheitsrelevante Auswirkungen haben. Die Erstellung und Wartung der Datei smb.conf kann auch durch graphische Oberflächen unterstützt werden, beispielsweise durch das Samba Web Administration Tool (SWAT), das im Lieferumfang des SAMBA-Pakets enthalten ist.

SAMBA bietet ab der Version 3 fünf verschiedene Verfahren zur Authentisierung von Clients. Bei der Einstellung security = user prüft der SAMBA-Server, ob der Client eine gültige Kombination aus Benutzer-Kennung und Passwort übermittelt. Bei security = domain überlässt er diese Prüfung einem oder mehreren anderen SMB/CIFS-Servern, die über den Parameter password server spezifiziert werden und denen er vertraut. Dagegen wird bei der Verwendung von security = share lediglich eine einfache Passwortprüfung durchgeführt, der Client muss keine Benutzer-Kennung übermitteln. Dieses Verfahren ist erheblich schwächer als die Authentisierung über Benutzer-Kennung und Passwort und sollte nur angewandt werden, wenn die Daten auf dem SAMBA-Server nicht geschützt werden müssen. Als Beispiel sei ein Server mit schreibgeschütztem Datenträger und öffentlich zugänglichen Daten genannt. Zweckmäßigerweise wird hier vollständig auf eine Authentisierung verzichtet, was am einfachsten über die Einstellung security = share realisierbar ist. Ähnlich wie beim Parameter security = domain authentisiert bei security = server ein anderer SMB/CIFS-Server die Benutzer. Der Parameter security = server bietet aber nur wenige Vorteile. Daher sollte in den meisten Fällen security = domain verwendet werden. Seit der Version 3 kann mit security = ads Samba als Active Directory Memberserver betrieben werden, bei dem die Authentisierung über Kerberos 5 stattfindet.

Bei der Authentisierung von Clients können Klartext-Passwörter oder verschlüsselte Passwörter verwendet werden. Da Klartext-Passwörter mit Hilfe von frei zugänglichen Tools beim Transport über das Netz leicht abgehört werden können, sollten grundsätzlich nur verschlüsselte Passwörter zum Einsatz kommen. Auf Seite der Clients werden verschlüsselte Passwörter z. B. von Windows 95 mit installiertem SMB-Update, Windows 98, Windows NT 4.0 und Windows 2000 unterstützt. In der Datei smb.conf des SAMBA-Servers werden verschlüsselte Passwörter durch den Parameter encrypt passwords = yes aktiviert. Die Nutzung der verschlüsselten Passwörter ist ab der Samba-Version 3 standardmäßig eingeschaltet. Diese Einstellung sollte nach Möglichkeit nicht deaktiviert werden. Anders als Klartext-Passwörter kann ein SAMBA-Server verschlüsselte Passwörter nicht mit Hilfe der Authentisierungsmechanismen des darunter liegenden Unix-Betriebssystems (die z. B. auf /etc/passwd oder /etc/shadow zurückgreifen) überprüfen. Daher müssen die zusätzlichen Hashwerte für die Passwörter separat angelegt und gespeichert werden. Dies kann entweder wie bei älteren Samba-Versionen in der "smbpasswd"-Datei, die durch den Parameter smb passwd file in der smb.conf festgelegt wird, in einer Samba-Datenbank (tdbsam) oder in einem zentralen LDAP-Verzeichnisdienst erfolgen. Je nachdem, welche Passwort-Speicherung durch den Parameter "passdb backend" gewählt wurde, muss die entsprechende Datei vor unberechtigtem Zugriff sorgfältig geschützt werden.

Im Falle von LDAP muss durch entsprechende Access-Controll-Lists (ACLs) der Zugriff für normale Benutzer beschränkt werden.

Die Rechte eines Benutzers beim Zugriff auf Verzeichnisse und Dateien über SAMBA ergeben sich einerseits aus den Einstellungen in der Datei smb.conf und andererseits aus den Zugriffsrechten des Dateisystems, auf dem die freigegebenen Daten vorgehalten werden. Auch hier ist durch sorgfältige Konfiguration sicherzustellen, dass Zugriffsrechte in konsistenter Weise vergeben werden. Anders als bei Windows NT Servern mit NTFS-Laufwerken ist es beim Einsatz von SAMBA nicht immer sinnvoll, die Zugriffsrechte ausschließlich über das Dateisystem zu vergeben. Der Grund ist, dass gängige Unix-Dateisysteme ein anderes Sicherheitsmodell (Permissions und Ownership) implementieren als NTFS. Abhängig vom konkreten Anwendungsfall ist daher zu prüfen, ob bestimmte übergeordnete Zugriffsbeschränkungen besser über die Datei smb.conf konfiguriert werden können. Hierzu wird auf die Parameter (in)valid users und read/write list verwiesen.

Die folgenden Parameter führen möglicherweise dazu, dass Zugriffsbeschränkungen umgangen werden können:

Bei Verwendung dieser Parameter sollten die möglichen Auswirkungen auf die Sicherheit daher genau geprüft werden.

Symbolische Links in freigegebenen Verzeichnissen können dazu führen, dass Clients unberechtigten Zugriff auf Dateien außerhalb des freigegebenen Bereiches erhalten. Es wird empfohlen, dies durch den Parameter wide links = no zu verhindern. Zu beachten ist jedoch, dass dieser Parameter zu einer Verminderung des Durchsatzes führen kann, da die zusätzlich erforderlichen Prüfungen Rechenzeit beanspruchen. Als Alternative zur Prüfung symbolischer Links kann auch überlegt werden, den Parameter root directory = <pfad> zu verwenden. Zugriffe auf Verzeichnisse und Dateien außerhalb von <pfad> werden damit ausgeschlossen. Dabei müssen jedoch alle zur Ausführung von SAMBA erforderlichen Dateien in Unterverzeichnisse von <pfad> kopiert werden, unter anderem auch die Passwortdateien.

Auf dem Server können über die Freigabe [netlogon] unter anderem Anmeldeskripten für Clients bereitgestellt werden. Benutzer sollten keinesfalls in der Lage sein, Dateien in dieser Freigabe zu modifizieren. Es wird empfohlen, writeable = no und guest ok = no bzw. äquivalente Parameter für diese Freigabe zu setzen.

Die folgenden Parameter sind voreingestellt und sollten nicht verändert werden, da anderenfalls der ordnungsgemäße und sichere Betrieb beeinträchtigt werden kann:

Wenn Dienste eines SAMBA-Servers über größere Netze genutzt werden, die nicht vollständig der eigenen Kontrolle unterliegen, sollte überlegt werden, die Kommunikationsverbindungen durch den Einsatz kryptographischer Verfahren zu schützen. Dies bietet sich insbesondere an, wenn aus zwingenden Gründen Klartext-Passwörter verwendet werden müssen. Die Absicherung kann durch entsprechende Hardware- oder Software-Komponenten erfolgen. Besondere Unterstützung bietet SAMBA für den Einsatz von SSL an. Hierzu muss auf dem SAMBA-Server ein SSL-Programmpaket, in der Regel das freie SSLeay, installiert werden. Client-seitig ist eine SSL-Proxy-Software erforderlich, die für Windows NT- und Unix-Clients kostenlos verfügbar ist. Windows 9x-Clients können den SSL-Proxy eines Windows NT- oder Unix-Clients in ihrem Subnetz mitbenutzen. Erste Schritte der Konfiguration stellen - falls noch nicht vorhanden - die Einrichtung einer Certification Authority (CA) und die Generierung von Schlüsselpaaren und Zertifikaten für den Server und die Clients dar. Die entsprechenden Vorgehensweisen sind in der Dokumentation von SSLeay erläutert. Um SSL auf dem SAMBA-Server zu aktivieren, sind in der Datei smb.conf mindestens die Parameter ssl = yes und ssl server cert = <pfad> zu setzen. Falls der private Schlüssel des Servers nicht in der gleichen Datei wie das Server-Zertifikat abgelegt ist, wird außerdem der Parameter ssl server key = <pfad> benötigt. Es wird empfohlen, die Überprüfung von Server- und Client-Zertifikaten zu aktivieren. Dies erfordert die Parameter ssl require clientcert = yes und ssl require servercert = yes, sowie ssl CA certDir = <pfad> oder ssl CA certFile = <pfad>. Für jeden Client, auf dem ein SSL-Proxy zum Einsatz kommt, sind das Schlüsselpaar und das Zertifikat dieses Clients in ein geschütztes Verzeichnis zu kopieren. Die Pfade dieser Dateien und der Name des SAMBA-Servers werden dem SSL-Proxy beim Start als Parameter übergeben. Anschließend können die Clients die gewünschten SMB/CIFS-Dienste vom jeweiligen SSL-Proxy abrufen. Der Proxy leitet die Anfragen - geschützt durch das SSL-Protokoll - an den eigentlichen SAMBA-Server weiter. Deshalb werden die Dienste aus Sicht der Clients scheinbar vom SSL-Proxy anstatt vom SAMBA-Server bereitgestellt.

Falls aus zwingenden Gründen Klartext-Passwörter verwendet werden müssen, kann dies auf Clients mit den Betriebssystemen Windows 9x, Windows NT 4.0 oder Windows 2000 durch bestimmte Registry-Einträge erzwungen werden. Erforderlich ist dies beispielsweise bei Windows NT 4.0 mit Service Pack 3 oder höher, da diese Betriebssystemversion ohne Anpassung der Registry die Übertragung von Klartext-Passworten auch dann verweigert, wenn der Server keine verschlüsselten Passwörter unterstützt. Der Client kann sich anderenfalls also nicht erfolgreich am Server anmelden.

Zu beachten ist jedoch, dass bei Verwendung von Klartext-Passwörtern auf jeden Fall zusätzliche Schutzmaßnahmen für die Kommunikationsverbindungen (z. B. VPN oder SSL) erforderlich sind.

Sogar mit erfolgter Registry-Anpassung ist die Anmeldung eines Windows NT 4.0 Clients an einem Server mit Klartext-Passwörtern problematisch. Der Benutzer wird in diesem Fall nämlich bei jeder Verbindungsanfrage erneut nach dem Passwort gefragt, was bei Nutzung verschiedener Ressourcen auf dem Server sehr störend sein kann. Dies ist ein weiterer Grund, auf die Verwendung von Klartext-Passwörtern möglichst vollständig zu verzichten.

Weitere Empfehlungen zur sicheren Konfiguration der Clients finden sich im Baustein B 3.201 Allgemeiner Client und in den betriebssystemspezifischen Bausteinen.

Ergänzende Kontrollfragen: