Embed Size (px)
Citation preview
AFPA DE DUNKERQUE
Le 25 novembre 2010
1
VANLERBERGHE Nicolas
-- MINIPROJET --
CONFIGURATION DE DNS POUR UN RESEAU DE PETITE ENTREPRISE
AVEC BIND9 SOUS
UBUNTU LINUX 10.04 ''Lucid Lynx"
AFPA DE DUNKERQUE
Le 25 novembre 2010
2
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
AFPA DE DUNKERQUE
Le 25 novembre 2010
3
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
AFPA DE DUNKERQUE
Le 25 novembre 2010
4
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
5
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
6
B - Le système de noms de domaines
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 sous-
domaines. Les sous domaines sont représentées comme des enfants de leur domaine parent.
Base de données du DNS
mil gov edu com
"."
AFPA DE DUNKERQUE
Le 25 novembre 2010
7
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é.
Base de données du DNS
intra
clientxp1
"."
hermite2012
tk
clientxp1.intra.hermite2012.tk.
AFPA DE DUNKERQUE
Le 25 novembre 2010
8
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
tk
hermite2012
fr
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. 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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
9
Un domaine peut contenir simultanément des hôtes, des sous domaines, des alias pointant vers
des noms canoniques.
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.
tk
hermite2012
intra
srvlan www
www
"."
clientxp1
www
AFPA DE DUNKERQUE
Le 25 novembre 2010
10
C - Principes de DNS
C - 1 Domaines
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 ".
intra
"."
tk
hermite2012
domainehermite2012.tk.
domaineintra.hermite2012.tk.
noeudintra.hermite2012.tk.
AFPA DE DUNKERQUE
Le 25 novembre 2010
11
C - 2 Délégation d'autorité et zones
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é...
"."
gov
fr tk edu
hermite2012
intra
berckeley
AFPA DE DUNKERQUE
Le 25 novembre 2010
12
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 .
AFPA DE DUNKERQUE
Le 25 novembre 2010
13
C - 4 la résolution de noms
‘’ . ‘’
tk fr be
DOT Hermite2012
ns01 www
Serveurs de noms de
‘’tk’’
Serveurs de noms de
‘’.’’
Serveurs de noms de
‘’hermite2012.tk’’
Requête www.hermite2012.tk.
Renseignements sur les Serveurs de noms de tk
Requête www.hermite2012.tk.
Renseignements sur les Serveurs de noms de Hermite2012.tk
@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 ……
Requête www.hermite2012.tk.
Réponse Adresse de
www.hermite2012.tk
RESOLVER
Processus de résolution de l'adresse www.hermite2012.tk.
AFPA DE DUNKERQUE
Le 25 novembre 2010
14
Résolution itérative manuelle de www.hermite2012.tk.
AFPA DE DUNKERQUE
Le 25 novembre 2010
15
Serveurs de noms
A D
C B
Resolver
www.hermite2012.tk ?
a.root-servers.net
root-c.taloha.tk
ns02.hermite2012.tk
1
1
2
3 4
5
6
7
www.hermite2012.tk. = 88.169.218.210
?
Processus de résolution sans cache
AFPA DE DUNKERQUE
Le 25 novembre 2010
16
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.
A D
Resolver
ftp.hermite2012.tk ?
ns01.hermite2012.tk
1
5
6
7
ftp.hermite2012.tk. = 88.169.218.210
?
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
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
17
C -6 La résolution inverse
210
218
169
88
in-address
‘’.’’
arpa
Machine : ns01.hermite2012.tk. Domaine :210.218.169.88.in-address.arpa.
Adresse IP 88.169.218.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…..)
AFPA DE DUNKERQUE
Le 25 novembre 2010
18
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).
AFPA DE DUNKERQUE
Le 25 novembre 2010
19
clientxp1 clientubuntu2
srvlan
srvfwl ns01
88.169.218.210 192.168.0.0 /24
.254
192.168.2.0 /24
.254
192.168.4.0 /24
.10 .1
192.168.3.0 /24
.254
.1
dhcp dhcp
78.234.33.25192.168.10.0
.254.10 .254
Schéma du modèle réseau
ns02
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
AFPA DE DUNKERQUE
Le 25 novembre 2010
20
Vmnet4 - 192.168.4.0 /24
Vmnet3 - 192.168.3.0 /24
Vmnet2 - 192.168.2.0 /24
Vmnet1 (Bridge)88.169.218.210
192.168.0.2192.168.0.254
192.168.0.10 192.168.2.254
192.168.2.1
srvdmz
srvfwl
srvlan
Schéma de principe VmWare
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
21
E - Configuration du DNS pour le réseau local
clientxp1 clientubuntu2
srvlan
.254
192.168.4.0 /24
192.168.3.0 /24
.1
dhcp dhcp
DNS
DHCP
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 };
AFPA DE DUNKERQUE
Le 25 novembre 2010
22
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
E-1-2 Zone inverse
root@srvlan:/var/cache/bind# nano rev.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
$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
$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.
-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
AFPA DE DUNKERQUE
Le 25 novembre 2010
23
E-1-4 vérification du fichier hosts
root@srvlan:/var/cache/bind# nano /etc/hosts
E-1-5 modification du fichier resolv.conf
root@srvlan:/var/cache/bind# nano /etc/resolv.conf
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
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
domain intra.hermite2012.tk search intra.hermite2012.tk
loading "intra.hermite2012.tk" from "db.intra.hermite2012.tk" class "IN" zone intra.hermite2012.tk/IN: loaded serial 2010111316 OK
AFPA DE DUNKERQUE
Le 25 novembre 2010
24
root@srvlan:/var/cache/bind# named-checkzone -d 4.168.192.in-addr.arpa rev.intra.hermite2012.tk
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' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-dlz-postgres=no' '--with-dlz-mysql=no' '--with-dlz-bdb=yes' '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=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
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
AFPA DE DUNKERQUE
Le 25 novembre 2010
25
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
AFPA DE DUNKERQUE
Le 25 novembre 2010
26
root@srvlan:~# dig SOA intra.hermite2012.tk
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
; <<>>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
AFPA DE DUNKERQUE
Le 25 novembre 2010
27
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"
AFPA DE DUNKERQUE
Le 25 novembre 2010
28
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; }
AFPA DE DUNKERQUE
Le 25 novembre 2010
29
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
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
F-2 vérifications
Démarrage de la machine virtuelle clientxp1, de nouvelles lignes apparaissent dans notre fichier journal dhcpd.log
rsyslogstart/running, process 17884
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.
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
AFPA DE DUNKERQUE
Le 25 novembre 2010
30
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
AFPA DE DUNKERQUE
Le 25 novembre 2010
31
testsde résolution et de connectivité de clientxp1 à clientubuntu2
AFPA DE DUNKERQUE
Le 25 novembre 2010
32
tests de résolution et de connectivité de clientxp1 à srvlan
tests de résolution et de connectivité de clientubuntu2 à clientxp1
AFPA DE DUNKERQUE
Le 25 novembre 2010
33
testsde résolution et de connectivité de clientubuntu2 à srvlan
testsde résolution et de connectivité de srvlan à clientxp1
AFPA DE DUNKERQUE
Le 25 novembre 2010
34
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
35
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é.
AFPA DE DUNKERQUE
Le 25 novembre 2010
36
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
37
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
clientxp1 clientubuntu2
srvlan
srvfwl ns01
88.169.218.210 192.168.0.0 /24
.254
192.168.2.0 /24
.254
192.168.4.0 /24
.10 .1
192.168.3.0 /24
.254
.1
dhcp dhcp
.254
sursrvdmz
AFPA DE DUNKERQUE
Le 25 novembre 2010
38
root@srvdmz:/etc/bind# cat named.conf
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 :
G2- création des fichiers de zones sur srvdmz
root@srvdmz:/etc/bind# nanonamed.conf.local
// 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";
// prime the server with knowledge of the root servers //zone "." { // typehint; // file "/etc/bind/db.root"; //};
// 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; } };
AFPA DE DUNKERQUE
Le 25 novembre 2010
39
G3-configuration des options générales "forward" sur srvdmz
root@srvdmz:/etc/bind# nanonamed.conf.options 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
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; }; };
; 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
AFPA DE DUNKERQUE
Le 25 novembre 2010
40
G5- création du fichier de zone inverse sur srvdmz
root@srvdmz:/var/cache/bind# nano db.ext.hermite2012.tk
G6-vérification des fichiers hosts et resolv.conf
root@srvdmz:/var/cache/bind# nano /etc/hosts root@srvdmz:/var/cache/bind# nano /etc/resolv.conf
G7- cacher l'existence des serveurs racines
sur srvlan nous allons apporter également quelques modifications root@srvlan:/etc/bind# nano named.conf.default-zones
; 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.
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
domain hermite2012.tk search hermite2012.tk nameserver 127.0.0.1
// prime the server with knowledge of the root servers //zone "." { // typehint; // file "/etc/bind/db.root"; //};
AFPA DE DUNKERQUE
Le 25 novembre 2010
41
G8- configuration des options générales "forward" sur srvlan
root@srvlan:/etc/bind# nanonamed.conf.options
/!\ 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,
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; }; };
AFPA DE DUNKERQUE
Le 25 novembre 2010
42
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
43
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"
AFPA DE DUNKERQUE
Le 25 novembre 2010
44
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
45
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
AFPA DE DUNKERQUE
Le 25 novembre 2010
46
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
AFPA DE DUNKERQUE
Le 25 novembre 2010
47
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
48
H - OUVERTURE DES SERVICES DE L' ENTREPRISE VERS L' EXTERIEUR
AFPA DE DUNKERQUE
Le 25 novembre 2010
49
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
50
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
51
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
52
I - LE MECANISME DES VUES, SPLIT DNS, ET TRANSFERT DE ZONES
clientxp1 clientubuntu2
srvlan
srvfwl ns01
88.169.218.210 192.168.0.0 /24
.254
192.168.2.0 /24
.254
192.168.4.0 /24
.10 .1
192.168.3.0 /24
.254
.1
dhcp dhcp
.254
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
VUE EXTERNE
VUE INTERNE
AFPA DE DUNKERQUE
Le 25 novembre 2010
53
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; };
AFPA DE DUNKERQUE
Le 25 novembre 2010
54
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"; };
AFPA DE DUNKERQUE
Le 25 novembre 2010
55
I4- Création de nos fichiers de zones directe et inverse pour la vue externe
root@srvdmz:/etc/bind# nanonamed.conf.external
root@srvdmz:/var/cache/bind/# nanodb.ext.hermite2012.tk
// // 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; }; };
; 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
AFPA DE DUNKERQUE
Le 25 novembre 2010
56
root@srvdmz:/var/cache/bind/# nanorev.ext.hermite2012.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. 210.218.169.88.in-addr.arpa. IN PTR ns01.hermite210.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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
57
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"; };
AFPA DE DUNKERQUE
Le 25 novembre 2010
58
root@ns02:/etc/bind# nanonamed.conf.options Nos serveurs de nom sont maintenant configurés, mais pas encore accessibles depuis internet.
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; }; };
AFPA DE DUNKERQUE
Le 25 novembre 2010
59
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
60
AFPA DE DUNKERQUE
Le 25 novembre 2010
61
srvfwl
88.169.218.210 192.168.0.0 /24 192.168.2.0 /24
.254.254 .10 .1
freebox srvdmz
53
AFPA DE DUNKERQUE
Le 25 novembre 2010
62
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.
AFPA DE DUNKERQUE
Le 25 novembre 2010
63
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
AFPA DE DUNKERQUE
Le 25 novembre 2010
64
essai de ping sur www.hermite2012.tk. depuis clientubuntu2
essai de ping sur www.hermite2012.tk. depuis clientxp1
AFPA DE DUNKERQUE
Le 25 novembre 2010
65
Essai de connexion au serveur ftp public
