Installation de votre nouveau domaine Mini-HOWTO

Christopher Neufeld <neufeld@linuxcare.com>
Traduction française par Geneviève Gracian <ggracian@free.fr> le 7 février 2001

version 0.12 du 17 octobre 2000
Ce document survole les opérations que vous serez probablement amené à réaliser quand vous voudrez mettre en place un réseau d'ordinateurs sous votre propre domaine. Il couvre la configuration du réseau, des services réseau ainsi que les paramétrages relatifs à la sécurité.

1. Notes

1.1 Mise en garde

Ce texte est une introduction. J'ai passé sous silence beaucoup de choses qui pourraient être présentées bien plus en détail et j'ai, probablement, raté entièrement des paragraphes importants. Toute suggestion concernant des compléments, suppressions, ou aspects sur lesquels je devrais donner plus ou moins de précisions est la bienvenue.

1.2 Nouvelles versions de ce document

La version la plus récente de ce document peut être trouvée à : http://caliban.physics.utoronto.ca/neufeld/Domain.HOWTO/.

1.3 Copyright

Copyright (c) Christopher Neufeld. Ce document peut être distribué selon les termes et conditions énoncés dans la licence LDP à l'adresse http://www.linuxdoc.org/COPYRIGHT.html.

2. Introduction

Le présent document est un guide pour mettre en place votre propre domaine de machines Linux ou d'un mélange de machines Linux et de machines Windows sur une connexion permanente avec une IP fixe et un domaine propre.

Il n'est pas vraiment approprié pour des installations qui utilisent des adresses IP dynamiques, ou qui sont régulièrement déconnectées de leur fournisseur d'accès pendant de longues périodes ; cependant, des conseils de base pour mettre en place de telles installations figurent dans la section Utiliser une IP dynamique.

Avec la démocratisation des connexions permanentes et des IPs statiques, il est devenu plus aisé pour les personnes et les organisations de mettre en place un véritable domaine avec la présence internet qui y est associée. Une planification rigoureuse peut réduire les problèmes pouvant se poser par la suite.

L'essentiel de ce document décrit les techniques pour mettre en place une sécurité discrète sur le réseau nouvellement exposé. Il traite de la protection contre les attaques extérieures et contre les attaques internes « fortuites ». Il ne prétend pas proposer une une installation extrêmement sécurisée mais en général suffisante pour dissuader les agresseurs les moins obstinés.

Ce document s'adresse en premier lieu à de petites organisations ayant un réseau préexistant, éventuellement une connexion « dial-up » partagée, qui cherchent à évoluer vers une connexion permanente relativement rapide, tant pour mettre en oeuvre des échanges de fichiers avec le monde extérieur que pour créer un site www ou ftp. Il concerne également de nouvelles organisations qui veulent sauter les étapes préliminaires et mettre en place tout de suite une connexion rapide et héberger des services sous leur propre domaine.

Tout au long de ce document, je traiterai de la configuration d'un nouveau réseau enregistré sous le nom de example.com. Notez que example.com est réservé par l'IANA pour une utilisation dans les documentations et, par conséquent, ne correspondra jamais à un domaine existant.

La plupart des informations du présent document est disponible ailleurs. J'ai essayé de synthétiser l'essentiel concernant la création d'un nouveau domaine. Si les détails sur un sujet spécifique semblent « simplets », vous pouvez consulter un des documents plus explicites.

Ce document couvrira également le cas d'un environnement mixte composé de plusieurs systèmes d'exploitation. Plus spécialement je suppose que les postes de travail fonctionnent sous Windows, alors que les serveurs et passerelles fonctionnent sous Linux.

3. Définir la topologie de votre réseau

Bien qu'il existe des arguments en faveur de différentes architectures, les exigences de bien des organisations peuvent être satisfaites en intégrant les postes de travail et les serveurs privés dans un réseau privé, et les machines publiques sur des adresses IP externes valides. Les machines possédant les adresses IP publiques seront appelées dans la suite de ce document « hôtes exposés ». Ceci conduit à la topologie suivante (exemple) :

+--------------+
|              |               +---------------+
| routeur du   |---------------| serveur FTP   |
| fournisseur  |        |      +---------------+
| d'accès      |        |      
|              |        |
+--------------+        |      +----------------+
                        |------| serveur WWW #1 |
                        |      +----------------+
                        |
                        |      +----------------+
                        |------| serveur WWW #2 |
                        |      +----------------+
                        |
                        ~
                        ~
                        |
                        |      +---------------+
                        |------| passerelle    |
                               | de réseau     |
                               | privé         |
                               +---------------+
                                       |
                                       |
                                       |
                                       |
      +------------+                   |      +------------------+
      | station #1 |-------------------|------| serveur privé #1 |
      +------------+                   |      +------------------+
                                       |
             .      -------------------|--------        .
             .                         |                .
             .      -------------------|--------        .
                                       |
      +------------+                   |      +------------------+
      | station #N |-------------------|------| serveur privé #N |
      +------------+                          +------------------+

Dans cet exemple, le routeur du FAI (fournisseur d'accès Internet -- provider--), le serveur FTP, les serveurs WWW et la machine désignée comme passerelle de réseau privé ont tous des adresses IP visibles depuis l'extérieur, alors que les stations et les serveurs privés ont des adresses IP réservées pour une utilisation privée. Voir la RFC1918 : http://www.ietf.org/rfc/rfc1918.txt ; http://abcdrfc.free.fr/rfc-vf/rfc1918.html en version française. Les adresses IP que vous choisissez pour votre réseau privé (tout ce qui est sous votre passerelle de réseau privé) doivent être uniques, mais pas seulement par rapport à l'ensemble des hôtes qui sont sous votre contrôle ; elles ne doivent pas non plus entrer en conflit avec des adresses attribuées dans les autres réseaux privés similaires, sur d'autres sites ou partenaires, avec lesquels vous pourriez vouloir un jour développer un réseau privé virtuel ; et ceci dans le but d'éviter déboires et reconfigurations lorsque les deux réseaux seront reliés de cette manière. Comme indiqué dans la RFC, vous pouvez opter pour un réseau de classe C entre les plages d'adresses 192.168.0.* et 192.168.255.*, un réseau de classe B compris entre les plages d'adresses 172.16.*.* et 172.31.*.*, ou bien, un réseau de classe A 10.*.*.*. Dans la suite de ce document, je supposerai que votre réseau privé (si vous avez choisi d'en créer un) est un réseau de classe C sur la plage 192.168.1.*, que l'interface extérieure de votre passerelle de réseau privé a l'adresse IP 10.1.1.9, une des adresses qui vous ont été allouées par le FAI (notez qu'il ne s'agit pas d'une adresse publique valide, je ne l'utilise que comme exemple). Je supposerai également qu'il y a une machine, betty.example.com à l'adresse 10.1.1.10, qui supporte simultanément le service FTP et le service www.

Faites le compte du nombre d'adresses IP externes dont vous avez besoin pour vos machines. Vous aurez besoin d'une adresse pour chacune des machines installées du coté externe de la passerelle de réseau privé, plus une pour la passerelle elle-même. Ce compte n'inclut pas toute IP qui pourrait être attribuée à d'autres routeurs, adresses de diffusion, etc. Vous devez demander à votre fournisseur d'accès un bloc d'adresses suffisamment grand pour mettre en place toutes vos machines. Par exemple, sur mon réseau professionnel, parmi les huit adresses IP allouées par le FAI, trois n'étaient pas utilisables par mes ordinateurs, laissant la place pour quatre machines à l'extérieur de la passerelle, plus la passerelle elle-même.

Cette topologie de réseau ne vaut pas pour tout le monde, mais elle constitue un point de départ raisonnable pour beaucoup de configurations qui n'ont pas de besoin particulier. Les avantages de cette configuration sont les suivants :

Les désavantages potentiels de ce type de configuration sont les suivants :

Vous devriez tenir compte de tous ces points lors de l'élaboration de la topologie de votre réseau, et décider si un réseau entièrement visible est mieux adapté à votre cas. Dans la suite du document, je supposerai que vous avez configuré votre réseau comme montré ci-dessus. Si vous avez opté pour un réseau entièrement visible, certains détails différeront, et j'essayerai de signaler de telles différences.

Au cas où vous n'auriez pas besoin de serveur externe, le routeur fourni par le provider peut être directement connecté à l'interface externe de la passerelle de réseau privé, plutôt que par l'intermédiaire d'un hub.

4. Vous procurer votre connexion

4.1 Choisir votre fournisseur d'accès

Comme pour tout, prospectez. Déterminez quelle est l'offre de services dans votre région, aussi bien que les coûts associés à chacun de ces services. Toutes les lieux ne sont pas câblés pour DSL, et certaines ne sont pas appropriés pour des connexions sans fils, à cause de contraintes géographiques, architecturales ou environnementales. Dans la mesure où la rapidité des liaisons DSL est intimement liée à la distance entre le point de liaison et le switch, soyez prêt à fournir l'adresse postale du lieu où la tête de votre liaison sera localisée, et posez également des questions précises sur la bande passante entre votre machine et le fournisseur d'accès, sur ce qui doit être fait pour installer la connexion et sur le matériel dont la location est comprise dans le forfait mensuel proposé. Vous devez également avoir une idée du nombre d'adresses IP dont vous avez besoin pour vos machines propres (rappelez-vous que les adresses de la série que vous obtiendrez ne seront pas toutes utilisables pour vos ordinateurs). Demandez au fournisseur d'accès quelle est sa bande passante totale vers l'extérieur car la vitesse déclarée dans sa proposition financière ne concerne que la liaison entre votre site et le sien. Si le provider a une bande passante insuffisante vers l'extérieur, ses clients auront à pâtir de goulots d'étranglements à l'intérieur de son réseau.

Une fois que vous avez présélectionné une liste de candidats, renseignez-vous, voyez si personne ne peut vous conseiller sur les prestataires que vous envisagez. Demandez leur quel type de bande passante ils obtiennent vers des sites non chargés. En outre, si vous avez l'intention d'avoir des connexions rapides entre le nouveau domaine et un accès internet personnel depuis chez vous, pour télétravailler ou bien pour faire de l'administration à distance, il est essentiel que vous fassiez un traceroute depuis votre connexion personnelle vers un hôte localisé chez le prestataire envisagé. Ceci vous renseignera sur le nombre de « pas », et la latence auxquels vous devez vous attendre entre chez vous et le nouveau domaine. Des latences supérieures à 100-200 millisecondes peuvent être problématiques pour des utilisations prolongées. Le traceroute doit être lancé aux moments de la journée pendant lesquels vous souhaitez utiler une connexion réseau entre votre domicile et le nouveau domaine.

4.2 Faire les préparatifs pour l'installation matérielle

Après avoir choisi le fournisseur et le type d'accès pour le nouveau domaine, renseignez-vous sur les détails de l'installation. Vous pouvez aussi bien avoir besoin d'une prestation de l'opérateur téléphonique en plus de celle du FAI afin de mettre en place l'accès, et les techniciens peuvent avoir besoin d'accéder à des zones contrôlées de vôtre bâtiment ; informez donc votre « responsable de la maintenance immobilière » des nécessités de l'installation. Avant que le technicien de l'ISP n'arrive, demandez les paramètres, tout spécialement les adresses IP, le masque de réseau, l'adresse de diffusion, l'adresse de la passerelle de routage, celle du serveur DNS, et également quel type de câblage est nécessaire pour le matériel apporté par le technicien (par exemple câble droit ou câble croisé RJ45, etc.).

Ayez une machine disponible pour les tests, et installez-la à proximité de l'endroit où le matériel de connexion au réseau sera localisé. Si possible, configurez-la avant que le technicien du prestataire n'arrive en paramétrant son adresse IP et le masque de réseau. Ayez également les câbles appropriés sous la main de façon à ce que les tests puissent être faits rapidement.

4.3 Tester la connexion

Une fois que votre machine de test est reliée au matériel du provider, assurez-vous que vous pouvez faire un ping sur une machine au delà du FAI. Si ce n'est pas possible, un traceroute vers l'extérieur peut vous aider à localiser la défaillance de la connexion. Si le traceroute ne montre aucun « pas » réussi, cela indique que la configuration réseau de votre machine (route par défaut, adresse de l'interface, pilote de la carte, DNS, etc.) n'est pas bonne. Si un seul « pas » est réussi, cela peut signifier que le routeur n'est pas correctement configuré pour communiquer avec le FAI. Si plusieurs « pas » sont réussis avant la défaillance, le problème est très certainement localisé chez le provider ou bien à l'extérieur, et hors de de votre contrôle immédiat.

4.4 Utiliser une IP dynamique

Les avantages d'une connexion d'entreprise avec une plage d'adresses IP statiques et l'hébergement de divers services entraînent un coût. Elle peut être 10 fois plus onéreuse qu'une connexion personnelle à haut débit avec DSL ou un modem-câble. Si votre budget ne peut supporter une telle connexion ou bien si ce type de connexion n'est pas disponible dans votre région, vous voudrez certainement essayer de mettre en place votre domaine sur une IP dynamique. En général, plutôt qu'une plage d'adresses vous n'obtiendrez qu'une seule adresse, ce qui veut dire que votre passerelle de réseau privé devra également héberger tous les services accessibles depuis l'extérieur.

D'abord vous devriez vérifier si c'est faisable. Beaucoup de contrats de prestataires interdisent explicitement la mise en place de services accessibles depuis l'extérieur sur des comptes personnels. Les prestataires peuvent faire appliquer cette règle par la mise en place d'un filtrage de paquets bloquant les connexions entrantes sur les ports http et FTP. Vous devez également être attentif au fait que la vitesse de transfert mentionnée dans l'offre pour des accès DSL ou modem-câble est la vitesse de la voie descendante, et que la voie montante peut être beaucoup plus lente. La bande passante montante est ce qui est important pour offrir des contenus web ou FTP.

Si vous avez une IP dynamique et que vous voulez avoir des connexions entrantes, vous devez vous inscrire à un service d'hébergement d'IP dynamique tels que ceux listés sur Dynamic DNS Providers (à l'adresse http://www.technopagan.org/dynamic). Ces services fonctionnent ordinairement en exécutant un logiciel sur votre machine qui communique votre adresse IP actuelle aux serveurs de l'hébergeur. Quand votre adresse IP est connue de ceux-ci, leurs tables DNS sont mises à jour pour tenir compte de la nouvelle valeur. Vous pouvez aussi obtenir un nom de domaine sous leur nom de domaine, tel que « example.dynip.com » ou bien « example.dynhost.com », ou bien vous pouvez enregistrer votre propre domaine et faire pointer le DNS primaire sur la société fournissant ce service (c'est habituellement plus cher).

Il existe également un service d'hébergement gratuit à Domain Host Services (à l'adresse http://www.dhs.org). Ce service semble assez récent et il y a peu de détails sur le site web pour l'instant, mais vous trouverez peut-être que cela vaut le coup d'être étudié.

Si vous avez mis en place une IP dynamique, et que vous êtes abonné à l'un de ces services, cela influera sur certaines décisions que vous ferez dans la section Décider des services que vous hébergerez. En particulier, cela ne sert à rien de vous abonner à un service d'hébergement d'IP dynamique si vous n'envisagez pas de mettre en place au moins un des services web ou FTP. Vous devrez configurer le DNS primaire de façon à ce qu'il pointe sur la société que vous avez choisie. Vous ne devez pas avoir un démon named qui répond à des requêtes émanant de l'extérieur de votre réseau privé. D'autres éléments tels que le transport du courrier électronique, dépendront des spécificités du service auquel vous vous êtes abonné, et peuvent mieux être expliqués par le service d'assistance de cette société.

Une remarque finale : si vous voulez avoir un accès distant à une machine avec une IP dynamique, machine qui n'hébergera pas d'autres services, une solution bon marché est de créer une « boite de dépôt » sur une machine publique avec une IP statique et de faire en sorte que l'hôte ayant une IP dynamique envoie son adresse IP à cet endroit, soit par mél ou tout simplement en l'inscrivant dans un fichier sous un compte shell. Quand vous voulez accéder à distance à votre machine, récupérez d'abord l'adresse IP actuelle dans la « boite de dépôt », puis utilisez slogin pour vous attacher directement à cette adresse IP. C'est, somme toute, tout ce que fait un service d'hébergement d'adresses IP dynamiques, il le fait juste de manière automatique au dessus des services standards, vous épargnant des manipulations.

5. Enregistrer un nom de domaine

Afin que les personnes du monde extérieur puissent localiser vos serveurs sous le nom de domaine de votre choix, que ce soit pour le web, pour le FTP ou pour la messagerie électronique, vous devrez enregistrer ce nom de domaine afin qu'il soit intégré dans la base de données du domaine de premier niveau adéquat.

Usez de prudence en choisissant votre nom de domaine. Certains mots ou locutions peuvent être interdits en raison de coutumes locales, ou pourraient être choquants pour des personnes dont le langage ou l'argot diffère de celui de votre région. Les noms de domaine peuvent contenir les 26 caractères de l'alphabet latin (sans accents), le tiret (quoique celui-ci ne peut être mis au début ou la fin du nom), et les dix chiffres. Les noms de domaines ne sont pas sensibles à la casse, et peuvent avoir une longueur maximale de 26 caractères (cette limite est susceptible de changer). Faites attention à ne pas enregistrer un nom de domaine à propos duquel vous ne pouvez pas raisonnablement faire valoir que vous ne saviez pas que celui-ci empétait sur des marques déposées par des sociétés existantes, les tribunaux ne sont pas indulgents pour les « cyber-squatters ». Des informations concernant les situations dans lesquelles votre nom de domaine humblement choisi peut être retiré de votre contrôle sont disponibles dans le document de l'ICANN « Politique pour une résolution des conflits sur les noms de domaines » à l'adresse http://www.icann.org/udrp/udrp-policy24oct99.htm (en français : http://www.juriscom.net/pro/2/ndm20001011.htm).

Il existe beaucoup de sociétés qui proposent l'enregistrement de noms dans les domaines de premier niveau « .com », « .net » et « .org ». Pour une liste à jour, vérifiez la liste de prestataires conventionnés à l'adresse http://www.icann.org/registrars/accredited-list.html. Pour enregistrer un nom dans un domaine de premier niveau géographique, tel que « .fr », « .ca », « .de », « .uk », etc., cherchez quelle est l'autorité appropriée, ce renseignement pouvant être trouvé dans la base de données des Country Code Top-Level Domains à l'adresse http://www.iana.org/cctld.html.

6. Décider des services que vous hébergerez

La plupart des fournisseurs d'accès « full-service » proposent à leur clients un éventail de services relatifs au domaine. Ceci est largement dû à la difficulté d'héberger ces services avec certains autres systèmes d'exploitation, plus populaires, pour machines de bureau et serveurs. Ces services sont beaucoup plus faciles à mettre en oeuvre sous Linux et peuvent être hébergés sur des matériels peu onéreux. Vous devriez donc décider des services que vous voulez garder sous votre contrôle. Certains de ces services sont :

Pour chacun de ces services vous devez évaluer l'intérêt d'en garder le contrôle. Si votre FAI propose un ou plusieurs de ces services, vous pouvez généralement avoir l'assurance qu'il a du personnel expérimenté pour la gestion de ceux-ci ; aussi, vous aurez moins à apprendre et moins de soucis. Parallèlement à cela, vous perdez la maîtrise de ces services. La moindre modification impose que vous passiez par le FAI, chose qui peut ne pas être pratique ou demander des délais plus longs que vous ne le voudriez. Il y a aussi une question de sécurité, le FAI est une cible beaucoup plus tentante pour les agresseurs que votre propre site. Dans la mesure où les serveurs d'un FAI peuvent héberger la messagerie et/ou les sites web de douzaines de sociétés qui sont ses clients, un pirate qui endommage un de ces serveurs obtient une bien meilleure récompense à ces efforts que celui qui attaque votre serveur personnel où les seules données d'une entreprise sont stockées.

6.1 DNS primaire

Quand une personne, quelque part, dans le monde extérieur, demande à se connecter sur une machine du nouveau domaine example.com, les requêtes transitent par des serveurs divers sur internet ; et finalement l'adresse IP de la machine est renvoyée au logiciel de la personne qui demande la connexion. Le détail de cette séquence est au delà de l'objet de ce document. Sans entrer dans les détails, quand une demande est faite pour la machine fred.example.com, une base de données centralisée est questionnée pour déterminer quelle est l'adresse IP de la machine qui a l'autorité administrative sur la zone example.com. L'adresse IP obtenue est ensuite questionnée pour obtenir l'adresse IP de fred.example.com.

Il doit exister un DNS primaire et un DNS secondaire pour chaque nom de domaine. Les noms et adresses de ces deux serveurs sont enregistrés dans une base de données dont les entrées sont contrôlées par des autorités de nommage telles que « Network solutions » (à l'adresse http://www.networksolutions.com).

Si vous avez opté pour un DNS primaire hébergé par le FAI, ces deux machines seront probablement contrôlées par celui-ci. À chaque fois que vous voudrez ajouter à votre réseau une machine visible depuis l'extérieur, vous devrez contacter le FAI pour lui demander d'ajouter la nouvelle machine à sa base de données.

Si vous avez choisi de gérer le DNS primaire sur votre propre machine, vous devrez également utiliser une deuxième machine comme serveur secondaire. Techniquement, vous devriez la localiser sur une connexion internet redondante , mais l'hébergement du DNS secondaire sur l'une des machines du FAI est très répandu. Si vous voulez ajouter à votre réseau une machine visible depuis l'extérieur, vous devrez mettre à jour votre propre base de données et ensuite attendre que la modification se propage (chose qui, habituellement, prend un petit nombre d'heures). Ceci vous permet d'ajouter barney.example.com sans passer par votre FAI.

C'est une bonne idée de mettre en oeuvre le DNS secondaire sur un hôte distant du point vue géographique ; ainsi, une simple rupture de câble du coté de votre FAI ne met pas simultanément hors-ligne vos serveurs DNS primaire et secondaire. Le prestataire d'enregistrement de nom que vous avez utilsé pour enregistrer votre domaine peut fournir un service de DNS secondaire. Il existe également un service gratuit, Granite Canyon (à l'adresse http://www.granitecanyon.com), disponible pour qui le demande.

Indépendamment du fait que vous avez choisi ou non de constituer vous même l'autorité DNS principale pour votre domaine, voyez la section Mettre en place la résolution de noms pour une aide concernant la configuration. Vous aurez besoin d'un système de résolution de noms au sein de votre réseau privé, même si vous déléguez le DNS primaire à votre FAI.

6.2 Messagerie électronique

En général, quand vous vous abonnez chez votre FAI, celui-ci vous fournit un certain nombre d'adresses de messagerie. Vous pouvez choisir de n'utiliser que cette possibilité, auquel cas tous les messages entrants sont stockés sur le serveur du FAI et vos utilisateurs lisent leur courrier avec des clients POP3 qui se connectent sur le serveur du FAI. D'une autre manière, vous pouvez décider d'installer la messagerie sur vos propres machines. Une fois de plus, vous devez peser le pour et le contre de chacune des deux possibilités et choisir celle qui vous convient le mieux.

Ce dont il faut se rappeler si vous utilisez les services de l'ISP pour la messagerie :

Ce dont il faut se rappeler si vous gérez vous-même la messagerie :

Une approche possible est d'héberger la messagerie vous-même et, en supplément, d'utiliser quelques unes des adresses fournies par le FAI. Les personnes qui ont besoin d'une messagerie accessible depuis l'extérieur du réseau privé peuvent avoir des adresses dans votre domaine qui sont redirigées sur l'une des adresses fournies par l'ISP. Les autres peuvent avoir une messagerie locale sur le réseau privé. Ceci requiert un petit peu plus de coordination et de configuration, mais donne plus de flexibilité que chacune des autres approches.

Si vous choisissez d'héberger la messagerie pour votre domaine, reportez-vous à la section Mettre en place la messagerie électronique

Si vous décidez de ne pas héberger la messagerie pour votre domaine, reportez-vous à la section Configuration du DNS si vous n'hébergez pas le service de messagerie.

6.3 Hébergement du site web

Votre FAI peut vous allouer une certaine quantité d'espace sur ses serveurs web. Vous pouvez décider d'utiliser cette possibilité ou vous pouvez avoir un serveur web que vous mettez dans votre réseau externe, sur une des IPs externes.

Ce dont il faut se rappeler si vous choisissez d'utiliser l'hébergement web du FAI :

Ce dont il faut se rappeler si choisissez d'héberger votre propre serveur web.

Notez que je ne dis rien à propos du fait que l'ISP a du matériel plus performant, des taux de transfert de données plus élevés, et ainsi de suite. Au fil du temps, ces choses deviennent importantes, et l'on parle de connexions réseaux à très hauts débits, et, très franchement, vous auriez dû déléguer ces décisions à un consultant spécialisé, pas regarder dans un HOWTO Linux.

Si vous choisissez d'héberger l'espace web de votre domaine sur vos propres serveurs, reportez-vous à d'autres documents tels que le WWW-HOWTO (à l'adresse ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO ou http://www.freenix.org/unix/linux/HOWTO/WWW-HOWTO.html en version française), pour la configuration. Pour des raisons de sécurité, je vous recommande chaudement de faire fonctionner ce service sur une autre machine que la passerelle de réseau privé.

6.4 Hébergement du site FTP

Fondamentalement, les mêmes raisonnements qui s'appliquent à l'hébergement WWW s'appliquent à l'hébergement FTP, à l'exception du fait que le ftp n'est pas concerné par les contenus dynamiques et que les scripts CGI n'y apparaissent pas. La plupart des exploits récents sur des serveurs ftpd ont été réalisés par des débordements de tampon consécutifs à la création de répertoires ayant des noms longs dans des répertoires de téléchargement modifiables par n'importe qui ; ainsi, si votre FAI autorise le téléchargement et se montre négligent dans la maintenance des mises à jour de sécurité sur le serveur FTP, vous feriez aussi bien d'héberger le service vous-même.

Dans le cas où vous choisissez d'héberger FTP pour votre domaine sur vos propres serveurs, assurez-vous d'avoir la dernière version du démon FTP, et consultez les instructions de configuration. Une fois de plus, je recommande fortement, pour des raisons de sécurité, que ce service fonctionne sur une autre machine que la passerelle de réseau privé.

Pour wu-ftpd, je recommande les options de configuration suivantes :

6.5 Filtrage de paquets

Certains FAI mettent des filtres de paquets, pour protéger les utilisateurs du système les uns des autres ou vis à vis d'agresseurs externes. Les réseaux modem-câble et d'autres réseau à diffusion similaires posent problème quand, sans le faire exprès, des utilisateurs de Windows 95 ou 98 activent le partage de fichiers mettant ainsi le contenu entier de leurs disques durs à la vue de n'importe qui prend le soin d'explorer son « voisinnage réseau » à la recherche de serveurs actifs. Dans certains cas, la solution a été de dire aux utilisateurs de ne pas faire cela, mais certains fournisseurs d'accès ont mis en place un filtrage dans le matériel de connexion pour empêcher les gens d'exporter leurs données par inadvertance.

Le filtrage de paquet est vraiment une chose que vous devriez faire vous-même. Il s'intègre facilement dans le noyau fonctionnant sur votre passerelle de réseau privé et vous donne une meilleure idée de ce qui se passe autour de vous. En outre, il arrive souvent que l'on veuille, pendant l'installation, procéder à de menus ajustements sur le pare-feu pour l'optimiser, et c'est beaucoup plus facile à faire en temps réel plutôt que par l'intermédiaire d'un support technique.

Si vous choisissez de faire le filtrage de paquets pour votre domaine, reportez-vous à la section Mettre en place le filtrage de paquets.

7. Configurer les services hébergés

7.1 Mettre en place la résolution de noms

Vous devrez mettre en place un moyen pour que les ordinateurs sur votre réseau se reconnaissent par leur nom, et également que les personnes à l'extérieur connaissent par leur nom vos machines exposées. Il existe plusieurs moyens d'aboutir à ce résultat.

résolution DNS sur le réseau privé, le FAI gère le domaine

(remarque : si vous avez choisi de ne pas mettre en place un réseau privé, allez à la section Réseau entièrement exposé, hébergé par le FAI)

Dans cette configuration, vous avez délégué la responsabilité du DNS primaire de votre domaine au FAI. Vous continuez à utiliser DNS à l'intérieur de votre réseau privé quand les hôtes internes veulent communiquer ensemble. Vous avez communiqué au FAI une liste des adresses IP de l'ensemble des hôtes exposés. Si vous voulez qu'une des machines visibles depuis l'extérieur, par exemple betty.example.com, soit en même temps le serveur web et le serveur FTP, vous devez demander au FAI de mettre en place des entrées CNAME www.example.com et ftp.example.com qui pointent sur betty.example.com.

Mettez en place le DNS sur votre passerelle de réseau privé. Ceci peut être réalisé de manière sécurisée, et rendre les mises à jour plus faciles, au cas où vous décidiez un jour d'héberger l'autorité primaire du DNS.

Je supposerai que vous avez décidé d'héberger le DNS sur la machine dns.example.com, qui est la passerelle de réseau privé, et un surnom (alias) pour fred.example.com à l'adresse 192.168.1.1. Si ce n'est pas le cas, de petites modifications doivent être faites à votre configuration. Je ne traiterai pas de cela dans ce HOWTO à moins que cela ne présente un véritable intérêt.

Vous devrez télécharger et compiler une version de BIND, Berkeley Internet Name Domain. Il est disponible sur le site de BIND (à l'adresse http://www.isc.org/products/BIND/). Ensuite vous devez configurer les démons. Créez le fichier /etc/named.conf suivant : 

     options {
             directory "/var/named";
             listen-on { 192.168.1.1 };
     };
 
     zone "." {
             type hint;
             file "root.hints";
     };
 
     zone "0.0.127.in-addr.arpa" {
             type master;
             file "pz/127.0.0";
     };
 
     zone "1.168.192.in-addr.arpa" {
             type master;
             file "pz/1.168.192";
     };
 
     zone "example.com" {
             type master;
             notify no;
             file "pz/example.com";
     };

Remarquez que nous nous sommes déclarés maîtres du domaine example.com. Cependant, notre FAI se déclare aussi comme l'autorité du même domaine. Ce n'est pas un problème tant que l'on fait attention à l'installation. Toutes les machines du réseau privé doivent utiliser dns.example.com pour mettre en oeuvre leur résolution de noms. Elles ne doivent pas utiliser le « resolver » de l'ISP dans la mesure où le le serveur de nom de l'ISP croit qu'il fait authorité sur l'intégralité du domaine mais ne connait pas les adresses IP ou les noms des machines sur votre réseau privé. De la même manière, les hôtes ayant les adresses publiques de votre domaine doivent utiliser le serveur de noms du FAI, pas le serveur de nom privé sur dns.example.com.

Les différents fichiers sous /var/named doivent maintenant être créés.

Le fichier root.hint est tel que décrit dans la documentation de BIND ou dans le DNS-HOWTO (à l'adresse ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/DNS-HOWTO ; http://www.freenix.org/unix/linux/HOWTO/DNS-HOWTO.html). À l'heure où j'écris, Ce qui suit est un fichier root.hint valide.

     H.ROOT-SERVERS.NET.     6d15h26m24s IN A  128.63.2.53
     C.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.33.4.12
     G.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.112.36.4
     F.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.5.5.241
     B.ROOT-SERVERS.NET.     6d15h26m24s IN A  128.9.0.107
     J.ROOT-SERVERS.NET.     6d15h26m24s IN A  198.41.0.10
     K.ROOT-SERVERS.NET.     6d15h26m24s IN A  193.0.14.129
     L.ROOT-SERVERS.NET.     6d15h26m24s IN A  198.32.64.12
     M.ROOT-SERVERS.NET.     6d15h26m24s IN A  202.12.27.33
     I.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.36.148.17
     E.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.203.230.10
     D.ROOT-SERVERS.NET.     6d15h26m24s IN A  128.8.10.90
     A.ROOT-SERVERS.NET.     6d15h26m24s IN A  198.41.0.4

Le fichier pz/127.0.0.0 est comme suit :

@               IN      SOA     example.com. root.example.com. (
                                1       ; numéro de série
                                8H      ; mise à jour
                                2H      ; tentative après échec
                                1W      ; délai d'expiration
                                1D)     ; durée de vie minimale
                        NS      dns.example.com.
1                       PTR     localhost.

Le fichier pz/1.168.192 est comme suit :

$TTL 86400
 
@       IN      SOA             dns.example.com. root.dns.example.com. (
                                1       ; numéro de série
                                8H      ; mise à jour            8 heures
                                2H      ; tentative après échec  2 heures
                                1W      ; délai d'expiration     1 semaine
                                1D      ; durée de vie minimale  1 jour
                        )
                NS      dns.example.com.
 
1               PTR     fred.example.com.
                PTR     dns.example.com.
                PTR     mail.example.com.
2               PTR     barney.example.com.
3               PTR     wilma.example.com.

et ainsi de suite, où vous créez un enregistrement PTR pour chacune des machines ayant une interface sur le réseau privé. Dans cet exemple, fred.example.com est à l'adresse 192.168.1.1 et il est « pointé » par les alias dns.example.com et mail.example.com. La machine barney.example.com est à l'adresse IP 192.168.1.2 et ainsi de suite.

Le fichier pz/example.com est comme suit :

$TTL 86400
 
@               IN      SOA     example.com. root.dns.example.com. (
                                1       ; numéro de série
                                8H      ; mise à jour             8 heures
                                2H      ; tentative après échec   2 heures
                                1W      ; délai d'expiration      1 semaine
                                1D      ; TTL minimale            1 jour
                        )
                        NS              dns.example.com.
        IN              A               192.168.1.1
        IN              MX          10  mail.example.com.
        IN              MX          20  <IP de la machine de mail de l'ISP>.
 
 
localhost               A           127.0.0.1
fred                    A           192.168.1.1
                        A           10.1.1.9
dns                     CNAME       fred
mail                    CNAME       fred
barney                  A           192.168.1.2
wilma                   A           192.168.1.3
betty                   A           10.1.1.10
www                     CNAME       betty
ftp                     CNAME       betty

Dans la mesure où les machines à l'intérieur du réseau privé n'ont pas intérêt à questionner le serveur de noms du FAI pour une requête sur, disons, betty.example.com, remarquez que nous créons des entrées tant pour les machines localisées à l'intérieur du réseau privé que pour celles ayant des adresses IP externes. Nous déclarons également chacune des deux adresses IP de fred, l'adresse externe et l'adresse interne.

Une ligne dans la section « options » de /etc/named.conf appelle une explication : 

listen-on { 192.168.1.1 };

Elle empêche votre démon named de répondre à des requêtes DNS sur son interface externe (toutes les requêtes émanant de l'extérieur doivent passer par le serveur de nom du FAI, pas par le vôtre).

pas de résolution DNS sur le réseau privé, le FAI gère le domaine

(note : si vous avez décidé de ne pas mettre en oeuvre de réseau privé, reportez-vous à la section Réseau pleinement exposé, hébergé par le FAI)

Dans cette configuration, vous avez tranché sur le fait que, somme toute, votre réseau est peu étendu et qu'il est improbable qu'il s'étende. Vous avez décidé de ne pas utiliser la base de données centralisée d'un serveur de noms, et, en conséquence, de maintenir la résolution de noms séparément sur chacune des machines. Toutes les machines doivent donc utiliser le serveur de noms de l'ISP pour résoudre les noms d'hôtes situés au delà de la passerelle de réseau privé. Pour la résolution de nom au sein du réseau privé, un fichier des hôtes doit être créé. Sous Linux, cela signifie entrer les noms et les adresses IP de toutes les machines dans le fichier /etc/hosts sur chacune des machines. À chaque fois qu'un nouvel hôte est ajouté, ou qu'une adresse IP est changée, ce fichier doit être modifié sur chaque Linuxette.

Comme dans la section le DNS est sur le réseau privé, le FAI gère le domaine, la liste des hôtes ayant des adresses IP publiques doit être communiquée au FAI et chaque alias (tels que les noms www et ftp) doit être spécifié dans une entrée CNAME créée par le FAI.

vous êtes l'autorité DNS primaire pour le domaine

Bien que vous puissiez mettre en oeuvre la résolution named sur les hôtes exposés, et une base de données privée de résolution pour le réseau privé, je ne m'étendrai pas sur ce cas. Si vous envisagez d'utiliser named pour un service, vous devriez vraiment le faire pour tous, juste pour simplifier la configuration. Dans cette section je supposerai que la passerelle de réseau privé gère la résolution de noms tant pour le réseau privé que pour les requêtes extérieures.

À l'heure où j'écris, sous la version 8.2.2 du paquet BIND, il n'est pas possible pour un démon named unique de produire des réponses différenciées en fonction de l'interface sur laquelle arrive la requête. On veut que la résolution de noms se comporte de manière différente si la requête vient du monde extérieur parce que les adresses IP du réseau privé ne doivent pas être envoyées à l'extérieur ; par contre, on doit être capable de répondre à des requêtes émanant du réseau privé. Une réflexion existe sur de nouveaux mot-clé « view » qui pourraient, à l'avenir, être intégrés à BIND pour combler cette lacune, mais, avant que cela ne soit effectif, la solution est de faire fonctionner deux démons named avec des configurations différentes.

D'abord, configurez le serveur de noms du domaine privé comme décrit dans la section résolution DNS sur le réseau privé, le FAI gère le domaine, il constituera le « resolver » visible depuis le réseau privé.

Ensuite, vous devez mettre en place le DNS de votre domaine de façon à ce qu'il soit visible des hôtes du monde extérieur. D'abord, vérifiez auprès de votre FAI s'il se déléguera lui-même les recherches DNS inversé sur vos adresses IP. Bien que la norme DNS d'origine ne donne pas la possibilité de contrôler le DNS inversé sur des sous-réseaux plus petits qu'un réseau de classe C, une méthode de contournement a été développée qui fonctionne avec tous les clients compatibles DNS et a été ébauchée dans la RFC 2317 (à l'adresse http://www.ietf.orf/rfc/rfc2317.txt). Si votre provider accepte de vous déléguer le DNS inversé sur votre série d'adresses IP, vous devez obtenir de lui le nom du pseudo-domaine in-addr qu'il a choisi pour la délégation (la RFC ne propose pas de normalisation pour une utilisation ordinaire) et vous devrez déclarer votre autorité sur ce pseudo-domaine. Je supposerai que le FAI vous a délégué l'autorité et que le nom du pseudo-domaine est 8.1.1.10.in-addr.arpa. L'ISP devra créer des entrées sous la forme : 

8.1.1.10.in-addr.arpa.     2H IN CNAME 8.8.1.1.10.in-addr.arpa.
9.1.1.10.in-addr.arpa.     2H IN CNAME 9.8.1.1.10.in-addr.arpa.
10.1.1.10.in-addr.arpa.    2H IN CNAME 10.8.1.1.10.in-addr.arpa.
etc.

dans son fichier de zone pour le domaine 1.1.10.in-addr.arpa. La configuration de votre fichier de zone 8.1.1.10.in-addr.arpa est donnée plus loin dans cette section.

Si votre provider accepte de vous déléguer le contrôle du DNS inversé, il créera, pour les adresses IP sous votre contrôle, des entrées CNAME dans la table des zones de son DNS inversé qui pointent vers les enregistrements correspondants dans votre pseudo-domaine comme montré ci-dessus. S'il n'envisage pas de vous déléguer l'autorité, vous devrez lui demander de mettre à jour son DNS à chaque fois que vous ajouterez, supprimerez ou changerez le nom d'un hôte visible depuis l'extérieur dans votre domaine. Si la table DNS inversé n'est pas synchronisée avec les entrées DNS direct, certains services peuvent émettre des avertissements ou bien refuser de traiter des requêtes produites par des machines affectées par ce dysfonctionnement.

Vous devez maintenant mettre en place un second named, celui là pour traiter les requêtes provenant de machines à l'extérieur de la passerelle de réseau privé.

D'abord, créez un second fichier de configuration, par exemple /etc/named.ext.conf pour les requêtes sur l'interface externe. Dans notre exemple, il pourrait être comme suit : 

options {
        directory "/var/named";
        listen-on { 10.1.1.9; };
};
 
zone "." {
        type hint;
        file "root.hints";
};
 
zone "0.0.127.in-addr.arpa" {
        type master;
        file "pz/127.0.0";
};
 
 
zone "8.1.1.10.in-addr.arpa" {
        type master;
        file "ext/8.1.1.10";
};
 
zone "example.com" {
        type master;
        notify no;
        file "ext/example.com";
};

Les fichiers root.hint et pz/127.0.0, tous les deux sous /var/named, sont partagés par les démons actifs. Le fichier /ext/8.1.1.10 est comme suit : 

$TTL 86400
 
@       IN      SOA             fred.example.com. root.fred.example.com. (
                                1               ; numéro de série
                                10800           ; mise à jour            3 heures
                                3600            ; tentative après échec  1 heure
                                3600000         ; délai d'expiration     1000 heures
                                86400 )         ; TTL minimale           24 heures
                NS      dns.example.com.
9       IN      PTR     fred.example.com.
                PTR     dns.example.com.
                PTR     mail.example.com.
10      IN      PTR     betty.example.com.
                PTR     www.example.com.
                PTR     ftp.example.com.

Le fichier ext/example.com contient ce qui suit : 

$TTL 86400
 
@               IN      SOA     example.com. root.fred.example.com. (
                                10021   ; numéro de série
                                8H      ; mise à jour             8 heures
                                2H      ; tentative après échec   2 heures
                                1W      ; délai d'expiration      1 semaine
                                1D      ; durée de vie minimale   1 jour
                        )
                        NS              fred.example.com.
        IN              A               10.1.1.9
        IN              MX          10  mail.example.com.
        IN              MX          20

Site hébergé sur un Cloud Public IKOULA Ikoula