MITM as a Service 3G Edition by Bouygues, ou quand ton FAI bousille DNSSEC

Mise à jour Mars 2020 :
Plus de 3 ans après ma découverte de MITM sur DNS chez Bouygues Telecom, le topic que j’ai lancé sur lafibre.info – suite au conseil d’une personne qui m’a informé qu’un des contributeurs du forum était à l’époque employé de Bouygues – est encore actif. On y apprend que Bouygues Telecom à enfin arrêté avec cette connerie d’interception de requêtes DNS, et aussi SMTP (même si en pratique le port TCP 25 n’est pas utilisé, ça reste dégueulasse). Comme quoi, en gueulant au bon endroit et en étant plusieurs à demander des comptes à une entreprise sur ses pratiques, on peut obtenir des résultats, même à 5 gus dans un garage… C’est une petite victoire, petite parce que le mieux reste encore de laisser tomber les résolveurs qui communiquent en claire et configurer un résolveur DNS-over-HTTP ou DNS-over-TLS, technos qui commencent à se répandre, (son propre résolveur, c’est encore mieux). Mais victoire quand même, parce qu’en pratique, on est encore loin du jour où 100% des résolveurs et des clients/OS utilisés par le grand public utilisent par défaut (sans bidouilles/logiciels tierces) du DoH/DoT à la place d’interroger des résolveurs DNS en clair. Donc cette victoire sera utile pour les gens utilisant des appareils avec des OS ne supportant pas DoH/DoT (vieux OS, notamment mobiles, que les fabricants ne maintiennent pas forcément correctement pour mieux vendre de nouveaux appareils… ), ou qui n’ont aucune  idée de ce qu’est un résolveur DNS et comment en choisir et le configurer sur sa machine. Merci à tous les gens qui ont relayé mon article, qui ont fait des tests plus ou moins régulièrement, en publiant les résultats, qui ont contribué de façon constructive au topic sur lafibre.info, et qui ont demandé des comptes à Bouygues. Sans oublier de rester vigilants concernant les atteintes à la neutralité du Net et autres pratqiues dégueulasses, cette victoire se savoure avec une bonne boisson caféinée.

Mise à jour Janvier 2020 :
Bouygues Telecom à complètement viré le support de DNSSEC de ses résolveurs DNS forcés par MITM pour les utilisateurs des forfaits 3G/4G mobiles, d’après les tests effectués par un abonné, qui a publié les résultats sur lafibre.info. Donc il n’y par définition plus d’erreurs relatives à DNSSEC, mais le MITM sur DNS est toujours d’actualité.

Introduction

Pour avoir le support de DANE/TLSA sous Firefox, j’utilise depuis certain temps un addon nommé DNSSEC/TLSA Validator, qui permet en plus de vérifier la validité des signatures DNSSEC (sur les sites qui le supportent) en un coup d’œil. Si la signature est valide, les icônes clé (DNSSEC) et cadenas (HTTPS) apparaissent en vert, si elle erronée, l’icône de la clé apparaît en rouge et cadenas rouge ou gris (HTTP :// à la place du cadenas, en gris. HTTPS, cadenas rouge), comme dans les exemples suivants. Et si le serveur web visité ne supporte pas du tout DNSSEC, les 2 icônes sont en gris.

Un test avec le site dnssec-failed.org, dont la signature DNS est volontairement erronée, pour permettre aux sysadmin de faire des tests en rapport avec DNSSEC, nous donne le résultat attendu.
TLSA Validator: DNSSEC fail
Jusqu’à là, tout va bien, sauf qu’un jour, en utilisant une connexion 3G de Bouygues Telecom, je me suis rendu compte que j’avais un comportement bizarre au niveau de DNSSEC, pour à peu près tous les noms de domaines, j’ai les deux icônes en rouge (signature erronée) un peu partout, aussi bien sur les sites avec une bonne signature de DNSSEC (debian.org, freebsd.org… ) que des sites ne supportant pas du tout DNSSEC. J’ai décidé de faire les tests plus détaillés.

Voici l’exemple avec debian.org sur une connexion 3G Bouygues :
DNSSEC MITM: Bogus signature
Voici l’exemple avec debian.org sur une connexion fixe, en utilisant le résolveur DNS de Lorraine Data Network (LDN) pour être de ne pas tomber sur un autre DNS foireux :

J’ai découvert ça il y a plusieurs mois, mais c’est toujours valable, je viens de refaire des tests… De toute évidence, c’est pas normal, du coup, j’ai essayé d’en savoir plus.

Sortez le popcorn et mettez vous bien à l’aise…

Tout d’abord, on fait un dig pour demander l’enregistrement RRSIG, pour debian.org, puis pour dnssec-failed.org, d’abord avec la connexion 3G Bouygues, ensuite avec une connexion propre, dans les 2 cas en interrogeant le serveur DNS de LDN (parce que je sais qu’il supporte DNSSEC). Le résultat est intéressant…

– Connexion Bouygues 3G

Pour debian.org :

me@laptop:~$ dig @80.67.188.188 +dnssec +cdflag debian.org ; <<>> DiG <VERSION> <<>> @80.67.188.188 +dnssec +cdflag debian.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49096 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;debian.org. IN A ;; ANSWER SECTION: debian.org. 26 IN A 5.153.231.4 debian.org. 26 IN A 128.31.0.62 debian.org. 26 IN A 130.89.148.14 debian.org. 26 IN A 140.211.15.34 debian.org. 26 IN A 149.20.20.22 ;; Query time: 704 msec ;; SERVER: 80.67.188.188#53(80.67.188.188) ;; WHEN: Thu Sep 22 20:14:32 CEST 2016 ;; MSG SIZE rcvd: 119

On utilise le +cdflag (Checking Disabled) pour dire au serveur DNS de donner le champs RRSIG sans vérifier la signature. Sans quoi, si la signature est erronée, on aura comme réponse status: SERVFAIL, et aucun champs DNS, même pas les IP. Or là, on pas du tout de champs RRSIG pour un nom de domaine qui a pourtant une signature valide…

Puis pour dnssec-failed.org :

me@laptop:~$ dig @80.67.188.188 +dnssec +cdflag www.dnssec-failed.org

; <<>> DiG <VERSION> <<>> @80.67.188.188 +dnssec +cdflag www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6583
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org. IN A

;; ANSWER SECTION:
www.dnssec-failed.org. 6747 IN A 68.87.109.242
www.dnssec-failed.org. 6747 IN A 69.252.193.191

;; Query time: 224 msec
;; SERVER: 80.67.188.188#53(80.67.188.188)
;; WHEN: Thu Sep 22 20:16:46 CEST 2016
;; MSG SIZE rcvd: 8

Exactement le même résultat… or on sait que ce nom de domaine a une signature DNSSEC (volontairement erronée, mais existante), on devrait avoir un champs RRSIG car on a mis l’option +cdflag.

D’ailleurs, si vous avez l’habitude d’utiliser dig, vous avez remarqué que vers la fin de la réponse, il y a l’IP du serveur qui répond, et que ici, on a bien l’IP du serveur interrogé… Et pourtant j’insiste, le résolveur DNS interrogé supporte DNSSEC.

On refait les mêmes tests, sans l’option +cdflag, sur une connexion fixe, car on veut justement vérifier la validité de la signature.

– Connexion fixe

Pour debian.org :

me@laptop:~$ dig @80.67.188.188 +dnssec debian.org

; <<>> DiG <VERSION> <<>> @80.67.188.188 +dnssec debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22069
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;debian.org. IN A

;; ANSWER SECTION:
debian.org. 109 IN A 140.211.15.34
debian.org. 109 IN A 149.20.20.22
debian.org. 109 IN A 5.153.231.4
debian.org. 109 IN A 128.31.0.62
debian.org. 109 IN A 130.89.148.14
debian.org. 109 IN RRSIG A 8 2 300 20161031065252 20160921055252 7866 debian.org. ZERtXROfGeAS+NYTa3BaDk/Q41QkuiimerRJ9+6WMSIeKNUnfPOJR01+ Y1KzxZ9bxhVJMaeLKeYs7eQmmOFiv1tIVb5fgQRjMdMn+1QyZZEz84Ru 9K5Udohml9wboEsQNEv+ejTSVjyDoZHwdBbZjZ9ToOt4v9bGLgCAXMu/ FjkFXJDyk5wJs3g9VgnrAYx3oHoIQFVALtu8u+bktVvDsHv+8rXbjkBv e6GkB1vAvh5HQ0X/cQbQ0lekFI8FtXFT

;; Query time: 51 msec
;; SERVER: 80.67.188.188#53(80.67.188.188)
;; WHEN: Thu Sep 22 19:54:48 CEST 2016
;; MSG SIZE rcvd: 353

Et là, on a une signature DNSSEC…

Puis pour dnssec-failed.org :

me@laptop:~$ dig @80.67.188.188 +dnssec www.dnssec-failed.org ; <<>> DiG <VERSION> <<>> @80.67.188.188 +dnssec www.dnssec-failed.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5061 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; Query time: 147 msec ;; SERVER: 80.67.188.188#53(80.67.188.188) ;; WHEN: Thu Sep 22 19:56:34 CEST 2016 ;; MSG SIZE rcvd: 50

On a exactement le comportement attendu, à savoir le refus de résolution d’adresse avec le message d’erreur status: SERVFAIL. En refaisant ce dernier test avec l’option +cdflag, on aura les IP et le champs RRSIG (certes signature invalide mais visible quand même).

A ce stade, ça pue déjà pas mal le Man In The Middle, je soupçonne très fortement Bouygues d’utiliser des proxies, qui en plus de faire du MITM, modifient les adresses sources pour mentir, en mettant l’IP du serveur interrogé pour chaque requête (règles iptables DNAT), voire champs SERVER: 80.67.188.188#53 (80.67.188.188).

Mais non, tu vois la mal partout, il y a une autre explication !

J’en doute très fort, mais supposons qu’il y a une autre explication, et que je soit parano… Alors on refait des tests suivants sur la connexion Bouygues 3G, avec des IP prises au hasard.
Le test est simple, prendre une IP au hasard, supposer que c’est un résolveur DNS, et l’utiliser dans la commande dig, pour interroger le serveur correspondant… et ensuite faire un nmap sur cette IP pour voir ce que c’est comme serveur, et on peut même faire un whois, pour bien voir que ça n’appartient pas aux ranges Bouygues Telecom.

Tomber du premier coup sur un vrai résolveur DNS public, j’y crois pas trop mais j’ai quand même fait le test avec 5 ou 6 différentes en tout (les 3 tests, dig, nmap et whois pour chaque IP), avec toujours le même résultat que l’exemple suivant, Je met qu’un seul pour ne pas écrire un pavé. L’exemple en question concerne l’IP 138.2.4.6, prise vraiment au hasard, qui appartient au range d’Oracle. Les autres IP que j’ai testé appartiennent entre autre à Cogent, IANA et j’en passe… avec d’interroger le serveur avec dig sur la connexion Bouygues 3G, commençons par dissiper le doute, on le fait d’abord sur une connexion fixe, certes pas la plus neutre du monde, mais un peu plus propre que la 3G chez Bouygues.

dig @138.2.4.6 +dnssec debian.org

; <<>> DiG <VERSION> <<>> @138.2.4.6 +dnssec debian.org
 ; (1 server found)
 ;; global options: +cmd
 ;; connection timed out; no servers could be reached

Voilà, ça répond pas, car ce n’est pas un résolveur DNS public, voir pas un résolveur DNS du tout. Pourtant, le même test chez Bouygues donne… une réponse, très similaire au test réalisée plus haut, avec le résolveur de LDN.

me@linuxbox:~$ dig @138.2.4.6 +dnssec debian.org

; <<>> DiG <VERSION> <<>> @138.2.4.6 +dnssec debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14422
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debian.org. IN A

;; ANSWER SECTION:
debian.org. 300 IN A 140.211.15.34
debian.org. 300 IN A 149.20.20.22
debian.org. 300 IN A 5.153.231.4
debian.org. 300 IN A 128.31.0.62
debian.org. 300 IN A 130.89.148.14

;; Query time: 229 msec
;; SERVER: 138.2.4.6#53(138.2.4.6)
;; WHEN: <DATE>
;; MSG SIZE rcvd: 119

Une réponse à une requête DNS en interrogeant un serveur qui ne fait pas de DNS, voir pas un serveur du tout (IP prise au hasard pour rappel), il y a qu’une explication, un proxy qui fait du Man-In-The-Middle, intercepte et traite tous les requêtes DNS, en mentant sur l’origine des paquets réponses (voire le champs ;; SERVER:)

J’y crois pas, pourquoi ils se seraient donner tout ce mal ?

Je vous épargne la sortie du whois, pour vérifier que ce range d’IP appartient bien à Oracle et non pas à Bouygues Telecom… c’est vérifiable depuis n’importe quelle connexion Internet. Par contre, la sortie de nmap, effectué sur le réseau 3G de Bouygues, est beaucoup plus intéressante… Avant d’aller plus loin, une précision, si vous essayer nmap -Pn 138.2.4.6 sur une connexion à peu près propre, sans proxy qui fait du MITM, vous aurez comme réponse All 1000 scanned ports on 138.2.4.6 are filtered, un serveur DNS (port 53) qui répond sur Internet, mais dont tous les 1000 1ers ports (1-1000) sont filtrés, c’est quand même curieux…

Sur une connexion 3G Bouygues, ça donne ça…

me@linuxbox:~$ sudo nmap -A 138.2.4.6

Starting Nmap <VERSION> ( http://nmap.org ) at <DATE>
Nmap scan report for 138.2.4.6
Host is up (0.13s latency).
Not shown: 993 filtered ports
PORT STATE SERVICE VERSION
21/tcp open ftp?
|_ftp-bounce: no banner
25/tcp open smtp Postfix smtpd
|_smtp-commands: Couldn't establish connection on port 25
53/tcp open domain ISC BIND hostmaster
80/tcp open http?
554/tcp open rtsp?
1723/tcp open pptp?
|_pptp-version: ERROR: Script execution failed (use -d to debug)
8080/tcp open http-proxy?
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
No OS matches for host
Network Distance: 4 hops
Service Info: Host: smtp-proxy-1b.bouyguesbox.fr

TRACEROUTE (using port 80/tcp)
HOP RTT ADDRESS
1 2.36 ms 10.42.0.1
2 75.44 ms 10.125.12.239
3 81.89 ms 10.125.14.234
4 94.37 ms 138.2.4.6

OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 358.62 seconds

Tout d’un coup, il y a plein de services qui tournent… Mais surtout, il y a un bon gros champs Service Info qui ne laisse aucun pas de doute sur le fait qu’on a bien à faire à proxy (pas si) transparent (que ça), appartenant à Bouygues Telecom

Service Info: Host: smtp-proxy-1b.bouyguesbox.fr

Et sur lequel il y a bien un serveur DNS prêt à intercepter vos requêtes, et à les rediriger vers le résolveur DNS de Bouygues, qui répond à la place du serveur qu’on croit avoir interrogé, en cassant DNSSEC au passage…

53/tcp open domain ISC BIND hostmaster

Mais encore ?

On sait qu’il y a un DNS menteur, qui ne semble pas supporter DNSSEC (Le champs RRSIG dans les requêtes dig qui finit toujours chez Dave Null), mais on sait toujours pas pourquoi on reçoit des signatures erronés d’après DNSSEC/TLSA Validator… là pour le coup, j’ai pas une explication aussi complète, mais peut-être un début d’explication (conf foireuse pour la partie DNSSEC?)
Lors des requêtes DNS, soit avec dig +dnssec soit DNSSEC/TLSA Validator (j’ai pas determiné le moment exact), je reçois des paquets DNSKEY, contenant une clé publique, et issus avec comme IP source, plusieurs IP délirantes, appartenant à des ranges/entités différentes…
Wireshark: DNSKEY
Je sais pas exactement ce que Bouygues Telecom fout, ni pourquoi j’ai clés DNSSEC qui sont fausses (erreurs DNSSEC visibles sur TLSA Validator pour tous les sites visités depuis la connexion Bouygues mobile concernée par le MITM, et seulement depuis ladire connexion), Mais dans tous les cas, ça pue. En tout cas si quelqu’un à plus d’infos à ce sujet, ça m’intéresse…

Conclusion

Ça pue très fort, parce qu’on peut pas utilser le DNS qu’on veut. Quelque soit celui configuré sur el système, le proxy de Bouygues intercepte les requêtes DNS, pour que le résolveur de Bougyes y réponde à la place du résolveur qu’on voulait interroger, et à l’insu de l’utilisateur.

Et je pense pas que Bouygues soit le seul à faire ce genre de magouilles. Si vous avez l’occasion de faire des tests sur des connexions agrumes télécom, SFR, ou encore Free, les retours m’intéressent. La solution la plus simple que je vois actuellement (2017), c’est de passer par un tunnel OpenVPN [1], dont le point de sortie doit se situer sur le même LAN, voire sur la même machine (de confiance) que le résolveur DNS qu’on utilise… il reste le problème de la requête première requête DNS pour établir la connexion VPN. Soit il faudra se connecter au VPN en spécifiant directement l’IP publique du serveur VPN, soit il faudra utiliser /etc/hosts (accès root évidemment nécessaire).

[1] Si c’est pas filtré, j’ai pas encore eu l’occasion de tester. Mais si jamais c’est filtré, on peut tenter de passer le flux VPN dans le port TCP 443, mais ça nécessite que le serveur utilisé soit configuré pour, et ça risque de créer de l’overhead au niveau de la bande passante/quantité de data utilisée (Il reste à vérifier si ce surplus reste dans la limite du raisonnable).

40 Replies to “MITM as a Service 3G Edition by Bouygues, ou quand ton FAI bousille DNSSEC”

  1. Cadenas + clé en vert quand je consulte debian.org. L’ADSL free.fr ne trafique pas les requêtes DNS.
    Quand je consulte cette page, le cadenas et la clé sont affichés avec un sens interdit rouge. Cet article serait-il un faux ?
    🙂

    prêt à intercepter vous requêtes -> prêt à intercepter vos requêtes
    (il y en a d’autres, j’ai la flemme de les signaler). Peut-être que l’extension Grammalecte aiderait ?

    1. TuxFamily ne supporte pas DNSSEC/TLSA, tu devrais avoir des icônes grises normalement. Tu utilise quel DNS? celui du FAI?

      PS: Alors oui, si je me relis pas 15 fois, je laisse trainer beaucoup de faute, je repasserai sur l’article plus tard quand j’aurais du temps durant la semaine.

  2. Ton article est top, juste un peu de correction d’orthographe mon ami : -).

    Je pense que pourla 3G, les operateurs telco donnent une IP NATé. Je suis pas certain que IPv4 soit adaptable au mobile, c’est à dire te deplacer sans changer d’IP. En IPv6 on devrait plus avoir ce probleme. A voir du coté des pro reseau 3G.

    1. Merci
      Oui, en 3G c’est bien une IP NATée (Carrier-Grade NAT, du NAT à grande échelle) sur les mobiles, c’est des adresses en 10.x.y.z attribués aux machines clients. Par contre, résoudre le problème avec IPv6, j’y compte pas trop
      – J’ai jamais vu d’IPv6 en mobile (et les forfaits pro, je peux essayer, c’est trop cher)
      – Les devices mobiles (en fonction de l’OS et de la version) peuvent ne pas supporter, ou pas complètement IPv6
      – On peut aussi faire du NAT en IPv6, même si c’est stupide, il y en a qui le font…
      Ça m’étonnerai que les FAI refusent de passer en IPv6 pour les réseaux mobiles, pour continuer à abuser du CGNAT, avec les mêmes excuses pourries qui sortent quand ils font pas du IPv6 en ADSL/fibre “c’est complikay” et autre “c’est trop cher pour l’instant”

      Conclusion : La solution passe forcément par actions coté user, comme tenter d’utiliser un VPN. Faudra pas compter sur les FAI commerciaux pour arrêter de faire n’importe quoi… dommage, les FAI associatifs ne font que du Internet fixe, ça serai intéressant si on avait les moyens de faire de faire du Net sur mobile, pour justement éviter ce genre de magouilles.

      Oui, je compte repasser sur l’article plus tard dans la semaine pour corriger les fautes, je l’ai écrit un peu vite 🙂

    2. Là aussi, il manque quelques accents et mots de liaison. Je sais bien que la réforme récente permet d’écrire en SMS mais quand même.

  3. Salut,

    Un test ultra rapide sur une connexion 4G de free :

    dig @80.67.188.188 +dnssec +cdflag debian.org

    ; <> DiG 9.9.5-9+deb8u9-Debian <> @80.67.188.188 +dnssec +cdflag debian.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43193
    ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; QUESTION SECTION:
    ;debian.org. IN A

    ;; ANSWER SECTION:
    debian.org. 300 IN A 140.211.166.202
    debian.org. 300 IN A 128.31.0.62
    debian.org. 300 IN A 149.20.4.15
    debian.org. 300 IN A 130.89.148.14
    debian.org. 300 IN A 5.153.231.4
    debian.org. 300 IN RRSIG A 8 2 300 20170407103449 20170226093449 53598 debian.org. kk53o6XM+LLvxdZKgM2VFKlONt/C9ACaR0i/F9B5nstS0kwbo05BCl2M znIOvPd4cB9041Vct2Ni/jIeDsAg71kgXaZpWOZ5uJcmeMA9Im1lmrgY npXl/7FOFlyvUXleYmW5WyRzKocp1IrZwoyAQyG3Btgfuwf80zRrmgXE IP0rH9SKaDBSeCD1F3zSRJuzhK9yDHzdSKJ5ybBaUlCOAYXENEN4fH5m /Z4y/I7XGLoC89j9YqvoChCDclGwt4wB

    ;; Query time: 120 msec
    ;; SERVER: 80.67.188.188#53(80.67.188.188)
    ;; WHEN: Mon Feb 27 08:24:51 CET 2017
    ;; MSG SIZE rcvd: 353

    1. Donc t’as bien un champs RRSIG. Mais ça dit pas si c’est le résolveur de Free qui répond (et que du coup le DNSSEC est supporté) ou c’est bien le résolveur de LDN.

      Pour avoir un peu plus d’infos (mais sans que ce soit forcément une réponse définitive), tu peux éventuellement de comparer avec dig +dnssec debian.org, pour interroger directement le DNS par défaut de ton appareil mobile (donc celui de Free)

  4. Pour Tuxfamily, j’ai aussi des icônes grises avec des sens interdits.
    Pour le DNS, c’est Free qui s’en occupe, je suppose. Je le vois comment ?

    1. Si t’as rien changé sur ton système GNU/Linux, tu devrais avoir dans ton /etc/resolv.conf quelque chose comme nameserver IP_de_tabox (et éventuellement d’autres lignes). Et il y a de grandes choses, voire 100% de chance pour que ta box soit configurée pour interroger les résolveurs DNS de Free. A peu près tous les FAI imposent plus ou moins leurs DNS par défaut.

      Je connais pas la Freebox mais dans l’interface tu peux probablement voir les IP qui sont configurées, et peut-être les changer. Mais il faut voir si les DNS sont effectivement changés ou si c’est toujours le résolveur du FAI qui répondra

      1. Je n’ai rien dans ma configuration.
        $ cat /etc/resolv.conf
        affiche :
        # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
        # DO NOT EDIT THIS FILE BY HAND — YOUR CHANGES WILL BE OVERWRITTEN
        nameserver 127.0.1.1

        Dans l’interface de ma freebox, j’ai la possibilité de paramétrer un nom de domaine donc d’activer un serveur DNS mais à part ça, je n’ai pas trouvé où sont paramétrés les DNS utilisés. Je suppose que ce sont les DNS de Free qui sont utilisés par défaut.

        1. Si, t’as nameserver 127.0.1.1, mais c’est bizarre, ça veut dire que t’as machine s’interroge elle même pour le DNS, c’est la conf à avoir quand t’as un résolveur DNS qui tourne sur ta machine. Du coup c’est un peu bizarre, mais effectivement je suppose que tu utilise les DNS de Free puisque c’est probablement la config par défaut de ta box

          1. Ce type dns se retrouve avec resolvconf+NetworkManager… Typique des ubuntu likes. Pour trouver le dns utilisé faut regarder dans les paramètres réseau. ☺

          2. Merci pour l’info. Je connais as très bien les confs par défauts des ubuntu et dérivées.
            Sous Debian, il n y pas de dns-masq ou équivalent par préinstallé et préconfiguré. Par défaut, nameserver prend l’IP de routeur/gateway/de la machinbox à la quelle on se connecte.

  5. J’ai apparemment un dnsmasq qui tourne mais il écoute une adresse 127.0.1.1 qui n’est pas dans mon réseau :

    $ ps aux|grep dns
    nobody 1346 0.0 0.0 52948 4200 ? S 21:51 0:00 /usr/sbin/dnsmasq –no-resolv –keep-in-foreground –no-hosts –bind-interfaces –pid-file=/var/run/NetworkManager/dnsmasq.pid –listen-address=127.0.1.1 –cache-size=0 –conf-file=/dev/null –proxy-dnssec –enable-dbus=org.freedesktop.NetworkManager.dnsmasq –conf-dir=/etc/NetworkManager/dnsmasq.d
    david 3529 0.0 0.1 361928 9096 ? Sl 22:03 0:00 /usr/lib/gvfs/gvfsd-dnssd –spawner :1.11 /org/gtk/gvfs/exec_spaw/13

  6. Ah si, 127.0.1.1, c’est moi (je viens d’apprendre que c’est aussi une adresse loopback, on en apprend tous les jours), dnsmask m’écoute donc bien.

    1. Oui, par convention pour pas avoir une tetrachiée d’IP différentes, on a décidé que le loopback, c’est 127.0.0.1, mais en fait, loopback va de 127.0.0.1 à 127.255.255.254.

  7. A new Bouygues customer here. Just discovered that my unbound resolver stopped validating after the switch to Bouygues. Here’s something else for you to muse over:

    telnet debian.org 25

    Cheers and sorry for my French.

  8. $ telnet smtp.gmail.com 25
    Trying 66.102.1.108…
    Connected to smtp.gmail.com.
    Escape character is ‘^]’.
    220 smtp-proxy-2y.bouyguesbox.fr ESMTP Postfix
    quit
    221 2.0.0 Bye
    Connection closed by foreign host.

    1. port 25 “magic smtp” isn’t that bad… I doubt you were planning to send credentials without SSL and sending email from your phone over mobile data without credentials through a server other than your mobile operator is unlikely to be a great success. This automated redirect actually helps your email go out in this case 😉

      1. I wasn’t planning to send my credentials without TLS. I was checking whether there is a proxy or not…

    2. J’ai quitté bouygues a cause de ça.
      Impossible d’envoyer des mails en 3G a cause des champs SPF.

      1. SPF n’a rien avoir avec Bouygues et leurs MITM… C’est un mécanisme de validation qui vérifie si l’adresse de l’expéditeur est légitime, ou si elle est forgée

  9. Bonjour,
    Soyez prudents avec vos nmap sur des adresses prises au hasard. De mémoire il me semble avoir lu, il y a un moment, un article qui disait que c’est pas trop bien vu par certains admins des serveurs questionnés. Cela peut dans certains cas, être considéré comme une “attaque”
    Merci pour cet article interessant

    1. Ça n’a rien d’une attaque, c’est juste demander au serveur « qui est-tu » pour savoir si le serveur attendu/légitime qui répond, ou c’est un proxy qui fait du MITM. Les admins qui considèrent ça comme “une attaque” devraient sérieusement à songer à changer de métier.

      D’ailleurs, ils ne voient pas les requêtes nmap dans leurs logs parce que les requêtes n’arrivent jamais aux serveurs en question, à cause proxy de Bouygues, qui redirige les requêtes vers des machines de Bouygues, qui semblent être derrière un NAT de Bouygues (le proxy fait NAT pour le résolveur DNS et éventuellement d’autres machines)

  10. Avec 4G Orange avec debian.org
    root@PC-Flubox:~# dig @80.67.188.188 +dnssec +cdflag debian.org

    ; <> DiG 9.10.3-P4-Ubuntu <> @80.67.188.188 +dnssec +cdflag debian.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10479
    ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; QUESTION SECTION:
    ;debian.org. IN A

    ;; ANSWER SECTION:
    debian.org. 273 IN A 128.31.0.62
    debian.org. 273 IN A 140.211.166.202
    debian.org. 273 IN A 130.89.148.14
    debian.org. 273 IN A 5.153.231.4
    debian.org. 273 IN A 149.20.4.15
    debian.org. 273 IN RRSIG A 8 2 300 20170712171726 20170602161726 53598 debian.org. akRwHRzqclshkrrhvEU+xCxYmRN2ukLDU9z3l7C/k/JrwkqfsH8Zq2lq Qju4/hkrKQfANwAv3SuKhNVVARYZXcaIYiQ27F56gmYFhJ0+y1ANjc2p qzeRKrSCzU4HdhU9Kp6ObFN7PamD7K7Et1sBUAfG8UJB26/qafovumIk yL8q9KqiqVZfK+ZlYul+1ywZJBkaf3uOWZbyTQjcgnhKQ0WEyE8pfXyc QmiGwzlnSkf5gXMO2nhotH+wtnrT4EOM

    ;; Query time: 79 msec
    ;; SERVER: 80.67.188.188#53(80.67.188.188)
    ;; WHEN: Mon Jun 05 12:00:40 DST 2017
    ;; MSG SIZE rcvd: 353

  11. Bonjour,

    Chez numericable c’est moche aussi sur une connexion en câble :

    $ dig @89.2.0.1 +dnssec +cdflag debian.org

    ; <> DiG 9.8.3-P1 <> @89.2.0.1 +dnssec +cdflag debian.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45888
    ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4000
    ;; QUESTION SECTION:
    ;debian.org. IN A

    ;; ANSWER SECTION:
    debian.org. 300 IN A 5.153.231.4
    debian.org. 300 IN A 128.31.0.62
    debian.org. 300 IN A 130.89.148.14
    debian.org. 300 IN A 140.211.166.202
    debian.org. 300 IN A 149.20.4.15

    ;; Query time: 13 msec
    ;; SERVER: 89.2.0.1#53(89.2.0.1)
    ;; WHEN: Wed Jun 28 11:26:27 2017
    ;; MSG SIZE rcvd: 119

    En revanche c'est juste du DNS menteur pas de proxyfication sur tout et n'importe quoi comme avec Bouygues en 3G.

  12. Nan mais le gars qui veut utiliser un serveur DNS autre que son FAI….
    C’est pour passer outre la censure par blocage DNS des sites terroristes hein ?
    C’est interdit ! Allez hop, encore un dont on a des raisons sérieuses de penser qu’il va nous exploser a la geule. Enfermez le ! (Chez lui, si possible, c’est moins cher)

    ;D

  13. Bonjour,

    Tu mets le doigt sur un truc tout simplement a-bo-mi-nable !

    Bouygues doit utiliser des techniques niveau IP pour rediriger tout les paquets en udp/53 vers leur serveur (par exemple chez Cisco : http://www.cisco.com/en/US/docs/ios-xml/ios/isg/configuration/15-2s/isg-l4-redirect.html).

    Je viens de tester avec une redirection de ce genre et un résolveur “lambda” : la valeur du champ “SERVER” dans la sortie de “dig” indique toujours l’IP du serveur que tu cherches à interroger (l’option “@” dans la ligne de commande). La redirection est donc transparente au moins tant qu’on ne s’attend pas à voir du DNSSEC et qu’il n’y en a pas.

    Ensuite, je pense que Bouygues a mis cela en place (et désactivé DNSSEC) pour faire mentir leur DNS. Pas de façon généralisée je pense, car tes résultats concernant debian.org sont cohérents (mais il faudrait valider, par exemple avec des sondes Atlas) mais potentiellement pour certains sites (les sites terroristes “main rouge” ou bien les sites de jeux en ligne interdits par l’ARJEL). Ca leur permet aussi de mieux savoir ce que font leurs gentils abonnés (même ceux qui configurent des résolveurs tiers).

    Enfin, vérifie la configuration de ton greffon “DNSSEC/TLSA Validator”. Par défaut, il utilise l’option “Without resolver” qui n’utilise pas le DNS (mais une API ?) pour obtenir les infos sur le domaine : ce qu’il attend et ce que te renvoie le résolveur menteur de Bouygues ne correspondent pas, ce qui occasionne l’alerte.

    Quelques test complémentaires à faire :
    – tester avec un résolveur DNS écoutant sur un autre port
    – tester avec un résolveur DNS écoutant en tcp/53
    – tester avec un résolveur DNS local (unbound par exemple)
    – refaire tes tests avec l’option ‘+trace’ de dig qui va décomposer la chaine de requêtes nécessaire à la résolution et à sa validation par DNSSEC
    – tester en changeant la configuration de ton greffon (bien que “Without resolver” soit la plus fiable dans ton cas, car elle recoupe des informations obtenues de sources et de façon différentes)

    Pour contourner tes problèmes, tu peux utiliser DNSCrypt (https://dnscrypt.org) ou bien te pencher les travaux du groupe de travail “drpive” de l’IETF et les RFCs 7858 et 8094.

    Pour terminer, les paquets de type DNSKEY que tu as capturés, correspondent certainement à l’envoi d’une des clé publiques (ZSK ou KSK) de la zone racine du DNS (le serveur D, l’un des plus redondés, est opéré par l’Université du Maryland : http://www.root-servers.org)

    1. Je vais checker DNSCrypt et les RFC mentionnés, merci

      Pour ce qui pas généralisé, enfait si. C’est juste que l’article serai illisible si je mettais 36 exemples, donc j’ai choisi debian.org comme example pour l’article, mais freebsd.org à le même problème, pleins d’autres sites aussi.

      Enfait j’ai découvert le problème en ayant des erreurs “Bogus DNSSEC Signature” pour le nom de domaine de mon serveur personnel. Or, il se trouve que ce site n’a même pas de DNSSEC (1). ça veut dire que non-seulement que la signature DNSSEC est foireuse pour noms de domaines ayant une conf DNSSEC valide, mais aussi pour les noms de noms n’ayant pas de configuration DNSSEC du tout.

      Après vérification, mon plugin TLSA Validator est bien configuré en without DNS. Je sais pas expliquer le pourquoi du comment. Mais ça empêche pas les erreurs “Bogus DNSSEC Signature”. D’ailleurs, après coup, j’ai aussi découvert une énorme conso CPU/lags violents de Firefox (2) uniquement quand j’utilise TLSA Validator sur une connexion 3G Bouygues
      – TLSA Validator fonctionne correctement sur d’autres connexions, et Firefox lagge pas.
      – Firefox arrête de lagger sur les connexions 3G Bouygues dès que je désactive TLSA Validator.

      1. Une conf DNSSEC propre requiert d’avoir un résolveur DNS dont on a la maîtrise. Et j’ai pas encore mon DNS perso par manque de temps/motivation/machine séparée de mon serveur qui héberge ledit site.
      2. Par lags violents, je parle pas des pages lentes à charger ou au lancement, mais dans la navigation dans l’interface, les changements d’onglets se comptent en plusieurs secondes… Firefox est certes consommateur en ressources, mais ne lagge pas comme ça dans des conditions de fonctionnements normale, en tout cas pas la version ESR/Iceweasel.

      1. > Pour ce qui pas généralisé, enfait si.

        Ce que “gjherbiet” à voulu dire c’est que le DNS ne ment pas de façon généralisée, dans ton exemple/tes tests (debian.org, freebsd.org, ..) il n’a pas de raison de mentir et de te rediriger sur une jolie page du FBI^WMinistère de la Pensée^WJustice (oups XD).

        > mon plugin TLSA Validator est bien configuré en without DNS. […] Mais ça empêche pas les erreurs “Bogus DNSSEC Signature”.

        C’est ce que “gjherbiet” explique, dans cette configuration le plugin ne fait pas confiance aux données issues de DNS pour la validation DNSSEC, donc comme le serveur ré-ecrit les réponses DNS il ne peut pas t’afficher une réponse “valide”.

        1. > Ce que “gjherbiet” à voulu dire c’est que le DNS ne ment pas de façon généralisée, dans ton exemple/tes tests (debian.org, freebsd.org, ..) il n’a pas de raison de mentir et de te rediriger sur une jolie page du FBI^WMinistère de la Pensée^WJustice (oups XD).

          Je parles pas de mentir sur l’IP pour me rediriger vers une page de la police de la pensée. Je parle de mentir sur les signatures DNSSEC.

          Et je maintiens que c’est généralisé. Tous le sites visités, quels qu’ils soient, qu’ils aient ou non un enregistrement DNSSEC (champs RRSIG), le résolveur de Bouygues me renvoient une signature erronée

          > C’est ce que “gjherbiet” explique, dans cette configuration le plugin ne fait pas confiance aux données issues de DNS pour la validation DNSSEC

          Oui… J’avais compris. C’est précisement pour ça que j’ai revérifier si j’avais bien la meilleure option possible dans ce cas de figure… Mais ça ne suffit pas à résoudre le problème.

          Après, je ne pourrais pas faire plus de tests car je me suis tiré de chez bouygues à cause de ces conneries… Non pas que la concurrence soit super clean non plus. mais c’est moins pire sur ce point (MITM DNS).

  14. Hello, pour infos je n’ai pas ces modifications sur le réseau avec la 4GBox de Bouygues.
    N’hésites pas à m’envoyer un mail si tu veux que je fasse des tests.

    1. Merci pour les infos. Je n’ai pas de box 4G, j’ai testé uniqument sur les réseaux mobiles (téléphone) en 3G et 4G¹

      [1] Note : Techniquement LTE n’est même pas de la 4G enfait, juste la dernière version de la 3G (appelé 3.9G). La 4G c’est LTE-Advanced (pas encore déployé en France sur les réseaux mobiles). Mais c’est un autre débat…

  15. Hier j’ai eu une expérience “amusante” avec Bouygues
    Sur une nouvelle machine où je n’avais pas encore changé les DNS, dans le milieu de l’apres midi sur toute les pages https chrome m’indiquais un problème de sécurité, le certificat https était remarqué comme falsifié chrome refusais donc d’afficher la page car détectant une attaque man in the middle.
    Un changement de DNS a résolu le problème et je n’avais pas prévu de poussé plus loin (flemme toussa)
    Mais ce matin j’avais de gros problème de débit j’ai donc du appeler mon bétonnier pour pouvoir résoudre ca, comme a chaque fois il disent faire une mise a jour de la box – un jour il faudra que je regarde si la version de firmware change ou même pas – donc j’en ai profité pour faire la demande pendant le redémarrage de ma box, ces réponses fu amusante mais peu concluante, on est retourner a ma box et apparemment il fallait transmettre mon dossier au équipes d’expert pour mon problème de débit j’ai donc demander a ajouté ma question sur les DNS pour avoir plus d’informations on verra bien s’ils me rappellent.

    1. Du coup t’as eu une réponse concernant le MITM DNS chez Bouygues ? J’imagine que non, mais sur un malentendu…

  16. Bonjour, j’ai fait un test avec VPN derrière un partage de connexion LTE (4G bullshit) c’est clair que c’est sale !
    ~$ dig @80.67.188.188 +dnssec +cdflag debian.org

    ; <> DiG 9.10.3-P4-Ubuntu <> @80.67.188.188 +dnssec +cdflag debian.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25188
    ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; QUESTION SECTION:
    ;debian.org. IN A

    ;; ANSWER SECTION:
    debian.org. 300 IN A 130.89.148.14
    debian.org. 300 IN A 128.31.0.62
    debian.org. 300 IN A 5.153.231.4
    debian.org. 300 IN A 149.20.4.15
    debian.org. 300 IN RRSIG A 8 2 300 20171121203307 20171012193307 52539 debian.org. bS5ij8J/yVtxRJWS9PEXu2vlMNh0VLeJLDdUfbegw0iNC1fxz90HLOk1 ouTjFFJtj0BT6d6WtuN2VKxnhNrD2EWixwxZj1nQlGgfz0433Pzib+4+ susjG0R9dN1Q8yL/IiJpGnCbhn4k25XOCAMNhaDKliGxWwWXtjz//MRA Ef8ihslaqgFoIiSY4/as+30zDH/XKw7qC4FEG5JXqGat2acsOvvz4P+P of2G360AW1kKRS8Lhl2mSVOhFX7Sx5Vw

    ;; Query time: 65 msec
    ;; SERVER: 80.67.188.188#53(80.67.188.188)
    ;; WHEN: Tue Oct 17 19:41:57 CEST 2017
    ;; MSG SIZE rcvd: 337

Comments are closed.