IP over DNS : Contourner les limitations des hotspots
Vous êtes dans une gare, un hôtel ou un aéroport. Celui-ci est équipé en hotspots WiFi mais dès que vous vous connectez ils essayent de vous sous-tirer plus de 10€ pour une petite heure de connexion, ce qui est totalement aberrant vu les coûts de déploiement actuels.
Là, vous avez deux solutions : payer (ce qui peut vite devenir cher si vous passer plus d’une semaine à l’hôtel) ou contourner les limitations. Vous vous rendrez vite compte que, même avant d’avoir payé, tous les hotspots résolvent les DNS… et il ne vous aura pas échappé qu’une résolution de DNS est un échange de données!
Le port UDP 53
Pour faciliter la configuration de ces hotspots, de nombreux administrateurs n’hésitent pas à tout simplement ouvrir le port DNS, c’est-à-dire le port UDP 53. Une solution simple pour accéder à internet serait donc d’avoir un serveur VPN sur ce port.
Malheureusement on tombe souvent sur des hotspots bien configurés, qui n’autorisent du trafic que vers leur propre serveur DNS. Pourtant, vous avez remarqué qu’un
vous a retourné la bonne adresse IP (81.93.247.142 actuellement) et non une adresse IP du hotspot. Vous venez de communiquer avec l’internet!
Échange de données over DNS
L’idée est donc simple : traduire vos “requêtes IP” en requêtes DNS. Un faux serveur DNS va comprendre ces requêtes, les exécuter et retourner la “réponse IP” en réponse DNS! Ce détournement du système DNS est réalisable grâce à NSTX, ou Name Service Transfer Procotol qui crée un véritable tunnel IP entre votre laptop et votre serveur, grâce aux requêtes DNS.
Par exemple vous essayez de vous connecter à Geekfault.
- Firefox génère une requête HTTP vers geekfault.org
- Celle-ci est interceptée par le client NSTX tournant sur le laptop. Il génère une requête vers le domaine KJhjh33.dd_2sT-XXT.dAAoi_f.tunnel.example.com
- Le NSTX tournant sur le serveur reçoit cette requête DNS et décode le KJhjh33.dd_2sT-XXT.dAAoi_f en “requête HTTP vers geekfault.org”
- Le serveur se connecte alors à geekfault.org et récupère son contenu
- Le contenu récupéré est encodé de la même manière et transmis vers votre laptop en tant que réponse DNS TXT
- Le NSTX tournant sur le laptop décode les données, reformant les paquets IP
- Firefox reçoit les données HTTP, Geekfault.org s’affiche 🙂
Mise en place du serveur
Attention il est important que votre vrai serveur DNS et votre serveur NSTX soient sur deux machines différentes, ou au moins sur deux IP différentes. En effet, il faut qu’un vrai serveur DNS fasse pointer le sous-domaine tunnel.example.com vers NSTX. Pour cela, ajoutez à la fin de votre zone DNS
@ IN NS ns.tunnel.example.com.
ns IN A 1.2.3.4
où example.com est votre domaine et 1.2.3.4 est l’IP du serveur où vous installerez NSTX.
Vérifiez que votre kernel est compilé avec le “Universal TUN/TAP device driver support” (dans Network device support) . Installez NSTX, disponible en package pour de nombreuses distributions.
Et il ne reste plus qu’à créer le tunnel côté serveur:
# nstxd -i 1.2.3.4 tunnel.example.com
# ifconfig tun0 up 172.16.42.1 netmask 255.255.255.0
# iptables -t nat -A POSTROUTING -s 172.16.42.2 -o eth0 -j SNAT
Le client sur le laptop
De la même manière, vérifiez que vous avez le support TUN/TAP dans le kernel et installez NSTX.
Récupérez l’adresse IP du serveur DNS fourni par DHCP (dans /etc/resolv.conf) ainsi que l’adresse IP du routeur (dans route). On crée alors l’autre bout du tunnel et on route le trafic approprié dans celui-ci:
# nstxcd tunnel.example.com <IP_serveur_DNS_filtrant>
# ifconfig tun0 up 172.16.42.2 netmask 255.255.255.0
# route del default
# route add -host <IP_serveur_DNS_filtrant> gw <IP_routeur_filtrant> dev <interface_réseau>
# route add default gw 172.16.42.1 tun0
Performances
Vous devriez maintenant être capable de surfer sur le web. Selon le serveur DNS du fournisseur, vous pouvez espérer entre 10 et 60ko/s. Malheureusement les fortes latences de toutes les requêtes empêchent l’utilisation de plusieurs services, dont le SSH. Mais, hé, vous accédez à internet sans vous défaire de 10€ 😉
Vous aurez aussi sans doute compris que nous sommes là au bord de la légalité : on exploite en quelque sorte une faille dans le système de hotspot. À utiliser avec précaution et parcimonie.
“Pour faciliter la configuration de ces hotspots, de nombreux administrateurs n’hésitent pas à tout simplement ouvrir le port DNS, c’est-à-dire le port UDP 53.”
Plus précisément, c’est pour en faciliter l’utilisation. Si le hotspot proposait un DNS menteur (comme le font les mauvais FAI), les utilisateurs se verraient dans le cas suivant:
– ils demandent “geekfault.org”,
– le hotspot leur répond, par exemple, “192.168.0.1” (adresse de l’interface du hotspot),
– ils renseignent le login et le mot de passe leur permettant de surfer,
– ils redemandent “geekfault.org” et.. ho surprise! Leur OS a gardé en cache la mauvaise adresse et les renvoie vers le portail.
Le cache DNS dure 5 longues minutes sur l’OS le plus utilisé, on imagine que les utilisateurs lambda laisseraient tomber très vite.
C’est donc non pas pour faciliter la configuration du hotspot, mais pour éviter de demander aux utilisateurs de vider leur cache DNS, que les administrateurs laissent le DNS passer.
@Grunt La résolution DNS et le fait de laisser passer le port 53 n’ont rien à voir.
Il est bien évident que les administrateurs sont presques obligés de réellement résoudre les DNS pour les raisons que tu expliques… C’est d’ailleurs ça qui est exploité par NSTX!
En fait ils envoient à la place une fausse redirection HTTP (sans doute avec un expire dans le passé pour éviter le cache du navigateur) vers leur page de login, en aucun cas ils ne renvoient une fausse réponse DNS.
Ma phrase est peut-être mal exprimée mais elle voulait dire que sur certains hotspots le traffic sur le port UDP 53 est entièrement libre, alors que sur la plupart il ne permet du traffic que vers le serveur DNS du hotspot.
Bjr,
Est-il possible d’avoir les lignes de commande pour Windows, svp ?
Merci
Ce n’est pas compatible Windows, désolé
L’ IP_serveur_DNS_filtrant c’est l’ip du serveur dns du hotspot? et L’IP_routeur_filtrant c’est l’ip du routeur du hotspot ?
C’est bien ça où je me trompe ?
(le message précédent a eu un pti bug dsl)
Oui c’est bien les adresses IP du hotspot 😉
J’ai quelques soucis, une fois qu’on a créer un serveur dns en local, comment faire pour qu’il soit accessible sur le net ? Il faut déclarer le nom de domaine et payer ?
Oui il te faudra un nom de domaine lié à ce serveur, ne serait-ce qu’un DynDNS pour que *.ton.domaine.com soit résolu par NSTX
Je n’arrive pas a faire le sous domaine 🙁
moi@root: nslookup moi
Server: 192.168.1.10
Address: 192.168.1.10#53
Name: moi1.moi.home.com
Address: 192.168.1.11
moi@root: nslookup tunnel
Server: 192.168.1.10
Address: 192.168.1.10#53
** server can’t find tunnel: NXDOMAIN
mon fichier conf :
moi.home.com. IN NS ns.moi.home.com.
moi1 IN A 192.168.1.11
ns IN A 192.168.1.10
$ORIGIN tunnel.moi.home.com.
@ IN NS ns.tunnel.moi.home.com.
ns IN A 172.16.204.128
Ta conf m’a l’air correcte, je ne sais pas plus t’aider que ça
salut tout le monde!
est ce que se serais possible de faire un tuto sur ce topic svp
parce que en réseau et protocole je mis connais pas du tout
et tout les trucs que vous proposer j’y comprend rien
sa serais cool genre de faire des screen
le truc en faite c’est que je suis chez moi connecté en hotspot et sa me fait ch*** parce que le temps de réponse est trop long et j’aimerais bien jouer a Css ^^
merci
Cette méthode ne sert pas a avoir une meilleur connection, au contraire, elle aura une latence plus élevée
Cet article est un échange de connaissance entre geeks et, pour peu que tu comprennes les protocoles réseaux et les lignes de commande sous Linux tu devrais t’en sortir. Il n’y aura pas de tutoriel étape par étape.
Et comme le dit Moi, les connexions obtenues par NSTX ont des latences de plus de 500ms et des débits misérables.
Bonsoir 🙂
je n’ai pas compris ce bout de ton article :
“Attention il est important que votre vrai serveur DNS et votre serveur NSTX soient sur deux machines différentes, ou au moins sur deux IP différentes”
Pourrait tu m’éclairer ? Merci d’avance , lemuria.
Il y a un serveur “vrai” DNS qui doit dire que *.tunnel.example.com est redirigé vers 1.2.3.4.
Ensuite il faut le “faux” serveur DNS NSTX qui répond aux requêtes sur *.tunnel.example.com.
Puisque le vrai et le faux serveur fonctionnent tous les deux sur le même port (UDP 53), ils ne peuvent pas être hébergés sur la même adresse IP.
Très bon article, comme d’autres que je viens de découvrir sur votre blog, esthétique qui plus est. Ajouté aux RSS 🙂
Autre soft intéressant : iodine (http://code.kryo.se/iodine/), sous *nix et même Windows grâce au tun/tap d’OpenVPN. Comme NSTX il fournit une connectivité niveau 3 (IP).
Bonne continuation.
Puisqu’on en est à l’échange de liens, que pensez-vous de
http://www.hsc.fr/ressources/outils/dns2tcp/index.html.fr
?
J’aurais bien aimé un comparatif entre ces trois logiciels. Les deux derniers commentaires sont d’une grande utilité car ces différents scripts n’ont pas tous le même travail de peaufinage.
Iodine semble être le plus répandu. NSTX avait un avantage (chiffrer entre le client et le DNS je crois), alors que dns2tcp semble être très vieux et très très mal documenté (très peu de gens en parlent aussi).
Bon à priori j’ai trouvé ca :
Compared to NSTX, iodine has the following advantages:
Higher performance
iodine uses the NULL type that allows the downstream data to be sent without encoding. Each DNS reply can contain over a kilobyte of compressed payload data.
Portability
iodine runs on many different UNIX-like systems as well as on Win32. Tunnels can be set up between two hosts no matter their endianness or operating system.
Security
iodine uses challenge-response login secured by MD5 hash. It also filters out any packets not coming from the IP used when logging in.
Less setup
iodine handles setting IP number on interfaces automatically, and up to 16 users can share one server at the same time. Packet size is automatically probed for maximum downstream throughput.
Even though Iodine is much easier to use and it has clients for Windows, it seems that it is not that reliable as NSTX, as NSTX works in some networks where Iodine fails. This has probably something to do with the different types of DNS queries that are used by those two applications.
The immediately obvious advantages are the Windows client, the password protection and the much easier setup process. As iodine comes bundled in most Debian distributions, you can just install it using apt-get
http://think-security.com/ip-over-dns/
Personnellement je suis passé à iodine, les performances sont plus du double je pense. La configuration est aussi un peu plus facile et je n’ai encore jamais rencontré de hotspot où iodine ne passait pas (il réduit la taille des paquets jusqu’à ce que ça passe) même si ça me semble possible (bloquer les requêtes TXT?)
Hum… visiblement dyndns en version gratos ne donne pas la possibilite d’utiliser des sous-domaines?
merci pour ce poste.
Si j’utilise un VPN comme vous l’avez dit, comment j fait pour passer le traffic gre?
gxtu80