Navigation

 News
 Blog
 Dokumente
    - Upload
     Linux
    - Windows
    - IT-Security
    - Kryptologie
    - Programmierung
    - Netzwerktechnik
    - Allgemeines
 Projekte
 Hacks
 Download
 Forum
 Partner
 Banner
 Links
 Changelog
 Impressum


Willkommen 54.225.48.56

Neuesten 3 Dokus:


Partner:

www.wissenundpraxis.com
www.saveyour.homelinux.org
www.sco-world.de
www.hakin9.org/de

schon Partner...?



zurück

LAN-Server(NFS und Samba) Grundlagen

Hallo,

und Willkommen zum "Tutorial LAN-Server(NFS und Samba) Grundlagen". Ich schreibe dieses Tutorial, um zu zeigen wie einfach es sein kann sich selbst einen NFS- oder Samba-Server einzurichten.
Dieses Tutorial beschreibt in erster Linie die Konfiguration von Netzwerkdiensten, die innerhalb von lokalen Netzwerken zur Verfügung gestellt werden. Es richtet sich in erster Linie an die Distributionen Suse Linux, Fedora Core sowie Red Hat. Trotz allem sollte dies auch auf andere Distributionen übertragbar sein. Ich habe das Tutorial in drei Abschnitte geteilt.

Teil 1: NFS
Teil 2: Samba
Teil 3: Infos

Um alles etwas zu vereinfachen wird immer davon ausgegangen, dass der Server unter den Namen "server" erreichbar ist und sich in der Domain "domaine" befindet. Alle Rechner haben die Netz-ID 192.168.1.0 und befinden sich auch in der Domian "domaine". Der Client ist immer der Rechner "bill" mit der IP 192.168.1.100. Die Server IP ist 192.168.1.1.

Teil 1 NFS-Server (Linux Verzeichnisse)

NFS steht für Network File System und ermöglicht es, dass ein Rechner seine lokalen Verzeichnisse einem anderen Rechner via Netzwerk zur Verfügung stellen kann.
Bevor man den NFS-Server einrichten kann, muss man die entsprechenden Pakete installieren. Diese heißen üblicherweise "nfs-util" und "portmap". Die Konfiguration erfolgt durch drei Dateien: /etc/exports, /etc/hosts.allow und /etc/hosts.deny.

Die zentrale Konfiguration für NFS ist /etc/exports. Diese Datei steuert, welcher Rechner auf welche Verzeichnisse zugreifen darf ( read-only oder read-write). Die Rechner können entweder durch Namen oder IP-Adresse angegeben werden. Weiterhin darf auch das Jokerzeichen "*" verwendet werden (z.B. *.domaine).
Das folgende Beispiel veranschaulicht die Verwendung von /etc/exports
Code:

# /etc/exports
# rw = read write, ro = read only
# sync = Synchron, async = Asynchron
/public 192.168.1.*(ro,async) *.domaine(ro,async)
/home/bill bill.domaine(rw,async)

Dieses kleine Beispiel gibt an, dass alle Clients Lesezugriffe auf /public haben wenn sie mit dem Namen *.domaine oder der IP-Adresse 192.168.1.* zugreifen. Darüber hinaus hat der Rechner bill.domaine, Lese- und Schreibzugriffe auf /home/bill aber nur Leserzugriffe auf /public.
sync gibt an, dass der NFS-Server erst nach Änderungen an einer Datei die Bestätigung sendet, wenn diese tatsächlich gespeichert wird. Per default gilt sync. Der Vorteil an async ist, dass es bis zu 10-mal schneller ist als sync, aber weniger sicher.
Falls der NFS-Server bereits am laufen ist, werden die Änderungen in /etc/exports erst durch folgenden Befehl wirksam: exportfs -a

Achtung:
IP-Adressen in /etc/exports habe nur dann Gültigkeit, wenn die dazu gehörigen Rechnernamen nicht bekannt sind (entweder durch einen Nameserver oder /etc/hosts).

Zugriffe:
Diese werden durch die Dateien /etc/hosts.allow und /etc/hosts.deny gesteuert. Diese Dateien geben an, welcher Rechner überhaupt auf den NFS-Server zugreifen darf. In der Hierarchie des Zugriffschutzes stehen diese beiden Dateien an erster Stelle. Wobei /etc/hosts.allow zuerst ausgewertet wird. Wird einem dort nicht explizit erlaubt auf den Dienst zuzugreifen, so wird /etc/hosts.deny ausgewertet. Wenn einem auch dort nicht der Zugriff explizit verweigert wird, so wird der Zugang gewährt. Das heißt, wenn einem Rechner in /etc/exports der Zugriff gewährt wird, kann ihm dieser dennoch in /etc/hosts.deny verwährt sein. Somit hat er keinen Zugriff auf den NFS-Server. /etc/exports ist nur für die Rechner relevant die diesen überhaupt kontaktieren können. Ein Beispiel:

Code:
# /etc/hosts.allow
# bestimmte Dienste erlauben
ALL : localhost : ALLOW
portmap : 192.168.1.0/255.255.255.0 *.domaine : ALLOW


# /etc/hosts.deny
ALL : ALL : spawn (echo Attempt from %h %a to %d at $(date) \
>> /var/log/xinet_deny.log)

Erklärung:
Vom lokalen Rechner werden alle Zugriffe auf alle Dienste erlaubt. Weiterhin werden alle Zugriffe auf den NFS-Server(portmap) aus dem lokalen Netz 192.168.1.* und der aller Rechner aus der Domain *.domaine erlaubt. Alle anderen werden in /etc/host.deny verweigert und gleichzeitig wird der Versuch durch die spawn-Anweisung protokolliert.

Jeder Eintrag besteht aus drei Teilen, die durch Doppelpunkte getrennt sind. Der erste Teil gibt den Dienst an, der zweite die IP-Adresse bzw. den Netzwerknamen und der dritte Teil gibt die resultierende Aktion (weitere Infos mit man 5 hosts_access) an.

Hinweis:
Diese Dateien werden nur dann ausgewertet, wenn auch der Dienst xinetd (früher inetd) läuft. Man kann dies zum Beispiel feststellen in dem man dmesg | grep inetd oder xinetd eingibt. Alternativ geht auch /etc/init.d/xinetd status. Läuft xinetd nicht, so sollte er mit mit /etc/init.d/xinetd start aktiviert werden.
Man kann natürlich auch mit

Code:
ps -ef | grep xinetd
feststellen ob xinetd läuft.

Code:
Start:
Zum manuellen Start müssen folgende Dienste gestartet werden:
/etc/init.d/portmap start
/etc/init.d/nfslock start
/etc/init.d/nfs start # unter SuSE nfsserver

# unter SuSE muss nfs durch nfsserver ersetzt werden

Automatischer Start:
chkconfig portmap 35 nfslock 35 nfs 35

oder

chkconfig --add portmap
chkconfig --level 35 portmap on
chkconfig --add nfslock
chkconfig --level 35 nfslock on
chkconfig --add nfs
chkconfig --level 35 nfs on

Code:
NFS-Status:

Anzeigen der Dämonen für den Betrieb des Rechners als NFS-Server:
Code:
rpcinfo -p
rpcinfo -e <entfernter NFS-Server>


Client Zugriffe auf den NFS-Server anzeigen:

showmount -a

NFS-Client (Zugriff auf Linux-Netzwerkverzeichnisse)
Um einen Zugriff auf ein NFS-Verzeichnis zu haben verwendet man folgenden Befehl:

Code:
Code:
mount -t nfs server:/public /nfsdata

Damit wird das Verzeichnis /public des Rechners "server" auf dem lokalen Rechner unter dem Verzeichnis /nfsdata verfügbar. (/nfsdata muss vor dem mount Befehl natürlich vorhanden sein!). Statt des Rechnernamens kann man auch die IP des NFS-Servers angeben.
Um NFS-Verzeichnisse schon während des Startvorgangs zu mounten, ist eine Ergänzung in /etc/fstab erforderlich:

Code:
# /etc/fstab
server:/public /nfsdata nfs user,exec,bg 0 0

Damit wird das Verzeichnis /public des Rechners "server" auf dem lokalen Rechner unter dem Verzeichnis /nfsdata verfügbar. Aber durch die NFS-spezifische Option bg wird der mount- Vorgang im Hintergrund ausgeführt. Dies ist praktisch wenn das Netzwerkverzeichnis nicht sofort zur Verfügung steht.

Teil 2 Samba

Samba ist eine Programmsammlung, welches bei der Integration von Windows- und Unix-/Linux-Rechnern hilft.
Der Name Samba wurde vom Protokoll SMB abgeleitet, welches wiederum für Server Message Block steht. Dieser Teil zeigt lediglich nur die Grundlagen von Samba, für fortgeschrittene Funktionen wie eine Authentifizierung via LDAP etc. ist folgende Website zu empfehlen:
http://www.samba.org/

Konfiguration:
Als zentrale Konfigurationsdatei dient /etc/samba/smb.conf. Eine einfache Freigabe könnte folgendermaßen aussehen:

Code:
; /etc/samba/smb.conf
[global]
workgroup = Arbeitsgruppe
security = share

[public]
path = /public
guest ok = yes
guest only = yes

Erklärung:
Damit wird der Arbeitsgruppe "Arbeitsgruppe" das Verzeichnis public angeboten. Dazu muss natürlich das Verzeichnis /public vorhanden sein. Der Zugriff ist ohne Passwort möglich, das liegt daran, dass das Sicherheitslevel dort so gesetzt wurde (security = share) und das Gast-Zugriffe erlaubt werden (guest ok = yes; guest only = yes erlaubt nur Gastzugriffe). Dabei dürfen keine Dateien verändert werden (per default immer read only = yes).
Start:
Die Samba-Server Funktionen werden von den Dämonen nmbd und smbd zur Verfügung gestellt.

nmbd --> dient zur internen Verwaltung und als Nameserver. Weiterhin stellt er die Browsing-Funktion bereit. Kann sogar als WINS-Server fungieren.

smbd --> stellt die Schnittstelle für die Clients dar und stellt diesen den Zugang zu Verzeichnissen, Druckern und zur aktuellen Browsing-Liste zur Verfügung.

Code:
manueller Start:

/etc/init.d/smb start # Bei Red Hat/Fedora Core reicht dieses Init-V-Script
/etc/init.d/nmb start # SUSE benötigt das auch noch

automatischer Start:

entweder:
chkconfig --add smb
chkconfig --level 35 smb on

oder
chkconfig smb 35 nmb 35


Test:
Zum Testen ob auch alles so funktioniert wie man es möchte, connectet man selbst vom Server auf den Server. Bei der Minimalkonfiguration oben, ist kein Passwort erforderlich, somit gibt man einfach Return(auf die Taste Return klicken) ein.

Code:
smbclient -L loccalhost

Wenn man nun größere Änderungen an smb.conf vorgenommen hat, sollte man die Datei erstmal nach syntaktischen Fehlern überprüfen. Hierzu dient der Befehl testparm.

Code:
server:~/bin # testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[public]"
Processing section "[printers]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

# Global parameters
[global]
workgroup = Arbeitsgruppe
...


Tipp:
Ab Samba 3.0 ist es möglich mit dem Schalter v (testparm -v) sich die Defaulteinstellungen von den smb.conf-Optionen geben zu lassen.

Status:
Mit smbstatus kann man den aktuellen Status von Samba feststellen, zusätzlich aller aktiven Verbindungen.

Protokollierung:
Samba protokolliert Status- und Fehlermeldungen üblicherweise in die Dateien /var/log/samba/log.smbd und log.nmbd
.
Sicherheitsstufen:
Samba kennt 5 verschiedene Sicherheitsstufen, diese werden in der smb.conf mit security angegeben.

security = share: 	Samba arbeitet mit der Share-Level-Sicherheit. Mit dieser Einstellung
			verlangt Samba beim Verbindungsaufbau vorerst kein Passwort und
			Login-Namen. Erst beim Zugriff auf Verzeichnisse oder Drucker ist eine
			Identifizierung erforderlich.

security = user: Bei dieser Einstellung müssen sich die Clients mit Name und Passwort anmelden, erst dann stehen die Freigaben zur Verfügung.

security = server: Samba delegiert die Authentifizierung an einen anderen Rechner (dieser wird mit password server = name bestimmt).

security = domain: Wie security = server, allerdings muss es sich beim externen Rechner um einen PDC handeln. Dabei muss der Samba-Server Teil der Domäne sein.

security = ads: Wie security = server es muss sich beim externen Rechner nur um einen Active-Directory-Server handeln.

Benutzerverwaltung

Der Zugriff auf Verzeichnisse unter Samba erfolgt auf Basis der Linux-Benutzerverwaltung, wenn man die Authentifizierung nicht auf einen anderen Rechner delegiert hat. So werden der Windows-Login-Name einem Linux-Login-Namen zugeordnet.

Mit diesem kleinen Beispiel wird die Zuordnung veranschaulicht:
Dieses Beispiel gibt das Verzeichnis /public/bill frei unter dem Namen bill-data für den Benutzer Bill.

Code:
[global]
workgroup = Arbeitsgruppe
security = user
encrypt passwords = yes
[bill-data]
path = /public/bill
username = bill
writeable = true


"bill" muss ein gültiger Benutzer auf dem Linux-System sein (dabei ist auf Groß/Klein-Schreibung zu achten!). Wichtig ist, dass das Verzeichnis /public/bill existiert und dieser der Besitzer des Verzeichnisses ist bzw. er die Rechte hat Daten bearbeiten zu können). Durch username = bill gelten für den Benutzer bill, der von irgendeinen Windows-Client aus auf test zugreift, alle Unix-Regeln der Zugriffsverwaltung. Die Option encrypt passwords = yes bewirkt, dass Passwörter verschlüsselt werden, dies gilt ab Samba 3.0 per Default. Bei Windows-Clients die älter als 98 sind (z.B 95) muss diese Option explizit auf no gestellt werden.


Um auch so lange Benutzernamen wie unter Windows zu ermöglichen, gibt es die Möglichkeit eine Zuordnung zwischen den Benutzernamen von Windows und Linux zu erstellen, welches über eine Datei erfolgt. Standardmäßig gibt es schon eine Datei in /etc/samba mit dem Namen smbusers, die diese Aufgabe übernimmt. Man kann aber auch eine neue Datei erstellen, welche dann diese Aufgabe übernimmt. Der Name dieser Datei wird in smb.conf, durch die Option username map angegeben:

Code:
# etc/samba/smb.conf
[global]
username map = /etc/samba/smbusers


Die Syntax der Datei ist ganz einfach. Erst kommt der Linux-Name und dann das Zeichen "=" gefolgt vom Windows-Namen.

Code:
# /etc/samba/smbusers
#root = administrator
bill = "Bill Newman"
#nobody = guest pcguest smbgues


Zum Schluss muss "bill" sich identifizieren, um auf /public/bill zugreifen zu können. Damit "bill" sein Samba-Verzeichnis nutzen kann, muss man in /etc/samba/smbpasswd (üblicher Ort für die Passwort-Kontrolle von Samba) einen neuen Eintrag für "bill" vorsehen. Dabei hilft einem das Kommando smbpasswd.

Code:
server:~/bin # smbpasswd -a bill
New SMB password: *********
Retype New SMB password: *********
Added user bill.
Password changed for user bill.


Verzeichnisse freigeben

Share-Level-Sicherheit

Zu beginn dieses Teiles wurde schon ein einfaches Beispiel für eine Share-Level-Sicherheit gegeben. Dabei erfolgte der Zugriff ohne Login- und Passwort-Abfrage:

Code:
# /etc/samba/smb.conf (Share Level, Teil 1)
[global]
workgroup = Arbeitsgruppe
encrypt passwords = yes
security = share

[public]
path = /public
guest ok = yes
guest only = yes


Durch die Optionen guest ok und guest only wird erreicht, dass von jedem der Zugriff auf das Verzeichnis /public ohne Passwort erlaubt ist und das der Zugriff immer dem Default-Account für guest zugeordnet wird. Normalerweise ist das der Benutzer nobody.
Welches das Default-Account für guest ist, lässt sich mit folgendem Befehl feststellen:

Code:
server:~/bin # testparm -v -s | grep "guest account"
guest account = nobody


Man kann, falls es notwendig ist, mit guest account = username guest auch einen anderen Account zuordnen.

Verzeichnis mit Passwort schützen:

Das folgende ergänzende Beispiel zeigt ein Passwortgeschütztes Verzeichnis. Dazu wird ein Linux-Account angelegt(hier "test"), der mit smbpasswd ein Passwort zugewiesen bekommt. Wenn nun ein Client auf das Verzeichnis zugreift, kann dieser einen beliebigen Benutzer angeben, aber das Passwort von "test" muss stimmen. Dieses Passwort schützt nun den Zugang zum Verzeichnis protect. Die Option browseable bewirkt, dass das Verzeichnis auf dem Client-Rechner sichtbar ist, noch bevor ein Zugang gewährt wird.

Code:
# /etc/samba/smb.conf (Share Level, Teil 2)
[pwprotection]
path = /public/protect
user = test
writeable = true
browseable = true


User-Level-Sicherheit

Home-Verzeichnisse:
Die User-Level-Sicherheit entspricht eher dem Linux-Sicherheitsmodell.
Hier ein Beispiel für eine User-Level-Sicherheit Freigabe:

Code:
# /etc/samba/smb.conf (Teil 1)
[global]
workgroup = Arbeitsgruppe
security = user
username map = /etc/samba/smbusers
encrypt passwords = yes
map to guest = bad user
guest account = nobody

[homes]
writeable = true
browseable = false


Die beiden guest Einstellungen bewirken, dass alle Benutzer die in /etc/samba/smbusers keine Zuordnung finden, dem Account nobody zugeordnet werden. Somit kann jeder mit dem Samba-Server Kontakt aufnehmen. Ein Zugriff auf Verzeichnisse ist aber nur dann möglich, wenn bei der Freigabe auch guest ok = yes gegeben ist.
Man sollte wenn es geht die Option map to guest = bad user aus Gründen der Sicherheit auf map to guest = never stellen.
Die Gruppe [homes] hat hier eine Sonderrolle, da sie bewirkt, dass das Home-Verzeichnis des momentan aktiven Benutzers unter dessen Namen sichtbar wird. Falls man nicht möchte, dass die Benutzer auf das Home-Verzeichnis, sondern auf ein anderes Verzeichnis zugreifen sollen, kann man das mit dem Schlüsselwort path festlegen. Hier wird statt des in /etc/passwd eingestellten Verzeichnisses /private/samba/name verwendet:
path = path=/data/sambahome/%u
Eine Freigabe für alle würde so aussehen:

Code:
[forall]
path = /public
guest ok = yes
read only = yes


Gruppenverzeichnisse

Das Home Verzeichis ist immer nur für einen bestimmten Benutzer zugänglich. Es wäre aber manchmal auch sinnvoll einer ganzen Gruppe eine Freigabe zuzuordnen. Dazu muss man zuerst den Linux-Account dieser Mitglieder, einer Gruppe zuordnen. Anschließend kann man in smb.conf ein Verzeichnis definieren, welches alle Mitglieder der Gruppe nutzen. Um sich etwas Schreibarbeit zu ersparen, kann man auch mit @name alle Mitglieder dieser Gruppe ansprechen.

Code:
# /etc/samba/smb.conf (Teil 2)
[gamersdata]
path = /data/gamers
writeable = true
browseable = true
user = @gamers
create mask = 0770
directory mask = 0770


Die zwei mask-Optionen stellen sicher, dass auch von Gruppenmitgliedern neu erstellte Dateien und Verzeichnisse von allen Gruppenmitgliedern bearbeitet werden können.

Client:

Um auf einen Samba-Server zu connecten gibt man einfach beim entsprechenden Dateimanger folgendes ein:
Konqueror: smb:/
Nautilus: smb:///


Über die Shell kommt das Kommando smbclient zur Hilfe.
Beispiel: smbclient -L server

Weiter Schalter sind:
W workgroupname
U benutzername
Sobald man zum externen Rechner eine Verbindung aufgebaut hat, kann man wie mit ftp sich mit ls Verzeichnisse ansehen, mit get Dateien auf den lokalen Rechner übertragen und mit put Daten auf dem externen Rechner speichern. Weitere Kommandos kann man sich mit help bzw. ? anzeigen lassen.
Noch komfortabler ist das Mounten:

Code:
mount -t smbfs -o username=name,password=pw //server/public /data

Ohne Angabe eines Passworts, also password= gilt eine leere Zeichenkette als Passwort.

Teil 3 Infos:

http://www.samba.org
http://mysite.verizon.net/res0yizl/id12.html

Weiterführende Literatur:
Addison-Wesley Verlag "Samba 3 - das offizielle Handbuch"
Addison-Wesley Verlag "Linux Installation, Konfiguration, Anwendung"
Addison-Wesley Verlag "Unix/Linux Survival Guide"
Oreilly Verlag "Samba kurz & gut"

Quellenverzeichnis:
Addison-Wesley Verlag "Linux Installation, Konfiguration, Anwendung"
Oreilly Verlag "Samba kurz & gut"
http://www.samba.org

Bei weiteren Fragen, Kritik oder Anregungen zum Artikel stehe ich natürlich jederzeit zur Verfügung.
Einfach eine E-Mail an duddits-[at]-remoteshell-security.com. Ich versuche diese dann so schnell als möglich zu beantworten.

Nach oben


Copyright © 2006-2022 Daniel Baier: Alle Rechte vorbehalten