Première rédaction de cet article le 8 janvier 2012
Dernière mise à jour le 9 janvier 2012
La sortie, le 30 décembre 2011, du décret n° 2011-2122 relatif aux modalités d'arrêt de l'accès à une activité d'offre de paris ou de jeux d'argent et de hasard en ligne non autorisée, décret qui permet à l'ARJEL de demander le blocage d'un site de paris ou de jeux en ligne, a ramené sur le devant de la scène la question du blocage via le DNS. En effet, le décret dit explicitement « Lorsque l'arrêt de l'accès à une offre de paris ou de jeux d'argent et de hasard en ligne non autorisée a été ordonné, [...] les [FAI] procèdent à cet arrêt en utilisant le protocole de blocage [sic] par nom de domaine (DNS) ». Il existe plusieurs façons de comprendre cette phrase. Si le FAI décide de mettre en œuvre cet arrêt en configurant ses résolveurs DNS pour mentir, un moyen simple de contourner cette censure sera alors pour les utilisateurs de changer de résolveur DNS. Est-ce simple ? Est-ce réaliste ? Des logiciels peuvent-ils aider ?
D'abord, un petit rappel de vocabulaire, car j'ai déjà lu pas mal
d'articles sur le sujet, où l'auteur est plein de bonne volonté et
veut vraiment aider les autres à contourner la censure, mais où il ne
connait pas vraiment le DNS et où il utilise un
vocabulaire approximatif, voire complètement faux. Il y a
deux sortes de serveurs DNS : la première, ce
sont les
serveurs faisant autorité, qui sont ceux qui
contiennent les données (par exemple, les serveurs de
DENIC ont la liste de tous les noms de domaine en
.de
, des serveurs de la société NS14
font autorité pour le domaine shr-project.org
, etc).
L'ARJEL ou un autre censeur ne peut pas
toujours agir sur eux car ils peuvent être situés en dehors de la
juridiction française.
Et il y a les résolveurs DNS. Ils ne connaissent au démarrage aucune donnée et servent uniquement de relais et de caches (stockage temporaire de données). Ils sont typiquement gérés par votre FAI ou bien par le service informatique de votre boîte. Ce sont eux qui sont indiqués à la machine cliente (en général par le protocole DHCP), qui les utilisera à chaque fois qu'elle aura une question (c'est-à-dire pas moins d'une centaine de fois pour la seule page d'accueil de CNN).
Si on veut censurer en France l'accès à un site de jeu en ligne, par le protocole DNS, c'est un bon endroit pour attaquer. Il en existe d'autres, mais que je garde pour d'autres articles. Modifier le comportement du résolveur est facile (les logiciels ont déjà ce qu'il faut pour cela) et certains FAI le faisaient déjà pour des raisons financières.
Mais c'est aussi une technique de censure relativement facile à contourner : l'utilisateur de la machine cliente peut changer la configuration de son système pour utiliser d'autres résolveurs que ceux de son FAI, par exemple ceux de Telecomix, qui promettent de ne pas censurer. C'est cette technique qui est discutée dans cet article.
Si vous lisez les forums un peu au hasard, vous trouverez souvent
des allusions à cette méthode, de la part de geeks
vantards qui affirment bien haut « rien à foutre de leur censure à la
con, je change mon DNS car je suis un top-eXpeRz et je surfe sans
filtrage ». La réalité est plus complexe. Prenons l'exemple d'une
machine Ubuntu (il y a peu près les mêmes
problèmes sur Windows ou
Mac OS X). La liste des résolveurs DNS utilisés figure dans le fichier /etc/resolv.conf
. Suffit-il
d'éditer ce fichier, comme on le lit souvent (et bien à tort) ?
forum.blaireaux.com/index.php
découvrira vite,
s'il essayait ce qu'il prêche, qu'éditer
resolv.conf
n'est pas la
bonne méthode, car le client DHCP effacera ses
modifications à la prochaine connexion. Il faut modifier la
configuration dudit client DHCP (cela varie énormément selon le
système et le logiciel installé ; sur ma
Debian, en ce moment, c'est
/etc/resolvconf/resolv.conf.d/head
).À noter que tous les cas ne peuvent pas être couverts dans un article. Par exemple, on peut aussi envisager de changer les réglages DNS sur la box si elle sert de relais DNS pour le réseau local vers les « vrais » résolveurs.
Pour résoudre tous ces problèmes, on peut écrire des documentations (exemples à la fin de cet article). Mais la plupart des utilisateurs auront du mal à les suivre et je pense donc que la bonne solution est la disponibiité d'un logiciel qui automatise tout cela. Quel serait le cahier des charges d'un tel logiciel ?
wikileaks.org
, etc) et tester les réponses des
résolveurs candidats. Ce n'est pas facile à faire car il faut aussi
connaître les bonnes réponses, et elles peuvent changer. Peut-être le
logiciel devrait-il interroger des résolveurs de confiance pour avoir
cette information ? Le fait de tester pourrait même permettre de
choisir automatiquement un résolveur, ce qui serait certainement
meilleur pour M. Toutlemonde.
Un tel logiciel est vulnérable à un blocage du port
53. Si cette mesure se répand, il faudra aussi que le logiciel
teste s'il peut atteindre des résolveurs publics et des serveurs faisant autorité, ou bien s'il
faut passer à d'autres méthodes comme de
tunneler le DNS sur TLS,
port 443, comme le permet déjà Unbound, dans sa
version de développement. D'autres attaques suivront alors (par
exemple des FAI qui annonceront les adresses
8.8.8.8
et 8.8.4.4
sur leur
propre réseau, pour se faire passer pour Google
Public DNS, profitant du fait que ce service n'est pas
authentifié).
Compte-tenu de ce cahier des charges, quels sont les logiciels qui conviennent aujourd'hui ? Il n'en existe aparemment qu'un seul, DNS Jumper (je ne suis pas sûr d'avoir mis un lien vers le site officiel, ce logiciel n'a pas de références bien précises et, son source n'étant pas distribué, on peut être inquiet de ce qu'il fait). DNS Jumper tourne sur Windows, assure les quatre premières fonctions de mon cahier des charges mais pas l'avant-dernière : il ne vérifie pas que le résolveur est digne de confiance. Il est décrit, par exemple, dans « Easily Switch Between 16 DNS Servers with DNS Jumper » (l'article est un peu ancien, le logiciel s'est perfectionné depuis), ou, en français, dans « DNS Jumper - Changez rapidement de serveurs DNS ».
Les autres logiciels restent à écrire (un truc comme DNS Helper ne compte pas, puisqu'il ne permet de changer... que pour les DNS de Google). Mais que les censeurs ne se réjouissent pas, les logiciels vont vite sortir, écrire un tel programme n'est pas un exploit technique, et la demande est forte, avec le décret ARJEL déja cité pour la France, SOPA pour les États-Unis, etc.
Sur le problème général de changer manuellement ses résolveurs DNS, un bon article est « How to Change DNS Server » de Remah (Windows seulement). Pour Mac OS, un bon article est « Disabling DNS servers from DHCP ».
Quelques petits détails techniques pour finir : on peut
parfaitement installer un serveur DNS résolveur sur sa propre
machine (enfin, sur un ordinateur portable, pas sur un
smartphone). La résolution DNS sera alors
entièrement sous le contrôle d'un logiciel qu'on gère, fournissant
ainsi le maximum de sécurité. Le processus
n'est pas très compliqué sur Unix, ni même sur
Windows (merci à Gils Gayraud et Mathieu Bouchonnet pour leur aide sur Windows). On peut le rendre encore plus simple avec des logiciels
astucieux comme dnssec-trigger, qui ne teste
pas la censure (son but est tout autre) mais pourrait servir de point
de départ à un paquetage simple d'installation, vraiment utilisable
par M. Toutlemonde (ce n'est pas encore le cas). Par contre, un tel
résolveur local a des conséquences négatives sur l'infrastructure du
DNS : comme il n'y a plus de cache partagé (avec le résolveur/cache du
FAI, une requête pour www.bortzmeyer.org
reste en
mémoire et bénéficie à tous les clients du FAI),
les serveurs faisant autorité verront leur charge s'accroître.
Pour éviter cet inconvénient, une des solutions serait pour le résolveur local de faire suivre les requêtes aux résolveurs du FAI (de tels résolveurs sont nommés forwarders). Mais cela implique de détecter lorsque le résolveur du FAI ment, pour le court-circuiter dans ce cas. DNSSEC fournit une piste intéressante pour cela mais, début 2012, les résolveurs ayant cette fonction forwarder (BIND et Unbound) n'ont pas de tel service de détection et de contournement.
Pire encore, on peut combiner le résolveur local (ou le remplacer)
avec des fichiers statiques locaux (/etc/hosts
sur Unix, C:\WINDOWS\system32\drivers\etc\hosts
sur Windows) mais la maintenance de tels fichiers serait un
cauchemar.
Cela ne veut pas dire que cela n'arrivera pas : dans ce maelstrom d'attaques et de contre-attaques, les solutions les plus mauvaises seront certainement déployées par certains acteurs et le futur est sombre pour le système de résolution de noms.
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)