Ceci est la première version depuis que Linuxports est devenu l'auteur de ce document. Tout d'abord je dois dire que nous avons l'espoir que dans les prochains mois ce document vous rendra service et que nous serons capables de vous fournir des informations précises en temps et en heure sur les publications en relation avec les réseaux sous linux.
Ce document, comme les autres HOWTO dont nous avons la charge, va devenir totalement différent et deviendra rapidement ``le réseau sous Linux-HOWTO'' et pas seulement le NET3-4-HOWTO. Nous traiterons de sujets tels que PPP, VPN et autres ...
Le premier document NET-FAQ fut écrit par Matt Welsh et Terry Dawson en vue de répondre aux questions qui étaient souvent posées au sujet des réseaux sous Linux, ceci en un temps où le LPD (Linux Documentation Project) n'existait pas encore. Il s'agissait alors des toutes premières versions de développement du noyau réseau sous Linux. Le document NET-2-HOWTO, qui succéda au NET-FAQ, fut l'un des premiers documents du LDP HOWTO et il traitait de ce qui fut appelé version 2, et plus tard version 3, du logiciel réseau du noyau Linux. Ce document prend la suite à son tour et ne traite que de la version 4 du noyau réseau Linux et plus spécialement des versions du noyau 2.x et 2.2.x.
Les versions précédentes de ce document étaient devenues plutôt énormes en raison du grand nombre de sujets abordés. Pour résoudre ce problème, un certain nombre de documents HOWTO ont été créés et traitent de sujets spécifiques. Ce document fait référence à ceux qui sont pertinents et aborde les sujets qui ne sont pas encore couverts par d'autres documents.
Nous apprécions toujours les retours d'informations. Contactez-nous s'il vous plait à: poet@linuxports.com.
Encore une fois, si vous trouvez quelque chose d'erroné ou bien si vous désirez que l'on ajoute quelque chose, contactez-nous.
Ce document est organisé de haut en bas. Les premières sections traitent d'informations sur le matériel et peuvent être sautées si cela ne vous intéresse pas ; ensuite il y a une discussion générale sur ce qui concerne les réseaux, et vous devez être certains de l'avoir assimilée avant de poursuivre vers les paragraphes plus spécifiques. Le restant, qui traite d'informations ``plus technologiques'', est regroupé en trois parties principales : informations sur Ethernet et IP, les technologies qui concernent le matériel PC le plus courant, et les technologies moins répandues.
La démarche que je suggère pour parcourir ce document est donc la suivante :
Ces paragraphes s'appliquent à chaque technologie, ou presque, décrite plus tard, il est donc important que vous les ayez compris. D'autre part, j'espère que beaucoup de lecteurs connaissent déjà le sujet.
Vous devez savoir comment votre réseau est, ou sera, conçu et quels matériels et types de technologies vous utiliserez.
Cette section traite de la configuration de base d'Ethernet et des différentes possibilités offertes par Linux, et qui concernent le réseau, telles que le pare-feu, le routage avancé, etc..
Cette section parle de PLIP, PPP, SLIP, et RNIS, les technologies utilisées habituellement sur les stations personnelles.
Si vos besoins ne concernent pas IP et/ou un matériel courant, vous trouverez à la fin des détails sur les protocoles non-IP et les matériels de communication particuliers.
Si vous allez réellement essayer de configurer votre réseau, prenez soigneusement note de tout problème éventuel.
Si vous rencontrez des problèmes qui ne sont pas traités dans ce document, reportez-vous au paragraphe donnant les endroits où l'on peut en obtenir ou bien envoyer des reports de bogues.
Le réseau est amusant, profitez-en.
Il n'y a pas de conventions spéciales utilisées ici, mais vous devez faire
attention à la façon de montrer les commandes. En regardant la documentation
habituelle d'Unix, toute commande qui doit être tapée est précédée d'une
invite du shell.
Ce document utilise "user%" comme invite pour les commandes
ne nécessitant pas de privilèges de superutilisateur, et "root#"
pour les commandes que l'on doit exécuter comme utilisateur root. J'ai préféré
utiliser "root#" à la place du classique "#" pour éviter
toute confusion avec les extraits de scripts shell, ou le signe dièse
est utilisé pour définir les lignes de commentaires.
Lorsque les ``Options de Compilation du noyau'' sont mentionnées, elles le sont avec le format utilisé par menuconfig. Elles devraient donc être compréhensibles même si vous (comme moi) n'êtes pas familiers avec menuconfig. Si vous avez un doute sur la déclaration des options, faire tourner le programme une fois ne peut qu'apporter de l'aide.
Notez que tous les liens avec les autres documents HOWTO sont locaux
pour vous aider à naviguer avec vos documents LDP copiés localement, au
cas où vous utiliseriez la version html de ce document. Si vous ne possédez
pas l'ensemble des documents, chaque HOWTO peut être récupéré sur
metalab.unc.edu
(répertoire /pub/Linux/HOWTO) ou l'un de ses nombreux miroirs.
Développer une nouvelle implémentation noyau de l'ensemble du protocole tcp/ip, de qualité, et qui marcherait aussi bien que les produits existants, n'était pas une tâche facile. La décision de ne pas partir d'une implémentation existante fut prise à un moment où il y avait un doute sur d'éventuelles restrictions sur les droits de copie, en raison de décisions de justice U.S., et à un moment où il y avait beaucoup d'enthousiasme pour faire différemment et peut-être même mieux que ce qui avait été fait auparavant.
Le premier volontaire pour diriger le développement fut
Ross Biro <biro@yggdrasil.com>. Ross produisit une
implémentation de routines simple, incomplète, mais
parfaitement utilisable, à laquelle fut ajouté un pilote
Ethernet pour la carte interface réseau WD-8003.
Ce fut suffisant pour que beaucoup de personnes essayent le logiciel et
même certains s'arrangèrent pour se connecter, avec
cette configuration, sur le réseau Internet en direct.
La pression de la communauté Linux qui
s'occupait du développement du support réseau augmenta, et
pour finir, la convergence de cette pression injuste et de ses propres
obligations l'emportèrent sur les avantages que Ross en tirait; il
arrêta donc sa tâche de coordinateur de développement.
Les efforts de Ross pour faire démarrer le projet, son acceptation de la
responsabilité de faire vraiment quelque chose d'utile dans de
telles circonstances mouvementées, furent le point de départ
de tout le travail ultérieur et donc un
élément essentiel du succès du produit actuel.
Orest Zborowski <obz@Kodak.COM> produisit la première interface
socket BSD pour le noyau Linux.
Ce fut un grand pas en avant et permit à beaucoup d'applications
réseau existantes d'être portées sous Linux sans grandes modifications.
À peu près à cette époque Laurence Culhane
<loz@holmes.demon.co.uk>
développa les premiers pilotes Linux pour supporter le protocole SLIP.
Ceci permit à beaucoup de gens qui n'avaient pas accès à
un réseau Ethernet d'essayer le logiciel réseau. Puis certains
utilisèrent ce pilote pour se connecter sur l'Internet.
Cela donna à encore plus de personnes un aperçu de ce qui
serait possible si Linux avait un support complet pour
le réseau et augmenta le nombre d'utilisateurs utilisant et
expérimentant ce logiciel réseau.
L'une des personnes qui a aussi activement travaillé sur la
construction du support réseau fut
Fred van Kempen <waltje@uwalt.nl.mugnet.org>.
Après la période d'incertitude qui suivit le retrait
de Ross, Fred offrit son temps et accepta le
rôle de conducteur du développement sans rencontrer d'opposition.
Fred avait quelques projets ambitieux quant à la direction vers laquelle
il voulait porter le logiciel réseau Linux, et il se mit à
progresser dans ces directions.
Fred produisit une série de code réseau appelée le code
noyau `NET-2' (le code `NET' étant celui de Ross), qui permit à
beaucoup de personnes de l'utiliser avec intérêt.
Ensuite Fred mit nombre d'innovations dans la poursuite du développement,
telle que l'interface de périphérique dynamique, le support du
protocole radio-amateur AX-25 et une implémentation réseau
conçue de manière plus modulaire.
Le code NET-2 de Fred fut utilisé par un grand nombre d'enthousiastes,
ce nombre augmentant au fur et à mesure de l'utilisation du logiciel
dans le monde. Le logiciel réseau à ce moment
était constitué encore d'un grand nombre de patches qui devaient être
appliqués au code noyau et n'était pas inclus dans la distribution normale.
Le document NET-FAQ et son successeur NET-2-HOWTO décrivait la
procédure assez complexe pour que tout cela fonctionne.
Fred se concentra sur le développement d'innovations et cela prenait
du temps. La communauté des utilisateurs s'impatientait, car elle
voulait avoir quelque chose
fonctionnant correctement et qui satisferait 80% des utilisateurs
puis, comme avec Ross, la pression sur le responsable du développement
augmentait.
Alan Cox <iialan@www.uk.linux.org> proposa une solution pour
améliorer la situation.
Il proposa de prendre le code NET-2 de Fred, de le déboguer, de le
rendre fiable et stable si bien qu'il satisferait l'utilisateur de base
impatient, relâchant ainsi la pression sur Fred qui pourrait continuer
son oeuvre.
Alan se mit au travail avec un certain succès et sa première
version du code réseau Linux fut appelée `Net-2D(ebugged;)'.
Le code fonctionnait de manière fiable avec plusieurs configurations
typiques et l'utilisateur de base était content. Alan avait vraiment
des idées et une compétence à lui pour contribuer au
projet et de nombreuses discussions concernant la direction que devait
prendre le code NET-2 furent suivies d'effet.
Il se développa alors deux écoles distinctes dans la communauté
Linux, l'une ayant pour principe `que ça marche d'abord, puis on
améliorera ensuite' et l'autre `améliorer d'abord'. Linus arbitra
finalement et offrit son aide aux efforts de développement d'Alan et
inclut son code dans la distribution standard du noyau.
Cela plaçait Fred dans une situation délicate. Tout
développement de longue haleine souffrirait de l'absence
d'utilisation et d'essais par l'utilisateur de base et cela signifierait que
les progrès seraient longs et difficiles.
Fred continua à travailler encore quelque temps, puis se retira
finalement, et Alan devint le nouveau pilote de développement
du code réseau dans le noyau Linux.
Donald Becker <becker@cesdis.gsfc.nasa.gov> révéla
rapidement ses talents dans les aspects de bas niveau du réseau et
produisit une énorme quantité de pilotes Ethernet, presque tous
ceux inclus dans les noyaux actuels étant de lui. Il y a d'autres personnes
qui ont apporté une contribution significative, mais le travail de
Donald est prolifique et mérite donc une mention spéciale.
Alan continua à affiner le code NET-2-D(ebugged) pendant
un certain temps, tout en progressant sur certains des sujets qui restaient
en suspens dans la liste des `TODO' (NdT : `À Faire').
Pendant que les sources du noyau Linux 1.3.* faisaient leurs
premiers pas, le code réseau migra vers la distribution NET-3,
sur laquelle les versions actuelles sont fondées.
Alan travailla sur de multiples aspects du code réseau et, avec
l'assistance d'un grand nombre de personnes talentueuses venant de la
communauté Linux, développa le code dans toutes sortes de
directions. Alan produisit des pilotes de périphériques
réseau, le premier standard AX.25 et les implémentations IPX.
Alan continua à rafistoler le code, le restructurant petit à
petit et l'amenant à son niveau d'aujourd'hui.
Le support PPP fut ajouté par Michael Callahan
<callahan@maths.ox.ac.uk>
et Al Longyear <longyear@netcom.com>, ce qui fut important pour
accroître le nombre de personnes utilisant Linux désireuses
d'aller sur le réseau.
Jonathon Naylor <jsn@cs.nott.ac.uk> apporta sa contribution en
améliorant le code AX.25 d'Alan et en y ajoutant les protocoles
NetRom et Rose. Le support AX.25/NetRom lui-même est tout à fait
significatif, car aucun autre système d'exploitation que Linux ne peut
se vanter d'avoir un support natif pour ce protocole.
Il y a eu bien sûr des centaines d'autres personnes qui ont apporté une contribution significative à la couche réseau de Linux. Vous en retrouverez certains plus tard dans les paragraphes traitant de technologies spécifiques, d'autres ont collaboré aux modules, pilotes, corrections de bogues, suggestions, rapports d'essais et support moral. Dans tous les cas chacun peut se prévaloir d'avoir joué un rôle et offert ce qu'il pouvait. Le code réseau Linux est un excellent exemple de ce que l'on peut obtenir avec un style Linux de développement anarchique, si cela ne vous a pas encore étonné, et on le voit encore, le développement ne s'est pas arrêté.
Il y a un grand nombre d'endroits où l'on peut trouver de bonnes informations sur le réseau Linux.
Il y a un tas de spécialistes disponibles. On peut en trouver une liste sur LinuxPorts Consultants Database.
Alan Cox, l'actuel mainteneur du code réseau Linux entretient une page web contenant les points principaux du réseau actuel, et ses nouveaux développements, à l'adresse : www.uk.linux.org.
Une autre bonne source est un livre écrit par Olaf Kirch ayant pour titre
Network Administrators Guide. C'est une oeuvre du
Linux Documentation Project
et vous pouvez le lire de manière interactive sur
Network Administrators Guide HTML version
ou bien vous pouvez l'obtenir sous différents formats via ftp sur :
metalab.unc.edu LDP ftp archive. Le livre d'Olaf est
très compréhensible et fournit un point de vue
de haut niveau sur la
configuration réseau sous Linux.
(NdT : ce livre a été traduit en français de manière remarquable par le regretté René Cougnenc)
Il existe un groupe de discussion dédié au réseau et, en ce qui le concerne dans la hiérarchie Linux, c'est : comp.os.linux.networking
Il existe une liste de diffusion à laquelle vous pouvez vous inscrire, et où vous pourrez poser des questions en relation avec le réseau Linux. Pour souscrire vous devez envoyer un message par courrier électronique :
To: majordomo@vger.rutgers.edu
Subject: (rien du tout)
Message:
subscribe linux-net
Sur les différents réseaux IRC, il y a souvent des canaux
#linux sur lesquels des personnes sont en mesure de répondre
à vos questions au sujet du réseau Linux.
Souvenez-vous lorsque vous faites part d'un problème d'y inclure le plus possible de détails nécessaires. Plus spécialement indiquez les versions des logiciels que vous utilisez, en particulier la version du noyau, les versions des outils tels que pppd ou dip, et la nature exacte des problèmes que vous rencontrez. Cela veut dire prendre note de la syntaxe exacte des messages d'erreurs que vous recevez, et les commandes que vous avez exécutées.
si vous désirez des informations générales de base sur tcp/ip, alors je vous recommande de regarder les documents suivants :
ce document se trouve à la fois sur en version texte et en version postscript.
ce document se trouve à la fois sur en version texte et en version postscript.
Si vous recherchez des informations plus détaillées je vous recommande chaudement :
Internetworking with TCP/IP, Volume 1 : principes, protocoles et architectures, par Douglas E. Comer,ISBN 0-13-227836-7, Prentice Hall publications, 3ème édition, 1995.
Si vous voulez apprendre comment écrire des applications réseau dans un environnement compatible Unix, je vous recommande également chaudement :
Unix Network Programming par W. Richard Stevens ISBN 0-13-949876-1, Prentice Hall publications, 1990.Une deuxième édition de ce livre va apparaitre sur les rayons : le nouveau livre comporte 3 volumes : voyez le site de Prentice Hall pour en savoir plus.
Vous pouvez essayer aussi le groupe de discussions : comp.protocols.tcp-ip.
Une importante source d'informations techniques concernant l'Internet et la suite des protocoles TCP/IP sont les RFC. RFC est l'acronyme de `Request For Comment' et c'est le moyen habituel de soumettre et de s'informer des normes de protocoles Internet. Il y a beauccoup d'endroits où sont stockées ces RFC. Beaucoup de ceux-ci sont des sites ftp, d'autres fournissent des accès WWW avec un moteur de recherche qui cherche les bases de données RFC avec des mots-clés particuliers.
Une source possible de RFC est : la base de données RFC de Nexor.
Vous devez connaître et bien comprendre les paragraphes suivants avant d'essayer de configurer votre réseau. Ce sont des principes de base qui s'appliquent, indépendamment de la nature du réseau que vous voulez mettre en place.
Avant de commencer à construire ou configurer votre réseau, vous aurez besoin de certaines choses. Les plus importantes sont :
À noter:
La majorité des distributions actuelles sont livrées avec l'option réseau activée, en sorte que vous n'avez pas besoin de recompiler le noyau. Si vous utilisez du matériel bien connu, tout ira bien. Par exemple: cartes 3COM, cartes NE2000 ou cartes Intel. Cependant si vous devez recompiler le noyau, voyez les informations qui suivent.
Si le noyau que vous utilisez actuellement ne supporte pas les types de réseau ou les cartes que vous voulez utiliser, vous aurez besoin des sources du noyau pour pouvoir le recompiler avec les options adéquates.
Pour les utilisateurs des principales distributions comme RedHat, Caldera, Debian ou Suse, ce n'est plus vrai. Tant que vous restez avec un matériel de grande diffusion, il n'est pas nécessaire de recompiler le noyau, à moins que vous n'ayez une exigence très spécifique.
Vous pouvez toujours obtenir les sources du dernier noyau sur : ftp.cdrom.com. Ce n'est pas le site officiel mais ils ont BEAUCOUP de bande passante et BEAUCOUP d'utilisateurs peuvent se connecter en même temps. Le site officiel est kernel.org, mais dans la mesure du possible, utilisez s'il vous plaît celui que je viens de donner. Souvenez-vous que ftp.kernel.org est particulièrement surchargé. Utilisez un miroir.: (NdT : et bien sûr ftp.lip6.fr) .
Normalement les sources du noyau doivent être désarchivées
dans le répertoire /usr/src/linux.
Pour savoir comment appliquer les patches et compiler le noyau, lisez le
Kernel-HOWTO.
Pour savoir comment configurer les modules du noyau, lisez
le ``Modules-mini-HOWTO''. Enfin, le fichier README qui
se trouve dans les sources du noyau ainsi que le répertoire
Documentation donnent beaucoup de renseignements au lecteur courageux.
Sauf indication contraire, je vous recommande de vous en tenir à une version stable du noyau (celle avec un chiffre pair en seconde place dans le numéro de version). Les versions de développement (avec un chiffre impair en seconde place dans le numéro de version) peuvent avoir une structure ou autre chose qui peut poser problème avec les logiciels de votre système. Si vous n'êtes pas certain de résoudre ce type de problèmes, avec en plus ceux qui existeraient sur d'autres logiciels, ne les utilisez pas.
D'autre part, certaines caractéristiques décrites dans ce document ont été introduites lors du développement des noyaux 2.1.x, vous devez donc choisir : soit vous restez avec la version 2.0 et attendez la version 2.2, avec une distribution mise à jour contenant tous les nouveaux outils, soit vous utilisez la version 2.1 et cherchez les divers programmes qui supportent les nouvelles fonctionnalités. Lorsque j'écris ce paragraphe, en août 1998, la version de développement en cours est la 2.1.115 et la 2.2 va apparaître prochainement.
Ces outils sont les programmes utilisés pour configurer les fichiers de périphériques réseau. Ils vous permettent d'assigner des adresses aux périphériques et de configurer des routes par exemple.
La plupart des distributions Linux modernes sont fournies avec les outils de réseau, aussi si vous avez fait votre installation à partie d'une distribution et que vous n'avez pas encore installé les outils de réseau, vous devez le faire.
Si vous n'avez pas fait l'installation à partir d'une distribution, vous aurez alors besoin des sources pour les compiler vous-même. Ce n'est pas difficile.
Les outils de réseau sont maintenus par Bernd Eckenfels et se trouvent sur : ftp.inka.de et sont recopiés sur : ftp.linux.uk.org.
Vous pouvez également obtenir les derniers paquetages RedHat sur net-tools-1.51-3.i386.rpm
Soyez sûrs de choisir la version la mieux appropriée à votre noyau et suivez les instructions incluses dans le paquetage.
Pour installer et configurer la version actuelle (au moment où j'écris), vous devrez faire :
user% tar xvfz net-tools-1.33.tar.gz
user% cd net-tools-1.33
user% make config
user% make
root# make install
Ou avec les paquetages Redhat:
root# rpm -U net-tools-1.51-3.i386.rpm
De plus, si vous voulez configurer une protection pare-feu ou utiliser le masquage IP vous aurez besoin de la commande ipfwadm. La dernière version peut-être obtenue sur : ftp.xos.nl. Encore une fois, de nombreuses versions existent. Soyez sûrs de prendre celle qui s'adapte le mieux à votre noyau. Notez que les fonctionnalités pour pare-feu de Linux ont changé pendant le développement de la version 2.1 et ont été remplacées par ipchains dans la version 2.2 du noyau. ipfwadm ne s'applique donc qu'aux versions 2.0 du noyau. Ce qui suit ne s'applique donc qu'aux distributions ayant la version 2.0 ou antérieure.
Redhat 5.2 ou inférieure
Caldera pré-version 2.2
Slackware pré-version 4.x
Debian pré-version 2.x
Pour installer et configurer la version existante au moment de l'écriture de ce document, vous devez lire le document howto IPchains situé sur Le projet de Documentation Linux.
Notez que si vous avez la version 2.2 (ou l'ancienne 2.1) du noyau, ipfwadm n'est pas le bon outil pour configurer le pare-feu. Cette version de NET-3-HOWTO n'est pas en accord avec les nouveaux réglages du pare-feu. Si vous désirez plus d'informations détaillées sur ipchains, référez-vous au document mentionné ci-dessus.
Les programmes d'application réseau sont des programmes tels que
telnet et
ftp et leurs serveurs respectifs. David Holland
s'occupe maintenant d'une distribution
très répandue, qui est maintenant maintenue par netbug@ftp.uk.linux.org.
Vous pouvez obtenir cette distribution sur :
ftp.uk.linux.org.
Les adresses de protocole Internet (IP) sont composées de quatre octets. La convention d'écriture est appelée `notation décimale pointée'. Sous cette forme chaque octet est converti en un nombre décimal (0-255), en omettant les zéros de tête (à moins que ce nombre ne soit lui-même un zéro) et chaque octet est séparé par le caractère `.'. Par convention, chaque interface d'un hôte ou routeur possède une adresse IP. Il est permis, dans certaines circonstances, que la même adresse IP soit utilisée sur différentes interfaces d'une même machine, mais, en général, chaque interface possède sa propre adresse.
Les réseaux IP (Protocole Internet) sont des séquences contiguës d'adresses IP. Toutes les adresses d'un même réseau ont des chiffres en commun. La partie d'adresse commune à toutes les adresses d'un réseau s'appelle la `partie réseau' de l'adresse. Les chiffres restants s'appellent `partie hôte'. Le nombre de bits qui sont partagés par toutes les adresses d'un même réseau est appelé masque de réseau (netmask) et c'est le rôle du masque de réseau de déterminer quelles adresses appartiennent à `son' réseau et celles qui ne sont pas concernées. Par exemple :
---------------------------------------- ----------------
Adresse hôte (host address) 192.168.110.23
Masque de réseau (network mask) 255.255.255.0
Partie réseau (network portion) 192.168.110.
Partie hôte (host portion) .23
---------------------------------------- ----------------
Adresse réseau (network address) 192.168.110.0
Adresse de diffusion (broadcast address) 192.168.110.255
---------------------------------------- ----------------
Toute adresse qui est `ANDÉE bit à bit' avec son masque de réseau révèlera l'adresse du réseau auquel elle appartient. L'adresse du réseau est par conséquent l'adresse de plus petit nombre dans l'ensemble des adresses et a toujours la partie hôte codée avec des zéros.
L'adresse de diffusion est une adresse spéciale que chaque hôte
du réseau écoute en même temps que son adresse personnelle.
Cette adresse est celle à laquelle les datagrammes sont envoyés
si tous les hôtes du réseau sont en mesure de les recevoir.
Certains types de données telles que les informations de routage et les
messages d'alerte sont transmis vers l'adresse de diffusion de telle sorte que
tous les hôtes du réseau peuvent les recevoir en même temps.
Il y a deux standards utilisés de manière courante pour
définir ce que doit être l'adresse de diffusion. Le plus largement
utilisé est de prendre
l'adresse la plus haute possible du réseau comme adresse de diffusion.
Dans l'exemple ci-dessus ce serait
192.168.110.255. Pour d'autres raisons, certains sites ont
adopté la convention d'utiliser l'adresse de réseau comme adresse
de diffusion. En pratique cela n'a pas beaucoup d'importance, mais vous devez
être sûrs que tous les hôtes du réseau sont
configurés avec la même adresse de diffusion.
Pour des raisons d'administration, il y a quelque temps, lors du développement du protocole IP, des ensembles d'adresses ont été organisés en réseaux et ces réseaux ont été regroupés en ce que l'on a appellé classes. Ces classes donnent un certain nombre de réseaux de tailles standards auxquels on peut assigner des adresses. Ces classes sont :
----------------------------------------------------------
|Classe de |Masque de | Adresses de réseau |
| réseau | réseau | |
----------------------------------------------------------
| A | 255.0.0.0 | 0.0.0.0 - 127.255.255.255 |
| B | 255.255.0.0 | 128.0.0.0 - 191.255.255.255 |
| C | 255.255.255.0 | 192.0.0.0 - 223.255.255.255 |
|Multicast| 240.0.0.0 | 224.0.0.0 - 239.255.255.255 |
----------------------------------------------------------
Le type d'adresse que vous devez utiliser dépend de ce que vous voulez faire exactement. Vous pouvez utiliser une combinaison des actions suivantes pour obtenir l'ensemble des adresses dont vous aurez besoin :
Vous devez alors contacter un des administrateurs du réseau et lui demander les informations suivantes :
Si vous construisez un réseau privé et que vous n'ayez pas l'intention de vous connecter à l'Internet, vous pouvez alors choisir n'importe quelle adresse. Cependant, pour des raisons de sécurité et de fiabilité, il y a quelques adresses de réseau IP réservées à cet usage. Elles sont spécifiées dans la RFC 1597 et sont les suivantes :
----------------------------------------------------------- | ALLOCATIONS POUR RÉSEAUX PRIVÉS | ----------------------------------------------------------- | Classe | Masque de | Adresses de réseau | | réseau | réseau | | ----------------------------------------------------------- | A | 255.0.0.0 | 10.0.0.0 - 10.255.255.255 | | B | 255.255.0.0 | 172.16.0.0 - 172.31.255.255 | | C | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 | -----------------------------------------------------------
Vous devez d'abord décider de la dimension de votre réseau et choisir ensuite les adresses dont vous avez besoin.
Il y a plusieurs possibilités de procédures
de démarrage d'un système Linux. Après le
démarrage du noyau,
celui-ci exécute toujours un programme appelé
`init'. Ce programme lit le fichier de configuration appelé
/etc/inittab et commence le processus de démarrage. Il y a
quelques variantes de
init, bien que maintenant tout le monde se dirige vers la variante
System V (cinq), développée par Miguel van Smoorenburg.
Bien que que le programme init soit toujours le même, les réglages
du processus de démarrage se font différemment suivant le type de distribution.
Habituellement le fichier /etc/inittab contient une entrée
telle que :
si::sysinit:/etc/init.d/boot
Cette ligne spécifie le nom du fichier script qui prend en charge
réellement la séquence de démarrage. Ce fichier est en
quelque sorte équivalent au fichier MS-DOS AUTOEXEC.BAT.
Il y a aussi d'autres scripts appelés par le script de démarrage, et souvent le réseau est configuré dans l'un de ceux-ci.
Le tableau suivant peut être utilisé comme guide suivant le système que vous avez :
-------------------------------------------------------------------------------
Distrib. |Interface Config/Routage | Initialisation serveur
-------------------------------------------------------------------------------
Debian | /etc/init.d/network | /etc/rc2.d/*
-------------------------------------------------------------------------------
Slackware| /etc/rc.d/rc.inet1 | /etc/rc.d/rc.inet2
-------------------------------------------------------------------------------
RedHat | /etc/rc.d/init.d/network | /etc/rc.d/rc3.d/*
-------------------------------------------------------------------------------
Notez que les distributions Debian et RedHat utilisent tout un répertoire
pour les scripts qui mettent en route les services du système (et
habituellement l'information ne se situe pas dans ces fichiers, par exemple
les systèmes RedHat stockent l'ensemble de la configuration du système
sous /etc/sysconfig, où elle est récupérée par les scripts de
démarrage). Si vous voulez saisir les détails du processus de démarrage,
je vous conseille de vérifier /etc/inittab ainsi que la documentation
accompagnant init. Linux Journal va également publier un article
sur l'initialisation des systèmes, et nous pointerons sur lui dès qu'il sera
disponible sur le réseau.
La plupart des distributions récentes incluent un programme qui permet de configurer de nombreux types d'interfaces réseau. Si vous en possédez une, regardez si ce programme vous convient au lieu de tenter une configuration manuelle.
-----------------------------------------
Distrib | Programme de configuration réseau
-----------------------------------------
RedHat | /sbin/netcfg
Slackware | /sbin/netconfig
-----------------------------------------
Sur beaucoup de systèmes Unix les périphériques réseau apparaissent dans le répertoire /dev . Il n'en est pas de même avec Linux. Les périphériques réseau sont créés dynamiquement par les logiciels et ne nécessitent donc pas de fichiers de périphériques.
Dans la majorité des cas, le périphérique réseau
est créé automatiquement par le pilote de
périphérique pendant son initialisation lorsqu'il détecte votre matériel.
Par exemple le pilote Ethernet crée
les interfaces eth[0..n] une à une quand il détecte votre
matériel Ethernet. La première carte Ethernet trouvée devient
eth0, la deuxième eth1, etc.
Cependant, dans certains cas, notamment avec SLIP et PPP, les périphériques réseau sont créés par un programme utilisateur. Le même mécanisme séquentiel s'applique sur les périphériques, mais ce n'est pas au moment du démarrage du système. La raison en est que, à l'inverse des dispositifs Ethernet, le nombre de périphériques SLIP ou PPP actifs peut varier dans le temps. Nous y reviendrons plus tard.
Lorsque vous avez tous les programmes requis, votre adresse et les informations réseau, vous pouvez alors configurer vos interfaces. Lorsque nous parlons de la configuration d'interface, nous faisons allusion au processus d'assignation des adresses du périphérique réseau, et au processus de réglage des paramètres configurables. Le programme le plus utilisé pour ce faire est la commande ifconfig (interface configure).
Typiquement vous utilisez une commande comme ci-dessous :
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
Dans ce cas je configure l'interface Ethernet `eth0' avec l'adresse
IP `192.168.0.1' et un masque de réseau `255.255.255.0'.
Le `up' qui termine la commande enjoint à l'interface de devenir
active, mais il peut être omis, étant par défaut. Pour clore une interface,
vous faites juste ``ifconfig eth0 down''.
Le noyau suppose certaines valeurs par défaut lorsque l'on configure les
interfaces. Par exemple, vous pouvez indiquer une adresse de réseau et
une adresse de diffusion, mais si vous ne le faites pas comme nous venons
de le faire dans l'exemple ci-dessus, alors le noyau fera certaines hypothèses
fondées sur le masque de réseau que vous avez fourni, et si vous ne l'avez pas
donnée, sur la classe de l'adresse IP configurée.
Dans mon exemple, le noyau considérera que c'est un réseau de classe C et
configurera une adresse réseau de
`192.168.0.0' et une adresse de diffusion de `192.168.0.255'.
Il y a de nombreuses autres options pour la commande ifconfig . Les plus importantes sont :
active une interface (est fait par défaut).
désactive une interface.
active ou désactive le protocole de résolution d'adresses sur cette interface.
active ou désactive la réception de tous les paquets multicast matériel (Ndt : Les adresses multicast sont un genre d'adresses de diffusion limitées à un groupe de machine qui n'ont pas nécessairement besoin de se trouver sur le même sous-réseau). Le multicast matériel permet à des groupes d'hôtes de recevoir des paquets adressés vers des destinations spéciales. Ce peut être important si vous utilisez des applications comme la vidéoconférence, mais la plupart du temps on ne l'utilise pas.
ce paramètre permet de régler le MTU (Maximum Transfert Unit) sur le périphérique.
ce paramètre permet de fixer le masque de réseau.
ce paramètre ne fonctionne qu'avec certains types de matériels, mais vous permet d'en fixer l'IRQ.
permet d'activer ou de désactiver l'acceptation de datagrammes destinés à l'adresse de diffusion.
permet de fixer l'adresse de la machine à l'extrémité d'un lien point-à-point comme pour slip ou ppp.
permet de fixer l'adresse matérielle de certains périphériques réseau. Ce n'est pas souvent utilisé pour Ethernet, mais utile pour d'autres types de réseau tels que AX.25.
Le `Solveur de Noms' (Name Resolver) fait partie de la
bibliothèque
standard de Linux. Sa première fonction est de convertir des noms
d'hôtes compréhensibles par l'homme, comme
`ftp.funet.fi' , en adresses IP compréhensibles par une machine,
comme 128.214.248.6.
Vous êtes probablement familiers avec l'aspect des noms d'hôtes Internet, mais vous ne savez pas comment ils sont composés ou décomposés. Les noms de domaine Internet sont hiérarchisés par nature, c'est-à-dire qu'ils ont une structure arborescente. Un `domaine' est une famille, ou un groupe de noms. Un `domaine' peut être subdivisé en `sous-domaines'. Un `domaine de premier niveau' est un domaine qui n'est pas un sous-domaine. Les Domaines de Premier Niveau sont spécifiés dans la RFC-920. Quelques exemples :
Organisations Commerciales
Organisations ayant rapport avec l'Éducation
Organisations Gouvernementales (NdT: parfois GOUV en France!)
Organisations Militaires
Autres organisations
Organisations ayant un rapport avec l'internet
il existe des codes de deux lettres qui représentent un pays donné.
Pour des raisons historiques la plupart des domaines appartenant à des
domaines qui ne sont pas basés sur des noms de pays sont pour les
organisations situées aux États-Unis, bien que les États-Unis aient aussi
le code de pays `.us'. Ce n'est plus vrai pour les domaines .com
et .org, qui sont couramment utilisés par des sociétés hors des États-Unis.
Chacun de ces domaines de premier niveau possède des sous-domaines. Les
domaines de premier niveau fondés sur les noms de pays sont
divisés ensuite en sous-domaines basés sur les domaines
com, edu, gov, mil et org . Ainsi par exemple, vous
finissez par : com.au and gov.au pour des organisations
commerciales ou
gouvernementales situées en Australie ; notez que ce n'est pas une règle
absolue, car les politiques réelles dépendant de l'autorité qui donne les noms
pour chaque domaine.
Le niveau de division suivant représente habituellement le nom de l'organisation. Ces sous-domaines sont variables, souvent ils sont fondés sur la structure en départements de l'organisation mais ils peuvent l'être également sur d'autres critères considérés comme rationnels et compréhensibles par les administrateurs réseau de l'organisation.
La partie tout à fait à gauche du nom est toujours le nom unique assigné à la machine hôte et est appelée le nom d'hôte `hostname', la partie de droite du nom est le nom de domaine `domainname' et le nom complet s'appelle le nom de domaine complètement qualifié `Fully Qualified Domain Name' (ou FQDN).
Si l'on examine l'adresse de la machine de Terry par exemple, le nom pleinement
qualifié est
`perf.no.itg.telstra.com.au'. Cela veut dire que le nom d'hôte
est `perf'
et le nom de domaine `no.itg.telstra.com.au'. Le nom de domaine est
fondé sur un domaine de premier niveau basé sur son pays,
l'Australie et comme son adresse électronique appartient à une
organisation commerciale nous avons
`.com' comme domaine de niveau adjacent. Le nom de la
société est (était)
`telstra' et notre structure interne de noms est basé sur la
structure organisationnelle, dans mon cas, ma machine appartient à
l'Information Technology Group, section Network Operations.
Habituellement, les noms sont plutôt plus courts ; par exemple, mon
fournisseur d'accès à l'internet est ``systemy.it'' et mon organisation
à but non lucratif est ``linux.it'', sans sous-domaine com ou
org, aussi mon propre hôte est simplement appelé
``morgana.systemy.it'' et rubini@linux.it est une adresse
électronique valide. Notez que le propriétaire d'un domaine a le droit
d'enregistrer les noms d'hôtes aussi bien
que les noms de sous-domaine ; par exemple le Groupe d'Utilisateur Linux auquel
j'appartiens utilise le domaine pluto.linux.it, car les propriétaires
de linux.it étaient d'accord pour créer un sous-domaine pour ce groupe.
Vous devez connaître le domaine auquel votre nom d'hôte appartient. Le solveur de nom effectue la traduction en faisant appel à un `Serveur de Noms de Domaine', aussi vous devez connaître l'adresse IP d'un serveur de nom local que vous pouvez utiliser.
Il y a trois fichiers que vous devez éditer, nous en parlerons chacun à leur tour.
Le fichier /etc/resolv.conf est le principal fichier de configuration
pour le code de résolution de nom. Son format est très simple.
C'est un fichier texte avec un mot-clé par ligne. Il y a trois
mots-clés typiquement utilisés, qui sont :
ce mot-clé indique le nom de domaine local.
ce mot-clé spécifie une liste d'autres noms de domaine pour rechercher un nom d'hôte.
ce mot-clé, qui peut être utilisé plusieurs fois, spécifie l'adresse IP d'un serveur de nom de domaine pour la résolution de noms.
Un exemple de /etc/resolv.conf pourrait ressembler à ceci :
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
maths.wu.edu.au, et que si l'hôte n'est pas trouvé dans ce
domaine on peut aussi essayer
le domaine wu.edu.au directement. Deux entrées de serveurs de noms
sont fournies, chacune d'elles pouvant être appelée par le
solveur de noms.
Le fichier /etc/hosts est l'endroit où vous mettez les noms et
les adresses IP des hôtes locaux. Si vous mettez un hôte dans ce
fichier, alors vous n'avez pas à interroger le serveur de nom de domaine
pour obtenir son adresse IP. L'inconvénient est que vous devez tenir
votre fichier à jour si l'adresse de cet hôte a changé.
Dans un système bien administré les seuls noms d'hôtes qui
apparaissent habituellement sont l'interface loopback, et le nom des
hôtes locaux.
# /etc/hosts
127.0.0.1 localhost loopback
192.168.0.1 ma.belle.machine
Vous pouvez spécifier plus d'un nom d'hôte, comme montré dans la première entrée (qui est standard pour l'interface loopback).
Si vous voulez faire tourner un serveur de nom local, vous pouvez le faire facilement. Voyez le DNS-HOWTO et tous les documents inclus dans votre version de BIND (Berkeley Internet Name Domain).
L'interface `loopback' est un type spécial d'interface qui permet
de vous connecter à vous-même. Il y a plusieurs raisons pour
faire cela, par exemple si vous voulez faire des essais de logiciel réseau
sans interférer avec quelqu'un d'autre sur votre réseau. Par
convention, l'adresse IP
`127.0.0.1' lui a été assignée. Aussi quelle que
soit la machine où vous êtes, si vous ouvrez une
connexion telnet vers
127.0.0.1 vous atteindrez toujours l'hôte local.
Configurer l'interface loopback est simple et vous devez vous assurer de l'avoir fait (mais notez que cette tâche est habituellement effectuée par les scripts standards d'initialisation).
root# ifconfig lo 127.0.0.1
root# route add -host 127.0.0.1 lo
Nous en dirons plus sur la commande route dans le prochain paragraphe.
Le routage est un vaste sujet. On peut écrire de grandes quantités de textes sur ce sujet. La plupart d'entre vous ont besoin d'un simple routage, et certains même de rien du tout. Je ne parlerai que des principes du routage. Si vous voulez plus d'informations je vous suggère de vous reporter aux références fournies en début du document.
Commençons par une définition. Qu'est-ce que le routage IP ? Voici celle que j'utilise :
Le routage IP est le processus par lequel un hôte, ayant des connexions réseau multiples, décide du chemin par lequel délivrer les datagrammes IP qu'il a reçus.
Il peut être utile d'illustrer cela par un exemple. Imaginez un routeur dans un bureau : il peut avoir un lien PPP sur l'Internet, un certain nombre de segments Ethernet alimentant les stations de travail et un second lien PPP vers un autre bureau. Lorsque le routeur reçoit un datagramme de l'une de ses connexions, le routage est le mécanisme utilisé pour déterminer vers quelle interface il doit renvoyer ce datagramme. De simples hôtes ont besoin aussi de routage, tous les hôtes Internet ayant deux périphériques réseau, l'un étant l'interface loopback décrite auparavant et l'autre est celui qui est utilisé pour parler avec le reste du monde, soit un lien Ethernet, soit une interface série PPP ou SLIP.
Ok, alors comment marche le routage ? Chaque hôte possède une liste spéciale de règles de routage, appelée une table de routage. Cette table contient des colonnes qui contiennent au moins trois champs, le premier étant une adresse de destination, le deuxième étant le nom de l'interface vers lequel le datagramme doit être routé et le troisième, qui est optionnel, l'adresse IP d'une autre machine qui transportera le datagramme vers sa prochaine destination sur le réseau passerelle. Sur Linux vous pouvez voir cette table en utilisant la commande suivante :
user% cat /proc/net/route
user% /sbin/route -n
user% /sbin/netstat -r
Le processus de routage est plutôt simple : un datagramme entrant est reçu, l'adresse de destination est examinée et comparée avec chaque entrée de la table. L'entrée qui correspond le mieux à cette adresse est choisie, et le datagramme est renvoyé vers l'interface spécifiée. Si le champ passerelle est rempli, alors le datagramme est renvoyé vers cet hôte via l'interface spécifiée, sinon l'adresse de destination est supposée comme étant sur le réseau supporté par l'interface.
Pour manipuler ce tableau, une commande spéciale est utilisée. Cette commande prend des arguments et les convertit en appels système pour demander au noyau d'ajouter, supprimer ou modifier des entrées dans la table de routage. Cette commande s'appelle `route'.
Un exemple simple. Imaginez que vous ayez un réseau Ethernet. On vous a
dit que c'est un réseau classe C avec une adresse de
192.168.1.0. On vous fournit une adresse IP
192.168.1.10 pour votre usage et on vous a dit que
192.168.1.1 est un routeur connecté à l'Internet.
La première étape est de configurer l'interface comme indiqué plus haut. Vous utiliserez la commande :
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
192.168.1.* doivent être dirigés vers le
périphérique Ethernet. Vous utiliserez une commande comme ceci :
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
-net' pour indiquer au programme route
que cette entrée est une route réseau.
Un autre choix peut être `-host' qui est une route spécifique
d'une adresse IP.
Cette route vous permettra d'établir des connexions IP avec tous les hôtes sur votre segment Ethernet. Mais qu'en est-il des hôtes IP qui n'y sont pas ?
Ce serait compliqué d'ajouter des routes pour chaque réseau
destinataire, aussi il y a une astuce utilisée pour simplifier la
tâche.
L'astuce est appelée route par `default'. La route par
defaut
s'adapte à toutes les destinations possibles, mais pas très
bien, de telle sorte que si il y a une entrée qui correspond à
l'adresse requise elle sera utilisée à la place de la route par
defaut. L'idée de la route par defaut est simplement de
pouvoir dire `et tout le reste va ici'. Dans l'exemple que j'ai
inventé, on utilisera une entrée telle que :
root# route add default gw 192.168.1.1 eth0
gw' indique à la commande route que le prochain
argument est l'adresse IP, ou le nom, d'une passerelle (gateway) ou
d'une machine routeur
vers qui tous les datagrammes correspondant à cette entrée
seront dirigés pour routage ultérieur.
Ainsi votre configuration complète sera :
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add default gw 192.168.1.1 eth0
rc' concernant le réseau
vous en trouverez
au moins un très semblable à celui-ci. C'est une configuration
courante.
Examinons maintenant une configuration un peu plus compliquée. Imaginons que nous configurions le routeur examiné auparavant, celui qui avait un lien PPP vers l'Internet et des segments LAN alimentant des stations de travail dans le bureau. Supposons que ce routeur ait 3 segments Ethernet et un lien PPP. Notre configuration de routage ressemblerait à ceci :
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
root# route add default ppp0
defaut les capturera toutes, laissant au routeur le soin de les
séparer de manière appropriée. Vous pouvez vous demander
pourquoi la route par défaut n'utilise pas
`gw'.
La raison en est très simple : les protocoles de lien série comme
PPP et SLIP ont seulement deux hôtes sur leur réseau, un à
chaque bout. Spécifier à l'hôte que l'autre bout de la
liaison est une passerelle est sans objet et redondant, car il n'a pas d'autre
choix, aussi vous n'avez pas à indiquer de passerelle pour ce type de
connexions réseau. Les autres types comme Ethernet,
arcnet ou token ring ont besoin que l'on indique une passerelle car ces
réseaux supportent un grand nombre d'hôtes.
La configuration de routage décrite ci-dessus est bien adaptée aux réseaux simples où il n'y a que des chemins uniques entre les destinations. Lorsque vous avez un réseau plus complexe les choses deviennent plus compliquées. Heureusement pour la plupart d'entre vous, ce ne sera pas le cas.
Le gros problème est qu'avec le `routage manuel' ou `routage statique' comme décrit ci-dessus, si une machine ou un lien tombe en panne dans le réseau, alors la seule façon de diriger vos datagrammes vers un autre chemin, s'il existe, est d'intervenir manuellement et d'exécuter les commandes adéquates. Naturellement c'est lourd, lent, peu pratique et source de risques. Des techniques variées ont été développées pour régler automatiquement les tables de routage dans le cas d'incidents sur un réseau où il y a plusieurs routes possibles, toutes ces techniques étant regroupées sous le nom de `protocoles de routage dynamique'.
Vous avez peut-être entendu parler des plus courants. Ce sont RIP (Routing Information Protocol) et OSPF (Open Shortest Path First Protocol). RIP est très souvent utilisé sur les petits ou moyens réseaux d'entreprise. L'OPSF est plus moderne et plus apte à gérer de grands réseaux et mieux adapté dans le cas où il y a un grand nombre de chemins possibles à travers le réseau. Les implémentations usuelles de ces protocoles sont : `routed' - RIP, et `gated' - RIP, OSPF et autres. Le programme `routed' est normalement fourni avec votre distribution Linux ou est inclus dans la paquetage `NetKit' décrit auparavant.
Un exemple pour vous montrer comment et où vous pouvez utiliser un protocole de routage dynamique ressemblerait à ceci :
192.168.1.0 / 192.168.2.0 /
255.255.255.0 255.255.255.0
- -
| |
| /-----\ /-----\ |
| | |ppp0 // ppp0| | |
eth0 |---| A |------//---------| B |---| eth0
| | | // | | |
| \-----/ \-----/ |
| \ ppp1 ppp1 / |
- \ / -
\ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
ppp0\ /ppp1
/-----\
| |
| C |
| |
\-----/
|eth0
|
|---------|
192.168.3.0 /
255.255.255.0
Il est évident que la table de routage sur le routeur A ressemble à ceci :
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
Mais.., si A peut parler à C et si C peut toujours parler à B, pourquoi A ne routerait-il pas ses datagrammes pour B via C, et laisser ensuite C les envoyer à B ? C'est exactement le type de problèmes que les protocoles de routage dynamique comme RIP sont en mesure de résoudre. Si chacun des routeurs A, B et C utilisent un démon de routage (NdT: démon est une francisation familière du vocable informatique anglais daemon, qui signifie Disk And Extension MONitor, c'est à dire qui n'est pas invoqué manuellement mais attend en tâche de fond que quelque chose se passe, que quelque condition se produise. Ce terme fut introduit au départ sous CTSS (Compatible Time Sharing System), un ancêtre du système MULTICS, lui-même parent d'UNIX (voir la traduction de René Cougnenc de `Le système Linux' de M. Welsh et L. Kaufman chez O'Reilly International Thomson), alors leurs tables de routage seront automatiquement réglées pour refléter le nouvel état du réseau même si l'une des liaisons est défectueuse. Configurer un tel réseau est simple, sur chaque routeur vous devez seulement faire deux choses. Dans ce cas, pour le routeur A :
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# /usr/sbin/routed
C'était une très brève explication du routage dynamique et de son utilisation. Si vous voulez d'avantage d'explications reportez-vous aux références listées en début de document.
Les points importants relatifs au routage dynamique sont :
Les serveurs de réseau et les services sont des programmes qui permettent à un utilisateur distant de devenir utilisateur de votre machine Linux. Les programmes serveurs sont à l'écoute des ports réseau. Les ports réseau permettent die demander un service particulier à un hôte particulier et de faire la différence entre une connexion telnet entrante et une connexion ftp entrante. L'utilisateur distant établit une connexion réseau avec votre machine puis le programme serveur, ou démon de réseau, à l'écoute du port, accepte la connexion et s'exécute. Il y a deux façons d'opérer pour les démons de réseau. Les deux sont couramment utilisés en pratique. Ce sont :
le programme démon écoute le port réseau désigné et lorsqu'il y a une connexion, il prend lui-même la connexion en charge pour fournir le service.
le serveur inetd est un programme démon spécial spécialisé dans la conduite des connexions réseau. Il possède un fichier de configuration qui indique quel programme doit être utilisé lorsqu'une connexion entrante est reçue. Chacun des ports service doit être configuré soit avec le protocole tcp, soit avec le protocole udp. Les ports sont décrits dans un autre fichier dont nous parlerons plus tard.
Il y deux fichiers importants que vous devez configurer. Ce sont
/etc/services qui assigne des noms aux numéros de port et
/etc/inetd.conf qui sert pour la configuration du démon de
réseau
inetd .
/etc/servicesLe fichier /etc/services est une simple base de données qui
associe des noms compréhensibles par l'homme à des ports service
compréhensibles par la machine. Son format est tout à fait
simple. Le fichier est un fichier texte dont chaque ligne représente une
entrée de la base de données. Chaque entrée comprend
trois champs séparés par des caractères espace ou tabulation. Ces champs sont :
nom port/protocole alias # commentaire
un simple mot qui représente le service décrit.
ce champ est divisé en deux.
un nombre qui spécifie le numéro de port
où le service désigné sera disponible. La plupart des
services ont des numéros assignés. Ils sont décrits dans la
RFC-1340.
c'est soit tcp soit
udp.
Il est important de noter qu'une entrée comme 18/tcp est
très différente de
18/udp et qu'il n'y a pas de raisons techniques que le même
service existe sur les deux. Normalement le bon sens prévaut et c'est
vraiment pour un service particulier disponible à la fois sur
tcp
et udp que vous verrez une entrée pour les deux..
autre nom qui peut être utilisé pour désigner ce service.
Tout texte apparaissant après le caractère `#' est
ignoré et traité comme commentaire.
/etc/services.Toutes les distributions récentes de Linux fournissent un bon fichier
/etc/services.
Juste au cas où vous construiriez tout depuis
le départ, voici une
copie du fichier
/etc/services fourni avec l'ancienne distribution
Debian .
# /etc/services:
# $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
#
# Network services, Internet style
#
# Notez que c'est la politique actuelle de l'IANA d'assigner un seul numéro
# de port à la fois pour TCP et UDP; ainsi, la plupart des ports ont deux
#entrées même si le protocole ne supporte pas UDP.
# Mis à jour d'après la RFC 1340, ``Assigned Numbers'' (Juillet 1992).
# Il n'y a pas tous les ports, seulement les plus courants.
tcpmux 1/tcp # TCP port service multiplexer
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # message send protocol
msp 18/udp # message send protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
telnet 23/tcp
# 24 - private
smtp 25/tcp mail
# 26 - non assigné
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
re-mail-ck 50/tcp # Remote Mail Checking Protocol
re-mail-ck 50/udp # Remote Mail Checking Protocol
domain 53/tcp nameserver # name-domain server
domain 53/udp nameserver
mtp 57/tcp # deprecated
bootps 67/tcp # BOOTP server
bootps 67/udp
bootpc 68/tcp # BOOTP client
bootpc 68/udp
tftp 69/udp
gopher 70/tcp # Internet Gopher
gopher 70/udp
rje 77/tcp netrjs
finger 79/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
link 87/tcp ttylink
kerberos 88/tcp kerberos5 krb5 # Kerberos v5
kerberos 88/udp kerberos5 krb5 # Kerberos v5
supdup 95/tcp
# 100 - reserve
hostnames 101/tcp hostname # usually from sri-nic
iso-tsap 102/tcp tsap # part of ISODE.
csnet-ns 105/tcp cso-ns # also used by CSO name server
csnet-ns 105/udp cso-ns
rtelnet 107/tcp # Remote Telnet
rtelnet 107/udp
pop-2 109/tcp postoffice # POP version 2
pop-2 109/udp
pop-3 110/tcp # POP version 3
pop-3 110/udp
sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP
auth 113/tcp authentication tap ident
sftp 115/tcp
uucp-path 117/tcp
nntp 119/tcp readnews untp # USENET News Transfer Protocol
ntp 123/tcp
ntp 123/udp # Network Time Protocol
netbios-ns 137/tcp # NETBIOS Name Service
netbios-ns 137/udp
netbios-dgm 138/tcp # NETBIOS Datagram Service
netbios-dgm 138/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp
imap2 143/tcp # Interim Mail Access Proto v2
imap2 143/udp
snmp 161/udp # Simple Net Mgmt Proto
snmp-trap 162/udp snmptrap # Traps for SNMP
cmip-man 163/tcp # ISO mgmt over IP (CMOT)
cmip-man 163/udp
cmip-agent 164/tcp
cmip-agent 164/udp
xdmcp 177/tcp # X Display Mgr. Control Proto
xdmcp 177/udp
nextstep 178/tcp NeXTStep NextStep # NeXTStep window
nextstep 178/udp NeXTStep NextStep # server
bgp 179/tcp # Border Gateway Proto.
bgp 179/udp
prospero 191/tcp # Cliff Neuman's Prospero
prospero 191/udp
irc 194/tcp # Internet Relay Chat
irc 194/udp
smux 199/tcp # SNMP Unix Multiplexer
smux 199/udp
at-rtmp 201/tcp # AppleTalk routing
at-rtmp 201/udp
at-nbp 202/tcp # AppleTalk name binding
at-nbp 202/udp
at-echo 204/tcp # AppleTalk echo
at-echo 204/udp
at-zis 206/tcp # AppleTalk zone information
at-zis 206/udp
z3950 210/tcp wais # NISO Z39.50 database
z3950 210/udp wais
ipx 213/tcp # IPX
ipx 213/udp
imap3 220/tcp # Interactive Mail Access
imap3 220/udp # Protocol v3
ulistserv 372/tcp # UNIX Listserv
ulistserv 372/udp
#
# services spécifiques à UNIX
#
exec 512/tcp
biff 512/udp comsat
login 513/tcp
who 513/udp whod
shell 514/tcp cmd # no passwords used
syslog 514/udp
printer 515/tcp spooler # line printer spooler
talk 517/udp
ntalk 518/udp
route 520/udp router routed # RIP
timed 525/udp timeserver
tempo 526/tcp newdate
courier 530/tcp rpc
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/udp # -for emergency broadcasts
uucp 540/tcp uucpd # uucp daemon
remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem
klogin 543/tcp # Kerberized `rlogin' (v5)
kshell 544/tcp krcmd # Kerberized `rsh' (v5)
kerberos-adm 749/tcp # Kerberos `kadmin' (v5)
#
webster 765/tcp # Network dictionary
webster 765/udp
#
# D'après ``Assigned Numbers'' :
#
#> Les Ports Enregistrés ne sont pas contrôlés par l'IANA et peuvent être
#> utilisés sur la plupart des systèmes par des processus ordinaires
#> ou des programmes exécutés par des utilisateurs ordinaires.
#
#> Les ports sont utilisés dans le TCP [45,106] pour nommer les extrémités
#> des connexions logiques qui transportent les conversations de longue
#> durée. Pour offrir des services à des utilisateurs non connus, un port
#> de service pour contact a été défini. Cette liste spécifie le port utilisé
#> par le processus serveur ainsi que son port de contact. Comme l'IANA ne peut
#> contrôler l'usage de ces ports, on donne ici une liste d'utilisation
#> de ces ports pour être agréable à la communauté.
#
ingreslock 1524/tcp
ingreslock 1524/udp
prospero-np 1525/tcp # Prospero non-privileged
prospero-np 1525/udp
rfe 5002/tcp # Radio Free Ethernet
rfe 5002/udp # Actually uses UDP only
bbs 7000/tcp # BBS service
#
#
# services Kerberos (Project Athena/MIT)
# Notez que ceux-ci sont pour Kerberos v4, et ne sont pas officiels. Les sites
# tournant sous v4 doivent utiliser ceux-ci et annuler les entrées v5 ci-dessus.
#
kerberos4 750/udp kdc # Kerberos (server) udp
kerberos4 750/tcp kdc # Kerberos (server) tcp
kerberos_master 751/udp # Kerberos authentication
kerberos_master 751/tcp # Kerberos authentication
passwd_server 752/udp # Kerberos passwd server
krb_prop 754/tcp # Kerberos slave propagation
krbupdate 760/tcp kreg # Kerberos registration
kpasswd 761/tcp kpwd # Kerberos "passwd"
kpop 1109/tcp # Pop with Kerberos
knetd 2053/tcp # Kerberos de-multiplexor
zephyr-srv 2102/udp # Zephyr server
zephyr-clt 2103/udp # Zephyr serv-hm connection
zephyr-hm 2104/udp # Zephyr hostmanager
eklogin 2105/tcp # Kerberos encrypted rlogin
#
# Services non officiels mais nécessaires (pour NetBSD)
#
supfilesrv 871/tcp # SUP server
supfiledbg 1127/tcp # SUP debugging
#
# Services protocole de délivrance de datagrammes
#
rtmp 1/ddp # Routing Table Maintenance Protocol
nbp 2/ddp # Name Binding Protocol
echo 4/ddp # AppleTalk Echo Protocol
zip 6/ddp # Zone Information Protocol
#
# Services Debian GNU/Linux
rmtcfg 1236/tcp # Gracilis Packeten remote config server
xtel 1313/tcp # french minitel
cfinger 2003/tcp # GNU Finger
postgres 4321/tcp # POSTGRES
mandelspawn 9359/udp mandelbrot # network mandelbrot
# Services locaux
Dans la réalité, le fichier augmente toujours en taille au fur et à mesure
que de nouveaux services apparaissent. Si vous craignez que votre copie
soit incomplète, je vous suggère de copier un nouveau fichier /etc/services provenant d'une distribution récente.
/etc/inetd.confLe fichier /etc/inetd.conf est le fichier de configuration du serveur
démon
inetd . Il sert à dire à inetd ce qu'il doit faire
lorsqu'il reçoit une demande de connexion pour un service particulier.
Pour les services où vous acceptez une connexion vous devez dire
à inetd quel démon serveur de réseau doit tourner, et comment.
Son format est aussi très simple. C'est un fichier texte dont chaque
ligne décrit un service que vous voulez fournir. Tout texte suivant un
`#'
est ignoré et considéré comme commentaire. Chaque ligne
contient sept champs séparés par un nombre quelconque d'espaces
(espace ou tabulation). Le format général est comme suit :
service type_de_socket protocole drapeaux utilisateur chemin arguments
est le nom de service applicable à cette configuration, pris
dans le fichier /etc/services.
ce champ décrit le type de socket que cette
entrée considère comme pertinent, les valeurs permises sont :
stream, dgram, raw, rdm, ou seqpacket.
C'est un peu technique par nature, mais par expérience, presque tous
les services basés sur tcp utilisent stream et presque tous
les services basés sur udp utilisent dgram.
Il n'y a que quelques types de serveurs démons spéciaux utilisant d'autres
valeurs.
le protocole considéré comme valide pour
cette entrée. Il doit correspondre à l'entrée appropriée dans le fichier
/etc/services et sera donc soit tcp soit udp.
Les serveurs basés sur Sun RPC (Remote Procedure Call) utilisent
rpc/tcp ou rpc/udp.
il n'y a en fait que deux valeurs pour ce champ. Celles-ci
disent à inetd si le programme serveur réseau libère le socket
aprés démarrage, et donc si
inetd peut prendre en compte une des prochaines demandes de connexion, ou
bien si inetd doit attendre qu'un autre démon serveur tournant
déjà prenne en charge la nouvelle demande de connexion.
C'est encore compliqué, mais en pratique tous les serveurs
tcp doivent avoir cette entrée positionnée sur
nowait et la plupart des serveurs
udp ont cette entrée positionnée sur wait.
Attention il y a quelques exceptions notables, laissez vous guider par
l'exemple suivant si vous n'êtes pas sûrs.
ce champ décrit quel compte utilisateur extrait de
/etc/passwd sera considéré comme propriétaire du démon
réseau lorsqu'il est lancé. C'est très utile lorsque vous voulez vous
protéger contre les trous de sécurité. Vous pouvez mettre nobody
comme utilisateur pour une entrée si bien que dans le cas où le réseau
comporte une brèche, les dommages éventuels seront minimisés.
Cependant habituellement ce champ est réglé sur root, car
beaucoup de serveurs ont besoin des privilèges de root pour tourner
correctement.
ce champ est le chemin réel du programme à exécuter pour cette entrée.
ce champ correspond au reste de la ligne et est optionnel. Il sert à indiquer les arguments de commande que vous voulez passer au programme serveur au lancement.
/etc/inetd.confComme pour le fichier /etc/services, toutes les distributions modernes
incluent un bon fichier
/etc/inetd.conf pour pouvoir travailler. Ici, pour
être complet , vous trouverez le fichier
/etc/inetd.conf de la distribution
Debian.
# /etc/inetd.conf: voir inetd(8) pour d'autres informations.
#
# Base de données pour la configuration d'un serveur Internet
#
#
# Modifié pour Debian par Peter Tobias <tobias@et-inf.fho-emden.de>
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# Services internes
#
#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
#
# Services standards.
#
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd
#fsp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.fspd
#
# Shell, login, exec et talk sont des protocoles BSD.
#
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd
talk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.ntalkd
#
# Services Mail, news et uucp.
#
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.smtpd
#nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/in.nntpd
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico
#comsat dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.comsat
#
# Pop et autres
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop3d
#
# `cfinger' est le serveur finger GNU de Debian. (NOTE : L'implémentation
# habituelle du démon `finger' permet de le faire tourner avec `root'.)
#
#cfinger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.cfingerd
#finger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.fingerd
#netstat stream tcp nowait nobody /usr/sbin/tcpd /bin/netstat
#systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx
#
# Le service tftp est fourni principalement pour démarrer. La plupart des sites
# l'utilisent seulement sur les machines servant de `serveurs de boot'.
#
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /boot
#bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
#
# Services Kerberos (ils doivent probablement être corrigés)
#
#klogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k
#eklogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k -x
#kshell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd -k
#
# Services tournant UNIQUEMENT sur Kerberos (doivent être probablement corrigés)
#
#krbupdate stream tcp nowait root /usr/sbin/tcpd /usr/sbin/registerd
#kpasswd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/kpasswdd
#
# Services RPC
#
#mountd/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.mountd
#rstatd/1-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rstatd
#rusersd/2-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rusersd
#walld/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rwalld
#
# Fin de inetd.conf.
ident stream tcp nowait nobody /usr/sbin/identd identd -i
Il y a beaucoup de fichiers relatifs à la configuration réseau sous Linux susceptibles de vous intéresser. Vous n'aurez jamais à modifier ces fichiers, mais il est utile de les décrire pour que vous sachiez ce qu'ils contiennent et quelle est leur utilité.
/etc/protocolsLe fichier /etc/protocols est une base de données qui donne la
relation des numéros id de protocole avec leurs noms.
Il est utilisé
par les programmeurs pour leur permettre de spécifier les protocoles
par leur nom dans les programmes et aussi par quelques programmes tels que
tcpdump pour pouvoir afficher en sortie des noms au lieu de
chiffres. La syntaxe générale de ce fichier est :
nom du protocole numéro alias
Le fichier /etc/protocols fourni avec la distribution
Debian est le suivant :
# /etc/protocols:
# $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
#
# Protocoles Internet (IP)
#
# d'après: @(#)protocols 5.1 (Berkeley) 4/17/89
#
# Mise à jour pour NetBSD basee sur la RFC 1340, Assigned Numbers (July 1992).
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # Internet Group Management
ggp 3 GGP # gateway-gateway protocol
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
st 5 ST # ST datagram mode
tcp 6 TCP # transmission control protocol
egp 8 EGP # exterior gateway protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
hmp 20 HMP # host monitoring protocol
xns-idp 22 XNS-IDP # Xerox NS IDP
rdp 27 RDP # "reliable datagram" protocol
iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4
xtp 36 XTP # Xpress Tranfer Protocol
ddp 37 DDP # Datagram Delivery Protocol
idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport
rspf 73 RSPF # Radio Shortest Path First.
vmtp 81 VMTP # Versatile Message Transport
ospf 89 OSPFIGP # Open Shortest Path First IGP
ipip 94 IPIP # Yet Another IP encapsulation
encap 98 ENCAP # Yet Another IP encapsulation
/etc/networksLe fichier /etc/networks a une fonction similaire au fichier
/etc/hosts. Il fournit une simple base de données de noms de
réseau avec des adresses. Son format diffère en ce qu'il n'y a
que deux champs par ligne, et que ces champs sont codés comme ceci :
Nom du réseau adresse de réseau
Un exemple :
loopnet 127.0.0.0
localnet 192.168.0.0
amprnet 44.0.0.0
Lorsque vous utilisez une commande comme route, si une destination
est un réseau, et que ce réseau a une entrée dans le fichier
/etc/networks la commande affichera alors le nom du réseau en
lieu et place de son adresse.
Laissez-moi débuter ce paragraphe en vous mettant en garde que la sécurisation de votre machine et du réseau contre les attaques pernicieuses est un art complexe. Je ne me considère pas du tout comme un expert dans ce domaine et bien que les mécanismes que je vais décrire puissent vous aider, si vous êtes préoccupés par la sécurité, alors je vous recommande d'effectuer vous-même des recherches sur le sujet. Il existe beaucoup de bonnes références sur l'Internet qui traitent du sujet, y compris Security-HOWTO
Une importante règle pratique est :
`N'utilisez pas de serveurs dont vous n'avez pas l'utilité'.
Beaucoup de distributions arrivent avec plein de services
configurés et démarrant automatiquement. Pour assurer quand
même un minimum de sécurité vous devriez aller dans votre
fichier
/etc/inetd.conf et retirez (placez un `#' au début de
la ligne) toute entrée que vous ne comptez pas utiliser.
De bons candidats sont : shell, login, exec,
uucp, ftp, et les services informatifs tels que finger,
netstat and systat.
Il y a plein de sortes de sécurité et de mécanismes de contrôle d'accès ; je vais décrire les plus élémentaires.
Le fichier /etc/ftpusers est un mécanisme simple qui vous
permet d'interdire l'accès de votre machine à certains
utilisateurs de ftp. Il est lu par le programme démon
(ftpd) lorsqu'une connexion ftp est reçue. Le fichier est une
simple liste d'utilisateurs qui ne peuvent pas se connecter. Il ressemble
à :
# /etc/ftpusers - utilisateurs ne pouvant pas se connecter par ftp
root
uucp
bin
mail
Le fichier /etc/securetty vous permet de spécifier sur quels
fichiers de périphériques tty
root a le droit de se connecter. Le fichier
/etc/securetty est lu par le programme de connexion (habituellement
/bin/login). Son format est une liste de fichiers de
périphériques tty autorisés (sur tous les autres root ne peut se
connecter) :
# /etc/securetty - consoles ou root peut se connecter
tty1
tty2
tty3
tty4
Le programme tcpd que vous avez vu dans le fichier
/etc/inetd.conf fournit les mécanismes de contrôle
d'accès et de connexion aux services qu'il a pour but de protéger.
Lorsqu'il est invoqué par le programme inetd, il lit deux fichiers contenant les règles d'accès et il autorise ou interdit l'accès au serveur qu'il protège.
Il cherche dans ces deux fichiers jusqu'à ce qu'il
trouve une correspondance. S'il n'en trouve pas il suppose que l'accès
est autorisé. Il recherche dans l'ordre suivant :
/etc/hosts.allow,
/etc/hosts.deny. Je décrirai chacun d'eux plus tard. Pour une
description complète référez-vous aux pages de manuel
appropriées
(hosts_access(5) est un bon point de départ).
Le fichier /etc/hosts.allow est un fichier de configuration du
programme
/usr/sbin/tcpd. Il contient les hôtes dont l'accès est
autorisé (allowed) et qui peuvent donc utiliser un service
de votre machine.
Le format du fichier est très simple :
# /etc/hosts.allow
#
# <liste des services>: <liste des hôtes> [: commande]
liste des servicesc'est une liste de serveurs, séparés par des virgules,
auxquels les règles d'accès s'appliquent.
Exemples de serveur : ftpd, telnetd, et fingerd.
liste des hôtesc'est une liste de noms d'hôtes, séparés par des virgules (vous
pouvez utiliser également des adresses IP).
Vous pouvez en plus spécifier des noms d'hôtes ou des adresses IP
avec des jokers pour obtenir des groupes d'hôtes.
Des exemples : gw.vk2ktj.ampr.org
pour un hôte spécifique, .uts.edu.au pour tous les
hôtes se terminant par cette chaîne
, 44. pour toutes les adresses IP commençant par ces chiffres.
Il y a quelques expressions pour simplifier la configuration, parmi lesquelles :
ALL pour tous les hôtes, LOCAL pour tout hôte dont le nom
ne contient pas de
`.' c'est à dire appartenant au même domaine que votre
machine, et PARANOID
pour tout hôte dont le nom ne correspond pas avec son adresse
(tricherie dans
le nom). Il y a enfin une expression qui peut être utile.
Il s'agit de EXCEPT qui vous permet de fournir une liste
avec des exceptions. Nous verrons un exemple plus tard.
commandec'est un paramètre optionnel. Ce paramètre est le nom
complet d'une commande (avec son répertoire) qui sera
exécutée
chaque fois qu'il y aura correspondance.
Ce peut être par exemple une commande qui essaiera d'identifier qui se
connecte, ou de générer un message par courrier ou tout message
d'alerte pour l'administrateur système avertissant
que quelqu'un est en
train de se connecter.
On peut y inclure des extensions, par exemple :
%h donnera le nom de l'hôte qui se connecte ou bien son
adresse s'il n'a pas de nom
, %d le programme démon appelé.
Un exemple :
# /etc/hosts.allow
#
# Permet a tout le monde d'utiliser le courrier
in.smtpd: ALL
# telnet et ftp pour les hotes de mon domaine et my.host.at.home.
telnetd, ftpd: LOCAL, myhost.athome.org.au
# finger pour tout le monde, mais garde une trace de l'identite.
fingerd: ALL: (finger @%h | mail -s "finger from %h" root)
Le fichier /etc/hosts.deny est un fichier de configuration du programme
/usr/sbin/tcpd. Ce fichier contient les hôtes qui
n'ont pas l'autorisation d'accéder à
l'un des services de votre machine.
Un exemple simple ressemblerait à ceci :
# /etc/hosts.deny
#
# Interdit l'acces aux hotes ayant des noms suspects
ALL: PARANOID
#
# Interdit l'acces a tous les hotes
ALL: ALL
L'entrée PARANOID est en fait redondante car l'autre
entrée interdit tous les cas.
L'une ou l'autre entrée devrait convenir, en fonction de vos besoins
particuliers.
Mettre ALL: ALL par défaut dans le fichier
/etc/hosts.deny puis autoriser certains services, en liaison avec les
hôtes que vous avez choisis, dans le fichier
/etc/hosts.allow, est la configuration la plus sûre.
Le fichier hosts.equiv est utilisé pour concéder à
certains hôtes des droits d'accès leur permettant
d'avoir un compte sur votre
machine sans fournir de mot de passe. Cela est utile dans un environnement
sécurisé où vous contrôlez toutes les machines, sinon ce
peut être très risqué. Votre
machine est aussi sûre que le moins sûr de vos hôtes de
confiance. Pour augmenter la sécurité, n'utilisez pas cette
possiblité et encouragez vos utilisateurs à ne pas utiliser le fichier
.rhosts.
Beaucoup de sites sont intéressés à avoir
un serveur ftp
anonyme pour permettre aux autres de transférer et de
récupérer des fichiers sans avoir besoin d'une identification spéciale.
Si vous décidez d'offrir ce service soyez certains de configurer votre
démon ftp de manière adéquate pour les accès anonymes. La
plupart des pages de manuel dédiées à
ftpd(8) décrivent tous les détails pour y
arriver. Vous devez toujours vous assurer que vous avez bien
suivi les instructions.
Un règle importante est de ne pas utiliser une copie de votre fichier
/etc/passwd dans le répertoire /etc du compte
anonyme. Soyez sûrs d'avoir éliminé tous les détails
des comptes exceptés ceux qui sont nécessaires, autrement vous serez
vulnérables vis à vis de ceux qui maîtrisent
les techniques de mise en pièces des mots de passe.
Ne pas permettre aux datagrammes d'atteindre votre machine ou les serveurs est un excellent moyen de sécurisation. Ceci est abordé en profondeur dans Firewall-HOWTO et (de manière plus concise) plus loin dans ce document.
Voici d'autres suggestions, potentiellement religieuses, à prendre en considération :
en dépit de sa popularité, le démon sendmail apparaît avec une effrayante régularité dans les mises en garde concernant la sécurité. Faites comme vous voulez, mais j'ai choisi de ne pas l'utiliser.
soyez circonspects avec eux. Il y a toutes sortes d'exploits possibles avec ces services. Il est difficile de trouver une option pour les services tels que NFS, mais si vous les configurez, soyez prudents envers ceux à qui vous accordez des droits.
Cette section traite d'informations spécifiques sur IP et Ethernet. Les sous-sections ont été rassemblées car je pense que ce sont les plus intéressantes de ce qui était appelé autrefois ``Technologies spécifiques''. Toute personne ayant un réseau local doit pouvoir tirer bénéfice de ces bonnes choses.
Les noms de périphériques Ethernet sont `eth0', `eth1',
`eth2' etc. La première carte détectée par le noyau devient
`eth0' et le reste est nommé dans l'ordre de détection.
par défaut, le noyau Linux ne détecte qu'un seul dispositif Ethernet, vous devez donc donner des arguments sur la ligne de commande pour forcer le noyau à détecter des autres cartes.
Pour savoir comment faire marcher votre carte Ethernet sous Linux référez-vous au Ethernet-HOWTO.
Une fois que vous avez compilé convenablement votre noyau pour supporter les cartes Ethernet, la configuration des cartes est aisée.
Typiquement vous faites ainsi (ce que la plupart des distributions font automatiquement pour vous, si vous les avez configurées pour supporter votre carte ethernet) :
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
root# route add -net 192.168.0.0 netmask 255.255.255.0 eth0
La plupart des pilotes Ethernet ont été développés
par Donald Becker,
becker@CESDIS.gsfc.nasa.gov.
Le nom du périphérique EQL est `eql'. Avec les sources
standards du noyau vous ne pouvez avoir qu'un seul périphérique
EQL par machine. EQL permet d'utiliser plusieurs lignes point à point
telles que PPP, SLIP ou PLIP comme si c'était un seul lien logique de
transport tcp/ip. C'est souvent moins cher d'utiliser plusieurs lignes
à faible débit que d'avoir une ligne à haut débit.
Options de compilation du noyau :
Network device support --->
[*] Network device support
<*> EQL (serial line load balancing) support
Pour supporter ce mécanisme la machine à l'autre bout de la ligne doit également supporter EQL. Linux, Livingstone Portmasters et de nouveaux serveurs de ligne supportent des systèmes compatibles.
Pour configurer EQL vous avez besoin des outils eql, disponibles sur : metalab.unc.edu.
La configuration est plutôt directe. Vous commencez par configurer l'interface eql. C'est exactement comme un autre périphérique réseau. Vous configurez l'adresse IP et le mtu en utilissant l'outil ifconfig , comme ceci :
root# ifconfig eql 192.168.10.1 mtu 1006
Ensuite vous devez initialiser manuellement chacune des lignes que vous allez utiliser. Ce peut être toute combinaison de périphériques réseau point à point. La façon d'initialiser les connexions dépend du type de lien, voyez les paragraphes appropriés pour d'autres informations.
Enfin vous devez associer le lien série et le dispositif EQL, cela s'appelle `asservissement' (enslaving) et est réalisé avec la commande eql_enslave comme suit :
root# eql_enslave eql sl0 28800
root# eql_enslave eql ppp0 14400
Pour libérer une ligne d'un périphérique EQL vous utilisez la commande eql_emancipate comme ci-dessous :
root# eql_emancipate eql sl0
Vous ajoutez le routage comme vous le feriez pour tout lien point
à point, sauf que vos routes doivent se rapporter au dispositif
eql plutôt qu'aux périphériques séries
eux-mêmes. Typiquement vous devriez utiliser :
root# route add default eql
Le pilote EQL fut développé par Simon Janes, simon@ncm.com.
Les possibilités d'enregistrement IP du noyau Linux vous permettent de recueillir et d'analyser les données d'utilisation du réseau. Les données collectées comprennent le nombre de paquets et le nombre d'octets en cumul depuis la dernière remise à zéro. Vous avez à votre disposition une grande variété de réglages pour obtenir les données que vous désirez. Cette option a été enlevée du 2.1.102, car l'ancien dispositif pare-feu basé sur ipfwadm a été remplacé par ``ipfwchains''.
Options de compilation noyau :
Networking options --->
[*] IP: accounting
Après avoir compilé et installé le noyau vous devez utiliser la commande ipfwadm pour configurer l'enregistrement IP. Il y a différentes possibilités pour choisir les informations à enregistrer. J'ai pris un exemple simplifié qui pourrait vous être utile; lisez plutôt la page de manuel ipfwadm pour plus d'informations.
Scenario : Vous avez un réseau Ethernet qui est relié à l'Internet via une liaison PPP. Sur l'Ethernet vous avez une machine qui offre un grand nombre de services et vous voulez savoir quel trafic est engendré par le trafic ftp et ww, aussi bien que le trafic total tcp et udp.
Vous pouvez utiliser une commande qui ressemble à ceci, qui se présente comme un script shell :
#!/bin/sh
#
# Donne les réglages d'enregistrement
ipfwadm -A -f
#
# Met en place les raccourcis
localnet=44.136.8.96/29
any=0/0
# Ajoute des réglages pour le segment Ethernet local
ipfwadm -A in -a -P tcp -D $localnet ftp-data
ipfwadm -A out -a -P tcp -S $localnet ftp-data
ipfwadm -A in -a -P tcp -D $localnet www
ipfwadm -A out -a -P tcp -S $localnet www
ipfwadm -A in -a -P tcp -D $localnet
ipfwadm -A out -a -P tcp -S $localnet
ipfwadm -A in -a -P udp -D $localnet
ipfwadm -A out -a -P udp -S $localnet
#
# Réglages par défaut
ipfwadm -A in -a -P tcp -D $any ftp-data
ipfwadm -A out -a -P tcp -S $any ftp-data
ipfwadm -A in -a -P tcp -D $any www
ipfwadm -A out -a -P tcp -S $any www
ipfwadm -A in -a -P tcp -D $any
ipfwadm -A out -a -P tcp -S $any
ipfwadm -A in -a -P udp -D $any
ipfwadm -A out -a -P udp -S $any
#
# Liste les réglages
ipfwadm -A -l -n
#
Les noms ``ftp-data'' et ``www'' se réfèrent aux lignes du fichier
/etc/services.
La dernière commande liste chacune des règles d'enregistrement et
affiche le total.
Il est important de noter, lorsque l'on analyse les enregistrement IP, que les totaux sont incrémentés à chaque fois, donc pour connaitre les différences vous devez exécuter les opérations mathématiques nécessaires. Par exemple si je veux savoir combien de données ne venaient pas de ftp, telnet, rlogin ou www je dois soustraire les totaux individuels correspondant à chaque port.
root# ipfwadm -A -l -n
IP accounting rules
pkts bytes dir prot source destination ports
0 0 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 20
0 0 out tcp 44.136.8.96/29 0.0.0.0/0 20 -> *
10 1166 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 80
10 572 out tcp 44.136.8.96/29 0.0.0.0/0 80 -> *
252 10943 in tcp 0.0.0.0/0 44.136.8.96/29 * -> *
231 18831 out tcp 44.136.8.96/29 0.0.0.0/0 * -> *
0 0 in udp 0.0.0.0/0 44.136.8.96/29 * -> *
0 0 out udp 44.136.8.96/29 0.0.0.0/0 * -> *
0 0 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 20
0 0 out tcp 0.0.0.0/0 0.0.0.0/0 20 -> *
10 1166 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 80
10 572 out tcp 0.0.0.0/0 0.0.0.0/0 80 -> *
253 10983 in tcp 0.0.0.0/0 0.0.0.0/0 * -> *
231 18831 out tcp 0.0.0.0/0 0.0.0.0/0 * -> *
0 0 in udp 0.0.0.0/0 0.0.0.0/0 * -> *
0 0 out udp 0.0.0.0/0 0.0.0.0/0 * -> *
#
On accède au nouveau code d'enregistrement par des ``chaînes IP pare-feu''.
Voir
La page d'accueil des chaînes IP pour plus d'informations. Entre autres
vous devrez utiliser ipchains au lieu de ipfwadm pour configurer
vos filtres. (d'après Documentations/Changes dans les sources du
dernier noyau).
Il y a des applications où être en mesure d'affecter plusieurs adresses IP à un seul périphérique réseau pourrait être utile. Certains fournisseurs d'accès à l'Internet utilise souvent cette possibilité pour fournir des offres www et ftp `à la carte' pour leurs clients. Vous pouvez vous référer au mini-HOWTO IP-Aliasing pour plus d'informations.
Options de compilation du noyau :
Networking options --->
....
[*] Network aliasing
....
<*> IP: aliasing support
Après avoir compilé et installé le noyau avec le support
IP_Alias, la configuration est très simple. Les alias sont ajoutés
aux périphériques réseau virtuels associés au périphérique réseau réel.
Une simple convention de noms s'applique pour périphériques :
<nom de périphérique> : <numéro de périphérique virtuel>, par ex. eth0:0,
ppp0:10 etc. Notez que le pilote de périphérique ifname:number
ne peut être configuré qu'après le réglage de l'interface principale.
Par exemple, supposons que vous ayez un réseau Ethernet avec simultanément deux sous-réseaux IP et que vous vouliez que votre machine ait un accès direct aux deux, vous pouvez faire quelque chose comme ceci :
root# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# ifconfig eth0:0 192.168.10.1 netmask 255.255.255.0 up
root# route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0
Pour supprimer un alias vous ajoutez simplement un `-' au bout de son nom
et et vous faites aussi simplement que ça :
root# ifconfig eth0:0- 0
Le pare-feu IP et les publications le concernant sont traités de manière plus appronfondies dans le document Firewall-HOWTO. Le pare-feu IP vous permet de sécuriser votre machine contre les accès réseau non-autorisés en filtrant, ou acceptant, des datagrammes venant de, ou allant vers, des adresses IP de votre choix. Il y a différentes règles : le filtrage en entrée, le filtrage en sortie, et le filtrage en retransmission. Les règles en entrée s'appliquent aux datagrammes qui sont reçus par un dispositif réseau. Les règles en sortie s'appliquent aux datagrammes qui sont émis par un dispositif réseau. Les règles en retransmission s'appliquent aux datagrammes qui ne sont pas pour cette machine, c'est à dire les datagrammes qui seront reroutés.
Options de compilation noyau :
Networking options --->
[*] Network firewalls
....
[*] IP: forwarding/gatewaying
....
[*] IP: firewalling
[ ] IP: firewall packet logging
La configuration du pare-feu IP est réalisée en utilisant la commande ipfwadm. Comme mentionné plus haut, la sécurité n'est pas ma spécialité, aussi, bien que je vous présente un exemple utilisable par vous-même, faites des recherches et mettez au point vos propres règlages si la sécurité est importante pour vous.
Vraisemblablement l'utilisation la plus courante du pare-feu IP est lorsque vous utilisez votre machine Linux comme routeur et passerelle pare-feu et que vous voulez protéger votre réseau local contre les accès extérieurs non autorisés.
La configuration suivante est due à Arnt Gulbrandsen,
<agulbra@troll.no>.
L'exemple décrit une configuration de pare-feu pour une machine Linux /pare-feu/routeur illustrée par ce diagramme :
- -
\ | 172.16.37.0
\ | /255.255.255.0
\ --------- |
| 172.16.174.30 | Linux | |
NET =================| f/w |------| ..37.19
| PPP | router| | --------
/ --------- |--| Mail |
/ | | /DNS |
/ | --------
- -
Les commandes suivantes doivent être normalement placées dans un
fichier rc de telle sorte qu'elles seront démarrées
automatiquement à chaque redémarrage du système. Pour une
sécurité maximum, elles devront être effectuées
après la configuration des interfaces réseau,
mais avant le montage de ces interfaces pour
éviter que quelqu'un puisse se connecter pendant que la machine
pare-feu reboute.
#!/bin/sh
# Nettoie la table des règles de 'Forwarding'
# Change le réglage par défaut en 'accept'
#
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p accept
#
# .. et pour 'Incoming'
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p accept
# En premier, dévérouille l'interface PPP
# J'aimerais bien utiliser '-a deny' au lieu de '-a reject -y' mais
# il serait alors impossible d'établir des connexions également sur
# cette interface. L'utilisation de -o fait en sorte que tous
# les datagrammes rejetés sont enregistrés. Cela occupe de l'espace
# disque avec pour compensation la connaissance sur l'attaque due
# à une erreur de configuration.
#
/sbin/ipfwadm -I -a reject -y -o -P tcp -S 0/0 -D 172.16.174.30
# Rejette certains types de paquets visiblement faux:
# Rien ne doit venir des adresses multicast/anycast/broadcast s
#
/sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24
#
# et aucune chose venant du réseau loopback ne doit être vu sur l'air
#
/sbin/ipfwadm -F -a deny -o -S 127.0/8 -D 172.16.37.0/24
# accepte les connexions entrantes SMTP et DNS, mais seules pour
# le serveur de courrier et le serveur de noms
#
/sbin/ipfwadm -F -a accept -P tcp -S 0/0 -D 172.16.37.19 25 53
#
# DNS utilise UDP aussi bien que TCP, ce qui l'autorise donc quand
# le serveur de noms est interrogé
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 -D 172.16.37.19 53
#
# mais pas de "réponses" arrivant sur les ports dangereux tels que
# NFS et l'extension NFS de Larry McVoy. Si vous utilisez squid
# ajoutez son port ici.
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 53 \
-D 172.16.37.0/24 2049 2050
# les réponses aux autres ports utilisateurs sont autorisées
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 53 \
-D 172.16.37.0/24 53 1024:65535
# Rejette les connexions entrantres vers identd
# Nous utilisons 'reject' dans ce cas en sorte qu'il soit dit à l'hôte
# entrant de ne pas persévérer, sinon nous devrons attendre que
# identd s'arrête.
#
/sbin/ipfwadm -F -a reject -o -P tcp -S 0/0 -D 172.16.37.0/24 113
# Accepte des connexions sur des services en provenance des réseaux
# 192.168.64 et 192.168.65, qui sont des amis de confiance.
#
/sbin/ipfwadm -F -a accept -P tcp -S 192.168.64.0/23 \
-D 172.16.37.0/24 20:23
# accepte et laisse passer tout ce qui vient de l'intérieur
#
/sbin/ipfwadm -F -a accept -P tcp -S 172.16.37.0/24 -D 0/0
# rejette la plupart des autres connexions TCP entrantes et les
# enregistre (ajoutez 1:1023 si ftp ne fonctionne pas)
#
/sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 -D 172.16.37.0/24
# ... pour UDP également
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 -D 172.16.37.0/24
De bonnes configurations pare-feu sont difficiles à faire. Cet exemple peut être un bon point de départ pour vous. La page de manuel ipfwadm vous aidera pour savoir comment utiliser cet outil. Si vous voulez configurer un pare-feu, demandez autour de vous et recueillez des avis venant de sources de confiance et prenez contact avec quelqu'un qui est à l'extérieur pour tester votre configuration et en vérifier la fiabilité.
On accède au nouveau code d'enregistrement par des ``chaînes pare-feu IP''.
Voir
La page d'accueil des chaînes IP pour plus d'informations. Entre autres
vous devrez utiliser ipchains au lieu de ipfwadm pour configurer
vos filtres. (D'après Documentations/Changes dans les sources du
dernier noyau).
Nous sommes conscients du fait que ce n'est malheureusement plus d'actualité et nous oeuvrons actuellement pour que cette section soit plus à jour. Vous pouvez en espérer une en Août 1999.
Pourquoi vouloir encapsuler des paquets IP dans d'autres paquets IP? Cela semble bizarre si vous n'avez jamais vu d'applications auparavant. Il y a deux endroits où c'est utilisé : le Mobile-IP et l'IP-Multicast. C'est dans un environnement qui est peut-être le plus largement utilisé et qui est le moins connu : le radio-amateurisme.
Options de compilation du noyau :