HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Articles > Why we must afraid by .COM and .NET wilcard DNS put by Verisign ?
Go to: HSC Trainings
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Why we must afraid by .COM and .NET wilcard DNS put by Verisign ?  
> Access to the content HTML Beginning of the article  
> Description Article about wilcard DNS put by Verisign on .COM and .NET domains.  
> Context & Dates Article of Alain Thivillon, also at Yahoo! News, quoted in an article on transfert.net on the same subject, and another on ZDnet about the CIGREF's reaction.
17 September 2003 
> Author Alain Thivillon  
> Type  
> Abstract &
Table of content
 
> Related documents
> Copyright © 2003, Hervé Schauer Consultants, all rights reserved.

 

Depuis le mardi 16 Septembre, Verisign Registry, qui gère les DNS des domaines .COM, .NET et quelques autres annexes, a installé un "WILDCARD DNS" pointant vers l'un de ses serveurs web.

Qu'est ce qu'un Wildcard DNS?

C'est un enregistrement DNS (nom de domaine internet) qui permet de répondre une valeur identique à toutes les questions. D'un point de vue utilisateur, cela revient à dire que depuis cette nuit, <NIMPORTEQUOI>.com existe et est dirigé sur le serveur Verisign http://sitefinder.verisign.com/.
Ceci n'est évidemment en place que pour les domaines qui n'existent pas (ou accessoirement et plus sournoisement, qui n'ont pas été payés à temps, ou qui ont été réservés et  "parqués" sans serveur DNS enregistré).

Quelles sont les conséquences immédiates?

Tout utilisateur faisant une erreur de domaine en tapant une URL dans son navigateur, telle que http://www.ma-socciete-dexemple.com/ au lieu de http://www.ma-societe-dexemple.com/, sera envoyé sur le serveur de Verisign.
Cela signifie aussi que tous les messages électroniques (e-mails) envoyés à une adresse dont la partie droite est erronée, telle que utilisateur@ma-socciete.com sera dirigé sur le serveur de Verisign (et refusé avec un message d'erreur en anglais).

Pourquoi font-ils ça?

Leur prétexte est que cela permet aux utilisateurs d'avoir une réponse plus précise que le sempiternel "This domain does not exist".

Pourquoi font-ils réellement ça?

Il y a plusieurs réponses, sans doute complémentaires:
Attirer des publicitaires sur un site qui va être accédé des millions de fois par jour. 
 Regarder quels sont les domaines les plus tapés en erreur, et vendre ces noms de domaines erronés aux propriétaires des domaines "voisins". 
 Se procurer une liste d'adresses e-mail valides afin de la revendre à des sociétés de marketing électronique (aka spammers).
 Tracer vos habitudes (cf. paragraphe suivant).

Pourquoi c'est mal? 

Là aussi, de multiples raisons: 
 Si vous vous trompez d'une seule lettre dans une URL, vous allez envoyer toute l'URL, ainsi que le Referer (l'endroit d'ou vous venez) à Verisign. Cette URL peut contenir des données très confidentielles, comme un mot de passe, une donnée d'identification, un numéro d'article...
 La page sur laquelle on arrive contient un webbug (image blanche 2 par 2) placé sur le site 2o7.net, qui envoie un cookie à votre navigateur. Cela signifie que ce site, affilié à Verisign, connaît toutes vos fautes de frappes et erreurs, et est capable d'en faire un historique.
 Le serveur de messagerie utilisé est complètement cassé, et ne suit pas le protocole SMTP. En particulier si un message est envoyé à plus de deux personnes, il va interrompre la transaction de telle manière qu'il restera plusieurs jours dans la file de votre serveur de messagerie.
 Le site http://sitefinder.verisign.com/ est complètement saturé et ne répond que très lentement. Vous ne vous rendez donc pas compte immédiatement que vous vous êtes trompés.
 Si les administrateurs de votre domaine ont installé un serveur de messagerie électronique qui envoie des messages en français quand le domaine est erroné, ce message n'est plus émis pour les domaines en .com et .net .
 Il y a probablement des traces de domaines ayant expiré ou disparu dans de nombreuses configurations de logiciel, domaines qui ont subitement réapparu depuis le 16 septembre. Il faut s'attendre à divers effets de bord très gênants.
 De nombreuses sociétés utilisent en interne des noms de domaines non officiels, qui existent désormais. Ainsi un PC qui cherchait http://www.masociete-interne.com/ dans le DNS avant de le rechercher dans un serveur Wins ou un fichier local, va désormais le trouver pointant vers une machine extérieure.
 Enfin, sur le plan juridique, Verisign semble être complètement en dehors de son contrat avec l'ICANN qui lui confie la gestion technique de .COM et .NET.

Que peut-on faire?

Tout dépend de votre infrastructure:
 Si vous êtes un utilisateur seul, vous pouvez commencer par bloquer la réception de cookies des sites verisign.com et 2o7.net.
 Vous pouvez mettre le site http://sitefinder.verisign.com/ dans votre fichier HOSTS (C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS) pointant sur 127.0.0.1, afin que votre navigateur n'aille pas de lui-même sur le site Verisign, mais soit plutôt redirigé vers votre machine elle même:
   127.0.0.1 sitefinder.verisign.com
 Si vous avez un relais HTTP sortant par lequel transitent vos utilisateurs, vous pouvez bloquer l'adresse 64.94.110.11 dans les sites autorisés. Il faut consulter la documentation de votre relais. Dans le relais squid, la séquence à utiliser est de type:
   acl verisign dst 64.94.110.11/255.255.255.255
   http_access deny verisign
   http_access allow <VOTRERESEAU>

 Vous pouvez également bloquer l'adresse via un filtrage IP en sortie, ou router la machine vers Null0 sur Cisco IOS:
ip route 64.94.110.11 255.255.255.255 Null0
À noter que cela bloquera les messages e-mails sortants, qui resteront en attente sur votre serveur de messagerie. Ce n'est donc pas forcément une solution idéale.
 Selon le type de votre serveur de messagerie, il peut exister des méthodes pour bloquer une adresse IP en sortie. Ce type de filtrage n'est malheureusement pas très répandu.
 Des "correctifs" sont en préparation pour le serveur DNS bind, qui rejettera toute réponse contenant 64.94.110.11 comme résultat.
 Vous pouvez écrire poliment à Verisign en leur expliquant que leur politique et leurs "Terms of Use" (http://sitefinder.verisign.com/terms.jsp) ne vous conviennent pas, et donc que vous ne pouvez pas utiliser leur système. Il faut donc que ce dernier ne vous permette pas d'utiliser leur moteur de recherche. C'est ce qu'ont commencé à faire de nombreuses personnes.
Il faut écrire à:

VeriSign, Inc.
Attention: Legal Department
21355 Ridgetop Circle
Dulles, VA 20166
États-Unis


Alain Thivillon, Hervé Schauer Consultants (www.hsc.fr)

Last modified on 6 November 2007 at 17:57:32 CET - webmaster@hsc.fr
Information on this server - © 1989-2013 Hervé Schauer Consultants