[Article MISC] De la scurit d'une architecture DNS d'entreprise - H...

http://brocas.org/blog/post/2006/06/22/14-de-la-securite-d-une-architec...

geek logiciel libre | how-to | vie numrique | articles air du temps

[Article MISC] De la scurit d'une architecture DNS d'entreprise

Cet article est issu de larticle publi dans le numro 23 de MISC http://www.ed-diamond.com/produit.php?ref=misc23&id_rubrique=8& caracteristique=1-2-&caracdisp=2-9- . Ses auteurs sont Christophe Brocas (christophe.brocas@free.fr) et Jean-Michel Farin (jeanmichel.farin@free.fr). Tous droits rservs MISC. Ces dix dernires annes, les entreprises ont vu une interconnexion toujours croissante de leurs systmes dinformations (SI), entre eux ainsi quavec linternet. Cette interconnexion sest accompagne dune adoption massive de protocoles standards. Parmi ces protocoles, le DNS (Domain Name Service) affiche la double caractristique dtre le plus systmatiquement utilis et srement le moins correctement surveill.

1. Introduction Le DNS est souvent vu comme un protocole utilitaire au fonctionnement opaque. Et la vue de son caractre primordial pour le bon fonctionnement des protocoles applicatifs tels SMTP ou HTTP, les portes de ce protocole sont souvent laisses grandes ouvertes tout au long de la chane de liaison du SI (postes, serveurs, routeurs etc). Nous verrons dans cet article comment scuriser ce protocole et en particulier son implmentation dans un rseau dentreprise. Les exemples de configuration reposeront sur le logiciel Bind, version 9.1.x et suivantes [BIND]. 1.1 Terminologie Avant de plonger dans le DNS, accordons nous sur les termes utiliss dans ce document : resolver : logiciel client DNS sollicit par les applications sur les postes clients afin dobtenir une rsolution; serveur cache : serveur sollicit par les resolvers ou par dautres serveurs cache. Ce type de serveur assure la fonction de rcupration dinformations auprs de serveurs de noms ou dautres serveurs cache. Il stocke les informations collectes dans son cache. Ce serveur ne grant aucune zone DNS, le type de recherche supporte est rcursif; serveur SOA : serveur de noms faisant autorit rpondant aux requtes pour une (ou plusieurs) zone(s). Ce serveur nayant pour mission que de rpondre des requtes sur un ou plusieurs domaines, dans notre configuration, nous nautorisons aucune rcursion. 1.2 Les vulnrabilits DNS prsent, regardons les diffrents types de menaces pouvant toucher le DNS : la fuite dinformations via des canaux cachs; la corruption de rsolution DNS permettant dabuser les utilisateurs du systme, dinformations et de leur drober des informations sensibles; le dni de services par lacceptation de requtes illgales ou par corruption de donnes dans les zones hberges par les serveurs DNS internes. La fuite dinformations La fuite dinformations par tunnel DNS a t couverte de manire complte dans les pages de MISC [TUN]. Les contre-mesures pour lutter contre ce type dvasion se concentreront autour de la politique daccs au service DNS ainsi quaux requtes autorises en fonction du type de client. La mise en oeuvre de cette politique sera dcrite dans le paragraphe " Configuration du serveur DNS cache interne ". Corruption de rsolution Ce type dattaque a pour but de corrompre les donnes DNS fournies au client afin de, par exemple, le diriger son insu vers des sites diffrents de ceux viss. Et ainsi, de lui drober tout type dinformations sensibles. Ce type dattaque peut tre ralis par : compromission du processus de rsolution; modification du trafic DNS; ou compromission des donnes dans le cache dun serveurs de noms. Les rponses que cet article amnera viseront : scuriser le processus de rsolution et en matriser les possibilits de modification; limiter au strict minimum lusage des requtes rcursives;

1 sur 9

26/07/2013 11:29

[Article MISC] De la scurit d'une architecture DNS d'entreprise - H...

http://brocas.org/blog/post/2006/06/22/14-de-la-securite-d-une-architec...

sassurer de lintgrit des transactions. Le dni de services Le dni de services distribu est une menace commune tous les protocoles TCP/IP implments sur les serveurs accessibles de linternet. En dehors des mesures de protections rseau (IPS) ou de rpartition de charges, peu de rponses spcifiques la configuration DNS peuvent tre appliques. Cependant, les mesures suivantes permettent limiter limpact et limplication des serveurs dns dans ces attaques : restriction des transferts de zone; interdiction de toute rcursion; contrle des requtes simples; restriction des notifications. 2. Architecture Les rgles du jeu Pour maitriser au mieux le DNS et son utilisation, nous fixons les rgles suivantes : Aucune machine du rseau interne ne peut accder linternet. Elles utilisent toutes un proxy HTTP pour le web ou un relais SMTP pour la messagerie; Aucune machine ne peut donc rsoudre autre chose que le domaine mondomaine.fr. Cela permet dtre sr de pouvoir dployer une politique de scurit maitrisable. 2.1 Les serveurs DNS et leur rle La base pour fixer une politique de rsolution est donc de dfinir un primtre et des rgles daccs : Un serveur DNS cache interne assure la rsolution de tout type de requte issue dune machine du rseau interne; Un serveur DNS SOA assure la gestion du domaine de lentreprise pour le rseau interne de lentreprise. Ce serveur ne peut tre sollicit que par le serveur de rsolution; Un serveur DNS cache en DMZ assure la rsolution des requtes sur les noms internet issues du serveur DNS cache interne; Un serveur DNS SOA externe assure la gestion du domaine de lentreprise pour les macines de linternet. Ce serveur sera sollicitable par toute machine sur linternet.

2.2 Rsolution dune requte interne du domaine ou dun sous-domaine de lentreprise Tout dabord, le resolver envoie sa requte au serveur DNS rfrenc dans sa configuration. Ce serveur est un DNS cache qui vrifie que le resolver est habilit demander des rsolutions pour le domaine ou sous-domaine demand via la mise en place dACL sur adresses IP (directive acl) et de vues (directive view). Le DNS cache ne contient aucune zone mais sait trouver le serveur matre de la zone interroge (directive forwarders). Nous utilisons les fonctionnalits de retransmission slective pour ce type de rsolution (dfinition de zones de type forward et non matre ou esclave). Afin de prserver les serveurs matres au mieux des attaques, ceux-ci sont placs dans des DMZ et seuls les serveurs cache sont autoriss y accder. 2.3 Rsolution dune requte interne dun domaine Internet Le resolver interroge le serveur cache rfrenc. Le serveur cache vrifie que le resolver est habilit rsoudre les domaines inconnus (donc Internet). Le domaine interrog ntant pas connu par le serveur cache comme zone faisant lobjet dune retransmission slective, le serveur cache retransmet la requte au serveur cache dlgu aux rsolutions externes que nous avons pris soin de positionner dans une DMZ. Ici aussi, seuls les serveurs cache sont autoriss y accder. En cas dattaque (via une hypothtique mauvaise implmentation du contrle dtat UDP sur notre pare-feu par exemple!), lattaquant naccdera qu un serveur en DMZ uniquement capable de rsoudre des requtes vers Internet. 2.4 Rsolution dune requte externe du domaine de lentreprise Dans ce cas, les requtes proveniennent dInternet vers un serveur que nous hbergeons. Bien entendu ce serveur est en DMZ. tant donn le peu de sret que constitue Internet, il ne nous semble pas utile de mettre en place des habilitations pour les rsolutions. Nous restreignons les

2 sur 9

26/07/2013 11:29

[Article MISC] De la scurit d'une architecture DNS d'entreprise - H...

http://brocas.org/blog/post/2006/06/22/14-de-la-securite-d-une-architec...

donnes de notre domaine au strict minimum pour Internet. Le resolver trouve alors sa rponse dans le DNS que nous lui proposons, la requte ne doit jamais entrer dans lentreprise. 3. Serveur DNS cache interne 3.1 Attention au poste de travail! Comme nous le disions en introduction, la corruption de donnes de rsolution est le problme majeur du DNS. Et bien, la premire attaque DNS est dviter toute requte DNS! En effet, la rsolution de noms dans les systmes dexploitation modernes impliquent des composants autres que les serveurs DNS. Par exemple sous un systme Microsoft Windows, le processus de rsolution suit les tapes suivantes : vrification si on demande la rsolution du propre nom de la machine; prsence du nom dans le fichier hosts (%Systemroot%\System32\Drives\Etc\hosts); DNS; WINS; broadcast rseaux; LMHOSTS. Ainsi, si vous modifier le contenu du fichier hosts, la chane de rsolution DNS est corrompue. Toute la politique de scurit DNS est dj rduite nant! Cette mthode est utilise par exemple par les vers de la ligne MYTOB [VER] qui font ainsi pointer des sites de type symantec.com ou update.symantec.com vers 127.0.0.1 et empcher ainsi toute mise jour de lantivirus. La solution est donc de sassurer que les utilisateurs nont pas les droits administrateur et donc ne peuvent excuter de processus pouvant modifier le fichier hosts. Idem pour ce qui est de laccs aux paramtres DNS. 3.2 Configuration du serveur DNS cache interne Une fois que le poste client nous semble correctement configur, voyons la configuration du serveur de cache interne. Dans notre exemple, les machines du rseau interne sont dans le rseau 10.1.0.0/16 et le serveur cache interne a ladresse 10.1.255.4. Les vues sous Bind Nos besoins nous conduiront dans le paragraphe suivant vouloir faire varier les rsultats des requtes en fonction du type de client (ici PC normaux et machines proxies/pivots). Or, Bind nous donne le moyen de raliser cela : les vues. Une vue est une configuration de Bind pour rpondre certains clients certains rsultats grce aux instructions suivantes : acl : permet de dfinir sous un nom un jeu de clients (adresses IP); view : dfinit une configuration complte pour un type de client; match-clients : instruction indiquant les clients qui sadressent une vue.

Au chapitre 2, nous avons dfini diffrents types de clients au sein du rseau interne (machines standards et machines passerelles). Ces diffrents types de clients vont se traduire par 2 ACLs diffrentes : NB: tous les fichiers de configuration sont disponibles sur le site [MISC23]. // ENTETE DU FICHIER NAMED.CONF du DNS CACHE INTERNE

3 sur 9

26/07/2013 11:29

[Article MISC] De la scurit d'une architecture DNS d'entreprise - H...

http://brocas.org/blog/post/2006/06/22/14-de-la-securite-d-une-architec...

// Definition des diffrents types de clients // les proxies acl "passerelles" { 10.1.255.3/32; }; // les machines du reseau interne de l'entreprise acl "reseaulocal" { 10.1.0.0/16; }; // le DNS cache en DMZ acl "dns-cache-internet" { 10.255.1.4/32; }; // le DNS soa interne acl "dns-soa" { 10.255.2.4/32; }; // localisation des fichiers de configuration options { directory "/var/named"; version "unavailable"; }; ces 2 types de clients vont correspondre 2 types de vues qui fourniront 2 types de rsolution . Voici la vue fournie aux clients de type proxies ou passerelles. // Suite du FICHIER NAMED.CONF du DNS CACHE INTERNE // vue s'adressant aux proxies view "passerelles" { // machines a qui s'adressent cette vue. Ici les proxies de l'entreprise. match-clients { "passerelles"; }; // en cas de requete faite sur un domaine non gr par ce serveur, // envoi des requtes sur le DNS cache internet forward only; forwarders { 10.255.1.4; }; // requete sur le mondomaine.fr : // redirection de la requete vers le DNS SOA interne zone "mondomaine.fr" { type forward; forwarders { 10.255.2.4;}; forward only; }; // redirection identique pour les requetes sur la zone reverse zone "10.in-addr.arpa" { type forward; forwarders { 10.255.2.4; }; forward only; }; };

Les passerelles peuvent effectuer tout type de requte. Ces requtes seront satisfaites de la manire suivante : requte sur le domaine mondomaine.fr : envoi dune requte auprs du serveur matre interne (IP : 10.255.2.4); requte sur tout autre domaine : envoi vers le serveur cache en DMZ (adresse IP 10.255.1.4). Voici ensuite la vue pour les postes lambda du rseau local :

// Fin du FICHIER NAMED.CONF du DNS CACHE INTERNE

4 sur 9

26/07/2013 11:29

[Article MISC] De la scurit d'une architecture DNS d'entreprise - H...

http://brocas.org/blog/post/2006/06/22/14-de-la-securite-d-une-architec...

// vue s'adressant aux PC du reseau interne de l'entreprise view "reseaulocal" { // Machines a qui s'adressent cette vue. // Ici, les machines lambda (PC) du reseau interne. match-clients { "reseaulocal"; }; // requete sur le mondomaine.fr : // redirection de la requete vers le DNS SOA interne zone "mondomaine.fr" { type forward; forwarders { 10.255.2.4; }; forward only; }; // redirection identique pour les requetes sur la zone reverse zone "10.in-addr.arpa" { type forward; forwarders { 10.255.2.4; }; forward only; }; }; Note : les zones de type forward ont t introduites en version 9.1.x de Bind.

Cette configuration ne permet de rsoudre que des noms dans le domaine mondomaine.fr . Les autres noms de domaines ne sont rsolus que pour les machines passerelles. Cette mesure combine la fermeture de tous les ports rseaux (comme HTTP/S ou SMTP) pour les machines du LAN au niveau du firewall empche toute capacit dvasion par tunnel DNS autonome. Pour que lvasion soit dsormais possible, il faut que lattaquant dispose du code dauthentification de lutilisateur sur le proxy applicatif ce qui limite grandement la menace des attaques automatises. Et nous sortons l du primtre de la scurisation du DNS. 4.1 Mise en sret des informations Les informations contenues dans le DNS SOA interne font de ce DNS le coeur de notre systme. En effet, il est le seul contenir les donnes de rsolution et doit ce titre tre le plus protg. Ce DNS est plac derrire un pare-feu voire un IPS implmentant un contrle dtat sur UDP performant. Des rgles de scurit sont mises en place pour nautoriser que les DNS cache interne interroger notre DNS SOA interne. Ces rgles sont mises en place sur lquipement de scurit rseau et dans la configuration du DNS. Ces restrictions limitent les risques de dni de services sur notre DNS SOA interne, le nombre de clients simultans tant limit par le nombre de DNS cache. 4.2 Les mises jour dynamiques Certaines applications de lentreprise peuvent ncessiter la mise en place des mises jour dynamiques (serveur DHCP, contrleur de domaine, etc.) sur notre DNS SOA. Dans ce cas, il est intressant de crer des sous-domaines particuliers pour ces applications, celles-ci ne peuvent alors pas tout modifier dans notre DNS. Par exemple, on peut crer le sous-domaine dhcp.mondomaine.fr sur notre DNS et autoriser le serveur DHCP y effectuer ses mises jour sans lui donner de droits sur mondomaine.fr. Loption update-policy permet de plus de limiter les oprations possibles sur la zone. Ainsi, nous pouvons nautoriser le serveur DHCP ne modifier que les enregistrements de type A, garantissant ainsi limpossibilit de modification nos enregistrements de type NS par exemple. Lutilisation de clef TSIG est galement une scurit mettre en oeuvre autant que possible. 4.3 Cration dune clef pour mises jour dynamiques

5 sur 9

26/07/2013 11:29

[Article MISC] De la scurit d'une architecture DNS d'entreprise - H...

http://brocas.org/blog/post/2006/06/22/14-de-la-securite-d-une-architec...

Nous commenons par mettre en place des clefs TSIG pour les serveurs utilisant les mises jour dynamiques et acceptant dutiliser ce type de clefs. Nous gnrerons notre clef avec loutil dnssec-keygen. Prenons par exemple la mise en place dune clef pour notre serveur DHCP: dnssec-keygen -a HMAC-MD5 -b 512 -n HOST dhcp.mondomaine.fr

Explication des options : Loption -a permet de choisir lalgorithme utilis par la clef (ici HMAC-MD5); Loption -b est la longueur de la clef (ici 512 bits); Loption -n spcifie le type de clef cr (dans notre cas, il sagit dune clef de type HOST); Le dernier paramtre est le nom de la clef. Nous obtenons deux fichiers du type Kdhcp.mondomaine.fr.+157+55315.key et Kdhcp.mondomaine.fr.+157+55315.private contenant chacun la clef. En effet, dans notre cas ces deux fichiers sont identiques. Les noms de ces fichiers sont toujours forms par la lettre K majuscule, suivie du nom de la clef, puis de lidentifiant de lalgorithme utilis et un identifiant. Le fichier en .key contient notre clef sous la forme:

dhcp.mondomaine.fr. IN KEY 512 3 157 S5m+161iLtk6Y7+nK+8jpV1fll2AHLxN8SqVeZqzxQyg+L1187PbT5wO pteHcN4NdwO59t2

et le fichier .private contient cette mme clef mais sous la forme: Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: S5m+161iLtk6Y7+nK+8jpV1fll2AHLxN8SqVeZqzxQyg+L1187PbT5wOpteHcN4NdwO59t2TYZkpsbUocMv1+g==

Pour nos besoins, nous crons un nouveau fichier ne contenant que la clef. Ce fichier sappelle clefdhcp.key et contient : secret "S5m+161iLtk6Y7+nK+8jpV1fll2AHLxN8SqVeZqzxQyg+L1187PbT5wOpteHcN4NdwO59t2TYZkpsbUocMv1+g==";

4.4 Configuration Nous filtrons les adresses ip source via loption allow-query. acl "dns-cache-interne" { 10.1.255.4/32; }; acl "updateservers" { 10.1.255.7/32; }; options { // Rpertoire o se trouvent les fichiers de zone directory "/var/named"; // Modification du nom de version renvoy version "unavailable"; // Interdiction des transferts de zone allow-transfer{"none";}; // Interdiction des notifications de mise jour allow-notify {none;}; // Autorisations de requtes internes et pour le DNS cache allow-query {127.0.0.1; "dns-cache-interne";"updateservers";}; // Pas de rcursion recursion no; }; // Dfinition de la clef du serveur DHCP key "key.dhcp.mondomaine.fr" { algorithm hmac-md5; include "clefdhcp.key"; }; // Dfinition de la sous-zone maitre dhcp zone "dhcp.mondomaine.fr" { type master; file "db.dhcp.mondomaine.fr"; // Dfinition des droits de mise jour (type A pour le serveur utilisant la clef dhcp) update-policy { grant key.dhcp.mondomaine.fr name dhcp.mondomaine.fr A ; }; forwarders {}; }; // Dfinition de la zone maitre zone "mondomaine.fr" {

6 sur 9

26/07/2013 11:29

[Article MISC] De la scurit d'une architecture DNS d'entreprise - H...

http://brocas.org/blog/post/2006/06/22/14-de-la-securite-d-une-architec...

type master; file "db.mondomaine.fr"; forwarders {}; }; 5. Serveur DNS cache en DMZ Ce serveur a pour vocation deffectuer pour le compte du serveur DNS cache interne les rsolutions de noms de domaines internet. Cette particularit nous permet de restreindre les clients pouvant le solliciter ce seul serveur. Note : si vous utilisez une version de Bind infrieure 9.x, il faut prendre soin de se prmunir de 2 risques majeurs de corruption de caches: le glue fetching qui consiste pour un serveur, recevant un enregistrement NS sans enregistrement de type A, chercher obtenir cet enregistrement A entrainant des risques de corruption du cache, la prdiction du numro de lID du message DNS [HEADER] qui rend le serveur sensible aux attaques de force brute. Voici la configuration du serveur :

// dfinition d'une ACL pointant le DNS cache interne acl "dns-cache-interne" { 10.255.1.4/32; }; options { // repertoire contenant les fichiers de configuration directory "/var/named"; // aucun transfert de zone autorise allow-transfer{"none";}; // seul le dns cache interne est autoris allow-query { "dns-cache-interne"; }; // pour BIND 8 : randomisation de l'ID de message DNS //use-id-pool yes; // pour Bind 8 : pas de glue fetching //fetch-glue no; }; // Definition de la zone racine : // Elle contient la liste des serveurs racines qui le serveur va s'adresser // pour commencer resoudre les requetes. zone "." { type hint; file "/var/named/named.root"; } Ports DNS et Firewall Voici un petit mmento sur les ports utiliss pour les requtes DNS : envoi de la requte port > 1023 vers port 53 en tcp ou udp; rponse la requte : port 53 vers port > 1023 en tcp ou udp. On dit gnralement que ludp est utilise pour les requtes simples et tcp pour les transferts de zones. Mais, en fait, en fonction de la taille de la rponse, tcp peut tre obligatoire mme pour les requtes simples. 6. Serveur DNS SOA externe Le serveur DNS Internet est celui le plus expos en considrant le danger extrieur (nous ne reviendrons pas sur ce vaste sujet...). Il est donc important de bien lui appliquer les rgles de scurit appliques tout serveur disponible sur Internet. Au niveau de la configuration DNS, elle est trs simple. Il suffit de crer une zone de type matre sur ce serveur et dinterdire toute rcursion. Il faut ensuite remplir la zone avec les donnes devant tre disponibles sur Internet.

options { // Rpertoire o se trouvent les fichiers de zone directory "/var/named"; // Modification du nom de version renvoy version "unavailable"; // Interdiction des transferts de zone allow-transfer{"none";}; // Interdiction des notifications de mise jour allow-notify {none;}; // Autorisations de requtes allow-query {any;}; // Pas de rcursion recursion no; };

7 sur 9

26/07/2013 11:29

[Article MISC] De la scurit d'une architecture DNS d'entreprise - H...

http://brocas.org/blog/post/2006/06/22/14-de-la-securite-d-une-architec...

// Dfinition de la zone maitre zone "mondomaine.fr" { type master; file "db.mondomaine.fr"; forwarders {}; };

Note : Nous pouvons fusionner physiquement les 2 serveurs DNS Internet (le cache et le serveur DNS internet). La configuration utiliserait alors le principe des vues en fonction de ladresse appelante comme nous lavons vu en chapitre 3 pour la configuration du DNS cache interne. 7. Les logs Par dfaut, le dmon named envoie tous ses messages au syslog de la machine qui peut aussi recevoir les messages des autres dmons du systme. Le manque de lisibilit dun tel syslog nuit de manire la scurit du DNS en gnant sa supervision. Heureusement, il est possible de configurer les logs de named via des canaux de logs afin de, dans notre cas, rediriger certains types de messages dans des fichiers spcifiques. Named peut utiliser plusieurs canaux de logs en parallle traitant les mmes informations ou non. Dans notre exemple, nous utilisons deux canaux de logs, un premier pour les messages concernant les problmes de scurit et les transferts de zone et un second pour les autres messages et les transferts de zone (messages par dfaut).

Ces lignes de configuration sont placer dans les fichiers /etc/named.conf de tous les DNS. logging { // Paramtrage du canal des messages de scurit channel securitylogs { // Envoi vers le fichier dns_security.log avec roulement de 10 archives de 5Mo file "/var/log/named-sec.log" versions 10 size 5m; // Affichage de tous les messages (+messages debug si activation du mode debug) severity dynamic; // Affiche le nom de la catgorie du message print-category yes; // Affiche la svrit du message dans les logs print-severity yes; // Affiche la date du message dans les logs print-time yes; }; // Paramtrage du canal par dfaut channel defaultlogs { // Envoi vers le fichier dns_default.log avec roulement de 10 archives de 5Mo file "/var/log/named-default.log" versions 10 size 5m; // Affiche les messages de svrit "info" et suprieur severity info; // Affiche le nom de la catgorie du message print-category yes; // Affiche la svrit du message dans les logs print-severity yes; // Affiche la date du message dans les logs print-time yes; }; // Envoi des messages par dfaut notre canal defaultlogs

8 sur 9

26/07/2013 11:29

[Article MISC] De la scurit d'une architecture DNS d'entreprise - H...

http://brocas.org/blog/post/2006/06/22/14-de-la-securite-d-une-architec...

category default { defaultlogs; }; // Envoi des messages de transferts a nos canaux defaultlogs et securitylogs category xfer-in { securitylogs; defaultlogs; }; category xfer-out { securitylogs; defaultlogs; }; // Envoi des messages de scurit notre canal securitylogs category security { securitylogs; }; };

Il est galement possible de crer un canal spcial pour les mises a jour dynamiques sur les serveurs utilisant ce service :

channel updatelogs { file "/var/log/named-update.log" versions 10 size 5m; severity dynamic; print-category yes; print-severity yes; print-time yes; }; category update { updatelogs; };

Voici deux exemples de messages lus dans le fichier de logs de scurit :

Nov 25 10:34:57.910 security: info: client 192.168.9.9#1349: query (cache) denied Nov 25 15:22:53.390 security: error: client 192.168.9.9#32776: zone transfer 'mondomaine.fr/IN' denied

Ces deux messages ont les significations suivantes : Le premier est une interdiction dinterrogation; Le second est une interdiction de transfert de zone. 8. Conclusion Comme nous avons pu le voir, la scurisation du DNS passe avant tout par le fait de se poser les bonnes questions sur son utilisation : qui lutilise? pour quels types de rsolution? est-ce lgitime? La rponse ces questions sous langle de la scurit nous a permis darriver aux solutions suivantes : une sparation des diffrents services DNS (rsolution internet vs rsolution du domaine interne) par spcialisation des serveurs; une politique centralise et matrise daccs linternet limitant le spectre de clients pouvant solliciter et donc potentiellement exploiter le DNS. Une amlioration supplmentaire pourrait tre lutilisation de DNSSEC [DNSSEC] pour le contrle dintgrit et lauthentification des demandes de rsolutions de noms et les rponses associes. Cette utilisation serait implmenter au niveau du DNS SOA internet. Rfrences : [TUN] VUILLARD, V. Tunnel DNS : fuite dinformation universelle. In:MISC 18, Mars-Avril 2005. [VER] TREND Micro System. Description du virus MYTOB.KG http://www.trendmicro.com/vinfo/virusencyclo /default5.asp?VName=WORM%5FMYTOB%2EKG&VSect=T , [MISC23] BROCAS C., FARIN J.M.. fichiers de configuration des diffrents serveurs DNS dcrits dans larticle. [BIND] Page daccueil de BIND http://www.isc.org/sw/bind/ , [HEADER] RFC 1035 http://www.ietf.org/rfc/rfc1035.txt?number=1035 , domain names - implementation and specification, chapitre 4.1.1 [DNSSEC] RFC 4033 http://www.ietf.org/rfc/rfc4033.txt , 4034 http://www.ietf.org/rfc/rfc4034.txt et 4035 http://www.ietf.org/rfc/rfc4035.txt , Ressources DNSSEC, bind http://brocas.org/blog/tag/bind dns http://brocas.org/blog/tag/dns scurit http://brocas.org/blog/tag/s%C3%A9curit%C3%A9 Commentaires (2) La discussion continue ailleurs youba01 | 26 octobre 2011 1. Je dois installer un serveur 2008 avec Exchange, FTP, WEB dans une DMZ. Je me pose des questions quant l'installation dAD ? Doit-on intgrer ce serveur dans l'AD du rseau existant et donc ouvrir des ports pour DMZ vers LAN ou est-il prfrable d'installer ce serveur de manire indpendante avec son AD et ses Utilisateurs. chris http://brocas.org/blog/ | 27 avril 2012 2. Dsol pour le lag La question est plus oriente W2K8 que DNS. Je ne peux pas rpondre, sorry.

9 sur 9

26/07/2013 11:29