Google lance son service DNS : une menace potentielle ?
Posted by Gutek in Réseaux, Sécurité, tags: vulnérabilité
Le géant du Web étend ses activités à l’ensemble d’Internet en devenant acteur de son fonctionnement aujourd’hui avec son nouveau service Google Public DNS de résolution de noms de domaine.
Le concept officiel est de participer à l’accélération du Réseau en proposant des serveurs DNS plus performants notamment au niveau de la mise à jour des nouveaux domaines (des centaines de sites se créent chaque jour, autant de noms de domaines migrent leur pointage vers de nouveaux serveurs). Officieusement on peut encore s’inquiéter de l’avancement de l’égémonie de Google sur l’Internet et de ce que la firme qui vit surtout de ses services marketing va pouvoir faire de la surveillance des requètes de navigation qui lui seront demandées : on l’a déjà dit dans un précédent article sur ce blog, Google à la caractéristique d’offrir à la fois des services performants et innovants mais il ne faut pas oublier quels sont ses buts avant tout. Etudier, décortiquer l’internaute, le cibler et ainsi proposer des études marketing ciblées à ses clients.
Actuellement il est en phase de test accessible à tous sur les serveurs primaires 8.8.8.8 (google-public-dns-a.google.com) et secondaires 8.8.4.4 (google-public-dns-b.google.com).
Dès lors il est intéressant de surveiller la configuration du service et la facon dont il est déployé.
La première chose qu’on peut constater c’est qu’au moment où les sites spécialisés propagent l’information les serveurs semblent supporter une charge conséquente et, loin de montrer une vitesse exceptionnelle, sont au contraire particulièrement lents. Bien entendu ceci devrait se régler en déploiement final.
Plus technique, ces serveurs ne présentent que le port 53 (DNS) d’accessible. Le reste est fortement surveillé par un système de filtrage performant dont la nature exacte échappe encore au moment de la rédaction de cet article.
Ils sont correctement positionnés au sein du réseau Google puisque la route qu’empruntent les requètes de l’utilisateur aboutit directement à eux une fois le backbone et l’océan nécessairement traversés (ces deux là sont quand même positionnés aux states). Normal pour un service DNS rapide.
Les services DNS sont vulnérables à plusieurs sortes d’attaques : transfert de zone, cache poisonning via la prévisibilté TXID/ port source (CVE-2008-1447), DoS par attaque d’amplification due à la récursion.
Une étude Nmap de ces vulnérabilités montre que les serveurs de Google sont protégés contre la plupart de ces vulnérabilités à l’exception de celles liées à la récursion : en effet, ils autorisent en l’état actuel l’interrogation tièrce-partie.
Comprenons rapidement l’idée : les serveurs DNS, ils y en a plein dans le monde. Ils travaillent chacun à un certain niveau de connaissance des relations IP/domaines étant donné que bien sûr aucun d’entre eux ne peut connaitre l’ensemble des centaines de millions de sites et de domaines associés. Tout en haut de la pile se trouve la famille des serveurs DNS “root”, dits authoritative. Ceux ci connaissent et interrogent ceux du niveau inférieur, spécialisés dans les Top Level Domains (les .com, .net et autres). A leur tour, ils interrogent les DNS spécialisés dans les grands domaines (par exemple Orange.fr, Hotmail.com etc…) qui, enfin, sont censés avoir connaissance du site recherché (foo.bar.perso.orange.com).
Habituellement un utilisateur interroge les DNS de son fournisseur d’accès et ceux ci relaient la requète à la chaine expliquée plus haut.
Pour éviter les problèmes, les serveurs accèptent des requètes et répondent à ce qui vient non pas de n’importe où, mais de domaines de confiance. Mais il arrive que certains d’entre eux dits “open recursive” accèptent de communiquer avec tout le monde, ce qu’on appelle la “tièrce partie” (ce n’est pas le serveur, ce n’est pas son domaine, c’est un troisième intervenant exterieur).
Or, le problème dont on parle, quel est il ?
Pour faire simple, il suffit de considérer qu’une requète DNS est quelque chose de très court, très léger. En revanche, une réponse DNS est beaucoup plus conséquente. Je demande peu, je recois beaucoup. Pour imager on pourrait dire que vous demandez où se trouve le restaurant A, et qu’on vous répond en vous expliquant que c’est dans tel arrondissement, telle rue, tel numéro, à coté du bar-tabac à droite après le feu rouge…
Maintenant imaginons qu’on utilise une technique de spoofing lors de notre requète. Ce faisant, on camoufle notre véritable adresse IP d’émission de la demande en la remplacant par celle d’une cible.
Le système DNS va répondre à celui qui semble être l’expéditeur de la demande : la cible, donc. Celle ci va donc recevoir une grosse réponse à une question qu’elle n’a pas posé.
Si on développe, on peut faire la même chose non pas avec une demande, mais avec une dizaine de milliers. Vous avez compris l’idée, la cible qui va recevoir tout ca risque d’en avoir vite marre : c’est le DoS potentiel.
On appelle ca un DoS par amplification parcequ’on génère artificiellement beaucoup de trafic à partir de peu de requètes.
Maintenant, il faut être honnète : Google n’est pas plus en faute qu’un autre la dedans parcequ’en réalité des DNS en open-recursion il en existe plein un peu partout bien que ce soit une mauvaise pratique.
La différence, c’est que Google est loin, dans un pays étranger. De ce fait, imaginons la situation dans laquelle c’est l’utilisateur qui est victime du DoS que nous venos de décrire : de ses logs de connexion il sait quel serveur DNS a relayé l’attaque. Traditionnellement si ses DNS primaires et secondaires sont ceux de son FAI il a toujours la possibilité de lui demander des comptes et de déterminer qui leur a envoyé initialement les requètes massives d’attaque.
En revanche si il fait confiance à Google il est probable qu’obtenir ces informations, réparation ou recours sera plus compliqué.
En attendant de plus amples études sur ce nouveau service il est conseillé de filtrer tout trafic DNS venant soit des serveur Google, soit de tous sauf de vos serveurs de confiance.
8.8.8.8
Not shown: 999 filtered ports, 697 open|filtered ports, 302 closed ports
PORT STATE SERVICE VERSION
53/tcp open tcpwrapped|_ dns-zone-transfer:53/udp open domain Netware dnsd|_ dns-recursion: Recursion appears to be enabled|_ dns-random-txid: ERROR: Server failure|_ dns-random-srcport: ERROR: Server failure
8.8.4.4
Not shown: 998 filtered ports, 891 open|filtered ports, 109 closed ports
PORT STATE SERVICE VERSION
53/tcp open tcpwrapped|_ dns-zone-transfer:53/udp open domain Netware dnsd|_ dns-recursion: Recursion appears to be enabled|_ dns-random-srcport: ERROR: Server failure|_ dns-random-txid: ERROR: Server failure
Entries (RSS)
Oui, je considère cela comme une menace potentielle concernant la vie privée de l’individu.