Détection du pharming côté client vers un
remplacement du nom de domaine

Etude préalable sur les hypothèses de travail

Plusieurs pistes ont été étudiées avant d’aboutir aux deux approches décrites en sections 5.3 et 6.1, l’idée essentielle étant de trouver un moyen d’utiliser un serveur DNS et une page web dits de référence. Divers scénarios intermédiaires ont été envisagés pour la définition d’un serveur de référence. Toutefois, parce que ces scénarios impliquaient l’échange d’une adresse de référence entre le client et le FAI (ou une tierce partie), nous avons jugé préférable de les abandonner. De plus, ils restaient vulnérables à une corruption de l’adresse de référence en amont, dans la chaîne de résolution DNS. Nous avons également un temps envisagé une comparaison « délocalisée », réalisée en dehors du réseau client, tant pour la vérification de l’adresse IP que pour la comparaison de pages webs. Néanmoins, les résultats de notre étude préalable nous ont indiqué que cela s’avérait difficilement exploitable (cf. sections 5.2.1 et 5.2.2). Cette section s’intéresse donc à expliquer les études préalables réalisées, ainsi que les choix auxquels elles ont abouti dans la conception de notre approche. 5.2.1 Variabilité de l’adresse IP du domaine visité Un des fondements de notre approche repose sur la possibilité de vérifier l’adresse IP du site visité. Nous avons donc conduit un premier set d’expérimentations depuis 9 localisations géographiques réparties sur 5 continents (Amérique du Nord, Europe, Afrique, Asie et Australie). Pour chaque localisation, nous avons récupéré les adresses IP retournées par le serveur DNS par défaut ainsi que 2 serveurs DNS de référence (OpenDNS [ope] et GoogleDNS [gooa]), afin d’analyser les variations d’adresses IP des domaines visités. 5.2.1.1 Échantillon d’URLs Nous avons testé 226 domaines (plus exactement des FQDN) de sites webs HTTP, sélectionnés de la manière suivante : – 100 domaines issus des sites webs les plus populaires au niveau mondial1 , – 100 domaines issus des sites webs les plus populaires en France1 , – et 26 domaines issus de sites bancaires.

Variabilité IP entre localisations géographiques

 Les résultats de tests démontrent que, pour les domaines évalués, les adresses IP varient notablement selon la localisation, et ce quel que soit le serveur DNS interrogé. A titre d’exemple, le tableau 5.1 reprend quelques résultats retournés par OpenDNS depuis 4 localisations différentes. Nous constatons par exemple que pour Facebook, Apple et Comcast – malgré quelques similitudes -, il n’y a aucun recoupement d’adresses entre les 4 localisations. Tandis que pour Ask, Amazon et Commentcamarche, nous avons quelques recoupements d’adresses, entre la France et la Tunisie. En utilisant des FQDN plus précis (p.ex. images.google.fr, portail.free.fr, webmail.laposte.net, etc.), nous obtenons davantage de résultats partiellement convergents, entre les différentes localisations (cf. tableau 5.2). Toutefois, nous notons que des exceptions subsistent (p.ex. login.yahoo.com, news.bbc.co.uk).

Variabilité IP depuis une même localisation géographique 

Nous avons également évalué la staticité des adresses IP sur 4 localisations. Pour chacune d’entre elles, nous avons comparé – en local – les adresses IP retournées par le serveur DNS par défaut ainsi que celles retournées par nos 2 serveurs de référence (GoogleDNS et OpenDNS). Pour les FQDN génériques, selon la localisation étudiée et pour une même liste d’URLs, nous constatons une grande variabilité des résultats (cf. tableau 5.3) entre les adresses IP retournées par le DNS par défaut et les adresses IP de référence. Néanmoins, lorsque nous analysons les résultats portant sur les FQDN plus précis, nous constatons à nouveau une nette amélioration (c.-à-d. les adresses IP des serveurs DNS Défaut et Référence son plus convergentes).

Problématique des informations WHOIS 

Nous avons envisagé d’exploiter les données WHOIS en vue de vérifier l’identité des domaines visités. Néanmoins, plusieurs problèmes se posent : – La RFC 3912 qui définit le protocole WHOIS ne spécifie pas de norme concernant les données stockées. Elle n’indique pas non plus de spécification sur le formatage/contenu des réponses WHOIS, envoyées en mode texte. Chaque registrar fournit donc ce service dans le format qu’il désire, ce qui rend les données difficilement exploitables de manière automatisée. – On peut alors imaginer se focaliser sur les cc-TLD, qui sont généralement gérés par une même autorité gouvernementale imposant un format standard pour l’ensemble de ses domaines. Néanmoins, le service WHOIS n’étant pas dimensionné pour le traitement automatique, l’interrogation automatique s’avère difficile. En effet, lorsque nous avons essayé d’automatiser des requêtes WHOIS, nous constatons qu’après une dizaine de requêtes depuis une même machine, l’adresse IP source est bloquée. – Il n’y a pas non plus d’obligation de maintenir des informations WHOIS à jour. D’ailleurs, ces informations accessibles au public, posent des problèmes liés à la protection (au sens protection de la vie privée). De nombreuses données stockées sont donc obsolètes et peu fiables (En 2010, une étude de l’ICANN – menée sur 5 g-TLD et 1419 enregistrements – a montré que seulement 23% des domaines interrogés ont des données WHOIS à jour [atUoCfI10]). – Enfin, lorsqu’une entreprise utilise des services de GSLB (Global Server Load Balancing) pour une meilleure disponibilité, les informations retournées pour une adresse IP peuvent s’avérer fausses ou inexploitables pour l’identification d’un domaine. Considérons un exemple : Une interrogation DNS sur le FQDN www.bouyguestelecom.fr retourne les adresses IP 62.41.70.12 et 62.41.70.138. Une interrogation de la base WHOIS pour l’adresse IP 62.41.70.12 retourne des informations sur la société Akamai International. Il n’y alors aucun moyen de faire le lien entre l’entreprise BouyguesTelecom et la société Akamai, spécialisée dans la mise en cache de contenus web