web-dev-qa-db-fra.com

Comment un serveur DNS public pourrait-il renvoyer de mauvais résultats?

Je vis dans un pays soumis à de nombreuses sanctions. Des sanctions internes (gouvernement sur les personnes) et des sanctions externes (États-Unis sur nos populations).

Dans notre pays, YouTube, Twitter, Facebook et de nombreux autres sites sont bloqués par défaut et nous ne pouvons y accéder que via VPN.

Mais il y a une chose qui devrait fonctionner: DNS. Si je configure mon DNS sur 8.8.8.8, il devrait théoriquement renvoyer la bonne adresse IP pour www.youtube.com et cette adresse IP devrait être bloquée par le FAI.

Mais ce n'est pas. Il semble que notre gouvernement manipule les serveurs DNS, même publics.

J'ai Ubuntu 18.04 (Bionic Beaver) et j'ai désactivé Network Manager DNS. J'ai désactivé resolvconf et systemd-resolve, c'est-à-dire qu'aucune entité de mon propre système ne peut modifier le fichier /etc/resolv.conf.

J'ai changé le contenu de /etc/resolv.conf à:

nameserver 8.8.8.8

et seulement ce serveur de noms. Alors maintenant, chaque application utilise ce serveur par défaut, et elle devrait interroger ce serveur pour l'adresse IP des sites Web, mais malheureusement ce n'est pas le cas! 

kasra@ubuntu:~$ nslookup google.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   google.com
Address: 216.58.214.110
Name:   google.com
Address: 2a00:1450:4001:812::200e

kasra@ubuntu:~$ nslookup youtube.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup Twitter.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   Twitter.com
Address: 10.10.34.35
Name:   Twitter.com
Address: 10.10.34.35

kasra@ubuntu:~$ █

10.10.34.35 est l'adresse IP intranet de l'autorité de filtrage.

Comment le FAI y parvient-il? Sont-ils vraiment en train de voler et MITM-ing le trafic de 8.8.8.8? Est-ce une sorte de détournement BGP ?

Comment contourner cela sans VPN?

dnsspoofingdns-spoofing
38
AlwaysLearner

Comment parviennent-ils (FAI) à atteindre cet objectif? Volent-ils vraiment et MITT-ils le trafic du 8.8.8.8?

Ils redirigent probablement simplement tous les paquets avec le port de destination 53 (c'est-à-dire DNS) vers leurs propres serveurs et répondent eux-mêmes à la requête. Ce n'est pas si difficile à faire.

Comment contourner cela sans VPN?

Un VPN correctement configuré (c'est-à-dire aucune fuite DNS) peut contourner ce problème (sauf s'il bloque également le VPN). L'utilisation d'un proxy HTTP ou d'un proxy SOCKS peut également aider (assurez-vous de configurer la résolution de nom externe pour le dernier) pour le trafic HTTP et HTTPS. Et les techniques de confidentialité DNS comme dnscurve, dnscrypt, DNS sur TLS et DNS sur HTTPS ( déjà pris en charge par Firefox ) aideront également.

47
Steffen Ullrich

malheureusement ils ne le font pas !

Ils le sont faisant cela, et votre TypeScript le montre, avec nslookup interrogeant cette adresse IP et obtenant des réponses de celle-ci.

Votre confusion provient en partie d'une conception erronée de ce qu'est le 8.8.8.8. Il s'agit d'une adresse IP anycast. Le trafic qui lui est envoyé est acheminé vers les interfaces réseau de plusieurs machines à travers le monde, gérées par Google dans divers centres de données. Ce routage est effectué par chaque nœud auquel il est envoyé, y compris son propre FAI immédiatement après avoir quitté son ou ses propres réseaux.

Premièrement, Google lui-même peut faire en sorte que ces machines se comportent différemment selon les pays. Elle peut faire en sorte que les machines d'un pays répondent différemment des machines d'autres pays, si elle le décide ou si les autorités de ce pays l'exigent.

Deuxièmement, les serveurs DNS de contenu que Google Public DNS interroge depuis son serveur principal peuvent répondre différemment aux différentes machines Google. Leurs adresses IP dorsales et les pays auxquels elles correspondent sont publiées dans le cadre du doco Google Public DNS. Les serveurs DNS de contenu donnant des réponses différentes à différents clients (les clients étant ici les backends de la résolution des serveurs DNS proxy) en fonction de leurs adresses IP source est une fonctionnalité de plusieurs logiciels de serveur DNS.

Troisièmement, les FAI soumis à la juridiction d'un pays particulier peuvent être invités à acheminer simplement l'anycast vers d'autres machines sous le contrôle de quelqu'un d'autre que Google. Comme cela s'est produit en Turquie en 2014. Il a été affirmé que Taiwan avait des plans similaires.

L'Iran le faisait déjà un an avant la Turquie. Les FAI iraniens interceptent tout le trafic DNS/UDP acheminé par leur intermédiaire et y répondent à partir de machines sous contrôle iranien. Fait intéressant, cela semble ne pas être fait de manière très compétente, car des paquets factices TCP (sic!) Passent toujours par les machines d'origine.

(La même chose arrive au service 1.1.1.1 de Cloudflare, mais moins pour des raisons politiques et de censure et plus en raison de la paresse et de la folie humaines. Il a longtemps été utilisé comme une adresse IP de test ou comme une plage d'adresses IP extra-privée non officielle, par des personnes programmant routeurs et autres.)

Bien sûr, si l'on s'arrange pour que le trafic DNS quitte sa propre machine via le VPN plutôt que directement vers son FAI, alors ces trois changements. Le trafic est acheminé via le VPN vers une machine Google différente dans un pays différent, qui envoie ses requêtes dorsales à partir d'une adresse IP source différente, et qui n'est pas acheminée vers 8.8.8.8 par son FAI.

L'inconvénient d'apparaître comme si l'on était dans un pays différent pour le service DNS est d'apparaître comme si l'on était dans un pays différent, comme l'ont découvert les Australiens utilisant Google Public DNS en 2010. Les CDN en dirigent un vers des serveurs HTTP de contenu beaucoup plus éloignés et non locaux. Les services à faible coût ou gratuits mais uniquement dans son propre pays proviennent soudainement de serveurs HTTP à contenu coûteux.

Lectures complémentaires

20
JdeBP

En bref, vous êtes MITMed. Le censeur auquel vous êtes confronté fait quelque chose à vos demandes DNS dirigées vers 8.8.8.8 afin que vous obteniez des réponses non authentiques. Il existe de nombreuses façons d'y parvenir, et différentes entités exécutent cette censure par différents moyens. Pour regarder de plus près, utilisez votre outil de capture de paquets préféré (Wireshark ou tcpdump).

À titre de démonstration, j'ai pris une capture de moi interrogeant le serveur DNS de Google au 8.8.8.8 pour les adresses de "www.google.com".

Screenshot of nslookup

Screenshot of Wireshark

Comme le montre la capture d'écran de Wireshark, mon ordinateur envoie deux requêtes DNS au serveur DNS, une pour l'enregistrement A (adresses IPv4) et une pour l'enregistrement AAAA (adresses IPv6). Pour chaque demande, 3 réponses ont été reçues. Les deux premières réponses contiennent de fausses adresses et, fait intéressant, les deux premières réponses à la requête AAAA contiennent un enregistrement A dans la réponse - clairement une réponse mal formée. La troisième et dernière réponse de chaque demande contient la véritable adresse IP de www.google.com. L'outil nslookup, ne sachant pas mieux, a accepté la première réponse pour chaque requête et a affiché ces adresses.

Cela indique ce que fait ma censure nationale. Évidemment, ils ne bloquent pas purement et simplement le trafic réseau vers 8.8.8.8. Au lieu de cela, ils surveillent ce trafic et lorsqu'une demande DNS pour un domaine bloqué est trouvée, la censure injecte de fausses réponses. Le censeur ne peut pas être dérangé pour créer une réponse AAAA appropriée, d'où les réponses mal formées. Les réponses authentiques du vrai serveur DNS ne sont pas non plus abandonnées. Cependant, les premières fausses réponses sont suffisantes pour tromper le client qui a fait la demande DNS en acceptant de fausses adresses.

Votre censeur pourrait faire quelque chose de similaire, ou il pourrait faire quelque chose de complètement différent. Prenez quelques captures de paquets, et nous pourrons peut-être en dire plus.

Quant à savoir comment contourner ce problème, la réponse pratique est probablement un proxy DNS crypté local, tel que DNSCrypt Proxy ou Stubby . Ces outils exécutent un serveur DNS sur votre ordinateur et les demandes DNS qui leur sont adressées seront cryptées et envoyées à un serveur DNS qui comprend le protocole de cryptage. De cette façon, la censure ne peut pas savoir pour quel domaine la demande est destinée et ne peut pas forger de réponses. Cependant, la censure peut toujours bloquer ces serveurs.

(Si vous essayez de contourner une censure nationale, vaincre l'empoisonnement DNS à lui seul peut ne pas être suffisant. Vous devrez peut-être utiliser différents outils pour différentes occasions.)

13
twisteroid ambassador

Puisque vous utilisez Linux, un moyen simple de contourner cela sans VPN à part entière est le tunelling SSH. Si vous pouvez configurer ou obtenir un compte sur un serveur dans un emplacement neutre et non filtré, vous pouvez tunneler votre trafic via cet emplacement à l'aide de SSH avec seulement quelques commandes. Vous pouvez tunneler à la fois votre trafic DNS sur le port 53 et votre trafic Web via la machine distante.

Vous pouvez utiliser un service Web Amazon ou une instance de Google Compute Engine, ou juste un vps distant régulier.

https://www.ssh.com/ssh/tunneling/example#sec-What-Is-SSH-Port-Forwarding-aka-SSH-Tunneling

https://serverfault.com/questions/78351/can-i-create-ssh-to-tunnel-http-through-server-like-it-was-proxy

4
Cameron Roberts