Salut,Ah, pas fait gaffe à cela. Même pas vu ce sujet avant.
Je crois que cela fait des années que ce n'est pas le cas sur l'apn des forfaits pour hotspots. De mémoire, je réussissais à avoir pirate bay (impossible avec les dns des opérateurs).
Je ne suis plus client Bouygues (et ce MITM est y pour beaucoup dans ma résiliation. Le rapport qualité prix aussi) donc je peux pas retester. Mais pour rappel j'ai découvert ça fin 2016 (entre septembre et décembre) et j'ai refait des tests quelques mois plus tard. Début 2017 c'était encore d'actualité. On doit pas avoir la même définition de « plusieurs années »…
Tu prétend que ce ce que j'ai constaté serait faux en te basant **uniquement** sur ta mémoire et le fait que tu as une fois réussi à accéder à tpb, sur on ne sait pas trop quel type d'abonnement/forfait… sachant que pb a paquets de nom de domaines justement pour contourner les filtrages par DNS (quelque chose me dit que ça fonctionne et que les FAI n'arrivent pas à suivre pour tous les bloquer)… C'est tout sauf un test digne de ce nom
Donc pour donner les détails,
je resors mes tests faits début 2017En essayant de comprendre pourquoi TLSA Validator me retournait que des erreurs pour des domaines portant une signature valide (debian.org, freebsd.org) ainsi que des domaines n,ayant pas du tout DNSSEC configuré…
Test sur ligne 3G/4G BandYou en configurant un DNS tierce supportant DNSSEC (TSLA Validator utisant le résolveur configuré sur l'OS)
Test sur ligne fixe d'un autre opérateur en configurant le même DNS tierce supportant DNSSEC (TSLA Validator utisant le résolveur configuré sur l'OS)
Mes tests sont en 3 étapes :
- Interroger un résolveur censé retourné une réponse DNSSEC valide (résolveur d'un FAI associatif)) en demandant explicitement la les champs liés à DNSSEC :Résultat attendu : RRSIG valide.Résultat : pas de RRSIG.Sur une ligne fixe d'un autre opérateur 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
J'ai le résultat attendu est bien là.
Sur une ligne 3g/4G BandYou (bouygues) 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
Même requête en interrogeant le même résolveur mais sur une ligne mobile Bouygues… RRSIG a disparu de la réponse… C'est pas le même résolveur DNS qui répond
- Interroger plusieurs résolveur qui n'existent pas (IP qui pointe vers rien ou autre chose que des résolveur)s publiques :Résultat attendu : Timeout valide.Résultat : réponse à ma requête DNS avec comme IP source des paquet, l'IP foireuse que j'ai interrogé à chaque fois.Sur une ligne fixe d'un autre opérateur 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
J'ai le résultat attendu est bien là. C'est normal qui trouve rien : 138.2.4.6 n'étant pas un résolveur public
Sur une ligne 3g/4G BandYou (bouygues) 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: 1pMrJSt9LLQPS
;; 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
Tiens donc… J'ai bien une réponse avec les IP de debian.org. Mais SANS le champ RRSIG que j'ai pourtant explicitement demandé (option +dnssec) et que debian.org a évidemment dans ses enregistrement DNS.
- Scan nmap de l'IP interrogéeTest qui montraient clairement qu'il y a avait un proxy avec un nom de domaine appartenant à Bouygues, entre moi et Internet (Du CGNAT très probablement) et que ce proxy montrait un port 53 (DNS) ouvert même si le serveur dont je scannait les ports n'a pas de port résolveur DNS public… Le port correspond probablement au résolveur DNS de Bouygues sur lequel le proxy redirige tous les requêtes adressées au port 53
Un nmap sur l'IP 138.2.4.6 qui n'est ni une IP appartenant à Bouygues Telecom ni un solveur DNS publique, me retourne les traces d'un des proxies/équipement NAT de Bouygues avec un port 53/TCP ouvert…
Ça sent la les redirections de certains paquets en fonction du port (53) va au résolveur DNS de bouygues, 25/TCP va vers le proxy SMTP [Service Info: Host: smtp-proxy-1b.bouyguesbox.fr] auxquels je n'ai jamais demandé à causer…)
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
Évidemment j'ai fais les tests avec
plusieurs noms de domaines et IP pour confirmer les résultats, mais pas à grand chose de tout conserver/publier, ça fait déjà un paquet d'infos à mettre en forme et à expliquer, pour moi, et à lire pour les autres…
LA **seule** explication logique et cohérente tous ces comportements, c'est que les équipements de Bouygues font du MITM sur DNS pour intercepter les requêtes et les rediriger vers le résolveur de Bouygues, qui les traitent et qui les revoient en prenant soin à l'adresse IP source (en mettant celle que j'ai interrogé plutôt que celle du serveur qui a effectivement répondu). Ça ressemble fortement à de la redirection de paquets + la réécriture d'IP avec du DNAT…