Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

Google détourné par Orange vers la place Beauvau

Première rédaction de cet article le 17 octobre 2016


Aujourd'hui, bien des clients d'Orange ont eu la mauvaise surprise de ne pas pouvoir visiter Google. La plupart n'avaient pas de messages d'erreur précis, juste une longue attente et un message d'erreur vague du genre « timeout ». Certains avaient la désagréable surprise de voir apparaitre une page menaçante, les accusant d'avoir voulu se connecter à un site Web terroriste. À l'origine de ce problème, une erreur de configuration dans les résolveurs DNS d'Orange, en raison de la fonction de censure administrative du Web.

D'abord, voyons l'étendue du problème. Il n'affectait que les clients d'Orange, et seulement ceux qui utilisaient les résolveurs DNS de l'opérateur (voir plus loin pour une définition des termes techniques). Les sites inaccessibles incluaient http://www.google.fr/, mais aussi http://fr.wikipedia.org/, http://www.ovh.com/ et quelques autres. Beaucoup d'utilisateurs ont imputé le problème à Google à tort (mot-croisillon #GoogleDown sur Twitter, ce qui était complètement erroné).

Il est rapidement apparu que le problème venait du DNS. Ce système permet d'associer à un nom de domaine (comme www.afnic.fr ou youtube.com) des données techniques, comme l'adresse IP de la machine serveuse. Cette adresse IP est indispensable au bon fonctionnement de l'Internet. Résoudre (traduire) un nom de domaine en adresse IP est le travail de deux sortes de serveurs DNS : les serveurs faisant autorité, qui connaissent le contenu d'une partie du DNS (par exemple, les serveurs faisant autorité gérés par l'AFNIC connaissent le contenu de .fr, les serveurs faisant autorité pour cfeditions.com connaissent le contenu de cfeditions.com, etc), et les résolveurs. Ces derniers ne connaissent rien mais, demandant aux serveurs faisant autorité, et mémorisant leur réponse (ce que les informaticiens appellent, bizarrement, « cacher »), ils obtiennent l'information qu'ils distribuent aux utilisateurs. Les résolveurs sont typiquement gérés par les FAI (comme Orange) mais il existe aussi des serveurs publics comme ceux de FDN. L'utilisateur de l'Internet n'a en général pas à s'en soucier, son FAI lui indique automatiquement ses résolveurs et tout roule.

Normalement, donc, un résolveur n'a pas de données propres et se contente de relayer entre l'utilisateur et le serveur faisant autorité. Mais, comme quasiment toute communication Internet commence par une requête DNS, il est tentant, lorsqu'on souhaite contrôler l'usage de l'Internet, de demander aux résolveurs de mentir, c'est-à-dire de donner une information qui n'est pas celle venue du serveur faisant autorité. C'est ce qui est prévu en France en application du décret n° 2015-125 du 5 février 2015. Le Ministère de l'Intérieur envoie aux principaux FAI une liste des domaines à bloquer (un article de Numérama détaille ce processus) et ceux-ci déploient la configuration nécessaire dans leurs résolveurs.

Mais, ce lundi matin, lorsqu'on interrogeait les résolveurs d'Orange au sujet de l'adresse IP de www.google.fr, au lieu de répondre avec l'adresse contenue dans les serveurs faisant autorité pour google.fr (serveurs gérés par Google), par exemple 216.58.211.99, ils répondaient 90.85.16.52, une adresse appartenant à un sous-traitant du Ministère de l'Intérieur. Lorsqu'un navigateur Web se connecte à cette adresse, il obtient normalement une page l'avertissant que le nom de domaine fait partie de ceux qui sont bloqués, et un motif est indiqué (promotion du terrorisme, par exemple, comme dans l'image ci-dessus).

Mais ce serveur était bien trop faible pour encaisser l'énorme trafic de Google et de Wikipédia, et a vite cessé de fonctionner correctement. C'est ce qui explique l'absence de réponse fréquemment rencontrée, faisant croire aux utilisateurs que Google était en panne. (Une autre raison est que la plupart des accès à Google se font désormais en HTTPS et que le serveur du Ministère ne gère pas HTTPS, ne répondant pas, même pas par un refus de connexion.)

Comment une telle bavure a pu se produire ? L'erreur était-elle dans la liste envoyée par le Ministère de l'Intérieur ou bien uniquement chez Orange ? On n'a évidemment pas d'information à ce sujet (les pannes Internet ne font jamais l'objet d'analyses indépendantes et publiques, ce qui explique que la sécurité ne progresse guère). Tout est possible, y compris des erreurs humaines qui sembleraient invraisemblables (mais on voit vraiment de tout dans le monde réel). Une des hypothèses les plus intéressantes (elle explique notamment pourquoi il y a eu plusieurs noms touchés) est celle d'un fichier de test installé par erreur à la place du « bon ».

Au fait, comment sait-on que les clients d'Orange (et uniquement eux) recevaient cette fausse information ? En effet, dans l'Internet d'aujourd'hui, complexe et international, une observation faite en un point n'est pas suffisante. Les clients d'Orange peuvent s'exclamer en chœur « Google est planté » et ceux de Free répondre « non, tout va bien ici ». Et les deux groupes ont raison... de leur point de vue. J'ai utilisé, outre les mesures faites par des experts chez différents FAI (merci, merci, merci), le réseau des sondes RIPE Atlas. Ces petits boitiers très utiles permettent de mesurer un certain nombre d'indicateurs techniques depuis de nombreux points du réseau. (Des détails pour les techniciens figurent à la fin de cet article.)

La panne elle-même, c'est-à-dire l'envoi de fausses informations par les résolveurs DNS d'Orange, a duré environ une heure. Mais son effet avait été prolongé par la mémorisation (les fameux « caches ») des informations dans certains composants du réseau (par exemple la « box » chez l'utilisateur). Cela fait que, plusieurs heures après, Google ou Wikipédia étaient toujours inaccessibles pour certains utilisateurs.

Les leçons à en tirer ? Le DNS est un composant critique de l'Internet et sa résilience, sa capacité à résister aux pannes et à repartir ensuite, est donc cruciale. D'où l'importance de l'Observatoire de la résilience Internet. Toute interférence avec le fonctionnement du DNS, que ce soit pour des raisons politiques ou autres, le met potentiellement en péril. C'est ce qu'avait analysé le rapport du Conseil Scientifique de l'AFNIC « Conséquences du filtrage Internet par le DNS », qui mettait bien en évidence le risque de tels filtrages ou blocages. Une bavure analogue à celle de Google était déjà arrivée au Danemark mais il semble que personne ne tire de leçons de l'expérience.

Que peuvent faire les utilisateurs face à de tels risques ? Le problème de fond est bien évidemment politique (la censure administrative, effectuée au mépris des contraintes opérationnelles) et doit donc être traité politiquement. Mais existe-t-il des solutions techniques ? Pour l'instant, la meilleure est d'avoir son propre résolveur DNS. Notez bien que je ne parle pas forcément d'un résolveur par machine à la maison. Cela peut être fait dans un équipement partagé, comme ce que permet le routeur Turris Omnia. Beaucoup de gens proposaient d'utiliser un résolveur DNS public. Ce n'est pas forcément une bonne solution. Google Public DNS a tous les inconvénients des services Google (bien expliqués dans le récent livre de Tristan Nitot). Cisco OpenDNS y ajoute le fait qu'il s'agit d'un résolveur menteur, comme ceux des principaux FAI français. Ceux d'OpenNIC marchent rarement et, de toute façon, sont une racine alternative, avec les inconvénients que cela présente. Et les résolveurs de FDN ? Ils sont honnêtes mais ils partagent un inconvénient commun avec presque tous les résolveurs DNS publics : ils n'offrent aucune authentification et rien ne garantit donc qu'on parle bien au résolveur qu'on veut. (C'est ainsi que Google Public DNS a déjà été détourné.)

Quelques lectures sur cet incident :

Le reste de cet article est uniquement pour les techniciens, attention. Le script utilisé pour interroger les sondes Atlas est décrit ici. La commande exacte était atlas-resolve --as 3215 --requested 100 www.google.fr, l'AS 3215 étant celui d'Orange.

La panne semble avoir duré d'environ 07:40 UTC à 08:35. Un utilisateur d'Orange qui testait avec dig voyait :

% dig A +short @192.168.10.1 www.google.fr
90.85.16.52

% dig A +short @8.8.8.8 www.google.fr
172.217.20.35
  

Les sondes Atlas, elles, voyaient :

% atlas-resolve --as 3215 -r 100 www.google.fr
[74.125.24.94] : 1 occurrences
[216.58.208.195] : 2 occurrences
[74.125.206.94] : 2 occurrences
[216.58.210.35] : 2 occurrences
[216.58.210.227] : 3 occurrences
[216.58.211.67] : 3 occurrences
[172.217.16.67] : 2 occurrences
[216.58.213.35] : 1 occurrences
[216.58.211.99] : 2 occurrences
[172.217.18.227] : 2 occurrences
[216.58.204.3] : 1 occurrences
[90.85.16.52] : 75 occurrences
[216.58.208.227] : 2 occurrences
Test #6886264 done at 2016-10-17T08:06:14Z
  

Remarquez que certaines sondes, minoritaires, voient la vraie valeur, sans doute parce que le réseau où elles sont situées n'utilise pas les résolveurs DNS d'Orange. Mais la grande majorité voit le 90.85.16.52 mensonger. Un autre exemple avec les sondes Atlas, mais en leur demandant d'utiliser un autre résolveur (Google Public DNS) :

 % atlas-resolve --as 3215 -r 100 -e 8.8.4.4 www.google.fr
Nameserver 8.8.4.4
[172.217.18.227] : 3 occurrences
[216.58.219.67] : 1 occurrences
[172.217.23.67] : 1 occurrences
[216.58.210.3] : 1 occurrences
[216.58.211.67] : 8 occurrences
[172.217.16.67] : 3 occurrences
[216.58.210.163] : 1 occurrences
[172.217.16.163] : 2 occurrences
[172.217.19.131] : 8 occurrences
[216.58.201.35] : 4 occurrences
[74.125.206.94] : 4 occurrences
[216.58.213.99] : 1 occurrences
[172.217.23.99] : 1 occurrences
[172.217.20.35] : 5 occurrences
[216.58.208.227] : 10 occurrences
[216.58.210.131] : 1 occurrences
[216.58.204.67] : 2 occurrences
[216.58.211.99] : 11 occurrences
[216.58.210.227] : 8 occurrences
[216.58.212.99] : 2 occurrences
[172.217.23.3] : 1 occurrences
[216.58.204.3] : 1 occurrences
[216.58.208.163] : 1 occurrences
[216.58.210.195] : 6 occurrences
[216.58.192.99] : 1 occurrences
[216.58.208.195] : 10 occurrences
Test #6886273 done at 2016-10-17T08:13:06Z
  

Cette fois, personne ne voit le mensonge (notez que les serveurs DNS de Google servent des réponses très différentes, mais qui sont toutes dans un réseau Google). Notez aussi que d'autres services Google comme Gmail ou comme le spyware Analytics n'avaient aucun problème.

Wikipédia faisait partie des victimes, comme Google :

% atlas-resolve --as 3215 -r 100 fr.wikipedia.org
[91.198.174.192] : 21 occurrences
[90.85.16.52] : 73 occurrences
[208.80.154.224] : 1 occurrences
Test #6886283 done at 2016-10-17T08:22:22Z
  

Merci à tou·te·s c·eux·elles qui m'ont envoyé des informations et des résultats de mesure. Ça, c'est l'Internet, la coopération, l'échange d'informations et la décentralisation.

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)