Changer de serveur DNS sur un Android non rooté ?

Un petit article rapide pour vous informer que je cherche un moyen de changer les serveurs DNS sur Android sans le rooter. On peut le faire manuellement dans les paramètres avancés de la connexion Wi-Fi, mais ça ne fonctionne qu’avec le Wi-Fi et nécessite de définir un adressage statique pour chaque point d’accès qu’on utilise.

Après recherche, j’ai trouvé une application sur le Play Store, DNSet, qui propose cela. Dans la description, on nous explique que l’application crée un VPN local pour dérouter le trafic DNS vers le serveur de son choix. Bon, pour 99 centimes, je tente.

J’ai un serveur DNS personnel. Je me connecte dessus en SSH et lance une écoute avec tcpdump pour capter le trafic DNS. Je lance l’appli, précise l’adresse de mon serveur. Le VPN s’établit, je lance Twitter pour tester. Résultat :

root@XXX:~# tcpdump -i XXX udp port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on XXX, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
22:13:15.141006 IP XXX.62129 > XXX.net.domain: 61136+ A? settings.crashlytics.com. (42)
22:13:15.163342 IP XXX.net.56316 > l.gtld-servers.net.domain: 52203% [1au] A? settings.crashlytics.com. (53)
[…]

Ahem. C’est quoi, ça ? Ça ne ressemble pas à Twitter. Si je configure mon DNS manuellement dans ma connexion Wi-Fi, ça donne quoi ?

root@XXX:~# tcpdump -i XXX udp port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on XXX, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
22:38:58.292666 IP XXX.6736 > XXX.net.domain: 5743+ A? twitter.com. (29)

Ah oui. Ok. Donc cette application pue à mort. Ne l’utilisez pas. Je l’ai immédiatement désinstallée après ce test. Et elle m’a été remboursée. Je n’en demandais pas tant !

TL;DR : DNSet altère vos requêtes DNS !

Voilà. Au passage, quand vous configurez vos paramètres DNS du Wi-Fi, ne vous plantez pas dans l’adresse. J’ai eu le malheur de mettre un zéro en trop, ça a fait crasher Android. Et ça crashait continuellement tant que le Wi-Fi était activé et que le smartphone tentait de se connecter au point d’accès mal configuré. J’ai dû aller dans un autre endroit, où le réseau maudit n’était pas, pour pouvoir faire « Oublier » et rétablir sa configuration par défaut.

Du coup, je cherche un développeur Android qui saurait faire une application où on peut changer le serveur DNS et qui n’altèrerait pas les requêtes. N’hésitez pas à me contacter !

[POC] Tweeter sans réseau (ou presque)

Dans le train, qu’il peut être difficile d’envoyer un tweet… Le réseau est fluctuant dès qu’on s’éloigne d’une ville, et pour quelque chose d’aussi bref qu’envoyer un tweet, ça devient très compliqué sans 3G ou 4G !

En effet, l’envoi d’un tweet se fait sur TLS (chiffrement) et TCP (transport fiable). L’établissement d’une connexion au serveur nécessite de nombreuses communications qui doivent toutes passer en un intervalle de temps réduit, sous peine de devoir tout recommencer ! Alors qu’en principe, il suffirait d’envoyer une seule requête…

C’est sur ces pensées que m’est venue l’idée d’exploiter l’IP over DNS. Grâce à ce principe, on peut envoyer une seule requête à un serveur qui, ensuite, enverra effectivement le tweet. Le concept est d’envoyer le tweet sous forme d’un nom de domaine encodé en base64. Le serveur qui recevra finalement cette requête DNS ne répondra pas mais interprétera le sous-domaine en le décodant et le tweetant. Cela nécessite un client Twitter sur le serveur. J’ai trouvé TTYtter qui fait très bien l’affaire.

S’agissant d’une preuve de concept (en anglais POC pour Proof Of Concept), j’ai (encore) fait du code sale à l’arrache en quelques heures. Mais ça marche. La POC combine deux petits programmes en C, qui récupèrent le sous-domaine, avec un script bash qui pilote le tout. Voici les codes sources :

  • recvdns.c : écoute sur le port 53 et enregistre dans un fichier une requête DNS
  • sousdom.c : détermine le sous-domaine en lisant dans un fichier
  • tod.sh : le script shell qui reçoit une requête DNS, décode le tweet et l’envoie
  • Le code perl du client Twitter, TTYtter

Avant tout, il est nécessaire de configurer le DNS et TTYtter. Pour ce dernier, c’est simple : lancez-le une première fois et laissez-vous guider ! Pour le DNS, vous devez avoir un enregistrement de type A qui pointe vers votre serveur et un enregistrement de type NS qui pointe vers le premier. Exemple :

Nom de l’enregistrement Type Pointe vers…
xxx.vincesafe.fr A 1.2.3.4
yyy.vincesafe.fr NS xxx.vincesafe.fr

Dans cet exemple, le serveur qui lancera le script a pour adresse 1.2.3.4.

Compilez les fichiers source C et placez tous les exécutables (sousdom, recvdns, tod.sh et ttytter) dans le même répertoire. Assurez-vous que le droit d’exécution est bien présent. Il n’y a plus qu’à lancer tod.sh.

… Et maintenant ? En fait, je n’ai pas (encore) développé de client… J’ai juste testé si ça fonctionnait en encodant un tweet en base64 et en lançant une requête du style tweetencode.yyy.vincesafe.fr… Et ça a marché ! J’ai utilisé le compte Twitter de mon serveur, vinceserv, pour immortaliser le moment.

Je rappelle qu’il s’agit là d’une preuve de concept (POC) codée à la va-vite et que tout reste à faire ! On peut facilement améliorer le code (et je vous encourage à le faire et à le partager), coder un client pour Android… J’entrouvre une porte, faites-en ce que vous voulez.

Ah, un détail : s’agissant d’IP over DNS, ce « truc » fonctionne sur les hotspots Wi-Fi sans avoir à s’identifier, ainsi que sur les réseaux de données (3G…) même si on n’a plus de crédit… 😉

aDNSblock, un serveur DNS qui bloque la pub

Dans un précédent article, je vous parlais d’une technique pour ne pas recevoir les pubs sur les applications smartphone. J’ai étendu le principe utilisé, à savoir le blocage de DNS, pour aller plus loin : utiliser son propre serveur comme serveur DNS et bloquer les domaines des annonceurs. Cela nécessite évidemment d’avoir son propre serveur. En fouinant un peu, j’ai vu que je n’étais pas le premier à avoir l’idée et j’ai trouvé un fichier de zones pas mal rempli que j’ai réutilisé.

J’ai codé (à l’arrache) un script bash dégueulasse mais qui marche chez moi (Debian + bind9, vous l’arrangerez suivant votre configuration). Voici pour vous aDNSblock. Je place ce code dans le domaine public, on va quand même pas foutre une licence sur un torchon pareil.

L’avantage de cette solution est qu’il vous suffit de configurer votre ordinateur en renseignant l’adresse d’un serveur aDNSblock et pouf ! Plus de pubs… Enfin, il faut maintenir la liste à jour manuellement. On doit pouvoir automatiser ça en se basant sur les filtres AdBlock+, je me pencherai dessus un de ces quatre.

Si quelqu’un laisse tourner son serveur aDNSblock et veut en faire profiter ceux qui n’en ont pas, n’hésitez pas à laisser l’adresse du serveur en question dans les commentaires.

Les appels en masqué, comment ça marche ?

Qui n’a jamais hésité à répondre à un appel d’un « numéro privé » ? Franchement, si on veut une réponse, c’est quand même mieux de se signaler dès le départ. Mais comment faire pour appeler en masqué ? D’ailleurs, comment ça marche, ce système ?

La présentation du numéro de l’appelant existe depuis la fin des années 1990 en France. À l’époque, on utilisait presque exclusivement des téléphones analogiques que l’on branchait directement sur la prise. Aujourd’hui, ça existe toujours, mais beaucoup ont une box (Livebox, Freebox, …) sur laquelle est branché le téléphone. Néanmoins, le système pour afficher le numéro n’a pas changé. Il faut bien que ça continue de marcher chez mamie Huguette aussi !

Le réseau téléphonique classique est composé de tout plein d’appareils chargés d’établir des communications. Ce sont des commutateurs. Quand vous composez un numéro, ce sont ces commutateurs qui font en sorte que vous tombiez sur mamie Huguette et non pas sur son voisin Robert. Votre téléphone fixe est forcément relié à un commutateur par des fils métalliques (généralement du cuivre). S’il est branché sur une box, votre box sert en quelque sorte de commutateur. S’il est branché sur la prise téléphonique, il est relié à un commutateur de votre opérateur (Orange, par exemple).

Quand vous composez un numéro, il est transmis au commutateur qui se débrouille pour vous raccorder avec la personne que vous voulez appeler. Le commutateur identifie votre ligne (« tiens, il y a le 0123456789 qui veut appeler le 0987654321 »). Votre numéro est transmis jusqu’au téléphone de votre interlocuteur de la même manière que votre voix quand vous parlez. Concrètement, il y a des signaux compréhensibles par le téléphone qui arrivent jusqu’au destinataire. C’est comme ça que votre numéro peut s’afficher sur le téléphone de mamie Huguette et qu’elle n’a pas à se demander si ce n’est pas des emmerdeurs qui veulent lui vendre des parfums (ou autre) !

Mais alors, si vous appelez en masqué, qu’est-ce qui se passe ? En fait, lorsque les signaux dont on parlait à l’instant arrivent au commutateur sur lequel est relié votre interlocuteur, ce commutateur interroge une base de données qui répertorie les numéros à ne pas afficher. Si vous avez demandé à votre opérateur que votre numéro ne s’affiche pas, le commutateur supprime ces signaux. Supposons que mamie Huguette (toujours elle) ait un téléphone branché sur le commutateur de Plaisance-du-Touch (ça existe vraiment, si si), c’est lui qui retirera l’information. Et la pauvre mamie ne saura pas que c’est son petit-fils chéri qui vient prendre de ses nouvelles.

Schéma représentant deux téléphones reliés par le réseau téléphonique commuté

Il existe une exception : les numéros d’urgence. Si vous appelez les secours (en France, pompiers : 18, police : 17, service d’assistance médicale d’urgence : 15, …), le commutateur final ne se pose pas la question de savoir si vous appelez en masqué : il y a urgence, il faut vite acheminer l’appel et tant qu’à faire, autant qu’on puisse identifier l’appelant.

Pour que votre numéro n’apparaisse jamais, il faut en faire la demande à votre opérateur. Sinon, il existe des numéros spéciaux suivant les opérateurs pour passer un appel ponctuel en masqué. Chez Orange, il faut composer le 3651 suivi du numéro à appeler. Ainsi, si vous composez le 36510123456789, vous appellerez le 0123456789 en masqué. D’un point de vue technique, la commutation (l’établissement de la communication) se fera pareillement, sauf que le commutateur final « verra » que le numéro appelé commence par 3651 et supprimera l’information du numéro appelant. Ce code est différent selon les opérateurs.

Pour les téléphones portables, c’est sensiblement la même chose, sauf que l’option est réglable directement depuis le téléphone et l’information n’est pas transmise de la même manière.

Maintenant que vous savez comment tout cela fonctionne, vous réfléchirez plus avant de faire un canular téléphonique !

Note aux puristes : cet article est volontairement imprécis et vulgarisé, le manque de rigueur technique est totalement assumé.

Smartphones, réseaux : prévenons les risques !

Bonjour,

Vous avez un instant ? Regardez autour de vous dans un lieu public. Que voyez-vous ? Des gens qui ont les yeux rivés sur leur smartphone, leur tablette, leur ordinateur. Rien de très extraordinaire à l’heure où l’accès à Internet est très facile et où le numérique est omniprésent. Oui mais… Que font ces gens réellement ? Ils jouent en attendant leur train, ils lisent un e-mail qu’ils viennent de recevoir, ils consultent leur Facebook… Des activités tout à fait banales. Maintenant, demandons-nous comment ils le font. Oui, comment ? Avec un smartphone ? Ils ont donc probablement installé une application. Pour ce faire, ils ont accordé des autorisations qu’ils n’ont sûrement pas lues. Mais quelle importance pour eux que leur jeu favori ait accès à leurs informations personnelles. Ces personnes y prêteraient bien plus d’attention si la société éditrice venait installer des caméras de surveillances chez elles.

Et comment fait cet homme d’affaires dans la gare pour lire ses e-mails depuis son ordinateur ? Il utilise un réseau Wi-Fi public ? Il n’en a sûrement rien à faire non plus que ce qu’il envoie puisse être intercepté voire détourné par n’importe qui. Ou plutôt, il ne doit pas être au courant. En effet, qui connait les problématiques liées aux smartphones et aux réseaux informatiques ? À part ceux qui étudient ou travaillent dans le domaine, pas grand-monde. Avant le scandale PRISM, une grande majorité des gens ne s’était jamais demandé si elle était surveillée, par qui et comment. La surmédiatisation de cette affaire est une brèche dans laquelle il peut être intéressant de s’engouffrer pour prévenir le grand public des dangers auxquels il s’expose inconsciemment.

Sensibiliser le grand public par des médias grand public

Si on ne met pas les gens en face de la réalité, ils ne vont pas aller la chercher d’eux-mêmes. C’est pourquoi j’aimerais créer une association de sensibilisation aux comportements à risques auxquels des milliers voire des millions de personnes se livrent quotidiennement sans s’en rendre compte. Je pense principalement à l’installation de tout et n’importe quoi sur les ordinateurs et smartphones, à l’utilisation de réseaux Wi-Fi publics hasardeux, au manque de protection des mots de passe, … L’idée est d’intervenir dans des médias de masse comme la radio, la télévision, les journaux ou l’affichage public en publiant des posters « choc » ou qui interpellent, ou en expliquant de manière très accessible ces risques.

Une association ?

La réalisation de campagnes de sensibilisation ne peut pas se faire tout seul. C’est pourquoi j’aimerais monter une association composée de plusieurs membres ayant des rôles différents pour mener à bien les opérations. Il faudrait des designers pour réaliser des affiches, des chargés de communication pour intervenir dans les médias, des auteurs pour écrire des cours accessibles afin d’expliquer concrètement les dangers, etc. La structure et le fonctionnement ne sont pas encore clairement définis : l’objectif de cet article est de vous présenter l’idée et de voir si elle intéresse du monde. En fonction des retours et des personnes qui voudront s’investir avec moi dans cette activité, nous verrons ce que nous ferons. Aucune date, aucun délai n’est actuellement défini : je préfère prendre le temps de bien définir ce que nous préparerons quitte à ce que l’association ne soit montée qu’en 2014. Une chose est sûre : vu la façon dont les gens (hors geeks) utilisent leur PC ou leur smartphone, le potentiel de la prévention est énorme.

Ça vous intéresse ?

Si vous êtes motivé par l’idée, sérieux et que vous souhaitez œuvrer avec moi, vous pouvez me contacter par e-mail (vince at vincesafe.fr). Cette association serait à but non lucratif et les activités non rémunérées, du moins dans un premier temps. Dans tous les cas, n’hésitez pas à me donner vos impressions, vos idées, vos remarques dans les commentaires de cet article ou par Twitter (@vincesafe).

À toutes fins utiles, je suis apprenti ingénieur dans une société de télécommunications et j’habite en région parisienne. Il serait donc plus facile de créer une association avec des personnes franciliennes dans un premier temps, puis d’ouvrir par la suite des branches dans d’autres régions voire d’autres pays.

Merci de votre attention.

Gestion de DNS OVH (ou autre) avec WordPress

Si vous aussi, vous êtes un boulet qui a déporté la gestion de son domaine chez WordPress et qui ne comprend pas que certaines choses ne fonctionnent pas, vous n’êtes plus seul ! Après deux ans, j’ai enfin compris que si je délègue la gestion de mon domaine acheté chez OVH (mais c’est aussi valable pour Gandi ou autre) à WordPress, il faut que je configure le DNS en question avec WordPress. Ainsi, pour utiliser le mail d’OVH dans cette configuration, il faut indiquer dans son fichier de zone (Boutique / Domaines / Modifier DNS) :

MX 1 mx1.ovh.net.
MX 5 mx2.ovh.net.
MX 100 mxb.ovh.net.

Ce qui est intéressant, c’est qu’avant de faire cela, je pouvais envoyer des mails mais pas en recevoir. Pourquoi ? Parce que quand j’envoie un courriel avec un client comme Thunderbird, c’est l’adresse du serveur SMTP d’OVH que j’indique. Il n’y a pas d’autre résolution DNS : le client demande des informations sur le serveur à l’adresse ssl0.ovh.net et c’est tout. On tombe ainsi directement sur le serveur SMTP. Pour la réception depuis ce même logiciel, c’est pareil, l’adresse du serveur POP est renseignée manuellement. En revanche, lorsque j’envoie un mail à quelquechose at vincesafe.fr depuis Gmail, Yahoo, etc., ce serveur mail va faire une requête de type MX sur vincesafe.fr. OVH va répondre que la gestion est déléguée à WordPress. La preuve :

vince@ssh:~$ dig mx vincesafe.fr

; <<>> DiG 9.6-ESV-R4 <<>> mx vincesafe.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56442
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;vincesafe.fr.                  IN      MX

;; AUTHORITY SECTION:
vincesafe.fr.           300     IN      SOA     ns1.wordpress.com. hostmaster.wordpress.com. 2005071858 14400 7200 604800 300

Alors la requête va être adressée à WordPress, qui va regarder dans sa configuration les enregistrements MX pour vincesafe.fr. S’il n’y en a pas, c’est le serveur mail par défaut de WordPress qui va réceptionner le mail… qui n’arrivera jamais dans la bonne boite puisqu’on souhaite, dans le cas présent, que ça aille dans une boite OVH.

En renseignant comme expliqué en début d’article les bons enregistrements, on délègue les domaines relatifs aux e-mails à OVH (qui, lui, délègue l’entièreté du domaine à WordPress) et c’est réglé…

En espérant que ça puisse aider du monde !

Virer les pubs des applications pour smartphone

En bon crevard, vous ne voulez pas payer 2 euros pour un jeu smartphone donc vous utilisez la version gratuite mais les pubs vous soulent. Or, les pubs, ça ne se génère pas tout seul. Elles sont téléchargées par les applications lorsque vous les utilisez. D’ailleurs, vous avez peut-être remarqué que sur certains jeux, si vous désactivez toutes vos connexions au net, il n’y a pas de pub (bon, pour les jeux en ligne comme DrawSomething ou Ruzzle, c’est pas évident à voir). On peut donc s’en passer et, si vous n’êtes pas scrupuleux, on ne va pas se priver…

Les pubs sont téléchargées depuis le net. L’idée est de déterminer depuis où afin de bloquer l’accès à ces serveurs. Connectons donc notre smartphone en Wi-Fi, lançons une analyse de trames et démarrons un jeu (allez, Draw Something). Sans fouiller, on voit tout de suite des requêtes DNS avec des noms qui sentent la pub du style « appads.com », « ads.flurry.com », … Si on indique à notre smartphone que ces adresses pointent vers un faux serveur, aucun risque de voir des pubs venir. Hop, on redirige tout ça vers la boucle locale (127.0.0.1).

Oui… mais comment ? Si votre smartphone est rooté, il ne doit pas être bien difficile de modifier le fichier hosts ou équivalent Android / iOS / autre. Si vous avez votre propre serveur DNS, vous pouvez le paramétrer dans la configuration de votre smartphone (au moins pour les connexions Wi-Fi) et bloquer les serveurs à ce niveau-là. Sinon, si vous jouez depuis chez vous en vous connectant à votre box, une petite modification du DNS local fera l’affaire. Ça ne bloquera les pubs que sur cette connexion mais c’est déjà ça.

On indique donc à notre machine (smartphone, serveur DNS ou box) que les adresses repérées pointent vers 127.0.0.1. Il se peut que l’application soit persévérante et tente de contacter d’autres serveurs si elle ne parvient pas à contacter les premiers. Dans ce cas, on continue le repérage jusqu’à ce qu’il n’y en ait plus (il ne peut pas y en avoir une infinité enregistrée en dur). Pour ma part, j’ai repéré les serveurs suivants pour Draw Something :

saturn.appads.com – saturn1.appads.com – saturn2.appads.com – saturn3.appads.com – ads.flurry.com – data.flurry.com – appads.com

En bloquant ça, vous pouvez dire au revoir aux pubs sur ce jeu pour un bon moment ! En procédant de la même manière, j’ai identifié les serveurs de pub suivants pour Ruzzle : www .adtilt.com – media.admob.com – pagead.l.doubleclick.net.

dns_pub

Blocage de serveurs de pub sur une neufbox

D’un point de vue technique, c’est formidable. Maintenant, si tout le monde fait cela, ça va être un problème pour les entreprises de développeurs qui se rémunèrent grâce à la pub. Si vous pouvez payer l’application, c’est préférable de le faire, en plus, il y a souvent des fonctionnalités supplémentaires. Cet article est là pour montrer qu’il est possible de le faire, pas pour que tout le monde s’y mette. De toute façon, l’aspect légèrement technique de la chose va repousser d’emblée pas mal de monde. Ne nous inquiétons pas tout de suite pour les développeurs. 🙂

Internet+, pour + de fraude sur Internet

Pour payer par Internet, il y a entre autres la carte de crédit, Paypal, Allopass et Internet+. Internet+, je n’en avais jamais entendu parler jusqu’à aujourd’hui. C’est un système qui permet de payer de petits achats via sa facture d’accès à Internet. Concrètement, je règle un achat de 5 euros par Internet+ et ma prochaine facture sera de 5 euros de plus que d’habitude. Comment ça fonctionne ? C’est bien ça, le problème.

Comme j’aime beaucoup Orange, c’est avec ce FAI que j’ai testé ce système. Quand on clique sur un bouton pour payer, on est redirigé vers une page de notre fournisseur d’accès qui nous propose de nous identifier. Dans mon cas, j’étais déjà identifié avec mon compte Orange, on m’a donc immédiatement proposé de cliquer sur un bouton de confirmation. Et hop, une facture légèrement plus élevée…

Sauf que. En réalité, je n’étais pas sur mon réseau, pas plus que je n’étais connecté avec mon compte Orange. J’étais sur le réseau Wi-Fi (Livebox) de quelqu’un d’autre et je n’ai pas eu à m’identifier ni à m’authentifier, comme ça arrive suivant les configurations. J’ai donc payé un service aux frais de la princesse.

Merci, Orange !

Information légale : je ne vous encourage pas à pirater un réseau Wi-Fi Orange pour voir si vous pouvez accéder au compte du titulaire sans authentification, pas plus que pour voler de l’argent. Vous encourez une peine de prison de plusieurs années si vous accédez frauduleusement à un système informatique. Le présent article ne peut en aucun cas faire l’objet d’un témoignage ou d’un pièce à conviction pour quelque plainte ou affaire judiciaire que ce soit. La véracité des informations fournies sur cette page n’est aucunement garantie.

Contournez restrictions et censure avec l’IP over DNS !

Avant-propos

Icone "IP over DNS"Voici un tutoriel que j’avais rédigé pour le Site du Zéro. Il était en bêta-test, ce qui permettait aux membres de le lire et de me donner leur avis avant soumission à validation. Il a été censuré (limite de la légalité, frilosité de Simple IT, tout ça), mais ce n’est pas un problème : je le publie ici. La portée est malheureusement bien moindre sur ce blog, mais bon, tout ce qui m’importe est qu’un maximum de gens en profitent. N’hésitez donc pas à le diffuser.

L’intégralité du contenu de cet article est sous licence CC BY-NC-SA (pour toute reproduction partielle ou totale : obligation de citer la provenance,  utilisation non commerciale uniquement, partage dans les mêmes conditions).

Téléchargez cet article en PDF !


Vous êtes sur un réseau très restrictif comme un point d’accès Wi-Fi public, une bibliothèque, une école, et vous souhaitez utiliser certains services comme la messagerie instantanée mais le réseau ne laisse passer que le web ? Faites sauter les barrières ! Dans ce cours, vous allez apprendre à faire transiter vos communications rien qu’avec des requêtes DNS. Oui, ces requêtes qui permettent de traduire les adresses comme www.siteduzero.com en adresses compréhensibles par les ordinateurs !

Pour suivre ce tuto, il est recommandé d’avoir quelques notions en réseau, notamment savoir ce qu’est une adresse IP, un protocole et connaitre un minimum le fonctionnement des noms de domaine. Quelques connaissances en Linux seront aussi utiles, notamment le système d’interfaces réseau (ifconfig…). Vous aurez aussi besoin d’un serveur que vous pouvez contrôler (obligatoirement) ainsi que d’un nom de domaine (facultatif).

C’est parti !

L’arbre à DNS

Pour comprendre ce cours, vous devez savoir que les DNS utilisent une structure arborescente et qu’il existe différents types de requêtes. Si ce n’est pas le cas, je vous renvoie à cet excellent tuto de Mathieu Nebra.

Côté client

Quand nous voulons accéder à http://www.siteduzero.com, que se passe-t-il ? Premièrement, notre machine envoie une requête DNS à un serveur DNS pour savoir à quelle adresse IP s’adresser. On le voit sur cette capture effectuée avec Wireshark :

Image utilisateur
On demande l’adresse IP (type A) correspondant à www.siteduzero.com et le serveur nous répond par l’adresse IP en question.

Mais le serveur DNS questionné ne connait pas forcément l’adresse IP demandée ! S’il connait l’adresse de siteduzero.com, il va lui demander l’adresse du sous-domaine www. S’il ne la connait pas, il va demander au serveur qui gère les .com quelle est l’adresse de siteduzero.com pour pouvoir faire la demande précédente.

En tant que client, on ne visualise pas bien comment tout cela se passe. Regardons alors comment le serveur voit les choses.

Côté serveur

Voici un exemple concret de configuration d’un domaine.

Sous-domaine Type Adresse pointée
a.sdz.us.to A 77.154.22.35
b.sdz.us.to NS a.sdz.us.to

Le type A signifie « ce (sous-)domaine correspond à cette adresse IP ». Le type NS signifie « pour tout sous-domaine de ce (sous-)domaine, il faut voir avec tel serveur ». En pratique, cela signifie que si on demande à quelle adresse correspond truc.b.sdz.us.to, le serveur DNS va contacter un autre serveur DNS à l’adresse a.sdz.us.to pour avoir la réponse et la transmettre au client qui l’a demandée.

En image, c’est plus clair :

Image utilisateur

1. Le client demande l’adresse de truc.b.sdz.us.to à son serveur DNS défini dans la configuration de sa machine.
2. Ce serveur DNS transmet la requête au serveur qui gère sdz.us.to, car il connait l’adresse de celui-ci, mais c’est tout.
3. Ce serveur est configuré pour transmettre toute requête concernant les sous-domaines de b.sdz.us.to vers un autre serveur DNS à l’adresse a.sdz.us.to. Il la lui transmet donc.
4. Ce dernier serveur renvoie la réponse au client.

C’est clair jusque là ? Il vaut mieux, car on va rentrer dans le vif du sujet maintenant !

Et si on truquait les requêtes ?

Rien ne nous empêche d’avoir notre propre serveur DNS à l’étape 4 configuré comme on l’entend. Rien ne nous empêche d’envoyer les requêtes qu’on veut à notre serveur. Ainsi, le client et le serveur peuvent utiliser un même « code » pour s’envoyer des messages cachés à travers les requêtes DNS ! Imaginez : le client demande l’adresse de loto.b.sdz.us.to. C’est notre serveur qui va répondre, et on peut parfaitement le configurer de manière qu’il réponde à cette requête particulière par les numéros du dernier tirage du loto ! On aura donc transmis des données d’une nature quelconque over DNS.

Et c’est le jackpot ! On peut donc transmettre n’importe quoi à travers des requêtes DNS. On peut transmettre de l’IP over DNS. En effet, toute communication que vous effectuez sur Internet utilise le protocole IP (Internet Protocol).
Attention, ce n’est pas non plus la panacée. Cela peut dépanner pour transmettre des données en contournant des restrictions, mais n’espérez pas rejoindre une partie de League of Legends, Need for Speed ou tout autre jeu qui demande à envoyer et recevoir en permanence des données. DNS s’appuie sur UDP qui est un protocole non fiable : on n’est jamais sûr qu’un paquet transmis avec UDP arrive bien à destination. Il est possible qu’un paquet ait à être envoyé plusieurs fois pour qu’il arrive intègre à destination.

Toutefois, comme cela peut quand même être bien utile, nous allons apprendre à mettre en place un tel système.

Configurons notre propre sous-domaine

Vous possédez un nom de domaine ? Parfait ! Sinon, ce n’est pas grave, nous allons en emprunter pour créer des sous-domaines.

Vous possédez un nom de domaine

Si vous possédez un nom de domaine, vous êtes censé savoir le configurer ! :p
Dans les zones DNS, créez un sous-domaine de type A que vous appelez comme vous voulez (« a » par exemple, parce que c’est court :-° ) et faites-le pointer vers l’adresse IP du serveur que vous allez utiliser pour l’IP over DNS. C’est ce serveur qui recevra les requêtes DNS « trafiquées » et qui renverra les paquets de manière normale.

Si vous préférez utiliser une adresse IPv6, choisissez le type AAAA. Le type A ne permet de faire pointer que vers une adresse IPv4.

Ensuite, créez un autre sous-domaine de type NS. Donnez-lui un nom court (« b » par exemple), car il va falloir le retaper quand on va mettre en place le serveur. Faites-le pointer vers l’autre sous-domaine précédemment créé mais rajoutez un point au bout. Si votre domaine est dom.tld, saisissez « a.dom.tld. ». Je ne peux que vous renvoyer au cours de Mathieu Nebra pour de plus amples informations à ce sujet.

Votre zone DNS est prête, vous pouvez passer à la sous-partie suivante. La suite de celle-ci concerne ceux qui n’ont pas de nom de domaine.

Emprunter des noms de domaine

Il y a des gens très gentils qui proposent à tous d’utiliser leur propre nom de domaine pour créer des sous-domaines. Le service FreeDNS est simple d’utilisation et permet à n’importe qui de créer des sous-domaines sur des milliers de noms de domaine différents. Inscrivez-vous donc à ce service gratuit si vous ne possédez pas de nom de domaine à vous !

Une fois inscrit et identifié, allez dans la section « Subdomains » et cliquez sur « Add ». Choisissez un domaine qui vous plait dans la liste, sélectionnez le type A et rentrez l’adresse IP de votre serveur dans le champ « Destination » (ou sélectionnez le type AAAA pour pouvoir rentrer l’adresse IPv6). Dans le champ « Subdomain », mettez ce que vous voulez (le tout est d’en trouver un qui ne soit pas déjà pris, essayez des valeurs comme « moi.sdz » ou « truc.sdz »). Cliquez sur « Save! » et hop ! Vous avez un sous-domaine qui pointe vers votre serveur. Par la suite, je considérerai qu’il s’agit de « a.sdz.us.to ». Vous adapterez les manipulations en utilisant le vôtre, évidemment.

Créons encore un sous-domaine. Encore une fois, choisissez le domaine qui vous plait, idem pour le sous-domaine. Sélectionnez le type NS et renseignez comme destination le sous-domaine précédemment créé (pas besoin de rajouter un point). Par la suite, je considérerai que ce sous-domaine de type NS est « b.sdz.us.to ».

Cela nous donne une configuration qui ressemble à ceci :

Sous-domaine Type Adresse pointée
a.sdz.us.to A 77.154.22.35
b.sdz.us.to NS a.sdz.us.to

Voilà, la configuration des DNS est terminée ! Il n’y a plus qu’à mettre le serveur en place !

53 protons !

Pour gérer le trafic qui va arriver jusqu’à notre serveur, nous utiliserons le logiciel iodine. Il est disponible sous Linux et sous Windows. Toutefois, ne l’ayant jamais utilisé sous Windows, je vous montrerai comment l’utiliser sous Linux. Vous pouvez demander à Google comment faire sur votre système d’exploitation s’il est différent.

Côté serveur

Installez iodine s’il n’est pas déjà présent sur votre serveur (apt-get install iodine sous Debian et dérivés). Lorsque vous allez lancer iodine, une nouvelle interface réseau sera créée. Vous devrez spécifier une adresse IP pour cette interface, assurez-vous qu’elle n’entrera pas en conflit avec votre configuration actuelle. Pour cela, relevez les adresses IP de vos cartes réseau avec ifconfig ou ipconfig sous Windows. Vous choisirez une adresse privée qui n’appartient pas à un réseau déjà configuré.

Si vous n’avez rien compris, vous prendrez l’adresse 192.168.53.1. Assurez-vous juste que vous n’avez aucune adresse commençant par « 192.168.53 » dans la configuration de vos cartes réseau.

Lançons donc le serveur iodine (adaptez la commande avec vos propres valeurs).

Code : Console

iodined -f 192.168.53.1 b.sdz.us.to
Le -f est facultatif, il sert juste à ne pas lancer le processus en arrière-plan pour qu’on puisse à tout moment l’arrêter en tapant CTRL C.

Vous êtes invité à rentrer un mot de passe, choisissez celui que vous voulez. Il servira juste à initier la connexion quand vous vous connecterez avec votre client.

Votre serveur IP over DNS est maintenant lancé. Il faut maintenant s’y connecter !

Côté client

Depuis votre client, lancez simplement la commande suivante :

Code : Console

iodine -f -P mot_de_passe b.sdz.us.to

La connexion peut être longue à s’établir. Une fois connecté, vous verrez un message comme suit :

Code : Console

Connection setup complete, transmitting data.

La connexion est établie ! Maintenant, testez si cela fonctionne, en lançant une analyse de trames avec Wireshark, par exemple. Si vous ne voyez que des requêtes DNS, c’est que ça fonctionne ! Si cela ne fonctionne pas, ce n’est pas grave, on passe au plan B.

Même si cela fonctionne chez vous, lisez quand même ce qui suit : nous allons établir un tunnel SSH, ce qui permettra de crypter les informations transmises. Cela est fortement recommandé si vous résidez dans un pays où la liberté d’expression est réduite et que vous voulez communiquer des informations délicates.

Le plan B

Je dois vous avouer quelque chose que je ne m’explique pas. La toute première fois que je me suis connecté sur un serveur iodine, tout était transmis over DNS, cela fonctionnait. Ça n’a plus jamais refonctionné comme cela depuis. :D Tout était transmis de manière normale, sans passer par des requêtes DNS. Alors j’ai eu recours à une astuce que je partage avec vous.

Logiquement, nous sommes dans le même réseau que notre serveur iodine avec l’interface dns0. Pourtant, toutes nos communications vers l’extérieur passent par une autre interface (wlan0, eth0, …). Si on tente de contacter notre serveur via son adresse 192.168.53.1, les communications se feront forcément over DNS. Établissons alors une connexion SSH avec notre serveur.

Code : Console

ssh 192.168.53.1

Nous sommes connectés à notre serveur over DNS. Maintenant, si nous ouvrions un tunnel SSH entre nous et le serveur pour faire transiter nos données ? Comme la connexion SSH fonctionne sur IP over DNS, tout ce qu’on transmet à travers fait de même !

Ouvrons donc cette fois une connexion SSH avec un tunnel dynamique.

Code : Console

ssh -D 30000 192.168.53.1

J’ai choisi le port 30000 mais vous pouvez utiliser celui que vous voulez, tant qu’aucun autre programme sur votre client n’écoute dessus.

Comment fonctionne ce tunnel ? Comment je peux faire passer ma navigation sur le web, mes e-mails, etc. dessus ?

Ce genre de tunnel agit comme un proxy SOCKS. Il vous faut donc configurer les applications que vous souhaitez utiliser pour qu’ils utilisent un proxy SOCKS à l’adresse 127.0.0.1 (la boucle locale, car c’est sur votre client que SSH écoute pour transmettre les données) et au port 30000 (ou celui que vous avez choisi).

Voilà, il faut juste que la connexion IP over DNS soit suffisamment solide pour pouvoir maintenir la connexion SSH, et roulez jeunesse !

Informations légales

Cette technique permet de contourner des restrictions, elle ne vous soustrait toutefois pas à la loi. Par exemple, ce n’est pas parce que vous allez utiliser un serveur dans un pays où le téléchargement d’œuvres protégées par le droit d’auteur n’est pas interdit, que vous avez le droit de rapatrier les-dites œuvres sur votre machine si vous résidez dans un pays où cela est interdit.
De plus, les hotspots ne filtrant généralement pas les requêtes DNS, il est possible d’utiliser l’IP over DNS pour utiliser sans avoir de compte les SFR Wi-Fi, Belgacom FON et autres points d’accès réservés aux utilisateurs enregistrés. N’en abusez pas, c’est à la limite de la légalité suivant les pays.

Bien entendu, si vous êtes en Iran ou en Chine et que vous souhaitez transmettre des informations sensibles de manière discrète, personne ne vous reprochera d’avoir recours à de telles techniques.

« Tout ça pour ça » ! Il est vrai que l’utilité de l’IP over DNS est relative. Quand on peut, on préfèrera utiliser des tunnels SSH : c’est beaucoup plus facile à mettre en place ! Mais il arrive que l’on tombe sur des réseaux qui ne laissent presque rien passer, dans ce genre de cas, une telle technique peut s’avérer utile.

Tethering Wi-Fi sans payer : la suite

Attention, article super technique. C’est un pavé qui fait brouillon mais j’ai envie de le partager quand même. J’en ferai un papier plus propre pour l’exposer à des professeurs.


Depuis mon dernier article sur le partage de la connexion 3G de son smartphone malgré le refus de l’opérateur, je me demande comment il est possible de déterminer qu’un paquet provient bien du smartphone et non d’un appareil connecté dessus. Aujourd’hui, je vous propose deux choses : une application pour faciliter l’astuce précédemment décrite et une réflexion sur le « truc » des opérateurs pour refuser le tethering.

SSH est trop compliqué ?

Si vous n’êtes pas à l’aise avec SSH, vous avez dû avoir des difficultés à expérimenter la technique du dernier article. Réflexion faite, je me suis dit que c’est le même principe qu’un proxy. Après, je ne sais pas du tout comment ce genre de serveur fonctionne. J’ai donc demandé à mon ami Google s’il connaissait des serveurs proxy pour Android. Je suis tombé sur Internet Sharer. Cette application est simple d’utilisation mais pas super pratique. Elle fournit un serveur proxy HTTP et SOCKS, ce qui devrait permettre de faire transiter tout ce qu’on veut (pour l’instant, je n’arrive à me servir que du proxy HTTP). On peut aussi utiliser cette application pour faire du port forwarding (on écoute sur un port et on renvoie ce qui arrive sur un autre port d’un hôte distant).

Pour faire transiter ses communications via le serveur proxy, ce qui permet de faire croire à l’opérateur qu’elles proviennent du smartphone, il faut configurer ses applications. C’est là que je ne comprends pas trop… Pour la navigation web, j’ai mis comme proxy HTTP l’adresse IP de l’interface Wi-Fi du smartphone (de la forme 192.168.X.1) et comme port 8080, et comme proxy SOCKS la même adresse et le port 1080. De cette manière, la navigation web fonctionne, mais SSL ne passe pas (autrement dit, HTTPS ne passe pas). Je creuserai sûrement si j’en ai le courage.

On ne peut donc pas à priori tout faire passer par ce proxy, alors qu’on peut techniquement tout faire passer par le tunnel SSH. Mais le mieux, ce serait encore de comprendre le truc qui fait que l’opérateur bloque les communications venant d’autres hôtes (ou demande de payer pour autoriser cette technique).

Du routage et du NAT

On part dans la technique, on part dans le réseau. Qu’est-ce qui différencie une trame émise du smartphone vers l’extérieur en passant par le réseau de données (3G) d’une trame émise d’un autre appareil, passant par le smartphone pour atteindre la même destination ?

Quand on fait du tethering sous Android, par défaut, l’interface Wi-Fi donne accès au réseau 192.168.X.0/24 et l’interface PPP (3G) au réseau 10.Y.Z.0/24 (réseau de l’opérateur). Si on regarde la table de routage du smartphone, on voit bien que l’interface PPP sert de passerelle par défaut. Toutes les communications non internes sont donc techniquement redirigées vers le réseau de l’opérateur (j’ai des doutes là-dessus, une capture de trames semble me contredire). On a donc du routage et par conséquent, des modifications au niveau de la couche 3 lors de l’acheminement.

De plus, on a 2 interfaces qui donnent sur des réseaux privés (10.0.0.0/8 et 192.168.0.0/16). On a donc obligatoirement de la translation d’adresses et de ports (NAT/PAT) puisque les adresses en question ne peuvent pas être routées. La couche 4 est donc également impactée… Sauf qu’on peut envoyer des paquets ICMP depuis son smartphone en passant par le réseau de données. Or, qui dit ICMP dit niveau 3. Il n’y a pas de niveau 4, on peut donc supposer que la couche transport (4) ne joue aucun rôle dans l’identification des paquets venant d’un hôte autre que le smartphone.

Par ailleurs, le NAT fait que l’adresse source du réseau Wi-Fi est remplacée par l’adresse source de l’interface PPP lors du routage. C’est donc comme si l’émetteur original était le smartphone. Il se pourrait donc que ce soit une autre information de la couche 3 qui soit la « taupe ». À part le TTL, je ne vois pas. Pourquoi le TTL ? Parce que lors du routage, il est décrémenté et vaut donc 63 ou 127 quand le paquet est envoyé sur le réseau de l’opérateur, alors qu’il vaudrait 64 ou 128 si le dit paquet provenait du smartphone. J’ai donc essayé d’envoyer une requête ICMP avec scapy en augmentant de 1 le TTL de base depuis mon hôte connecté en Wi-Fi, mais ça ne fonctionne pas mieux.

Si quelqu’un réussit à trouver une explication qui tient la route, même une vague idée, n’hésitez surtout pas à la proposer !

%d blogueurs aiment cette page :