La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 5G/4G Bouygues Telecom => 
5G/4G Bouygues Telecom => Discussion démarrée par: DaveNull le 18 mars 2017 à 22:17:47
-
Bonjour
En constatant que DNSSEC ne fonctionne pas sur les accès 3G de BandYou, j'ai commencé à creuser pour identifier l'orgine du problème, et j'ai découvert que Bouygues se permet de faire un peu n'importe quoi à l'insu de ses client⋅e⋅s, en cassant au passage DNSSEC
Pratiques parmi les quels :
- Proxy intrusif
J'essaye de me connecter sur le port 25 d'OpenMailBox avec netcat, d'abord sur une connexion sans proxy SMTP
(https://lafibre.info/images/bytel/201703_dns_smtp_mitm_bouygues_1.png)
J'ai le bon serveur qui me répond
Puis je réessaye la même chose mais en 3G BandYou
(https://lafibre.info/images/bytel/201703_dns_smtp_mitm_bouygues_2.png)
L'image parle d'elle-même, c'est clairement pas le serveur interrogé qui répond…
- DNS menteur : Impossible d'utiliser un DNS tierce, c'est le DNS de Bouygues qui répond, en mentant sur l'IP source de la réponse
Même en interrogeant un faux résolveur DNS (dig @IP avec comme IP une adresse ne pointant vers aucun résolveur DNS réel), j'ai une réponse (voir lien donné plus bas) avec une IP source correspond à celle du serveur interrogé, or comme l'IP ne correspond à aucun résolveur réel, ça veut dire qu'il y a un équipement qui répond aux requêtes en forgeant les IP sources
- Paquets DNSSEC forgés : IP sources de paquets DNSKEY totalement fantaisistes, et clés sont foireuses, je reçois en permanence des signatures DNSSEC erronées pour tous les sites, y compris les sites qui ne supportent pas du tout DNSSEC
Un exemple avec un paquet DNSKEY, avec comme IP source une adresse de l'université du Maryland, sachant que j'ai jamais configuré un éventuel résolveur DNS de cette Université sur mon système
(https://lafibre.info/images/bytel/201703_dns_smtp_mitm_bouygues_3.png)
J'ai pleins d'autres paquets du genre avec diverses IP de serveurs que j'ai jamais interrogé
Pour ces 2 derniers points, j'ai écrit un article détaillé sur la question, disponible ici (https://davenull.tuxfamily.org/mitm-as-a-service-3g-edition-by-bouygues/) :
(https://lafibre.info/images/bytel/201702_davenull_mitm-as-a-service-3g-edition-by-bouygues.png)
En tant que client de Bouygues, je trouve ce genre de pratiques totalement inadmissibles, il y a aucune raison de m'empêcher d'utiliser le résolveur DNS de mon choix. C'est d'autant plus grave que c'est fait en douce et qu'en plus ces bidouillages coté réseaux cassent un protocole de sécurité (DNSSEC).
Bien que ces pratiques qui violent clairement la Neutralité du Net ne m'étonnent pas, j'estime que
- Ces pratiques doivent être rendues publiques, à défaut de disparaître (je compte pas trop dessus)
- Ça mérite quelques explications de la part de Bouygues
Si quelqu'un à des infos sur les motivations de Bouygues, ou sur d'autres pratiques du genre, ça m'intéresse d'en savoir plus à ce sujet.
-
Pour un non spécialiste, concrètement ca fait quoi ?
-
Concrètement, ça veut dire que la connexion internet que tu as via Bouygues Telecom en mobile, en plus de n'être pas neutre, est en partie fake : Si je veux me connecter à un serveur SMTP donné, je m'attends soit à effectivement me connecter à *ce serveur*, soit à être bloqué : là ByTel répond avec un serveur à lui. Pareil pour le DNS, ce qui est bien pire.
C'est comme si tu envoyais une lettre à un ami, à son adresse, et que quelqu'un d'autre te répondait à sa place avec l'adresse de ton ami en expéditeur.
-
Je serai curieux de savoir comment Bouygues justifie un tel bidouillage, parce que je vois pas ce qu'ils y gagnent.
-
Après l'abandon de bytemobile (proxy http) ça fait tâche de voir qu'il y a encore ce genre de truc...
Je me rappelle encore de la période ou les pages web trop lourdes se soldaient par un 403... ou encore que les fichiers de plus de 10 Mo ne se téléchargeaient pas, 403 là aussi. J'avais chargé un petit utilitaire qui découpait en petit morceau les fichiers pour que ça passe.
Par contre il ne m'a jamais été facturé de hors forfait alors que j’utilisais mon forfait 500 Mo en mode modem à l'époque alors que c'était interdit dans les CGV. Ah... le fameux *99# ;D
Source : https://www.freenews.fr/freenews-edition-nationale-299/concurrence-149/bouygues-pris-en-flagrant-delit-de-bridage-de-connexion-3g-10540
-
Il y a eu un sujet l'été dernier pour les dns déjà. Boris avait dit que c'était pour que le net marche même si le apn du mobile était mauvais.
-
Il y a eu un sujet l'été dernier pour les dns déjà. Boris avait dit que c'était pour que le net marche même si le apn du mobile était mauvais.
Ça me parait étrange comme justification, comment ça peut fonctionner si on rentre un APN orange par exemple à la place de bouygues ? Quelqu'un a déjà testé ?
-
Bonjour
Pour un non spécialiste, concrètement ca fait quoi ?
J'allais répondre mais Gabi m'a devancé, son explication résume très bien la situation, Merci @Gabi
Je serai curieux de savoir comment Bouygues justifie un tel bidouillage, parce que je vois pas ce qu'ils y gagnent.
Je suis tout aussi curieux, et à part éventuellement pourvoir faire de la censure par DNS en complexifiant le contournement, je vois pas non plus ce qu'ils y gagnent
Par ailleurs, je suis pas juriste mais j'ai des doutes sur la légalité de la pratique, usurpation d'IPs (IP des DNS vraiment interrogées dans les paquets réponses produits par le serveurs de Bouygues, ainsi que IP de structures tierces dans différents paquets DNS, modifications de paquets à la volée via leurs proxies… )
Il y a eu un sujet l'été dernier pour les dns déjà. Boris avait dit que c'était pour que le net marche même si le apn du mobile était mauvais.
Merci pour l'info, mais je suis pas convaincu par cette explication.
1. Généralement, et depuis quelques années, les APN sont configurés automagiquement, quand l'opérateur correspondant à la carte SIM est détecté par le téléphone. Je me souviens pas de la dernière fois où j'ai du configurer l'APN à la main (et du coup risquer de me planter)
2. Pourquoi tant d'opacité sur ces pratiques, plutôt que d'informer les utilisateurs et de leurs laisser le choix, s'ils acceptent au non de passer par des proxies de Bouygues, et de ne pas pouvoir utiliser des DNS tierces ?
3. DNS menteur qui traite toutes les requêtes qui ne lui sont pas destinées, et qui casse DNSSEC + proxy SMTP qui intercepte les requêtes sur le port 25 + paquets forgés (voir capture d'écran Wireshark + article), sans aucune transparence sur ces pratiques, ni aucune possibilité d'en sortir (sauf à résilier l'abonnement, et trouver un autre FAI qui fait pas la même chose), c'est trop cher payé sous prétexte de résister à une mauvaise conf (faite automatiquement, donc ne nécessitant aucune connaissance de la part des users, donc risque d'erreur très faible au final)
4. Bien que ça reste une mauvaise raison, ça expliquerai à la limite le non-support de DNSSEC (DNS menteur imposé ne supportant pas DNSSEC), mais ça n'explique pas le proxy SMTP, et encore moins les signatures DNSSEC erronées que je reçois pour tous les noms de domaines, y compris ceux n'ayant aucun champs RRSIG dans leurs enregistrement DNS, ni les IP fantaisistes des paquets DNSKEY
4.1 Les IP sources sont forcèment forgées vu c'est des paquets DNS dont les IP n'ont jamais été configurées en tant que résolveur sur ma machine, cf l'article mis en lien, d'autant plus que ça touche des noms de domaines qui ne supportent pas DNSSEC… je vois pas pourquoi un serveur DNS légitime m'envoie des signature RRSIG erronées pour tous les noms de domaines auxquels je me connecte (J'ai fais plusieurs fois les testes à plusieurs mois d'intervalles, les résultats sont strictement les mêmes, donc j'exclus l'erreur de configuration, au bout de tout ce temps, quelqu'un aurait finit par voir et corriger l'erreur, si c'était une erreur)
-
C'est peut être lié a la protection du réseau contre de l'UDP Amplification par exemple (dns étant sur udp).
Notamment quand le tél est en mode hotspot ou quand on utilise une box4G (un resolveur DNS ouvert derriere une connexion 4G ca peut faire mal).
Tout dépend ou se situe ce 'mitm', s'il est proche de l'utilisateur, par exemple la ou y'a l'antenne cela permet de protéger les collectes contre un flood udp.
Apres c'est peu-être simplement pour faire du CDN et soulager les collectes...
ou réduire la latence des réso DNS
ou augmenter leur fiabilité
ou collecter des infos sur les usages: vu que quasi tout se fait en https de nos jours sur des CDN globalisés (cloudflare & co), l'opérateur ne voit plus grand chose, les IPs destinations donnant peu d'info... en interceptant les reso DNS il peut tracker des infos sur les usages.
Il faudrait tester quelques réponses DNS et les comparer avec les autoritatives pour voir s'ils changent quelque chose ou pas. s'ils ne changent rien c'est de la protection ou de la collecte de data.
Apres 99% des gens s'en tapent car ils ne touchent pas leur conf DNS de leur mobile qui de toute facon va chez l'opérateur.
Et quasi aucune application mobile embarque son propre client DNS, elles délèguent toutes cela a l'OS.
La ou c'est problématique c'est en mode hotspot si on a un PC avec config DNS particuliere. Mais la encore c'est pas 99% des gens.
Et on peut toujours faire un VPN en faisant tout passer dedans , y compris les réso DNS.
Bref meme si c'est pas 'réglo' c'est pas si gênant qu'un MiTM sur du vrai contenu par exemple.
-
C'est peut être lié a la protection du réseau contre de l'UDP Amplification par exemple (dns étant sur udp).
Notamment quand le tél est en mode hotspot ou quand on utilise une box4G (un resolveur DNS ouvert derriere une connexion 4G ca peut faire mal).
En quoi « la protection contre le flood UDP » explique les signatures RRSIG foireuses issus de paquets forgées? ou le proxy SMTP ? Je vois pas le rapport
De plus, c'est connexion 3G (pas 4G, ni 4G "Box") via BandYou avec un débit en upload ridicule, même le download est mauvais
De plus qui mettrai un serveur DNS derrière un accès Internet mobile? Personne… les serveurs autohebergées sont en général derrière des accès fixes (xDSL ou FTTB/FTTH)
Sans compter le fait que c'est aux admins d'êtres responsables, et de configurer correctement leurs machines, aps aux FAI de jouer aux flics du Net. L'infantilisation des clients/users, ça va 5 minutes
Après c'est peu-être simplement pour faire du CDN et soulager les collectes...
ou réduire la latence des réso DNS
ou augmenter leur fiabilité
T'as lu au moins tout le topic? et l'article mis en lien? je vois pas en qupi du MITM sur SMTP et DNS, en cassant DNSSEC au passage, via des paquets forgés, relève de l'amélioration au passage
ou collecter des infos sur les usages: vu que quasi tout se fait en https de nos jours sur des CDN globalisés (cloudflare & co), l'opérateur ne voit plus grand chose, les IPs destinations donnant peu d'info... en interceptant les reso DNS il peut tracker des infos sur les usages.
Archi faux! même avec HTTPS + CDN, ils ont accès aux URL <correction>noms de domaines. Les requêtes et réponses DNS passent en clair sur le réseau du FAI, sauf à faire du DNS over TLS (pas très répandu)<correction>
D'autant plus que le flicage est la pire des raisons de faire du MITM, c'est pareil qu'un script kiddie qui fait du MITM sur les réseaux WiFi publics.
Ce que leurs utilisateurs font, ça es regarde pas… c'est un FAI, pas un OPJ dans le cadre d'une enquête encadrée…
Il faudrait tester quelques réponses DNS et les comparer avec les autoritatives pour voir s'ils changent quelque chose ou pas. s'ils ne changent rien c'est de la protection ou de la collecte de data.
Encore une fois, il y a des paquets forgées avec de fausses signatures DNSSEC pour tous les noms de domaines visités, que ces NdD aient une signature RRSIG ou non dans leurs vrais enregistrement DNS, donc il y a bien notification des réponses
Apres 99% des gens s'en tapent car ils ne touchent pas leur conf DNS de leur mobile qui de toute facon va chez l'opérateur.
Et quasi aucune application mobile embarque son propre client DNS, elles délèguent toutes cela a l'OS.
Encore heureux que les applis mobiles n'imposent pas leurs résolveur DNS… l'OS qui définit le résolveur, c'est un comportement normal… et ça ne justifie rien, sosu pretexte que les utilisateurs s'en foutent de ce que bricolent leurs FAI… je me demande comment ces mêmes personnes réagiraient si La Poste intercepter et lisait leurs couriers, puis répondait en se faisant passer pour les destinataires légitimes à qui s'adresser le courrier
La ou c'est problématique c'est en mode hotspot si on a un PC avec config DNS particuliere. Mais la encore c'est pas 99% des gens.
Je fais partie de ces utilisateurs, et ces le cas de plus en plus de gens qui utilisent des DNS tierces… je vois pas le rapport entre les pratiques douteuses et le fait que peu de personnes sont susceptibles de découvrir ce que le FAI bricole… D'ailleurs s'ils se croient tout permis c'est justement parce que les egns ont tendant à se dire « C'est pas grave, ils savent mieux que nous pourquoi ils font ça »
Et on peut toujours faire un VPN en faisant tout passer dedans, y compris les réso DNS.
Non, ça reste à verifier (ça dépends s'ils bloquent ou non, voir la conclusion de mon article, donné en lien dans mon 1er post)
Le VPN à des coups, devoir payé plus juste pour pas se faire pourrir malhonnêtement sa connexion Internet ne devrait pas être considéré comme normall, et encore moins accepté
Bref meme si c'est pas 'réglo' c'est pas si gênant qu'un MiTM sur du vrai contenu par exemple.
Bien sur que si, c'est génant, ils pourrisent un protocole de sécurité (DNSSEC), donc rendent le DNS moins fiable, ils facilitent la censure par DNS en imposant le leurs, qui mentent déjà en modifiant le contenant des réponses et mentant sur les identités…
-
même avec HTTPS, et les CDN, ils ont accès aux URL
les URL dans HTTPS ? ;D
-
les URL dans HTTPS ? ;D
Je reformule, pas toutes les URL, mais les noms de domaines visités sont visibles en HTTPS, même sans MITM DNS
A moins que tu fasse du DNS over TLS (dispo sur peu de résolveurs et utilisé par peu de gens), t'aura beau interroger un DNS tierce, ton FAI aura beau ne pas faire du MITM DNS, il verra quand même passer les requêtes DNS, et les réponses, donc il aura les noms de domaines sur lesquelles ta machine se connecte, en plus des NdD dont tu récupère l'IP (ou que tu récupère à partir de l'IP) sans forcèment te connecter dessus (genre les requêtes effectués par des outils tels que dig, dans le cadre de tests/debugs)
-
Bonjour,
En tant que client de Bouygues, je trouve ce genre de pratiques totalement inadmissibles, il y a aucune raison de m'empêcher d'utiliser le résolveur DNS de mon choix. C'est d'autant plus grave que c'est fait en douce et qu'en plus ces bidouillages coté réseaux cassent un protocole de sécurité (DNSSEC).
Bien que ces pratiques qui violent clairement la Neutralité du Net ne m'étonnent pas, j'estime que
- Ces pratiques doivent être rendues publiques, à défaut de disparaître (je compte pas trop dessus)
- Ça mérite quelques explications de la part de Bouygues
Si quelqu'un à des infos sur les motivations de Bouygues, ou sur d'autres pratiques du genre, ça m'intéresse d'en savoir plus à ce sujet
Je ne sais pas si ces comportement techniques observables sont inadmissibles ou graves, je sais qu'ils sont extrêmement communs (en se rappelant qu'il y a plus de 800 opérateurs mobiles dans le monde, sans compter les virtuels).
La motivation de base est l'optimisation du trafic mobile à l'aide d'équipements dédiés, une chose qui se rencontre partout depuis le début des années 2000. Ce que tu cites relève probablement d'effets de bords de ceux-ci, pour lesquels obtenir une correction n'est probablement pas simple (mais n'impacte pas le gros de la base clientèle non plus).
Présumer que les équipes de Bouygues ont un facteur de décision direct sur les comportements techniques mentionnés est s'avancer trop, étant donné que les équipements fonctionnant à ces fins sont développés largement par des sociétés présentes sur de marchés de niches qui revendent en général leur prestation à un grand nombre d'opérateurs.
Un cœur de réseau mobile est un système complexe qui se fonde sur une opacité et des modalités d'ingénierie qui font que les opérateurs par exemple moyens ont en effet souvent peu d'ingérence sur des points techniques aussi précis, et réutilisent massivement des solutions génériques.
Bonne journée
-
@DaveNull :
Je formulais juste des hypothèses pour essayer de comprendre le point de vue de l'opérateur et pourquoi ils ont mis en place ce mitm.
Tu ne vois qu'un coté des choses , ton coté, qui en plus n'est pas représentatif des usages de la majorité des clients de l'opérateur mobile et tu réagis de façon assez primaire/utopiste sans chercher a comprendre leur motivation. Ils ne font pas ca sans raisons valables, du moins j'ose le croire (eux ou leur fournisseurs de solution/produit).
On n'a aucune idée de ce qu'ils voient et de ce que leur réseau subit. On n'a aucune idée de ce que des 'petits malins' sont capables de faire en utilisant de l'udp sur le port 53 par exemple. Les opérateurs sont confrontés a des comportements de masse, des dysfonctionnements et par dessus cela a plein de tentatives d'attaques utilisant des réseaux de bots gigantesques comportant de plus en plus de smartphones infectés ou peu sécurisés.
C'est sur que ca manque de comm mais c'est probablement parce que 99% des clients ne comprendront pas cette comm de toute facon.
Quand a 'pourrir' DNSSEC , il faut savoir qu'un domaine utilisant DNSSEC et étant mal configuré peut servir a pourrir le réseau et que malheureusement il y a plein de domaines DNSSEC mal configurés...
un petit mot la dessus : (cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/doc/201602_akamai_dnssec_amplification_ddos.png) (https://lafibre.info/images/doc/201602_akamai_dnssec_amplification_ddos.pdf)
Et concernant Bytel, comme indique Marin, je pense qu'ils dépendent avant tout de solutions complexes fournies par des prestataires et equipementiers et qu'ils ont probablement peu de latitude sur ce problème.
-
Vous avez trouvé un document de l'ARCEP qui explique de manière claire :
- Ce qui est neutre
- Ce qui est toléré comme entraves à la neutralité, dans des conditions précises (exemple: en cas d'attaque DDOS)
- Ce qui n'est pas neutre, mais qui ne fait pas l'objet de sanction
- Ce qui n'est pas neutre et qui fait l'objet de sanction si on opérateur est pris en flagrant délit
Le seul document c'est Règlement (UE) 2015/2120 du Parlement européen et du Conseil établissant des mesures relatives à l’accès à un internet ouvert (25 novembre 2015) (http://www.arcep.fr/fileadmin/reprise/textes/communautaires/reglement-UE-2015_310-Net-Neutralite-251115.pdf) ?
-
Bonjour
Présumer que les équipes de Bouygues ont un facteur de décision direct sur les comportements techniques mentionnés est s'avancer trop
Non, j'ai jamais dit que les techs de Bouygues sont directement responsables de ces choix, je dis juste que les conséquences sont dégueulasses, et que le manque de transparence sur ce qui est fait, est un problème
Quand a 'pourrir' DNSSEC , il faut savoir qu'un domaine utilisant DNSSEC et étant mal configuré peut servir a pourrir le réseau et que malheureusement il y a plein de domaines DNSSEC mal configurés...
un petit mot la dessus : (cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/doc/201602_akamai_dnssec_amplification_ddos.png) (https://lafibre.info/images/doc/201602_akamai_dnssec_amplification_ddos.pdf)
Les exemples pris pour tester. DNSSEC concernent des NdD avec une configuration valide... Sur plusieurs réseaux, ça fonctionne très bien
-
- DNS menteur : Impossible d'utiliser un DNS tierce, c'est le DNS de Bouygues qui répond, en mentant sur l'IP source de la réponse
Même en interrogeant un faux résolveur DNS (dig @IP avec comme IP une adresse ne pointant vers aucun résolveur DNS réel), j'ai une réponse (voir lien donné plus bas) avec une IP source correspond à celle du serveur interrogé, or comme l'IP ne correspond à aucun résolveur réel, ça veut dire qu'il y a un équipement qui répond aux requêtes en forgeant les IP sources
- Paquets DNSSEC forgés : IP sources de paquets DNSKEY totalement fantaisistes, et clés sont foireuses, je reçois en permanence des signatures DNSSEC erronées pour tous les sites, y compris les sites qui ne supportent pas du tout DNSSEC
Un exemple avec un paquet DNSKEY, avec comme IP source une adresse de l'université du Maryland, sachant que j'ai jamais configuré un éventuel résolveur DNS de cette Université sur mon système
(https://lafibre.info/images/bytel/201703_dns_smtp_mitm_bouygues_3.png)
J'ai pleins d'autres paquets du genre avec diverses IP de serveurs que j'ai jamais interrogé
Je répète mon point de vue juridique : une interception DNS est l'usurpation d'identité et une violation des droits de "propriété intellectuelle" des sites.
-
Quand a 'pourrir' DNSSEC , il faut savoir qu'un domaine utilisant DNSSEC et étant mal configuré peut servir a pourrir le réseau et que malheureusement il y a plein de domaines DNSSEC mal configurés...
Explique nous donc comment un DNS bien configuré pourrait éviter de servir dans une attaque DDoS quand les attaquants modifient l'adresse IP source.
Il me semblait que la possibilité du DoS (et variante DDoS) était l'autre face du fait d'avoir un réseau ouvert.
-
Les requêtes et réponses DNS passent en clair sur le réseau du FAI, sauf à faire du DNS over TLS (pas très répandu)<correction>
Si on va par là, même s'ils ne peuvent pas capturer l'échange DNS (mettons parce que la réponse est dans le cache de l'application ou bien du PC), ils pourraient examiner le certificat TLS pour récupérer le (les) domaine(s).
Enfin je ne vois pas à quoi ça servirait, mais ils peuvent le faire!
-
De plus, le comportement d'un resolver se configure, Si la sécurité absolue n'existe pas, il existe de bonnes pratiques (https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful) pour limiter la casse
should consider the upward referral "out of bailiwick"
super.
Je vois pas DU TOUT le rapport avec ce dont tu parles, mais cela reste un bon conseil.
Et je ne comprends à quoi serviraient ces "referrals": pourquoi un résolveur aurait besoin de "hints" pour trouver les serveurs racine?
-
Le rapport, c'est que limiter les chances que les résolveurs DNS ne servnet à des attaques par amplification, ça passe par des résolveurs bien configurés, et non pas par du MITM DNS fait par le FAI, contrairement à ce qu'affirmait un des intervenants…
Et je ne comprends à quoi serviraient ces "referrals": pourquoi un résolveur aurait besoin de "hints" pour trouver les serveurs racine?
Bonne question, il va falloir creuser plus en détail à tête reposée, là maintenant je saurai pas répondre
-
Le rapport, c'est que limiter les chances que les résolveurs DNS ne servent à des attaques par amplification, ça passe par des résolveurs bien configurés,
Encore une fois, aucun rapport avec ton lien qui ne parle pas du tout de résolveurs DNS!!!
-
Encore une fois, aucun rapport avec ton lien qui ne parle pas du tout de résolveurs DNS!!!
Alors tu devrais relire l'article… il ne parle pas QUE de resolvers DNS, mais il en parle
-
Some are calling it an amplification attack because the query ". IN NS" is quite small (47 octets) while an upward referral response is a bit larger (256 octets)
C'est assez minable comme amplification!!!
Franchement, ils pourraient trouver des amplifications bien supérieures, tu ne crois pas?
-
ANY marche mieux, surtout si la zone est signé avec DNSSEC :)
-
Alors tu devrais relire l'article… il ne parle pas QUE de resolvers DNS, mais il en parle
Il en parle quelque part un peu, mais l'attaque en question n'est PAS sur un résolveur.
-
Le problème est toujours d'actualité ? Je n'ai pas vraiment de quoi tester de mon coté.
-
Salut,
Le problème est toujours d'actualité ? Je n'ai pas vraiment de quoi tester de mon coté.
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).
-
C'est résolut pour le port 25 (SMTP).
-
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 2017
En 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)
(https://lafibre.info/images/bytel/201703_dns_smtp_mitm_bouygues_debian_bouygues.png)
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)
(https://lafibre.info/images/bytel/201703_dns_smtp_mitm_bouygues_debian_propre.png)
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ée
Test 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…
-
Il faudrait tester avec les APN ipv6 de Bouygues pour voir si le trafic ipv6 est aussi bricolé.
-
Il faudrait tester avec les APN ipv6 de Bouygues pour voir si le trafic ipv6 est aussi bricolé.
+1 : Si quelqu'un veut s'en occuper, le résultat m'intéresse. Bouygues ne fournissait pas encore IPv6 (ou juste pas sur le type de forfait que j'avais?) quand j'étais chez eux donc j'ai pas pu tester
-
Du calme DaveNull.
Je confirme ce que j'ai dis, avant 2015, et probablement aujourd'hui.
J'ai aussi précisé que c'était un autre apn.
B&You (toi) et Sensation ont un autre apn... où je ne change pas le dns, car je n'utilise pas le mode modem du smartphone.
Par contre, sur ordi, il m’arrive d'utiliser un hostpot 4G, avec le forfait adéquat (bbox nomad). Et là, nous n’avons pas les mêmes règles par l'opérateur. Idem en 4G box, encore un autre apn.
-
Du calme DaveNull.
Parce que les gens ne prennent pas tes propos pour argent comptant, quand ils ont constaté le contraire, ça implique nécessairement qu'ils sont « pas calmes » ? ???
Ensuite, j'ai jamais parlé de box 4G, j'ai parlé 3G/4G en passant par le mode modem de l'ordiphone…
En capture d'écran Extrait de la fiche récap (https://www.bouyguestelecom.fr/static/cms/tarifs/Fiche_D_Information_Standardisee_Forfaits_Mobile_B_You.pdf) des services BandYou sur la quelle j'ai fait le test… Le partage de connexion (ordiphone qui fait office de hotspot) est « inclut » (1) dans ce type de forfait, donc officiellement je peux utiliser APN configuré sur le téléphone (automatiquement) pour utiliser le téléphone comme hotspot. Donc ton argument sur « un AP différent pour hotspot » fait :
- Soit référence au hotspot exclusivement fixe (box 4G) auquel c'est hors sujet puisque je parlais pas de box 4G et donc la question à la quelle tu répond ne concerne pas la box 4G
- Soit référence aux hotspot en général (donc ça inclut l'APN sur lequel j'ai fait mes tests), au quel cas ton affirmation est fausse car ton ça suppose que le MITM DNS que j'ai constaté ne concerne pas un APN qui permet l'utilisation du téléphone en tant que hotspot (or si, justement…).
Et je maintiens qu'aux dates (dernier trimètre 2016 et début 2017) ou mes tests ont été effectués, Bouygues Telecom faisait de MITM sur DNS sur ses forfaits mobile 4G, y compris sur les APN dont ils n'interdisent pas l'utilisation pour faire hotspot avec son téléphone (puisque la fiche de vente prétend que c'est un service vendu à part alors qu'en réalité, c'est juste une fonctionnalité du téléphone)
(https://lafibre.info/images/bytel/201703_dns_smtp_mitm_bouygues_4.png)
D'ailleurs faudrai m'expliquer comment tu peux affirmer qu'il y a pas de MITM DNS si tu utilises QUE le DNS de bouygues, puisque tu dis toi même que tu le change pas…
1. Passons sur le fait qu'un octet sur écran d'ordiphone et un octet sur PC c'est strictement pareil et que c'est par conséquent une escroquerie de prétendre que c'est un service à part
-
J'ai migré vers un forfait B&You et je constate que Bouygues Tel intercepte toujours les requêtes DNS vers les autres résolveurs pour les rediriger vers le sien >:(
Donc si on veut utiliser d'autres résolveurs on doit utiliser un VPN ou des résolveurs supportant DNS over TLS ou DNSCrypt voir DNS over HTTPS (qui n'est pas encore normalisé)
Pour DNS over TLS a ma connaissance seul Quad9 et CloudFlare le propose, mais seul Android P permet d'en tirer parti nativement.
Entre ça et l'utilisation de ByteMobile, je trouve que ça renvoi une image négative de l'internet mobile chez ByTel.
-
ByteMobile n'est plus utilisé depuis 2016 :
J'ai oublié de vous faire un retour : Il n'y a plus de compression ByteMobile chez Bouygues Telecom.
Pour contourner l’interception du port 53, l'utilisation de DNS over HTTPS (DoH) est une solution (merci Firefox)
Cela être utile dans de nombreux pays où la liberté d'expression est très limitée et où les requêtes DNS sont interceptées pour bloquer des sites Internet.
Je me demande si un site référence les opérateurs ou pays (car généralement c'est imposé par l'état) qui interceptent les requêtes DNS quel que soit l'IP utilisée.
J'ai été il y a trois ans en Turquie et il y avait une interception DNS. Il y avait également un snif des requêtes http : Après avoir mis l'IP de Youtube dans mon /etc/hosts j'ai été bloqué pour les requêtes Youtube en http (a l'époque Youtube était proposé en http et https). Merci le https qu fonctionnait bien :-)
Et pour se détendre sur le sujet, la campagne RSF: Une année exceptionnelle pour la censure (https://lafibre.info/bistro-sujet-libre/rsf/)
-
Effectivement je viens de tester ByteMobile est plus utilisé et c'est une bonne nouvelle, pareil pour l'interception SMTP.
Encore un effort et ça sera bon pour DNS ? ::)
-
On n'a toujours pas d'explication officielle de la part de Bytel ?
-
Je viens de découvrir cette app qui permet d'utiliser DNS over HTTPS sur Android : https://play.google.com/store/apps/details?id=app.intra
Ça s'appelle Intra c'est développé par Jigsaw qui est un Think Tank créé par Google cf. https://en.m.wikipedia.org/wiki/Jigsaw_(company) (https://en.m.wikipedia.org/wiki/Jigsaw_(company))
Bien entendu c'est open source voici le GitHub : https://github.com/Jigsaw-Code/intra
L'app utilise par défaut les DNS de Google mais on peut choisir ceux de Cloudflare aussi
-
DNS over TLS sera dans la prochaine version d'Android (Android P actuellement en beta).
source: https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
-
Je viens de découvrir cette app qui permet d'utiliser DNS over HTTPS sur Android : https://play.google.com/store/apps/details?id=app.intra
belle trouvaille. Ca fonctionne aussi sur ChromeOS. Fenetre de droite l'app Android, fenetre de gauche: Chrome natif de ChromeOS.
sans derriere un bbox donc resolveur bytel:
(https://lafibre.info/testdebit/android/201806_dns_ovh_https_1.jpg)
avec :
(https://lafibre.info/testdebit/android/201806_dns_ovh_https_2.jpg)
-
Effectivement je viens de tester ByteMobile est plus utilisé et c'est une bonne nouvelle, pareil pour l'interception SMTP.
Encore un effort et ça sera bon pour DNS ? ::)
Un an et demi plus tard, l'interception DNS continue.
-
Je confirme qu'à ce jour ils continuent l'interception DNS en ipv4 et ipv6.
Une explication serait bienvenue.
-
Je vais me faire l'avocat du diable :
- Quels sont les impacts ?
- C'est une obligation pour filtrer les sites terroristes
- Que-ce-que cela bloque à part DNSSEC et le contrôle parental quand on utilise des DNS spécifiques pour limiter les sites accessibles à un mineur ?
- En cas de configuration de l'APN en IPv6, quels sont les DNS tiers qui permettent de récupérer le préfixe DNS64 pour faire du DNS64/NAT64 ?
Dire que "c'est pas bien" et "les autres ne le font pas" n'est pas suffisant pour convaincre le régulateur d'ouvrir une procédure pour cette pratique.
-
- C'est une obligation pour filtrer les sites terroristes
non. le blocage peut-être fait directement dans leur resolvers dns comme font les autres FAI francais et comme Bouygues fait en fixe.
l'interception va bien au dela et a ce jour on a toujours pas reçu d'explication officielle a sa présence.
- Quels sont les impacts ?
L'impact le plus gênant apres DNSSEC est qu'on est forcé d'obtenir des réponses DNS de Bouygues plutôt que d'un resolver de son choix, notamment on ne peut pointer sur un serveur dns 'ad blocker' ou 'contrôle parental' par exemple.
Apres c'est certain que ca ne doit impacté qu'une infime minorité donc ils n'ont aucune motivation économique ou PR a modifier cela.
- En cas de configuration de l'APN en IPv6, quels sont les DNS tiers qui permettent de récupérer le préfixe DNS64 pour faire du DNS64/NAT64 ?
Google:
https://developers.google.com/speed/public-dns/docs/dns64
Cloudfare:
https://developers.cloudflare.com/1.1.1.1/support-nat64/
sans doute d'autres.
-
En plus VPN et TOR servent facilement à avoir accès malgré les éventuels filtrages de DNS
-
En cas de configuration de l'APN en IPv6, quels sont les DNS tiers qui permettent de récupérer le préfixe DNS64 pour faire du DNS64/NAT64 ?
Je ne vois que cette pseudo-raison qui puisse être un début d'explication. Pseudo car ça ne devrait concerner que les requêtes en ipv6.
Effectivement, si en ipv6-only on choisi un DNS tiers qui ne fais pas de DNS64, on perd la connectivité ipv4 sur certains appareils, notamment les iphones qui ne font pas de 464XLAT si j'ai bien compris.
Cela dit, le quidam qui s'amuse à changer ses dns et qui voit que ça casse son internet, il comprend sa connerie et fait demi-tour vite fait.
Pour répondre à la question "quels sont les impacts ? à part...." je citerais un philosophe célèbre :
C'est essentiel à la neutralité du net, de ne pas être contraint dans l’utilisation d'un serveur DNS tiers.
;)
-
Il ne faut pas hésiter a indiquer votre problème sur https://jalerte.arcep.fr/
Si vous êtes plusieurs a vous plaindre, le régulateur pourrait contacter Bouygues Telecom sur ce sujet.
Petite vidéo pour expliquer à quoi sert https://jalerte.arcep.fr/ :[/size]
https://lafibre.info/videos/arcep/201806_jalerte_arcep.mp4
Texte de la vidéo :
Elle, c’est Anne. Elle possède un téléphone et une box internet. Pour regarder ses séries préférées, mais aussi pour contacter des clients. Car, elle vient de créer sa société.
Problème... Il lui arrive d’être confrontée à des bugs comme celui-là...
Et ça la rend comme ça ! Pas besoin de se mettre dans cet état !
Pour résoudre son problème, il faut bien sûr contacter son opérateur.
Mais pour faire entendre sa voix auprès des pouvoirs publics, il y a la plateforme « J’alerte l’Arcep ».
Mais oui, Anne... l’Arcep ! Le gendarme des télécoms ! Cette autorité régule les opérateurs de téléphonie, d’internet mais aussi La Poste : en clair... elle leur impose des obligations et les sanctionne si elles ne sont pas respectées.
Pour alerter l’Arcep, c’est simple et rapide. Je commence par m’identifier : particuliers, entreprises ou collectivités.
Ensuite, je décris mon problème. À chaque fois, plusieurs propositions me sont faites. C’est très ergonomique. Pas besoin d’être un geek !
1ère étape, je sélectionne : l’opérateur et le service défaillant.
Ensuite, je qualifie mon problème : le service est-il en cause ? La facturation est-elle correcte ?
Enfin, si je le souhaite, je précise la résolution ou non de mon problème par le service client de mon opérateur. Attention, l’Arcep n’est pas en charge du règlement des litiges individuels entre utilisateurs et opérateurs.
Mais, elle donne des conseils et indique les voies de recours possibles en fonction de votre profil et de la description de votre problème.
Que fait l’Arcep avec ces informations ? Elle analyse en temps réel les difficultés rencontrées, et peut surtout mesurer leur ampleur par le nombre d’alertes déposées.
Si vous êtes nombreux, l’Arcep peut ainsi être plus efficace dans ses actions de régulation et agir en conséquence auprès des opérateurs.
À la fin, on vous propose de partager votre alerte sur les réseaux sociaux On vous suggère même le texte : « #jalertelArcep »
Tu sais ce qu’il te reste à faire Anne ! Faire peser ton expérience, c’est inciter les opérateurs à améliorer leur qualité de service. C’est aussi faire un acte citoyen ! Une bonne connectivité est capitale non seulement pour les jeunes entrepreneurs qui se lancent comme toi ! Mais aussi pour chaque Français sur tout le territoire !
-
Bonjour tout le monde,
Apparemment, le MITM en DNS est toujours d'actualité chez Bouygues en forfait Data 4G et B&YOU d'après mes derniers tests de ce matin.
Boris de Bouygues Telecom ne fait rien depuis plus de 2 ans.
Moi je vous propose de faire une action commune et moi je vais faire un rapport à l'Arcep et au siège de Bouygues car je suis aussi opérateur telecom.
Bouygues filtre tout ses abonnés et rend sa navigation "NON NEUTRE".
Si vous avez des idées pour que je pousse le ou les dossiers dite-le sur le phread.
-
quel est l'interet pour les DNS ? ok pour le SMTP on dira "à la rigueur"
-
Le SMTP a été enlevé en 2017 :
C'est résolut pour le port 25 (SMTP).
-
Le SMTP a été enlevé en 2017 :
Pas faux pour le SMTP, mais sa date.
Empêche que toutes les connexions avec le port 53 sont redirigés sur les serveurs DNS de Bouygues.
Il pourrait enlever ses règles qui existent pas sur un forfait 4GBOX.
-
Il y a également redirection de tous les paquets du port 53 avec un forfait 4G Box illimité et IPv4 publique dédiée ?
-
Pour tester sous Linux ou MacOS, vous pouvez tester de télécharger un fichier de 100 Mo sur le port 53 en https.
La commande à utiliser : wget https://k-net.testdebit.info:53/100M.iso
(vous pouvez utiliser curl si vous n'avez pas wget)
Le serveur en question écoute sur le port 53 en https.
N'essayez pas depuis un navigateurs, ils refusent les connexions https sur le port 53.
Exemple quand cela fonctionne :
$ wget https://k-net.testdebit.info:53/100M.iso
--2020-01-15 16:43:19-- https://k-net.testdebit.info:53/100M.iso
Résolution de k-net.testdebit.info (k-net.testdebit.info)… 2a03:4980::f:0:17, 178.250.208.152
Connexion à k-net.testdebit.info (k-net.testdebit.info)|2a03:4980::f:0:17|:53… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 100000000 (95M) [application/x-iso9660-image]
Enregistre : «100M.iso»
100M.iso 100%[==================================================>] 95,37M 107MB/s ds 0,9s
2020-01-15 16:43:20 (107 MB/s) - «100M.iso» enregistré [100000000/100000000]
Si cela part en IPv6 (c'est le cas sur mon exemple) et que vous souhaitez forcer l'IPv4 : wget -4 https://k-net.testdebit.info:53/100M.iso
$ wget -4 https://k-net.testdebit.info:53/100M.iso
--2020-01-15 16:46:31-- https://k-net.testdebit.info:53/100M.iso
Résolution de k-net.testdebit.info (k-net.testdebit.info)… 178.250.208.152
Connexion à k-net.testdebit.info (k-net.testdebit.info)|178.250.208.152|:53… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 100000000 (95M) [application/x-iso9660-image]
Enregistre : «100M.iso»
100M.iso 100%[==================================================>] 95,37M 106MB/s ds 0,9s
2020-01-15 16:46:32 (106 MB/s) - «100M.iso» enregistré [100000000/100000000]
-
Il y a également redirection de tous les paquets du port 53 avec un forfait 4G Box illimité et IPv4 publique dédiée ?
Regarde bien se que j'ai dis : Il pourrait enlever ses règles "qui existent pas" sur un forfait 4GBOX.
-
mode modem sur un forfait 40GB:
wget -4 https://k-net.testdebit.info:53/100M.iso --2020-01-15 20:18:32-- https://k-net.testdebit.info:53/100M.iso
Resolving k-net.testdebit.info (k-net.testdebit.info)... 178.250.208.152
Connecting to k-net.testdebit.info (k-net.testdebit.info)|178.250.208.152|:53... connected.
Unable to establish SSL connection.
*****
nslookup ip.lafibre.info ip.lafibre.info
Server: ip.lafibre.info
Address: 46.227.16.8#53
Non-authoritative answer:
Name: ip.lafibre.info
Address: 46.227.16.8
Name: ip.lafibre.info
Address: 2a01:6e00:10:410::2
-
Forfait 20GO Data Bouygues:
PS C:\Users\unknown\Downloads\Programs> wget
applet de commande Invoke-WebRequest à la position 1 du pipeline de la commande
Fournissez des valeurs pour les paramètres suivants :
Uri: https://k-net.testdebit.info:53/100M.iso
wget : La connexion sous-jacente a été fermée : Une erreur inattendue s'est produite lors de l'envoi.
Au caractère Ligne:1 : 1
+ wget
+ ~~~~
+ CategoryInfo : InvalidOperation : (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebEx
ception
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
nslookup ip.lafibre.info
Serveur : www.huaweimobilewifi.com
Address: 192.168.8.1
Réponse ne faisant pas autorité :
Nom : ip.lafibre.info
Addresses: 2a01:6e00:10:410::2
46.227.16.8
-
macgyver79, il me semble que le wget n'a pas fonctionné.
Sous Windows je recommande plutôt d'utiliser CURL
Étape 1 : Télécharger CURL
- CURL 7.54 (64bits pour Windows 64bits) (https://soft.lafibre.info/download/windows/network-utilities/curl/curl-7.54.0-win64.exe)
- CURL 7.54 (32bits pour Windows 32bits) (https://soft.lafibre.info/download/windows/network-utilities/curl/curl-7.54.0-win32.exe)
Étape 2 :
Renommer votre version de curl en curl.exe et placez là dans le dossier C:\WINDOWS
Étape 3 :
Dans le menu démarrer, lancer l'application "Invite de commandes" (pour aller plus vite, cherchez cmd dans le champ de recherche)
Si curl.exe n'est pas dans C:\WINDOWS, placez vous dans le dossier où il est installé, par exemple avec la commande cd Downloads si il est dans le dossier téléchargement.
Exécuter la commande suivante :
curl -o NUL https://k-net.testdebit.info:53/100M.iso
Le fichier n'est pas téléchargé sur votre disque dur mais envoyé vers nul part (/dev/null)
Pour forcer l'IPv4 (si l'IPv6 est disponible, le test se fait en IPv6) :
curl -4 -o /dev/null https://k-net.testdebit.info:53/100M.iso
Sur mac, CURL est installé de base. Il y a une petite modification pour la ligne de commande : NULL se relace par /dev/null
curl -o /dev/null https://k-net.testdebit.info:53/100M.iso
Sous Linux, si vous souhaitez utiliser CURL, c'est la même ligne sur sur mac, avec /dev/null
Exemple avec une connexion 4G SFR partagée avec un Ubuntu 19.10 :
$ curl -o /dev/null https://k-net.testdebit.info:53/100M.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 1994k 0 0:00:48 0:00:48 --:--:-- 2317k
(débit moyen de 1994 Kio/s)
-
vivien, "nslookup ip.lafibre.info ip.lafibre.info" suffit comme je l'ai fait ;) si ca te donne un résultat c'est que c'est tronqué ;) j'ai cela en ce moment sur mon autre forfait BoT 50GB + WE illimité ;)
-
La je pense que l'on perd une partie des lecteurs.
Il faut préciser qu'il n'y a pas de serveur DNS sur lafibre.info
Si on obtient une réponse, c'est qu'un autre serveur a répondu à la place.
Cela fonctionne aussi avec des IP assez improbable (genre une requête DNS sur 255.255.255.255 fonctionne, si mes souvenirs sont bon)
Les IPb4 de 224.0.0.0 à 239.255.255.255 sont des IPv4 multicast, donc pas possible d'avoir un serveur DNS.
Les IPv4 de 240.0.0.0 à 255.255.255.255 sont des IPv4 réservées et inutilisables sur Internet, donc pas possible d'avoir un serveur DNS.
-
> La je pense que l'on perd une partie des lecteurs.
mais l'outil est natif sous windows ;)
> Il faut préciser qu'il n'y a pas de serveur DNS sur lafibre.info
> Si on obtient une réponse, c'est qu'un autre serveur a répondu à la place.
oui
> Cela fonctionne aussi avec des IP assez improbable (genre une requête DNS sur 255.255.255.255 fonctionne, si mes souvenirs sont bon)
non, je viens d'essayer...
en résumé "nslookup www.lafibre.info www.lafibre.info" et "nslookup www.lafibre.info www.free.fr"
et "nslookup www.lafibre.info www.orange.fr" et "nslookup www.lafibre.info www.sfr.fr" ne devrait pas répondre 46.227.16.8 ;)
-
Forfait Bouygues Data 20GO:
curl -o NUL https://k-net.testdebit.info:53/100M.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:07 --:--:-- 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to k-net.testdebit.info:53
nslookup www.lafibre.info www.sfr.fr
Serveur : UnKnown
Address: 80.125.163.172
Réponse ne faisant pas autorité :
Nom : lafibre.info
Addresses: 2a01:6e00:10:410::2
46.227.16.8
Aliases: www.lafibre.info
nslookup www.sfr.fr
Serveur : homerouter.cpe
Address: 192.168.1.1
Réponse ne faisant pas autorité :
Nom : www.sfr.fr
Addresses: 64:ff9b::507d:a3ac
80.125.163.172
Sa sent mauvais pour Bouygtel. ;D
-
non, je viens d'essayer...
255.255.255.254 alors ?
-
non, ni 225.225.225.225 ni 235.235.235.235
nada kedal keutchi zero rien
-
Requêtes effectuées sous Ubuntu 19.10 via une connexion Wi-Fi à un mobile Android en 4G Bouygues Telecom en partage de connexion :
(https://lafibre.info/images/wireshark/202001_dns_bouygues_4g_via_464xlat_1.png)
Note le mobile est en IPv6, ce sont donc des paquets qui passent par le 464XLAT.
La capture Wireshark pour vérifier que je dialogue bien avec :
- 1.0.0.0
- 240.0.0.0
- 255.255.255.254
(https://lafibre.info/images/wireshark/202001_dns_bouygues_4g_via_464xlat_2.png)
La capture wireshark (1 ko) si vous souhaitez regarder: (cliquer sur la miniature ci-dessous, Wireshark est nécessaire pour lire le fichier)
202001_dns_bouygues_4g_via_464xlat.pcapng.gz
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/images/wireshark/202001_dns_bouygues_4g_via_464xlat.pcapng.gz)
-
ah ca répond... mais ca devrait pas ;)
nslookup lafibre.info 240.240.10.10
Server: 240.240.10.10
Address: 240.240.10.10#53
Non-authoritative answer:
Name: lafibre.info
Address: 46.227.16.8
Name: lafibre.info
Address: 2a01:6e00:10:410::2
-
Il serait temps que Vivien contact Boris.
Le réseau raconte de la merde aux abonnés (bref il y a pas que le réseau , aussi le service client qui est incompétent).
Le service client m'a sortie ce matin "hors périmètre" alors que le problème viens de chez eux.
-
Le Boris doit avoir interdiction de parler ici depuix X années ou il a quitté l'entreprise sans remplaçant.
-
En ADSL chez Free :
dig A fhocorp.com @1.1.1.1 +dnssec
; <<>> DiG 9.11.14 <<>> A fhocorp.com @1.1.1.1 +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58847
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;fhocorp.com. IN A
;; AUTHORITY SECTION:
fhocorp.com. 300 IN SOA dns109.ovh.net. tech.ovh.net. 2020010601 86400 3600 3600000 300
fhocorp.com. 300 IN RRSIG SOA 7 2 3600 20200205175509 20200106175509 23717 fhocorp.com. CehiteBRLe4YOQIPRLhlVu3jr4UoWZrhaOz1GaHDQ6JvrlvH9NS1ekQL PAYWe+k6uY3kKcj5tygXQnDWwqY4I6G7YRl52VjzczIroHekRtlPDIqL P4Aj4HWT2+Y1QrfL87RRdRoF0WGHtgZn1AnBWbWx4idv8ZO9YGDqMe9h nH4=
trp7on947s7qdkfssjuop0blnka8a3ec.fhocorp.com. 300 IN NSEC3 1 0 8 67FDB78B3C439D71 TUSEMOKP6145429DN2J8U8OLJN9REU6R NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM
trp7on947s7qdkfssjuop0blnka8a3ec.fhocorp.com. 300 IN RRSIG NSEC3 7 3 300 20200205175509 20200106175509 23717 fhocorp.com. usFRbBWvFPYpNEiwlUeXplIhYhwaz3UM38Jw1vLppizlLzJLuN1MR3Hr iQRoD8FmirBfZqeLFBkhjNeULyxz7nMegNTOjsnaUI8GV49fmtOJZNhv 7tNoHxYDTktfUKfudD7uaIcsLAMuQv6tWmRRLghTrGhG7g+58kOdykrz tv0=
;; Query time: 73 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Jan 17 13:03:54 Paris, Madrid 2020
;; MSG SIZE rcvd: 525
En forfait 20GO DATA Bouygues :
dig A fhocorp.com @1.1.1.1 +dnssec
; <<>> DiG 9.11.14 <<>> A fhocorp.com @1.1.1.1 +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30484
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;fhocorp.com. IN A
;; AUTHORITY SECTION:
fhocorp.com. 300 IN SOA dns109.ovh.net. tech.ovh.net. 2020010601 86400 3600 3600000 300
;; Query time: 41 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Jan 17 13:04:39 Paris, Madrid 2020
;; MSG SIZE rcvd: 95
Il y a même plus de vérification DNSSEC chez Bouygues.
Très inquiétant
-
Le Boris doit avoir interdiction de parler ici depuix X années ou il a quitté l'entreprise sans remplaçant.
Boris a quitté Bouygues oui, après, il me semble que répondre ici était 100 % bénévole (et pas forcément "officiel"), donc si son "remplaçant" n'a pas envie de le faire ... beh il n'y a plus personne.
Mais il y a stlan qui de temps en temps dépanne sur les sujets Bouygues. Mais reste à voir si il est dans le même service que l'était Boris. et si il a les mêmes "pouvoirs" de remontées d'informations.
-
Slt,
Sa éviterai à Bouygtel d'avoir une "injonction de faire"https://www.service-public.fr/particuliers/vosdroits/F1787 (https://www.service-public.fr/particuliers/vosdroits/F1787)
Sa fait mal à eux mais si tout le monde concerner le fait on à tout à y gagner car c'est pas correct et pas honnête.
On pourrait même passer sa en loi piratage si il le faut (si sa coïncide avec un MITM).
-
On va être clair, c'est pas un bug c'est volontaire....
-
Je vais passer le mobile de madame sur RED ou Free.
-
Je vais passer le mobile de madame sur RED ou Free.
Slt Mogette,
Tu verras que chez Free le trafic est lisser.
Pas comme Bouygues et SFR ou la QOS fait des vagues en débit.
-
Je suis passé chez Free ( porta hier ) et pour le moment cela fonctionne bien mieux que chez B&You. Couverture meilleurs ( enfin par chez moi ).
A la lecture des différents postes sur ce topic, je n'ai pas tout compris un résumé serait bienvenu. Je souhaite migré les dernières liste B&You sur un autre opérateur.
-
Je suis passé chez Free ( porta hier ) et pour le moment cela fonctionne bien mieux que chez B&You. Couverture meilleurs ( enfin par chez moi ).
A la lecture des différents postes sur ce topic, je n'ai pas tout compris un résumé serait bienvenu. Je souhaite migré les dernières liste B&You sur un autre opérateur.
Slt Mogette,
Bouygues Force les DNS vers chez eux et leur DNS ment comme Pinocchio.
Bref sur certains forfaits comme le DATA et B&YOU, Bouygues filtre à font ses forfaits et dé-neutralise internet.
-
Le Boris doit avoir interdiction de parler ici depuix X années ou il a quitté l'entreprise sans remplaçant.
Boris va très bien, mais il a effectivement quitté Bouygues il y'a quelques années :-)
-
Slt Mogette,
Bouygues Force les DNS vers chez eux et leur DNS ment comme Pinocchio.
Bref sur certains forfaits comme le DATA et B&YOU, Bouygues filtre à font ses forfaits et dé-neutralise internet.
C'est relativement grave je trouve ! Je vais migrer la ligne de madame ailleurs !
-
Slt Mogette,
Bouygues Force les DNS vers chez eux et leur DNS ment comme Pinocchio.
Bref sur certains forfaits comme le DATA et B&YOU, Bouygues filtre à font ses forfaits et dé-neutralise internet.
Je me permets de te corriger : les DNS de Bouygues Telecom ne sont pas menteurs. Je suis aussi impacté par le forcage des DNS sur le mobile, et je n'aime pas ça non plus.
Mais ils ne sont en aucun cas menteurs.
Aucun autre filtrage n'est effectué. Avant de crier au loup, encore faudrait-il faire des mesures...
Qu-est ce qui te fait dire que Bouygues Telecom filre "à fond" les forfaits ?
-
Je me permets de te corriger : les DNS de Bouygues Telecom ne sont pas menteurs. Je suis aussi impacté par le forcage des DNS sur le mobile, et je n'aime pas ça non plus.
Mais ils ne sont en aucun cas menteurs.
Aucun autre filtrage n'est effectué. Avant de crier au loup, encore faudrait-il faire des mesures...
Qu-est ce qui te fait dire que Bouygues Telecom filre "à fond" les forfaits ?
Slt,
Moi je te recorrige, regarde bien le DNSSEC.
Les serveurs DNS nous racontent de la merde et dé-sécurise le protocole DNSSEC qui doit nous protéger.
Tu dois être "un sacré farceur" ou "Pro Bouygues".
Moi je vais faire un rapport à l'Arcep car je suis aussi un FAI et un client Bouygues.
-
En effet, je n'avais pas pensé à DNSSEC. Mes excuses.
Cependant, hors DNS/DNSSEC, aucun autre filtrage n'est réalisé. Et bien que cassant DNSSEC (car ils ne l'implémentent pas), ils ne "mentent" pas pour autant (les enregistrements DNS ne sont pas modifiés à la volée)
-
En effet, je n'avais pas pensé à DNSSEC. Mes excuses.
Cependant, hors DNS/DNSSEC, aucun autre filtrage n'est réalisé. Et bien que cassant DNSSEC (car ils ne l'implémentent pas), ils ne "mentent" pas pour autant (les enregistrements DNS ne sont pas modifiés à la volée)
Tout est filtré sur l'ensemble des forfaits sauf les 4GBox curieux.
-
Tout est filtré sur l'ensemble des forfaits sauf les 4GBox curieux.
Je confirme ce jour encore...
c'est facile pour le savoir quand vous avez 5 requêtes sur un DNS chinois entre 34 et 55ms alors que chez FREE c'est entre 150 et 750ms....
bien évidemment j'ai fait 3 aller/retour Free/BoT pour confirmer mes dires.
-
EDIT : J'ai vu dans un autre post relativement récent (janvier 2020) vers la fin de la page 6 qu'il y a pas plus de DNSSEC sur le résolveur de Bouygues. Donc les fausses valeurs RRSIG ne sont donc plus d'actualité (puisqu'il y a plus de DNSSEC sur les résolveurs de bouygues, leurs réponses n'ont plus de champs RRSIG du tout, forcément). Mais ce même test montre que le MITM sur DNS est toujours d’actualité. Le serveur interrogé supporte DNSSEC. Donc il doit retourner un champ RRSIG quand c'est explicitement demandé et le domaine à résoudre en a un. Or une requête demandant le champ RRSIG (dig +dnssec) depuis une connexion Bouygues 4G, pour la résolution d'un nom de domaine ayant signature, le champs RRSIG n'est pas retourné alors qu'il devrait être présent. C'est dû au fait le résolveur qui a en réalité répondu à la place de celui interrogé, ne connaît pas DNSSEC, donc celui de Bouygues.
Salut,
Note importante : J'ai quitté Bouygues peu après cette histoire de MITM sur DNS, et pour une qualité réseau douteuse dans ma zone géographique. Donc j'ai pas pu retester fin 2017 et plus tard et il se peut que la précision que je vais donner ne soit plus d’actualité (mais j'en doute fort vu les retours que j'ai eu y a quelques mois).
Je me permets de te corriger : les DNS de Bouygues Telecom ne sont pas menteurs. Je suis aussi impacté par le forcage des DNS sur le mobile, et je n'aime pas ça non plus.
Mais ils ne sont en aucun cas menteurs.
Aucun autre filtrage n'est effectué. Avant de crier au loup, encore faudrait-il faire des mesures...
Qu-est ce qui te fait dire que Bouygues Telecom filre "à fond" les forfaits ?
Faut déjà les lire « les mesures » qui ont été faites par pleins de gens ici, avant de répondre…
En effet, je n'avais pas pensé à DNSSEC. Mes excuses.
Cependant, hors DNS/DNSSEC, aucun autre filtrage n'est réalisé. Et bien que cassant DNSSEC (car ils ne l'implémentent pas), ils ne "mentent" pas pour autant (les enregistrements DNS ne sont pas modifiés à la volée)
Même si les IP ne sont apparemment pas modifiées¹, ça n'annule en rien le problème dont il est question. Le résolveur de Bouygues donne des infos (autres que l'IP) qui sont fausses. Donc en ce sens, il ment.
Et déjà empêcher d’utiliser le résolveur qu'on veut, pour en imposer un tout pourri est une forme de filtrage! Et une forme de filtrage grave !
Mais surtout l'affirmation que DNSSEC est cassé juste parce que juste parce que DNSSEC « n'est pas implémenté » est fausse. Si il le cas, ce serai moins grave que ce fait Bouygues…
Si DNSSEC n'était juste pas supporté, y aurait tout simplement aucune fausse information relative à DNSSEC, puisque le protocole serait juste inconnu/pas utilisable… Donc le champ signature (RRSIG) existerai pas dans les réponses issus du résolveur de Bouygues. Or, ce n'est pas DU TOUT ce qui se passe ici.
Comme je l'ai précisé dans mon post de blog (et démonté par de tests + captures d'écrans) à ce sujet, et au début de ce thread, le résolveur de Bouygues qui en plus de répondre de force aux requêtes qui ne lui sent pas destinés, via du Man-In-The-Middle², génère des signatures DNSSEC erronés. Et ce pour la totalité des noms des résolutions, que les noms de domaines concernés aient ou non un enregistrement RRSIG (signature pour des enregistrements « protégés » par DNSSEC). Un protocole qui fournit des informations foireuses « juste par le protocole concerné n'est pas implémenté » est un concept intriguant…
Maintenant, je ne sais pas pour la partie RRSIG erronée, si c'est volontaire/pourquoi, ou c'est si c'est juste de l'incompétence. Dans les 2 cas
- Il y a un du MITM crasse, qui n'a pas de raison d’être
- Y a aucune raison de bousiller DNSSEC. Même si c'est une coquille, il aurait peut-être fallut le corriger dans un délai raisonnable, alors que c'est littéralement resté pendant au quasiment 3 bonnes années (constaté en automne 2016, retours d'autres clients bouygues ayant toujours ce problème, datant de fin 2019), et que c'est probablement toujours d'actualité.
Faut peut-être lire avant de répondre hein. T'es pas le premier à faire ce genre de réponses… Ça commence à devenir agaçant d'avoir ce genre de réponses pleins de déni, basés uniquement sur des propos pleins de certitudes (0 preuves), et qui vont pourtant à l'encontre que ce que les tests³ ont démontré.
1. À voir si c'est vrai tout le temps, qu'un aucun moment ce n'est utilisé à des fins de censure commerciale/sur simple de demandes de prévus ayants-droits ou whatever, commme c'est le cas de certains hébergeurs qui font sauter du contenu dérivé/3 secondes d’extraits au mépris du fair use à la moindre demande des ayants-tous-les-droits…
2. Le proxy/CGNAT de bouygues filtre/redirige toute requête DNSa destinée à un résolveur non contrôlé par Bouygues, vers le résolveur de Bouygues.
a. Du DNS « à l'ancienne », en plaintext, donc hors DoH/DoT qui sont tous récents et peu répandues.
3. Non seulement les miens, mais aussi ceux de tous les contributeurs à ce sujet, qui ont refait les tests de leurs cotés… Difficile de m'accuser de présenter de faux de tests, ou de parler d'un filtrage/MITM imaginaire…
-
Qui peut faire un petit test sur le port 53 sur la 4G Bouygues Telecom ?
Une bonne nouvelle pourrait arriver...
C'est un test a réaliser en mettant son smartphone en partage de connexion.
Si c'est bon, le fichier test de 10 Mo se télécharge.
Si c'est pas bon, il y a un échec.
Tutoriel sous Windows :
Étape 1 : Télécharger CURL
- CURL 7.54 (64bits pour Windows 64bits) (https://soft.lafibre.info/download/windows/network-utilities/curl/curl-7.54.0-win64.exe)
- CURL 7.54 (32bits pour Windows 32bits) (https://soft.lafibre.info/download/windows/network-utilities/curl/curl-7.54.0-win32.exe)
Étape 2 :
Renommer votre version de curl en curl.exe et placez là dans le dossier C:\WINDOWS
Étape 3 :
Dans le menu démarrer, lancer l'application "Invite de commandes" (pour aller plus vite, cherchez cmd dans le champ de recherche)
Si curl.exe n'est pas dans C:\WINDOWS, placez vous dans le dossier où il est installé, par exemple avec la commande cd Downloads si il est dans le dossier téléchargement.
Étape 4 : Test du port 53
- IPv4 : curl -4 -k -o NUL https://k-net.testdebit.info:53/10M.iso
- IPv6 : curl -6 -k -o NUL https://k-net.testdebit.info:53/10M.iso
Tutoriel sous Linux : (wget est toujours pré-installé)
- IPv4 : wget -4 -O /dev/null https://bouygues.testdebit.info:53/10M.iso
- IPv6 : wget -6 -O /dev/null https://bouygues.testdebit.info:53/10M.iso
Tutoriel sous MacOS :
Bonne nouvelle, curl est installé de base sur les Mac.
Si ce n'est pas le cas :
- Démarrez un terminal (Raccourci clavier : Command + barre espace)
- Exécutez ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" < /dev/null 2> /dev/null
- Exécutez brew install curl
- IPv4 : curl -4 -o /dev/null https://k-net.testdebit.info:53/10M.iso
- IPv6 : curl -6 -o /dev/null https://k-net.testdebit.info:53/10M.iso
En bonus, il serait intéressant de tester avec un TTL simulant une connexion du smartphone :
Bouygues Telecom décompte la consommation du forfait, en présence d'un routeur/partage de connexion coté abonné sur son bonus option illimité le week-end.
Pour avoir le trafic en illimité, même en mode modem (ou avec un routeur 4G) il faut modifier le TTL des PC connecté à ton point d’accès pour avoir l'illimité même sur PC :
- TTL = 63 ou 64 ou 127 ou 128 = facturation (par défaut le TTL est de 64 ou 128)
- TTL autre que 63 ou 64 ou 127 ou 128 = non facturation
Modifier le TTL sur Windows
Commande pour afficher le TTL sous Windows :
netsh int ipv4 show glob
netsh int ipv6 show glob
Changement du TTL sous Windows pour avoir de la data illimitée : (à exécuter avec les privilèges administrateurs)
netsh int ipv4 set glob defaultcurhoplimit=65
netsh int ipv6 set glob defaultcurhoplimit=65
Modifier le TTL sur Linux :
Commande pour afficher le TTL sous Linux :
cat /proc/sys/net/ipv4/ip_default_ttl
64
Commande pour changer le TTL sous Linux pour avoir de la data illimitée :
sudo sysctl net.ipv4.ip_default_ttl=65
Commande pour rendre le changement de TTL persistant au redémarrage sous Linux :
sudo nano /etc/sysctl.conf
Rajouter en début de fichier la ligne :
net.ipv4.ip_default_ttl = 65
Exemple :
(https://lafibre.info/testdebit/ubuntu/201704_etc_sysctl_ttl.png)
Modifier le TTL sur MacOS
Commande pour changer le TTL sous MacOS pour avoir de la data illimitée :
sudo sysctl -w net.inet.ip.ttl=65
Modifier le TTL sur un routeur
Pour les routeurs basés sur Linux, qui permettent de rajouter une ligne iptables, voici la ligne à rajouter pour forcer un TTL de 65 pour tous les périphériques :
iptables -t mangle -I POSTROUTING -o `nvram get wan_iface` -j TTL --ttl-set 65
-
Ça fonctionne, mais même en testant des ports au hasard ça marche toujours.
Donc Bouygues ignore le port c'est ça ?
-
Le serveur écoute sur tous les ports en https, du port 1 au port 9199 (sauf les ports 80/81 qui écoutent en http)
Il est donc normal que cela fonctionne quel que soit le port (dans la limite de ceux écouté par le serveur).
Les problèmes de Bouygues qui concernaient 3 ports :
- Port 25 (smtp)
- Port 53 (dns)
- Port 8080 (SpeedTest)
Sont donc clos.
C'est une bonne nouvelle, Bouygues Telecom est maintenant neutre.
-
Hi
Ça fonctionne, hourra :)
Forfait Sensation 100 Go, partage de connexion vers mon MacBook :
eahlys@EdBook:~# curl -6 -o /dev/null https://k-net.testdebit.info:53/1G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
1 953M 1 18.0M 0 0 2679k 0 0:06:04 0:00:06 0:05:58 3228k^C
edraens@EdBook:~# sudo sysctl -w net.inet.ip.ttl=65
net.inet.ip.ttl: 64 -> 65
eahlys@EdBook:~# curl -6 -o /dev/null https://k-net.testdebit.info:53/1G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
2 953M 2 22.7M 0 0 2684k 0 0:06:03 0:00:08 0:05:55 3627k^C
Il en aura fallu du temps :)
-
En IPv4 aussi ?
(C'est bien de tout vérifier, au cas où des règles ont été oubliées)
-
En IPv4 aussi ?
(C'est bien de tout vérifier, au cas où des règles ont été oubliées)
My bad, dans la précipitation j'ai oublié :)
Oui !
eahlys@EdBook:~# curl -4 -o /dev/null https://k-net.testdebit.info:53/1G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
1 953M 1 15.1M 0 0 2614k 0 0:06:13 0:00:05 0:06:08 3162k^C
edraens@EdBook:~# sudo sysctl -w net.inet.ip.ttl=65
net.inet.ip.ttl: 64 -> 65
eahlys@EdBook:~# curl -4 -o /dev/null https://k-net.testdebit.info:53/1G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
1 953M 1 9776k 0 0 2605k 0 0:06:14 0:00:03 0:06:11 2604k^C
-
C'est bon sous routeur 4G et sous smartphone...
sous android j'utilise "DNS speedmeter" et je mets en DNS 1.2.4.8 c'est du DNS public chinois ou HK donc si j'ai une réponse inférieure à 100ms je sais que c'est pas bon...