Résoudre Tous Les Problèmes De Windows Et Autres Programmes

Comment utiliser un DNS personnel pour isoler les attaques du serveur racine

À condition que quelques programmeurs aient raison, ce qui a commencé comme une tentative de fournir de meilleures performances de serveur DNS (Domain Name System) sur les machines Windows peut également être un moyen de réduire les problèmes de sécurité DNS.

De manière assez surprenante, le projet est centré sur un dérivé spécialement configuré de BIND 9.2 (Berkeley Internet Name Domain) localisé sur la machine de l'utilisateur. Ce DNS localisé, appelé BIND-PE et disponible sur NTCanuck.com —a été initialement annoncé sur le serveur de nouvelles de Gibson Research Corp. (GRC), news.grc.com , dans un groupe de discussion lié à l'utilitaire de recherche du système de noms de domaine (DNSRU) de GRC, qui a été conçu pour tester les performances et les taux d'expiration du système DNS.



Le serveur BIND est le serveur de noms le plus fréquemment utilisé sur Internet et fournit le mécanisme qui traduit les noms de domaine en adresses de protocole Internet pour les navigateurs Web et autres applications Internet. Normalement, un fournisseur de services Internet (FAI) fournit plusieurs serveurs de noms à l'usage de ses clients. BIND-PE, cependant, fournit un DNS indépendant du FAI qui s'exécute directement sur les ordinateurs des utilisateurs.



l'espace de stockage du système android s'épuise

Un épisode malheureux stimule l'action

Mon attrait immédiat pour l'exécution d'un DNS localisé était la possibilité d'éviter un empoisonnement potentiel du cache local des serveurs DNS de mon FAI. L'empoisonnement du cache DNS est un exploit d'attaque sur un serveur DNS qui remplace le mappage d'adresse Internet d'un nom de domaine par l'adresse IP d'un autre ordinateur. J'ai été victime d'un empoisonnement du cache DNS lorsque ma tentative de visite du site Web de CNN a conduit mon navigateur à me diriger vers un site Web qui proposait un contenu d'une tout autre nature.



Randal Vaughn est professeur de systèmes d'information à l'Université Baylor à Waco, au Texas. Il est joignable au Randy_Vaughn@Baylor.edu .

L'empoisonnement du cache peut non seulement entraîner un incident embarrassant comme le mien, mais il peut également être utilisé pour rediriger votre navigateur depuis, par exemple, le site Web de votre banque vers un autre serveur qui ressemble suffisamment à votre banque pour vous faire subir une perte financière. Inutile de dire que je suis très motivé pour éviter ce genre de problème à l'avenir. Malgré tout, j'ai pensé qu'il valait la peine de considérer les performances du DNS localisé.

DNSRU a vu le jour après que GRC a tenté d'esquiver une attaque par déni de service en modifiant l'adresse IP de son domaine. GRC, basé à Laguna Hills, en Californie, a remarqué que les serveurs DNS n'honoraient pas toujours correctement le court délai d'expiration du cache (10 minutes) de l'entreprise en retournant aux serveurs faisant autorité de GRC pour mettre à jour leur IP de domaine. Les tests DNSRU comprennent un certain nombre de requêtes conçues pour mesurer les réponses d'un serveur DNS aux noms de domaine mis en cache, non mis en cache et connus.

Pour mesurer un serveur, DNSRU rassemble plusieurs centaines de demandes de noms telles que 3bglnvvvzeyrk5f3xqsqrxflqh.computerworld.com et nvtfp1prswuqzfnfcatcgpiufc.com, ainsi que des demandes de noms d'un certain nombre d'autres sites Web populaires. Gibson a publié DNSRU afin de recueillir les résultats des tests d'un grand nombre de serveurs DNS. Chaque rapport DNSRU comprend l'adresse IP du serveur, le temps universel coordonné (UTC) de l'exécution du test et les mesures de performance du serveur.



Une exécution de test DNSRU typique, telle qu'une exécution utilisant le serveur DNS d'un FAI, produit un résumé des résultats du test tels que :

66. xxx.xxx.xxx Min Moy Max Dev.Std Fiable%
Nom mis en cache 0,025 0,038 0,057 0,006 99,0
Nom non mis en cache 0,051 0,097 0,212 0,028 100,0
Recherche DotCom 0,083 0,097 0,150 0,013 100,0

UTC : 2002-12-14, de 22:05:58 à 22:06:53, pour 00:55.419

J'ai masqué la véritable IP du serveur dans la sortie DNSRU ci-dessus à 66.xxx.xxx.xxx afin de protéger le DNS.

Le même test contre l'utilisation du serveur DNS localisé exécuté sur localhost (127.0.0.1) a produit :

127. 0. 0. 1 Min Moy Max Dev.Std Fiable%
Nom mis en cache 0,000 0,000 0,002 0,000 100,0
Nom non mis en cache 0,037 0,092 0,210 0,034 99,5
Recherche DotCom 0,065 0,085 0,120 0,010 100,0

UTC : 2002-12-14, de 22:05:05 à 22:05:38, pour 00:33.478

Ces résultats typiques suggèrent que le DNS localisé présente en effet un avantage significatif en termes de performances pour les noms mis en cache et un indice de performances améliorées pour les recherches « DotCom », mais ils n'offrent pas d'amélioration pour les noms non mis en cache par rapport au DNS du FAI. Les temps de mise en cache améliorés sont le résultat de la mise en œuvre par le DNS localisé d'une fonction de cache persistante. Un test DNSRU se compose de plusieurs centaines de requêtes. La colonne Fiabilité implique que le DNS du FAI et le DNS localisé n'ont pas répondu à quelques requêtes, ce qui est commun à tous ces tests. Il est intéressant de noter que le DNS localisé, BIND-PE, est configuré pour utiliser des serveurs racine maintenus par Open Root Server Confederation Inc. (ORSC) plutôt que les racines standard utilisées par mon FAI.

Les tests d'expiration de DNSRU dépendaient du serveur DNS de GRC fournissant un nom spécialisé avec un délai d'attente de quelques secondes. Le serveur DNS du FAI et le DNS localisé ont tous deux obtenu des résultats satisfaisants lors des tests d'expiration. Une capture de paquets de quelques tests DNSRU a établi que le serveur DNS standard de mon FAI générait près de 1 600 paquets par test, tandis que le DNS localisé a généré un peu plus de 1 800 paquets lors de son test DNSRU initial et environ 850 paquets par test lors des tests suivants. DNSRU contourne le cache du client DNS de Windows, je peux donc conclure que le cache DNS localisé fonctionne correctement, mais je ne peux pas déterminer si le DNS localisé offre une réduction globale du trafic.

Il y a, bien sûr, quelques inconvénients potentiels à l'exécution d'un DNS localisé. Premièrement, une large distribution d'un tel outil pourrait éventuellement rendre les utilisateurs à domicile vulnérables à des exploits spécifiques. Le BIND-PE actuel ne serait pas applicable dans les paramètres commerciaux lorsqu'ils nécessitent des entrées DNS spécifiques. Selon Richard Sexton, membre du conseil d'administration de l'ORSC, les serveurs racine ORSC utilisés dans l'installation par défaut de BIND-PE résoudront toutes les demandes vers un domaine de premier niveau (TLD) actuel. Il souligne qu'un FAI utilisant une mise en cache proxy transparente pourrait empêcher la résolution des requêtes vers des TLD améliorés pris en charge par ORSC, tels que .ocean. Malgré les dangers potentiels, une large distribution de DNS localisés peut rendre les attaques par déni de service contre les serveurs racine moins probables.

Paul Mockapetris, scientifique en chef chez Nominum Inc. et fondateur du système DNS, a récemment suggéré que les opérateurs DNS conservent une copie à jour des zones racines afin de s'isoler des futures attaques du serveur racine. Sexton souligne que si les zones racine locales étaient une pratique courante, les opérateurs DNS remarqueraient rarement des pannes de serveur racine. Un obstacle à cette approche est la perception qu'elle nécessite une expertise technique considérable.

Pour l'utilisateur d'ordinateur occasionnel, l'installation d'un DNS localisé semble être une expérience intimidante, et les mises à jour périodiques de la zone racine seraient probablement ignorées. La distribution BIND-PE, cependant, configure automatiquement le serveur pour qu'il s'exécute et inclut une configuration 'root-slave' pour que le DNS localisé agisse comme un esclave de serveur racine ORSC avec toutes les informations TLD nécessaires dans un fichier local.

De plus, le DNS localisé met automatiquement à jour les données de la zone racine. Cette configuration permet à l'utilisateur occasionnel d'avoir des miroirs personnels à jour des données du serveur racine sans un obstacle intimidant de configuration. Une telle approche pourrait également être adaptée pour les serveurs DNS des FAI ou des entreprises. L'approche racine-esclave permet aux opérateurs DNS d'éviter le risque de futures attaques de serveur racine et, si elle est mise en œuvre à grande échelle par des individus utilisant un DNS localisé ou d'autres opérateurs DNS, elle pourrait réduire la motivation pour de futures attaques de serveur racine.