DÉPLOIEMENT DE SERVICE DNS DANS UN RÉSEAU DE FOURNISSEUR D’ACCÈS INTERNET :

(1)

RÉPUBLIQUE DU BÉNIN

UNIVERSITÉ D’ABOMEY-CALAVI (UAC)

***

ÉCOLE POLYTECHNIQUE D’ABOMEY-CALAVI (EPAC)

***

DÉPARTEMENT DE GÉNIE INFORMATIQUE ET TÉLÉCOMMUNICATIONS (GIT)

***

OPTION : RÉSEAUX INFORMATIQUES ET INTERNET (RII)

MÉMOIRE DE FIN DE FORMATION

POUR L’OBTENTION DU

DIPLÔME D’INGÉNIEUR DE CONCEPTION THÈME

DÉPLOIEMENT DE SERVICE DNS DANS UN RÉSEAU DE FOURNISSEUR D’ACCÈS INTERNET : cas de BJNet

Réalisé par :

Ulrich Nelson Abdul AZONHOU Maître de mémoire :

CNE Bidossessi ALAHASSA, I

R

Sous la supervision de : Prof. Marc kokou ASSOGBA

Année académique :2015 - 2016 8ème Promotion

(2)

SOMMAIRE

SOMMAIRE ii

DÉDICACES iv

REMERCIEMENTS v

LISTE DES SIGLES ET ABRÉVIATIONS vi

TABLE DES FIGURES ix

LISTE DES TABLEAUX xi

RÉSUMÉ xii

ABSTRACT xiii

INTRODUCTION 2

PARTIE 1 : SYNTHÈSE BIBLIOGRAPHIQUE 7

1 PRÉSENTATION DE BJNet 7

2 SYNTHÈSE BIBLIOGRAPHIQUE 10

PARTIE 2 : DÉPLOIEMENT DES SERVEURS ET SÉCURISA-

ii

(3)

TION DU SERVICE 20

3 DÉPLOIEMENT DES SERVEURS AU SEIN DU CENTRE DE DON-

NÉES 20

4 CHOIX TECHNIQUES POUR GARANTIR LA PERFORMANCE ET LA

DISPONIBILITÉ DU SERVICE 27

5 SÉCURITÉ DU SERVICE 39

PARTIE 3 : SIMULATION-TESTS-DISCUSSION 56

6 SIMULATION et TESTS 56

7 DISCUSSION 62

CONCLUSION ET PERSPECTIVES 65

RÉFÉRENCES BIBLIOGRAPHIQUES

67

RÉFÉRENCES WEBOGRPHIQUES

69

ANNEXES 71

ENGLISH VERSION 84

ENGLISH VERSION 84

TABLE DES MATIÈRES

102

iii

(4)

DÉDICACES

À :

— A mes parentsCodjo AZONHOU et feueExaucée AHOUANDJINOU.

Trouvez en ce mémoire l’expression de ma gratitude pour tous vos ef- forts effectués dans le cadre de mon éducation et de ma formation. Vous avez su placer en l’éducation de vos enfants, la plus grande priorité qui soit ! Puisse l’Eternel vous en savoir gré.

— A mes frèresTedetFériol AZONHOU.

— A mon oncleHéribert AHOUANDJINOU dont le soutien indéfectible et les conseils m’ont été d’un grand réconfort.

Ulrich N. A. AZONHOU .

iv

(5)

REMERCIEMENTS

Louanges à toi Seigneur, l’unique DIEU de l’univers, pour ta grâce et ta miséricorde le long de mes études.

Je remercie tous ceux qui de près ou de loin ont contribué à la réalisation de ce travail. Mes remerciements vont particulièrement à l’endroit de :

— Professeur Mohamed SOUMANOU, Directeur de l’Ecole Polytechnique d’Abomey-Calavi, et à son adjoint le Professeur Clément AHOUAN- NOU;

— Professeur Marc Kokou ASSOGBA, Directeur du LETIA, pour avoir accepter de superviser ce travail ;

— Dr Leopold DJOGBE, Maître-assistant du CAMES, chef du départe- ment de Génie Informatique et Télécommunications ;

— CNE Bidossessi ALAHASSA, Ir, maître de ce mémoire, qui a accepté d’encadrer mes travaux. Ses enseignements de qualité, son oreille at- tentive, sa patience, ses conseils judicieux m’ont été d’une aide pré- cieuse. Merci d’avoir cru en moi ;

— Tous les professeurs de l’EPAC, et en particulier à ceux qui ont parti- cipé à ma formation, pour la richesse de leurs enseignements ;

— A tous mes camarades du département GIT, en particulierCosta, Ga- farou, Kevin, Phinehas, Anicet, Murielle, Michael et Daniel.

v

(6)

LISTE DES SIGLES ET ABRÉVIATIONS

A

AFNIC :Association Française pour le Nommage Internet en Coopération AS :Autonomous System

ASN :Autonomous System Number B

BGP :Border Gateway Protocol C

CIPMA :Chaire Internationale Physique Mathématique et Application D

DHCP :Dynamic Host Configuration Protocol DNS :Domain Name System

DMZ :DeMilitarized Zone E

ECMP :Equal-Cost Multi-Path Routing EDNS0 :Extension Mechanisms for DNS 0

EIGRP :Enhanced Interior Gateway Routing Protocol F

FAI :Fournisseur d’Accès Internet FTP :File Transfer Protocol

vi

(7)

FQDN :Fully Qualified Domain Name G

GIT :Genie Informatique et Telecommunications I

IP :Internet Protocol

ISP :Internet Service Provider

IETF :Internet Engineering Task Force

ICANN :Internet Corporation for Assigned Names and Numbers ISC :Internet Systems Consortium

ISIS :Intermediate System to Intermediate System IGP :Interior Gateway Protocol

K

KSK :Key Signing Key O

OSPF :Open Shortest Path First R

RFC :Request For Comment

RIP :Routing Information Protocol S

SRI :Stanford Research Institute SSH :Secure Shell

T

TCP :Transmission Control Protocol TLD :Top-level Domain

TSIG :Transaction SIGnature

vii

(8)

U

UAC :Université d’Abomey-Calavi UCL :Université Catholique de Louvain

UNIX :Uniplexed Information and Computer Service Z

ZSK :Zone Signing Key

viii

(9)

Table des figures

1.1 Topologie physique du centre de données de BJNet [1] . . . . 9

2.1 Structure de l’espace de noms DNS [2] . . . 12

2.2 Domaines, zones et délégations [3] . . . 14

2.3 Diagramme du processus de résolution de nom . . . 18

3.1 Topologie des serveurs de noms du centre de données . . . . 23

3.2 Comparaison de performances de BIND, PowerDNS, Knot DNS et NSD [15] . . . 24

4.1 Temps du processus de résolution . . . 28

4.2 Unicast[4] . . . 30

4.3 Broadcast[4] . . . 30

4.4 Multicast[4] . . . 30

4.5 Anycast[4] . . . 30

4.6 Utilisation d’anycast pour faire de la répartition de charge [5] 31 4.7 Utilisation d’anycast à l’échelle d’un AS (Autonomous Sys- tem) [5] . . . 32

4.8 Utilisation d’anycast à l’échelle d’internet [5] . . . 32

4.9 Anycast avec des serveurs DNS récursifs [5] . . . 33

4.10 Anycast avec des serveurs DNS autoritaires [5] . . . 33

4.11 Architecture de BJNet . . . 35

4.12 Anycast au sein de BJNet . . . 38

5.1 Structure d’un enregistrement DNSKEY [6] . . . 46

5.2 Structure d’un enregistrement RRSIG [6] . . . 46

5.3 Structure d’un enregistrement NSEC [6] . . . 47

5.4 Exemple de chaînage NSEC [6] . . . 48 ix

(10)

5.5 Structure d’un enregistrement NSEC3PARAM [6] . . . 50

5.6 Structure d’un enregistrement NSEC3 [6] . . . 50

5.7 Exemple de chaînage NSEC3 [6] . . . 51

5.8 Structure d’un enregistrement DS [6] . . . 52

6.1 Topologie de l’environnement de simulation . . . 57

6.2 Test du fonctionnement de la résolution de noms . . . 59

6.3 Test de l’identité du routeur qui répond au client deb2 . . . . 60

6.4 Test de redondance du service . . . 61

C1 Aperçu du fichier /etc/softhsm/softhsm.conf . . . 76

C2 Aperçu du fichier /etc/opendnssec/zonelist.xml . . . 82

8.4.1 Physical architecture of the BJNet data center [1] . . . 87

8.5.1 DNS namespace structure [2] . . . 89

8.5.2 Domain, zone and delegations [14] . . . 90

8.7.1 Name Server Architecture . . . 93

8.8.1 Anycast within BJNet . . . 94

8.8.2 Topology of the simulation environment . . . 95

x

(11)

Liste des tableaux

3.1 Récapitulatif des choix de logiciels pour les serveurs . . . 26 6.1 Caractéristiques matérielles des machines virtuelles pour la

simulation . . . 58 B1 Dimensionnement des serveurs récursifs . . . 74

xi

(12)

RÉSUMÉ

BJNet est un réseau d’envergure nationale visant l’interconnexion de toutes les structures de l’administration publique. Il a pour objectif principal de fournir un accès à internet à toute organisation exploitant ces infrastructures. Cela passe par le déploiement du service DNS. Ainsi, notre étude a porté sur la mise en place du service DNS dans le réseau BJNet.

Pour ce faire, une topologie des serveurs DNS au sein du centre de données du réseau a été pensée et proposée. Nous nous sommes ensuite penchés sur la façon d’améliorer l’expérience utilisateur. Pour cela, nous avons mis en place un dispositif en vue d’augmenter la rapidité et la fiabilité du service. Ensuite, nous nous sommes intéressés à la sécurité du service. Enfin, pour prouver la viabilité des solutions proposées, des tests ont été menés et ont montré que nos solutions sont adéquates.

Mots-clés :DNS, BJNet, serveur primaire, serveur secondaire, serveur cache, DNSSEC, Anycasting.

xii

(13)

ABSTRACT

BJNet is a national network aiming at the interconnection of all the structures of the public administration. Its main objective is to provide In- ternet access to any organization operating its infrastructure. This involves deploying the DNS service. Thus, our study will focus on the implementa- tion of the DNS service in the BJNet network. To do this, a topology of the DNS servers within the data center of the network has been conceived and proposed. We then looked at how to improve the user experience. To this end, we have put in place a system to increase the speed and reliability of the service. Then we looked at the security of the service. Finally, to prove the viability of the proposed solutions, tests were carried out and showed that our solutions were functional.

Keywords : DNS, BJNet, Primary server, Secondary server, Cache server, DNSSEC, Anycasting.

xiii

(14)

xiv

(15)

INTRODUCTION GÉNÉRALE

1

(16)

INTRODUCTION

Le protocole DNS a été conçu pour répondre au besoin d’association de noms symboliques, facilement mémorisables par l’homme avec les adresses IP. Au fur et à mesure de l’expansion de l’internet, le DNS s’est révélé en être un élément de base et incontournable pour sa bonne marche. En effet, la quasi-totalité des services de réseau de l’Internet utilisent le DNS.

cela inclut le Web, le courrier électronique, l’accès terminal distant, et le transfert de fichiers [2]. Si l’on en croit une étude réalisée par l’AFNIC, une association française qui gère les domaines internet nationaux de premier niveau de France (.fr), la Réunion (.re), Mayotte (.yt), Terres australes et antarctiques françaises (.tf ), Saint-Pierre-et-Miquelon (.pm) et Wallis-et- Futuna (.wf ) et qui fournit aussi des solutions techniques et de registre, les 8 instances du serveur d.nic.fr faisant autorité pour la zone .fr reçoivent en moyenne 4000 requêtes/s [7]. En 2012, Google avait déclaré par le biais d’un communiqué publié sur son blog que : les serveurs de son service Google Public DNS seraient désormais les serveurs DNS publics les plus sollicités au monde en revendiquant notamment 70 milliards de requêtes par jour [16].

Ce rôle prépondérant du DNS dans les communications sur internet en fait une cible de choix pour les attaques orchestrées par les pirates informatiques. Les gouvernements et les entreprises s’en servent également comme outil de censure ou de restriction du web [8]. D’après l’entreprise Yankee Group, Le 17 décembre 2009, de 9h45 à 11h, 80 pour cent du trafic Twitter a été redirigé via une parodie de DNS à une page montrant une image d’un drapeau vert suivi par les mots : "Ce site a été piraté par l’Ira- nian Cyber Army". Twitter est le plus grand site de profil à avoir souffert d’une attaque DNS, mais on estime que 06 à 10 autres sites ont également été touchés [8]. Le 24 Mars 2010, la Chine a étendu sa censure de réseau à l’étranger quand au moins un fournisseur de services Internet a com- mencé à retourner des réponses à des requêtes de premier niveau défec- tueuses, à partir d’un serveur DNS racine de Pékin exploité par l’opéra- teur suédois d’échange Internet Netnod. L’information que le serveur ren- voyait était destinée aux utilisateurs chinois, pour bloquer l’accès à des

Réalisé par Ulrich N. A. AZONHOU 2

(17)

sites tels que Facebook, Twitter et YouTube et rediriger les utilisateurs vers de fausses adresses. Netnod a clamé que son serveur n’avait pas publié les données défectueuses qui ont redirigées les requêtes. Les experts en sécu- rité ont avancés qu’elles avaient été modifiées par le gouvernement chinois [8]. En Février 2008, la société de télécommunications appartenant à l’Etat du Pakistan a réussi à rendre YouTube inaccessible pendant plus d’une heure après avoir reçu des ordres du gouvernement pakistanais pour bloquer l’accès au site. Dans ce qui était essentiellement une attaque d’in- toxication de cache, le telco a diffusé la fausse information selon laquelle il faisait autorité sur 256 adresses dans le domaine de YouTube. Malheureu- sement, cette redirection n’a pas affecté que le trafic YouTube du Pakistan.

Il a envoyé tout le trafic à destination du domaine au nouvel ensemble de fausses adresses IP [8].

Le DNS étant un élément critique d’internet, il constitue un enjeu capi- tal pour tout fournisseur d’accès internet. En effet, pour satisfaire les utilisateurs et en attirer d’autres il convient de mettre en place un service DNS de qualité, disponible et qui puisse garantir la protection de leurs données.

Contexte, justification et problématique

BJNet est un réseau permettant l’inter-connexion de toutes les structures de l’administration publique, notamment les ministères, les univer- sités, etc... Ses infrastructures sont présentes dans tous les départements du Bénin. C’est un fournisseur d’accès internet FAI donc il veut fournir un accès à Internet à toute structure exploitant ses infrastructures.

Cet accès à internet ne saurait se faire sans le déploiement du service DNS. De plus il est primordial que le service DNS proposé soit performant, toujours disponible et sécurisé. En effet, une lenteur au niveau de la réso- lution des requêtes DNS est perçue comme une connexion internet lente au niveau des utilisateurs alors que nous sommes à une ère où la préoccu- pation majeure des clients et donc des FAI qui les desservent est d’avoir la connexion internet la plus rapide possible. Des interruptions du service DNS se traduisent en moments d’inaccessibilité au réseau internet.

(18)

Quand on sait l’importance des structures qui devront profiter des services de BJNet, notamment les ministères, il apparaît clairement que ces pannes peuvent causer des dommages non négligeables. Aussi, un service DNS non sécurisé exposerait ces institutions à des attaques comme l’ha- meçonnage pouvant aboutir à la récupération de données confidentielles, le ralentissement du service ou son arrêt.

En vue d’assurer les services que désire fournir BJNet, outre l’inter-connexion à internet (notamment l’hébergement web, le mail etc. . . ), il a été mis en place un centre de données (au sein duquel seront déployés les différents serveurs, dont les serveurs DNS), sur deux sites, notamment l’UAC et le camp GHEZO, où, les services déployés sur l’un sont répliqués à l’identique sur l’autre.

Le réseau étant d’envergure nationale, ses utilisateurs sont censés se trou- ver n’importe où sur le territoire national. Il apparaît donc que les requêtes des utilisateurs éloignés, seront contraintes de faire l’aller-retour vers l’un des deux sites qui sont situés dans le sud ce qui amplifiera les temps de réponses. De plus, l’ensemble des requêtes DNS des utilisateurs du réseau sera pris en charge par les serveurs du centre de données. La conséquence est que la charge résultante du fonctionnement du service est concentrée sur le dit centre et donc qu’une attaque DoS ou DDoS pourrait paralyser le service et donc l’accès au réseau internet. Le présent travail de fin d’études a donc pour but, la mise en place d’un service DNS au sein de BJNet qui soit fiable, sécurisé et de qualité.

Objectifs

Le principal objectif de cette étude est de proposer une topologie de déploiement de serveurs en garantissant aux utilisateurs, sécurité, performance et disponibilité. Plus spécifiquement, il s’agira de :

— Proposer une répartition des serveurs de noms pour garantir performance et disponibilité ;

(19)

— Proposer une technique de renforcement de la sécurité du service DNS.

(20)

PARTIE 1 : SYNTHÈSE

BIBLIOGRAPHIQUE

6

(21)

Chapitre 1

PRÉSENTATION DE BJNet

1.1 Le projet BJNet

BJNet est un projet initié, dans le cadre de la coopération entre l’Univer- sité Catholique de Louvain (UCL) et l’Université d’Abomey-Calavi (UAC), par deux professeurs. D’une part, le Professeur Marc LOBELLE, Colonel de Réserve de l’Arme des Transmissions dans l’Armée Belge et Professeur à l’Université Catholique de Louvain ; et d’autre part, le Professeur Norbert HOUNKONNOU, Président de la Chaire Internationale Physique Mathé- matique et Application (CIPMA) et coordonnateur du projet au Bénin.

Ce projet vise la modernisation de l’Administration publique par la mise en place d’un réseau pour l’interconnexion entre ses principales structures. Cette interconnexion se fait avec de la fibre optique et des faisceaux hertziens. Dans son modèle de déploiement, BJNet base le cœur du ré- seau sur les tronçons de fibre optique de Bénin Télécoms S.A. qui, met à la disposition de BJNet, une paire de fibre noire que BJNet se charge d’alimenter avec ses propres équipements. Au regard du budget et tenant compte de la faisabilité dans les délais impartis, BJNet interconnecte certaines structures avec des fibres acquises sur fonds propre. Ainsi, la Fa- culté des Sciences de la Santé, le campus d’Abomey-Calavi, le Ministère de la Défense Nationale et le camp Guézo sont entièrement interconnec- tés en fibre optique. Les autres entités sont interconnectées en faisceaux hertziens.

Le réseau de BJNet a également l’ambition d’être un FAI donc il veut 7

(22)

Chapitre 1. PRÉSENTATION DE BJNet

fournir un accès à Internet ainsi que certains services additionnels comme l’hébergement de sites web, le mail, etc. . . à toutes structures exploitant ses infrastructures.

1.2 Topologie physique de déploiement des ser- vices du centre de données

La fourniture des services DNS, de mail et d’hébergement web par BJ- Net ne consistera pas seulement à mettre en place les serveurs remplis- sant ces fonctions. En effet, outre les services à offrir, le réseau est tenu de garantir une certaine sécurité à ses clients. Cela passe donc par la mise en place de solutions de sécurité, en l’occurrence des pare-feu ; mais cela passe aussi par la mise en place de DMZ (DeMilitarized Zone) qui ser- vira d’interface entre les serveurs proprement dits et les utilisateurs. Les concepteurs de l’architecture physique du centre de données ont, pour ac- croître la sécurité, choisi de mettre en place deux DMZ : une pour les utilisateurs accédant au centre de données depuis le réseau BJNet et une pour ceux y accédant depuis d’autres réseaux, en l’occurrence Internet. Aussi, afin de mieux administrer les divers serveurs à mettre en place, le centre de données sera équipé d’outils d’administration et de surveillance réseau et système (Dude, Nagios et OpenVAS). Ces outils permettent de faire des mises à jour groupées et automatiques, d’établir une cartographie du ré- seau, générer des alertes en cas de dysfonctionnement, configurer à distance les équipements, faire des scans de vulnérabilités, générer des rap- ports de fonctionnement, etc. Ces outils seront regroupés au sein d’un ré- seau : le centre d’administration réseau. Enfin, pour garantir une certaine disponibilité de ses services, le centre de données de BJNet sera réparti sur deux sites disposant chacun d’un serveur physique. Le cluster ainsi mis en place permet de mettre en œuvre deux fonctionnalités :

— augmentation de la puissance de traitement : les requêtes des clients ne seront pas toutes traitées par la même machine ;

— augmentation de la disponibilité : les inconvénients liés aux pannes seront minimisés par la redondance des machines entre elles.

(23)

1.2 Topologie physique de déploiement des services du centre de données

Les services seront donc déployés à l’identique sur les deux sites, et fonctionneront en primaire sur l’un et en secondaire sur l’autre. Nous avons donc pris pour principal cas d’étude, le serveur de l’un des sites, étant en- tendu que tout ce qui se fera sur ledit serveur sera répliqué sur le serveur de l’autre site. Pour récapituler, on note que pour atteindre les objectifs de sécurité et de disponibilité, les serveurs, pare-feu et outils de monitoring sont répartis sur quatre réseaux distincts : celui du centre d’administration réseau, celui de la DMZ publique, celui de la DMZ privée et celui du réseau de données critiques qui regroupe les serveurs de mails, web et de bases de données[1]. Tout cela est présenté à la figure 1.1 .

Figure 1.1 – Topologie physique du centre de données de BJNet [1]

(24)

Chapitre 2

SYNTHÈSE

BIBLIOGRAPHIQUE

2.1 Concept du DNS

Internet est le plus grand réseau informatique du monde, avec plus de 3,186 milliards d’utilisateurs fin 2015 [17]. Du point de vue d’un utilisateur, chaque nœud ou ressource sur ce réseau est identifié par un nom unique : le nom de domaine.

Du point de vue des équipements réseau (par exemple, les routeurs) qui acheminent les paquets à travers Internet, l’identifiant unique d’une ressource est l’Internet protocole (IP). Pour accéder aux ressources d’internet par des noms de domaine plus conviviaux plutôt que ces adresses IP, les utilisateurs ont besoin d’un système qui traduit ces noms de domaine en adresses IP et l’inverse. Quelques exemples de ressources Internet sont les suivants :

— Des serveurs Web : pour l’accès aux pages web ;

— Des serveurs Mail : pour la transmission des mails ;

— Les serveurs d’application : pour accéder à des systèmes logiciels et des bases de données à distance.

Cette traduction est la tâche principale assignée au DNS. Les utilisateurs accèdent à une ressource Internet (par exemple, un serveur Web) à travers le programme client ou utilisateur correspondant (par exemple, un

10

(25)

2.2 L’infrastructure DNS

navigateur Web) en y tapant le nom de domaine. Pour contacter le serveur Web et récupérer la page Web appropriée, le navigateur a besoin de l’adresse IP correspondante. Il appelle le DNS pour lui fournir cette information. Cette fonction d’association entre noms de domaine et adresses IP est appelée résolution de nom. Le protocole que le DNS utilise pour remplir cette fonction de résolution de nom est appelé le protocole DNS.

La fonction DNS décrite ci-dessus comprend les éléments constitutifs suivants : Tout d’abord, le DNS doit disposer d’une base de données pour stocker les noms de domaine et leurs adresses IP associées. Parce que le nombre de noms de domaine est très grand, les exigences d’évolutivité et de performance demandent à ce qu’il soit distribué. Les noms de domaine peuvent même avoir besoin d’être répliqué pour fournir la tolérance aux pannes. Deuxièmement, il devrait y avoir un logiciel qui gère cette base de données et assure la fonction de résolution de nom. Ces deux fonctions (gestion de la base de données des noms de domaine et l’accomplissement de la tache de résolution de noms) sont fournies par le composant primaire du DNS, le serveur de noms. Il existe plusieurs catégories de serveurs de noms, se distinguant par le type de données desservies et les fonctions exercées. Pour accéder aux services fournis par un serveur de noms DNS pour le compte des programmes de l’utilisateur, il existe une autre compo- sante DNS appelée le résolveur. Le protocole de communication ; les divers composants DNS ; les politiques qui régissent la configuration de ces composants ; et les procédures pour la création, le stockage et l’utilisation des noms de domaine constituent l’infrastructure DNS [9].

2.2 L’infrastructure DNS

2.2.1 L’espace de noms de domaine

L’espace de noms de domaine (l’univers de tous les noms de domaine) est organisé en une structure arborescente des noms de domaine, avec un domaine racine au sommet représenté par un point (‘.’). Immédiatement en-dessous du domaine racine se retrouvent les principaux domaines tels que .com, .net et .org, appelés TLD. A partir de ces domaines, l’espace de

(26)

Chapitre 2. SYNTHÈSE BIBLIOGRAPHIQUE

nom peut se ramifier en plusieurs chemins. Chaque point d’intersection est appelé un nœud et marqué avec un nom simple qui peut compter jusqu’à soixante-trois (63) caractères. Une étiquette nulle (longueur nulle) est réservée à la racine.

Figure 2.1 – Structure de l’espace de noms DNS [2]

Le nom de domaine complet d’un nœud dans l’arborescence est la sé- quence d’étiquettes rencontrée sur le chemin, partant de ce nœud jusqu’à la racine, séparées par des points. Les noms de domaine sont toujours lus à partir du nœud vers la racine.

Lorsque l’on veut faire apparaitre l’étiquette du nœud racine, on le ma- térialise par un point, ".", Par convention, comme dans "www.oreilly.com."

(Il se termine effectivement avec un point séparant le reste du nom de l’éti- quette nulle de la racine). Par conséquent, certains logiciels interprètent un point mis à la fin dans un nom de domaine pour indiquer que le nom de domaine est absolu. Un nom de domaine absolu est écrit relativement à la racine et spécifie l’emplacement d’un nœud dans la hiérarchie sans ambiguïté. Un nom de domaine absolu est également considéré comme un nom de domaine pleinement qualifié, souvent abrégé FQDN. Les noms

(27)

sans point à la fin sont parfois interprétés comme relatifs à un nom de domaine autre que la racine, tout comme les noms de répertoire sans slash au début sont souvent interprétés comme relatif au répertoire courant dans les systèmes Linux. Le DNS exige que les nœuds qui sont du même parent aient des étiquettes différentes. Cette restriction garantit qu’un nom de domaine unique puisse identifier de manière unique un nœud dans l’arbre.

La restriction n’est vraiment pas une limitation parce que les étiquettes doivent être uniques seulement parmi les enfants, et non pas entre tous les nœuds de l’arbre.

Un domaine est tout simplement une sous-arborescence de l’espace de noms de domaine. Le nom de domaine d’un domaine est le même que le nom de domaine du nœud tout en haut du domaine [2].

2.2.2 Délégation et zone

L’un des objectifs principaux de la conception du DNS était de décen- traliser l’administration. Ce résultat est obtenu grâce à la délégation. Dé- léguer des domaines fonctionne un peu comme la délégation des tâches au travail. Un administrateur peut subdiviser un grand projet en petites tâches et déléguer la responsabilité de chacune de ces tâches à des em- ployés différents. De même, un organisme qui administre un domaine peut le diviser en sous-domaines. Chaque sous-domaine peut être délégué à d’autres organisations, ce qui signifie que chacune des organisations bé- néficiaires deviennent responsables du maintien de toutes les données du sous-domaine dont elle a héritée. Chacune d’elle peut librement modi- fier les données et même diviser son sous-domaine en plusieurs autres sous-domaines et les déléguer. Le domaine parent ne conserve que des pointeurs vers les sources de données de ses sous-domaines, de sorte qu’il puisse y référer ses requêtes. Chaque fois que l’on fait une délégation d’un sous-domaine, on crée une zone. La différence entre un domaine et une zone est importante mais subtile. Le terme zone est utilisé pour se référer à un domaine qui est gérée comme une entité administrative autonome.

Une zone est gérée par un ou plusieurs serveurs qui disposent de toutes les informations de cette zone. Les administrateurs de ces serveurs sont

(28)

responsables des informations de zone, de leur mise à jour et de leur dis- ponibilité [2].

Figure 2.2 – Domaines, zones et délégations [3]

2.2.3 Le fichier de zone

Un fichier de zone contient des informations relatives à diverses ressources dans cette zone. Les informations sur chaque ressource sont repré- sentées dans un registre appelé resource record (RR). Parce qu’une zone peut contenir plusieurs domaines et plusieurs types de ressources au sein de chaque domaine, le format de chaque RR contient des champs pour faire cette identification. Plus précisément, le RR comprend les champs principaux suivants :

— Owner name :Le nom du domaine ou de la ressource ;

— TTL : Temps de validité ou de vie en secondes ;

— Class : A l’heure actuelle, la classe omniprésente et pratiquement la seule utilisée est IN (désignant Internet) ;

— RRType :Le type de la ressource ;

— RData :Information sur la ressource (dépend du RRType).

(29)

Certains des RRType courants sont :

— A :Adresse RRType. Un RR de ce type fournit l’adresse IP pour un nom d’hôte (identifié en utilisant un nom de domaine complet) ;

— MX : Mail Exchanger RRType. Un RR de ce type fournit le nom d’hôte du serveur de courrier pour un domaine ;

— NS :Name Server RRType. Un RR de ce type fournit le nom d’hôte du serveur de nom pour un domaine [9].

2.2.4 Serveurs de nom

Les principales fonctions des serveurs de nom sont d’héberger une base de données (le fichier de zone) et de fournir des réponses aux requêtes de résolution de noms. Il existe deux principaux types de serveurs de noms : Les serveurs de noms autoritaires primaires et secondaires. Le terme autoritaire est en rapport à une zone. Si un serveur de noms est une source faisant autorité sur un RR pour une zone particulière (ou pour plusieurs), il est appelé un serveur de noms faisant autorité pour cette zone (ou pour ces zones). Un serveur de noms faisant autorité pour une zone fournit des réponses aux requêtes de résolution de noms des ressources de cette zone, en utilisant les RR présents dans son propre fichier de zone. Il existe toutefois une troisième catégorie de serveurs de noms. Il s’agit du serveur ré- cursif.

2.2.4.1 Serveur de noms autoritaire primaire

Ils contiennent les fichiers de zone qui sont créés et édités manuelle- ment par l’administrateur de la zone. Toutefois, un serveur de noms primaire peut permettre la mise à jour dynamique du fichier de zone par des clients DNS autorisés.

2.2.4.2 Serveur de noms autoritaire secondaire

Ils contiennent également des informations faisant autorité pour une zone. Mais leurs fichiers de zone sont des répliques de ceux du serveur

(30)

de noms primaire associé. La réplication est activée par une transaction appelée ZONE TRANSFERT qui transfère tous les RR à partir du fichier de zone d’un serveur de noms maître¹ vers le serveur de noms esclave² Chaque fois que le contenu d’un fichier de zone est modifié dans les serveurs de noms de maître, les serveurs de noms esclaves sont informés de ce changement par le biais d’une transaction appelée DNS NOTIFY. Quand un serveur de noms esclave reçoit cette demande, il initie une demande de transfert de zone vers le serveur de nom maître [9].

2.2.4.3 Serveur cache ou récursif

Les serveurs caches ne font autorité sur aucune zone, ils ne possèdent pas de fichier de zone. Un serveur cache est généralement placé sur un ré- seau afin de recevoir les requêtes des résolveurs locaux. Le serveur cache a pour rôle de répondre à ces requêtes en utilisant les informations pré- cédemment reçues qu’il conserve en mémoire durant un certain temps.

S’il ne possède pas la réponse, le serveur cache fait suivre ces requêtes au serveur autoritaire qu’il pense le plus à même de posséder la réponse, met en cache la réponse reçue et la fait suivre au résolveur. L’utilisation de serveurs caches permet de diminuer la charge sur les serveurs autoritaires en mutualisant les informations[2].

2.2.5 Le résolveur

Le résolveur est l’entité cliente. C’est lui qui reçoit les demandes en provenance d’une application et envoie les requêtes DNS appropriées, gé- néralement à un serveur cache récursif. Les résolveurs sont généralement configurés avec une liste de deux ou plusieurs serveurs de noms caches ou récursifs histoire de fournir une certaine tolérance de panne pour leur fonctionnement. Lorsque le résolveur reçoit la réponse à sa requête, il trans- met l’information à l’application [2].

1. Le serveur maitre désigne le serveur primaire mais peut aussi désigner un serveur secondaire.

2. Le serveur esclave représente le serveur secondaire.

(31)

2.3 La résolution de noms

Lorsqu’un utilisateur tape par exemple l’URL fr.wikipedia.org dans un navigateur Web, le programme du navigateur contacte un résolveur qui contacte ensuite un serveur de noms cache ou récursif. Le serveur de noms récursif vérifie son cache afin de déterminer s’il a des informations valides pour fournir l’adresse IP de la ressource Internet demandée (c’est-à-dire fr.wikipedia.org). Si non, le serveur récursif vérifie son cache pour détermi- ner s’il a des informations concernant le serveur de noms faisant autorité pour la zone wikipedia.org (puisque c’est la zone qui devrait normalement contenir la ressource fr.wikipedia.org). Si l’adresse IP de ce serveur est dans le cache, la requête suivante du serveur récursif sera dirigée vers ce serveur de noms. Si l’adresse IP du serveur de noms faisant autorité pour wikipedia.org n’est pas disponible dans le cache, le serveur récursif détermine si il dispose de l’information sur le serveur de noms faisant autorité pour une zone qui est à un niveau immédiatement supérieur à wikipedia.org (c’est-à-dire .org). Si la recherche de la mémoire cache est probante, le serveur récursif aura à interroger les serveurs de noms faisant autorité pour l’un des niveaux inférieurs à la zone racine (dans ce contexte, soit wikipedia.org, ou .org). Si non, si la recherche complète de la mémoire cache (tel que décrite ci-dessus) ne donne pas les informations requises, le serveur récursif n’aura pas d’autre alternative que de commencer sa recherche en interrogeant les serveurs de noms dans la zone la plus haute dans la hiérar- chie de l’espace de noms DNS (c’est-à-dire, les serveurs racine). Le contact avec un serveur racine est rendu possible par un fichier appelé root hints, fichier qui est habituellement présent sur n’importe quel serveur de noms.

Le fichier root hints contient l’adresse IP d’un ou de plusieurs des treize (13) serveurs racines. Le serveur racine contiendra des informations sur les serveurs de noms de ses zones filles(les TLD). Un TLD (par exemple, .org) contiendra des informations sur les serveurs de noms de ses zones filles (par exemple, wikipedia.org. Et ainsi de suite, grâce à la délégation.

Le serveur racine contacté fournit le nom et l’adresse IP des serveurs de noms pour la zone TLD qui est en rapport à la demande, soit la zone .org, puisque la requête est pour une ressource dans wikipedia.org. Utilisant ces

(32)

informations, le serveur cache ou récursif formule ensuite et envoie une requête au serveur de noms de la zone org. Ce serveur fournira les mêmes informations (nom et adresse IP) pour le serveur de noms de la zone wikipedia.org. Il ne restera plus qu’à interroger le serveur de noms de la zone wikipedia.org pour avoir l’adresse IP de la ressource fr.wikipedia.org. Un diagramme du processus de résolution de noms (sans les opérations de recherche de cache) est donné à la figure suivante.

Figure 2.3 – Diagramme du processus de résolution de nom

(33)

PARTIE 2 :

DEPLOIEMENT DES SERVEURS ET

SÉCURISATION DU SERVICE

19

(34)

Chapitre 3

DÉPLOIEMENT DES

SERVEURS AU SEIN DU CENTRE DE DONNÉES

3.1 Topologie de déploiement des serveurs de noms du centre de données

Serveurs de noms primaires

Nous allons déployer une topologie dite “serveur primaire caché” ou “serveur primaire furtif” : le serveur primaire sur lequel les zones sont crées et modifiées n’est jamais accessible ni visible de l’extérieur. Les serveurs autoritaires officiels, sont en réalité les serveurs secondaires qui synchro- nisent leurs zones sur le serveur primaire caché.

Il se doit d’être déployé dans une partie très sécurisée du réseau du centre de données. Nous avons donc choisi le réseau du centre de données critiques.

C’est sur ce serveur que seront créées et modifiées toutes les zones sous la tutelle de BJNet. Pour chacune d’elles, on mettra en place le mécanisme des vues. Ceci permettra aux requêtes des clients internes de ne pas suivre exactement le même chemin que celles des clients externes. On aura donc à chaque fois deux zones, une publique accessible par les clients externes au réseau et une privée, accessible par les clients internes au réseau.

20

(35)

3.1 Topologie de déploiement des serveurs de noms du centre de données

Mettre en place un serveur primaire caché présente les avantages suivants :

— Avoir une tolérance aux pannes. Si le serveur primaire venait à tomber en panne, cela n’impacterait pas l’ensemble du service ;

— Le redémarrage ou le rechargement du serveur n’a aucun impact sur le service

— Il est difficile à attaquer vu que sa présence est masqué Serveurs de noms secondaires

Nous aurons deux types de serveurs de noms secondaires : les serveurs de noms secondaires pour les zones externes et les serveurs de noms secondaires pour les zones internes. Ces deux types de serveurs transféreront donc des vues différentes à partir du serveur primaire. Ce sont elles qui seront rendues publiques comme serveurs autoritaires pour les différentes zones sous la tutelle de BJNet. Nous avons donc choisi de déployer le serveur secondaire faisant autorité sur les zones externes, sur le réseau de la DMZ publique et celui faisant autorité sur les zones internes, sur le réseau de la DMZ privée. Ces serveurs synchroniseront donc leurs zones avec le serveur primaire. A chaque modification d’un fichier de zone sur ce dernier, le serveur secondaire concerné se fera notifié et donc pourra initier un transfert de zone en direction du serveur primaire.

Serveur de nom cache ou récursif

Les serveurs de noms récursifs sont ceux qui fourniront le service de réso- lution de noms aux utilisateurs du réseau BJNet. Pour des raisons de sécu- rité, l’accès au service de résolution récursive que fournissent ces serveurs sera limité aux clients du réseau. En effet, un serveur récursif ouvert à tout l’Internet présente des risques importants :

— d’empoisonnement du cache,

— d’être victime d’une attaque de déni de service (DOS) ciblée sur le serveur récursif (impactant l’ensemble des utilisateurs internes),

— de servir de vecteur indirect dans une attaque de déni de service dis- tribuée (DDOS) : attaque DNS par amplification en usurpant l’adresse IP source.

(36)

Chapitre 3. DÉPLOIEMENT DES SERVEURS AU SEIN DU CENTRE DE DONNÉES

Les serveurs récursifs n’ayant pas connaissance des zones internes ad- ministrées par BJNet, les requêtes des clients internes sur ces zones, ne suivront pas le chemin désiré, à savoir, aller vers le serveur secondaire faisant autorité sur les zones internes situé sur le réseau de la DMZ privée. On mettra alors en place, sur les serveurs récursifs, un mécanisme de redirection des requêtes portant sur les zones internes, vers le serveur secondaire autoritaire pour les zones internes.

Une autre solution aurait été de faire des serveurs récursifs, des “serveurs secondaires cachés” pour les zones internes. Ceci aurait permis aux serveurs récursifs d’héberger des zones (internes) qu’ils récupèreraient aux moyens de transferts de zones à partir du serveur primaire. Du coup, ces serveurs fourniraient directement, eux-mêmes, des réponses autoritaires aux requêtes des clients sur ces zones. Cependant, tout ceci aurait engen- dré une complexité de gestion puisque les serveurs seraient devenus hy- brides, à la fois récursifs et secondaires. De plus, pour des raisons de sé- curité, il n’est pas recommandé qu’un serveur qui fait autorité puisse ré- pondre à des requêtes récursives.

Nous avons donc décidé de déployer deux serveurs récursifs sur le ré- seau de la DMZ privée, puisque le service de résolution récursive est des- tiné aux clients internes au réseau. Le fait de choisir deux serveurs au lieu d’un seul vient en réponse au besoin de redondance. Donc, même si l’un des serveurs venait à tomber, le second pourra continuer d’assurer le service en attendant que le service soit rétabli sur le serveur en panne.

La figure 3.1 de la page suivante nous présente la topologie des serveurs de noms tel que décrit ci-dessus.

(37)

3.1Topologiededéploiementdesserveursdenomsducentrededonnées

Figure 3.1 – Topologie des serveurs de noms du centre de données

RéaliséparUlrichN.A.AZONHOU23

(38)

3.2 Choix techniques

3.2.1 Pour les serveurs autoritaires

Après avoir étudié les logiciels DNS faisant office de serveur autoritaires, quatre d’entre eux ont retenus notre attention, il s’agit de BIND, NSD, PowerDNS et KNOT.

— BIND est le logiciel serveur DNS le plus répandu. Il intègre toutes les nouvelles technologies ,

— NSD est utilisé par plusieurs gros TLD comme .FR ou .DE, ainsi que par la racine (à chaque fois, sur une partie seulement des serveurs).

NSD a fait le choix de ne pas en faire trop, afin de rester simple et rapide (tous les tests indiquent des performances deux à trois fois meilleures que celles de BIND),

— KNOT DNS est un nouveau serveur de noms (DNS) faisant autorité et spécialement conçu pour les domaines de premier niveau et les hé- bergeurs,

— PowerDNS fait partie des logiciels serveurs DNS autoritaire présen- tant les meilleures performances.

Une comparaison des performances de ces serveurs est résumée à la figure suivante :

Figure 3.2 – Comparaison de performances de BIND, PowerDNS, Knot DNS et NSD [15]

(39)

3.2 Choix techniques

Il en ressort que lorsque les requêtes augmentent, les serveurs les plus performants sont Knot et NSD. BIND arrive en dernière position quand PowerDNS vient juste derrière le duo de tête. Ceci n’est pas étonnant car NSD et Knot sont tous deux construits exclusivement pour être des serveurs autoritaires avec de grosses performances (vitesse et fiabilité) quand BIND pense beaucoup plus à être complet (à tout faire).

BIND gère le mécanisme des vues, que nous avons décidé d’implémen- ter sur notre serveur primaire alors que les trois autres ne le font pas, ou partiellement pour PowerDNS.

C’est la raison pour laquelle, pour notre logiciel serveur DNS primaire, nous avons choisi d’utiliser BIND9.x

Etant donné que les deux logiciels serveurs NSD et Knot sont aussi performants l’un que l’autre, nous avons décidé de les utiliser tous les deux pour nos serveurs secondaires. Ainsi, Knot sera utilisé comme serveur secondaire faisant autorité sur les zones internes et NSD comme serveur secondaire faisant autorité sur les zones externes.

3.2.2 Pour les serveurs récursifs

Ici les critères de sélection sont : la capacité ou non à faire la validation DNSSEC et la rapidité de réponse aux requêtes. Parmi les logiciels serveurs récursifs DNS existants, trois ont retenus notre attention :

— BIND,

— Unbound,

— PowerDNS

D’après une étude comparative de ces trois logiciels, unbound appa- rait le meilleur car très rapide et s’appliquant à répondre à toutes les re- quêtes là où, pour certaines requêtes dont la résolution prend du temps, PowerDNS préfère envoyer un message d’erreur et BIND, aucune réponse

(40)

[10]. En plus de tout ça, unbound est DNSSEC validant. C’est donc logi- quement que notre choix fut porté sur lui pour nos serveurs récursifs.

Tableau 3.1 – Récapitulatif des choix de logiciels pour les serveurs

SERVEUR CHOIX

Primaire BIND9.X

Secondaire autoritaire sur les zones internes Knot DNS Secondaire autoritaire sur les zones externes NSD

Récursifs Unbound

On obtient donc une diversité logicielle très intéressante. En effet, il est recommandé d’avoir des logiciels de serveurs différents afin d’empêcher les attaques groupées sur l’ensemble du service en exploitant une faille dans le (seul) logiciel qui aurait été installé. Concernant l’installation et la configuration des serveurs, veuillez vous référer à l’annexe

(41)

Chapitre 4

CHOIX TECHNIQUES POUR GARANTIR LA

PERFORMANCE ET LA DISPONIBILITÉ DU

SERVICE

4.1 Choix techniques

Performance

La figure suivante nous présente le diagramme de temps lié au processus de résolution de noms

27

(42)

Chapitre 4. CHOIX TECHNIQUES POUR GARANTIR LA PERFORMANCE ET LA DISPONIBILITÉ DU SERVICE

Figure 4.1 – Temps du processus de résolution

Pour améliorer la performance du service, nous ne pouvons jouer que sur deux paramètres à savoir le temps de latence du réseau interne et le temps que met le serveur récursif dans sa tâche de résolution.

Le temps que met le serveur récursif pour la résolution des requêtes est lié au logiciel qui effectue cette tâche et à son dimensionnement. En effet, mieux le serveur est dimensionné, moins il est susceptible de perdre du temps dans sa tâche de résolution. Une proposition de dimensionnement est annexé à ce document. Le choix du logiciel a déjà été fait au chapitre précédent et l’un des critères était la rapidité.

Le temps de latence du réseau interne est en réalité la somme du temps que met la requête pour passer de la machine de l’utilisateur au serveur ré- cursif situé dans le centre de données et du temps que met la réponse pour faire le chemin inverse. Pour réduire ce temps, notre proposition est de dé- ployer des serveurs récursifs près des utilisateurs. Ceci permettrait d’avoir des temps de latence très court, notamment dans le cas où la réponse à la requête se trouverait dans le cache du serveur. Ainsi, nous proposons de placer au moins un serveur récursif dans chaque point de présence afin de desservir les clients qui lui sont les plus proches.

Haute disponibilité

Une haute disponibilité s’obtient en mettant en place plusieurs serveurs récursifs de sorte que si un serveur venait à tomber en panne, un

(43)

4.2 Présentation de l’anycast

autre puisse prendre le relai. Ceci permet d’avoir une redondance du service et donc une tolérance aux pannes. Il existe plusieurs moyens pour le faire dont :

— La reconfiguration des clients, en modifiant la liste des serveurs récur- sifs des clients (dans le fichier /etc/resolv.conf ) chaque fois qu’un serveur tombe en panne (en le supprimant en fait de la liste). Un moyen d’automatiser la diffusion de cette reconfiguration de la liste des serveurs est d’utiliser un service DHCP

— DNS anycast,

— L’utilisation de protocole de redondance spécifique tels que VRRP, Heart- beat, etc... [11]

Nous avons donc opté pour la mise en place de l’anycast qui, non seulement, permet à la fois de disposer de serveurs proches des utilisateurs (performance) et qui sont redondants entre eux (disponibilité) mais égale- ment de faire de la distribution de charges et de résister aux attaques DoS et DDoS

4.2 Présentation de l’anycast

La plupart des adresses IP que l’on manipule sont des adresses unicast, c’est à dire des adresses qui désignent un unique destinataire. À chaque fois que vous envoyez un paquet vers une adresse de ce type, celui-ci sera routé vers un unique destinataire(Figure 4.2).

Il existe aussi des adresses multicast (qui comprennent les adresses broadcast) pour lesquelles plusieurs destinataires reçoivent une copie du paquet(Figure 4.3 et Figure 4.4).

Les adresses anycast quant à elles permettent d’envoyer le paquet à un destinataire parmi plusieurs. Il n’y a donc pas de copie, mais pas de destinataire unique. Idéalement, le paquet parvient au destinataire le plus proche(Figure 4.5).

L’anycast représente le moyen de pouvoir utiliser la même adresse IP sur différents serveurs. C’est fondamentalement un schéma de routage. Sa

(44)

mise en œuvre est plus centrée sur la configuration des routeurs que des serveurs eux-mêmes.

Figure 4.2 – Unicast[4] Figure 4.3 – Broadcast[4]

Figure 4.4 – Multicast[4] Figure 4.5 – Anycast[4]

4.2.1 Les propriétés d’anycast

— Chaque paquet que l’on envoie à une adresse anycast est susceptible d’aller vers un serveur différent ;

— Les paquets sont routés vers l’adresse IP possédant la meilleure mé- trique réseau. C’est souvent le serveur le plus proche, mais pas toujours. Les métriques peuvent être définis en fonction d’autres facteurs tels que la bande passante, le coût, la charge ou encore la fiabilité ;

— Les serveurs possédant des adresses anycast doivent également avoir une adresse unicast.

(45)

4.2.2 Les cas d’utilisation d’anycast

L’anycast peut être utilisé de façon locale pour :

— Faire de la répartition de charge sur plusieurs serveurs situés sur le même sous-réseau ;

— Eliminer le besoin d’utiliser un équilibreur de charge en laissant le réseau (routeur) distribuer le trafic.

Figure 4.6 – Utilisation d’anycast pour faire de la répartition de charge [5]

La décision du serveur vers lequel envoyer les données est basée sur le flux de routage ECMP. Le fait qu’il n’y ait qu’une seule route réduit les questions de routage. L’annonce des routes se fait en général avec n’importe quel protocole (RIP/OSPF/ISIS/BGP/EIGRP) ou même de façon statique.

L’anycast peut également être utilisé de façon globale pour :

— Faire une distribution de charge à travers plusieurs locations ;

— Et produire de la redondance.

(46)

Figure 4.7 – Utilisation d’anycast à l’échelle d’un AS (Autonomous System) [5]

Figure 4.8 – Utilisation d’anycast à l’échelle d’internet [5]

4.2.3 Anycast avec le DNS

Avec le DNS, anycast est généralement utilisé de deux manières :

— Sur les serveurs récursifs. C’est ce qui est observé généralement dans les réseaux d’ISP. L’objectif est de réduire les temps de réponse des requêtes, de distribuer la charge sur plusieurs équipements et de produire de la redondance. Ceci se fait en configurant l’adresse anycast chez les clients comme adresse de serveur cache récursif (par DHCP par exemple) ;

(47)

Figure 4.9 – Anycast avec des serveurs DNS récursifs [5]

— Sur les serveurs autoritaires. C’est cela qu’utilise par exemple l’ISC qui gère le serveur root F. L’objectif est de réduire les temps de réponse aux requêtes(certaines requêtes n’étant plus contraintes à faire le tour de la planète), de faire de la distribution de charge, d’apporter de la redondance et de limiter le nombre de serveurs autoritaires qui peuvent être listé dans une réponse.

Figure 4.10 – Anycast avec des serveurs DNS autoritaires [5]

Le fonctionnement général du DNS anycasting s’appuie sur les prin- cipes suivants :

— une même adresse IP (l’adresse du service DNS) est configurée sur plusieurs serveurs DNS différents (sur une interface loopback) locali-

(48)

sés chacun sur un site distinct ;

— un démon de routage (QUAGGA, BIRD etc.) implémentant un protocole de routage (OSPF, BGP etc.)tourne sur le serveur DNS en plus du serveur de noms ;

— une annonce de l’adresse du service DNS est envoyée au routeur par le démon de routage ;

— le routeur apprend l’adresse IP du serveur. La décision de routage garantit que les paquets à destination du DNS sont transmis au serveur le plus proche.

Le mécanisme de redondance est simple : si le DNS ou le réseau ne fonctionne plus, l’annonce de l’adresse IP n’est plus envoyée au routeur.

Pour que cela fonctionne, il est impératif de coupler l’état de fonctionnement du serveur DNS et l’annonce de la route au routeur. cela est souvent réalisé avec un simple script :

— le script tourne sur le serveur DNS ;

— il effectue régulièrement une requête locale auprès du service DNS ;

— si le service DNS ne fonctionne plus, le script stoppe le démon de routage pour cesser d’annoncer l’adresse ;

— à l’inverse quand le DNS fonctionne à nouveau, le script peut relancer le démon de routage. Il faut noter que le temps de convergence est souvent de plusieurs secondes, car l’ajout et la suppression de la route doivent se diffuser entre les routeurs.

L’anycast fonctionne bien car le protocole DNS est sans état : il se base sur UDP, une requête donne lieu à une réponse. Dans certains cas, le DNS utilise TCP. L’anycast fonctionne également en TCP à condition que la route ne change pas durant la connexion TCP [11].

4.3 Architecture physique du réseau de BJNet

Son déploiement s’étend à tout le Bénin et son épine dorsale se com- pose de points de présence (Point Of Presence) interconnectés entre eux

(49)

4.3 Architecture physique du réseau de BJNet

(voir Figure 4.11). Ces POP assurent les grandes distributions et sont char- gés de desservir les routeurs de bord (Provider Edge) auxquelles sont inter- connectées les administrations concernées. Les routeurs utilisés suivent la logique suivante :

Figure 4.11 – Architecture de BJNet

— les points de présence (Point of Presence) sont des routeurs possé- dant de grandes ressources (CPU, RAM, . . .) car devant gérer des quan- tités importantes de données destinées à plusieurs sous-réseaux et/ou à d’autres points de présence,

— En revanche, les routeurs de bord (Provider edge) ne disposent que d’une vue partielle du réseau. Ils savent uniquement ce qui leur est destiné et ce qui sort de leur sous-réseau. Pour cela, ils nécessitent moins de performance. Ils sont destinés à ne traiter que des flux appartenant à un nombre restreint de sous-réseau. Ce sont les routeurs servant de passerelles vers les structures connectées à BJNet. En d’autres

(50)

termes, ils font le lien entre le sous-réseau que représente la structure et le cœur du réseau. Étant plus proche des utilisateurs finaux, ils sont donc capables de filtrage plus spécifique que les routeurs au cœur du réseau.

4.4 Mise en oeuvre

Les principaux objectifs visés par l’utilisation de l’anycast dans notre contexte sont de minimiser les temps de réponse aux requêtes, de garantir la fiabilité du service et sa résistance aux attaques par déni de service. Nous avons donc décidé d’utiliser l’anycast avec les serveurs récursifs. Donc, les adresses des serveurs DNS qui seront configurés chez les utilisateurs du réseau seront des adresses anycast aboutissant vers des serveurs récursifs.

Les normes préconisent d’avoir un ou de préférence deux serveurs ré- cursifs par point de présence (pour des questions de redondance). Cha- cun de ces serveurs possédant une adresse anycast différente. Nous au- rions donc seulement à utiliser en tout deux adresses anycast, configurés sur deux serveurs récursifs et ceci dans chaque point de présence. Les utilisateurs seraient configurés avec ces deux adresses. Donc, même dans le cas où les deux serveurs tomberaient en panne, le protocole de routage dynamique (IGP) mis en place permettrait d’assurer la redirection vers le serveur cache le plus proche.

Cependant, nous venons de voir dans la partie précédente que les points de présence de notre réseau sont en réalité des routeurs possédant de grandes ressources. L’idée de déploiement de plus d’un serveur récursif dans les points de présence est donc à abandonner.

Nous avons donc choisi d’utiliser les routeurs des points de présence eux-mêmes comme serveurs récursifs. En effet, ce sont des routeurs mi- krotik qui seront utilisés dans ces points de présence, les routeurs mikro- tik offrant la possibilité d’opérer en tant que serveur DNS. Cependant, ces routeurs n’offrent pas la possibilité de faire de la résolution récursive. Nous

(51)

4.4 Mise en oeuvre

avons donc décidé de les utiliser en tant que serveurs cache only, c’est-à- dire qu’ils ne font que mettre en cache les réponses et redirigent les re- quêtes pour lesquelles ils ne possèdent pas les réponses vers d’autres serveurs qui eux sont capables de faire de la résolution et qui leur enverront les réponses. Ces routeurs seront donc configurés avec une adresse anycast. C’est cette adresse qui sera connue des résolveurs des utilisateurs.

Les routeurs seront configurés de la façon suivante : lorsqu’ils reçoivent une requête, ils font un forward, c’est-à-dire une redirection de celle-ci vers le serveur récursif du centre de données. Ce dernier fera la résolution et renverra la réponse à notre routeur qui enregistrera les données reçues dans son cache et les transmettra à l’utilisateur qui avait fait la requête.

Donc pour une résolution future portant sur les mêmes données, le routeur n’aura qu’à servir les informations qu’il détient en cache, à condition que celles-ci n’aient pas expirées.

Pour récapituler, les routeurs de chaque point de présence seront confi- gurés de façon à fournir un service DNS récursif sur une adresse anycast qui sera l’adresse du serveur DNS connue des résolveurs des utilisateurs.

Donc, en cas de panne de panne au niveau du routeur d’un point de pré- sence, le protocole de routage utilisé assurera la redirection des requêtes destinées à ce routeur vers le point de présence le plus proche. La figure de la page suivante montre comment tout ceci est organisé(Aller à l’annexe pour voir les configurations).

(52)

Figure 4.12 – Anycast au sein de BJNet

(53)

Chapitre 5

SÉCURITÉ DU SERVICE

5.1 Les attaques visant le DNS et les principales techniques de sécurisation

Au fil du temps le DNS s’est révélé comporter plusieurs failles. Les at- teintes aux infrastructures DNS sont essentiellement d’ordre technique, faisant appel à des stratégies d’attaques massives ou de corruption des informations échangées entre les serveurs récursifs et les serveurs DNS :

— l’empoisonnement : vise à intoxiquer le serveur récursif pour qu’il considère que le serveur « pirate » est légitime, en lieu et place du serveur réel. Cette opération permet notamment de capter et de dé- tourner les requêtes vers un autre site web sans que les utilisateurs puissent s’en rendre compte, avec à la clé, le risque de les voir confier des données personnelles en se croyant sur le site légitime de la victime de l’attaque. La « faille Kaminsky » dévoilée durant l’été 2008 fait partie de ce type d’attaques par empoisonnement des serveurs récur- sifs DNS ;

— le déni de service : (Denial of Service ou DoS) a pour objectif de rendre l’accès à un service impossible ou très pénible. Cette attaque peut se faire de manière brutale (saturation des serveurs par envoi massif de requêtes simultanées) ou plus subtile si l’attaquant essaie d’épuiser une ressource rare sur le serveur. Les attaques dirigées contre le système racine du DNS en février 2007 étaient typiquement des at-

39

(54)

Chapitre 5. SÉCURITÉ DU SERVICE

taques par DoS ;

— le déni de service distribué :(distributed Denial of Service ou dDoS), forme élaborée du DoS impliquant plusieurs milliers d’ordinateurs, en général dans le contexte d’un BOTNET ou roBOT NETwork : réseau d’ordinateurs « zombies » dont l’attaquant se sert à l’insu de leurs pro- priétaires grâce à des programmes malveillants diffusés via des vers se propageant d’une machine à l’autre ;

— la réflexion : des milliers de requêtes sont envoyées par l’attaquant au nom de la victime. Lorsque les destinataires répondent, toutes les réponses convergent vers l’émetteur officiel, dont les infrastructures se trouvent affectées ;

— la réflexion combinée à l’amplification :si la taille de la réponse est plus grosse que celle de la question, on dit qu’il y a amplification. La technique est la même que pour la réflexion, mais la différence de poids entre question et réponses crée un effet amplificateur. Une va- riante peut exploiter les mécanismes de protection mis en place, qui ont besoin de temps pour décoder les réponses longues avec pour effet éventuel un ralentissement dans la résolution des requêtes ;

Voici quelques actions à envisager pour garantir un niveau de sécurité correcte du dispositif DNS :

— assurer la meilleure redondance possible,de manière à ce qu’un serveur affecté par une attaque puisse être remplacé en toute transpa- rence par d’autres serveurs disposant des mêmes informations mais situés sur d’autres réseaux. C’est la raison pour laquelle les registres de noms de domaine, tel l’AFNIC, exigent toujours que chaque nom de domaine soit installé sur au moins deux serveurs de noms. D’autres techniques plus élaborées, comme le recours à des nuages anycast, permettent d’augmenter encore plus la redondance avec à la clé des gains notables en termes de sécurisation et de performances ;

— veiller à utiliser des versions à jour des logiciels DNS, notamment de BIND, corrigées par les « patchs » appropriés, afin de ne pas être vulnérable à des attaques portant sur des failles de sécurité déjà bien identifiées ;

(55)

5.2 Assurer la meilleure redondance possible

— assurer une surveillance régulière de ses serveurs et de leur confi- guration, de préférence depuis plusieurs points de l’Internet. Il est souvent arrivé, en raison de la robustesse du DNS, que la panne de serveurs ne soit détectée que lorsque le dernier d’entre eux tombe en panne. Pour vérifier la configuration, il existe des logiciels libres comme ZoneCheck. Pour assurer la surveillance depuis l’extérieur, l’organisation qui ne souhaite pas déployer une infrastructure spé- cifique peut faire appel à des services commerciaux ou communau- taires existants ;

— envisager de déployer DNSSEC, protocole de sécurisation du DNS par l’authentification des serveurs, ce système limitant notamment les attaques par empoisonnement. La perception de l’intérêt de DNS- SEC a été fortement accrue par la révélation de la faille Kaminsky qui a montré comment exploiter efficacement des vulnérabilités déjà connues au plan théorique [12].

Pour sécuriser le service, nous allons mettre en application toutes les recommandations ainsi formulées.

5.2 Assurer la meilleure redondance possible

L’utilisation de anycast permet de produire une grande redondance du service.

5.3 Veiller à utiliser des versions à jour des logi- ciels DNS

Nous proposons donc d’utiliser les dernières versions stables des logiciels que nous avons suggérés. Au moment de la rédaction de ce mémoire, il s’agit de :

— 9.11.0pour BIND ;

— 2.3.3pour Knot DNS ;

— 4.1.14pour NSD ;