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.
(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).
(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.
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 <machine mail du FAI>. localhost A 127.0.0.1 fred A 10.1.1.9 betty A 10.1.1.10 dns CNAME fred mail CNAME fred www CNAME betty ftp CNAME betty
Démarrez les deux démons sur votre passerelle de réseau privé. Mettez ce qui suit dans vos scripts d'initialisation :
/usr/sbin/named -u dnsuser -g dnsgroup /etc/named.conf /usr/sbin/named -u dnsuser -g dnsgroup /etc/named.ext.conf
J'ai supposé ici que vous avez créé l'utilisateur sans privilège « dnsuser »
et le groupe sans privilège correspondant « dnsgroup ». Si un bogue se fait jour,
permettant à un attaquant d'exécuter du code à l'intérieur de named, l'agresseur
sera limité aux actions permises à un utilisateur sans privilège. Le répertoire
/var/named et les fichiers qui y sont inclus ne doivent pas être modifiables
par « dnsuser ».
Les machines du réseau privé doivent avoir leur résolution de noms réglée pour s'en référer à dns.example.com (à l'IP 192.168.1.1 dans notre exemple) alors que les machines visibles depuis l'extérieur peuvent envoyer leurs requêtes à l'interface externe de la passerelle réseau (à l'IP 10.0.1.9) ou au serveur de noms du FAI.
Dans cette configuration, vous avez choisi d'exposer tous vos hôtes. Vous avez une « véritable » adresse IP pour chacune des machines de votre domaine et vous avez communiqué à votre FAI la liste des noms de machines et de leurs adresses IP. Le FAI vous a donné l'adresse d'un au moins de ses serveurs de noms. Vos machines Linux sont alors configurées pour la résolution de noms dans /etc/resolv.conf :
search example.com nameserver <premier hôte DNS> nameserver <deuxième hôte DNS>
Les machines Windows sont configurées de la même manière dans les boites de dialogue de configuration du réseau.
Si vous décidez de déplacer votre domaine sur de nouvelles adresses IP, soit parce que vous devez changer de FAI soit parce que vous avez apporté des modifications à vos services et que ceci vous impose de migrer vers de nouvelles adresses IP chez le même FAI, vous devrez faire quelques préparatifs avant la migration.
Vous devez mettre les choses en place de façon à ce que, avant la migration, l'adresse IP demandée par une recherche DNS quelque part dans le monde pointe correctement sur l'adresse IP d'origine et, qu'ensuite, après la migration, elle pointe rapidement sur la nouvelle adresse IP. Des sites distants peuvent avoir mis en cache votre adresse IP, et des requêtes postérieures peuvent obtenir une réponse localement, depuis le cache, plutôt qu'en questionnant les serveurs appropriés. L'effet de ceci peut être que des personnes ayant visité votre site récemment sont dans l'impossibilité de se connecter alors que de nouveaux visiteurs récupèrent des informations valides non mises en cache. Le fait que les serveurs racine ne soient mis à jour que deux fois par jour complique encore plus les choses ; ainsi il est difficile d'accélérer un changement fait à l'identité de vos serveurs DNS primaire et secondaire dans les serveurs racine.
La manière la plus simple de faire la transition est sûrement de dupliquer son site en entier, ou au moins ses composantes visibles publiquement, sur la nouvelle IP, déclarer la modification et attendre que le trafic bascule complètement sur la nouvelle adresse IP. Cependant, ce n'est probablement pas très faisable.
Ce que vous pouvez faire est de vous arranger avec votre nouveau FAI (ou avec votre FAI actuel si vous changez juste d'adresses chez le même FAI) afin qu'il héberge le DNS primaire et le DNS secondaire pendant le transfert. Ceci devrait être fait au moins un jour avant le déplacement. Demandez-lui de positionner la TTL (durée de vie) de cet enregistrement sur quelque chose de suffisamment petit (par exemple 5 minutes). Les exemples de fichier DNS montrés plus haut dans cette section ont tous des valeurs TTL positionnées sur 86400 secondes (1 jour). Si votre TTL est plus longue que cela, vous devrez faire le changement plus longtemps à l'avance. En définitive, voici ce que vous devez faire. Si la configuration actuelle de la TTL de votre domaine est, disons, N heures, alors ce qui suit doit être réalisé plus que N heures avant le déplacement :
Remarquez que vous ne pouvez pas accélérer le processus en réduisant la valeur actuelle de la TTL de votre domaine, à moins que vous ne l'ayez déjà fait au moins N heures avant le déplacement.
Maintenant, vous êtes prêt pour le transfert. Migrez vos machines sur les nouvelles adresses IP. Synchronisez ceci avec une mise à jour des enregistrements DNS de votre FAI de façon à ce qu'ils pointent sur les nouvelles adresses. Dans un délai de 5 minutes (la petite TTL que vous avez enregistrée pour le transfert), le trafic devrait avoir basculé sur le nouveau site. Vous pouvez maintenant arranger la section autorisée du DNS à votre goût, vous rendant primaire si c'est ce que vous voulez et repositionant la TTL sur une valeur raisonnablement grande.
Les configurations décrites dans la section Mettre en place la résolution de noms ont des enregistrements MX qui pointent sur une machine « mail.example.com ». L'enregistrement MX avec la valeur de priorité la moins grande signale aux sites distants où envoyer le courrier électronique. Les autres enregistrements de MX avec des valeurs de priorité plus élevées sont utilisés comme des échangeurs de mél de secours. Ces « secours » retiendront les messages pendant une certaine durée si l'échangeur primaire n'est pas en mesure, pour une raison quelconque, d'accepter les messages. Dans les exemples de cette section, j'ai supposé que fred.example.com sous son alias de mail.example.com, gère la messagerie pour le domaine. Si vous avez choisi de laisser le FAI héberger de votre messagerie, vous devrez modifier ces enregistrements MX de façon à ce qu'ils pointent sur les machines appropriées du FAI. Demandez à l'assistance technique de votre fournisseur quels sont les noms des hôtes que vous devez utiliser pour les enregistrements MX dans les divers fichiers.
Si vous avez choisi d'héberger intégralement la messagerie pour votre domaine, vous devrez prendre des mesures spéciales pour les messages entrants sur les hôtes du réseau privé. À moins que vous ne soyez vigilant, les messages ont de fortes chances de rester en rade s'ils attendent sur une machine et que le destinataire correspondant est connecté sur une autre machine. Pour des questions de sécurité, je recommande que les messages entrants ne soient pas accessibles depuis les hôtes publiquement visibles (ceci pouvant aider à dissuader un PHB qui veut que sa station de travail soit sur une adresse IP réelle et qui s'étonne de se faire planter sa machine par un ping de la mort deux fois par jour). Sendmail s'accomode très bien d'un système de distribution de courrier transparent sur le réseau privé. Si quiconque souhaite fournir ici des solutions testées pour d'autres démons de messagerie, j'accueille volontiers toute contribution.
Afin que les messages délivrés sur un hôte soient accessibles depuis toutes les machines, la solution la plus simple est d'exporter le répertoire de spool de la messagerie avec des droits de lecture/écriture sur l'ensemble du réseau privé. La passerelle de réseau privé se comportera comme un échangeur de messagerie pour celui-ci et doit donc avoir les droits de « root » en ce qui concerne l'écriture sur le disque du répertoire de spool de la messagerie. Les autres clients peuvent ou non rembarrer « root », à votre gré. Ma philosophie générale en matière de sécurité est de ne pas attribuer ces privilèges à moins qu'il n'y ait une bonne raison de le faire, ainsi j'interdis l'utilisateur « root » depuis toutes les machines sauf depuis la passerelle de réseau privé. Ceci a pour effet que root ne peut lire son courrier que depuis cette machine mais ce n'est pas vraiment un handicap sérieux. Notez que le répertoire réseau de spool peut être localisé sur la passerelle de réseau privé elle-même, exporté par NFS, ou qu'il peut être localisé sur l'un des serveurs internes, exporté sur l'ensemble du réseau privé. Si le répertoire de spool réside sur la passerelle de réseau privé, il n'y a pas intérêt à interdire « root » pour cette machine. Si le répertoire de spool est sur un autre serveur, notez que le courrier ne sera pas délivrable si ce serveur, la passerelle, ou le réseau les reliant sont hors-service.
Pour les machines Windows de votre réseau privé, vous pouvez soit mettre en place un serveur POP sur le serveur de mail ou bien utiliser Samba pour exporter le répertoire de spool sur ces machines. Les machines Windows doivent être configurées pour envoyer et recevoir les messages sous un nom d'utilisateur Linux tel que joeuser@example.com, ainsi l'adresse mél de l'hôte est le nom de domaine uniquement, pas un nom de machine tel que barney.example.com. Le serveur SMTP sortant doit être localisé sur la passerelle de réseau privé qui sera chargée de la redirection des messages et de toute réécriture d'adresse.
Ensuite vous devrez configurer Sendmail pour qu'il redirige les messages
en provenance des machines du réseau privé et qu'il réécrive les adresses si
nécessaire. Récupérez les sources les plus récents depuis le site web de Sendmail
à l'adresse
http://www.sendmail.org. Compilez les exécutables et ensuite allez dans le sous-répertoire
cf/domain dans l'arborescence source de Sendmail et créez le nouveau fichier
suivant : example.com.m4.
divert(-1) # # Copyright (c) 1998 Sendmail, Inc. All rights reserved. # Copyright (c) 1983 Eric P. Allman. All rights reserved. # Copyright (c) 1988, 1993 # The Regents of the University of California. All rights reserved. # # Par l'utilisation de ce fichier, vous acceptez les termes et conditions placés # dorénavant dans le fichier LICENCE qui peut être trouvé à la racine # de la distribution de sendmail # # # # Ce qui suit est un fichier générique de domaine. Vous devriez pouvoir # l'utiliser n'importe où. Si vous voulez le personnaliser, copiez-le dans un fichier # nommé comme votre domaine et faites les modifications; puis copiez les fichiers .mc # appropriés et changez `DOMAIN(generic)' pour qu'ils renvoient à vos fichiers # de domaine modifiés. # divert(0) define(`confFORWARD_PATH', `$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward')dnl FEATURE(redirect)dnl MASQUERADE_AS(example.com)dnl FEATURE(masquerade_envelope)dnl
Ceci définit le domaine example.com. Ensuite vous devez créer les fichiers
sendmail.cf qui seront utilisés sur le serveur de messagerie (la passerelle
de réseau privé), et sur les autres noeuds du réseau privé.
Créez le fichier suivant dans l'arborescence de Sendmail, sous cf/cf :
example.master.m4
divert(-1) # # Copyright (c) 1998 Sendmail, Inc. All rights reserved. # Copyright (c) 1983 Eric P. Allman. All rights reserved. # Copyright (c) 1988, 1993 # The Regents of the University of California. All rights reserved. # # Par l'utilisation de ce fichier, vous acceptez les termes et conditions placés # dorénavant dans le fichier LICENCE qui peut être trouvé à la racine # de la distribution de sendmail # # # Ceci est un fichier prototype pour une configuration qui ne supporte rien # à part des connexions SMTP de base sur TCP. # # Vous devez changer la macro `OSTYPE' pour spécifier le système d'exploitation # sur lequel ça va marcher ; cela indiquera la localisation de fichiers de support # divers pour l'environnement de votre système d'exploitation. Vous DEVEZ # créer un fichier de domaine dans ../domain et le référencer en ajoutant une # macro `DOMAIN' après la macro `OSTYPE'. Je vous recommande de # commencer par copier ce fichier sous un autre nom de façon à ce que les mises # à jour de sendmail n'écrasent pas vos modifications. # divert(0)dnl OSTYPE(linux)dnl DOMAIN(example.com)dnl FEATURE(nouucp) FEATURE(relay_entire_domain) FEATURE(`virtusertable', `hash /etc/sendmail/virtusertable')dnl FEATURE(`genericstable', `hash /etc/sendmail/genericstable')dnl define(`confPRIVACY_FLAGS', ``noexpn,novrfy'')dnl MAILER(local) MAILER(smtp) Cw fred.example.com Cw example.com
Dans cet exemple, on a désactivé les commandes « expn » et « vrfy ». Un agresseur pourrait tester en boucle avec « expn » des alias tels que « personnel » ou « employes » jusqu'à ce qu'il trouve un alias qui lui développe plusieurs noms d'utilisateurs. Il peut alors essayer certains mots de passe médiocres dans le but d'entrer (en supposant qu'il puisse obtenir une invite de login - les réglages de sécurité dans la section Sécuriser votre domaine sont définis de façon à ce qu'aucune invite de login ne soit possible pour les attaquants de l'extérieur).
L'autre fichier que vous devez créer définira le sendmail.cf pour les machines
esclaves : example.slave.m4.
divert(-1) # # Copyright (c) 1998 Sendmail, Inc. All rights reserved. # Copyright (c) 1983 Eric P. Allman. All rights reserved. # Copyright (c) 1988, 1993 # The Regents of the University of California. All rights reserved. # # Par l'utilisation de ce fichier, vous acceptez les termes et conditions placés # dorénavant dans le fichier LICENCE qui peut être trouvé à la racine # de la distribution de sendmail # # # # Ceci est un prototype pour un « null-client » -- c'est à dire un client qui # ne fait rien à part rediriger tout le courrier vers un échangeur de mail. # IL N'EST PAS UTILISABLE EN L'ETAT !!! # # Pour l'utiliser, vous devez utiliser la fonction nullclient avec le nom de # de l'échangeur de mail comme argument. Vous DEVEZ également définir un # `OSTYPE' pour définir la localisation des répertoires de file d'attente et apparentés. # En plus, vous POUVEZ sélectionner la fonction nocanonify. Cela entrainera # l'envoi d'adresses non qualifiées par la connection SMTP; normalement # elles sont qualifiées avec le nom de masquage, qui est par défaut le # nom de la machine de connexion. # A part ça, il ne devrait pas contenir d'autre ligne. # divert(0)dnl OSTYPE(linux) FEATURE(nullclient, fred.$m) Cm example.com
Vous compilez les fichiers sendmail.cf qui vont bien avec la commande :
make example.master.cf example.slave.cf
et puis vous copiez les fichiers sur les machines appropriées sous le nom
de sendmail.cf.
Cette configuration installe la plupart des fichiers de configuration de
Sendmail dans le sous-répertoire /etc/sendmail et amène sendmail à analyser
et à utiliser deux fichiers spécifiques, virtusertable.db et genericstable.db.
Pour utiliser ces fichiers spécifiques, créez leurs fichiers source. D'abord,
virtusertable.db :
John.Public@example.com jpublic Jane.Doe@example.com jdoe@somemachine.somedomain abuse@example.com root Pointyhaired.Boss@example.com #phb#@hotmail.com
Ceci met en relation les adresses de messagerie du courrier entrant avec
de nouvelles destinations. Les messages envoyés à John.Public@example.com sont
délivrés localement sur le compte Linux jpublic. Les messages pour Jane.Doe@example.com
sont redirigés vers un autre compte de messagerie, éventuellement, dans un
domaine différent. Le courrier pour abuse@example.com est envoyé à root et
ainsi de suite. L'autre fichier est genericstable.src :
jpublic John.Public@example.com janedoe Jane.Doe@example.com whgiii Pointyhaired.Boss@example.com
Ce fichier change le nom de l'expéditeur des courriers sortants provenant
de la messagerie locale. Alors qu'il ne peut manifestement pas avoir d'incidence
sur l'adresse de retour des messages envoyés directement par jdoe@somemachine.somedomain,
il vous permet de réécrire l'adresse des expéditeurs en changeant leurs noms
d'utilisateurs internes selon le « plan d'adressage mél » que vous avez choisi.
En dernier ressort, créez le fichier Makefile suivant dans /etc/sendmail :
all : genericstable.db virtusertable.db virtusertable.db : virtusertable.src makemap hash virtusertable < virtusertable.src genericstable.db : genericstable.src makemap hash genericstable < genericstable.src
Exécutez make pour créer les fichiers compilés interprétables par sendmail, et n'oubliez pas de ré-exécuter make et de redémarrer sendmail (ou de lui envoyer un SIGHUP) après toute modification de chacun de ces fichiers « .src ».
Je n'ai d'expérience que sur Sendmail. Si quiconque souhaite écrire cette section, contactez-moi svp. Sinon, il est possible que j'essaye plus tard de donner moi-même des détails sur des MTA tels que Postfix, Exim ou smail. Je préférerais vraiment que quelqu'un d'autre, qui utilise ces programmes, écrive cette section.
Pour des raisons de sécurité, vous devriez mettre en place votre serveur web public sur une machine à l'extérieur du réseau privé et non sur la passerelle. Si le serveur web a besoin d'accéder à des bases de données ou à d'autres ressouces entreposées sur le réseau privé, la situation se complique tant du point de vue du réseau que du point de vue de la sécurité. Une telle configuration est hors du champ de ce document.
Les précisions sur l'installation du serveur en lui même peuvent être trouvés dans la documentation d'apache et dans le WWW-HOWTO de Linux à l'adresse ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO ou à l'adresse http://www.freenix.org/unix/linux/HOWTO/WWW-HOWTO.html en version française.
Une fois encore, votre serveur FTP devrait être localisé sur une des machines visibles depuis l'extérieur et non sur la passerelle de réseau privé. Suivez les indications qui sont fournies avec votre démon FTP. Assurez-vous d'avoir récupéré la version la plus récente car il existe des failles de sécurité dans les vieilles versions de beaucoup de serveurs. Si votre site FTP ne nécessite pas que des utilisateurs anonymes y transfèrent des fichiers, assurez-vous d'avoir désactivé cette fonction dans le démon. Je recommande que la « connexion-utilisateur » (non anonyme) ne soit pas autorisée sur le serveur, ceci impliquant que vos utilisateurs utilisent scp, la commande de copie à distance du shell sécurisé, pour toute mise à jour de fichier qu'ils seraient amenés à faire sur le serveur FTP. Cela donne également aux utilisateurs de bonnes habitudes de sécurité et protège du problème de « routeur hostile » décrit dans la section Sécuriser votre domaine.
Ce sujet est présenté en détail dans la section Configurer votre Pare-feu.