-- MINIPROJET -- CONFIGURATION DE DNS POUR UN RESEAU DE PETITE ENTREPRISE AVEC BIND9 SOUS UBUNTU LINUX 10.04 ''Lucid Lynx"

VANLERBERGHE Nicolas -- MINIPROJET -- CONFIGURATION DE DNS POUR UN RESEAU DE PETITE ENTREPRISE AVEC BIND9 SOUS UBUNTU LINUX 10.04 ''Lucid Lynx" 1

INDEX A - Historique du système de noms de domaines B - Le système de noms de domaines C - Le principe de DNS C1 - Domaines C2 - Délégation d'autorité et zones C3 - Serveurs de noms de la racine C4 - La résolution d noms C5 - Les serveurs cache C6 - La résolution inverse D - Présentation du modèle réseau Schéma du modèle réseau Schéma de principe VMWare E - Installation du DNS pour le réseau local E1 - Construction du fichier de zones E11 - Zone directe E12 - Zone inverse E13 - Changement de l' appartenance et du groupe des fichiers de zone E14 - Vérification du fichier HOSTS E15 - Modification du fichier resolv.conf E16 - Véreification de la conformité de configuration de BIND9 F - Installation du DHCP et du DNS ynamique sur SRVLAN F1 - Installation du serveur DHCP F2 - Vérifications G - Mise en oeuvre de DNS sur SRVDMZ, délégation de zone à SRVLAN et accès internet pour le LAN G1 - Nous allons cacher l'existence des serveurs racine à SRVDMZ G2 - Création des fichiers de zones sur srvdmz G3-configuration des options générales "forward" sur srvdmz G4- création du fichier de zone directe sur srvdmz G5- création du fichier de zone inverse sur srvdmz G6-vérification des fichiers hosts et resolv.conf G7- cacher l'existence des serveurs racines G8- configuration des options générales "forward" sur srvlan G9 - Vérifications H - ouverrture de l'entreprise vers l' extérieur 2

I - Le mécanisme des vues split DNS et transfert de zones I1- Définition des ACL. I2 - Définition des vues I2- Modification du fichier named.conf de bind9 sur srvdmz I3- Création de nos fichiers de zones directe et inverse pour la vue externe I4- installation et configuration de bind9 sur ns02.hermite2012.tk. J - Configuration des translations d' adresses J1 - Définir les redirections de ports sur les boxs et sur SRVFWL J2 - Vérifications 3

A -Historique du système de noms de domaine. Durant les années 70 ARPAnet est demeuré une petite communauté de quelques centaines d'hôtes. La table de correspondances entres Hôtes et adresses était entretenue par le "Network Information Consortium" ( NIC ) au "StanfordResearch Institute" (SRI )dans un fichier unique HOSTS.TXT.Ce fichier n'était téléchargeable qu' à partir d' une machine unique SRI-NIC. Les administrateurs ARPANET envoient leurs modifications par e-mail au NIC, et récupèrent périodiquement le dernier HOSTS.TXT par connexion ftp au SRI-NIC. Les mises à jour du fichier HOSTS.TXT se font à la cadence de l'ordre de une à deux fois par semaine.la taille de HOSTS.TXT a augmenté proportionnellement à l' arrivée de nouveaux hôtes sur le réseau, et le trafic généré, s'est envolé, un nouvel hôte entrainant non seulement, une nouvelle entrée dans HOSTS.TXT, mais également une nouvelle diffusion potentielle par SRI-NIC. Lors de l' évolution du réseau ARPAnet vers l' utilisation de TCP/IP développé par l 'université de Berckeley, la taille des hôtes connectés a explosé, engendrant ainsi une séries de problèmes dans l'utilisation de HOSTS.TXT Le traffic et la charge. Le coût en terme de charge du réseau et du processeur, est devenu bien trop élevé. Les conflits de noms. Dans HOSTS.TXT deux hôtes ne pouvaient avoir le même nom. Même si le NIC garantissait l' unicité de l'attribution des adresses IP. Il ne pouvait en revanche empêcher quelqu'un d'utiliser un nom d' hôte déjà présent sur le réseau. Ainsi si un nouvel hôte apparaissait sur le réseau avec par exemple un nom déjà utilisé par un serveur de messagerie, ceci engendrait une interruption du service dans la zone concernée. Cohérence. La gestion d' un fichier HOSTS.TXT statique dans un réseau en pleine expansion est devenue quasiment impossible. Le temps mis par le fichier HOSTS.TXT pour atteindre les hôtes en périphérie du réseau ne garantissait pas son exactitude. En effet, entre temps un nouvel hôte a pu, soit faire son apparition, soit avoir changé son adresse, ou encore avoir disparu du réseau. 4

Une réflexion a lors été lancée par les autorités de ARPAnet avec les points de reflexion suivants : - Trouver un système permettant de résoudre les problèmes engendrés par l' utilisation d' un système central de descriptions d' hôtes0 - Données gérées localement, mais accessibles globalement - Décentralisation de la gestion pour éliminer le goulot d'étranglement sur SRI-NIC - Gestion locale permettant ainsi d'avoir des informations plus facilement mises à jour. - Espace de nom hiérarchique garantissant l' unicité des noms. La conception hiérarchique du nouveau système fut alors confiée à PAUL MOCKAPETRIS en 1983, alors en poste à l' Information Science Institutede l' USC. En 1984, il produisit les RFC 882 et 883 qui décrivaient le système de nom de domaine. Ces deux RFC furent ultérieurement remplacées par les RFC 1034 et 1035 toujours d'actualité. Les RFC 1034 et 1035, sont aujourd'hui complétées par d'autres RFC traitant de mise en œuvre, de gestion de sécurisation et de mises à jours automatiques des serveurs de noms. 5

B - Le système de noms de domaines "." com edu gov mil Base de données du DNS Le système de noms de domaine est une base de données distribuées, ceci permet un contrôle local de la base de données globale, les données de chaque segment étant accessibles de partout par un mécanisme client serveur. Des duplications et des mémoires caches règlent les problèmes de robustesse et de performance. La base de données du DNS est représentée comme un arbre inversé, avec le nœud racine en haut, un nom unique identifie chaque noeud de l'arbre relativement à son nœud parent. Le nœud racine est représenté par un point unique ( ". " ). Chaque nœud est aussi la racine d' un nouveau sous-arbre de l'arbre global. Chaque sous arbre, représente une partie de la base de données globale. Chaque domaine peut être divisé en sousdomaines. Les sous domaines sont représentées comme des enfants de leur domaine parent. 6

Chaque domaine possède un nom unique, et indique sa position dans la base de données. Le nom de est la réunion de tous les noms de noeud séparés par un ". " en partant de la feuille jusqu' à la racine de l'arbre inversé. "." tk hermite2012 intra clientxp1 clientxp1.intra.hermite2012.tk. Base de données du DNS 7

Dans le DNS chaque domaine peut être géré par un organisme différent, chaque organisme peut scinder son domaine en sous-domaines, et distribuer la responsabilité des sous domaines à d'autres organismes fr tk hermite2012 C' est VANLERBERGHE Nicolas un stagiaire de TSRIT à l' AFPA de DUNKERQUE qui gère le hermite2012.tk. Dans le cadre de son miniprojet de fin d'apprentissage on lui a demandé de présenter DNS, il a donc enregistré son domaine gratuitement auprès de DOT.tk. Et a demandé la délégation de la gestion de son domaine en indiquant à DOT.TK l'adresse IP et le nom des serveurs DNS de sa zone. C est Dot TK une filiale du gouvernement de Tokelau, son entreprise de communication Teletok et de Taloha Inc, une société basée à San Francisco (USA) avec une filiale à Amsterdam, aux Pays-Bas qui gère le.tk jusqu en 2014. Il distribue actuellement gratuitement les noms de domaine en.tk. 8

Un domaine peut contenir simultanément des hôtes, des sous domaines, des alias pointant vers des noms canoniques. "." tk hermite2012 www intra www clientxp1 srvlan www Dans l' exempleci dessus: - "intra" est un sous domaine de hemite2012.tk. - "www.intra" est un alias pointant vers "srvlan.intra" - clientxp1 et srvlan sont des noms d' hôtes. Illustration en rouge : Nous voyons que nous ne pouvons pas avoir deux nœuds possédant le même nom au même niveau, par analogie aux fichiers et dossier d' un système d' exploitation, nous ne pouvons pas avoir deux fichiers portant le même nom au sein d' un même dossier. Par contre rien n' empêche au sein d' un domaine à partir du moment où les enregistrements de se situent pas au même niveau de l'arborescence, d' avoir deux fois un même nom : - www.hermite2012.tk. -www.intra.hermite2012.tk. 9

C - Principes de DNS C - 1 Domaines "." tk noeudintra.hermite2012.tk. domainehermite2012.tk. hermite2012 domaineintra.hermite2012.tk. intra Un domaine est tout simplement un sous arbre de l' espace de nommage, le nom d'un domaine est le nom du noeud se situant au sommet de l'arbre. Ainsi le sommet du domaine hermite2012.tk. est le noeudhermite2012.tk. Tout nom du sous arbre est condidéré comme faisant partie du domaine, ainsi le nom intra.hermite2012.tk. fait partie du domaine hermite2012.tk et fait également partie intégrante du domaine.tk. Dans la figure ci dessus nous pouvons différencier les domaines par leur niveau, " tk " est un domaine de premier niveau " Top Level Domain " car enfant direct de la racine ". ", et hermite2012 est un domaine de second niveau car enfant du domaine " tk ". 10

C - 2 Délégation d'autorité et zones "." fr tk edu gov hermite2012 berckeley intra La distinction entre domaines et zones est pour le moins subtile et mérite que l'on s'y attarde un instant. Les domaines de niveau supérieur ainsi que de nombreux domaines de niveau inférieur sont divisés en unités plus petites et plus faciles à gérer par délégation d' autorité. On voit dans la figure ci dessus que le domaine ".tk" scindé en zones : - La zone "tk" - La zone "hermite2012.tk", elle même subdivisée avec la zone "intra.hermite2012.tk" Il est normal que ce soit aux administrateurs de "hermite2012.tk" de gérer leur propre base de donnée et non à ceux de la zone ".tk." de le faire. La base de donnée de la zone ".tk." contiendra essentiellement les informations de délégations des zones de niveau inférieur. exemple : - la zone ".tk" contiendra les noms et adresses des serveurs de noms de la zone "hermite2012.tk - la zone "hermite2012.tk" contiendra les informations concernant les serveurs de noms de sa zone, les informations de délégation pour la zone " intra.hermite2012.tk.", les correspondances noms, adresses, services mail, pour sa propre zone... - la zone "intra.hermite2012.tk" quant à elle contiendra une base de donnée des hôtes de son réseau local et les directives indiquant à qui retransmettre les requêtes ne concernant pas la zone dont elle a autorité... 11

C - 3 Serveurs de noms de la racine Les serveurs de noms de la racine savent où se trouvent les serveurs de noms de chaque domaine de niveau supérieur (la plupart des serveurs de noms de la racine ont autorité sur les domaines de niveau supérieur).lorsqu ils répondent à une requête quelconque les serveurs de la racine renvoient au minimum des informations concernant les serveurs de noms du domaine inférieur, qu il faudra alors contacter pour poursuivre la résolution de noms. En absence d informations supplémentaires, un serveur DNS local qui effectuera une recherche pour un résolveur, interrogera en premier lieu les serveurs de la racine. En effet, chaque serveur de noms a connaissance des adresses des serveurs de noms de la racine. S il arrivait que tous les serveurs de la racine deviennent indisponibles pendant un grand laps de temps, plus aucune requête n aboutirait et toute communication serait alors interrompue. Les serveurs de noms de la racine occupent une position centrale dans l architecture d internet, ils peuvent recevoir plusieurs milliers de requêtes à la seconde, on voit par là qu ils sont soumis à un trafic très dense. La position stratégique centrale des serveurs de noms de la racine, les expose à des attaques organisées visant à les inonder de requêtes simultanées afin de les faire tomber en déni de service. Une attaque est survenue en 2002 sur les serveurs ROOT, 7 sur les 13 serveurs sont devenus inopérants après une attaque massive en deni de service. Une technique de duplication de serveurs a été mise en place. Le serveur logique F possède 46 répliques toutes accessibles à la même adresse IP grace à une technique de routage dite anycast, c est le réseau qui se chargera de router au mieux les demandes de résolutions vers le serveur le plus approprié. Certains serveurs DNS racine sont en fait de grosses grappes de serveurs utilisant anycast. Les serveurs C, F, I, J, K et M sont éparpillés sur plusieurs continents et utilisent anycast pour fournir un service décentralisé. Du coup, la plupart des serveurs racine physiques sont en dehors des États-Unis. La RFC 3258 décrit comment anycast est utilisé pour fournir un service DNS. Plusieurs cctld utilisent également cette technique, comme le.fr [1]. Cette technique est aussi utilisée sur le registre suisse qui gère le nom de domaine de premier niveau. 12

C - 4 la résolution de noms. Requête www.hermite2012.tk. Renseignements sur les Serveurs de noms de tk Serveurs de noms de. Requête www.hermite2012.tk. Renseignements sur les Serveurs de noms de Hermite2012.tk Serveurs de noms de tk tk fr be Requête www.hermite2012.tk. Serveurs de noms de RESOLVER Réponse Adresse de www.hermite2012.tk hermite2012.tk DOT Hermite2012 @SOA ns01.hermite2012.tk. root.hermite2012.tk.. Contenu... omis.. IN NS ns01.hermite2012.tk. IN NS ns02.hermite2012.tk. IN MX srvdmz.hermite2012.tk. Srvdmz IN A 88.169.218.210 ns01 IN A 88.169.218.210 ns02 IN A 77.234.33.25 www IN CNAME srvdmz ftp IN CNAME srvdmz www ns01 Processus de résolution de l'adresse www.hermite2012.tk. 13

Résolution itérative manuelle de www.hermite2012.tk. 14

a.root-servers.net Serveurs de noms B 2 root-c.taloha.tk C 1 3 4 ns02.hermite2012.tk A 5 6 D? 7 1 www.hermite2012.tk. = 88.169.218.210 Resolver www.hermite2012.tk? Processus de résolution sans cache 15

C - 5 Les serveurs cache La plupart des serveurs DNS jouent également le rôle de serveur cache, le serveur apprend beaucoup de ses précédentes requêtes. A chaque fois qu' il se réfère à une nouvelle zone il apprend quels serveurs en ont autorité.le serveur placera donc dans son cache toutes ses précieuses informations qui lui serviront probablement pour une requête ultérieure. CACHE tk primary name-server ROOT-A.TALOHA.TK. nameserver = ROOT-A.taloaha.tk. nameserver = ROOT-B.taloha.tk. nameserver = ROOT-C.taloaha.tk. nameserver = ROOT-D.taloha.tk. internet address 217.119.57.22 hermite2012.tk primary nameserver NS01.HERMITE2012.TK. nameserver = NSO1.hermite2012.tk. internet address 88.169.218.210 nameserver = NS02.hermite20120.tk. internet address 77.237.33.25 A 5 6 D? 7 ns01.hermite2012.tk 1 ftp.hermite2012.tk. = 88.169.218.210 Resolver ftp.hermite2012.tk? Lors de sa précédente recherche le serveur DNS A a appris, non seulement l' adresse correspondant à www.hermite2012.tk., mais également de nombreuses autres informations précieuses : La liste des serveurs ayant autorité sur la zone tk, et également la liste des serveurs de noms ayant autorité sur la zone hermite2012.tk. Sachant que sa recherche porte sur la zone hermite2012.tk, il va directement aller interroger l' un des serveurs ayant autorité sur la zone, sa résolution de noms se voit ainsi considérablement raccourcie. 16

C -6 La résolution inverse. Adresse IP 88.169.218.210 arpa in-address 88 169 218 Machine : ns01.hermite2012.tk. Domaine :210.218.169.88.in-address.arpa. 210 Etant donné qu il est aisé de retrouver une adresse lorsque l on dispose du nom, une section de l espace de nommage a été créée, cette zone utilise les adresses comme des noms. Dans la figure ci-dessus, nous voyons une adresse IP de 32 de bits représentée par 4 nombres en décimal pointé, allant de 0 à 255 séparés par des points. Le domaine in-address.arpa. par exemple, peut contenir 256 sous domaines correspondants à la valeur que peut prendre le premier octet d une adresse IP. Chacun de ses sous domaines peuvent eux même contenir 256 sous domaines correspondantes aux valeurs de leurs octets respectifs, et ce, jusqu au 4eme niveau où l enregistrement de ressource attaché à cette valeur fait correspondre le nom complet de l hôte Ex : 210.218.169.88.in-addr.aprpa. PTR ns01.hermite2012.tk. Au final le domaine in-address.arpa. est suffisemment spacieux pour contenir toutes les addresses IPV4 existentes(soit 254^4 = 41 623 142 565 adresses..) 17

D - Présentation du modèle réseau retenu Ce modèle réseau est surtout un modèle basé sur l'apprentissage et constitue un bon labo pour mettre en application bon nombre de services réseaux dont pourrait avoir besoin une petite entreprise. Ce labo a été réalisé en virtualisant des serveurs linux Ubuntu 10.04 LTS, et des machines clientes Ubuntu desktop, et Windows XP Professionnel, afin de montrer que les services réseau offerts par ces serveurs ne se cantonnent pas à l'environnement linux, mais sont également disponibles pour les clients XP. La machine hôte VmWare sur laquelle nous faisons tourner toutes les machines virtuelles du labo avec un grand confort de travail, est dotée d' un processeur Intel Core I7 et dispose de 6 Go de mémoire Ram. Le système d'exploitation embarqué est un windows 7 en version 64 bits, et nous avons doté cette machine d'un disque dur SSD de 30 Go dont l'unique rôle est de recevoir les fichiers d' échange ( SWAP). 18

Schéma du modèle réseau ns02 srvfwl ns01 192.168.10.0 78.234.33.25 88.169.218.210 192.168.0.0 /24 192.168.2.0 /24.10.254.254.10.254.1.254 192.168.3.0 /24.1 srvlan.254 192.168.4.0 /24 dhcp dhcp clientxp1 clientubuntu2 La première chose à prendre en considération, et à mettre en oeuvre lorsque l' on monte un réseau est le service DNS, nous allons donc attribuer un rôle bien particulier à chacun de nos serveurs, leur donnant une position et un rôle bien précis au sein de l'arborescence de DNS. SRVLAN sera serveur DNS autoritaire pour la zone intra.hermite2012.tk., la zone intra.hermite2012.tk. correspond au domaine interne de l' organisation. Sa base de données DNS sera constituée de deux types d'entrées: - des entrées statiques, entrées manuellement par l'administrateur - des entrées dynamiques apprises par le serveur DHCP ( SRVLAN Fait également office de serveur DHCP ) La base de donnée du domaine " intra.hermite2012.tk." ne doit être disponible sur le réseau local, SRVLAN se verra donc déléguer l'autorité de cette zone par NS01. NS01 se trouve dans une zone sensible, car accessible aussi bien du réseau local, que de l' internet. Son rôle est primordial du point de vue de la communication de l' organisation avec l'extérieur, site web, serveur ftp public.. et le plus importants serveur maître autoritaire pour la zone hermite2012.tk. Son rôle n' étant pas de s'occuper de la base de donnée DNS du réseau local, mais plus de la partie orientée vers l'extérieur, il va déléguer l' autorité de la zone intra.hermite2012.tk. à SRVLAN.Il contiendra dans sa base de données des informations concernant les adresses de sites web, ftp, et du serveur secondaire pour la zone hermite2012.tk qui sera NS02 situé sur un autre site. NS01, sera configuré avec le principe du split DNS, grâce à un mécanisme de vues, il ne fournira pas les mêmes réponses que les requêtes proviennent du réseau interne ou de l 'extérieur. NS02 par souci de redondance, sera le serveur secondaire pour la zone hemite2012.tk. il répliquera sa base de donnée à partir de celle contenue par NS01 19

Schéma de principe VmWare srvdmz 192.168.2.1 88.169.218.210 Vmnet1 (Bridge) srvfwl Vmnet2-192.168.2.0 /24 192.168.0.10 192.168.2.254 192.168.0.254 192.168.0.2 srvlan Vmnet3-192.168.3.0 /24 Vmnet4-192.168.4.0 /24 La connexion internet se fait via un routeur modem freebox, les représentations nommées Vmnetx sont des switchs virtuels de VMWare Workstation. SRVDMZ est doté de : 1 interface réseau eth1 reliée à VMNET 2 @IP=192.168.2.1. 1 sous interface eth1:0 @IP=192.168.2.11, elle fournira une adresse IP virtuelle pour apache en https. SRVFWL est doté de 3 interfaces réseau : 1 interface réseau eth0 bridgée avec la carte réseau physique du système Hôte @IP=192.168.0.10. 1 interface réseau eth1 reliée à VMNET 2 @IP=192.168.2.254. 1 interface réseau eth2 reliée à VMNET 3 @IP=192.168.2.254. SRVLAN est doté de deux interfaces réseau : 1 interface réseau eth2 reliée à VMNET3 @IP=192.168.3.1. 1 interface réseau eth3 reliée à VMNET4 @IP=192.168.4.254. Les divers clients du LAN ont chacun une interface réseau reliée à VMNET4, sur le réseau 192.168.4.0/24. 20

E - Configuration du DNS pour le réseau local srvlan.1.254 192.168.3.0 /24 DHCP DNS 192.168.4.0 /24 dhcp dhcp clientxp1 clientubuntu2 root@srvlan:~# aptitude install bind9 root@srvlan:~# cd /etc/bind root@srvlan:/etc/bind# nanonamed.conf.local$ zone "intra.hermite2012.tk" IN { type master; file "db.intra.hermite2012.tk"; allow-update { 127.0.0.1; } ; on va autoriser les mises à jour par dhcp }; zone "4.168.192.in-addr.arpa" IN { type master; file "rev.intra.hermite2012.tk"; allow-update { 127.0.0.1; } ; on va autoriser les mises à jour par dhcp }; 21

E-1 Construction des fichiers de zone E-1-1- Zone directe root@srvlan:/etc/bind# cd /var/cache/bind root@srvlan:/var/cache/bind# nano db.intra.hermite2012.tk $TTL 86400 ; 1 day @ IN SOA srvlan.intra.hermite2012.tk. root.intra.hermite2012.tk. ( 2010111316 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200 ; expire (4 weeks) 604800 ; minimum (1 week) ) @ IN NS srvlan.intra.hermite2012.tk. srvlan A 192.168.4.254 ftp CNAME srvlan www CNAME srvlan E-1-2 Zone inverse root@srvlan:/var/cache/bind# nano rev.intra.hermite2012.tk $ORIGIN. $TTL 86400 ; 1 day @ IN SOA srvlan.intra.hermite2012.tk. root.intra.hermite2012.tk. 2010111311 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200 ; expire (4 weeks) 604800 ; minimum (1 week) ) @ IN NS srvlan.intra.hermite2012.tk. 254 PTR srvlan.intra.hermite2012.tk. E-1-3- Changement de l' appartenance du groupe pour les fichiers de zone root@srvlan:/var/cache/bind# chgrp bind * root@srvlan:chmod 664 * root@srvlan:/var/cache/bind# ls -l -rw-rw-r-- 1 bind bind 406 2010-11-22 19:38 db.intra.hermite2012.tk -rw-rw-r-- 1 bind bind 386 2010-11-22 19:42 rev.intra.hermite2012.tk 22

E-1-4 vérification du fichier hosts root@srvlan:/var/cache/bind# nano /etc/hosts 127.0.0.1 localhost.localdomainlocalhost 192.168.4.254 srvlan.intra.hermite2012.tk srvlan # The following lines are desirable for IPv6 capable hosts ::1localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters E-1-5 modification du fichier resolv.conf root@srvlan:/var/cache/bind# nano /etc/resolv.conf domain intra.hermite2012.tk search intra.hermite2012.tk la directive "domain" fixele domaine courant d'appartenance de la machine. la directive "search" ajoute le domaine "intra.hermite2012.tk" à toute demande de nom d'hôte non pleinement qualifié. exemple: une recherche sur "machine-test" sera transformée en "machine-test.intra.hermite2012.tk." avant d'envoyer une requête au serveur dns. E1-6 Vérification de la conformité de la configuration de bind9 Pour ce faire nous allons utiliser l' utilitaire "named-checkconf"; qui vérifie par défaut la configuration de "/etc/bind/named.conf" si la configuration est correcte, la commande ne retourne rien, en cas d' erreurs, la sortie est suffisamment explicite pour retrouver où l' erreur a été commise. root@srvlan:/var/cache/bind# named-checkconf root@srvlan:/var/cache/bind# La deuxième vérification consiste à contrôler la conformité de nos fichier de zones à l'aide de l'utilitaire "named-checkzone" root@srvlan:/var/cache/bind# named-checkzone -d intra.hermite2012.tk db.intra.hermite2012.tk loading "intra.hermite2012.tk" from "db.intra.hermite2012.tk" class "IN" zone intra.hermite2012.tk/in: loaded serial 2010111316 OK 23

root@srvlan:/var/cache/bind# named-checkzone -d 4.168.192.in-addr.arpa rev.intra.hermite2012.tk loading "4.168.192.in-addr.arpa" from "rev.intra.hermite2012.tk" class "IN" zone 4.168.192.in-addr.arpa/IN: loaded serial 2010111311 OK Nous allons maintenant vérifier le fichiers de log général dans une nouvelle console [Alt] [F2], root@srvlan:/var/cache/bind# tail -f /var/log/syslog à la première console [Alt] [F1] et redémarrage du service bind9 root@srvlan:/var/cache/bind#service bind9 restart Nov 25 17:21:38 srvlannamed[3196]: starting BIND 9.7.0-P1 -u bind Nov 25 17:21:38 srvlan named[3196]: built with '--prefix=/usr' '--mandir=/usr/share/man' '-- infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--withlibtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-dlzpostgres=no' '--with-dlz-mysql=no' '--with-dlz-bdb=yes' '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlzstub=yes' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' 'LDFLAGS=-Wl,- Bsymbolic-functions' 'CPPFLAGS=' Nov 25 17:21:38 srvlannamed[3196]: adjusted limit on open files from 1024 to 1048576 Nov 25 17:21:38 srvlannamed[3196]: found 1 CPU, using 1 worker thread Nov 25 17:21:38 srvlannamed[3196]: using up to 4096 sockets Nov 25 17:21:38 srvlannamed[3196]: loading configuration from '/etc/bind/named.conf' Nov 25 17:21:38 srvlannamed[3196]: reading built-in trusted keys from file '/etc/bind/bind.keys' Nov 25 17:21:38 srvlannamed[3196]: using default UDP/IPv4 port range: [1024, 65535] Nov 25 17:21:38 srvlannamed[3196]: using default UDP/IPv6 port range: [1024, 65535] Nov 25 17:21:38 srvlannamed[3196]: listening on IPv6 interfaces, port 53 Nov 25 17:21:38 srvlannamed[3196]: listening on IPv4 interface lo, 127.0.0.1#53 Nov 25 17:21:38 srvlannamed[3196]: listening on IPv4 interface eth2, 192.168.3.1#53 Nov 25 17:21:38 srvlannamed[3196]: listening on IPv4 interface eth3, 192.168.4.254#53 Nov 25 17:21:38 srvlannamed[3196]: generating session key for dynamic DNS Nov 25 17:21:38 srvlannamed[3196]: automatic empty zone: 254.169.IN-ADDR.ARPA Nov 25 17:21:38 srvlannamed[3196]: automatic empty zone: 2.0.192.IN-ADDR.ARPA Nov 25 17:21:38 srvlannamed[3196]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Nov 25 17:21:38 srvlannamed[3196]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Nov 25 17:21:38 srvlannamed[3196]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Nov 25 17:21:38 srvlannamed[3196]: automatic empty zone: D.F.IP6.ARPA Nov 25 17:21:38 srvlannamed[3196]: automatic empty zone: 8.E.F.IP6.ARPA Nov 25 17:21:38 srvlannamed[3196]: automatic empty zone: 9.E.F.IP6.ARPA Nov 25 17:21:38 srvlannamed[3196]: automatic empty zone: A.E.F.IP6.ARPA Nov 25 17:21:38 srvlannamed[3196]: automatic empty zone: B.E.F.IP6.ARPA Nov 25 17:21:38 srvlannamed[3196]: command channel listening on 127.0.0.1#953 Nov 25 17:21:38 srvlannamed[3196]: command channel listening on ::1#953 Nov 25 17:21:38 srvlannamed[3196]: zone 0.in-addr.arpa/IN: loaded serial 1 Nov 25 17:21:38 srvlannamed[3196]: zone 127.in-addr.arpa/IN: loaded serial 1 Nov 25 17:21:38 srvlannamed[3196]: zone 4.168.192.in-addr.arpa/IN: loaded serial 2010111311 Nov 25 17:21:38 srvlannamed[3196]: zone 255.in-addr.arpa/IN: loaded serial 1 Nov 25 17:21:38 srvlannamed[3196]: zone localhost/in: loaded serial 2 Nov 25 17:21:38 srvlannamed[3196]: zone intra.hermite2012.tk/in: loaded serial 2010111316 Nov 25 17:21:38 srvlannamed[3196]: running 24

autre vérification possible en utilisant l' utilitaire "dnsutils" root@srvlan:~# aptitude installdnsutils root@srvlan:~# host -v srvlan.intra.hermite2012.tk Trying "srvlan.intra.hermite2012.tk" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36780 ;; flags: qraardra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;srvlan.intra.hermite2012.tk. IN A ;; ANSWER SECTION: srvlan.intra.hermite2012.tk. 86400 IN A 192.168.4.254 ;; AUTHORITY SECTION: intra.hermite2012.tk. 86400 IN NS srvlan.intra.hermite2012.tk. Received 75 bytes from 127.0.0.1#53 in 0 ms Trying "srvlan.intra.hermite2012.tk" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10674 ;; flags: qraardra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;srvlan.intra.hermite2012.tk. IN AAAA ;; AUTHORITY SECTION: intra.hermite2012.tk. 86400 IN SOA srvlan.intra.hermite2012.tk. root.intra.hermite2012.tk. 2010111316 604800 86400 2419200 604800 Received 86 bytes from 127.0.0.1#53 in 0 ms Trying "srvlan.intra.hermite2012.tk" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31643 ;; flags: qraardra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;srvlan.intra.hermite2012.tk. IN MX ;; AUTHORITY SECTION: intra.hermite2012.tk. 86400 IN SOA srvlan.intra.hermite2012.tk. root.intra.hermite2012.tk. 2010111316 604800 86400 2419200 604800 Received 86 bytes from 127.0.0.1#53 in 0 ms 25

root@srvlan:~# dig SOA intra.hermite2012.tk ; <<>>DiG 9.7.0-P1 <<>> SOA intra.hermite2012.tk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43493 ;; flags: qraardra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;intra.hermite2012.tk. IN SOA ;; ANSWER SECTION: intra.hermite2012.tk. 86400 IN SOA srvlan.intra.hermite2012.tk. root.intra.hermite2012.tk. 2010111316 604800 86400 2419200 604800 ;; AUTHORITY SECTION: intra.hermite2012.tk. 86400 IN NS srvlan.intra.hermite2012.tk. ;; ADDITIONAL SECTION: srvlan.intra.hermite2012.tk. 86400 IN A 192.168.4.254 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Nov 26 08:36:24 2010 ;; MSG SIZE rcvd: 116 Vérification de la résolution interne root@srvlan:~# ping -c 4 srvlan PING srvlan.intra.hermite2012.tk (127.0.1.1) 56(84) bytes of data. 64 bytes from srvlan.intra.hermite2012.tk (127.0.1.1): icmp_seq=1 ttl=64 time=0.045 ms 64 bytes from srvlan.intra.hermite2012.tk (127.0.1.1): icmp_seq=2 ttl=64 time=0.047 ms 64 bytes from srvlan.intra.hermite2012.tk (127.0.1.1): icmp_seq=3 ttl=64 time=0.046 ms 64 bytes from srvlan.intra.hermite2012.tk (127.0.1.1): icmp_seq=4 ttl=64 time=0.053 ms --- srvlan.intra.hermite2012.tk ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.045/0.047/0.053/0.009 ms 26

F - Installation du DHCP et du DNS dynamique sur srvlan. DHCP constitue la suite logique de la mise en service de notre réseau local, le but étant, pour l'administrateur réseau, de pouvoir s' affranchir de toute configuration IP fixe sur les machines clientes, en leur attribuant toutes les informations nécessaires à leur connectivité au sein du réseau local. Le serveur DHCP, attribue l' IP de la machine cliente pour une durée déterminée appelée bail, il leur fournit également leurs DNS, l' adresse de la passerelle par défaut, l'adresse du serveur de temps NTP etc... L' inconvénient majeur du DHCP, est qu'il engendre un trafic de broadcast proportionnel au nombre de machines qui sont présentes sur le LAN. L'administrateur aura tout intérêt à prévoir cette charge de trafic au moment de la conception de son réseau, la charge maximale engendrée se fera surtout sentir à l' ouverturee des bureaux entre 8h et 9h au moment où les salariés allumeront leur équipement. F-1 Installation du serveur DHCP Cette installation se fera pour la carte réseau reliée à notre réseau local, (dans notre cas eth3). root@srvlan:~# aptitude install dhcp3-server sauvegarde des fichiers de configuration de base ( "ceinture et bretelle" ) root@srvlan:~#cp /etc/dhcp3/dhcpd.conf/etc/dhcp3/dhcp.conf.back Indiquer sur quelle interface doit écouter le serveur dhcp root@srvlan:~# nano /etc/default/dhcp3-server # Defaults for dhcpinitscript # sourced by /etc/init.d/dhcp # installed at /etc/default/dhcp3-server by the maintainer scripts # # This is a POSIX shell fragment # # On what interfaces should the DHCP server (dhcpd) serve DHCP requests? # Separate multiple interfaces with spaces, e.g. "eth0 eth1". INTERFACES="eth3" 27

Nous allons maintenant modifier le fichier de configuration du serveur dhcp. root@srvlan:~#nano /etc/dhcp3/dhcpd.conf # méthode dynamique pour la mise à jour ddns-update-style interim; # autorisation des mises à jour ddns-updates on; # lamise a jour est faite par le serveur dhcp ignore client-updates; # misea jour même en cas d'ip statiques update-static-leases on; # autoriser les clients dont la mac est inconnue allow-unknow-clients; # indique quelle zone DNS mettre à jour zone intra.hermite2012.tk. { primary 127.0.0.1; } zone 4.168.192.in-addr.arpa. { primary 127.0.0.1; } # option definitions common to all supported networks... option domain-name "intra.hermite2012.tk"; optiondomain-name-servers 192.168.4.254; # durée du bail par défaut sans nouvelle demande du client default-lease-time 86400; # duréemaximale du bail ( 1 week ) max-lease-time 604800; # If this DHCP server is the official DHCP server for the local # network, the authoritative directive should be uncommented. authoritative; # Use this to send dhcp log messages to a different log file (you also # have to hack syslog.conf to complete the redirection). log-facility local7; subnet 192.168.4.0 netmask 255.255.255.0 { # passerelle par défaut "srvlan" optionrouters 192.168.4.254; # masque optionsubnet-mask 255.255.255.0; # etendue range 192.168.4.30 192.168.4.99; } 28

séparation de des logs de dhcppour pouvoir suivre les évènements dhcp dans un fichier à part de l'énorme syslog, qui trace tout ce qui se passe sur votre machine. root@srvlan:~# echo "local7.* /var/log/dhcpd.log" >> "/etc/rsyslog.conf" ce qui a pour effet d'ajouter la ligne "local7.* /var/log/dhcpd.log" à la fin du fichier rsyslog.conf nous allons maintenant pouvoir suivre uniquement les logs concernant le serveur grâce au fichier "dhcpd.log". redémarrage du démon syslog root@srvlan:~# service rsyslog restart rsyslogstart/running, process 17884 nous allons ouvrir une nouvelle console [Alt] [F3] afin de pouvoir suivre les logs du serveur dhcp root@srvlan:~# tail -f /var/log/dhcpd.log Nov 22 19:27:27 srvlandhcpd: Wrote 3 leases to leases file. Nov 25 15:49:20 srvlandhcpd: Internet Systems Consortium DHCP Server V3.1.3 Nov 25 15:49:20 srvlandhcpd: Copyright 2004-2009 Internet Systems Consortium. Nov 25 15:49:20 srvlandhcpd: All rights reserved. Nov 25 15:49:20 srvlandhcpd: For info, please visit https://www.isc.org/software/dhcp/ Nov 25 15:49:20 srvlandhcpd: Internet Systems Consortium DHCP Server V3.1.3 Nov 25 15:49:20 srvlandhcpd: Copyright 2004-2009 Internet Systems Consortium. Nov 25 15:49:20 srvlandhcpd: All rights reserved. Nov 25 15:49:20 srvlandhcpd: For info, please visit https://www.isc.org/software/dhcp/ Nov 25 15:49:20 srvlandhcpd: Wrote 3 leases to leases file. F-2 vérifications Démarrage de la machine virtuelle clientxp1, de nouvelles lignes apparaissent dans notre fichier journal dhcpd.log Nov 26 10:50:11 srvlandhcpd: DHCPDISCOVER from 00:0c:29:7d:64:86 (clientxp1) vi a eth3 Nov 26 10:50:12 srvlandhcpd: DHCPOFFER on 192.168.4.30 to 00:0c:29:7d:64:86 (cl ientxp1) via eth3 Nov 26 10:50:12 srvlandhcpd: DHCPREQUEST for 192.168.4.30 (192.168.4.254) from 00:0c:29:7d:64:86 (clientxp1) via eth3 Nov 26 10:50:12 srvlandhcpd: DHCPACK on 192.168.4.30 to 00:0c:29:7d:64:86 (clie ntxp1) via eth3 29

Démarrage de la machine virtuelle clientubuntu2, de nouvelles lignes apparaissent dans notre fichier journal dhcpd.log Nov 26 10:56:42 srvlandhcpd: DHCPDISCOVER from 00:0c:29:7e:c6:5b via eth3 Nov 26 10:56:43 srvlandhcpd: DHCPOFFER on 192.168.4.31 to 00:0c:29:7e:c6:5b (clientubuntu2) via eth3 Nov 26 10:56:43 srvlandhcpd: Added new forward map from clientubuntu2.intra.hermite2012.tk to 192.168.4.31 Nov 26 10:56:43 srvlandhcpd: added reverse map from 31.4.168.192.in-addr.arpa. to clientubuntu2.intra.hermite2012.tk Nov 26 10:56:43 srvlandhcpd: DHCPREQUEST for 192.168.4.31 (192.168.4.254) from 00:0c:29:7e:c6:5b (clientubuntu2) via eth3 Nov 26 10:56:43 srvlandhcpd: DHCPACK on 192.168.4.31 to 00:0c:29:7e:c6:5b (clientubuntu2) via eth3 30

testsde résolution et de connectivité de clientxp1 à clientubuntu2 31

tests de résolution et de connectivité de clientxp1 à srvlan tests de résolution et de connectivité de clientubuntu2 à clientxp1 32

testsde résolution et de connectivité de clientubuntu2 à srvlan testsde résolution et de connectivité de srvlan à clientxp1 33

tests de résolution et de connectivité de srvlan à clientubuntu2 Comment se fait-il que clientxp1 et clientubuntu2 soient accessibles par leur nom alors que nous ne leur avons pas ajouté d' enregistrement"in A" et "PTR" dans les fichiers de configuration "db.intra.hermite2012.tk" et "rev.intra.hermite2012.tk" de bind9?? Simplement par le fait que nous ayons autorisé le serveur dhcp à mettre à jour dynamiquement les entrées dns de bind9 voyons cela de plus près... sur srvlan root@srvlan:/var/cache/bind#ls -l On peut remarquer l'apparition de deux nouveaux fichiers "*.jnl"dans le dossier contenant les configurations de zones de bind9. 34

Regardons maintenant le contenu des fichiers de zones directe et inverse. Fichier de zone directe A quoi peuvent bien servir ces enregistrements «.TXT»? Ca sert au système de mise à jour à ne pas écraser un enregistrement ajouté manuellement: Chaque fois qu'un nouvel enregistrement est ajouté dynamiquement, on positionne une zone de texte du même nom que l'enregistrement A. Quand la fois suivante, le système de mise à jour essaie de mettre à jour l'enregistrement, il trouve un enregistrement A du même nom. Si pour ce nom là il existe un enregistrement TXT, il effectue la mise à jour. Dans le cas contraire, cela veut dire que l'enregistrement a été écrit manuellement, et qu'il ne doit pas être écrasé. 35

Fichier de zone inverse On remarque l' ajout de nouveaux enregistrements de type A pour toutes les machines du réseau local qui se sont vues attribuer une adresse ip dynamiquement par le serveur dhcp. 36

G - Mise en oeuvre de DNS sur SRVDMZ, délégation de zone et accès internet pour le LAN Nous ne reviendrons pas sur l'installation de bind9, et sur les divers contrôles à effectuer pour vérifier son bon fonctionnement, nous allons uniquement présenter les fichiers de configuration de srvdmz, et les modifications à apporter sur srvlan. But de l' opération : un client du lan qui envoie une demande de résolution récursive à srvlan, vera sa requête transmise à srvdmz, qui à son tour la transmettra aux DNS du FAI. Pourquoi? Afin de ne pas surcharger le réseau par des requêtes de résolution de noms. Srvdmz, aurait très bien pu enregistrer les requêtes récursives de srvlan, et à son tour effectuer une recherche itérative afin de résoudre la requête. Pour notre cas, ce sera pas le rôle de srvdmz, Ainsi, les requêtes de résolution qui seront effectuées par les resolvers de notre réseau local seront plus rapides car s'appuyant sur les serveurs dns du FAI qui possèdent des débits de connexion bien supérieurs au notre, et qui contiendra une bonne part des informations demandées dans son cache DNS. Dans cette conception du service DNS srvlan ne s'occupera que des requêtes pour la zone intra.hermite2012.tk qui lui a été déléguée, et srvdmz des requêtes pour la zone hermite2012.tk srvfwl ns01 88.169.218.210 192.168.0.0 /24 192.168.2.0 /24.254.10.254.1.254 192.168.3.0 /24.1 srvlan.254 192.168.4.0 /24 dhcp dhcp clientxp1 clientubuntu2 sursrvdmz 37

root@srvdmz:/etc/bind# cat named.conf // This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/readme.debian.gz for information on the // structure of BIND configuration files in Debian, *BEFORE* you customize // this configuration file. // // If you are just adding zones, please do that in /etc/bind/named.conf.local include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones"; G1- nous allons cacher l'existence des serveurs racine à srvdmz root@srvdmz:/etc/bind# nano named.conf.default-zones en commentant les lignes ci dessous : // prime the server with knowledge of the root servers //zone "." { // typehint; // file "/etc/bind/db.root"; //}; G2- création des fichiers de zones sur srvdmz root@srvdmz:/etc/bind# nanonamed.conf.local // Les zones zone "hermite2012.tk" IN { type master; file "db.int.hermite2012.tk"; allow-update { none; }; }; zone "2.168.192.in-addr.arpa" IN { type master; file "rev.int.hermite2012.tk"; allow-update { none; } }; 38

G3-configuration des options générales "forward" sur srvdmz root@srvdmz:/etc/bind# nanonamed.conf.options options { // Emplacement des zones si on ne spã cifie pas le chemin absolu directory "/var/cache/bind"; forward only; forwarders { 212.27.40.240 ;DNS FAI 1 212.27.40.241 ;DNS FAI 2 }; auth-nxdomain yes; listen-on-v6 { any; }; }; par l'instruction "forwardonly", srvdmz se contente de transmettre les requêtes dns aux serveurs mentionnés par l'instruction "forwarders". G4- création du fichier de zone directe sur srvdmz dans ce fichier nous aurons l' inscription de la délégation de la zone intra.hermite2012.tk. à srvlan, et les divers enregistrements "CNAME" ( Alias ) pour les divers services proposés sur srvfwl. root@srvdmz:/var/cache/bind# nano db.int.hermite2012.tk ; Fichier pour la resolution directe $TTL 86400 @ IN SOA srvdmz.hermite2012.tk. root.hermite2012.tk. ( 2010110409 1w 1d 4w 1w ) @ IN NS srvdmz.hermite2012.tk. intra IN NS srvlan.intra.hermite2012.tk. srvlan.intra.hermite2012.tk. IN A 192.168.3.1 @ IN MX 10 srvdmz.hermite2012.tk. srvdmz IN A 192.168.2.1 ftp IN CNAME srvdmz secu IN CNAME srvdmz www IN CNAME srvdmz sup IN CNAME srvdmz smtp IN CNAME srvdmz pop IN CNAME srvdmz 39

G5- création du fichier de zone inverse sur srvdmz root@srvdmz:/var/cache/bind# nano db.ext.hermite2012.tk ; Fichier de résolution inverse $TTL 84600 @ IN SOA srvdmz.hermite2012.tk. root.hermite2012.tk. ( 2010110401 1w 1d 4w 1w ) @ IN NS srvdmz.hermite2012.tk. 1 IN PTR srvdmz.hermite2012.tk. G6-vérification des fichiers hosts et resolv.conf root@srvdmz:/var/cache/bind# nano /etc/hosts 127.0.0.1 localhost #127.0.1.1 192.168.2.1 srvdmz.hermite2012.tksrvdmz # The following lines are desirable for IPv6 capable hosts ::1localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters root@srvdmz:/var/cache/bind# nano /etc/resolv.conf domain hermite2012.tk search hermite2012.tk nameserver 127.0.0.1 G7- cacher l'existence des serveurs racines sur srvlan nous allons apporter également quelques modifications root@srvlan:/etc/bind# nano named.conf.default-zones // prime the server with knowledge of the root servers //zone "." { // typehint; // file "/etc/bind/db.root"; //}; 40

G8- configuration des options générales "forward" sur srvlan root@srvlan:/etc/bind# nanonamed.conf.options options { directory "/var/cache/bind"; forward only; forwarders { 192.168.2.1 ;@IP de srvdmz }; auth-nxdomain no; # conform to RFC1035 allow-recursion { localnets; }; listen-on-v6 { any; }; }; /!\ Ne pas oublier de redémarrer le service DNS après chaque modification et d'effectuer les vérifications vues au chapitre précédent. G9 - Vérifications Plaçons nous sur l'un des clients de notre réseau local, ce sera clientxp1. testde ping sur srvdmz, 41

Demande de résolution inverse pour srvdmz grâce à nslookup Plaçons nous sur clientubuntu2 pour vérifier la conformité de la délégation de zone Essai pour la zone "intra.hermite2012.tk.", et pour la zone "hermite2012.tk." et google.fr". Zone intra.hermite2012.tk. 42

Zone hermite2012.tk. On voit bien par là que srvdmz, qui a autorité sur la "zone hermite2012.tk.", a bien délégué l'autorité de la zone "intra.hermite2012.tk." à srvlan. nos clients doivent maintenant être en mesure de se connecter à internet zone "google.fr" 43

On voit bien que par défaut, c'est srvlan qui répond à la requête mais que sa réponse ne fait pas autorité. suite logique, on doit pouvoir effectuer une requête ping sur un site extérieur à partir d' un de nos clients. Ouvrons maintenant un explorateur web sur clientxp1 afin de s' assurer que celui est bien en mesure d' accéder à internet. 44

Test d'accès aux services " l'intranet " web, (voir les Alias dans le fichier de configuration " db.intra.hermite2012.tk sur srvlan. ) Un utilisateur local doit être en mesure d' accéder a à son répertoire "home" ( voir configuration de apache pour l' intranet.) Ici, nous avions créé un utilisateur "Max" qui doit pouvoir accéder à son répertoire perso à l'adresse http://www.intra.hermite2012.tk/~max Test d'accès aux servives web internes 45

nous devons également pouvoir accéder au site internet http://www.hermite2012.tk à partir de l'ip locale de srvdmz, car celui n'est pas encore accessible depuis l'extérieur. Tests d'accès au serveur web à partir de son ip locale 46

Ouvrons maintenant la page dans un navigateur pour voir de quoi il s'agit. merci à Julien pour ce précieux document qu'il a mis à la disposition des stagiaires tsrit2010. 47

H - OUVERTURE DES SERVICES DE L' ENTREPRISE VERS L' EXTERIEUR 48

L'accès en local aux ressources réseau est une bonne chose, mais il faut maintenant passer dans une optique d'entreprise possédant sa propre identité sur internet. Afin de proposer des services à ses clients et à ses employés, tels que site internet, ftp public, boite mail... Tout d'abord nous allons nous créer un nom de domaine, après quelques recherches sur internet on apprend que l' île de tokelau comptant 1500 habitants s'est vue attribuer un domaine de premier niveau ( TLD) en ".tk" et qu' elle propose gratuitement des noms de domaines. Il est également possible de les acquérir pour la modique somme de 10 /an Pourquoi? Afin de promouvoir cette île à travers le monde, et de contribuer aux revenus de l' île. Ces attributions de domaine couvrent 10 % des revenus de l 'île. 49

notons les nombreuses les possibilités offertes par un domaine en ".tk" - possibilité de faire une redirection de domaine : exemple si vous avez un site de la forme "http://www.monsite.free.fr", vous pouvez le transformer en "www.monsite.tk" - possibilité d' utiliser leurs propres serveurs DNS vous n' aurez alors qu' à indiquer vos enregistrements de type A, CNAME, MX...directement sur la page de configuration de votre domaine - comme indiqué sur la capture ci dessus, et c'est ce qui nous intéresse ici, utilisation de nos propres serveurs de noms. Pour la suite des évènements, nous allons, non seulement utiliser notre DNS, mais par souci de redondance, nous allons également configurer un serveur secondaire, qui répliquera la base de donnée à partir du serveur primaire, ainsi nous n'aurons qu' un seul serveur à administrer. Les administrateurs du domaine ".tk" ne vous obligent pas à avoir vos serveurs dns personnels en fonctionnement lors de leur enregistrement, nous allons donc les enregistrer tout de suite. rendez-vous sur votre espace personnel d'administration de votre domaine, - renseignez les champs @mail d'enregistrement et mot de passe - cliquez sur mes domaines - modifier un domaine - choississez le domaine à modifier. - dans le menu déroulant choisir utiliser autre service dns - indiquer la ou les IP de vos serveurs DNS personnels. 50

Par souci de conformité avec les dénominations des serveurs de noms de l' internet j'ai choisi de nommer mon serveur primaire ns01.hermite2012.tk, et mon serveur secondaire ns02.hermite2012.tk.( Ceci n'est pas une obligation ) Les @IP indiquées en vis a vis du nom du serveur correspondent aux @IP_publiquesde la pseudo entreprise "hermite2012.tk" Notons que le fournisseur d'accès internet pour les deux sites est free, nous reviendrons sur la configuration des "boxs" par la suite. 51

I - LE MECANISME DES VUES, SPLIT DNS, ET TRANSFERT DE ZONES srvfwl ns01 88.169.218.210 192.168.0.0 /24 192.168.2.0 /24 VUE EXTERNE.254.10.254.1.254 192.168.3.0 /24.1 srvlan.254 192.168.4.0 /24 dhcp dhcp clientxp1 clientubuntu2 VUE INTERNE Notre serveur DNS ne répondra pas de la même façon suivant que les requêtes proviennent de notre LAN, ou de l 'internet. - La résolution de noms sur intra.hermite2012.tk ne doit pas être disponible depuis internet. - L' adresseip d' accès à nos services doit être publique si les requêtes proviennent d'internet - L'adresse ip d'accès à nos services doit être privée si les requêtes proviennent de notre LAN, ce afin de ne pas engendrer de trafic inutile sur notre liaison internet et de permettre aux 52

clients de notre LAN, de pouvoir accéder aux informations beaucoup plus rapidement et sans être bridé par les limitations de bande passante de notre FAI. - Les serveurs de noms accepteront uniquement les requêtes récursives en provenance de notre LAN. Leur rôle n'est en aucun cas de servir de relais DNS pour quiconque se trouvant sur la toile. - les requêtes de transfert de zones ne seront admises uniquement par NS01.hermite2012.tk. que si elles proviennent de NS02.hermite2012.tk. Ceci étant posé, nous allons aborder le mécanisme du split DNS et des vues par contrôle d'accès. I1- Définition des ACL. au nombre de 2 : - nos lans 192.168.2.0/24 et 192.168.3.0/24 - l' adresseip publique de NS02 soit 78.234.33.25 root@srvdmz:/etc/bind# nano named.conf.options options { // Emplacement des zones si on ne spécifie pas le chemin absolu directory "/var/cache/bind"; forward only; forwarders { 212.27.40.240; 212.27.40.241; }; auth-nxdomain yes; listen-on-v6 { any; }; }; acl lans { 192.168.2.0; 192.168.3.0; }; acl ns02 { 78.234.33.25; }; 53

I2- Définition des vues au nombre de deux : - vue interne pour notre réseau local -vue externe pour le reste du monde I3- Modification du fichier named.conf de bind9 sur srvdmz // This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/readme.debian.gz for information on the // structure of BIND configuration files in Debian, *BEFORE* you customize // this configuration file. // // If you are just adding zones, please do that in /etc/bind/named.conf.local //include "/etc/bind/named.conf.options"; //include "/etc/bind/named.conf.local"; //include "/etc/bind/named.conf.default-zones"; //options //debut des options globales //--------------------------- include "/etc/bind/named.conf.options"; //debut des vues //vue interne view "INTERNE" { match-clients { lans; }; allow-recursion { lans; }; include "/etc/bind/named.conf.default-zones"; include "/etc/bind/named.conf.local"; }; view "EXTERNE" { match-clients { any; }; allow-query { any; }; allow-transfer { ns02; }; allow-recursion {127.0.0.1; none; }; include "/etc/bind/named.conf.external"; }; 54

I4- Création de nos fichiers de zones directe et inverse pour la vue externe root@srvdmz:/etc/bind# nanonamed.conf.external // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918"; zone "hermite2012.tk" IN { type master; file "db.ext.hermite2012.tk"; allow-update { none; }; }; zone "210.218.169.88.in-addr.arpa" IN { type master; file "rev.ext.hermite2012.tk"; allow-update { none; }; }; zone "25.33.234.78.in-addr.arpa" IN { type master; file "rev2.ext.hermite2012.tk"; allow-update { none; }; }; root@srvdmz:/var/cache/bind/# nanodb.ext.hermite2012.tk ; Fichier pour la résolution directe $TTL 86400 @ IN SOA ns01.hermite2012.tk. root.hermite2012.tk. ( 2010112222 7201 ;refreshapres 2 heures 3600 ;retry après 1 heure 604800 ;expire après 1 semaine 86400 ) ;minimum TTL 1 jour @ IN NS ns01.hermite2012.tk. @ IN NS ns02.hermite2012.tk. @ IN MX 10 srvdmz.hermite2012.tk. srvdmz IN A 88.169.218.210 ns01 IN A 88.169.218.210 ns02.hermite2012.tk. IN A 78.234.33.25 ftp IN CNAME srvdmz secu IN CNAME srvdmz www IN CNAME srvdmz sup IN CNAME srvdmz smtp IN CNAME srvdmz pop IN CNAME srvdmz miniprojet IN CNAME srvdmz 55

root@srvdmz:/var/cache/bind/# nanorev.ext.hermite2012.tk ; Fichier de résolution inverse $TTL 84600 @ IN SOA ns01.hermite2012.tk. root.hermite2012.tk. ( 2010112222 1w 1d 4w 1w ) @ IN NS ns01.hermite2012.tk. @ IN NS ns02.hermite2012.tk. 210.218.169.88.in-addr.arpa. IN PTR ns01.hermite210.tk. root@srvdmz:/var/cache/bind/# nanorev2.ext.hermite2012.tk ; Fichier de résolution inverse $TTL 84600 @ IN SOA ns01.hermite2012.tk. root.hermite2012.tk. ( 2010112222 1w 1d 4w 1w ) @ IN NS ns01.hermite2012.tk. @ IN NS ns02.hermite2012.tk. 25.33.234.78.in-addr.arpa. IN PTR ns02.hermite2012.tk. 56

I5- installation et configuration de bind9 sur ns02.hermite2012.tk. root@ns02:/etc/bind# nanonamed.conf // This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/readme.debian.gz for information on the // structure of BIND configuration files in Debian, *BEFORE* you customize // this configuration file. // // If you are just adding zones, please do that in /etc/bind/named.conf.local //include "/etc/bind/named.conf.options"; //include "/etc/bind/named.conf.local"; //include "/etc/bind/named.conf.default-zones"; include "/etc/bind/named.conf.options"; view "EXTERNAL" { allow-query { any; }; allow-transfer { 88.169.218.210; }; match-clients { any; }; zone "hermite2012.tk" { type slave; masters { 88.169.218.210; } ; file "/var/cache/bind/db.ext.hermite2012.tk"; }; zone "210.218.169.88.in-addr.arpa" { type slave; masters { 88.169.218.210; } ; file "/var/cache/bind/rev.ext.hermite2012.tk"; }; zone "25.33.234.78.in-addr.arpa" { type slave; masters { 88.169.218.210; }; file "/var/cache/bind/rev2.ext.hermite2012.tk"; }; include "/etc/bind/named.conf.default-zones"; }; 57

root@ns02:/etc/bind# nanonamed.conf.options options { directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http://www.kb.cert.org/vuls/id/800113 // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder. allow-recursion { none; }; forward only; forwarders { 212.27.40.241; 212.27.40.240; }; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; }; Nos serveurs de nom sont maintenant configurés, mais pas encore accessibles depuis internet. 58

J - CONFIGURATION DES TRANSLATIONS D' ADRESSE J1 - Définir les redirections de ports sur les boxs et sur SRVFWL Nous ferons ici la démonstration pour la box offrant l'accès internet à notre réseau virtuel. La même procédure doit être mise en oeuvre sur la box hébergeant notre serveur dns secondaire ns02.hermite2012.tk. Notre fournisseur d'accès internet ( FAI ) est free nous allons donc nous rendre sur l'interface de gestion de notre freebox. 59

60

freebox srvfwl srvdmz 88.169.218.210 192.168.0.0 /24 192.168.2.0 /24.254.10.254.1 53 61

Les services devant être visibles de l extérieur, il faut rediriger les paquets vers la machine interne fournissant le service voulu Les requête DNS externes s effectuent en UDP sur le port 53. Le client qui demande la résolution de noms pour www.hermite2012.tk le fera sur l IP publique: 88.169.218.210:53 udp Regardons la table de translation. 88.169.218.210:53 udp 192.168.0.10:53 udp Ce n est pas suffisant, ce n est pas srvfwl qui fournit le service DNS, mais srvdmz, charge à srvfwl de router les paquets sur le bon serveur. Pour cela nous allons allons utiliser des règles simples iptables. Etape 1- Tous les paquets entrant dans srvfwl par l une de ses interfaces internes et destiné à l extérieur doit en ressortir par son interface reliée au routeur freebox sur le réseau 192.168.0.0/24, le routeur freebox n a pas connaissance du sous réseau 192.168.2.0/24.Il doit donc croire que le paquet provient de srvfwl. -A POSTROUTING -o eth0 -j MASQUERADE // eth0 étant l interface 192.168.0.10 Etape 2-Tous les paquets correspondant à des requêtes DNS 53 UDP ou à des transferts de zones DNS 53 TCP doivent être redirigés vers srvdmz -A PREROUTING -i eth0 -p udp -m udp - -dport 53 -j DNAT --to-destination 192.168.2.1 -A PREROUTING -i eth0 -p tcp -m tcp -- dport 53 -j DNAT --to-destination 192.168.2.1 Ainsi srvdmz, répond de façon transparente aux clients internet, pour le client, tout se passe comme si c est 88.169.218.210 qui répond à ses requêtes. 62

J2 - Vérifications : Ping sur www.hermite2012.tk. depuis internet ou depuis la machine hôte : on voit remarque que c'est l IP publique qui est fournie par les services DNS Ping sur www.hermite2012.tk. depuis le LAN essai de ping de www.hermite2012.tk. depuis le système hôte 63

essai de ping sur www.hermite2012.tk. depuis clientubuntu2 essai de ping sur www.hermite2012.tk. depuis clientxp1 64

Essai de connexion au serveur ftp public 65