PROJET DNS Administration Système - Ngoné DIOP Sébastien CARLES Informatique et Réseaux Première année
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Ngoné DIOP Jeudi 15 décembre 2005
Sébastien CARLES
Informatique et Réseaux
Première année
PROJET DNS
Administration Système
Professeur : Mme S. Charraire
s.charraire@voila.fr
Année : 2005/2006
Rapport
Projet DNS
SOMMAIRE
SUJET .............................................................................................................3
INTRODUCTION ...............................................................................................3
I- Préliminaire .................................................................................................4
II- Les outils / périphériques utilisé pour le serveur DNS ........................................5
1. Bind............................................................................................................5
2. Le moniteur Syslog .......................................................................................6
3. L'analyseur de réseau Ethereal .......................................................................7
4. L'utilitaire « dig »..........................................................................................8
III- Procédure d'installation des serveurs .......................................................... 10
1. Installation proprement dite ......................................................................... 10
2. Configuration de l'environnement Unix pour BIND ........................................... 10
3. Test de la configuration initiale ..................................................................... 11
IV- Un serveur primaire et un serveur secondaire qui gèrent notre domaine ........... 12
1. Configuration du serveur principal ................................................................ 12
2. Configuration du serveur secondaire.............................................................. 15
3. Test de la synchronisation............................................................................ 16
3.1 Synchronisation au démarrage.................................................................... 16
3.2 Synchronisation journalisée ........................................................................ 18
V- Sécurisation des serveurs ............................................................................ 20
1. Mise en place d'un Firewall ........................................................................... 20
2. Sauvegarde système ................................................................................... 22
3. L'utilitaire rndc ........................................................................................... 23
CONCLUSION................................................................................................. 24
SITOGRAPHIE ................................................................................................ 25
Ingénieurs 2000 2
Filière Informatique et Réseaux
Rapport
Projet DNS
SUJET
Mise en place d'une infrastructure DNS comprenant un serveur primaire, un
serveur secondaire et au moins un client. Il faut également fournir la procédure
d'intégration de nouveaux clients. Vous expliciterez les synchronisations.
INTRODUCTION
Chaque ordinateur directement connecté à Internet possède au moins une
adresse IP propre. Cependant, les utilisateurs ne veulent pas travailler avec des
adresses numériques du genre « 193.50.159.88 » mais avec des noms de machine ou
des adresses plus explicites (appelées adresses FQDN) du type « http://www.univ-
mlv.fr ». Ainsi, il est possible d'associer des noms en langage courant aux adresses
numériques grâce à un système appelé DNS (Domain Name System). On appelle
résolution de noms de domaines (ou résolution d'adresses), la corrélation entre les
adresses IP et le nom de domaine associé.
Le but de ce projet d'installer et de configurer un serveur DNS primaire ainsi
qu'un serveur secondaire afin que le dernier puisse régulièrement synchroniser avec le
premier afin de récupérer les données de celui-ci. Le DNS primaire doit par définition
s'occuper de renseigner les acteurs des réseaux (processus, machines,...) sur les
noms des machines du domaine que l'on étudiera. Le serveur secondaire en plus de
sauvegarder les données du primaire devra lui aussi être capable de renseigner les
noms.
Après avoir présenté les différents outils que l'on a utilisé pour mener à bien ce
projet, nous poursuivrons en montrant l'installation des deux serveurs. Nous
détaillerons ensuite les configurations effectuées sur ces deux serveurs pour aboutir à
la mise en place de la synchronisation entre eux. Nous finirons en évoquant les
problématiques de sécurité des serveurs DNS avant de parfaire à cette sécurisation.
Ingénieurs 2000 3
Filière Informatique et Réseaux
Rapport
Projet DNS
I- Préliminaire
Pour mettre en place nos serveurs DNS, une étape préliminaire concernant
l'installation matérielle des serveurs a été nécessaire. Ci-dessous nous avons le
schéma général de notre domaine. Il est composé de trois parties principales : la
partie des postes de travail en IP fixe, les serveurs de la zone, une DMZ et une patte
vers Internet.
On note que l’on identifie nos serveurs DNS (primaire et secondaire) par leur
nom et adresses IP.
DOMAINE projetdns.umlv
MACHINES CLIENTES AVEC IP FIXE
192.168.50.0 /24
SERVEUR DNS SECONDAIRE
capricorne
192.168.50.79
SERVEUR DNS PRIMAIRE
verseau
192.168.50.80
ROUTEUR
192.168.50.1
Internet
DMZ
SERVEURS DU DOMAINE
Fig. I.1 - Schéma du réseau
Ingénieurs 2000 4
Filière Informatique et Réseaux
Rapport
Projet DNS
II- Les outils / périphériques utilisé pour le serveur DNS
1. Bind
Issu du monde des logiciels libres, BIND est l'implémentation du protocole DNS
et le serveur de noms de domaine (BIND DNS) le plus largement utilisé sur Internet.
Ainsi, ce logiciel a pour but premier la résolution de noms de domaine en adresses
IP.
Pour cela, BIND stocke en mémoire et maintient une base de données mettant
en correspondance le domaine et l'adresse IP de l'hôte à contacter.
Le principal fichier de configuration de BIND est le fichier « named.conf ». Ce
fichier contient une suite de déclarations utilisant des options imbriquées qui sont
placées entre accolades, { }. Lorsqu'ils modifient le fichier « named.conf », les
administrateurs doivent veiller tout particulièrement à ne pas faire de fautes de
syntaxe car des erreurs mineures en apparence empêcheront le démarrage du
service « named ». A l'installation, ce fichier ne contient que les options générales du
serveur et en particulier la description des zones racines, de la boucle locale et de
diffusion.
Parmi ces déclarations, on peut citer :
• acl : La déclaration acl (de l'anglais « access control list », ou déclaration de
liste de contrôle d'accès) définit des groupes d'hôtes qui peuvent ensuite être
autorisés ou non à accéder au serveur de noms.
• include : La déclaration include permet à des fichiers d'être inclus dans un
fichier « named.conf ». Ce faisant, des données de configurations critiques
(telles que les clés, keys) peuvent être placées dans un fichier séparé doté de
permissions restrictives.
• options : La déclaration options définit les options globales de configuration
serveur et établit des valeurs par défaut pour les autres déclarations. Cette
déclaration peut être utilisée entre autres pour spécifier l'emplacement du
répertoire de travail « named » ou pour déterminer les types de requêtes
autorisés.
• zone : Une déclaration zone définit les caractéristiques d'une zone tels que
l'emplacement de ses fichiers de configuration et les options spécifiques à la
zone. Cette déclaration peut être utilisée pour remplacer les déclarations
globales d'options.
BIND permet également de gérer un serveur primaire et un ou plusieurs
serveurs secondaires. Cette fonctionnalité nous intéresse particulièrement. Ainsi
allons-nous utiliser cet outil pour mener à bien notre projet.
Ingénieurs 2000 5
Filière Informatique et Réseaux
Rapport
Projet DNS
2. Le moniteur Syslog
Le noyau UNIX, et beaucoup de programmes systèmes, produisent des
messages d'erreurs, des avertissements et d'autres messages. Souvent, il est
important de pouvoir relire ces messages plus tard, même bien plus tard. Ces
messages doivent donc être écrits dans un fichier. Le programme qui est chargé de
cette tâche s'appelle syslog. Il peut être configuré pour trier les messages dans
différents fichiers selon leur origine et leur degré de sévérité. Par exemple, les
messages du noyau sont souvent redirigés dans un fichier à part puisqu'ils sont
généralement plus importants et ont besoin d'être lus régulièrement pour identifier les
problèmes.
Nous l'utilisons pour voir en temps ce qui se passe sur notre serveur DNS. Par
exemple lors du démarrage, on peut vérifier que BIND se lance correctement. Pour le
lancer en mode temps réel, on demande à voir la fin du fichier contenant ces logs.
Avec la commande « tail -f /var/log/syslog ». Ce log va donc nous permettre de voire
nos actions sur notre serveur de noms ainsi que leurs conséquences.
Fig. II.1 – Moniteur Syslog
Ingénieurs 2000 6
Filière Informatique et Réseaux
Rapport
Projet DNS
3. L'analyseur de réseau Ethereal
Ethereal est un analyseur de protocole de réseau qui examine les données à
partir d'un réseau en direct ou à partir d'une capture de fichier sur disque. Il permet
de naviguer de façon interactive sur les données capturées, visionner le résumé et
l'information détaillée pour chaque ensemble. Ethereal possède quelques fonctions
puissantes, incluant un affichage de langage filtré et la possibilité de visionner le flux
reconstitué de la session TCP.
Cet outil nous permettra d'observer la communication entre les deux serveurs,
notamment lors des synchronisations par la capture de trames DNS.
Fig. II.2 – Logiciel Ethereal
L'affichage des résultats se décompose en trois parties :
• La liste des paquets capturés disponibles en dessous de la barre de menu
avec un affichage synthétique du contenu de chaque paquet.
• La décomposition exacte du paquet actuellement sélectionné dans la
liste. Cette décomposition permet de visualiser les champs des entêtes
des protocoles ainsi que l'imbrication des différentes couches de
protocoles connus.
• La troisième zone contient le paquet affiché en hexadécimal et en ASCII.
Ingénieurs 2000 7
Filière Informatique et Réseaux
Rapport
Projet DNS
4. L'utilitaire « dig »
L'utilitaire « dig » permet de faire des requêtes DNS évoluées et fournit un
maximum d'informations sur la requête. Il est très utile pour vérifier la bonne
configuration d'un serveur DNS. D'autres commandes (moins précis ou peu
conseillées) comme « host » et « nslookup » peuvent fournir le même genre
d'informations. La syntaxe générale est simple, il suffit de taper « dig » suivi du nom
de l'hôte qu'on veut résoudre, puis du type (par exemple dig univ-mlv.fr MX pour
demande adresses des serveurs mail du serveur de l'université ». Pour utiliser un
serveur DNS autre que celui renseigné dans le fichier « /etc/resolv.conf », il faut
ajouter une options « @ » suivi de son adresse.
Exemple d'utilisation de « dig »
Pour déterminer l'adresse du nom « www.inria.fr », il faut taper la commande
« dig www.inria.fr A ». Le serveur interrogé, à la suite d'un certain nombre de
requêtes DNS, nous répond que le nom précité a pour adresse IP « 138.96.146.2 ».
La réponse retournée par « dig » est très riche. Elle nous permet notamment de
déterminer si le serveur qui a répondu à notre demande supporte la récursion ou non.
La récursion veut dire que lorsqu'un serveur le supportant reçoit une question dont il
ne connais pas la réponse, il l'envoie directement au serveur d'autorité supérieure
c'est à dire au serveur jusqu'à ce qu'on trouve la bonne adresse. On le remarque sur
la présence du flag « rd » (récursion souhaitée), donc ce serveur supporte la
récursion. On remarque par contre que cette réponse ne fait pas autorité ; c'est-à-dire
que l'on a interrogé un serveur DNS qui avait l'information dans son cache. En effet,
le flag « aa » n'apparaît dans l'entête de la réponse. Pour avoir une réponse qui fait
autorité, on fait la requête en utilisant le serveur « dns.inria.fr » qui est le serveur qui
fait autorité dans la zone inria.
Ingénieurs 2000 8
Filière Informatique et RéseauxRapport
Projet DNS
Fig. II.3 – Dig sur le domaine www.insria.fr
Ingénieurs 2000 9
Filière Informatique et RéseauxRapport
Projet DNS
III- Procédure d'installation des serveurs
1. Installation proprement dite
Nous avons téléchargé des sources de la version 9.3 de Bind depuis le site
« www.bind9.net » que nous avons décompressé avec la commande « tar ». Nous
l'avons ensuite compilé ces sources avec « make » puis installé avec « make install ».
2. Configuration de l'environnement Unix pour BIND
• Ajout du dossier des exécutables de BIND dans la variable d'environnement
PATH pour lancer les divers programmes directement avec leur nom et nom en
tapant le chemin complet vers ceux-ci.
vi /root/.bashrc
[...]
PATH= $(PATH) : /root/named/sbin : .
[...]
• Le démon « named » qui démarrage/s'arrête au démarrage/arrêt du système :
Pour lancer un programme automatique au démarrage du système Unix et
l'arrêter correctement à l'arrêt, il faut utiliser les « runlevel ». Ce sont les
différents niveaux de démarrage/arrêt sous Unix/Linux. Il existe donc 6 runlevel
sous Debian GNU/Linux:
z Le runlevel 0 correspond à l'arrêt du système
z Le runlevel 1 correspond au démarrage single user
z Le runlevel 2 correspond mode de démarrage normal
z Les runlevels 3-5 correspondent à des modes de démarrage que l'on peut se
configurer
z Le runlevel 6 correspond au redémarrage
Les runlevel sont des niveaux constitués d'un ensemble de liens situés dans les
répertoires /etc/rcX.d/ qui, pour la plupart pointe vers les scripts situés dans
/etc/init.d/. Le X de etc/rcX.d/ représente un runlevel (0-6).
Ces liens sont de la forme Cnnprog ce qui pointe vers le programme qu'on veut
traiter.
z C= S ou K, où S passe le paramètre « start » au programme et K passe le
paramètre « stop ».
z nn= numéro correspondant à la priorité de démarrage dans le runlevel. Les
numéros les plus petits sont démarrés en premiers.
Les programmes dont le lien commence par K sont exécutés en premier, ensuite
vient les scripts dont le lien commence par S.
Comme on veut démarrer notre serveur au runlevel 2 et l'arrêter au 0 en
priorité maximale, il nous suffit de créer correctement les deux liens vers
/root/named/sbin/named avec les deux commandes suivantes :
ln -s /root/named/sbin/named K00bind
ln -s /root/named/sbin/named S00bind
Ingénieurs 2000 10
Filière Informatique et RéseauxRapport
Projet DNS
3. Test de la configuration initiale
On teste la configuration initiale de BIND ; celle qu'on a obtenue après
l'installation. Notre machine se comporte à présent comme un serveur DNS normal.
La commande « dig @localhost www.google.fr » nous permet de demander l'adresse
IP de l'hôte « www.google.fr » en utilisant le serveur qu'on vient d'installer. On
remarque que ça marche bien. On ajoute alors dans notre fichier « /etc/resolv.conf »
la ligne « nameserver localhost » pour que notre machine utilise notre serveur pour
résoudre les noms.
Fig. III.1 – Test du serveur initial
Ingénieurs 2000 11
Filière Informatique et RéseauxRapport
Projet DNS
IV- Un serveur primaire et un serveur secondaire qui gèrent notre domaine
C'est ici où on commence à avoir la notion de serveur primaire et de serveur
secondaire et la notion de zone. On va en effet considérer que l'on se trouve dans la
zone « projetdns.umlv ». Nous allons configurer un serveur de telle sorte qu'il fasse
serveur primaire de cette zone pendant que l'autre fera serveur secondaire.
1. Configuration du serveur principal
On commence par renseigner le fichier de zone que l'on stocke dans
« /root/named/etc/bind/db.projetdns.umlv ». Ce fichier sera partagé par tous les
serveurs DNS de la zone. Il sera notamment utilisé pour renseigner les demandeurs
du réseau sur le nom des machines se trouvant dans notre domaine.
Fig. IV.1 – Fichier de zone
Contenu de notre fichier de zone :
On a d'abord la définition de notre serveur en tant que serveur autoritaire de la
zone. L'adresse IP de notre serveur est le « 192.168.50.80 » et le nom associé est
« verseau ». Dans cette définition, nous avons des attributs intéressant notamment le
numéro de série (20041124 dans notre fichier de zone. Ce numéro doit être
incrémenté à chaque fois que le fichier de zone est modifié. Il va permettre au(x)
serveur(s) DNS secondaire (s) de se remettre à jour. En effet, dès qu’un serveur
secondaire détecte le changement de ce numéro, celui-ci demande un transfert de
zone.
Ingénieurs 2000 12
Filière Informatique et RéseauxRapport
Projet DNS
Pour l'instant, dans notre fichier de zone, on a résolu les noms d'un certain
nombre de serveurs de notre réseau ; notamment le serveur WEB, SMTP, POP, DHCP,
WEB... et on leur a donnée des noms explicites.
En bas, on donne des noms canoniques à certains serveurs notamment le
serveur web qui a pour nom, par convention, « www », le serveur smtp, « smtp »...
Ces noms se comporteront comme des noms de machines normaux et seront résolus
par notre serveur si on lui demandait.
Un autre fichier de zone a du être établie. Il s'agit du fichier de zone qui traite
la résolution inverse des machines de la zone. Il est similaire au fichier de zone qui
traite la résolution normale. Ce fichier est également partagé par les différents
serveurs DNS de la zone.
Fig. IV.2 – Fichier de résolution inverse de la zone
Maintenant que les fichiers de zone ont été établies, il reste à modifier le fichier
de configuration « named.conf » pour que notre serveur s'occupe de la résolution des
machines de notre zone, qu'il y soit le serveur principal, et qu'il déclare le serveur
dont l'adresse IP est « 192.168.50.79 » et dont le nom est capricorne. On ajoute
pour cela les lignes de définition de la zone qui suivent :
Ajout d'un nouveau client :
L'ajout d'un nouveau client à notre domaine est facile. Il suffit, en effet, de
renseigner les fichiers de zones (résolution normale et inverse) avec les informations
du client en question (adresse IP, nom...) comme nous l'avons fait ci-dessus avec les
serveurs.
Pour permettre à ce client d’utiliser nos serveur pour résoudre les noms, il suffit
d’ajouter les lignes « nameserver 192.168.50.80 » et « nameserver 192.168.50.79 »
dans son fichier « /etc/resolv.conf ».
Ingénieurs 2000 13
Filière Informatique et RéseauxRapport
Projet DNS
Testons notre fichier de zone avec la commande « dig » depuis un autre poste.
Le « @ » nous permet de spécifier le serveur qu’on utilise pour faire le test. On
demande l'adresse IP correspondant au nom de domaine « scorpion.projetdns.umlv »
en utilisant notre serveur DNS : « dig @192.168.50.80 scorpion.projetdns.fr ». On
aurait pu se contenter de modifier le fichier « /etc/resolv.conf ». Dans ce cas, la
commande « dig scorpion.projetdns.fr » sans l’instruction « @ » serait suffisant.
Fig. IV.3 – Test avec dig
Dig nous retourne donc l'adresse IP du nom demandé : 192.168.50.77. La
réponse nous renseigne également sur le serveur principal, notamment sur le fait qu'il
est autoritaire dans notre zone.
Un autre test en faisant un « ping » directement en utilisant le nom de la
machine. Cette étape suppose que nous avons modifié le fichier « /etc/resolv.conf »
du client en y intégrant la ligne « nameserver 192.168.50.80 ». On fait alors un ping
vers « capricorne.projetdns.umlv » et on reçoit des réponses.
Fig. IV.4 – Test avec ping
Ingénieurs 2000 14
Filière Informatique et RéseauxRapport
Projet DNS
2. Configuration du serveur secondaire
La configuration du serveur secondaire a été faite sur la deuxième machine, qui
porte le nom de capricorne. Il va donc falloir la paramétrer pour quel soit le serveur
secondaire de la zone « projetdns.umlv ».
Nous allons procéder à la configuration, en modifiant le fichier named.conf,
pour déclarer la nouvelle zone (projetdns.umlv), et indiquer que le serveur est esclave
de la machine verseau (192.168.50.80), qui est le serveur DNS primaire de la zone.
Pour cela nous rajoutons les lignes suivantes dans le fichier « named.conf » :
Fig. IV.5 – fichier named.conf du serveur secondaire :
Nous avons ainsi mise en place la résolution normale et inverse du domaine :
« projetdns.umlv », comme nous l'avions fait pour le serveur primaire. Mais comme
cette machine est un serveur DNS secondaire (« type slave »), les fichiers de zone
mentionnés dans le champs « file » (« /root/named/etc/bind/db.projetdns.umlv-sec »
et « /root/named/etc/bind/db.projetdns.umlv-sec-reverse ») ne sont pas créés a la
configuration, mais lors de la première synchronisation. Par la suite, ils seront remis à
jour lors de chaque synchronisation avec le serveur primaire. L'adresse de ce serveur
est mentionnée par le champ « masters » (192.168.50.80).
Une fois le serveur DNS secondaire installé et configuré, il faut tester la
synchronisation avec le serveur primaire du domaine afin d’observer l’échange
d’information (transfert de zone).
Ingénieurs 2000 15
Filière Informatique et RéseauxRapport
Projet DNS
3. Test de la synchronisation
3.1 Synchronisation au démarrage
Maintenant que les deux serveurs sont configurés pour s'occuper de la zone,
procédons aux tests de synchronisation. Pour cela, lançons le serveur DNS secondaire
et observons, a l'aide de l'outil syslog la synchronisation entre les deux serveurs.
Fig. IV.6 – Syslog, transfert de zone
La fenêtre ci-dessus retourne les différents logs émis par le programme du
serveur secondaire lors de son démarrage. Ces logs nous renseignent sur la
synchronisation de notre serveur secondaire sur le serveur primaire. En effet, on voit
le début du transfert de zone qui c'est effectué entre nos deux serveur (ligne 2 :
« zone projetdns.umlv/IN: Transfert started »). Le serveur DNS secondaire
(192.168.50.79) reçoit donc le fichier de zone depuis le serveur DNS primaire
(192.168.50.80).
Fig. IV.7– Fichier de zone récupéré sur le serveur DNS secondaire
Ingénieurs 2000 16
Filière Informatique et RéseauxRapport
Projet DNS
Pour tester le bon fonctionnement du serveur DNS secondaire, on tape la
commande « dig @192.168.50.79 www.projetdns.umlv » depuis un poste client.
Fig. IV.8 – Test du serveur secondaire
Ingénieurs 2000 17
Filière Informatique et RéseauxRapport
Projet DNS
3.2 Synchronisation journalisée
Pour constater la mise à jours du serveur DNS secondaire, nous avons changé
le numéro de série (20041127) et baissé le temps de rafraîchissement du cache (2).
Nous avons en plus ajouté la résolution d'autres machines dans le fichier de zone (du
serveur DNS primaire), pour bien distinguer le changement.
Fig. IV.9 – Fichier de zone après ajout des postes de travail
Après redémarrage nous avons pu observé que le serveur secondaire se
synchronise bien avec le serveur DNS principale pour récupérer le nouveau fichier de
zone (numéro de série : 20041127)
Fig. IV.10 - Transfert de zone
Ingénieurs 2000 18
Filière Informatique et RéseauxRapport
Projet DNS
On voit également la mise à travers une capture de trame avec l’outil Ethereal.
Dans la section « Answer » de la trame DNS capturée, on voit les différentes
informations du nouveau fichier dont le nouveau numéro de série (20041127)…
Fig. IV. 11 - Capture du transfert de zone
Regardons le nouveau fichier de zone : celui qui a été téléchargé lors du
transfert de zone depuis le serveur DNS principal « verseau » vers le serveur DNS
secondaire « capricorne ».
Fig. IV.12 - Nouveau Fichier de zone téléchargé
Ingénieurs 2000 19
Filière Informatique et RéseauxRapport
Projet DNS
V- Sécurisation des serveurs
1. Mise en place d'un Firewall
Description d’Iptables :
Le firewall a pour but de sécuriser au maximum le réseau local de l'entreprise,
de détecter les tentatives d'intrusion et d'y parer au mieux possible. De plus, il peut
permettre de restreindre l'accès interne vers l'extérieur. En plaçant un firewall limitant
ou interdisant l'accès à ces services, l'entreprise peut donc avoir un contrôle sur les
activités se déroulant dans son enceinte.
Le firewall propose donc un véritable contrôle sur le trafic réseau de
l'entreprise. Il permet d'analyser, de sécuriser et de gérer le trafic réseau, et ainsi
d'utiliser le réseau tel qu'il a été prévu pour et sans l'encombrer avec des activités
inutiles, et d'empêcher une personne sans autorisation d'accéder à ce réseau de
données.
Le filtrage « stateless » est la méthode de filtrage la plus simple, elle opère au
niveau de la couche réseau et transport du modèle OSI. Cela consiste à accorder ou
refuser le passage de paquet d'un réseau à un autre en se basant sur:
- l'adresse IP Source/Destination.
- le numéro de port Source/Destination.
- le protocole de niveau 3 ou 4.
La politique la plus sécuritaire au niveau des règles de filtrage est de tout
interdire sauf ce dont on a besoin et ce en quoi on a confiance. Ainsi, pas de
mauvaises surprises sur un service que l'on pensait ne pas avoir installé: tout service
autorisé est explicitement déclaré dans le firewall.
Iptables repose sur un système de tables qui correspondent aux différents
types de trafic. Ici, nous allons utiliser la table FILTER. La table FILTER va contenir
toutes les règles qui permettront de filtrer les paquets. Elle contient 3 chaînes:
- La chaîne INPUT : cette chaîne décidera du sort des paquets entrant
localement sur l’hôte.
- La chaîne OUTPUT : concerne les paquets émis par l’hôte local.
- La chaîne FORWARD : filtre les paquets qui traversent l’hôte suivant les routes
implémentées.
Le pare-feu doit être activé au démarrage de la machine. On place donc le
script dans le répertoire /etc/init.d/. On le déclare ensuite en tant que service avec la
commande chkconfig au niveau d’exécution 3, 4 et 5 et l’activation au démarrage se
fait avec l’outil ntsysv.
Script Iptables :
Le script utilisé (Fig. V.1) accepte le protocole DNS, et les connexions en SSH
(pour paramétrer le serveur à distance). Tous autres types de protocole (Web, FTP,
etc…) est automatiquement rejetés, afin de respecter l’intégrité du serveur.
Ingénieurs 2000 20
Filière Informatique et RéseauxRapport
Projet DNS
#!/bin/bash
# chkconfig: 345 60 50
# description: Pare-Feux ServeurDNS
clear()
{
# Effacer toutes les règles existantes et les chaînes utilisateur
for TABLE in filter nat mangle; do
iptables -t $TABLE -F
iptables -t $TABLE -X
done
}
stop()
{
clear
echo "Pare-Feux Desactive!"
exit 0
}
start()
{
clear
### DNS ACCEPTE
for DNS in $(grep ^nameserver /etc/resolv.conf | cut -d " " -f2); do
iptables -t filter -A INPUT -p udp -s $DNS \
--source-port domain -j ACCEPT
done
# SSH ACCEPTE POUR ADMINISTRATER NOTRE MACHINE A DISTANCE
iptables -t filter -A INPUT -p tcp --destination-port ssh -j ACCEPT
#DENY ALL : ON REFUSE TOUS LE RESTE
iptables -N logdeny
iptables -t filter -A logdeny -j LOG --log-prefix "iptables: "
iptables -t filter -A logdeny -j DROP
iptables -t filter -A INPUT -i ! lo -p all -j logdeny
echo "Pare-Feux Active!"
exit 0;
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart|reload)
stop
start
;;
status)
iptables -L
;;
*)
echo $"Usage: $0 {start|stop|restart|status}"
exit 1
esac
exit 0
Fig. V.1 – Script IPTABLES
Ingénieurs 2000 21
Filière Informatique et RéseauxRapport
Projet DNS
2. Sauvegarde système
S’agissant de serveur DNS, nos machines n’ont pas besoin d’une sauvegarde
très régulière du système. C’est pour cela que nous avons non nécessaire le fait de
faire un script de sauvegarde automatisé. Nous avons donc choisi la sauvegarde
différentielle.
Pré requis
Pour ce type de sauvegarde, il faut au préalable réserver une taille de partition
adéquate, qui doit être égale à la somme des tailles des partitions de notre système
original. Nous avons donc réservé /mnt/save_dns pour la sauvegarde. On peut en plus
mettre cette sauvegarde dans une archive (« tar ») que nous stockerons sur un autre
media, ou sur une autre machine.
Sauvegarde
Nous avons, dans un premier temps, créé un fichier d'exclusion, qui comme son
nom l'indique, contiendra la liste des fichiers ou répertoires à ne pas sauvegarder. Ce
fichier contiendra les lignes suivantes.
/proc
/tmp
/mnt
/etc/fstab
Ce fichier doit aussi contenir le répertoire où nous allons fait la copie. Une fois
ce fichier créé. Maintenant, procédons au sauvegarde de notre système avec la
commande qui suit.
rsync -ravH --exclude-from=exclud.lst / /mnt/save_dns
Restauration
Pour la restauration, il suffit de recopier les fichiers qui ont été sauvegardé
depuis notre partition vers leur emplacement d’origine.
Ingénieurs 2000 22
Filière Informatique et RéseauxRapport
Projet DNS
3. L'utilitaire rndc
Qu'est-ce que c'est ?
BIND contient un utilitaire appelé « rndc » qui permet d'utiliser des lignes de
commande pour administrer le démon « named » à partir de l'hôte local ou d'un hôte
distant. Afin d'empêcher l'accès non-autorisé au démon « named », BIND utilise
une méthode d'authentification à clé secrète partagée pour accorder des privilèges
aux hôtes. Ainsi, une clé identique doit être présente aussi bien dans
« /etc/named.conf » que dans le fichier de configuration de « rndc », à savoir
« /etc/rndc.conf ».
Mise en place
On génère une configuration sécurisée par défaut, pour cela, on lance la
commande « rndc-confgen ». On obtient un script dont une partie devra être copié
dans le fichier de configuration du server « /root/named/etc/named.conf » et l'autre
dans celui de rndc « /root/named/etc/named.conf ».
Partie copiée dans « rndc.conf » :
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "i3vA56SIOWBb7AgHNiPrlg==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
# End of rndc.conf
Partie copiée dans named.conf
# Use with the following in named.conf, adjusting the allow list as needed :
key "rndc-key" {
algorithm hmac-md5;
secret "i3vA56SIOWBb7AgHNiPrlg==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
# End of named.conf
Ingénieurs 2000 23
Filière Informatique et RéseauxRapport
Projet DNS
On a donc la même clé secrète partagée par les deux fichiers. Rechargeons à
présent la configuration que nous venons d'effectuer avec « rndc reload » après avoir
lancé « named ». La configuration est correcte, le syslog nous indique que le serveur
a été rechargé avec succès.
root@linuxportable:~/named/sbin # .named
root@linuxportable:~/named/sbin # rndc reload
server reload successful
root@linuxportable:~/named/sbin #
CONCLUSION
Dans ce projet, nous avons mis en place la gestion de la résolution des noms
d’un domaine. Nous avons supposé que ce domaine comprenait un ensemble de
serveurs qui disposent d’un nom propre. Pour ce faire, nous avons installé deux
serveurs DNS (un primaire et un secondaire) avec le logiciel BIND. Nous avons
également observé la synchronisation entre ces derniers. Nous avons finis par mettre
en place un système de sécurisation de nos serveurs ; une sécurisation à base de
firewall et de sauvegarde des différents systèmes.
Ingénieurs 2000 24
Filière Informatique et RéseauxRapport
Projet DNS
SITOGRAPHIE
www.lea-linux.org
www.linux-khops.com
Ingénieurs 2000 25
Filière Informatique et RéseauxVous pouvez aussi lire
