FIABILISATION ET SECURISATION DU DNS

Dimension: px
Commencer à balayer dès la page:

Download "FIABILISATION ET SECURISATION DU DNS"

Transcription

1 FIABILISATION ET SECURISATION DU DNS Best Practice Document Document rédigé par le groupe de travail «DNS» animé par le GIP RENATER (CBP R6.1) Auteurs: Jean Benoit (Université de Strasbourg/GIP RENATER) Olivier Prins (CNRS/GIP RENATER) V1 03/12/13

2 GIP RENATER 2013 TERENA All rights reserved. Document No: GN3plus-NA3-T2-R6.1 Version / date: V1 03/12/13 Original language : French Original title: «FIABILISATION ET SECURISATION DU DNS» Original version / date: V1 03/12/13 Contact: RENATER bears responsibility for the content of this document. The work has been carried out by a RENATER led working group on DNS as part of a joint-venture project within the HE sector in France. Parts of the report may be freely copied, unaltered, provided that the original source is acknowledged and copyright preserved. The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/ ) under grant agreement n , relating to the project 'Multi-Gigabit European Research and Education Network and Associated Services (GN3plus)'. 2

3 Table of Contents 1 Executive Summary 5 2 Contexte 6 3 Préconisations générales Sensibilité du service par rapport aux dépendances hiérarchiques Isolement des rôles de résolution récursive et de serveur faisant autorité Isolement des zones publiques et des zones privées Plusieurs NS esclaves Hébergement des NS sur des réseaux distincts Hébergement des NS sur des sites géographique distincts Choisir une valeur adaptée pour le TTL Synchroniser les zones privées sur les résolveurs internes Panacher les systèmes d exploitation et les types de serveurs pour augmenter la résilience Virtualisation Séparer l adresse IP du service et l adresse IP de gestion Politique de sécurité et de filtrage des serveurs Chroot et limitation de privilèges Politique de nommage 9 4 Gestion des zones Enregistrement et gestion administrative des zones Choix du TLD Choix du bureau d'enregistrement (registrar) Whois: informations diffusées par les TLDs Création et suivi du domaine Transfert administratif de domaine Architecture des serveurs d autorité Serveur maître furtif ou caché Restriction des transferts de zones par IP et/ou signature TSIG et des mises à jour dynamiques Vues et split-dns Management/Supervision Gestion manuelle des zones Approche dite «industrielle» Ventilation des fichiers de configuration Ventilation des logs Suivi des délégations de zones 16 5 Service de résolution de requêtes DNS : résolveur Rappels sur la résolution récursive et le serveur cache 17 3

4 5.2 Résolveur et esclave non-officiel (stealth) pour les zones locales Fiabilisation du service de résolution DNS Reconfiguration des clients DNS ANYCAST Protocole de redondance (VRRP, Heart-beat,...) Problématique des résolveurs ouverts Résolveur et zones privées Activation de la validation DNSSEC sur le résolveur 22 6 DNSSEC Risques Risques d expiration Risque de compromission des clefs Risque d inaccessibilité de la zone Mise en oeuvre de DNSSEC Rotation des clefs 24 7 Messagerie : dépendance au DNS Eviter le «phishing» Publier les serveurs SMTP ayant autorité Signer un domaine de messagerie Utiliser des résolveurs locaux sur les serveurs SMTP 25 8 Synthèse des recommandations 26 9 Annexes Description des différents TTLs Le TTL par défaut de la zone Les TTL de l enregistrement SOA Réinitialisation du serial number par "overflow" (RFC1982) Contrôler la compatibilité EDNS du résolveur (RFC2671) Délais de timeout lors de la résolution par Bind Références Erreur! Signet non défini. 11 Glossaire Erreur! Signet non défini. 4

5 1 Executive Summary Le service DNS (pour Domain Name System) est un composant primordial d une architecture informatique. Lors des échanges inter-machines, la quasi-totalité des processus font en effet référence non pas directement à des adresses IP mais à des noms. Si la traduction des noms en adresses IP faite par le DNS venait à ne plus être assurée, tous ces services deviendraient inopérants. Il en est de même pour les autres informations que diffuse le DNS, notamment la résolution inverse, les relais des zones de messagerie ainsi qu un nombre croissant d autres informations fonctionnelles (via les champs de type TXT ou SRV). De plus, le DNS est appelé à devenir un référentiel d autorité incontournable grâce au déploiement de DNSSEC qui assure l intégrité de la source. Par exemple, la diffusion de certificats HTTPS via DANE (enregistrement TLSA) de manière autonome, contrairement aux certificats X509 qui nécessitent l intervention de tiers comme les autorités de certification. Sa criticité et son extension à de nouvelles fonctions sensibles font du DNS une cible de choix pour les attaques. Sa fiabilisation et sa sécurisation doivent être assurées rigoureusement. Ce document se veut un guide de bonnes pratiques afin d augmenter la résilience de votre service DNS. 5

6 2 Contexte La première section de ce document reviendra sur les notions de base du DNS qu il est nécessaire de maîtriser. Nous utiliserons les termes suivants : «NS» (Name Server) pour serveur DNS. «NS maître» pour serveur de nom primaire. «NS esclave» pour serveur de nom secondaire. 6

7 3 Préconisations générales 3.1 Sensibilité du service par rapport aux dépendances hiérarchiques Il faut garder à l esprit que l architecture DNS repose sur une arborescence hiérarchique stricte. Toute défaillance d un nœud père remet en cause la résolution d une zone fille. Dans le cas de zone de 1 er niveau ce n est pas problématique car les serveurs de nom pour la racine et pour les Top Level Domains (com, net, org, fr) s appuient sur des architectures fortement redondantes à l échelon international et sont en général très fiables. Pour les niveaux sous-jacents, il faudra s assurer que la zone parente à laquelle on se rattache propose un niveau de résilience élevé. 3.2 Isolement des rôles de résolution récursive et de serveur faisant autorité Il est fortement conseillé de compartimenter sur des plateformes matérielles distinctes les rôles de serveur faisant autorité et de serveur de résolution récursive. 3.3 Isolement des zones publiques et des zones privées De la même manière, il faut compartimenter les serveurs faisant autorité pour les zones publiques et les serveurs faisant autorité pour les zones privées. En effet, ces périmètres ont des finalités bien distinctes et des besoins de sécurité opposés : les zones publiques sont destinées à être visibles sur tout l Internet pour que les services qui en dépendent (serveur web, messagerie etc.) soient accessibles ; les zones privées contiennent des adresses internes qui intéressent uniquement les clients internes. Faire une séparation entre les données des zones publiques et celle des zones privées, et isoler au niveau réseau l accès à ces zones privées garantit la non-divulgation d informations vers l extérieur : architecture du réseau interne, plans d adressage, noms des serveurs, etc. Bien évidemment, la sécurité par l obscurité qui en découle ne constitue pas une mesure suffisante pour protéger le réseau interne. Cependant, en complément de la mesure principale qu est le filtrage à la périphérie du réseau par un pare-feu, elle contribue superficiellement à la protection du réseau interne. 3.4 Plusieurs NS esclaves Afin d assurer la continuité de service en cas de défaillance du NS maître il est indispensable de prévoir des NS esclaves afin de répartir le service sur plusieurs NS. La bonne pratique recommande d avoir au moins 3 NS (un maître et deux esclaves). Il est recommandé de mettre en place des serveurs secondaires, à la fois sur des réseaux IP distincts et sur des sites distincts, pour augmenter la résilience. Il est d usage de demander l hébergement d un serveur esclave à un partenaire, en proposant, en échange de bons procédés, d héberger le serveur esclave du partenaire. Des communautés peuvent formaliser un agrément d hébergement de serveurs esclaves. Il est très important de prévoir des canaux de communications entre les gestionnaires du serveur maître et ceux du serveur esclave. Il faut être très attentif aux risques que présentent des serveurs esclaves qui ne font plus autorité. Il peut arriver que le gestionnaire du serveur maître supprime l esclave dans sa liste des esclaves à notifier en cas de modification ou dans la liste des serveurs autorisés à transférer les zones. Dans ce cas, le serveur esclave risque de continuer à servir pendant quelque temps des données périmées. Les gestionnaires du serveur maître doivent absolument avertir de tout changement. 7

8 3.5 Hébergement des NS sur des réseaux distincts Afin d améliorer la résilience en cas de défaillance d un des NS ou d une attaque de type DOS par exemple, il est indispensable d héberger les NS sur des réseaux distincts. Cela permet d améliorer les capacités d interconnexion (attaque DOS) et d apporter une redondance en cas de défaillance d un de ces réseaux. 3.6 Hébergement des NS sur des sites géographique distincts. La répartition sur des réseaux distincts si elle est importante n est pas un élément suffisant, il convient également que les NS soient dispersés sur des infrastructures physiques et des sites géographiques distincts. 3.7 Choisir une valeur adaptée pour le TTL La durée de validité (Time To Live ou TTL) des enregistrements de la zone est fixée en fonction des paramètres suivants : le niveau de redondance de l architecture DNS : le TTL doit être supérieur à la durée estimée d une interruption du service DNS ; la charge : plus le TTL est faible, plus le DNS sera interrogé fréquemment (ce problème se pose surtout pour des services très visités) ; la réactivité lors d une modification de la zone : le TTL doit être inférieur à la durée souhaitée d expiration des enregistrements dans les caches des résolveurs. Exemple : le serveur web change d adresse IP ; si le TTL est à 24h, l ancienne adresse IP doit continuer à fonctionner pendant une journée avant qu on puisse la supprimer ; les risques d empoisonnement de cache : plus le TTL est élevé, plus les risques d empoisonnement du cache sont faibles. Les valeurs les plus communes du TTL sont entre 3600 et secondes. Il faut être vigilant aux effets du cache négatif lié au TTL. En effet, les résolveurs gardent en cache nonseulement les enregistrements trouvés, mais également les réponses indiquant qu'un enregistrement n existe pas, et cela pour une durée de plusieurs minutes à plusieurs heures. Par exemple, si lors de la modification d'un enregistrement, il y a un intervalle de temps pendant lequel l'enregistrement n'existe pas (entre le moment de la suppression et le moment de la recréation) le risque existe qu'un résolveur mette en cache la réponse négative. 3.8 Synchroniser les zones privées sur les résolveurs internes Afin d éviter les latences de mise à jour des zones liées au TTL, il est conseillé de déclarer ses zones en esclaves sur les résolveurs internes. Ces zones esclaves ne seront pas publiées publiquement. Elles ne servent que de cache bénéficiant d une notification active de la part du NS maître (clause «notify-also» sous Bind). Ce point est détaillé dans le paragraphe Panacher les systèmes d exploitation et les types de serveurs pour augmenter la résilience Utiliser différents systèmes d exploitation ou distribution (Debian Linux, RedHat Linux, OpenBSD ou FreeBSD par exemple) et différents serveurs DNS (ISC Bind ou NSD par exemple) permet de limiter les risques d attaques en s appuyant sur des ressources hétérogènes qui n ont pas des faiblesses exploitables simultanément. 8

9 3.10 Virtualisation L hébergement des NS sur une infrastructure virtualisée ne présente pas de contre-indications. Pour éviter le risque de dépendance circulaire, il faut néanmoins s assurer que la plateforme de virtualisation (l hôte) ne s appuie pas sur des ressources DNS publiées par la machine virtuelle (pour des réseaux privés notamment). Il est conseillé de préserver au moins un NS physique, qu il soit maître ou esclave Séparer l adresse IP du service et l adresse IP de gestion Le NS doit disposer d une adresse IP dédiée pour la gestion (accès SSH, supervision, contrôle à distance du serveur de nom etc.) et d une autre adresse IP consacrée au service DNS, sur une autre interface physique ou virtuelle (éventuellement sur une interface loopback). Cela permet de séparer l administration du serveur et l accès au service, et elle autorise différentes technique de redondance (VRRP, Anycast etc.) Politique de sécurité et de filtrage des serveurs Seul le port 53 en TCP et en UDP doit être accessible de l Internet pour un serveur public. Aucun autre service ne devrait tourner sur les serveurs en dehors du DNS. Il faut maintenir à jour le logiciel de serveur de nom, appliquer les correctifs de sécurité et limiter l'accès à ce serveur Chroot et limitation de privilèges Il est recommandé de chrooter le service DNS dans une arborescence dédiée afin de limiter la portée d une exploitation de faille de sécurité. De plus, le serveur ne doit pas tourner sous un utilisateur ayant les droits d administration ( root ou Administrateur ). Pour limiter ses privilèges, il faut le faire tourner sous l identité d un utilisateur avec un minimum de privilèges créés spécifiquement pour cela ( named par exemple). Exemple pour bind ; démarrage du processus sous l utilisateur named dans le répertoire chroot /var/named : /usr/sbin/named -u named -t /var/named Pour plus d information, consulter le chapitre 7 (Bind Security consideration) du [Bind Operation Guide] Politique de nommage Les données servies par les DNS sont publiques par nature. Il faut veiller à ne pas y mettre des données sensibles ou qui pourraient faciliter des attaques. De plus, il est recommandé de définir et d'appliquer une politique de nommage. 9

10 4 Gestion des zones 4.1 Enregistrement et gestion administrative des zones Choix du TLD Du fait du fonctionnement hiérarchique du DNS, le choix de l'extension d'un domaine n'est pas neutre. En effet le niveau de fiabilité des TLDs n'est pas homogène. Mieux vaut éviter les extensions "exotiques" Choix du bureau d'enregistrement (registrar) La qualité de service des différents bureaux d'enregistrement est très hétérogène. Il faut veiller à la qualité, à la souplesse et à la réactivité des procédures de mise à jour (l'idéal étant une interface de management en ligne avec une API). En effet, pour une zone de premier niveau, toute mise à jour de NS nécessitera une demande auprès du bureau d'enregistrement afin qu'il modifie la délégation de zone auprès du TLD Whois: informations diffusées par les TLDs Les TLDs diffusent via le service Whois des informations administratives et techniques sur les zones DNS, notamment le propriétaire et les contacts techniques ainsi que la liste des NS. Ces informations sont purement indicatives. Les NS indiqués peuvent ne pas correspondre aux NS ayant effectivement délégation. Cela n a pas d'incidence pratique. Néanmoins il est souhaitable que les données Whois soient maintenues à jour via le bureau d enregistrement Création et suivi du domaine Pour limiter les risques de cybersquating, il est conseillé d enregistrer des déclinaisons du nom (exemple : mondomaine.fr, mon-domaine.fr, etc.) et sous différents TLDs (exemple : mondomaine.fr, mondomaine.net, mondomaine.org etc.) Lors de la création, il faut vérifier que les enregistrements de la zone sont corrects avec un outil comme ZoneCheck. Il faut consulter régulièrement les informations concernant le domaine grâce à Whois, et veiller à renouveler le contrat pour éviter l'expiration du domaine. Autant que possible, il est recommandé d automatiser la surveillance et/ou le renouvellement. 10

11 4.1.5 Transfert administratif de domaine Lors de l'enregistrement d'un domaine, il faut bien s'assurer d'être bien déclaré comme propriétaire administratif du domaine, notamment lorsque l'on passe par un prestataire de service. Car le cas échéant, seul le propriétaire pourra initier la session ou la migration du domaine. Il faut également prendre soin de définir une personne morale comme propriétaire et non une personne physique qui risque de partir vers de nouveaux horizons. 4.2 Architecture des serveurs d autorité Le serveur maître est particulièrement sensible. S il est compromis et si les zones sur lesquelles il fait autorité sont modifiées, au bout d un certain temps, tous les serveurs esclaves et les serveurs cache finiront par récupérer les informations modifiées. De même, tous les clients qui font une résolution auront les informations modifiées. Ces informations modifiées le resteront jusqu à la correction de la zone et après expiration du TTL associé. Il faut sécuriser le serveur tel que décrit dans le paragraphe Serveur maître furtif ou caché Il est possible d isoler le serveur maître dans une architecture dite stealth master DNS ou hidden master DNS : le serveur maître sur lequel les zones sont modifiées n est jamais accessible ni visible de l extérieur. Le serveur maître officiel, dont le nom est mentionné dans le SOA, est en réalité un serveur esclave qui synchronise ses zones sur le serveur maître caché. Chaque fois qu une zone est modifiée sur le maître caché, les esclaves sont notifiés. 11

12 De plus, il est préconisé de mettre en place plusieurs serveurs esclaves. Comme indiqué plus haut, deux serveurs esclaves représentent le minimum recommandé. Il est tout à fait possible de mettre en place trois serveurs esclaves ou plus, de préférence sur des sites et des réseaux distincts, afin de distribuer la charge. Ainsi, en cas de dysfonctionnements réseau ou serveur, accidentels ou liés à une attaque, les autres serveurs esclaves sont toujours disponibles pour répondre aux requêtes extérieures. Il faut veiller à ne pas mettre trop de serveurs car la réponse à la requête DNS concernant les serveurs de nom doit idéalement rester en dessous des 512 octets en UDP (certaines implémentations de firewall filtrant les extensions DNS EDNS0) [RFC1035, & RFC2671] Restriction des transferts de zones par IP et/ou signature TSIG et des mises à jour dynamiques Pour que les mises à jour de zones soient le plus rapide possible entre le maître et les esclaves, il est recommandé d'activer la notification. Exemple pour Bind : notify yes; Le comportement par défaut de Bind est de notifier tous les serveurs indiqués sous les enregistrements de type NS dans le fichier de zone. Un NS maître ne doit autoriser les transferts de zones (AXFR ou IXFR) qu'à ses seuls NS esclaves (directive "allow-transfer sous Bind). Il est important de restreindre les transferts de zone sur tous les serveurs, aussi bien les serveurs maîtres que les serveurs esclaves. Exemple (bind) : options { allow-transfer { } } Afin de contrôler l'identité des NS lors des transferts de zones, il est conseillé de mettre en place une signature symétrique TSIG (Transaction SIGnature) [RFC2845]. Cela nécessite de mettre en place une clef sur le serveur maître et sur les serveurs esclaves et de configurer les serveurs pour signer les transferts de zone avec cette clef. Attention: il est impératif de synchroniser les horloges systèmes de tous les serveurs de noms, par exemple avec le protocole NTP. De plus, il faut interdire les mises à jour dynamiques. Normalement, elles sont interdites par défaut dans Bind. Il faut veiller à ne pas avoir de directives qui les autorisent dans la configuration. Autoriser une adresse IP à faire des mises à jour dynamiques est extrêmement dangereux. Si cette fonctionnalité est vraiment nécessaire, il faut utiliser TSIG pour authentifier les mises à jour dynamiques. Example de configuration TSIG dans le fichier named.conf de Bind : key "tsig_001." { algorithm "hmac-md5"; secret "IaPUtN3x+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...xxxxxS4g=="; }; server { keys { tsig_001.; }; }; server 2001:DB8::ABCD:ABCD:1 { keys { tsig_001.; }; }; 12

13 4.2.3 Vues et split-dns La mise en place du principe de séparation des zones publiques et privée se fait soit en utilisant les vues, soit via une architecture scindée en deux dite Split DNS Il est possible de créer plusieurs vues à destination des clients différents. En fonction de son adresse IP, chaque client verra d autres enregistrements. Par exemple, pour la zone example.com, les clients internes verront l ensemble des postes, des imprimantes et des serveurs internes déclarés dans la vue interne, et les clients externes ne verront que le serveur web et le relais de messagerie publics. Exemple dans Bind : view internal { match-clients { /24; }; # uniquement les adresses internes zone example.com { type master; file internal/example.com ; # contient l ensemble des enregistrements } } view external { match-clients { any; }; zone example.com { type master; file external/example.com ; # ne contient que www et mail } } L'utilisation des vues présente des risques opérationnels. Dans la mesure où, en fonction de son adresse IP source, on ne reçoit pas la même réponse, cela peut introduire des problèmes qui n'existent pas dans le fonctionnement normal du DNS et peut compliquer le débogage. Il est recommandé de bien mettre en perspective le risque et le gain de sécurité avant de choisir d'implémenter les vues DNS. 4.3 Management/Supervision Il existe deux approches pour gérer le contenu des zones Gestion manuelle des zones La gestion manuelle des fichiers de configuration est conseillée pour les zones ayant peu d entrées et/ou peu de mise à jour. C est également envisageable pour les zones plus complexes si l on adopte une grande rigueur dans le formatage des fichiers, en l occurrence: Mise à jour systématique du cartouche ; Classement par ordre alphabétique stricte : Dans le cas d entrées multi-niveaux classer sur le niveau parent ; Contrôle syntaxique via un outillage (sous Bind le rechargement d un fichier erroné ne génère pas d erreur) => voir script d exemple en annexe : named-checkconf pour les fichiers de configuration ; named-checkzone pour les fichiers de zones ; Vérifier que la valeur du champ Serial est bien incrémentée (ou incrémenter la valeur par programme) Exemple sous Bind : 13

14 ; DEBUT DE FICHIER ; Zone example.fr ; ; pdupond : update "web" from to ; pdupond : create zone ; ; TTL par defaut $TTL 3600 ; RACINE $ORIGIN example.com. ; Serveur maitre Mail contact technique ; IN SOA ns1.example.com. dnsmaster.example.com. ( ; Version ; Refresh (6h) 3600 ; Retry (1h) ; Expire (1000h) 3600 ; Negative caching TTL (1h) ) ; Serveurs maitre et esclave(s) IN NS ns1.example.com. IN NS ns2.example.com. IN NS ns3.example.com. ; Messagerie IN MX 0 smtp1.example.com. IN MX 0 smtp2.example.com. IN TXT "v=spf1 mx mx:smtprelay.example.com ~all" ; Microsoft Office 365 IN TXT "MS=ms " ; COLLE ; Les adresses des NS sous example.com ; ns1 IN A IN AAAA 2001:DB8:1234:1234:1234:1 ns2 IN A IN AAAA 2001:DB8:ABCD:ABCD:ABCD:1 ns3 IN A IN AAAA 2001:DB8:CDEF:CDEF:CDEF:1 ns1.succursale IN A ns2.succursale IN A ns3.succursale IN A ; ; DECLARATION DES ENTREES ; ; Ordre alphabetique sur le 1er niveau (ex: xxx.yyy est trie sur yyy). ; Les zones deleguees sont mixees avec les non deleguees. ; On ne tient pas compte de l'eventuel "www." ; Separateur: tabulation (sauf entre MX et son poids: utiliser un espace). ; abc IN CNAME web ; succursale IN NS ns1.succursale IN NS ns2.succursale IN NS ns3.succursale test IN CNAME web IN CNAME web list.test IN CNAME web IN CNAME web intranet.test IN CNAME web IN CNAME web web IN A ; FIN DE FICHIER

15 4.3.2 Approche dite «industrielle» À l inverse, il est possible de gérer l ensemble des informations du DNS dans une base externe au serveur de nom. Il existe des outils libres ou commerciaux, les IPAM (IP Address Management), permettant de maintenir un référentiel des données du DNS : noms de domaines, noms des machines, sous-réseaux, adresses IP etc. Ces outils offrent plusieurs avantages : cohérence des données. Par exemple, les enregistrements de type A, associant une adresse à un nom auront toujours un enregistrement inverse, de type PTR correspondant ; gestion intégrée d autres services d infrastructure : DHCP, routage de messagerie etc ; possibilité de déléguer l administration : il est possible de donner des droits fins à d autres administrateurs via une interface web ; découplage des données et du serveur de nom : il est possible de changer la façon de stocker les enregistrements sans dépendre du format des fichiers de zone d ISC BIND. Aussi, la migration vers un autre serveur de nom dépend simplement de la modification du processus de génération des zones à partir de la base de données ; automatisation de certaines tâches. Par exemple, l import et l export dans d autres formats, la déclaration ou le renommage en masse ; application systématique de politiques. Par exemple, il est possible de vérifier à la saisie si les noms entrés se conforment à un schéma de nommage défini (pour les postes de travail, pour les interfaces de routeurs etc.) Ces outils présentent également un certain nombre de risques : une plus grand complexité, et donc des difficultés de débogage, en raison des dépendances entre les différents éléments : outils de génération, interface web, authentification des utilisateurs, base de données etc ; s il existe une faille de sécurité dans l outil, que ce soit dans l interface web, l authentification, la génération, il est possible de modifier les zones. Il est recommandé de sécuriser l outil de gestion des zones avec des mesures telles que le filtrage au niveau réseau du serveur et du contrôle d accès Ventilation des fichiers de configuration Lorsqu un grand nombre de zones sont hébergés, il est conseillé d éclater la configuration dans différents fichiers qui seront incorporés par des «include» dans le fichier principal (named.conf sous Bind). Cela offre une meilleure visibilité et facilite la maintenance. Exemple pour Bind sous /var/named/chroot/etc : named.conf options.conf controls.conf logging.conf masters.conf masters_reverse.conf slaves.conf slaves_reverse.conf forwards.conf 15

16 4.3.4 Ventilation des logs Par défaut l ensemble des logs sont stockés dans un fichier unique. Il est conseillé de les ventiler par type via la section «logging» sous Bind par exemple. Exemple pour Bind : /var/log/queries/queries.log Requêtes clientes /var/log/lamers.log Erreurs serveurs DNS distants /var/log/xfer-out.log Transferts de zones sortant /var/log/xfer-in.log Transferts de zones entrant /var/log/client.log Erreurs lors émission réponse /var/log/default.log Autres messages Il peut être judicieux d exploiter ces logs pour réaliser des statistiques afin de détecter d éventuelles dérives. Par exemple la commande suivante fournit le palmarès des IP des 10 plus gros requêteurs : cat /var/named/chroot/var/log/queries/queries.log* cut -d" " -f6 cut -d"#" -f1 sort uniq -c sort -nr head -10 Des utilitaires tiers comme dnstop ou dnsperf offrent des tableaux de bord complets. Il est recommandé de centraliser les logs sur un serveur de log dédié. [ajouter configuration syslog bind en exemple] Suivi des délégations de zones La délégation de zone est à réaliser avec prudence car une fois un sous-domaine délégué celui-ci échappe totalement au domaine père. Il est ainsi fréquent qu un sous-domaine soit abandonné sans que l administrateur du domaine père en soit averti. Pour garder un œil sur les zones déléguées, il est intéressant de mettre en place un outillage qui réalisera périodiquement un ensemble de contrôle : connectivité DNS aux NS, transfert de zone si l on est esclave, etc => voir exemple de script en annexe. 16

17 5 Service de résolution de requêtes DNS : résolveur 5.1 Rappels sur la résolution récursive et le serveur cache Un serveur DNS assurant la fonction de résolution DNS pour des clients est parfois abusivement appelé serveur récursif. Cela tient au fait que ce serveur va effectuer toutes les requêtes nécessaires pour obtenir la réponse et ceci de manière récursive avant de renvoyer l'information au demandeur. Par opposition, on parlera de serveur itératif lorsqu'un serveur de noms qui ne possède pas l'information n'effectue pas de recherche mais renvoie comme réponse que l'information est détenue par un autre serveur. Le choix de ces modes de configuration a de fortes implications. De manière générale, les serveurs DNS faisant autorité sur une zone doivent être configurés en mode itératif et les serveurs DNS assurant un service de résolution de requêtes DNS doivent être configurés en mode récursif. De même un résolveur est également parfois appelé abusivement serveur cache. Cela tient au fait que le serveur de noms va également avoir une fonctionnalité appelée cache qui va stocker les informations qu il a recueillies tant que celles-ci ne sont pas périmées. Ceci est fait pour améliorer le temps de réponse aux requêtes mais également pour éviter de surcharger les serveurs de noms de requêtes identiques. 17

18 5.2 Résolveur et esclave non-officiel (stealth) pour les zones locales Pour un résolveur, la fonction de cache peut entraîner une certaine latence dans les mises à jour des données, ce qui pose des problèmes pour les zones locales. En effet, il se peut que peu de temps après une requête DNS, l enregistrement DNS qui a été sollicité soit modifié. Or cet enregistrement restera stocké dans le cache tant que sa durée de validité ne sera pas atteinte (TTL). Pour pallier ce problème, il est parfois utile de déclarer le résolveur comme esclave des zones sans pour autant que le résolveur soit un esclave officiel et visible dans le SOA de la zone. On parle alors de serveur caché qui va être notifié par les serveurs faisant autorités lors d une modification sur la zone DNS concernée. La configuration de cette notification se fait via l option alsonotify sous ISC BIND. 5.3 Fiabilisation du service de résolution DNS Historiquement, la fiabilisation de cette fonction est assurée par le fait d'avoir plusieurs serveurs DNS qui puissent être interrogés par le client. Pour les systèmes unix, la liste des serveurs DNS interrogeables est spécifiée dans le fichier /etc/resolv.conf dont voici un exemple : search example.com nameserver nameserver nameserver De cette façon, si le premier serveur DNS a une défaillance, le client interroge le serveur DNS suivant et ainsi de suite. Toutefois, cette solution n est pas forcément la plus efficace : elle est dépendante de l'algorithme utilisé par le système d exploitation. Ce qui est généralement constaté sur les systèmes unix (linux, freebsd,...), c est que par défaut toute requête va d'abord interroger le premier serveur DNS et si ce dernier ne répond pas ce n'est qu'au bout que de 5 secondes que le client va interroger le serveur DNS suivant et ainsi de suite. Il est toutefois possible de modifier ce délai via l option timeout. Ce principe qui a l intérêt d être simple et généralement disponible sur tous les systèmes n est cependant pas satisfaisant car il entraîne des latences perceptibles par l'utilisateur dès que le premier serveur DNS est défaillant. Nous allons donc aborder, sans être exhaustif, 3 méthodes pour limiter voire rendre invisible l impact de la défaillance d un serveur DNS : 1. Reconfiguration de la liste des serveurs DNS 2. DNS ANYCAST 3. Redondance du service de résolution de nom DNS par un protocole de redondance spécifique (VRRP, Heartbeat etc.) 18

19 5.3.1 Reconfiguration des clients Une solution simple serait de supprimer le résolveur défaillant de la liste des serveurs DNS que doit interroger le client. Concrètement, sur un système unix, il s agit de supprimer l entrée associée au serveur DNS défaillant dans le fichier /etc/resolv.conf. Toutefois, si cette solution simple peut être envisageable pour un poste client, elle est difficilement applicable pour un parc comportant plusieurs centaines voire milliers de machines. Un moyen d automatiser la diffusion de cette reconfiguration de la liste des résolveurs est d utiliser un service DHCP (et notamment l option domain-name-servers pour la déclaration des serveurs DNS) pour la configuration IP des machines. Le principe serait alors de mettre à jour la liste des serveurs DNS interrogeables dès qu'un résolveur serait détecté comme défaillant. Ceci suppose toutefois de disposer d'un bail DHCP court pour que cette reconfiguration soit effectuée le plus rapidement possible sur les postes. Exemple de configuration de l option domain-name-servers sous ISC DHCP : option domain-name-servers , , ; DNS ANYCAST L architecture DNS anycast est intéressante dans le cas où l infrastructure est répartie sur plusieurs sites, de préférence éloignés l un de l autre. Les serveurs DNS devront être routés sur des routeurs différents. L architecture anycast apporte une redondance du service et une répartition de la charge ; elle permet de résister aux attaques de déni de service. L anycast assure une répartition des requêtes sur plusieurs serveurs DNS en agissant au niveau de la couche réseau. Son fonctionnement s appuie sur les principes suivants : une même adresse ip (l adresse du service dns) est configurée sur plusieurs serveurs DNS différents (sur une interface loopback) localisé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 nom, 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 (si le process Bind ne tourne plus par exemple), 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 doit se diffuser entre les routeurs. Il existe un grand choix de démons de routage à déployer sur le serveur DNS : Quagga, Bird, openbgpd, openospfd etc. Le protocole de routage est également un choix ouvert en fonction des possibilités des routeurs : BGP nécessite un peu plus de configuration notamment la mise en place de peering, mais il permet de fonctionner au-delà des frontières d un domaine de routage (AS) OSPF est légèrement plus simple à configurer mais est limité au domaine de routage 19

20 L anycast fonctionne bien car le protocole DNS est sans état : en 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. Il est possible d avoir plusieurs serveurs qui s annoncent sur le même serveur mais cette architecture n est pas recommandée. S il existe plusieurs routes de poids équivalent vers différents serveurs DNS, la répartition de charge effectuée par le routeur doit toujours envoyer les paquets de la même connexion TCP vers le même serveur. Ceci est souvent le cas si le routeur route par flux ou si l algorithme de répartition de charge s appuie sur une fonction de hachage prenant l adresse IP source et/ou les ports source et destination Protocole de redondance (VRRP, Heart-beat,...) Il existe une autre approche en matière d architecture redondante. Sans s appuyer sur des protocoles de routage, il est possible d utiliser un mécanisme de redondance directement sur le serveur, comme VRRP ou heart-beat : soit entre des serveurs de noms redondants, soit entre des load-balancers frontaux redondants. Grace à VRRP, un serveur principal est élu et tous les autres serveurs sont en backup. Le mécanisme d élection est basé sur des annonces régulières effectuées par le serveur principal, doté d une priorité plus grande que les serveurs de backup. Il existe plusieurs implémentations pour les unix libres : CARP, ucarp, VRRPd, heartbeat, corosync etc. Comme pour l anycast où redondance est liée à des protocoles de routage, il faut coupler le mécanisme de redondance et l état du service Problématique des résolveurs ouverts Un résolveur 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 résolveur (impactant l ensemble des utilisateurs internes), de servir de vecteur indirect dans une attaque de déni de service distribuée (DDOS) : attaque DNS par amplification en usurpant l adresse IP source. 20

Gérer son DNS. Matthieu Herrb. tetaneutral.net. Atelier Tetaneutral.net, 10 février 2015. http://homepages.laas.fr/matthieu/talks/ttnn-dns.

Gérer son DNS. Matthieu Herrb. tetaneutral.net. Atelier Tetaneutral.net, 10 février 2015. http://homepages.laas.fr/matthieu/talks/ttnn-dns. Gérer son DNS Matthieu Herrb tetaneutral.net Atelier Tetaneutral.net, 10 février 2015 http://homepages.laas.fr/matthieu/talks/ttnn-dns.pdf Licence Ce document est sous licence Creative Commons Paternité

Plus en détail

UE5A Administration Réseaux LP SIRI

UE5A Administration Réseaux LP SIRI UE5A Administration Réseaux LP SIRI José Dordoigne Architecte infrastructure v1.0 2012-2013 Objectif de la formation -Fournir les éléments clés pour : -Comprendre les principaux services réseaux déployés

Plus en détail

Domain Name Service (DNS)

Domain Name Service (DNS) Domain Name Service () 1 PLAN Introduction Nommage avec /etc/hosts Principe du découpage en domaines Configuration de BIND Création d une zone Outils de débuggage (dig, nslookup) Déclaration d une zone

Plus en détail

Sécurisation du DNS : les extensions DNSsec

Sécurisation du DNS : les extensions DNSsec Sécurisation du DNS : les extensions DNSsec Bertrand Leonard, AFNIC/projet IDsA Sécurisation du DNS: les extensions DNSsec JRES, 19/11/03 1 Historique Jusqu en 1984 : réseau restreint militaire/universitaire/recherche

Plus en détail

Fonctionnement et Administration d un serveur de noms

Fonctionnement et Administration d un serveur de noms Fonctionnement et Administration d un serveur de noms McInfo4 - Réseaux Département d informatique IUT Bordeaux 1 Janvier 07 Rôle d un serveur de noms : Domain Name Server (Paul Mokapetris, 1983) Rôle

Plus en détail

Sécurité des protocoles internet

Sécurité des protocoles internet pascal.malterre@cea.fr Historique A l origine, les noms des machines présentes sur le réseau étaient listés dans un simple fichier texte (HOSTS.TXT), mis à jour par le NIC (Network Information Center).

Plus en détail

Serveurs de noms (domain name servers)

Serveurs de noms (domain name servers) Serveurs de noms (domain name servers) Rôle : conversion noms adresses IP Organisation hiérarchique des noms en domaines, sous-domaines etc. Fonctionnement par délégation : un domaine est géré par un serveur,

Plus en détail

DNS : Domaine Name System

DNS : Domaine Name System DNS : Domaine Name System - Les machines utilisent les adresses IP pour communiquer. - Les humaines ont du mal à manipuler et à retenir des adresses IP. Ils retiennent plus facilement des noms de machines.

Plus en détail

Administration et sécurité des réseaux

Administration et sécurité des réseaux Plan Administration et sécurité des réseaux Chapitre 5 Le service DNS (Domain name service) 1 Assurer la conversion entre les noms d hôtes et les adresses IP. Exemple: machine.domaine.xz i résolution résolution

Plus en détail

Administration Système & Réseau. Domain Name System Historique & Concepts Fonctionnalités & Hiérarchie Requêtes & Base de donnée DNS

Administration Système & Réseau. Domain Name System Historique & Concepts Fonctionnalités & Hiérarchie Requêtes & Base de donnée DNS 1/25 Administration Système & Réseau Domain Name System Historique & Concepts Fonctionnalités & Hiérarchie Requêtes & Base de donnée DNS Dynamic Host Configuration Protocol L3 STRI 2005 Philippe Latu philippe.latu(at)linux-france.org

Plus en détail

Formation EFREI - 2004/2005. Implémentation du système DNS dans Windows 200x

Formation EFREI - 2004/2005. Implémentation du système DNS dans Windows 200x Formation EFREI - 2004/2005 Implémentation du système DNS dans Windows 200x Vue d'ensemble Généralités sur DNS Installation du service Serveur DNS Configuration de zones dans Windows 200x Test du service

Plus en détail

Installation Serveur DNS Bind9 Ubuntu 12.04 LTS

Installation Serveur DNS Bind9 Ubuntu 12.04 LTS 1 Installation Serveur DNS Bind9 Ubuntu 12.04 LTS BIND (Berkeley Internet Name Daemon ou Berkeley Internet Name Domain) est le serveur DNS le plus utilisé sur Internet, spécialement sur les systèmes de

Plus en détail

DNS / NTP / SNMP. Administration Système et Réseaux, Sécurité. Objectifs. Pourquoi DNS? DNS / NTP / SNMP DNS. Philippe Harrand NTP SNMP

DNS / NTP / SNMP. Administration Système et Réseaux, Sécurité. Objectifs. Pourquoi DNS? DNS / NTP / SNMP DNS. Philippe Harrand NTP SNMP DNS / NTP / SNMP Administration Système et Réseaux, Sécurité DNS / NTP / SNMP Philippe Harrand 1 Département Informatique Pôle Sciences et Technologies 2 Direction Territoriale Sud Ouest France Télécom

Plus en détail

Domain Name System. F. Nolot

Domain Name System. F. Nolot Domain Name System F. Nolot 1 Domain Name System Principe F. Nolot 2 Les besoins Internet est composé de plusieurs réseaux Chaque réseau est composé de sous réseaux Les sous réseaux sont constitués de

Plus en détail

Bind, le serveur de noms sous Linux

Bind, le serveur de noms sous Linux Bind, le serveur de noms sous Linux 1. Principes de fonctionnement d'un serveur de noms La résolution des noms d'hôtes sur les réseaux tcp/ip est fondée sur le principe d'une répartition de la base des

Plus en détail

Domain Name Space. IUT1 dpt SRC L Isle d Abeau Jean-françois Berdjugin

Domain Name Space. IUT1 dpt SRC L Isle d Abeau Jean-françois Berdjugin Domain Name Space IUT1 dpt SRC L Isle d Abeau Jean-françois Berdjugin DNS Domain Name System permet : la résolution (directe) de nom d hôte (nom logique) en adresse(s) IP, la résolution (inverse) d adresse

Plus en détail

DNS: généralités. Annuaire téléphonique: DNS:

DNS: généralités. Annuaire téléphonique: DNS: Cours 4: DNS DNS: généralités Annuaire téléphonique: utilisé par les centraux: No de tel. (01 69 47 70 00) mémorisé par les humains : nom (P. Petit) lien entre les deux: annuaire téléphonique DNS: communication

Plus en détail

[inetdoc.linux] http://www.linux-france.org/prj/inetdoc. Administration Système & Réseau. Domain Name System. Dynamic Host Configuration Protocol

[inetdoc.linux] http://www.linux-france.org/prj/inetdoc. Administration Système & Réseau. Domain Name System. Dynamic Host Configuration Protocol [inetdoc.linux] http://www.linux-france.org/prj/inetdoc Administration Système & Réseau Domain Name System Historique & Concepts Fonctionnalités & Hiérarchie Requêtes & Base de donnée DNS Dynamic Host

Plus en détail

DNSSEC. Introduction. les extensions de sécurité du DNS. Les dossiers thématiques de l AFNIC. 1 - Organisation et fonctionnement du DNS

DNSSEC. Introduction. les extensions de sécurité du DNS. Les dossiers thématiques de l AFNIC. 1 - Organisation et fonctionnement du DNS Les dossiers thématiques de l AFNIC DNSSEC les extensions de sécurité du DNS 1 - Organisation et fonctionnement du DNS 2 - Les attaques par empoisonnement de cache 3 - Qu est-ce que DNSSEC? 4 - Ce que

Plus en détail

B1-4 Administration de réseaux

B1-4 Administration de réseaux B1-4 Administration de réseaux Domain Name System (DNS) École nationale supérieure de techniques avancées B1-4 Administration de réseaux 1 / 29 Principe Chaque machine d un réseau IP est repérée par une

Plus en détail

Gilles.Roussel univ-mlv.fr DNS

Gilles.Roussel univ-mlv.fr DNS DNS 1 Problématique Référence des machines par un nom plutôt que par un numéro (adresse IP) Moins facile à retenir Impossible de deviner une adresse d'un serveur Web Noms valables sur tout l'internet 250

Plus en détail

Délégation. Délégation d autorité. Délégation. Serveur de noms. Serveurs racine. Les serveurs de noms

Délégation. Délégation d autorité. Délégation. Serveur de noms. Serveurs racine. Les serveurs de noms D - Généralité D Domaine Name System Port : 3 [RFC 03 à 03, 987] Plus de 0 autres documents Espace de nom mondiale et cohérent Accès à toutes les ressources d Internet Gestion décentralisée Indépendant

Plus en détail

BIND : installer un serveur DNS

BIND : installer un serveur DNS BIND : installer un serveur DNS Cet article a pour but de vous présenter comment installer et configurer un serveur DNS en utilisant l'application BIND. Je supposerai que vous disposez d'un réseau local

Plus en détail

DNS. Olivier Aubert 1/27

DNS. Olivier Aubert 1/27 DNS Olivier Aubert 1/27 Liens http://www.dns.net/dnsrd/ DNS Resource Directory http://www.isc.org/products/bind/ Internet Software Consortium - Berkeley Internet Name Domain http://www.nic.fr/guides/dns-intro

Plus en détail

Formation DNS. Le pouvoir de dire nom. Valentin Roussellet (p2010) - louen@via.ecp.fr. Mercredi 1 er Décembre 2010.

Formation DNS. Le pouvoir de dire nom. Valentin Roussellet (p2010) - louen@via.ecp.fr. Mercredi 1 er Décembre 2010. Le pouvoir de dire nom Centrale Réseaux Mercredi 1 er Décembre 2010 Sommaire Noms, arbres et domaines 1 Noms, arbres et domaines Une petite histoire L arbre qui cache la forêt Domaines et sous-domaines

Plus en détail

Master 1 ALMA Réseaux informatiques 2010-2011. Rapport DNS. François HUVE Peter MOUËZA

Master 1 ALMA Réseaux informatiques 2010-2011. Rapport DNS. François HUVE Peter MOUËZA Master 1 ALMA Réseaux informatiques 2010-2011 Rapport DNS François HUVE Peter MOUËZA Table des matières 1 Principe de fonctionnement......................................... 2 2 Ajout d une machine dans

Plus en détail

M2102 - Architecture des réseaux

M2102 - Architecture des réseaux M2102 - Architecture des réseaux 8 - Service de Nom de Domaine (DNS) Cyril Pain-Barre IUT Aix-Marseille - Dept INFO Aix version du 10/3/2014 Cyril Pain-Barre 8 - DNS 1 / 16 Le DNS (Domain Name Service)

Plus en détail

DNS. Généralités Historique Arborescence Notion de registrar Architecture Principaux RR 2005-11 DNS - 1

DNS. Généralités Historique Arborescence Notion de registrar Architecture Principaux RR 2005-11 DNS - 1 DNS Généralités Historique Arborescence Notion de registrar Architecture Principaux RR DNS - 1 Licence: ce document est distribué sous la licence Gnu FDL version originale anglaise: http://www.gnu.org/copyleft/fdl.html

Plus en détail

Service de noms des domaines (Domain Name System) Cours administration des services réseaux M.BOUABID, 09-2014

Service de noms des domaines (Domain Name System) Cours administration des services réseaux M.BOUABID, 09-2014 Service de noms des domaines (Domain Name System) Cours administration des services réseaux M.BOUABID, 09-2014 Problématique Pour communiquer avec une machine, il faut connaître son adresse IP. comment

Plus en détail

- FICHE DE PROCEDURE - Configurer un serveur DNS avec Bind9 sur Debian

- FICHE DE PROCEDURE - Configurer un serveur DNS avec Bind9 sur Debian - FICHE DE PROCEDURE - Configurer un serveur DNS avec Bind9 sur Debian SISR3 N 1 Pré requis : Debian installé. Avoir une IP fixe pour le serveur DNS. Disposer d une connexion à l Internet. Création d un

Plus en détail

Administration d un serveur DNS (Domain Name System) TP N o 1 Interconnexions de réseaux

Administration d un serveur DNS (Domain Name System) TP N o 1 Interconnexions de réseaux RICM 4 - Option Réseaux Administration d un serveur DNS (Domain Name System) TP N o 1 Interconnexions de réseaux Pascal Sicard 1 Introduction Nous allons nous intéresser dans ce TP à la configuration d

Plus en détail

Contrôle Réseau Internet et services Documents papier et calculatrice autorisés 2h00

Contrôle Réseau Internet et services Documents papier et calculatrice autorisés 2h00 Contrôle Réseau Internet et services Documents papier et calculatrice autorisés 2h00 NOM : Nombre total de points : 56,5 points. Note finale = nb points acquis*20/ Les parties sont indépendantes. Dans

Plus en détail

Domain Name System 5 0 0 2 ot ol F. N 1

Domain Name System 5 0 0 2 ot ol F. N 1 Domain Name System 1 Domain Name System Principe 2 Les besoins Internet est composé de plusieurs réseaux Chaque réseau est composé de sous-réseaux Les sous-réseaux sont constitués de machines Il est possible

Plus en détail

Résolution de noms. Résolution de noms

Résolution de noms. Résolution de noms cb (C:\Documents and Settings\bcousin\Mes documents\enseignement\res (UE18)\12.DNS.fm- 25 janvier 2009 13:15) PLAN Introduction Noms des domaines de noms Principe de la résolution de noms La résolution

Plus en détail

Résolution de nom avec Bind

Résolution de nom avec Bind Stéphane Gill Stephane.Gill@CollegeAhuntsic.qc.ca Table des matières Introduction 3 Principe de fonctionnement 3 Type de serveur DNS 4 Serveur de noms primaire 4 Serveur de nom secondaire 4 Serveur cache

Plus en détail

Master d'informatique e-secure

Master d'informatique e-secure Master d'informatique e-secure Réseaux DNSSEC Bureau S3-354 Mailto:Jean.Saquet@unicaen.fr http://saquet.users.greyc.fr/m2 DNS : rappel du principe Base de données répartie et hiérarchique Contient les

Plus en détail

INFOM468 - DNSSEC. Seweryn Dynerowicz - Bureau 227. Facultés Universitaires Notre-Dame de la Paix de Namur Faculté d informatique 29 III 2011

INFOM468 - DNSSEC. Seweryn Dynerowicz - Bureau 227. Facultés Universitaires Notre-Dame de la Paix de Namur Faculté d informatique 29 III 2011 INFOM468 - DNSSEC Seweryn Dynerowicz - Bureau 227 Facultés Universitaires Notre-Dame de la Paix de Namur Faculté d informatique 29 III 2011 SDy, LSc (CSF (FUNDP)) INFOM468 - DNSSEC 29 III 2011 1 / 41 Sommaire

Plus en détail

La hiérarchie du système DNS

La hiérarchie du système DNS LA RÉSOLUTION DE NOMS 1. PRÉSENTATION DU SYSTÈME DNS 1.1 INTRODUCTION À LA RÉSOLUTION DE NOMS Pour pouvoir communiquer, chaque machine présente sur un réseau doit avoir un identifiant unique. Avec le protocole

Plus en détail

Domain Name Service (DNS)

Domain Name Service (DNS) Domain Name Service (DNS) FOSSOUO Xavier (AUF) Xavier.fossouo@auf.org PLAN Introduction Nommage avec /etc/hosts Principe du découpage en domaines Configuration de BIND Création d une zone Outils de débuggage

Plus en détail

MMI M1204 TCP/IP RÉSOLUTION DES NOMS

MMI M1204 TCP/IP RÉSOLUTION DES NOMS MMI M1204 TCP/IP RÉSOLUTION DES NOMS Problématique Sur un réseau comme Internet une machine (ou un service) peut être identifiée par : Un Nom d'hôte Une adresse logique (IP) En général, les utilisateurs

Plus en détail

INGI2347 - Securité. Rapport n 1. par François Beuvens Grégoire de Hemptinne. Groupe 6

INGI2347 - Securité. Rapport n 1. par François Beuvens Grégoire de Hemptinne. Groupe 6 INGI2347 - Securité Projet de sécurité Rapport n 1 par François Beuvens Grégoire de Hemptinne Groupe 6 Table des matières 1 Les grands principes du DNS 3 1.1 DNS : Fonctionnement des clients..........................

Plus en détail

Sur un ordinateur exécutant Windows 2000 Server Ayant une adresse IP statique

Sur un ordinateur exécutant Windows 2000 Server Ayant une adresse IP statique Le DNS DNS = Domain Name Service Sert à résoudre les noms d ordinateur en adresse IP. Contention de dénomination pour les domaines Windows 2000 (nommage des domaines W2K) Localisation des composants physiques

Plus en détail

BONY Simon IR1. Services Réseaux TP1. BONY Simon

BONY Simon IR1. Services Réseaux TP1. BONY Simon Services Réseaux TP1 BONY Simon 09 novembre 2011 1 Table des matières Introduction... 3 A Préliminaire... 4 B Configuration du client... 5 B.1 /etc/hosts et /etc/resolv.conf... 5 B.2 Tests de configuration...

Plus en détail

Sécurité des réseaux Les attaques

Sécurité des réseaux Les attaques Sécurité des réseaux Les attaques A. Guermouche A. Guermouche Cours 2 : Les attaques 1 Plan 1. Les attaques? 2. Quelques cas concrets DNS : Failles & dangers 3. honeypot A. Guermouche Cours 2 : Les attaques

Plus en détail

LEILA BACCOUCHE. La Désignation dans les systèmes répartis

LEILA BACCOUCHE. La Désignation dans les systèmes répartis La Désignation dans les systèmes répartis 1 Le service de désignation (1) Permet de nommer, gérer et localiser de manière transparente un objet ou une ressource du SD Désignation externe : appliquée par

Plus en détail

L3 informatique Réseaux : Configuration d une interface réseau

L3 informatique Réseaux : Configuration d une interface réseau L3 informatique Réseaux : Configuration d une interface réseau Sovanna Tan Septembre 2009 Révision septembre 2012 1/23 Sovanna Tan Configuration d une interface réseau Plan 1 Introduction aux réseaux 2

Plus en détail

DNS Session 3: Configuration du serveur autoritaire. Historique du support de cours RECAPITULATION REPLICATION DNS

DNS Session 3: Configuration du serveur autoritaire. Historique du support de cours RECAPITULATION REPLICATION DNS DNS Session 3: Configuration du serveur autoritaire Historique du support de cours Présenté par Alain Patrick AINA Roger YERBANGA RALL 2007 22-26 Novembre 2007 Rabat, Maroc Création du support en septembre

Plus en détail

RFC 6168 : Requirements for Management of Name Servers for the DNS

RFC 6168 : Requirements for Management of Name Servers for the DNS RFC 6168 : Requirements for Management of Name Servers for the DNS Stéphane Bortzmeyer Première rédaction de cet article le 4 mai 2011 Date de publication du RFC : Mai 2011

Plus en détail

Domain Name System Extensions Sécurité

Domain Name System Extensions Sécurité Domain Name System Extensions Sécurité 2 juin 2006 France Telecom R&D Daniel Migault, Bogdan Marinoiu mglt.biz@gmail.com, bogdan.marinoiu@polytechnique.org Introduction Extentions de Sécurité DNS Problématique

Plus en détail

Jean Saquet Université de Caen. Master 2 E-secure. Réseaux DNS. Bureau S3-354 Mailto:Jean.Saquet@unicaen.fr http://saquet.users.greyc.

Jean Saquet Université de Caen. Master 2 E-secure. Réseaux DNS. Bureau S3-354 Mailto:Jean.Saquet@unicaen.fr http://saquet.users.greyc. Master 2 E-secure Réseaux DNS Bureau S3-354 Mailto:Jean.Saquet@unicaen.fr http://saquet.users.greyc.fr/m2/rezo Domain Name System Rappel : structure de noms de domaine hiérarchique en arbre (ex : info.unicaen.fr.,

Plus en détail

CONFIGURATION P 2 P 3 P 3 P 10 P 11 P 13 P 14 P 16

CONFIGURATION P 2 P 3 P 3 P 10 P 11 P 13 P 14 P 16 CONFIGURATION 1 Présentation 2 Topologie du projet 3 Installation 4 Configuration 4.1 Création de la DMZ publique 4.2 Accès vers l Internet 4.3 Publication d Exchange 4.4 Rapports d activité et alertes

Plus en détail

Master d'informatique 1ère année Réseaux et protocoles

Master d'informatique 1ère année Réseaux et protocoles Master d'informatique 1ère année Réseaux et protocoles DNS - DHCP Bureau S3-354 mailto:jean.saquet@info.unicaen.fr http://www.info.unicaen.fr/~jean/ue9 Applications : DNS et DHCP Ces deux services sont

Plus en détail

L3 ASR Projet 1: DNS. Rapport de Projet

L3 ASR Projet 1: DNS. Rapport de Projet L3 ASR Projet 1: DNS Rapport de Projet Table des matières I. Maquette de travail...1 II. Configuration des machines...2 III. Type de zone...3 IV. Délégation de zone...3 V. Suffixes DNS...4 VI. Mise en

Plus en détail

Serveur Appliance IPAM et Services Réseaux

Serveur Appliance IPAM et Services Réseaux Page 1 Datasheet Serveur Appliance IPAM et Services Réseaux SIMPLIFER LE DEPLOIEMENT DE VOS ARCHITECTURES & DHCP Les services d adressage et de nommage sont au cœur de votre système d information, car

Plus en détail

Ce TP consiste à installer, configurer et tester un serveur DNS sous Linux. Serveur open source : bind9 Distribution : Mandriva

Ce TP consiste à installer, configurer et tester un serveur DNS sous Linux. Serveur open source : bind9 Distribution : Mandriva DNS (DOMAIN NAME SERVER) INSTALLATION ET CONFIGURATION Ce TP consiste à installer, configurer et tester un serveur DNS sous Linux. Serveur open source : bind9 Distribution : Mandriva Objectifs : L objectif

Plus en détail

Il est possible d associer ces noms aux langages numérique grâce à un système nommé DNS(Domain Name System)

Il est possible d associer ces noms aux langages numérique grâce à un système nommé DNS(Domain Name System) DNSsousLinux(debian) Introduction Tout ordinateur possède une adresse IP qui lui est propre. Exemple: 192.168.3.33 Cependant, les utilisateurs ne peuvent travailler avec des adresses numériques aussi longue

Plus en détail

Table des matières. Préface...xi. 1. Contexte... 1. 2. Principes du DNS... 11. 3. Premiers pas dans la mise en œuvre... 35

Table des matières. Préface...xi. 1. Contexte... 1. 2. Principes du DNS... 11. 3. Premiers pas dans la mise en œuvre... 35 Table des matières Préface...xi 1. Contexte... 1 Petit historique de l Internet...1 Internet et internet...2 Système de noms de domaine...4 Historique de BIND...9 Alternative au DNS?...9 2. Principes du

Plus en détail

Cisco Certified Network Associate

Cisco Certified Network Associate Cisco Certified Network Associate Version 4 Notions de base sur les réseaux Chapitre 3 01 Quel protocole de la couche application sert couramment à prendre en charge les transferts de fichiers entre un

Plus en détail

DNS. Domain Name System

DNS. Domain Name System DNS Domain Name System Dans ce dossier, nous allons expliquer le rôle et le fonctionnement d un système DNS et ensuite, nous allons montrer la mise en place d un serveur DNS secondaire. S.VAUGEOIS 24/11/2014

Plus en détail

Alinto Protect. Guide de l administrateur. Alinto Version 1.7

Alinto Protect. Guide de l administrateur. Alinto Version 1.7 Alinto Protect Guide de l administrateur Alinto Version 1.7 Index 1. Rappels sur Alinto Protect......................................................................... 1 1.1. Niveau 1 : relais de messagerie................................................................

Plus en détail

Nommage et adressage dans Internet

Nommage et adressage dans Internet 1 Nommage et adressage dans Internet Full Qualified Domain Name et URL FQDN : Full Qualified Domain Name Nom complet d'un hôte, sur l'internet, c'est-à-dire de la machine jusqu'au domaine, en passant par

Plus en détail

VI - DNS : RESOLUTION de NOMS. dans le modèle TCP/IP

VI - DNS : RESOLUTION de NOMS. dans le modèle TCP/IP SUPPORT de COURS Thierry DESPRATS VI - DNS : RESOLUTION de NOMS dans le modèle TCP/IP Sommaire Résolution de noms Principes de nommage (espace, arborescence, domaine) Modèle organisationnel du DNS Clients

Plus en détail

FICHE PRODUIT COREYE CACHE Architecture technique En bref Plateforme Clients Web Coreye Cache applicative Références Principe de fonctionnement

FICHE PRODUIT COREYE CACHE Architecture technique En bref Plateforme Clients Web Coreye Cache applicative Références Principe de fonctionnement COREYE CACHE Solution d absorption de charge pour une disponibilité et une performance optimales des applications Web En bref Architecture technique La plateforme Coreye Cache délivre la majeure partie

Plus en détail

LINUX FIREWALL. Le firewall opèrera en fonction de règles de filtrage, appelées des ACL (Access Control Lists).

LINUX FIREWALL. Le firewall opèrera en fonction de règles de filtrage, appelées des ACL (Access Control Lists). 1 LINUX FIREWALL Introduction Un firewall ou pare-feu est un des composants essentiel à la sécurité informatique d un réseau. Il va permettre d isoler une ou plusieurs machines ou réorienter les requêtes

Plus en détail

SECURIDAY 2012 Pro Edition

SECURIDAY 2012 Pro Edition SECURINETS CLUB DE LA SECURITE INFORMATIQUE INSAT SECURIDAY 2012 Pro Edition [LOAD BALANCING] Chef Atelier : Asma JERBI (rt5) Hajer MEHRZI(rt3) Rania FLISS (rt3) Ibtissem OMAR (rt3) Asma Tounsi (rt3la)

Plus en détail

Retour d expérience sur Prelude

Retour d expérience sur Prelude Retour d expérience sur Prelude OSSIR Paris / Mathieu Mauger Consultant Sécurité (Mathieu.Mauger@intrinsec.com) Guillaume Lopes Consultant Sécurité (Guillaume.Lopes@Intrinsec.com) @Intrinsec_Secu 1 Plan

Plus en détail

Plan. Les pare-feux (Firewalls) Chapitre II. Introduction. Notions de base - Modèle de référence OSI : 7 couches. Introduction

Plan. Les pare-feux (Firewalls) Chapitre II. Introduction. Notions de base - Modèle de référence OSI : 7 couches. Introduction Plan Introduction Chapitre II Les pare-feux (Firewalls) Licence Appliquée en STIC L2 - option Sécurité des Réseaux Yacine DJEMAIEL ISET Com Notions de base relatives au réseau Définition d un pare-feu

Plus en détail

Présentation du module. Services Réseau. Services réseaux, quid? Rappels Modèle OSI. Rappels Modèle OSI

Présentation du module. Services Réseau. Services réseaux, quid? Rappels Modèle OSI. Rappels Modèle OSI Présentation du module Services Réseau Michaël Hauspie Michael.Hauspie@lifl.fr Licence Professionnelle Réseaux et Télécommunications Organisation générale semaines heure de cours et heures de TD/TP par

Plus en détail

Archit Arc hit c e t c ure ure Ré Ré e s a e u

Archit Arc hit c e t c ure ure Ré Ré e s a e u Architectures Réseau Architecture d'un réseau Vous avez travaillé avec l'infrastructure du cours depuis quelque jours, et êtes un peu plus comfortables avec celle-ci Vous avez probablement la responsabilité

Plus en détail

1 Résolution de nom... 2 1.1 Introduction à la résolution de noms... 2. 1.2 Le système DNS... 2. 1.3 Les types de requêtes DNS...

1 Résolution de nom... 2 1.1 Introduction à la résolution de noms... 2. 1.2 Le système DNS... 2. 1.3 Les types de requêtes DNS... Table des matières 1 Résolution de nom... 2 1.1 Introduction à la résolution de noms... 2 1.2 Le système DNS... 2 1.3 Les types de requêtes DNS... 4 1.4 Configuration des clients DNS... 8 1.4.1 Résolution

Plus en détail

titre : CENTOS_BIND_install&config Système : CentOS 5.7 Technologie : Bind 9.3 Auteur : Charles-Alban BENEZECH

titre : CENTOS_BIND_install&config Système : CentOS 5.7 Technologie : Bind 9.3 Auteur : Charles-Alban BENEZECH 2012 Les tutos à toto BIND server-install and configure Réalisée sur CentOS 5.7 Ecrit par Charles-Alban BENEZECH 2012 titre : CENTOS_BIND_install&config Système : CentOS 5.7 Technologie : Bind 9.3 Auteur

Plus en détail

Objectifs : Faire du serveur ServLinux un serveur DNS et DHCP pour remplacer dans un premier temps les rôles assumer par le Serveur w2008.

Objectifs : Faire du serveur ServLinux un serveur DNS et DHCP pour remplacer dans un premier temps les rôles assumer par le Serveur w2008. Pré-requis : Machine Debian texte configurer L'infrastructure de base L'enregistrement du serveur linux dans les enregistrements DNS du serveur DNS de la zone Situation initiale : Objectifs : Faire du

Plus en détail

Administration réseau Résolution de noms et attribution d adresses IP

Administration réseau Résolution de noms et attribution d adresses IP Administration réseau Résolution de noms et attribution d adresses IP A. Guermouche A. Guermouche Cours 9 : DNS & DHCP 1 Plan 1. DNS Introduction Fonctionnement DNS & Linux/UNIX 2. DHCP Introduction Le

Plus en détail

PROBLÉMATIQUE D INTERCONNEXION DES RÉSEAUX IP

PROBLÉMATIQUE D INTERCONNEXION DES RÉSEAUX IP PREMIER MINISTRE Secrétariat général de la défense nationale Direction centrale de la sécurité des systèmes d information Sous-direction scientifique et technique Laboratoire Technologies de l Information

Plus en détail

CREER UN ENREGISTREMENT DANS LA ZONE DNS DU DOMAINE

CREER UN ENREGISTREMENT DANS LA ZONE DNS DU DOMAINE CREER UN ENREGISTREMENT DANS LA ZONE DNS DU DOMAINE Ref : FP. P861 V 9.0 Résumé La zone DNS de votre domaine regroupe l'ensemble des informations permettant de faire fonctionner votre domaine. Vous pouvez

Plus en détail

TP4 : Firewall IPTABLES

TP4 : Firewall IPTABLES Module Sécurité TP4 : Firewall IPTABLES Ala Rezmerita François Lesueur Le TP donnera lieu à la rédaction d un petit fichier texte contenant votre nom, les réponses aux questions ainsi que d éventuels résultats

Plus en détail

LOSLIER Mathieu. Filière Informatique et Réseau 1 ère année. TP DNS. Responsable : LOHIER Stephane. Chargé de TD : QUIDELLEUR Aurélie

LOSLIER Mathieu. Filière Informatique et Réseau 1 ère année. TP DNS. Responsable : LOHIER Stephane. Chargé de TD : QUIDELLEUR Aurélie LOSLIER Mathieu Filière Informatique et Réseau 1 ère année. TP DNS Responsable : LOHIER Stephane Chargé de TD : QUIDELLEUR Aurélie Le 24 Novembre 2010 Table des matières 1. Intoduction... 4 2. Préliminaires...

Plus en détail

Domaine Name System. Auteur: Congduc Pham, Université Lyon 1. Figure 1: Schéma des salles TP11 et TD4

Domaine Name System. Auteur: Congduc Pham, Université Lyon 1. Figure 1: Schéma des salles TP11 et TD4 TP de Réseaux IP pour DESS Domaine Name System Auteur: Congduc Pham, Université Lyon 1 1 Schéma de départ Figure 1: Schéma des salles TP11 et TD4 Le schéma de départ pour aujourd hui est celui de la figure

Plus en détail

DOMAIN NAME SYSTEM. CAILLET Mélanie. Tutoriel sur le DNS. Session 2012-2014 Option SISR

DOMAIN NAME SYSTEM. CAILLET Mélanie. Tutoriel sur le DNS. Session 2012-2014 Option SISR DOMAIN NAME SYSTEM Tutoriel sur le DNS CAILLET Mélanie Session 2012-2014 Option SISR Table des matières DOMAIN NAME SYSTEM 2013 I. DNS Statique sous Linux (Ubuntu 12.04 LTS)... 3 A. DNS Principal... 3

Plus en détail

DNS Session 3: Configura2on du serveur autoritaire

DNS Session 3: Configura2on du serveur autoritaire DNS Session 3: Configura2on du serveur autoritaire Alain Patrick AINA Grégoire EHOUMI AFNOG 2014, Djibouti, Djibouti 1 RECAPITULATION Ø Le DNS est une base de données distribuée Ø Le resolver s adresse

Plus en détail

DNS ( DOMAIN NAME SYSTEM)

DNS ( DOMAIN NAME SYSTEM) DNS ( DOMAIN NAME SYSTEM) Principe de la résolution de Noms Certaines applications nécessitent pour communiquer d utiliser les noms de Machines : Sony alors que d autres utiliseront des noms Internet ou

Plus en détail

Conception des réseaux Contrôle Continu 1

Conception des réseaux Contrôle Continu 1 NOM: PRENOM: Conception des réseaux Contrôle Continu 1 Durée : 2 heures Seuls les documents manuscrits ou distribués en cours sont autorisés. Les réponses doivent tenir dans l encadré prévu à cet effet

Plus en détail

Master d'informatique 1ère année Réseaux et protocoles

Master d'informatique 1ère année Réseaux et protocoles Master d'informatique 1ère année Réseaux et protocoles DNS Bureau S3-203 mailto://alexis.lechervy@unicaen.fr Domain Name System Le fonctionnement d'un réseau IP est basé sur l'adressage et le routage.

Plus en détail

Réseau Réseau DHCPD DNS

Réseau Réseau DHCPD DNS Réseau DHCPD DNS 3 Réseaux : DNS L internet est constitué de réseaux (dizaines de milliers) Introduction Les réseaux sont constitués de sous-réseaux Les sous-réseaux sont constitués de machines, La technologie

Plus en détail

INTERNET & RESEAUX. Dino LOPEZ PACHECO lopezpac@i3s.unice.fr

INTERNET & RESEAUX. Dino LOPEZ PACHECO lopezpac@i3s.unice.fr INTERNET & RESEAUX Dino LOPEZ PACHECO lopezpac@i3s.unice.fr Le modèle OSI Le modèle OSI (cont) Résolution et obtention d'adresses Démarrage et auto-configuration Ex. DHCP Recherche d'une adresse IP à partir

Plus en détail

Bénéfices de Citrix NetScaler pour les architectures Citrix

Bénéfices de Citrix NetScaler pour les architectures Citrix Bénéfices de Citrix NetScaler pour les architectures Citrix 15 novembre 2007 Auteurs: Mahmoud EL GHOMARI E-mail: mahmoud.elghomari@eu.citrix.com Stéphane CAUNES E-mail: stephane.caunes@eu.citrix.com Riad

Plus en détail

-DNS. Constantin Yamkoudougou. 28 décembre 2005

-DNS. Constantin Yamkoudougou. 28 décembre 2005 Sécurité dans le système de résolution de noms -DNS Constantin Yamkoudougou 28 décembre 2005 Table des matières 1 Généralités dans les systèmes de résolution de noms 2 1.1 Petite anecdote de la résolution

Plus en détail

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant. http://robert.cireddu.free.

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant. http://robert.cireddu.free. 2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES 2.2 Architecture fonctionnelle d un système communicant Page:1/11 http://robert.cireddu.free.fr/sin LES DÉFENSES Objectifs du COURS : Ce cours traitera essentiellement

Plus en détail

Profil de protection d un pare-feu industriel

Profil de protection d un pare-feu industriel Version 1.0 court-terme GTCSI 13 juillet 2015 Avant-propos Dans toute la suite de ce document, l acronyme ToE (Target of Evaluation) désigne le composant qui est l objet de l évaluation. Les passages en

Plus en détail

Il est recommandé de fermer les serveurs DNS récursifs ouverts

Il est recommandé de fermer les serveurs DNS récursifs ouverts Il est recommandé de fermer les serveurs DNS récursifs ouverts Stéphane Bortzmeyer Première rédaction de cet article le 23 mars 2006. Dernière mise à jour le 26 janvier 2009

Plus en détail

1 Configuration réseau des PC de la salle TP

1 Configuration réseau des PC de la salle TP TP Installation/Configuration du service DNS sur serveur GNU/Linux Nom : Prénom : Date : Numéro : Objectifs : Installer un serveur DNS sur un PC serveur GNU/Linux (Mandriva). Visiter les principaux fichiers

Plus en détail

(Third-Man Attack) PASCAL BONHEUR PASCAL BONHEUR@YAHOO.FR 4/07/2001. Introduction. 1 Domain Name Server. 2 Commandes DNS. 3 Hacking des serveurs DNS

(Third-Man Attack) PASCAL BONHEUR PASCAL BONHEUR@YAHOO.FR 4/07/2001. Introduction. 1 Domain Name Server. 2 Commandes DNS. 3 Hacking des serveurs DNS Détournement de serveur DNS (Third-Man Attack) PASCAL BONHEUR PASCAL BONHEUR@YAHOO.FR 4/07/2001 Introduction Ce document traite de la possibilité d exploiter le serveur DNS pour pirater certains sites

Plus en détail

TP DNS Utilisation de BIND sous LINUX

TP DNS Utilisation de BIND sous LINUX NOMS : GIRARD Fabien, NARO Guillaume PARTIE 1 : INSTALLATION D'UN SERVEUR TP DNS Utilisation de BIND sous LINUX Pour récupérer les adresses IP, on lance un terminal sur chaque machine et on tape la commande

Plus en détail

DNS Session 1: Principes de base

DNS Session 1: Principes de base DNS Session 1: Principes de base Les ordinateurs utilisent des adresses IP. Pourquoi avons nous besoin des noms? Faciles aux êtres humains de mémoriser Les ordinateurs peuvent être déplacés entres les

Plus en détail

Domaine Name Service ( DNS )

Domaine Name Service ( DNS ) Domaine Name Service ( DNS ) DOMAINE NAME SERVICE ( DNS )...2 1.) Qu'est ce qu un Service de Nom de Domaine?...2 1.1) Pourquoi utiliser un DNS...2 Historique...2 Dans quel cas l utiliser...2 1.2) Fonctionnement

Plus en détail

TP DNS. 1 Résolutions de noms. 1) Le fichier "/etc/nsswitch.conf" 2) Le fichier "/etc/resolv.conf"

TP DNS. 1 Résolutions de noms. 1) Le fichier /etc/nsswitch.conf 2) Le fichier /etc/resolv.conf TP DNS 1 Résolutions de noms 1) Le fichier "/etc/nsswitch.conf" Au préalable, nous devons configurer la machine centrale, dénommée S "n de poste", soit s52 pour nous. On lui met l'adresse IP 10.254.52.1,

Plus en détail

Windows Vista et Windows Server 2003... 15. Étude de cas... 41

Windows Vista et Windows Server 2003... 15. Étude de cas... 41 Windows Vista et Windows Server 2003... 15 Windows Vista... 16 Pourquoi Vista?... 16 L initiative pour l informatique de confiance... 17 Le cycle de développement des logiciels informatiques fiables...

Plus en détail