# R303-304 TP2: Service DNS sous linux


## Préambule
1.Vérifiez la configuration réseau de votre infrastructure. Si besoin, référez-vous au TP précédent.
L’ensemble des hôtes des sous-réseaux doivent pouvoir se joindre et doivent pouvoir sortir sur
Internet.

## 2.2.1 Généralités
Le DNS est un service permettant d’obtenir les correspondances entre les noms des hôtes (machines
clientes, serveurs, routeurs. . .) et leur adresse IP et vice-et-versa.
Le serveur DNS de l’entreprise est le serveur BINDv.9 de linux.
Par défaut, il existe sur toutes les machines linux un fichier /etc/hosts qui permet de faire la
résolution de noms.

**Pour se connecter au dns**
**ssh gtr@10.0.15.128
mdp : gtrnet**


#2.Visualisez ce fichier. Quels sont les inconvénients/contraintes de ce mécanisme ? Pourquoi préférer la mise en place d’un serveur DNS ?


2.2.2 Configuration de l’infrastructure réseau

2.2.3 Configuration du serveur principal
Le serveur DNS principal de l’entreprise est accessible à distance par ssh à partir de l’un des postes
sous Windows avec l’utilitaire Putty. L’adresse IP de votre serveur DNS est 10.0.x.128/24 où x représente votre identifiant. Le mot de passe pour l’administrateur root est gtrnet.
Le service DNS bind v.9 installé sur votre serveur se configure à partir du répertoire /etc/bind.
Le service DNS fonctionne par l’intermédiaire du démon named. Le fichier de configuration principal
est le fichier /etc/bind/named.conf qui fait appel aux fichiers suivants :
• /etc/bind/named.conf.options qui fournit des options de configuration tels que des forwarders ;
• /etc/bind/named.conf.local qui permet de déclarer les nouvelles zones qui doivent être gérées
par le serveur ;
• /etc/bind/named.conf.default-zones qui possède les indications nécessaires sur les zones dns par
défaut.
3. Connectez-vous sur le serveur DNS situé dans la DMZ.
**Pour se connecter au dns**
**ssh gtr@10.0.15.128
mdp : gtrnet**
4. Modifiez la configuration du fichier /etc/resolv.conf afin que votre hôte s’interroge pour toute requête DNS.


5.Visualisez le fichier named.conf. Que contient-il ?

6.Visualisez les fichiers named.conf.default-zones et named.conf.local. Que contiennent-ils ?

2.2.4 Déclarations des zones

Les déclarations des zones se font dans le fichier /etc/bind/named.conf.local.
Une zone directe, par exemple nom_domain.fr, est déclarée grâce aux lignes suivantes :
7.Quelle est l’utilité des champs type et file ? Que représentent-t-ils ?
8.Quel est le rôle d’une zone directe ?
9.Quel est le rôle d’une zone inverse ?
10.Dans le fichier named.conf.local, déclarez la zone directe tableX.rt correspondant à votre sous-
réseau IP DMZ. Le fichier de description de la zone directe s’appellera db.tableX.rt.

2.2.5 Définitions de la zone directe
Après avoir déclaré les zones dns, il faut maintenant décrire le contenu des zones que vous sou-
haitez administrer sur votre serveur. A titre d’exemple, pour une zone mon_domain.fr le fichier doit
ressembler à :
Les enregistrements des serveurs s’écrivent à la suite.
11.Qu’est ce qu’un SOA ? Qui est le SOA pour la zone ?
12.A quoi servent les termes situés après mon_domain.fr IN SOA ?
13.Que représente le symbole @ ?
14.Expliquez les termes NS et ORIGIN
15.Pourquoi ne met-on pas de . à la fin de la ligne @ NS server ?
Il existe plusieurs types d’enregistrement directs. Le premier est de type A, il permet de faire la
correspondance entre un nom et une adresse IP :
16.Copiez un fichier de zone directe (par exemple db.empty) sous le nom db.tableX.rt

**cp db.emty db.table15.rt**

17.Modifiez ce fichier pour qu’il corresponde à votre zone. Vous déclarerez un enregistrement de
type A pour le serveur dns de la DMZ. Il s’appelera dns.tableX.rt.

18.Un serveur apache est également installé sur la machine 10.0.x.128/24. Ce serveur web est
associé au nom www.tableX.rt. Ajoutez l’enregistrement correspondant dans le DNS. Quel
type d’enregistrement sera utilisé de préférence ?

## 2.2.6 Définitions des zones inverses
A chaque sous-réseau IP peut-être associée une zone inverse.
Un fichier de description de zone inverse associée au sous-réseau 192.168.0.0/24 ressemble à :

19.Expliquez le contenu de ce fichier

20.Copiez un fichier de zone inverse (par exemple db.127) sous le nom db.tableX.rt.rev



21.Modifiez ce fichier pour qu’il corresponde à la zone inverse associée au vlan DMZ. Vous déclarerez
un enregistrement de type PTR pour le serveur dns de la DMZ

22.Vérifiez la syntaxe de vos fichiers de configuration avec la commande



23. Configurez un redirecteur pour votre serveur DNS. Vous utiliserez celui de l’IUT 195.220.217.6.

## 2.2.7 Mise en route du service

24. Sur le serveur, tapez la commande rndc reload ou /etc/init.d/bind9 restart pour relancer
le service.

25. Vérifiez le statut du service à l’aide de la commande :
systemctl status bind9
Le serveur DNS est maintenant accessible.

## 2.2.8 Test de configuration sous linux
Pour faire la résolution de nom, les resolver ont besoin de connaître le DNS par défaut. Sous linux,
il se configure au travers du fichier /etc/resolv.conf.

26.Ouvrez ce fichier sur le serveur

#### 27. Pour définir le serveur DNS par défaut tapez la commande nameserver ip-serveur. Vous indiquerez l’adresse IP de votre serveur DNS.28.La commande nslookup permet faire une requête de résolution de nom. Tapez la commande nslookup dns.tableX.rt. Expliquez.

## 2.2.9 Test de configuration sous windows

#### 29.Configurez un poste sous windows pour que le serveur DNS par défaut soit celui de la dmz.

#### 30. Sous windows, la commande nslookup permet également de faire une requête de résolution de
nom. Faites des requêtes de résolution directes et inverses. Visualisez et expliquez les flux au
travers de wireshark.

31. Vérifiez que vous avez toujours accès à l’interne

## 2.3 Replication de zone
Afin d’assurer la disponibilité du service dns et de faire de la répartition de charge, il est fortement
conseillé de mettre en place un serveur réplicat ou esclave qui synchronisera ses informations auprès du
serveur maître. Toutes les modifications d’enregistrements (ajouts, modifications. . .) DNS ne se font
que sur le serveur maître.
Dans notre architecture, le serveur principal 10.0.x.128/24 sera le serveur maître et le serveur
secondaire 10.1.x.128 sera le réplicat.
Le serveur DNS principal est un serveur SOA et NS. Le serveur secondaire est uniquement un serveur
NS.
Nous allons mettre en place une réplication pour la zone tableX.rt et uniquement pour cette zone.
Nous appellerons le serveur réplicat dns2.tableX.rt.

## 2.3.1 Configuration du serveur réplicat
32.Connectez vous en ssh sur le serveur réplicat.
33.Modifiez le fichier /etc/resolv.conf de sorte que le serveur réplicat s’interroge lui-même pour les
requêtes DNS.
34.Les fichiers de zone esclave sont créés par le démon named lors de la réplication. Le répertoire de
stockage de ces fichiers sont définis dans /etc/bind/named.conf.options par la variable directory.
Quel est ce répertoire ?
35.Créez dans ce dernier un répertoire nommé slavezones.
36.Dans le fichier /etc/bind/named.conf.local, rajoutez les lignes suivantes en remplaçant le champ
<adresse_ip_serveur_maitre> par l’adresse IP du serveur maître afin de déclarer la zone ré-
pliquée.


37.Expliquez les différents champs : slave, file, masters et notify yes.
#### 38. Relancez le serveur et vérifiez le statut du service (systemctl status bind9)

39.Quel message d’erreur est généré ? (Visualisez le fichier /var/log/syslog).

40.Le propriétaire (user et group) du fichier slavezones doit être bind. Faites les modifications
nécessaires à l’aide de la commande chown.

41.Relancez à nouveau le serveur ; il doit être opérationnel. Vérifiez en faisant une requête DNS.

42.Tapez la commande file /var/cache/bind/slavezones/db.tableX.rt . De quel type de fichier
s’agit-il ? Est-il lisible ?

43

2.3.2 Mise à jour de la configuration du serveur maître
L’utilisation d’un serveur secondaire nécessite de faire quelques modifications sur le serveur primaire
pour un fonctionnement plus optimal.
Sur le serveur principal :
43.Dans le fichier de zone associé à tableX.rt,
— déclarez le serveur secondaire (dns2) en tant que serveur NS
— ajoutez un enregistrement de type A précisant l’adresse IP associée au serveur secondaire.

2.3 Replication de zone 19

44.Dans le fichier /etc/bind/named.conf.local, rajoutez l’instruction suivante dans la déclaration de
zone de tableX.rt. Elle indique au serveur principal d’envoyer des notifications à tous les NS.
notify yes ;
Cette instruction indique au serveur principal d’informer les serveurs secondaires des change-
ments DNS.
Par défaut, tout serveur DNS peut aller chercher des réplications de zones auprès d’un serveur
principal. Ceci peut engendrer de graves problèmes de sécurité. Il est nécessaire de préciser explicitement
quels sont les serveurs autorisés pour la réplication.
Ceci se fait au moyen de la directive allow-transfer.

45.Dans le fichier /etc/bind/named.conf.local, rajoutez l’instruction suivante dans la déclaration
de zone de tableX.rt 2 :
allow - transfer {10.1. x .128;}; // seul le serveur 10.1. x .128 peut se synchroniser

2.3.3 Modification des règles du pare-feu
Le parefeu Stormshield se base sur un moteur d’intrusion IPS. En réalité, même si votre jeu de
règles filtrage autorise tous les flux, ces flux sont vérifiés par le moteur IPS du pare-feu.
De nombreuses règles de sécurité et d’analyse sont prédéfinies dont des règles concernant le transfert
de zone DNS. Par défaut, les transferts de zone seront interdits par le moteur IPS même si vous êtes
en pass all. Ceci est illustré par les captures ci-après (figures 2.2 et 2.3) :
Nous allons donc modifier les règles de filtrages pour permettre la réplication de zone entre nos
serveurs DNS primaires et secondaires.
2.Attention, il est possible de placer cette instruction directement dans le fichier /etc/bind/named.conf.options. Dans
ce cas, toutes les zones dns pourront être répliquées

2.3.3.1 Création des objets
46.Allez dans CONFIGURATION > OBJETS > Objets réseau

47.Créez deux objets correspondant à vos serveurs dns principal et secondaire (Ajouter > Machine).
Vous pourrez les appeler _dns_principal et _dns_secondaire.
Afin de retrouver facilement vos objets dans la configuration du pare-feu, nous vous conseillons
de préfixer chaque nom par une _
2.3.3.2 Mise en place de la règle de filtrage
Allez dans CONFIGURATION > POLITIQUE DE SECURITE > Filtrage et NAT. Les règles de filtrage
sur un parefeu sont appliquées dans l’ordre chronologique.
Il faudra donc ajouter une règle en amont de la règle pass all actuelle.
48.Cliquez sur Ajouter > Règles simples. Double cliquer sur la règle afin de la paramétrer avec
les informations suivantes (voir figure 2.4) :
— Général : Etat : On
— Action : Passer ; Niveau de traces : alerte mineure
— Source : _dns_principal
— Destination : _dns_secondaire
— Port / Protocole : dns
— Inspection : Niveau d’inspection IDS

49.Appliquez le nouveau jeu de règles.
Le passage d’un mode d’inspection d’IPS à IDS pour les flux dns permet la détection des flux dns
sensibles sans les bloquer. Attention, il est important de me pas passer l’ensemble des analyses en IDS,
sous risques de perdre de nombreuses fonctionnalités du pare-feu.

2.3.4 Vérifications
50.Sur un poste client Windows, indiquez l’IP de votre serveur secondaire dans la configuration
réseau/dns.
51.Videz le cache dns à l’aide de la commande : ipconfig /flushdns

52.Tapez la commande : nslookup dns.tableX.rt. Quel serveur DNS vous répond ?
53.Lancer une nouvelle connexion ssh sur le serveur principal et tapez la commande suivante :
tshark -i nom_interface port 53

54.Relevez l’adresse IP de votre client Windows situé dans la DMZ et rajoutez l’enregistrement
DNS correspondant. Cet hôte devra apparaitre sous le nom client.tableX.rt

55.Relancez le service dns sur le serveur principal.

56.Quels sont les flux générés lors de la réplication ?
57.Sur le client windows, lancez une requête de nom pour résoudre client.tableX.rt. Si la réplication est fonctionnelle la résolution doit réussir.

2.4 Configuration de la délégation de zone
Votre DNS n’a pour le moment qu’un usage interne. Il n’est connu d’aucun DNS de niveau supé-
rieur. De ce fait, aucune résolution DNS sur votre nom de domaine depuis internet n’est possible.
Pour que votre DNS soit connu, il faut que votre registrar le déclare. En général, deux cas de figures
se présentent :
1.Le registrar gère l’ensemble de votre domaine DNS ;
2.Le registrar vous délègue cette gestion. Il ne fait que déclarer votre existence. Nous nous plaçons
dans ce cas de figure.
2.4.1 Préalable : configuration du PAT
58.Quelle est l’adresse IP “publique” de votre infrastructure ?
#### 59. Pourriez-vous faire une requête de nom à partir du serveur registar sur votre serveur DNS ?
Pourquoi ?
Afin de rendre votre serveur DNS accessible depuis internet il est nécessaire de mettre en place une
translation de port sur votre pare-feu : toute requête DNS émise à destination de votre IP publique
sera nattée sur votre serveur DNS.
60.Rendez-vous dans CONFIGURATION > POLITIQUE DE SECURITE > Filtrage et
NAT et rendez-vous dans l’onglet NAT.
61.Ajoutez une règle de NAT statique (bimap) que vous paramétrerez avec les informations suivantes (figure 2.5) :
— Machine privée : _dns_principal
— Adresse IP virtuelle (publique) : Firewall_out ; uniquement sur interface out
— uniquement pour les ports : dns
#### 62.Connectez-vous en ssh sur votre serveur registrar (192.168.155.1X)

#### 63.Testez la résolution de nom en tapant la commande suivante depuis le registrar :
nslookup dns.tableX.rt 192.168.155.X
2.4.2 Mise en place de la délégation de zone
On suppose donc ici que votre registrar vous délègue la gestion complète de votre nom de domaine
(vous gérez votre propre zone DNS). Des modifications doivent être apportées sur le DNS du registrar.
Dans ce cas, le registrar déclare l’existence de cette zone mais indique que les requêtes concernant votre
nom de domaine seront résolues par votre serveur NS.
Deux modifications doivent être faites sur le serveur du registrar (on suppose que le DNS de votre
registrar soit également géré par bind). :
— la déclaration de la zone tableX.rt
— la déclaration du serveur NS de cette zone.
A titre d’exemple, l’AFNIC qui gère le domaine fr. a délégué la gestion du domaine univ-
poitiers.fr. à l’Université de Poitiers. Le serveur DNS principal de l’Université est dns.univ-
poitiers.fr. La zone fr de l’AFNIC contient donc les lignes suivantes :

#### 64.la déclaration de la zone dans le fichier /etc/named.conf.local. La zone est alors de type forward :
Il faut ensuite déclarer dans le fichier de zone, le nom du serveur NS associée à la zone.
65.Connectez vous en ssh sur le serveur du registar et déplacez vous dans le répertoire /etc/bind
66.Quelle zone est déclarée dans le fichier named.conf.local ?
67. Editez le fichier de zone associé. Quels sont les enregistrements actuellement présents ?
68. Quelle doit être l’IP associée à votre serveur DNS dns.tableX.rt vis-à-vis de l’extérieur ?
Pourquoi ?
La déclaration de la nouvelle zone tableX.rt. est réalisée dans le fichier /etc/bind/named.conf.local.
Le registrar indique qu’il ne fait que du forwarding de zone :
69. Complétez le fichier de zone et le fichier /etc/bind/named.conf.local en rajoutant les instructions
suivantes :
Les réquêtes DNS à destination du serveur du registrar et concernant la zone tableX.rt. seront
ainsi transférées au serveur NS de la zone. Il est donc maintenant nécessaire de rajouter un
enregistrement NS dans le fichier de zone de rt.. .
70. Dans le fichier de zone de rt. rajoutez l’instruction suivante :
71. D’après-vous, devez-vous ajouter d’autres enregistrements ? Si oui, faites le nécessaire.
72. Relancez le serveur et vérifiez que vous pouvez résoudre le nom associé à votre DNS. Quel
serveur vous à répondu ?
73. Faites une résolution de nom pour dns2.tableX.rt ? Quelle est l’IP obtenue ?
74. Faites une résolution de nom pour www.tableX.rt ? Quelle est l’IP obtenue ?
75. Dans ce cas, votre serveur web est-il accessible depuis l’extérieur ? Et depuis votre réseau d’en-
treprise ?

### 2.5 Les vues (views)
Une vue est un mécanisme qui permet de fournir des réponses aux requêtes DNS en fonction de
l’adresse IP de la machine cliente.
Pour que le site web de notre réseau puisse être accessible de l’interne comme de l’externe, le
DNS doit fournir des réponses différenciées. Ainsi la réponse à une demande de résolution de nom sur
www.tableX.rt doit fournir :
— l’adresse IP publique de notre réseau, si la requête provient de l’extérieur ;
— l’adresse IP interne du serveur web, si la requête provient de l’interieur.
Un autre intérêt des vues est de ne mettre à disposition de l’extérieur que les informations DNS stric-
tement nécessaires (pas d’informations sur les hôtes ne devant pas être accessibles depuis l’extérieur ;
pas de divulgation d’information)


# Service d’annuaire LDAP

#### 1. Connectez-vous au serveur ldap situé dans le vlan ressource à l’aide de l’utilitaire putty sous Windows.

Putty 10.1.15.130

#### 2. Vérifier que le service d’annuaire est actif avec les commmandes suivantes :

# netstat -at
ou
# ss -a4n

Quels sont le protocole transport et le port d’écoute ?

#### 3. Visualisez la configuration active de l’annuaire avec la commande :

# slapcat -b cn = config

Elle est équivalente à la commande :
ldapsearch - LQY EXTERNAL -H ldapi :/// -b cn = config

5. Éditez le fichier /etc/ldap/web.ldif. Tracez le DIT correspondant à cet annuaire.

6. Créez un répertoire pour héberger les fichiers de la base de données correspondant à cette
arborescence :

# mkdir / var / lib / ldap / web
# chown -R openldap . openldap / var / lib / ldap / web

### 3.3 Gestion de l’annuaire

#### 10. L’outil graphique Studio permet de visualiser et de modifier l’annuaire à partir d’un client Windows. Configurez la connection pour accéder à l’annuaire en mode root

#### 11. A partir de la console graphique de Studio, rajoutez un utilisateur sous promo2 avec le mot de passe gtrnet.














### 3.5 Authentification sur un site Web à l’aide d’un annuaire

 nano 000-default.conf


Pour se connecter il faut utiliser le user avec mot de passe
ex
**nom utili..: user1
password: gtrnet**

# Serveurs de messagerie : cyrus-Imap et postfix