|
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:
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
|
News
Dokumente