26/09/2009

IP over DNS : Contourner les limitations des hotspots

WiFiZoneVous ê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!

Attention : Cet article fait appel à des connaissances avancé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

dig geekfault.org

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.
Schema-NSTX

  • 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

$ORIGIN tunnel.example.com.
@               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:

# modprobe tun   #Uniquement si compilé en module
# 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:

# modprobe tun   #Uniquement si compilé en module
# 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

hotspotVous 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.

  1. 04/10/2009 à 20:23 | #1

    “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.

  2. 04/10/2009 à 21:16 | #2

    @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.

  3. Pigeon
    17/10/2009 à 01:16 | #3

    Bjr,
    Est-il possible d’avoir les lignes de commande pour Windows, svp ?
    Merci

  4. 18/10/2009 à 16:51 | #4

    Ce n’est pas compatible Windows, désolé

  5. Moi
    05/12/2009 à 18:40 | #5

    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)

  6. 05/12/2009 à 21:21 | #6

    Oui c’est bien les adresses IP du hotspot ;-)

  7. Moi
    05/12/2009 à 22:55 | #7

    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 ?

  8. 05/12/2009 à 23:27 | #8

    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

  9. Moi
    06/12/2009 à 19:17 | #9

    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

  10. 07/12/2009 à 03:47 | #10

    Ta conf m’a l’air correcte, je ne sais pas plus t’aider que ça

  11. nofootman
    07/12/2009 à 21:26 | #11

    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

  12. Moi
    07/12/2009 à 23:52 | #12

    Cette méthode ne sert pas a avoir une meilleur connection, au contraire, elle aura une latence plus élevée

  13. 09/12/2009 à 12:44 | #13

    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.

  14. 28/02/2010 à 00:02 | #14

    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.

  15. 28/02/2010 à 02:28 | #15

    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.

  16. StalkR
    27/04/2010 à 04:48 | #16

    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.

  17. Anonymous
    18/03/2011 à 16:57 | #17

    Puisqu’on en est à l’échange de liens, que pensez-vous de

    http://www.hsc.fr/ressources/outils/dns2tcp/index.html.fr

    ?

  18. 12/07/2011 à 10:41 | #18

    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).

  19. 12/07/2011 à 10:50 | #19

    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/

  20. 14/07/2011 à 09:41 | #20

    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?)

  21. yann
    12/08/2011 à 11:24 | #21

    Hum… visiblement dyndns en version gratos ne donne pas la possibilite d’utiliser des sous-domaines?

  1. 03/09/2014 à 21:55 | #1
  2. 14/11/2014 à 07:14 | #2