Visualiser

TCP/IP sous Linux
Serveur réseau
Fac-similé contenant la table des matières,
le préambule et quelques pages du chapitre 1.
Auteur
Jean-François Bouchaudy
GUIDE DE FORMATION
La marque © TSOFT est une marque déposée.
La collection des guides de formation © TSOFT est éditée par la société TSOFT.
Toutes les marques citées dans cet ouvrage sont des marques déposées par leurs propriétaires respectifs
Tous les efforts ont été faits par TSOFT pour fournir dans cet ouvrage une information claire et exacte à
la date de parution. TSOFT n’assume de responsabilités, ni pour son utilisation, ni pour les contrefaçons
de brevets ou atteintes de tierces personnes qui pourraient résulter de cette utilisation.
Réf : TS0061
TCP/IP sous Linux
Serveur Réseau
Auteur : Jean François Bouchaudy
septembre 2003
Editeur
Tsoft
10, rue du Colisée
75008 Paris
http://www.tsoft.fr
Tél. : 01 56 88 29 64
Fax : 01 53 76 03 64
©TSOFT, Paris 2003
Toute représentation ou reproduction intégrale ou partielle faite sans le consentement de l’auteur ou de
ses ayants droit ou ayants cause est illicite selon le Code de la propriété intellectuelle (Art L 122-4) et
constitue une contrefaçon réprimée par le Code pénal. Seules sont autorisées (Art 122-5) les copies ou
reproductions strictement réservées à l’usage privé du copiste et non destinées à une utilisation collective,
ainsi que les analyses et courtes citations justifiées par le caractère critique, pédagogique ou d’information
de l’œuvre à laquelle elles sont incorporées, sous réserve, toutefois, du respect des dispositions des
articles L122-10 à L122-12 du même Code relatives à la reproduction par reprographie.
Avant-propos
Le monde des réseaux est complexe, touffu, incompréhensible pour le non-spécialiste.
Dans ce livre, nous nous intéressons à la mise à disposition sur le réseau des
applications depuis un serveur Linux. Un responsable d’applications réseau peut
résoudre beaucoup de problèmes grâce à Internet, encore lui faut-il de solides
connaissances de base et déjà un savoir pratique.
Ce livre essaie de répondre à cet ambitieux programme. Il veut d’abord donner au
lecteur un savoir pratique. Il apprend à administrer, à gérer les applications que l’on
trouve habituellement sur un serveur Linux. Évidemment, les logiciels stratégiques,
comme Apache, Samba ou Postfix sont traités de manière plus détaillée.
Dans l’apprentissage de chaque application on évite les explications destinées aux
néophytes (« pour les nuls »), on va tout de suite à l’essentiel, en privilégiant le mode
texte (commandes et fichiers de configuration textes). Ce mode est le seul utilisé par
l’expert. Il permet aussi une compréhension profonde des logiciels et des mécanismes
réseaux. Les copies d’écran et les « assistants » sont le plus souvent de la poudre aux
yeux qui donnent l’illusion d’un savoir faire en masquant la complexité sous-jacente.
Ce livre veut également donner un panorama très complet des protocoles réseaux
sous-jacents aux applications réseau. Cette vision est encore une fois pragmatique. On
est à l’opposé d’une approche universitaire. Un protocole est vu tel qu’il apparaît dans
les logs ou dans les analyseurs réseau. On ne donne pas de détails inutiles, les RFC
sont là pour çà et ces derniers sont donnés en référence.
On traite des applications réseaux sous Linux, pourquoi ce choix ? C’est tout simple,
Linux est un système gratuit et un des plus utilisés dans le monde des réseaux. Il est
idéal autant pour l’étudiant en informatique, que pour l’autodidacte ou le responsable
d’applications réseau exigeant.
Le lecteur doit-il être déjà un expert en Linux ou en Réseau ? Non, Internet lui a sans
doute déjà permis d’avoir une grande autonomie. Par ailleurs, les deux livres Linux
Administration et TCP/IP sous Linux : Administration réseau, dans la même
collection, donnent de solides bases, respectivement dans l’administration d’un
système Linux et dans les réseaux TCP/IP.
Cher ami des pingouins, bonne lecture !
© Tsoft – TCP/IP sous Linux : Serveur réseau
Table
des matières
MODULE 1 : APPLICATIONS RESEAUX ...........................................................1-1
La gestion d’une application réseau......................................................................................1-2
inetd .......................................................................................................................................1-7
xinetd ...................................................................................................................................1-12
Dépannage d’une application réseau...................................................................................1-17
Atelier 7 : Les applications réseaux.....................................................................................1-23
MODULE 2 : S ERVICES DE BASE ...................................................................2-1
Les services réseaux ..............................................................................................................2-2
FTP ........................................................................................................................................2-7
Les commandes remotes......................................................................................................2-15
LPD, LPRng ........................................................................................................................2-21
CUPS ...................................................................................................................................2-32
X-Window...........................................................................................................................2-39
VNC.....................................................................................................................................2-47
Atelier 13 : Les services de base .........................................................................................2-51
MODULE 3 : S ERVICES D’ANNUAIRES ...........................................................3-1
Les services gérés par l’administrateur .................................................................................3-2
DHCP ....................................................................................................................................3-4
DNS .....................................................................................................................................3-22
LDAP...................................................................................................................................3-42
Whois...................................................................................................................................3-68
Atelier 10 : Les services annuaires ......................................................................................3-71
© Tsoft – TCP/IP sous Linux : Serveur réseau
T-1
Table des matières
MODULE 4 : S ERVICES ONC........................................................................4-1
Les RPC-ONC.......................................................................................................................4-2
NFS......................................................................................................................................4-11
NIS ......................................................................................................................................4-22
Atelier 11 : Les services ONC.............................................................................................4-35
MODULE 5 : APACHE ...................................................................................5-1
Apache, introduction.............................................................................................................5-2
Un site Web en 1/4 d’heure ...................................................................................................5-9
Les protocoles du Web ........................................................................................................5-17
La configuration d’Apache ..................................................................................................5-25
Les sites dynamiques...........................................................................................................5-39
La sécurité du Web..............................................................................................................5-48
Atelier 14 : Apache .............................................................................................................5-55
MODULE 6 : S AMBA.....................................................................................6-1
Samba, introduction ..............................................................................................................6-2
Un serveur Samba en 1/4 d’heure .........................................................................................6-7
Les protocoles Windows .....................................................................................................6-21
La configuration de Samba .................................................................................................6-41
Dépannage ...........................................................................................................................6-52
Quelques configurations ......................................................................................................6-67
Linux comme client SMB ...................................................................................................6-78
Atelier 15 : Samba ...............................................................................................................6-83
MODULE 7 : L’ E-MAIL .................................................................................7-1
L’architecture de l’e-mail TCP/IP.........................................................................................7-2
Les protocoles du email.........................................................................................................7-6
Un serveur de messagerie en 1/4 d’heure............................................................................7-17
POSTFIX.............................................................................................................................7-25
Sendmail..............................................................................................................................7-34
La sécurité de l’e-mail.........................................................................................................7-40
Atelier 16 : L’e- mail............................................................................................................7-48
ANNEXES
Annexe A : Solutions des exercices ..................................................................................... A-3
Annexe B : Références bibliographiques........................................................................... A-17
T-2
© Tsoft – TCP/IP sous Linux : Serveur réseau
Module 2 : Préambule
Ce guide a pour objectif de former des administrateurs d’applications réseaux TCP/IP
en environnement Linux. Une connaissance minimale de Linux et de son
administration est souhaitable. En outre il est fortement conseillé de posséder des
notions concernant TCP/IP. Les livres Linux Administration et TCP/IP sous Linux :
Administration réseau, dans la même collection, donnent de solides bases,
respectivement dans l’administration d’un système Linux et dans les réseaux TCP/IP.
Support de formation
Le support de formation se divise en 7 modules :
Applications réseau (inetd/xinetd, …).
Services de base (Telnet, FTP, R-commands, LPD, …).
Services d’annuaires (DHCP, DNS, LDAP, WHOIS).
Services ONC (RPC, NFS, NIS).
Apache.
Samba.
L’e-mail (Sendmail, Postfix).
Chaque module est suivi d’un atelier composé de plusieurs exercices.
Le support convient à des formations concernant l’administration d’un serveur réseau
Linux, sur une durée de un à cinq jours. Chaque logiciel serveur, Apache, Samba,
Postfix peut faire l’objet d’un cours spécifique sur deux jours.
© Tsoft – TCP/IP sous Linux : Serveur réseau
P-1
Préambule
Progression pédagogique
Erreur ! Liaison incorrecte.
Module 1: Applications réseaux
Ce module traite principalement du démarrage des applications serveurs via les
services inetd et xinetd. Il enseigne également la logique du dépannage d’une
application réseau quelconque.
Module 2 : Services de base
Ce module survole quelques services simples ou peu stratégiques : FTP, les
commandes remote (rlogin, rcp, rsh, ..), les services d’impression LPD et CUPS, XWindow et VNC.
Module 3 : Services d’annuaires
Dans ce module, le lecteur apprend à configurer des services stratégiques de
l’administration d’un réseau : le DNS, le DHCP et les annuaires LDAP.
Normalement, un administrateur d’applications réseaux n’est pas amené à gérer ces
services, qui sont plutôt du ressort de l’administrateur réseau. On a décidé de les
inclure dans ce support. En effet, ils sont importants pour la culture d’un responsable
d’application. D’autre part, ce dernier épaule souvent l’administrateur réseau en gérant
des serveurs d’annuaires secondaires.
Module 4 : Services ONC
Un poste Linux peut être intégré dans un réseau de systèmes Unix/Linux grâce aux
services NFS et NIS. Ce module traite de ce sujet.
Module 5 : Apache
Apache correspond sans doute à l’utilisation principale d’un serveur Linux. Apache
est le logiciel serveur Web le plus répandu dans le monde. Sa robustesse, sa
modularité sont légendaires. Ce module décrit l’installation d’Apache, sa
configuration élémentaire et avancée, par exemple la création de sites virtuels. Il
aborde également la description du protocole http et les paramètres lié s à la
sécurisation d’un site.
Module 6 : Samba
Une autre utilisation très courante d’un serveur Linux est d’abriter un serveur Samba.
Ce logiciel transforme votre ordinateur en serveur Windows. Ce module décrit
l’installation de Samba, quelques configurations élémentaires et quelques
configurations avancées, par exemple, Samba comme PDC ou Samba comme membre
d’un domaine. Il traite également des commandes de diagnostics et des protocoles
Microsoft qu’utilise Samba. Le module se termine en montrant comment transformer
sont poste Linux en client Windows.
Module 7 : L’e-mail
Linux comme serveur de messagerie clôt la liste des principales utilisations d’un
serveur Linux. Le module décrit la structure d’un e-mail, les protocoles SMTP, POP et
P-2
© Tsoft – TCP/IP sous Linux : Serveur réseau
Applications réseau
IMAP et le paramétrage élémentaire des applications Sendmail, Imap et Fetchmail.
L’accent est mis sur l’étude du serveur SMTP postfix. Ce dernier s’impose à la fois
pour sa simplicité de configuration et ses qualités en terme de sécurité.
Progression pédagogique conseillée
La majorité des applications présentées peuvent être étudiées indépendamment. Nous
conseillons au lecteur de lire le premier module au préalable. Il présente les services
inetd/xinetd et le dépannage d’une application réseau. La connaissance de ces sujets
est utile qu’elle que soit l’application réseau étudiée. Les conventions utilisées dans ce
livre
© Tsoft – TCP/IP sous Linux : Serveur réseau
1-3
Préambule
Les conventions utilisées dans ce livre
Les types et les polices
Les noms de fichiers, de commandes, d’options ou de procédures sont écrits en police
courrier. Par exemple, la commande ifconfig affiche l’adresse IP du système.
Une référence ou un confer (cf.) s’écrivent en italique. Par exemple, la lecture de
l’ouvrage Linux administration est vivement conseillée. La lecture de cet ouvrage
nécessite une connaissance de l’administration Linux (cf. l’ouvrage Linux
Administration).
Les remarques
Les remarques, les conseils ou les notes de mises en garde sont précédés et suivis
d’une ligne de séparation. Le type de note est en gras. Par exemple :
Remarque
Les mises en gardes commencent par le mot attention en majuscule suivi d’un point
d’exclamation : ATTENTION !
Les exemples
Les exemples apparaissent en police courrier sur fond grisé, comme dans l’exemple
ci-dessous. Le texte saisi par l’utilisateur est indiqué en gras.
L’invite d’une commande contient ou se résume au caractère « $ » dans le cas d’une
session activée par un simple utilisateur. Elle est représentée, ou contient le caractère
« # » dans le cas d’une session activée par l’administrateur Linux (root). Si l’invite ne
contient aucun de ces signes, il correspond à une session utilisateur. Une commande
peut être suivie d’un commentaire introduit par le caractère « # ». Par exemple :
jf@bulbizarre:~ > date
mar jui 1 21:26:54 CEST 2003
jf@bulbizarre:~ > uname –n # affiche le nom du système
bulbizarre
jf@bulbizarre:~ > PS1="$ "
$ cal 9 1952
septembre 1952
di lu ma me je ve sa
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
$ su Password:
bulbizarre:~ # tail -1 /etc/shadow
cathy:4wzavvZ4fJC36:11775:0:99999:7:0::
bulbizarre:~ #
P-4
© Tsoft – TCP/IP sous Linux : Serveur réseau
• /etc/services
• /etc/inetd.conf
• /etc/xinetd.d/telnet
1
Module 1 : Applications
réseaux
Objectifs
Savoir activer une application réseau en utilisant inetd ou xinetd. Connaître les
principales raisons de non-fonctionnement d’une application et en conséquence savoir
dépanner (grossièrement) une application.
Contenu
La gestion d’une application réseau
inetd
xinetd
Le dépannage d’une application réseau
Références
Man
inetd(8), xinetd(8)
© Tsoft – TCP/IP sous Linux : Serveur réseau
1-1
Applications réseau
La gestion d’une application réseau
La gestion d'une application réseau
n
L’activation du serveur
l
par un RC
l
par inetd/xinetd
n
Le port et éventuellement l’adresse d’écoute du serveur
n
L’UID et le GID du serveur
n
L’activation des journaux de bord et le niveau de déboguage
TSOFT - TCP/IP sous Linux
Module 7 : Les applications réseaux - 7.2
Objectif : comprendre quels sont les principaux paramètres de configuration d’une
application réseau.
La configuration d’un client
La configuration d’une application cliente est généralement simple, voire inexistante.
On doit évidemment indiquer l’adresse du serveur et son port. Le plus souvent
l’adresse du serveur est donnée au moment du lancement de l’application par
l’utilisateur. Le port du serveur est normalement implicite. Si l’application cliente est
bien écrite, elle récupère cette information à partir du fichier /etc/services.
Si l’application utilise un proxy, elle doit comporter les références de celui-ci, c’est-àdire son adresse IP et son numéro de port.
Enfin il faut éventuellement paramétrer la sécurité d’accès. Dans le cas le plus simple,
l’utilisateur doit indiquer un nom et un mot de passe dans la phase de connexion au
serveur. Il faut dans d’autres cas mémoriser dans des fichiers les informations
d’authentific ation, par exemple le nom et le mot de passe déjà cités ou bien un couple
de clé publique et secrète. Dans ce dernier cas, il faut protéger le fichier en lecture.
La configuration d’une application serveur
La configuration d’une application serveur est beaucoup plus complexe. Voici les
éléments de configuration les plus importants et communs à toute application serveur :
• L’activation du serveur par un RC ou par inetd/xinetd.
• Le port d’écoute du serveur.
• L’UID et le GID du serveur.
• L’activation des journaux de bord et le niveau de débogage.
1-2
© Tsoft – TCP/IP sous Linux : Serveur réseau
Applications réseau
L’activation du serveur
Une application serveur est activée grâce à un script de démarrage ou bien grâce aux
serveurs inetd/xinetd.
Si l’on utilise un script de démarrage (ou RC, « Run Command »), une instance au
moins du serveur est présente en permanence même s’il n’y a aucun client. Le script
permet aussi bien d’activer que d’arrêter l’application. On peut faire en sorte qu’il soit
activé automatiquement au démarrage et à l’arrêt du système (cf. le livre Linux
Administration). Voici par exemple l’arrêt/démarrage du serveur de nom :
# /etc/init.d/named
# /etc/init.d/named
start
stop
# démarre le serveur DNS.
# arrêt du serveur DNS.
Si l’on utilise le service inetd ou xinetd, l’application serveur n’est active que s’il
y a des clients. Seule l’application inetd/xinetd est présente en permanence (cf. le
prochain chapitre).
Le port d’écoute du serveur
Comme pour l’application cliente, le port d’écoute du serveur est normalement lu à
partir du fichier /etc/services.
Très fréquemment, le fichier de configuration du serveur ou ses arguments d’appels
permettent de modifier cette valeur. Ceci permet notamment d’avoir plusieurs
instances du serveur en fonction. On peut utiliser cette possibilité pour tester une
nouvelle version du logiciel serveur.
Quand une application serveur s’associe à un port d’écoute, elle peut spécifier le ou
les cartes réseaux sur lesquelles elle attend des demandes de connexion. Le plus
souvent elle se met à l’écoute de l’ensemble des cartes.
L’UID et le GID du serveur
L’UID et le GID de l’application serveur sont des paramètres très importants car ils
fixent ses droits. Le plus souvent un serveur doit être activé sous le compte root, et
dans ce cas il a tous les droits sur le système. Si l’application est boguée ou vérolée,
un pirate peut prendre en main complètement le système à distance.
Les journaux de bords d’une application
La voix royale pour déboguer une application est de lire les journaux de bord générés
par l’application elle -même. Encore faut-il que l’on demande à l’application de les
générer et que l’on fixe correctement le niveau de débogage.
D’autre part, il faut choisir de rediriger les journaux de bord vers le système Syslog.
Ce service peut gérer l’ensemble des journaux de bord du système et des applications
(cf. le livre Linux Administration).
Le fichier /etc/services
Le fichier /etc/services contient une table de correspondance entre le nom
symbolique d’un port réseau UDP ou TPC et son équivalent numérique. Chaque
application cliente ou serveur doit normalement l’utiliser pour en déduire le numéro de
port.
Les noms et les numéros qui sont listés dans ce fichier sont attribués par l’IANA. Son
site Web nous renseigne sur les valeurs que l’on peut ajouter à ce fichier.
Extrait :
# more /etc/services
© Tsoft – TCP/IP sous Linux : Serveur réseau
1-3
Applications réseau
#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single
well-known
# port number for both TCP and UDP; hence, most entries here have
two entries
# even if the protocol doesn't support UDP operations.
#
# This list could be found on:
#
http://www.isi.edu/in-notes/iana/assignments/portnumbers
#
#
0/tcp
Reserved
#
0/udp
Reserved
tcpmux
1/tcp
# TCP Port Service
Multiplexer
tcpmux
1/udp
# TCP Port Service
Multiplexer
compressnet
2/tcp
# Management Utility
compressnet
2/udp
# Management Utility
compressnet
3/tcp
# Compression Process
compressnet
3/udp
# Compression Process
rje
5/tcp
# Remote Job Entry
rje
5/udp
# Remote Job Entry
echo
7/tcp
Echo
#
echo
7/udp
Echo
#
discard
9/tcp
Discard sink null
#
discard
9/udp
Discard sink null
#
systat
11/tcp
users
# Active Users
systat
11/udp
users
# Active Users
daytime
13/tcp
Daytime
# (RFC 867)
daytime
13/udp
Daytime
# (RFC 867)
netstat
15/tcp
# Unassigned [was netstat]
qotd
17/tcp
quote
# Quote of the Day
qotd
17/udp
quote
# Quote of the Day
msp
18/tcp
# Message Send Protocol
msp
18/udp
# Message Send Protocol
chargen
19/tcp
ttytst source
# Character
Generator
chargen
19/udp
ttytst source
# Character
Generator
ftp-data
20/tcp
# File Transfer [Default
Data]
ftp-data
20/udp
# File Transfer [Default
Data]
ftp
21/tcp
# File Transfer [Control]
fsp
21/udp
# UDP File Transfer
ssh
22/tcp
# SSH Remote Login Protocol
ssh
22/udp
# SSH Remote Login Protocol
telnet
23/tcp
# Telnet
telnet
23/udp
# Telnet
1-4
© Tsoft – TCP/IP sous Linux : Serveur réseau
Applications réseau
La surveillance d’une application serveur
La surveillance d’une application se fait essentiellement via les commandes ps,
netstat et lsof. La visualisation des journaux de bord est bien sûr le complément
indispensable.
ps -ef
La commande ps -ef est la technique la plus simple. Elle affiche la totalité des
processus actifs. On l’utilise le plus souvent avec la commande grep pour tester la
présence d’une application particulière.
# ps -ef |more
UID
PID PPID
root
1
0
root
2
1
root
3
1
root
4
0
root
5
0
root
6
0
root
7
0
root
8
1
root
1226
1
root
1227
1
root
1228
1
root
2186
1
root
2502
1
...
# ps -ef | grep sshd
root
2502
1
#
C
0
0
0
0
0
0
0
0
0
0
0
0
0
STIME
Nov20
Nov20
Nov20
Nov20
Nov20
Nov20
Nov20
Nov20
Nov20
Nov20
Nov20
Nov20
Nov20
TTY
?
?
?
?
?
?
?
?
?
?
?
?
?
0 Nov20 ?
TIME
00:00:06
00:00:00
00:00:00
00:00:00
00:00:03
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00
00:00:02
CMD
init [5]
[keventd]
[kapm-idled]
[ksoftirqd_CPU0]
[kswapd]
[bdflush]
[kupdated]
[mdrecoveryd]
[jfsIO]
[jfsCommit]
[jfsSync]
[raid5d]
/usr/sbin/sshd
00:00:02 /usr/sbin/sshd
netstat -a
La commande netstat -a nous donne beaucoup d’informations. En effet elle
affiche l’état des sockets réseaux UDP et TCP. On peut en déduire les applications
TCP serveur car elles sont en attente de connexion (état LISTEN). On voit les sockets
TCP établie et enfin on sait les ports UDP utilisés.
Options :
-n Affiche les valeurs numériques. Par défaut, la commande réalise une résolution
des noms des machines et des noms des ports réseaux.
-p
Affiche le PID de l’application qui a ouvert le port.
Exemples :
# netstat -an | more
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address
Foreign Address
tcp
0
0 0.0.0.0:1024
0.0.0.0:*
tcp
0
0 0.0.0.0:513
0.0.0.0:*
tcp
0
0 0.0.0.0:515
0.0.0.0:*
tcp
0
0 0.0.0.0:37
0.0.0.0:*
tcp
0
0 0.0.0.0:79
0.0.0.0:*
tcp
0
0 0.0.0.0:111
0.0.0.0:*
tcp
0
0 0.0.0.0:80
0.0.0.0:*
tcp
0
0 0.0.0.0:10000
0.0.0.0:*
tcp
0
0 0.0.0.0:6000
0.0.0.0:*
© Tsoft – TCP/IP sous Linux : Serveur réseau
State
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
1-5
Applications réseau
tcp
0
0 0.0.0.0:23
tcp
0
0 0.0.0.0:7741
tcp
0
2 192.168.218.12:23
ESTABLISHED
tcp
0
0 :::113
tcp
0
0 :::22
udp
0
0 0.0.0.0:517
udp
0
0 0.0.0.0:518
udp
0
0 0.0.0.0:520
udp
0
0 0.0.0.0:10000
udp
0
0 0.0.0.0:37
udp
0
0 0.0.0.0:177
# netstat -a | grep ssh
tcp
0
0 *:ssh
# netstat -ap | grep ssh
tcp
0
0 *:ssh
2502/sshd
#
0.0.0.0:*
0.0.0.0:*
192.168.218.1:1395
LISTEN
LISTEN
:::*
:::*
0.0.0.0:*
0.0.0.0:*
0.0.0.0:*
0.0.0.0:*
0.0.0.0:*
0.0.0.0:*
LISTEN
LISTEN
*:*
LISTEN
*:*
LISTEN
lsof
La commande lsof liste les fichiers ouverts y compris les sockets.
Références
Man
services(5), netstat(8), lsof(8), ps(1)
Internet
http://www.iana.org/assignments/ports-numbers
Le site officiel qui liste les numéros de ports enregistrés auprès des instances
d’Internet.
Livre
Linux Administration, de A. Berlat, J-F. Bouchaudy et G. Goubet.
1-6
© Tsoft – TCP/IP sous Linux : Serveur réseau
Applications réseau
inetd
inetd
/etc/services
/etc/inetd.conf
Client
Serveurs
ftp
ftp
inetd
inetd
3245
ftpd
ftpd
21
httpd
httpd
80
Socket associée
au port 3245
TCP/IP
TCP/IP
TCP/IP
TCP/IP
Dialogue réseau
TSOFT - TCP/IP sous Linux
Module 7 : Les applications réseaux - 7.3
Objectifs : savoir activer une application réseau en utilisant inetd. Comprendre la
logique de fonctionnement du wrapper tcpd.
Introduction
Quand on utilise le service inetd, l’application serveur n’est active que s’il y a des
clients. Seul le démon inetd est présent en permanence.
Comment inetd connaît-il les ports réseaux à surveiller et les applications serveur à
activer en conséquence ? Toutes ces informations lui sont communiquées par son
fichier de configuration /etc/inetd.conf.
Le fichier /etc/inetd.conf
Chaque ligne du fichier /etc/inetd.conf décrit une application serveur gérée par
inetd. Les différents champs du fichier sont séparés par des espaces ou des
tabulations. Par ailleurs, il est possible d’ajouter le symbole « # » devant une ligne
pour la mettre en commentaire. Inversement la suppression de ce caractère ouvre le
port réseau.
Voici la description des différents champs :
• 1er champ : le nom du port qui identifie l’application. Inetd lit le fichier
/etc/services pour en déduire le numéro de port équivalent, et se met à
l’écoute de ce port.
• 2ème et 3ème champ : le type de protocole utilisé par le service réseau. Ces
champs ont pour valeur :
-« stream tcp » si elle utilise TCP.
-« dgram udp » si elle utilise UDP.
© Tsoft – TCP/IP sous Linux : Serveur réseau
1-7
Applications réseau
• 4ème champ : le paramètre « nowait » indique qu’il y aura un serveur par client,
c’est le cas de in.telnetd, et le paramètre « wait », qu’il y aura un seul serveur
pour l’ensemble des clients. C’est le cas de in.talkd, le serveur qui dialogue
avec la commande talk.
• 5ème champ : l’identité sous laquelle s’exécute l’application serveur, c’est-à-dire
son « UID ».
• 6ème champ : le chemin de l’exécutable de l’application serveur.
• Les autres champs : les arguments de l’application en n’oubliant pas « l’argument
0 » qui correspond normalement au nom de l’application.
Remarque
Certaines applications, très simples, peuvent être gérées directement par inetd. Dans
ce cas le mot clé « internal » remplace le chemin de l’exécutable.
Extrait du fichier /etc/inetd.conf
# more /etc/inetd.conf
# See "man 8 inetd" for more information.
#
# If you make changes to this file, either reboot your machine or
send the
# inetd a HUP signal with "/sbin/init.d/inetd reload" or by hand:
# Do a "ps x" as root and look up the pid of inetd. Then do a
# "kill -HUP <pid of inetd>".
# The inetd will re-read this file whenever it gets that signal.
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path>
<args>
#
# echo stream tcp
nowait root
internal
# echo dgram
udp
wait
root
internal
# discard
stream tcp
nowait root
internal
# discard
dgram
udp
wait
root
internal
# daytime
stream tcp
nowait root
internal
# daytime
dgram
udp
wait
root
internal
# chargen
stream tcp
nowait root
internal
# chargen
dgram
udp
wait
root
internal
time
stream tcp
nowait root
internal
time
dgram
udp
wait
root
internal
#
# These are standard services.
#
# ftp
stream tcp
nowait root
/usr/sbin/tcpd wu.ftpd -a
# ftp
stream tcp
nowait root
/usr/sbin/tcpd proftpd
ftp
stream tcp
nowait root
/usr/sbin/tcpd in.ftpd
#
# If you want telnetd not to "keep-alives" (e.g. if it runs over a
ISDN
# uplink), add "-n". See 'man telnetd' for more details.
telnet stream tcp
nowait root
/usr/sbin/tcpd in.telnetd
# nntp stream tcp
nowait news
/usr/sbin/tcpd
/usr/sbin/leafnode
# smtp stream tcp
nowait root
/usr/sbin/sendmail
sendmail -bs
1-8
© Tsoft – TCP/IP sous Linux : Serveur réseau
Applications réseau
# printer
stream tcp
nowait root
/usr/sbin/tcpd
/usr/bin/lpd -i
#
# Shell, login, exec and talk are BSD protocols.
# The option "-h" permits ``.rhosts'' files for the superuser.
Please look at
# man-page of rlogind and rshd to see more configuration
possibilities about
# .rhosts files.
shell
stream tcp
nowait root
/usr/sbin/tcpd in.rshd -L
# shell stream tcp
nowait root
/usr/sbin/tcpd in.rshd -aL
#
# If you want rlogind not to "keep-alives" (e.g. if it runs over a
ISDN
# uplink), add "-n". See 'man rlogind' for more details.
login
stream tcp
nowait root
/usr/sbin/tcpd in.rlogind
# login stream tcp
nowait root
/usr/sbin/tcpd in.rlogind a
exec
stream tcp
nowait root
/usr/sbin/tcpd in.rexecd
talk
dgram
udp
wait
root
/usr/sbin/tcpd in.talkd
ntalk
dgram
udp
wait
root
/usr/sbin/tcpd in.talkd
#
#
# Pop et al
#
# pop2 stream tcp nowait root /usr/sbin/tcpd in.pop2d
pop3
stream tcp nowait root /usr/sbin/tcpd /usr/sbin/popper s
#
# Imapd - Interactive Mail Access Protocol server
# Attention: This service is very insecure
# imap stream tcp
nowait root
/usr/sbin/tcpd imapd
#
# Comsat - has to do with mail.
#
# comsat
dgram
udp
wait
root
/usr/sbin/tcpd
in.comsat
#
# The Internet UUCP service.
#
# uucp stream tcp
nowait uucp
/usr/sbin/tcpd
/usr/lib/uucp/uucico -l
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
#
# tftp
dgram
udp wait
root /usr/sbin/tcpd in.tftpd -s
/tftpboot
# bootps
dgram
udp wait
root
/usr/sbin/bootpd bootpd -c
/tftpboot
#
# Finger, systat and netstat give out user information which may be
# valuable to potential "system crackers." Many sites choose to
disable
# some or all of these services to improve security.
© Tsoft – TCP/IP sous Linux : Serveur réseau
1-9
Applications réseau
# Try "telnet localhost
see that
# information yourself!
#
finger stream tcp
w
# systat
stream
/bin/ps -auwwx
# netstat
stream
/bin/netstat -a
#
systat" and "telnet localhost netstat" to
nowait
nobody
/usr/sbin/tcpd
in.fingerd -
tcp
nowait
nobody
/usr/sbin/tcpd
tcp
nowait
root
/usr/sbin/tcpd
Fonctionnement de inetd
Soit la ligne suivante du fichier /etc/inetd.conf qui décrit le service FTP :
ftp
stream
tcp
nowait
root
/usr/sbin/wu.ftpd
wu.ftpd -a
Quand inetd est activée, il se met à l’écoute du port TCP 21 (inetd déduit le
numéro de port du fichier /etc/services). Quand une demande de connexion
arrive sur ce port, il active l’application /usr/sbin/wu.ftpd et lui transmet les
arguments « wu.ftpd -a ». L’application est activé sous le compte de root. Si une
deuxième demande de connexion survient sur le même port, inetd active une autre
instance d’application serveur en suivant la recommandation « nowait ». Quand une
instance d’application serveur a terminé son travail, elle meurt, et en final inetd se
retrouve le plus souvent seul actif.
Activation/arrêt du service
Le démon inetd est normalement activé au démarrage par un script RC, par exemple
/etc/rc.d/rc2.d/S20inetd.
Il est possible d’arrêter ou de relancer le service de manière interactive :
# /etc/init.d/inetd
# /etc/init.d/inetd
#
stop
start
# arrêt du service
# réactive le service
Si l’on vient de modifier le fichier /etc/inetd.conf, il faut prévenir le démon en
lui envoyant le signal « 1 » (SIGHUP).
# ps -e | grep inetd
309 ?
00:00:00 inetd
# kill -HUP 309
#
Le « wrapper » tcpd
Un « wrapper » offre une couche de protection. Il contrôle l’accès à des services
réseaux grâce à des fichiers contenant des listes de contrôle d’accès ou ACL (Access
Control List).
Lors de l’installation de Linux, la plupart des services réseaux activés à travers le
fichier inetd.conf, le sont via tcpd.
Extrait de inetd.conf :
ftp
1-10
stream
tcp
nowait
root
/usr/sbin/tcpd wu.ftpd
–a
© Tsoft – TCP/IP sous Linux : Serveur réseau
Applications réseau
Chaque fois qu’une requête est adressée au service FTP, le démon principal du réseau,
inetd, active tcpd plutôt que in.ftpd directement.
tcpd met à jour un journal de bord (log) et vérifie que le client est autorisé à utiliser
le service. Dans l’affirmative, tcpd exécute le serveur demandé, wu.ftpd dans
l’exemple.
Les listes de contrôle d’accès sont conservées dans les fichiers :
/etc/hosts.allow
/etc/hosts.deny
Le format de ces fichiers est décrit dans le manuel hosts_access(5). Si les fichiers
n’existent pas ou sont vides, il n’y a pas de contrôle d’accès.
Dans le cas contraire, l’administrateur du système Linux utilise le fichier
hosts.allow ou hosts.deny pour indiquer les clients qui sont autorisés ou
interdits de service.
Le contrôle d’accès est global, pour l’ensemble des services, ou peut être décidé
service par service, pour chaque ordinateur hôte ou pour un domaine.
La structure d’une ligne de l’un des deux fichiers ACL est :
liste_de_démon : liste_de_client [ : commande ]
Les listes sont composées des identificateurs de démons ou de clients, séparés par des
virgules ou des espaces.
Les noms des hôtes ou des clients peuvent être des mots clés pour désigner un
ensemble prédéfini.
Extrait du fichier /etc/hosts.allow :
wu.ftpd : LOCAL, .societe.com
Tous les clients dont le nom ne comporte pas de point (LOCAL) et les clients du
domaine societe.com ont le droit d’utiliser le service FTP de l’hôte.
Références
Man
inetd(8), inetd.conf(5), services(5), tcpd(8), hosts_access(5).
© Tsoft – TCP/IP sous Linux : Serveur réseau
1-11