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

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

Spacer
Linux von Johannes Plötner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
Rheinwerk Computing
1282 S., 5., aktualisierte Auflage 2012, geb., mit 2 DVDs
49,90 Euro, ISBN 978-3-8362-1822-1
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 (WendzelNNTPd 2)
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.5 Network File System
Pfeil 17.5.1 NFS-Server aufsetzen
Pfeil 17.5.2 Clients konfigurieren
Pfeil 17.6 FTP
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 smb.conf
Pfeil 17.7.4 Samba, LDAP & Co.
Pfeil 17.8 Zusammenfassung
Pfeil 17.9 Aufgaben

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

17 NetzwerkdiensteZur nächsten Überschrift

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.


Rheinwerk Computing - Zum Seitenanfang

17.1 inetd und xinetdZur 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. [Fn. 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 sind dabei 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. [Fn. 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 von (x)inetd verwalteter Dienst wird erst gestartet, wenn ein Verbindungswunsch vorliegt. Der entsprechende 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].

Rheinwerk Computing - Zum Seitenanfang

17.1.1 inetdZur 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: [Fn. 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.]

Listing 17.1 Ausschnitt aus einer inetd.conf

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

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. [Fn. 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. [Fn. 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. [Fn. 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.


Rheinwerk Computing - Zum Seitenanfang

17.1.2 tcpdZur 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

Listing 17.2 Ohne tcpd

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

wird folglich ein Eintrag der Form

Listing 17.3 Mit tcpd: Form

Dienst [stream/dgram] Protokoll [no]wait Benutzer  \
tcpd-Binary [Dienst-Name bzw. Binary des externen \
Dienstes]

Listing 17.4 Mit tcpd: ein Beispiel

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

Rheinwerk Computing - Zum Seitenanfang

17.1.3 xinetdZur nächsten ÜberschriftZur vorigen Überschrift

Die Konfiguration des Superservers xinetd [Fn. 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 über die Datei /etc/xinetd.conf abgewickelt. Diese Datei ist allerdings anders aufgebaut als /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 Hostname, Prozess-ID, Benutzer-ID, Verbindungszeit und Exit-Status festgehalten. Tritt aber 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.

Listing 17.5 Eine defaults-Sektion

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
}

Dienste konfigurieren

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

Listing 17.6 Konfiguration eines FTP-Servers

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
}

Für TCP wählt man auch beim xinetd die Stream-Option als Socket-Typ 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.

>> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux Handbuch






 Linux Handbuch


Zum Katalog: Linux Server






 Linux Server


Zum Katalog: Raspberry Pi






 Raspberry Pi


Zum Katalog: Ubuntu 14.04 LTS






 Ubuntu 14.04 LTS


Zum Katalog: Roboter bauen mit Arduino






 Roboter bauen
 mit Arduino


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
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.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de