Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
5 Der Kernel
6 Die Grundlagen aus Anwendersicht
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP
20 DNS-Server
21 Secure Shell
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in die Sicherheit
33 Netzwerksicherheit überwachen
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Die Buch-DVDs
F Glossar
G Literatur
Stichwort

Download:
- ZIP, ca. 15,7 MB
Buch bestellen
Ihre Meinung?

Spacer
 <<   zurück
Linux von Johannes Pl&ouml;tner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
geb., mit 2 DVDs
1302 S., 39,90 Euro
Galileo Computing
ISBN 978-3-8362-1704-0
Pfeil 17 Netzwerkdienste
  Pfeil 17.1 inetd und xinetd
    Pfeil 17.1.1 inetd
    Pfeil 17.1.2 tcpd
    Pfeil 17.1.3 xinetd
  Pfeil 17.2 Standarddienste
    Pfeil 17.2.1 Echo
    Pfeil 17.2.2 Discard
    Pfeil 17.2.3 Systat und Netstat
    Pfeil 17.2.4 Daytime und Time
    Pfeil 17.2.5 QotD
    Pfeil 17.2.6 Chargen
    Pfeil 17.2.7 Finger
    Pfeil 17.2.8 Telnet und R-Dienste
  Pfeil 17.3 DHCP
    Pfeil 17.3.1 dhcpd
    Pfeil 17.3.2 Client-Konfiguration
  Pfeil 17.4 NNTP-Server
    Pfeil 17.4.1 Konfiguration
    Pfeil 17.4.2 Server starten
    Pfeil 17.4.3 Authentifizierung
    Pfeil 17.4.4 Anonyme Message-IDs
    Pfeil 17.4.5 WendzelNNTPGUI
  Pfeil 17.5 Network File System
    Pfeil 17.5.1 Einen NFS-Server aufsetzen
    Pfeil 17.5.2 Den Client konfigurieren
  Pfeil 17.6 Der FTP-Dienst
    Pfeil 17.6.1 Konfigurationsdateien
  Pfeil 17.7 Samba
    Pfeil 17.7.1 Windows-Freigaben mounten
    Pfeil 17.7.2 Dateien freigeben
    Pfeil 17.7.3 Die Konfigurationsdatei smb.conf
    Pfeil 17.7.4 Samba, LDAP
  Pfeil 17.8 Zusammenfassung
  Pfeil 17.9 Aufgaben

»Wer klug zu dienen weiß, ist halb Gebieter.«
– Publilius Syrus

17 Netzwerkdienste

In diesem Kapitel möchten wir uns nun mit einigen grundlegenden Diensten auseinandersetzen, die Linux- und Unix-Systeme mit sich bringen – davon gibt es übrigens eine ganze Menge. In den folgenden Kapiteln werden daher noch weitere besonders wichtige und populäre Dienste wie Nameserver und SSH sowie der Einsatz von Linux als »LAMP«-Server besprochen.


Galileo Computing - Zum Seitenanfang

17.1 inetd und xinetd  Zur nächsten ÜberschriftZur vorigen Überschrift

Superserver?

Als Erstes wollen wir uns mit den sogenannten »Superservern« befassen. Dabei handelt es sich um die beiden Dienste inetd und xinetd. Je nach Distribution bzw. Derivat wird entweder standardmäßig der inetd oder der neuere und bessere xinetd auf Ihrem System vorhanden sein. Welchen Dienst Sie nutzen, ist aber für die weitere Lektüre prinzipiell egal – wir besprechen beide Dienste. [Sind wir nicht toll ...]

Zur grundlegenden Funktionsweise ist zu sagen, dass die Superserver darauf warten, dass bestimmte Netzwerkverbindungen hergestellt werden. Ist zum Beispiel eine FTP-Funktionalität konfiguriert, wird der entsprechende FTP-Dienst erst gestartet, wenn eine Verbindungsanfrage seitens eines Clients vorliegt.

Es gibt dabei sowohl Superserver-interne als auch -externe Dienste. Die internen Dienste sind kleine Dienste, für die man keine gesonderten Binaries verwenden will. Sie brauchen also nicht explizit über ein anderes Programm gestartet werden, sondern werden vom Superserver selbst bereitgestellt. Externe Programme, etwa ein FTP-Server, werden in einem eigenen Prozess gestartet und kommunizieren dann indirekt mit dem Client, da sich zwischen den beiden Endpunkten immer noch der Superserver befindet.

Diese Superserver können sowohl mit UDP- als auch mit TCP-Diensten, ja sogar mit RPC-Diensten umgehen. [RPC steht für Remote Procedure Call und wird zum Beispiel von NFS und NIS verwendet. Es erlaubt sogenanntes Distributed Computing. Nähere Informationen hierzu erhalten Sie in Andrew Tanenbaums Buch »Verteilte Systeme« [TanVanSt07].] Aber warum sollte man überhaupt so etwas wie Superserver einsetzen wollen?


Ein über den Superserver (x)inetd verwalteter Dienst wird erst gestartet, wenn ein Verbindungswunsch vorliegt. Ein entsprechender Serverdienst wird also nur aktiv, wenn er auch wirklich benötigt wird. Für selten genutzte Dienste können so Ressourcen gespart werden, auch wird man hier die durch den Start des Dienstes bedingte minimale Verzögerung bei der ersten Antwort vom Server akzeptieren.



Einen Serverdienst bezeichnet man als standalone, wenn er nicht durch einen Superserver gestartet wird, sondern permanent im Hintergrund läuft und auf Anfragen wartet.



Eine Anleitung zur Programmierung von Superserver-basierten Diensten finden Sie in [Stevens00A].



Galileo Computing - Zum Seitenanfang

17.1.1 inetd  Zur nächsten ÜberschriftZur vorigen Überschrift

Zunächst wollen wir uns mit der alten, aber immer noch sehr verbreiteten Variante inetd beschäftigen. Veröffentlicht wurde der Dienst mit 4.3BSD, spätere Weiterentwicklungen mit SunOS 4.1 fügten die Unterstützung für Sun RPC hinzu. Unter BSD wurde 1999 der IPv6-Support durch das KAME-Projekt hinzugefügt.

Die primäre Konfiguration des Superservers erfolgt über die Datei /etc/ inetd.conf. Der Aufbau der Datei ist, wie für Unix-Systeme üblich, sehr einfach. Sehen wir uns einmal eine solche Konfigurationsdatei an: [Leider ist aufgrund der Seitenbreite die Lesbarkeit dieses Listings etwas beeinträchtigt. Die Backslashes am Ende der Zeile zeigen wie immer an, dass eine Zeile in der darauffolgenden Zeile fortgesetzt wird.]

ftp    stream tcp  nowait root /usr/libexec/ftpd ftpd -US
ftp    stream tcp6 nowait root /usr/libexec/ftpd ftpd -US
telnet stream tcp  nowait root \
/usr/libexec/telnetd telnetd -k
telnet stream tcp6 nowait root \
/usr/libexec/telnetd telnetd -k
shell  stream tcp  nowait root /usr/libexec/rshd rshd -L
shell  stream tcp6 nowait root /usr/libexec/rshd rshd -L
uucpd  stream tcp  nowait root /usr/libexec/uucpd uucpd
uucpd  stream tcp6 nowait root /usr/libexec/uucpd uucpd
finger stream tcp  nowait _fingerd \
/usr/libexec/fingerd fingerd -lsm
finger stream tcp6 nowait _fingerd \
/usr/libexec/fingerd fingerd -lsm
...
...
echo   dgram udp  wait   root    internal
echo   dgram udp6 wait   root    internal
...
...
sprayd/1 dgram rpc/udp wait root \
/usr/libexec/rpc.sprayd rpc.sprayd

Listing 17.1  Ausschnitt aus einer inetd.conf

Betrachten wir zunächst die erste Spalte. Sie gibt den Namen des Dienstes an und informiert den Superserver über den zu verwendenden Port. Wie Sie sich sicherlich erinnern, werden diese Informationen aus der Datei /etc/services bezogen. Hinter einem Slash kann zusätzlich die Dienstversion angegeben werden.

Die zweite Spalte gibt an, ob es sich um einen datagramm- (dgram) oder einen verbindungsorientierten Dienst (stream) handelt. UDP ist ein Datagramm-Protokoll. Daher wird bei UDP-Diensten dgram gesetzt und bei TCP-Diensten stream, da TCP ein verbindungsorientierter (Stream-)Dienst ist. [In der Netzwerkprogrammierung ist dieser Wert als »Socket-Type« bekannt. Bei einem Aufruf von socket() wird entsprechend SOCK_DGRAM oder SOCK_STREAM als Parameter übergeben.]

Die dritte Spalte gibt das Transport-Layer-Protokoll des Dienstes an. Unterstützt werden tcp für TCP über IPv4, tcp6 für TCP über IPv6 und dasselbe analog für UDP mit udp und udp6. Außerdem kann man RPC mit beiden Protokollen verwenden (was dann durch einen Slash in der Form rpc/Protokoll angegeben wird) oder Unix-Domain-Sockets via unix-Keyword einsetzen. [Wenn Sie diese Informationen mit denen des letzten Absatzes klug kombinieren, werden Sie feststellen, dass dgram nur in Verbindung mit udp genutzt wird und stream nur in Verbindung mit tcp.]

Spalte vier ist nur für UDP-Dienste interessant. Hier wird entweder wait oder nowait angegeben. Handelt es sich um einen Dienst, der so programmiert ist, dass er jeweils nur eine Verbindung handhaben kann, wird wait verwendet. inetd startet in diesem Fall den Dienst und wartet auf dessen Beendigung, bevor neue Verbindungen entgegengenommen werden. Wird hingegen nowait angegeben, muss der Server in der Lage sein, mehrere Verbindungen gleichzeitig zu handhaben. [Dies funktioniert beispielsweise durch Threads und Child-Prozesse.]

Anschließend folgt die Angabe eines Benutzers. Mit den Berechtigungen des Benutzers wird der Dienst gestartet. Im Übrigen ist es auch möglich, eine Gruppe in der Form user.group oder user:group anzugeben.

Die nächste Spalte gibt die Programmdatei an, die gestartet werden soll – oder eben das Keyword internal für einen inetd-internen Dienst.

Alle folgenden Spalten sind zu übergebende Startparameter für das festgelegte Programm. Der erste Parameter (C-Programmierer kennen ihn vom Argument-Vektor argv[]) ist der Programmname selbst, die nächsten Parameter sind optional und abhängig vom jeweiligen Dienst.


Galileo Computing - Zum Seitenanfang

17.1.2 tcpd  Zur nächsten ÜberschriftZur vorigen Überschrift

Was inetd nun aber noch fehlt, ist eine Zugriffskontrolle. Diese wickelt man bei Bedarf über tcpd ab. Dieses Programm nennt sich TCP-Wrapper und wird zwischen inetd und den jeweiligen Dienst gesetzt. Es überprüft die Autorisierung einer Verbindung anhand zweier Konfigurationsdateien: /etc/hosts.allow und /etc/hosts.deny.

Die Vorgehensweise ist dabei die folgende: Ist ein Dienst/Client in der hosts.allow gelistet, wird die Verbindung erlaubt. Ist dort nichts zu finden, wirft tcpd einen Blick in die hosts.deny. Ist dort ein entsprechender Eintrag zu finden, wird die Verbindung nicht erlaubt. Ist in keiner dieser Dateien ein Eintrag zu finden, wird die Verbindung wiederum erlaubt.

Um einen Dienst, der über inetd gestartet werden soll, zusätzlich mit dem tcpd zu überprüfen, wird anstelle der Binaries des Dienstes die Binary des tcpd angegeben. Aus einem Eintrag wie

finger stream tcp nowait nobody /usr/libexec/fingerd \
fingerd

Listing 17.2  Ohne tcpd

wird folglich ein Eintrag der Form

Dienst [stream/dgram] Protokoll [no]wait Benutzer\
tcpd-Binary [Dienst-Name bzw. Binary des externen\
Dienstes]
[Mit tcpd: Ein Beispiel]
finger stream tcp nowait nobody /usr/libexec/tcpd \
fingerd

Listing 17.3  Mit tcpd: Form


Galileo Computing - Zum Seitenanfang

17.1.3 xinetd  topZur vorigen Überschrift

Die Konfiguration des Superservers xinetd [Das »x« steht hierbei für extended (also erweitert), da xinetd als verbesserte Version des inetd angesehen wird.] gestaltet sich geringfügig komplizierter. Belohnt wird der Mehraufwand aber mit vielen zusätzlichen Features:

  • Schutz vor Denial-of-Service-(DoS-)Attacken
  • Logging via syslog und eigenes Logging-System
  • Zugriffskontrolle und Unterstützung der Dateien hosts.allow und hosts.deny – daher wird kein tcpd mehr benötigt!
  • Verbindungsbeschränkungen
  • tageszeitbezogene Bewilligungen von Verbindungen
  • Dienste können explizit auf bestimmten Adressen, beispielsweise nur lokal, angeboten werden.
  • Weiterleitung von TCP-Verbindungen auf (interne) Rechner

Die xinetd.conf

Basic Setup

Die Konfiguration des Servers xinetd wird in der Datei /etc/xinetd.conf abgewickelt. Diese Datei ist allerdings anders aufgebaut als die /etc/inetd.conf. Zunächst einmal werden Standardattribute konfiguriert, was in der defaults-Sektion erledigt wird.

Als Erstes wird festgelegt, dass nie mehr als 10 Serverdienste (instances) gleichzeitig laufen sollen. Möchte man keine Begrenzung, kann man statt einer Zahl auch das Keyword UNLIMITED eintragen.

Protokolliert wird über die Datei /var/log/xinetd.log, und bei erfolgreichen Verbindungen (log_on_success) werden der Hostname, die Prozess-ID, die Benutzer-ID, die Verbindungszeit und der Exit-Status protokolliert. Tritt hingegen ein Fehler auf (log_on_failure), werden Hostname, User-ID, der Grund für den Fehler (ATTEMPT) sowie einige weitere Informationen (RECORD) ausgegeben.

Durch das Schlüsselwort only_from gestatten wir im Beispiel nur Zugriffe von den Rechnern im Netz 192.168.1.0/24. Das Schlüsselwort disabled wird nur im Sektionsbereich defaults angewandt und unterbindet die Nutzung einiger Dienste.

defaults
{
instances        = 10
log_type         = FILE /var/log/xinetd.log
log_on_success   = HOST PID USERID DURATION EXIT
log_on_failure   = HOST USERID ATTEMPT RECORD
only_from        = 192.168.1.0/24
   disabled = finger
disabled += systat netstat
disabled += exec
}

Listing 17.4  Eine defaults-Sektion

Dienste konfigurieren

Kommen wir nun zur expliziten Konfiguration eines Dienstes. Als Beispiel soll wieder ein FTP-Server dienen:

service ftp
{
socket_type    = stream
wait           = no
user           = root
server         = /usr/sbin/wu.ftpd
server_args    = -a
instances      = 2
access_times   = 8:00-13:00 14:00-19:00
nice           = 10
only_from      = 192.168.1.123 192.168.1.124
}

Listing 17.5  Konfiguration eines FTP-Servers

Für TCP wählt man auch beim xinetd die Stream-Option als Socket-Type und als Analogon zu (no)wait bei inetd das no beim wait-Flag. Der FTP-Dienst soll als Superuser gestartet werden (user). Das Binary ist wu.ftpd, und als Parameter für den Aufruf des Programms wird -a übergeben.

Der Server soll von 8 bis 13 Uhr und von 14 bis 19 Uhr erreichbar sein, zum Beispiel, weil von 13 bis 14 Uhr Mittagspause ist und nachts alle Mitarbeiter schlafen ... zumindest die meisten.

Außerdem soll die Nice-Priorität auf »10« gesetzt und der Zugriff nur von den Hosts 192.168.1.123 und 192.168.1.124 gestattet werden.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






 <<   zurück
  Zum Katalog
Zum Katalog: Linux, Ausgabe 2011






Linux, Ausgabe 2011
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Linux Hochverfügbarkeit






 Linux Hoch-
 verfügbarkeit


Zum Katalog: LPIC-1






 LPIC-1


Zum Katalog: Debian GNU/Linux






 Debian GNU/Linux


Zum Katalog: openSUSE 11.2






 openSUSE 11.2


Zum Katalog: Shell-Programmierung






 Shell-Programmierung


Zum Katalog: Ubuntu GNU/Linux






 Ubuntu GNU/Linux


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2011
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de