ICT-Infrastruktur für Bildungsaufgaben

(1)

ICT-Infrastruktur für Bildungsaufgaben

6. Netzwerk - Services

Thomas Leitner <thomas.leitner@univie.ac.at>

Fakultät für Mathematik, Universität Wien Sommersemester 2013

Letzte Änderung: 2013-09-20 20:46:17 +0200

Inhalt

Firewall mit iptables Remote Login via SSH

Netzwerkdateisysteme (NFS, CIFS) Webserver mit Apache

Firewall

Eine Firewall (auch Paketfilter genannt) dient zur Sicherung eines ganzen Netzwerks (externe Firewall) oder eines einzelnen Computers vor unerwünschten Netzwerkzugriffen.

Wenn ein einzelner Computer geschützt werden soll, so wird die Firewall-Software auf dem Computer selbst installiert und der Benutzer muss sicherstellen, dass Schadprogramme die Firewall nicht manipulieren.

Ein externe Firewall hat den Vorteil, dass sie vor Manipulationen besser geschützt ist und bietet, weil sie meist durch eine dezidierte Hardware implementiert ist, meist besseren Schutz.

Es gibt verschiedene Arten, wie eine Firewall Netzwerkzugriffe unterbinden kann, z.B. Sperren von bestimmten IP-Adressen (Internetschicht) oder Sperren von bestimmten Ports oder anderen Informationen (Transportschicht).

Firewall in Linux

Der Linux-Kernel hat eingebaute Mechanismen für eine Firewall. Das heißt, außer einem Programm, das weiß, wie man die im Kernel vorhandenen Regeln manipuliert, braucht man nichts.

Die Implementierung der Paketfilter-Mechanismen direkt im Kernel hat zudem den Vorteil, dass die IP-Pakete sehr schnell verarbeitet werden können.

Der derzeit im Linux-Kernel (seit 2001 und der Kernelversion 2.4) verwendete Paketfilter heißt iptables. Der erste Paketfilter hieß ipfw, basiert auf BSD-Code und wurde 1994 implementiert. Mitte 1998 wurde dann für Linux 2.2 ein neuer Paketfilter namens ipchains eingeführt, der dann von iptables abgelöst wurde.

Ein großer Vorteil von iptables ist die Erweiterbarkeit. Ein Kernel-Modul kann Filtermethoden zur Verfügung stellen (z.B. für das TCP- Protokoll), die dann von iptables benutzt werden können.

Dokumentation:

man iptables

, Linux 2.4 Packet Filtering HOWTO.

Firewall in Linux - iptables 1

Im Kernel sind mehrere Tabellen hinterlegt, die verändert werden können:

filter: Die Default-Tabelle, in der man allgemeine Filter hinterlegen kann (mit dieser werden wir uns beschäftigen).

nat: Eine spezielle Tabelle für NAT (network address translation).

mangle: Eine spezielle Tabelle für Veränderungen an Paketen.

In der Default-Tabelle filter gibt es immer die folgenden drei Filter-Ketten, in denen man Regeln hinterlegen kann:

INPUT: Für Pakete, die lokal zugestellt werden sollen.

FORWARD: Für Pakete, die der Computer weiterleiten soll.

OUTPUT: Für Pakete, die lokal generiert werden.

Zusätzlich zu den genannten Ketten kann man auch beliebige andere Ketten anlegen, was zusätzliche Flexibilität bringt.

Da die Tabellen im gesicherten Speicher des Kernels hinterlegt sind, muss man die Regeln beim Start des Systems in den Kernel laden (die Befehle

iptables-save

und

iptables-restore

helfen dabei).

Firewall in Linux - iptables 2

In einer Filter-Kette werden die eigentlichen Regeln hinterlegt, die der Reihe nach durchgearbeitet werden.

Eine Regel besteht dabei aus einer oder mehreren Bedingungen und einem Ziel, das angibt, was mit einem passenden Paket gemacht werden soll.

Es gibt sehr viele Bedingungen, die man verwenden kann. Meist braucht man aber nur einen kleinen Teil davon.

Ein Ziel kann entweder der Name einer Kette sein (dann werden die Regeln dieser Kette der Reihe nach abgearbeitet) oder einer der speziellen Werte ACCEPT (Paket durchlassen) und DROP (Paket verwerfen). Es gibt auch noch die spezielle Wert QUEUE und RETURN, auf die wir aber nicht näher eingehen werden.

Passen alle Bedingungen einer Regel auf ein Paket, so wird diese Regel angewandt und zu dem in der Regel definierten Ziel gesprungen. Falls eine Regel nicht passt, wird die nächste Regel in der Kette probiert. Passen alle Regeln einer Kette nicht, so wird zum Standardziel der Kette gesprungen.

(2)

Befehle - iptables 1

Befehle - iptables 2

Befehle - iptables 3

Befehle - iptables 4

Befehle - iptables 5

Befehle - iptables 6

iptables, ip6tables - Administrieren der IPv4/IPv6 Paketfilter.

Das ist das Programm, mit dem man die Paketfilter im Kernel verwalten kann. Daher braucht man root-Rechte für das Ausführen.

Es unterstützt alle Filtermethoden, die durch Kernel-Module bereitgestellt werden, d.h. man braucht wirklich nur dieses Programm.

Alle Unterbefehle (zum Erstellen/Löschen von benutzerdefinierten Ketten und Verwalten von Ketten) sind ähnlich aufgebaut und unterstützen eine Unmenge von Optionen. Wir sehen uns die Unterbefehle der Reihe nach an.

Globale Optionen:

-n

→ keine Namensauflösung durchführen,

-v

→ detailierte Ausgabe,

--line-numbers

→ Zeilennummer bei Regeln anzeigen.

»

Befehle zum Verwalten von Ketten

-L [Kette]

→ Anzeigen der Regeln der spezifizierten Kette oder von allen Ketten.

-N Kette

→ Eine neue, benutzerdefinierte Kette anlegen.

-F [Kette]

→ Alle Regeln der spezifizierten Kette oder aller Ketten löschen.

-X [Kette]

→ Die spezifizierte oder alle benutzerdefinierten Ketten löschen (dürfen keine Regeln enthalten und auch nirgends referenziert werden).

-Z [Kette]

→ Die Zähler der spezifizierten Kette oder aller Ketten zurücksetzen.

-P Kette Ziel

→ Das Standardziel der Kette definieren.

$ # Zurücksetzen auf den Ursprungszustand

$ iptables -F

$ iptables -X

$ iptables -Z

$ iptables -P INPUT ACCEPT

$ iptables -P FORWARD ACCEPT

$ iptables -P OUTPUT ACCEPT

»

Befehle zum Verwalten von Regeln

-A Kette Regel

→ Anfügen einer Regel an eine Kette.

-D Kette Regel|Zeile

→ Löschen einer Regel (durch Angabe der Regel oder der Zeilennummer).

-I Kette [Zeile] Regel

→ Einfügen der Regel in die erste oder der spezifizierten Zeile.

-R Kette Zeile Regel

→ Ersetzen der Regel in der spezifizierten Zeile.

-j Ziel

→ Spezifiziert das Ziel einer Regel.

$ # Einige Beispielaufrufe

$ iptables -A INPUT -p tcp -j DROP

$ iptables -D INPUT -p tcp -j DROP # oder: iptables -D INPUT 1

$ iptables -I INPUT -p tcp -j DROP

$ iptables -I INPUT -p udp -j DROP

$ iptables -L INPUT

Chain INPUT (policy ACCEPT)

target prot opt source destination DROP udp -- anywhere anywhere DROP tcp -- anywhere anywhere

»

Nützliche Standardbedingungen für Regeln

-p Protokoll

→ Angabe des Protokolls (z.B.

tcp

^oder

udp

^).

-i Schnittstelle

→ Angabe der Netzwerkschnittstelle, über die das Paket hereingekommen ist (z.B.

lo

^oder

eth0

^).

-o Schnittstelle

→ Angabe der Netzwerkschnittstelle, über die das Paket versandt werden wird.

-s Quelladresse

→ Angabe der Quell-IP oder des Quell-Netzes (z.B.

131.130.16.0/22

^).

-d Zieladresse

→ Angabe der Ziel-IP oder Ziel-Netzes.

Das Voranstellen eines Rufzeichens vor einer der obigen Bedingungen invertiert die Bedingung.

$ # Alle Pakete wegwerfen, außer die von einem bestimmten Netz

$ iptables -A INPUT ! -s 131.130.16.0/22 -j DROP

$ # Alle Pakete an eine bestimmte IP wegwerfen

$ iptables -A OUTPUT -o eth0 -d 131.130.16.5 -j DROP

»

Zusätzliche Bedingungen für TCP/UDP

-m tcp

→ Bedingungen für TCP-Pakete (nur wenn

-p tcp

gesetzt ist)

--sport Port

→ Quellport

--dport Port

→ Zielport

--syn

→ Paket, bei dem das SYN-Flag gesetzt und RST-, ACK- und FIN-Flags nicht gesetzt sind (erstes Paket bei Verbindungsaufbau)

-m udp

→ Bedingungen für UDP-Pakete (nur wenn

-p udp

gesetzt ist)

--sport Port

→ Quellport

--dport Port

→ Zielport

$ # Alle eingehenden Verbindungsanfragen an TCP-Port 80 zulassen

$ iptables -A INPUT -p tcp -m tcp --dport 80 --syn -j ACCEPT

»

(3)

Befehle - iptables 7

Befehle - iptables 8

Secure Shell (SSH)

Ganz früher wurde telnet verwendet und ab circa 1983 dann vermehrt rlogin oder rsh, um sich auf einem anderen Rechner einzuloggen.

Beide Programm haben aber mehrere Sicherheitsprobleme und sollten daher nicht mehr benutzt werden!

Im Jahr 1995 wurde dann die Secure Shell (SSH) entwickelt, um ein sicheres Einloggen auf anderen Rechner zu gewährleisten. Das Programm wurde ursprünglich frei zur Verfügung gestellt, später aber entwickelte es sich in Richtung einer proprietären Software.

Daher wurde ab 1999 ausgehend von einer freien Version des ursprünglichen Programms die Software OpenSSH entwickelt, die mittlerweile Standard auf Linux- und BSD-Systemen geworden ist.

SSH benutzt ein asymmetrisches Kryptosystem zum Authentifizieren des entfernten Rechners. Weiters wird der Datenverkehr zwischen Client und Server verschlüsselt und Benutzer können sich entweder mittels Benutzername und Passwort oder mit Hilfe von Public-Key- Authentifizierung anmelden.

OpenSSH - Konfiguration

Unter Ubuntu gibt es zwei Pakete: openssh-server (die Serversoftware) und openssh-client (die Software zum Zugriff auf einen Server).

Bei der Installation von openssh-server werden automatisch die benötigten Host-Schlüssel erstellt und der Server gestartet. Die Default- Konfiguration reicht für normale Systeme, bei Servern sollte man sie eventuell noch ein wenig modifizieren, um optimale Sicherheit gewährleisten zu können.

Auf Servern sollte man die automatisch generierten Host-Schlüssel verwerfen, wenn es für den Host schon Schlüssel gibt, weil sonst bei den Clients eine Meldung über nicht übereinstimmende Schlüssel auftaucht.

Das Konfigurationsverzeichnis für OpenSSH ist

/etc/ssh

. Darin befindet sich die Konfigurationsdatei

sshd_config

^{für das} Serverprogramm und die globale Konfigurationsdatei

ssh_config

für das Clientprogramm.

Die Konfigurationsdateien eines Benutzers liegen in

~/.ssh

. Es ist darauf zu achten, dass dieses Verzeichnis die Zugriffsrechte 0700 hat!

OpenSSH - Public-Key-Authentifizierung

Die Verwendung von Public-Key-Authentifizierung ermöglicht ein sicheres und passwortloses Einloggen auf einem Rechner. Daher sollte man diese Authentifizierungsmethode bevorzugen.

Es gibt mehrere verschiedene Algorithmen für die Public-Key-Authentifizierung in OpenSSH. RSA war der ursprüngliche Algorithmus, später kamen DSA und ECDSA hinzu.

Derzeit kann man nur rohe Gewalt anwenden, um die Schlüssel zu knacken, egal welcher Algorithmus verwendet wird. Es empfiehlt sich daher immer einen Schlüssel mit möglichst vielen Bits zu verwenden (je länger der Schlüssel, desto schwieriger ist er zu knacken; z.B. RSA 2048 Bit, DSA 1024 Bit, ECDSA 521 Bit).

OpenSSH - Erzeugen eines Schlüsselpaars

Das Programm ssh-keygen erlaubt das Erzeugen/Verwalten eines Public/Private-Schlüsselpaars.

Zusätzliche Bedingungen für den Verbindungsstatus

-m state

→ Bedingungen für Verbindungsstatus

--state Status[,Status,...]

→ Verbindungsstatus muss einem der Werte entsprechen. Mögliche Werte: INVALID (ungültiges Paket), ESTABLISHED (aufgebaute Verbindung), NEW (Paket baut eine neue Verbindung auf), RELATED (Paket hat neue Verbindung aufgebaut, steht aber in Beziehung zu einer bereits aufgebauten Verbindung)

$ # Alle Pakete, die zu einer aufgebauten Verbindung gehören, zulassen

$ iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

»

Zusätzliche, eingebaute Ziele

REJECT → Wie DROP, aber es wird ein Fehlerpaket an die Quelle zurückgesandt.

LOG → Paketinformationen werden in das Kernel-Log geschrieben; danach wird bei der nächsten Regel fortgefahren

$ # Verbindungsanfragen an den SSH-Server protokollieren und zulassen

$ iptables -A INPUT -p tcp -m tcp --dport 22 --syn -j LOG --log-prefix "SSH connection"

$ # Alle anderen Verbindungsanfragen mit einem Fehler zurückweisen

$ iptables -A INPUT -p tcp -m tcp --syn -j REJECT

»

Beispielkonfiguration

$ # Pakete von der lokalen Schnittstelle akzeptieren wir immer

$ iptables -A INPUT -i lo -j ACCEPT

$ # Pakete von aufgebauten Verbindungen werden erlaubt

$ iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

$ # Pakete zum Verbindungsaufbau an den OpenSSH-Server sind erlaubt

$ # Standardziele der Ketten zum Abschluss sinnvoll setzen

$ iptables -P INPUT DROP

$ iptables -P FORWARD DROP

$ iptables -P OUTPUT ACCEPT

»

(4)

Mit der Option

-t rsa|dsa|ecdsa

kann man den Algorithmus auswählen und mit

-b Bits

die Schlüssellänge. Wichtig: Das unter Windows sehr oft verwendete SSH-Clientprogramm putty kann derzeit noch nicht ECDSA-Schlüsseln verwenden!

Beim Erstellen des Schlüsselpaares fragt das Programm nach dem Speicherort und nach einem Passphrase. Man muss nicht zwingend eine Passphrase eingeben, es empfiehlt sich aber, da sonst jeder die Schlüssel verwenden kann, der in Besitz der Dateien kommt.

Der private und der öffentliche Schlüssel werden von ssh-keygen in das Verzeichnis

~/.ssh/

gespeichert, wenn man keinen anderen Speicherort auswählt, und mit Hilfe des Programms ssh-copy-id kann der öffentliche Schlüssel auf einen Rechner übertragen werden.

$ ssh-keygen -t dsa -b 1024

$ ssh-copy-id -i ~/.ssh/id_dsa.pub benutzer@computer.example.org

OpenSSH - ssh-agent

Damit man nicht jedes Mal die Passphrase für den Schlüssel eingeben muss, kann man das Programm ssh-agent benutzen. Dieses speichert die Passphrasen für einen oder mehrere Schlüssel, die man mit Hilfe von ssh-add hinzufügt.

Üblicherweise wird das Programm ssh-agent automatisch beim Starten einer graphischen Oberfläche mitgestartet. Falls nicht, kann man das Programm auch später in der Shell starten. Dabei ist darauf zu achten, dass die ausgegebenen Umgebungsvariablen in die Prozessumgebung der Shell aufgenommen werden.

$ eval $(ssh-agent) Agent pid 2789

$ ssh-add

Enter passphrase for /home/thomas/.ssh/id_dsa:

Identity added: /home/thomas/.ssh/id_dsa (/home/thomas/.ssh/id_dsa)

OpenSSH - Clientprogramm 1

Das Clientprogramm ssh wird zum Einloggen auf einem entfernten Rechner verwendet.

$ ssh leitner@login.mat.univie.ac.at leitner@login:~$

Mit Hilfe der Option

-o

können beliebige SSH-Client-Optionen angegeben werden. Nützlich sind oft die folgenden Optionen:

PubkeyAuthentication → zum Ein-/Ausschalten der Public-Key-Authentifizierung PasswortAuthentication → zum Ein-/Ausschalten der Passwortauthentifizierung StrictHostKeyChecking → damit die Host-Schlüssel nicht überprüft werden

In der Datei

~/.ssh/config

können SSH-Client-Optionen für alle Verbindungen oder für Verbindungen zu speziellen Hosts angegeben werden.

OpenSSH - Clientprogramm 2

Daneben unterstützt es aber auch noch das Weiterleiten von X11-Verbindungen sowie Port-Forwarding.

# X11-Weiterleitung bei einer Verbindung aktivieren

$ ssh -Y login.example.com

# Zugriff auf einen nicht öffentlichen Webserver über http://localhost:1234

$ ssh -L 1234:webserver.internal.example.com:80 login.example.com

Mit Hilfe des Programms scp kann man Dateien von einem Rechner über SSH auf einen anderen übertragen.

$ scp -r user@example.com:/data/my_dir .

Falls das SFTP-Modul am SSH-Server aktiviert worden ist, kann man auch ähnlich zum klassichen FTP Dateien vom oder zum Server übertragen (WinSCP ist ein gutes Windowsprogramm dafür).

Es gibt auch einige interessante Projekte, die auf SSH aufsetzen. Ein sehr nützliches ist sshuttle, welches eine Art VPN aufbaut und dazu nur SSH und einen installierten Python-Interpreter auf dem Server braucht.

Links: OpenSSH WikiBook, SSH Tricks, SSH Can Do That?

Network File System (NFS)

Das Network File System (NFS) (definiert in RFC 1094, RFC 1813 und RFC 3530) wurde von Sun Microsystems entwickelt und erlaubt den Zugriff auf Dateien über ein Netzwerk.

Es gibt verschiedene Versionen von NFS. Derzeit kommen die Versionen NFSv3 und NFSv4 zum Einsatz. Hauptvorteile von NFSv4 gegenüber NFSv3 sind:

Authentifikation von Benutzern, nicht nur Hostauthentifikation

Unterstützung von access control lists (ACLs) für erweiterte Zugriffsrechte Datenübertragung nur mehr über TCP, weil das Protokoll nicht mehr zustandslos ist

Früher benötigte Serverdienste wie portmapper, rpc.mountd und rpc.lockd werden nicht mehr gebraucht Alle gängigen UNIX-/Linux-/BSD-Systeme unterstützen mittlerweile sowohl NFSv3 als auch NFSv4.

NFSv4 - Überblick 1

Da NFSv4 gegenüber NFSv3 viele Vorteile bietet, sollte man nicht mehr NFSv3 einsetzen. Dies wird dadurch erleichtert, dass man NFSv4 in einem zu NFSv3 ähnlichen Modus ohne Benutzerauthentifikation betreiben kann.

Wir betrachten ab jetzt nur mehr NFSv4, das meiste ist aber auch für NFSv3 gültig.

(5)

NFS basiert auf Open Network Computing (ONC) Remote Procedure Call (RPC). Das ist ein System, mit dem Applikationen Nachrichten über das Netzwerk austauschen können. Dabei sieht es für den Programmier so aus, als würde er nur lokal Nachrichten austauschen.

Wichtig: Die Authentifizierung erfolgt über RPC und nicht über NFSv4, welches nur ein Protokoll ist, das RPC benutzt.

Die Authentifizierung der Benutzer kann bei NFSv4 nicht nur mit der üblichen Benutzername/Passwort-Kombination gemacht werden (Sicherheit sec=sys), sondern es ist auch möglich, Benutzer über Kerberos zu authentifizieren (Sicherheit sec=krb5|krb5i|krb5p).

NFSv4 - Überblick 2

Unter NFSv4 werden nicht mehr UID und GIDs über das Netzwerk übertragen (so wie bei vorigen Protokollversionen), sondern Zeichenketten der Form „user@domain“ bzw. „group@domain“. Dadurch müssen Benutzer nicht mehr die gleiche UID auf Client und Server besitzen und das Protokoll wird vielseitiger einsetzbar (weil es nicht in allen Betriebssysteme eine UID bzw. GID geben muss).

Da dies aber zu Problemen bei Benutzung der Sicherheit sec=sys führt, wurde vor kurzem im NFSv4-System von Linux die Möglichkeit implementiert, statt Namen wieder UIDs und GIDs zu übertragen (siehe RFC 3530bis). Dies ist unter Ubuntu die Defaulteinstellung und kann durch Änderung der Modulparameter

nfs.nfs4_disable_idmapping

(für den Client) sowie

nfsd.nfs4_disable_idmapping

(für den Server) deaktiviert werden.

Das Zuordnen von UID/GID zu einem Namen erfolgt durch einen ID-Mapping-Dienst am Client bzw. Server. Unter Linux ist dieser Dienst durch rpc.idmapd implementiert.

NFSv4-Server einrichten - Dienste 1

Es empfiehlt sich, dass am Server sowie auf den Clients die gleichen Benutzer die gleichen UIDs besitzen. Dies ist zwar nicht mehr unbedingt nötig, beugt aber Problemen vor (vor allem, wenn Kerberos nicht eingesetzt wird).

Unter Ubuntu werden alle nötigen Programme bei der Installation des Pakets nfs-kernel-server installiert und nach der Installation laufen alle Dienste mit den Standardeinstellungen. Da wir nur NFSv4 verwenden wollen, muss man die Konfiguration anpassen.

In

/etc/default/nfs-common

deaktiviert man den statd-Dämonen, in

/etc/default/nfs-kernel-server

^{fügt man} bei RPCNFSDCOUNT und RPCMOUNTDOPTS die Optionen

--no-nfs-version 3 --no-nfs-version 2

^hinzu.

NFSv4-Server einrichten - Dienste 2

In

/etc/idmapd.conf

muss man den Domännamen der NFS-Domäne eingeben (außer er entspricht der DNS-Domäne).

Falls das ID-Mapping nicht verwendet werden soll (wenn es nur Linux-Clients gibt), passt die Standardeinstellung. Ansonsten eine Datei

/etc/modprobe.d/nfs.conf

mit folgendem Inhalt anlegen:

options nfs nfs4_disable_idmapping=N options nfsd nfs4_disable_idmapping=N

Nach den Änderungen nicht auf das Neustarten der Services nfs-kernel-server und idmapd vergessen!

NFSv4-Server einrichten - Exports 1

Nach dem nun die Dienste entsprechend eingerichtet worden sind, müssen wir dem NFS-Server noch mitteilen, welche Verzeichnisse exportiert werden sollen. Dazu braucht man die Datei

/etc/exports

und den Befehl exportfs.

In der Datei

/etc/exports

trägt man die Verzeichnisse mit den dazugehörigen Optionen ein, die man freigeben will. Jede Zeile enthält ein Verzeichnis und dann eine Liste von Rechnern (durch Leerzeichen getrennt), die darauf zugreifen können. Direkt nach der Angabe von Rechnern können Optionen in runden Klammern angegeben werden.

/srv/exports hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)

Wichtig: Bei NFSv4 müssen (im Gegensatz zu NFSv3) alle Verzeichnisse unter einem Wurzelverzeichnis liegen. Das heißt, wenn das Wurzelverzeichnis

/srv/exports

ist, müssen alle zu exportierenden Verzeichnisse in diesem Verzeichnis liegen. Will man ein schon existierendes Verzeichnis exportieren, so muss man ein bind-Mount machen (

mount --bind /pfad/zu/verz

/srv/exports/verz

; am besten in

/etc/fstab

eintragen).

NFSv4-Server einrichten - Exports 2

Einige wichtige Export-Optionen:

rw

→ Lese- und Schreibzugriff ist möglich (sonst nur Lesezugriff)

sync

→ Synchroner Zugriff (Antwort von Server erst, nachdem Änderungen geschrieben worden sind)

no_subtree_check

→ Keine Überprüfung von Unterverzeichnissen (sollte man fast immer verwenden)

fsid=Wert

→ Angabe einer eindeutigen ID für das exportierte Verzeichnis (unter NFSv4 muss man die Wurzel der exportierten Verzeichnisse mit fsid=root exportieren)

[no_]root_squash

→ Den Administrator (nicht) auf den anonymen Benutzer abbilden

Nach dem Eintragen der zu exportierenden Verzeichnisse muss man die Änderungen der NFS-Server mitteilen:

$ exportfs -rav NFS-Client einrichten

Der ID-Mapper am Client muss gleich wie am Server konfiguriert werden, d.h. die NFS-Domännamen müssen übereinstimmen.

Weiters muss auch der Modulparameter

nfs.nfs4_disable_idmapping

mit der Einstellung am Server übereinstimmen.

Anschließend braucht man das Netzwerkdateisystem nur wie ein normales Dateisystem einhängen:

$ mount -t nfs4 server:/ /mnt

(6)

Common Internet File System (CIFS)

Das Common Internet File System (CIFS), auch bekannt unter Server Message Block (SMB), ist, wie NFS, ein Netzwerkdateisystem.

Allerdings bietet es darüber hinaus auch noch andere Möglichkeiten, zum Beispiel Druckerfreigaben.

Das Protokoll wurde ursprünglich Anfang der 1980er Jahre bei IBM entwickelt und später stark von Microsoft weiterentwickelt. Änderungen im Protokoll müssen von Microsoft auf Druck der EU seit einige Jahren veröffentlicht werden, damit andere als die Microsoftimplementierung ohne Reverse-Engineering möglich sind.

Unter Unix-artigen Betriebssystemen gibt es seit 1992 die freie Software Samba, die die Kommunikation über SMB bzw. CIFS ermöglicht. Die aktuelle Version von Samba ist Version 4, die es nun auch ermöglicht, einen Active Directory-Domain Controller zu betreiben. Damit kann man mit Samba ohne Microsoft-Server ein Windows-Netzwerk betreiben.

Derzeit empfiehlt es sich aber noch, die letztgültig Version 3.x von Samba einzusetzen, falls man die Active Directory-Domain Controller- Funktion nicht braucht, da Version 4 erst im Dezember 2012 veröffentlicht worden ist.

Samba-Server einrichten 1

Unter Ubuntu werden die benötigten Komponenten für den Server durch das Paket samba bereitgestellt.

Im Gegensatz zu NFS umfasst ein Samba-Server viel mehr Komponenten und ist dementsprechend auch schwieriger aufzusetzen, auch wenn man nur die Netzwerkdateisystem-Komponente benutzen will.

Die Konfigurationsdatei

/etc/samba/smb.conf

wird sowohl für die Konfiguration des Servers als auch der Client-Programme verwendet. Es gibt eine Unmenge von einstellbaren Optionen. Die Konfiguration von Samba als Active Directory-Domain Controller sprengt den Rahmen der Vorlesung, wir werden uns nur mit der Freigabe von Dateien beschäftigen.

Wichtige Konfigurationsoptionen der Gruppe global:

workgroup → Der Name der Arbeitsgruppe bzw. Windows-Domäne

security → Bestimmt das verwendete Sicherheitsmodell, ist für unseren einfachen Fall auf user zu setzen

Samba-Server einrichten 2

Konfigurationsoptionen für die Gruppe homes (erlaubt das automatische Exportieren der Home-Verzeichnisse der Benutzer unter deren Benutzernamen, falls aktiviert) bzw. für allgemeine Shares:

read only → Sollte man auf no stellen, wenn auch Schreibzugriffe möglich sein soll guest okay → Anonymen Zugriff auf das Share erlauben

path → Das Verzeichnis, das exportiert werden soll (nicht nötig für die Gruppe homes)

Um ein Verzeichnis als Share zu exportieren, eine Optionengruppe mit dem Namen anlegen und darin die nötigen Optionen setzen:

[home]

path = /home guest okay = no read only = no

Nach Änderungen an der Konfigurationsdatei den Samba-Server neustarten:

$ service smbd restart

Samba-Server einrichten 3

Samba benutzt für die Authentifikation von Benutzern eine eigene Datenbank oder, falls so konfiguriert, einen LDAP-Server (Option passdb backend). Das heißt, dass die am System definierten Benutzer nicht automatisch zum Zugriff auf den Samba-Server verwendet werden.

Damit ein Benutzer zugreifen kann, muss man ihn in die Passwortdatenbank mittels smbpasswd aufnehmen.

$ smbpasswd praxis New SMB password:

Retype new SMB password:

Normale Benutzer können später mit Hilfe dieses Programmes auch ihr Samba-Passwort ändern.

Das Programm pdbedit kann von root auch für die Verwaltung der Passwortdatenbank genutzt werden:

$ pdbedit -x praxis # Benutzer löschen

$ pdbedit -a praxis # Benutzer hinzufügen

$ pdbedit -L # Benutzer auflisten

Samba-Server mittels SWAT einrichten

Das Samba Web Administration Tool (SWAT) kann als Alternative zur manuellen Konfiguration der Konfigurationsdatei verwendet werden. Es erlaubt die Konfiguration mittels einer relativ einfachen Webapplikation.

Unter Ubuntu muss das Paket swat installiert und danach der Serverdienst openbsd-inetd neugestartet werden. Danach kann auf die Webapplikation über den Port 901 zugegriffen werden.

Ein großer Vorteil dieser Webapplikation ist, dass überall Hilfe-Buttons vorhanden sind, die schnell Hilfe zu einer Konfigurationsoption bieten.

Es kann auch der aktuelle Status des Samba-Server angesehen werden bzw. können auch Benutzerpasswörter verändert werden.

Samba-Server mittels SWAT einrichten - Screenshot

(7)

Samba-Client einrichten

Am Client-Rechner müssen die Pakete smbclient und cifs-utils installiert werden. Das erste stellt das Programm smbclient zur Verfügung, das zweite erlaubt das Einhängen eines Samba-Shares mittels mount.cifs.

Der Befehl smbclient agiert ähnlich wie ein FTP-Client-Programm und kann für die Interaktion mit einem CIFS-Dateiserver verwendet werden.

$ smbclient -U praxis -L //server # Auflisten alle Shares am Server

$ smbclient -U praxis //server/home # Verbinden zum Share home

Um ein CIFS-Share in das Dateisystem einzuhängen, verwendet man den Befehl mount.cifs, welcher wie der Befehl mount funktioniert.

Die wichtigsten Optionen sind dabei user, pass und dom (Arbeitsgruppen- bzw. Domänname), wobei das Passwort interaktiv abgefragt wird, wenn es nicht spezifiziert worden ist.

$ mount.cifs //192.168.56.101/home /mnt -o user=praxis,dom=PRAXIS Password:

Webserver

Man könnte sich die Welt heutzutage kaum mehr ohne das World Wide Web vorstellen. Das Web ist ein Teil des Internets und besteht aus Hypertext-Dokumenten, die durch Hyperlinks miteinandern verbunden sind.

Grundlage für den Datenaustausch ist das Hypertext Transfer Protocol (HTTP; definiert in RFC 1945 bzw. RFC 2616) bzw. die sichere Variante HTTPS (definiert in RFC 2818).

Um auf Inhalte im Web zuzugreifen, verwendet man im Allgemeinen einen Webbrowser. Dieser verbindet sich dann über HTTP mit einem Webserver und lädt die angeforderten Dokumente.

Gerade im Bereich der Webserver haben Unix-artige Betriebssysteme eine Vorrangstellung, speziell auch Linux. Und der Webserver schlechthin ist der Apache HTTP Server, der freie Software ist. Andere oft benutzte Webserver sind nginx und Microsoft Internet Information Services (IIS).

Apache HTTP Server

Der Apache HTTP Server ist modular aufgebaut, d.h. man braucht nur die Komponenten installieren, die man auch wirklich verwendet, was Ressourcen schont. Zudem ist er sehr stabil und schnell.

Einige Funktionen des Servers:

Virtual Hosts zur Bereitstellung von Websites verschiedener Domänen Verschlüsselung der Daten mittels SSL (HTTPS-Protokoll) mittels mod_ssl Manipulieren von HTTP-Kopfdaten (mod_headers) oder URLs (mod_rewrite)

Einbinden dynamischer Inhalte mittels CGI, FastCGI, oder anderen Modulen (z.B. mod_passenger für die Programmiersprache Ruby) Verschiedene Authentifizierungsmodule

Unterstützung von zusätzlichen Protokollen wie WebDAV

Apache HTTP Server einrichten 1

Die Installation des Servers erfolgt mittels des Pakets apache2. Damit sind auch die wichtigsten Module bereits vorhanden.

(8)

Die Konfigurationsdateien befinden sich im Verzeichnis

/etc/apache2

. In diesem Verzeichnis befinden sich mehrere Dateien und Verzeichnisse, unter anderem:

apache2.conf

→ Die Hauptkonfigurationsdatei

conf.d/

→ Verzeichnis für zusätzliche Konfigurationsdateien

mods-available/

→ Konfigurationsdateien für die verfügbaren Module

mods-enabled/

→ Symlinks nach

mods-available/

für die aktivierten Module

sites-available/

→ Konfigurationsdateien für einzelne Websites

sites-enabled/

→ Symlinks nach

sites-available/

für aktivierte Websites

Das (de)aktivieren von Modulen und Webseiten kann entweder händisch durch Setzen der entsprechende Links gemacht werden oder über die Progamme a2enmod, a2dismod, a2ensite und a2dissite.

Das Standard-Webserver-Verzeichnis ist

/var/www

. Alle darin vorhandenen Dateien können über den Webserver abgefragt werden.

Apache HTTP Server einrichten 2

Die Standardkonfiguration ist für einfache Websites, die nur statische Dateien benutzen, ausreichend. Falls man auch dynamische Webseiten generieren will, muss man die entsprechenden Module nachinstallieren (z.B. das Paket libapache2-mod-php5 für die Programmiersprache PHP5). Nicht vergessen mit, die Module mit Hilfe von a2enmod zu aktivieren!

Die Apache Dokumentation liefert zu allen Modulen und Einstellungen genaue Informationen und auch Anwendungsbeispiele. Falls etwas unklar ist, sollte man dort als erstes nachsehen.

Copyright und Lizenz

Copyright: Thomas Leitner thomas.leitner@univie.ac.at Lizenz: Creative Commons CC BY-NC-SA

„Namensnennung-Keine kommerzielle Nutzung-Weitergabe unter gleichen Bedingungen 3.0 Österreich.“ - http://creativecommons.org/licenses/by-nc-sa/3.0/at/