Passer au contenu

Routeur portable et confidentialité : ajouter DNS-over-TLS à OpenWRT (LEDE) avec Unbound

Nous partageons aujourd'hui un guide détaillé rédigé par Junade Ali pour configurer DNS-over-TLS sur le GL-AR750. Si vous découvrez cette technologie, voici d'abord quelques explications.

Un fournisseur d'accès indiscret peut analyser vos activités en ligne et vendre ces données à des annonceurs. DNS-over-TLS est un outil de sécurité qui contribue à protéger la confidentialité de votre navigation. Il chiffre vos requêtes DNS et aide à empêcher l'écoute et la manipulation des réponses DNS lors d'attaques de l'homme du milieu.


Si vous souhaitez aller directement aux instructions, passez à la section suivante. Mais, comme une négociation TLS, j'aime donner des détails : voici une introduction.

Imaginez que je sois au restaurant et que je doive passer un appel privé, mais que la batterie de mon téléphone soit vide. J'emprunte celui d'un ami, compose le numéro et sors pour préserver la confidentialité de la conversation. Une fois l'appel terminé, je reviens lui rendre son téléphone.

Le téléphone n'enregistre pas nécessairement la conversation, mais il conserve la liste des numéros récemment composés. Mon ami pourrait donc voir qui j'ai appelé, même sans connaître le sujet de notre échange.

Savoir qui vous avez appelé peut parfois en révéler beaucoup : un appel à une ligne d'aide psychologique ou à un organisme de recouvrement permettrait de déduire la nature probable de la conversation.

Sur Internet, nous utilisons le chiffrement pour protéger nos échanges. Lorsque vous ouvrez un site en HTTPS, le cadenas du navigateur indique que la connexion est chiffrée : une personne interposée entre vous et le serveur aurait beaucoup de mal à lire son contenu.

J'ai déjà expliqué qu'il est parfois possible de contourner ce chiffrement et présenté les moyens dont disposent les sites pour s'en prémunir. Mais un problème encore plus fondamental menace la confidentialité en ligne.

Avant que votre navigateur n'établisse une connexion HTTP avec un site, par exemple cloudflare.com, il doit interroger le DNS pour trouver son adresse IP. Il en va de même pour les autres protocoles applicatifs lorsque vous utilisez un nom d'hôte plutôt qu'une adresse IP. Notre centre d'apprentissage propose une introduction au DNS.

Schéma de résolution DNS

Le chiffrement HTTP existe depuis longtemps, mais sa normalisation pour le DNS est beaucoup plus récente. Si vous ne savez pas si votre trafic DNS est chiffré, il ne l'est probablement pas.

Ainsi, même lorsque vous consultez un site HTTPS, une personne capable d'intercepter votre connexion peut voir le site recherché et, selon ses protections, manipuler la réponse pour vous diriger vers un autre serveur.

Cela intéresse les indiscrets : l'opérateur d'un point d'accès Wi-Fi gratuit qui vend des données aux annonceurs comme un pirate qui intercepte le trafic réseau depuis son café.

En passant au résolveur DNS de Cloudflare, vous pouvez bénéficier d'une navigation plus rapide tout en évitant que l'opérateur de ce résolveur vende vos données à des annonceurs. Le résolveur Cloudflare prend en charge DNS-over-HTTPS et DNS-over-TLS, mais il faut parfois effectuer une configuration supplémentaire, comme activer un client DNS-over-HTTPS, pour chiffrer la connexion entre vous et lui.

Cet article explique comment configurer un routeur OpenWRT pour chiffrer le trafic sortant vers le résolveur Cloudflare. C'est utile pour protéger les appareils domestiques qui ne prennent pas eux-mêmes en charge le DNS chiffré, comme un téléviseur ou un appareil IoT. Certains clients peuvent ignorer explicitement le résolveur local du routeur, mais beaucoup l'utilisent par défaut.

OpenWRT (LEDE)

IMG-3335-1

Le week-end précédant la rédaction de cet article, j'ai commandé un routeur sans fil GL.iNet GL-AR750. Ce « routeur de voyage » très compact peut servir de répéteur ou de routeur Wi-Fi classique. Son côté le plus long mesure à peu près la longueur de mon index :

IMG-3360

Son format n'est pas la seule raison de mon choix. Il est livré avec OpenWRT, un système d'exploitation embarqué basé sur Linux, adapté aux routeurs. En mai 2016, le projet OpenWRT a donné naissance à LEDE (Linux Embedded Development Environment), avant la réunification des deux projets en janvier 2018.

Si LEDE n'est pas préinstallé sur votre routeur, vous pouvez suivre ce guide avec un autre modèle compatible avec le firmware OpenWRT. Consultez la liste des appareils pris en charge par OpenWRT, en gardant à l'esprit que l'installation comporte des risques selon l'appareil.

Prise en charge de DNS-over-TLS (ou son absence)

Mon routeur permet de définir un résolveur DNS en amont pour les requêtes absentes de son cache interne. Ce résolveur local est ensuite proposé aux clients connectés au routeur.

Pour l'essai, je peux définir dans l'interface web 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 et 2606:4700:4700::1001 comme serveurs DNS en amont (en adaptant les adresses IPv6 si le réseau ne les prend pas en charge) :

Screen-Shot-2018-04-09-at-13.15.07

En reliant le port WAN du routeur à mon ordinateur, je peux analyser le trafic sortant avec Wireshark. Une requête DNS absente du cache est transmise à 1.1.1.1. Comme le routeur l'envoie sans chiffrement au lieu d'utiliser DNS-over-TLS, je peux lire les requêtes qui circulent :

DNS non chiffré

Le résolveur Cloudflare prend en charge DNS-over-TLS, mais pas ce routeur dans sa configuration actuelle : ses requêtes restent donc non chiffrées.

Configurer DNS-over-TLS

LEDE utilise Dnsmasq comme résolveur interne par défaut, sans prise en charge de DNS-over-TLS. Pour chiffrer les requêtes, nous allons le remplacer par Unbound et odhcpd. Cette procédure s'appuie sur la documentation du paquet Unbound pour OpenWRT.

Commencez par vous connecter au routeur en SSH. Si un mot de passe est demandé, il s'agit probablement de celui défini pour l'interface web :

Screen-Shot-2018-04-09-at-13.06.26

LEDE utilise opkg​ comme gestionnaire de paquets. Mettez à jour la liste des paquets, puis installez Unbound, Unbound-Control et la version complète d'odhcpd :

opkg update
opkg install unbound odhcpd unbound-control
opkg remove dnsmasq

Vous pouvez aussi installer l'application LuCI pour Unbound si vous souhaitez le gérer depuis l'interface standard.

opkg install luci-app-unbound

Mon routeur n'utilise pas une version standard de LEDE : installer ce module ne modifierait donc pas son interface. Je ne l'ai pas testé.

Une fois Unbound installé, configurez-le pour utiliser 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 et 2606:4700:4700::1001 comme résolveurs DNS avec chiffrement TLS. J'ai ajouté la configuration suivante à /etc/unbound/unbound_ext.conf avec Vim :

forward-zone:
  name: "."
  forward-addr: 1.1.1.1@853
  forward-addr: 1.0.0.1@853
  forward-addr: 2606:4700:4700::1111@853
  forward-addr: 2606:4700:4700::1001@853
  forward-ssl-upstream: yes

Dans le fichier /etc/config/unbound, j'ai ajouté les paramètres requis par la documentation du paquet. J'ai sauvegardé le fichier existant, puis utilisé la configuration suivante :

config unbound
  option add_local_fqdn '1'
  option add_wan_fqdn '1'
  option dhcp_link 'odhcpd'
  option dhcp4_slaac6 '1'
  option domain 'lan'
  option domain_type 'static'
  option listen_port '53'
  option rebind_protection '1'
  option unbound_control '1'

Si votre fichier contient d'autres paramètres, vérifiez qu'ils ne remplacent pas ceux-ci, en particulier unbound_control.

J'ai également fusionné les paramètres suivants dans /etc/config/dhcp, sans modifier certaines entrées existantes :

config dhcp 'lan'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option interface 'lan'
        option leasetime '12h'
        option ra 'server'
        option ra_management '1'

config odhcpd 'odhcpd'
        option maindhcp '1'
        option leasefile '/var/lib/odhcpd/dhcp.leases'
        option leasetrigger '/usr/lib/unbound/odhcpd.sh'

Enfin, activez le démarrage automatique d'Unbound et lancez-le :

service unbound enable
service unbound start

Vérifions le résultat : si nous interceptons les requêtes DNS entre le routeur et Internet, nous constatons qu'elles sont chiffrées avec TLS v1.2 :

DNS non chiffré

Conclusion

Chiffrer le trafic DNS contribue à préserver la confidentialité de la navigation. En remplaçant Dnsmasq par Unbound, OpenWRT peut utiliser DNS-over-TLS pour chiffrer les requêtes DNS.


Merci à Junade Ali de nous avoir autorisés à publier cet article sur notre site. Il a d'abord été publié sur le site de Cloudflare le 9 avril 2018 : https://blog.cloudflare.com/dns-over-tls-for-openwrt/

À propos de GL.iNet

Fondée en 2010, GL.iNet est un fournisseur de premier plan de routeurs innovants et de solutions réseau. Des routeurs de voyage compacts aux solutions KVM à distance de pointe, GL.iNet propose des technologies réseau primées, conçues pour la performance et la sécurité.

GL.iNet donne aux particuliers et aux organisations les moyens de se connecter en toute confiance. En laissant le contrôle aux utilisateurs, GL.iNet favorise la productivité et la collaboration qui contribuent à une Good Life.

Article précédent MiFi à énergie solaire : voyagez en sécurité et de façon plus écologique
Article suivant Première participation de GL.iNet au CeBit 2018

Comparer les produits

{"one"=>"Sélectionnez 2 ou 3 articles à comparer", "other"=>"{{ count }} éléments sélectionnés sur 3"}

Sélectionnez le premier élément à comparer

Sélectionnez le deuxième élément à comparer

Sélectionnez le troisième élément à comparer

Comparer