La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Opérateurs grand public alternatifs => 
MilkyWan => Discussion démarrée par: patrick_01 le 20 septembre 2022 à 08:58:41
-
Hello,
Est-ce qu'il y a ici des abonnés fibre sur le réseau du SIEA (Ain 01), qui ont un DNS authoritative (pas juste un resolver) au bout de leur fibre optique ?
C'est mon cas, et il me semble constater qu'il y a un filtre / un firewall quelque part entre chez moi et le réseau MilkyWan : impossible d'interroger le DNS (à l'intérieur de mon réseau) depuis l'extérieur (un VPS ou une connexion 4G par exemple).
Mes traces montrent que les paquets sortants (donc les réponses DNS) quittent mon routeur sur l'interface vers le CPE fibre, mais n'arrivent pas à destination.
Est-ce qu'il y a quelqu'un qui a aussi ce style de configuration ? Je pense à des gens qui s'auto-hébergent, évidemment.
-
C'est curieux ça.
Pour résumé, si j'ai bien compris :
Les DNS query arrivent chez toi : UDP port ABC -> port 53
Tu renvoies une réponse : UDP port 53 -> ABC qui sort bien de ton routeur, mais n'arrive pas à destination.
Donc le filtrage serait seulement sur les paquets émis chez toi, depuis le port 53 ?
As-tu essayé pour tests avec un autre port que 53 pour ton serveur DNS ? (pour confirmer que c'est bien ça)
-
En tout cas, on ne filtre pas le port 53 de notre coté, le seul port filtré c'est le port 111 (sunrpc) pour éviter de l'ampli ddos
-
Pour résumé, si j'ai bien compris :
Les DNS query arrivent chez toi : UDP port ABC -> port 53
Tu renvoies une réponse : UDP port 53 -> ABC qui sort bien de ton routeur, mais n'arrive pas à destination.
C'est exactement ça. Je vois le paquet sortir de mon routeur sur l'interface ethernet vers le CPE, je ne le vois pas arriver sur la machine qui a fait la query.
Donc le filtrage serait seulement sur les paquets émis chez toi, depuis le port 53 ?
Apparement, oui. D'ailleurs, quoi que j'envoie avec un port source 53 ne passe pas.
Même un truc aussi con que echo -n "hello" |nc -p 53 -u -q1 [destination] 12345 est filtré, et ça passe avec les autres ports, privileged ou pas.
J'observe le même comportement en IPv4 et IPv6, en TCP et UDP.
As-tu essayé pour tests avec un autre port que 53 pour ton serveur DNS ? (pour confirmer que c'est bien ça)
Bien vu : oui, avec listen-on port 5533 {any;}; sur mon DNS et dig -p 5533, les queries aboutissent, et je reçois une réponse.
En tout cas, on ne filtre pas le port 53 de notre coté, le seul port filtré c'est le port 111 (sunrpc) pour éviter de l'ampli ddos
OK, c'est bien ce que je pense. D'ailleurs sur le L2TP ça passe : comme workaround pour l'instant, j'ai joué du routing-mark sur mon routeur pour forcer les paquet avec src-port=53 sur le L2TP (mais malheureusement RouterOS v6 ne sait pas faire ça en IPv6).
J'aimerais bien me dire que j'ai fait une connerie quelque part, mais là ça me rappelle gentiment une autre emmerde récente dont tu dois te souvenir, quand le SIEA avait mis un filtre sur le BGP
(jamais su si c'était volontaire et délibéré, ou si c'était un effet de bord d'une autre modif).
-
Ça ne semble pas être de ton côté le problème...
Tous tes tests semblent bien confirmer un blocage unidirectionel du port 53 au niveau du SIEA ou dans le CPE (donc SIEA aussi).
-
Du coup je te confirme que le SIEA bloque bien l'UDP53, et que ça a été débloqué sur ton switch a l'instant...
-
Ils font ça pourquoi ?
-
Ils font ça pourquoi ?
Pour éviter les relais DNS ouverts aux 4 vents je présume.
-
C'est un cas qui semble peu probable.
Avec les box qui font du NAT, il faut ouvrir les ports et enfin c'est pas Mme michu qui a un serveur DNS chez elle.
L'autre point qui est choquant, c'est que ce soit l'opérateur d'infrastructure qui filtre. Sur quelle base légale ?
-
L'autre point qui est choquant, c'est que ce soit l'opérateur d'infrastructure qui filtre. Sur quelle base légale ?
Aucune, et je t'avoue que ça commence à me soûler, j'ai la chance d'avoir un interlocuteur très compréhensif coté SIEA, mais là ils s'assoient totalement sur la loi et ça ne me plait pas du tout.
-
Du coup je te confirme que le SIEA bloque bien l'UDP53, et que ça a été débloqué sur ton switch a l'instant...
En effet : ça refonctionne.
Alors d'abord, merci Hugues pour la réaction et la correction rapide, c'est vraiment appréciable de ta part.
(et honte à moi de n'avoir toujours pas mis un système de monitoring et d'alerting sur mon infrastructure, c'est pourtant pas difficile aujourd'hui)
Ensuite, ça me préoccupe un peu toute cette histoire. C'est la deuxième fois en quelques semaines que le SIEA fait des modifications sur leur config sans avertir ni les abonnés, ni les FAI (dans les deux cas, Hugues n'était apparemment pas au courant avant que je lui signale). Chaque fois, ça a cassé quelque chose dont j'ai besoin, la première fois c'était le BGP qui était filtré (port 179 TCP sortant), maintenant le DNS (port 53 TCP et UDP sortant).
Alors OK, l'abonné de FAI moyen il s'en fout de faire du BGP ou du DNS depuis chez lui, le port 443 vers les les google facebook amazon et netflix lui suffit, ces problèmes n'affectent pas tout le monde. Mais j'ai quand même l'impression que ce n'est pas le rôle d'un exploitant de fibre de faire ce genre de filtrage. S'il y a abus, attaque, DDoS, open relay DNS etc, on s'adressera au FAI qui attribue les adresses, pas au SIEA. Pour moi, la fibre devrait être un tuyau transparent entre le FAI et l'abonné. Qu'il y ait des limitations au layer 2, du DHCP snooping, de l'IPv6 qui fonctionne pas partout, je peux comprendre, sinon excuser. Il y a des explications techniques derrière. Mais du filtrage délibéré sur les couches supérieures (ici on est au blocage de ports UDP/TCP), désolé mais non, c'est pas leur métier.
J'ai choisi MilkyWan parce qu'ils offrent un réseau neutre et transparent, mais le SIEA vient entre deux pour empêcher MilkyWan de me fournir le service proposé, ce n'est pas normal. Demain c'est peut être le SMTP qui s'arrête à l'improviste, ou le 80/443, je suis emmerdé du jour au lendemain, et je viens me plaindre chez Hugues qui n'y est pour rien.
Hugues, te laisse pas faire :) C'est cool que tu aies le bon interlocuteur au SIEA, et ça simplifie les choses, mais ces questions devraient être réglées en amont, et donc traitées comme un ticket de panne franche, que l'interlocuteur soit compréhensif ou non.
Même si je me demande s'il y a vraiment des "lois" qui régissent les rapports entre FAI et OI, sur ce sujet ma compréhension est limitée.
<mode coup de gueule="off"> ;)
Un point positif quand même pour le SIEA : l'IPv6 qu'ils n'ont jamais réussi à faire marcher proprement avec K-Net fonctionne sans souci depuis que j'ai passé chez MW.
-
Un point positif quand même pour le SIEA : l'IPv6 qu'ils n'ont jamais réussi à faire marcher proprement avec K-Net fonctionne sans souci depuis que j'ai passé chez MW.
On a pris la place de K-Net dans le pilote IPv6 du SIEA, faut dire...
Mais oui je suis assez en colère sur le sujet et ils le savent bien, et ça finira à l'ARCEP s'il le faut...
-
C'est un cas qui semble peu probable.
J'ai trouvé pas mal de routeur Zyxel mal configuré où le service cache DNS écoute (et répond) sur le Wan.
Et ils sont souvent en train de participer à une attaque DDOS par amplification...
-
Ils font ça pourquoi ?
Et bonjour la neutralité du Net
-
On a pris la place de K-Net dans le pilote IPv6 du SIEA, faut dire...
Mais oui je suis assez en colère sur le sujet et ils le savent bien, et ça finira à l'ARCEP s'il le faut...
deux cartons rouges : un pour le SIEA et un pour Hugues (qui publie "Absence de bridage, neutralité du net" sur ses offres et coupe le port 111).
-
J'ai trouvé pas mal de routeur Zyxel mal configuré où le service cache DNS écoute (et répond) sur le Wan.
Et ils sont souvent en train de participer à une attaque DDOS par amplification...
Ouais, c'est clair. Mais en jouant "l'avocat du diable", on peut aussi dire : "j'ai trouvé pas mal d'abonnés qui ont des machines infectées qui font partie de botnets, donc on leur coupe purement et simplement l'accès au réseau". Une machine Windows sortie du carton n'est probablement pas plus propre qu'un routeur Zyxel mal configuré.
De manière générale j'ai l'impression que les abonnés MilkyWan sont suffisemment compétents pour comprendre de quoi il retourne si Hugues ou le SIEA leur signale qu'ils ont un DNS ouvert. C'est pour ça que MW peut offrir un réseau neutre et sans bridage. "Mme Michu" (ou Mr Michu, ne soyons pas sexistes) va habituellement chez Orange / SFR / Free.
Ce genre de cas doit se gérer par un texte de conditions d'utilisation, par par filtrage par défaut. Et un scan d'un range pour voir s'il y a un relais DNS ouvert, c'est 10 lignes de script, et on agit au coup par coup sur les positifs.
-
J'ai trouvé pas mal de routeur Zyxel mal configuré où le service cache DNS écoute (et répond) sur le Wan.
Et ils sont souvent en train de participer à une attaque DDOS par amplification...
Dans ce cas-là, si cela met le réseau en danger, c'est au fournisseur d'accès de mettre à jour (ou à la limite de bloquer) pas à l'opérateur d'infrastructure. Vous remarquerez que chez les OCEN, les blocages de ports sur le fixe se font plutôt sur la box que sur le réseau (oui, il reste la problématique de port TCP 25 chez Orange qui est bloqué au niveau réseau, pour moi cela à vocation à partir sur la box comme chez les 3 autres).
-
un pour Hugues (qui publie "Absence de bridage, neutralité du net" sur ses offres et coupe le port 111).
Oui oui d'accord :
FAI c'est un métier assez classique, techniquement à la portée de gamins de 15-20 ans
Du coup je t'invite à monter le tien et tu comprendras pourquoi certaines décisions doivent être prises.
PS : Le 111 est filtré depuis au moins 4 ans et personne, même toi ne s'en est plaint. Dont acte.
D'ailleurs il est filtré sur pas mal de réseaux, GP ou pas, et ça n'émeut globalement personne vu l'inutilité de ce protocole vs la nuisance qu'il génère
-
PS : Le 111 est filtré depuis au moins 4 ans et personne, même toi ne s'en est plaint. Dont acte.
D'ailleurs il est filtré sur pas mal de réseaux, GP ou pas, et ça n'émeut globalement personne vu l'inutilité de ce protocole vs la nuisance qu'il génère
Sur le principe j'ai pas de religion (même si j'ai tendance à penser que tout blocage de port quel qu'il soit est toujours une pente savonneuse).
Par contre dans un souci de cohérence, et surtout d'information, ce serait pas mal que ce soit documenté il me semble ;)
La FAQ (https://milkywan.fr/faqfai/) indique:
Il n'y a ni bridage ni blocage de port. C'est la nature même de MilkyWan :-)
ce qui est donc manifestement inexact :)
-
ce qui est donc manifestement inexact :)
Y a plusieurs lectures possible: "manifestement" le port est actuellement ouvert. Il a en effet eu blocage par un intermédiaire, que nous avons traité comme un incident et celui-ci a été résolu. On parle pas d'un blocage délibéré de port et pour lequel aucun recours n'est possible. Je trouve pas tout à fait comparable à un filtrage du port 25 par Orange et pour lequel il n'y pas de recours possible ;)
-
Après, pour portmapper, cela pourrait être juste un blocage de l'UDP, plus exposé.
NFSv3 est utilisable avec TCP/port 111, c'est d'ailleurs la configuration par défaut des clients je crois.
Mais dans tous les cas on est d'accord que plus personne n'utilise ce truc hors-LAN ? ::).
-
Ah oui c'est uniquement udp111 qui est bloqué, pas tcp111 :)
-
Mais dans tous les cas on est d'accord que plus personne n'utilise ce truc hors-LAN ? ::).
Tu as des NAS, notamment Synology ou QNAP qui ont ce port ouvert justement
-
Oui, il y a bien deux points ici :
Le port 53 bloqué par le SIEA (pire, sans communication préalable à leurs clients), qui pose des questions légales et éthiques vu que ce n'est pas leur rôle.
Le port 111 bloqué par MW pour des raisons de sécurité/stabilité de l'infrastructure.
Ça n'est pas caché, MW est transparent, mais en effet, cela entre en contradiction avec la déclaration sur le site, un oubli qui sera corrigé ! Merci @blarglibloup d'avoir remarqué cela :)
-
Le port 25 bloqué par le SIEA
C'était pas le 25 mais le 53. Le 25 c'est chez Orange, si j'en crois ce qui est écrit plus haut.
(pire, sans communication préalable à leurs clients),
Mais en fait c'est qui les clients du SIEA ? Parce que les deux fois où je les ai contactés, il m'ont expliqué qu'ils ne traitaient pas avec les abonnés et que mon interlocuteur unique était mon FAI.
Et effectivement, je ne paye rien directement au SIEA et je n'ai jamais signé de contrat avec eux.
qui pose des questions légales et éthiques vu que ce n'est pas leur rôle.
"Éthiques", sans discussion possible, même si le mot est un peu fort.
Mais "légales" ?? Est-ce qu'il y a des documents contractuels, donc contraignants, qui définissent l'interface technique entre FAI et opérateurs fibre ? Si oui, le FAI peut aller voir l'OI et lui dire "là tu ne respectes pas le contrat, donc tu corriges", et que l'interlocuteur soit compréhensif (comme l'écrivait Hugues) ou pas, c'est contractuel.
(même si ça n'est jamais désagréable de bosser avec des gens avec qui le courant passe...)
Vivien, est-ce que l'ARCEP a son mot à dire là-dessus, en tant que régulateur ?
-
Tout le monde devrait se réjouïr de ce que le portmapper soit filtré. Il y a sans doute une entaille à un principe auquel les gens sont attachés mais il y a aussi une bonne dose de pragmatisme à avoir.
Comme on patche un code, la bonne attitude serait, à mon avis, de proposer un patch de documentation à MW, tout bonnement.
-
C'était pas le 25 mais le 53. Le 25 c'est chez Orange, si j'en crois ce qui est écrit plus haut.
Mais en fait c'est qui les clients du SIEA ? Parce que les deux fois où je les ai contactés, il m'ont expliqué qu'ils ne traitaient pas avec les abonnés et que mon interlocuteur unique était mon FAI.
Et effectivement, je ne paye rien directement au SIEA et je n'ai jamais signé de contrat avec eux.
"Éthiques", sans discussion possible, même si le mot est un peu fort.
Mais "légales" ?? Est-ce qu'il y a des documents contractuels, donc contraignants, qui définissent l'interface technique entre FAI et opérateurs fibre ? Si oui, le FAI peut aller voir l'OI et lui dire "là tu ne respectes pas le contrat, donc tu corriges", et que l'interlocuteur soit compréhensif (comme l'écrivait Hugues) ou pas, c'est contractuel.
(même si ça n'est jamais désagréable de bosser avec des gens avec qui le courant passe...)
Vivien, est-ce que l'ARCEP a son mot à dire là-dessus, en tant que régulateur ?
Oui, SIEA port 53, j'ai écrit trop vite… Je corrige sur mon post initial.
Problèmes éthiques, car de quel droit moral le font-ils, et dans quel but, au nom de quoi/qui ? Après, le mot est peut-être un peu fort. Mais ça soulève une question : l'OI peut-il décider unilatéralement et sans même en avertir ses clients de bloquer des ports ?
Et légalement, j'imagine que c'est un problème aussi. Après, tout cela est mon opinion/ressenti, je ne suis pas juriste, et je ne connais pas personnellement les termes des contrats, donc…
-
Tout le monde devrait se réjouïr de ce que le portmapper soit filtré. Il y a sans doute une entaille à un principe auquel les gens sont attachés mais il y a aussi une bonne dose de pragmatisme à avoir.
Comme on patche un code, la bonne attitude serait, à mon avis, de proposer un patch de documentation à MW, tout bonnement.
C'est surtout un problème de communication aussi.
Si l'ouverture du port 53 créait de réels problèmes à la stabilité des services de l'OI (pour je ne sais quelle raison), ce serait justifié (sans cela, nous ne pouvons offrir de service stable), mais encore faut-il l'annoncer à ses clients (à savoir les FAI qui utilisent cet OI) et l'expliquer…
Mais c'est encore une fois en principe à l'OC (FAI) de décider ou non de bloquer des ports, pas l'OI.
-
Tout le monde devrait se réjouïr de ce que le portmapper soit filtré.
Ah bon, pourquoi?
-
parce que ça ne sert a rien à part de l'ampli ddos aujourd'hui...
-
C'est surtout un problème de communication aussi.
Si l'ouverture du port 53 créait de réels problèmes à la stabilité des services de l'OI (pour je ne sais quelle raison), ce serait justifié (sans cela, nous ne pouvons offrir de service stable), mais encore faut-il l'annoncer à ses clients (à savoir les FAI qui utilisent cet OI) et l'expliquer…
Mais c'est encore une fois en principe à l'OC (FAI) de décider ou non de bloquer des ports, pas l'OI.
Je ne vous parle pas du DNS.
Par ailleurs je ne sais pas si c'est au FAI de tout décider. Je vois seulement l'aspect concret de bloquer ce portmapper. L'écueil est la documentation du fait, c'est à mon avis mineur et nécessite de ceux qui s'en préoccupent de simplement proposer un patch de documentation dont MW jugera de la pertinence. Rien de bien important ni grave de mon point de vue.
-
Sur le principe, filtrer un port, c'est débile. Cela oblige à déplacer le service vers un autre port non standard, pour ceux en ayant un besoin.
On a crée les port avec des services derrière, pourquoi ? Pour les filtrer !! Allez chercher l'erreur...
Soit on a besoin du service standard, et le port est ouvert avec le service, soit on en a pas besoin et le service n'est pas ouvert.
On place le cadre et le périmètre de responsabilité ou ? Chez le fournisseur de service, ou l'utilisateur ?
On voit bien, au nom de la sécurité, toutes les dérives envers la Liberté.
Portmapper c'est pas pour NIS/NFS ? On a tendance à sécuriser ( par cryptage essentiellement) la totalité des services ( http, dns etc.) peut-être sécuriser nfs ?
-
Je ne vous parle pas du DNS.
Par ailleurs je ne sais pas si c'est au FAI de tout décider. Je vois seulement l'aspect concret de bloquer ce portmapper. L'écueil est la documentation du fait, c'est à mon avis mineur et nécessite de ceux qui s'en préoccupent de simplement proposer un patch de documentation dont MW jugera de la pertinence. Rien de bien important ni grave de mon point de vue.
Ah oui, pour le port 111, non seulement la décision avait été prise en raison d'attaques DDOS, mais MW étant FAI, a le droit de prendre cette décision.
Après, oui, c'est une petite entorse à la neutralité annoncée sur la faq du site MW spécifiant qu'aucun port n'est bloqué et qu'on s'est retrouvé avec un port non courant bloqué en UDP... On ne l'avait même pas réalisé en fait.
Je suis bien d'accord que ce n'est ni important ni grave, et que le blocage de ce port apporte une sécurité et ne manque à aucun abonné.
Après, oui, on va je pense corriger cela d'une manière ou d'une autre, histoire d'être cohérent, mais ce n'est pas une urgence ni un problème de fond.
Et non Anonyme, ce n'est pas débile. Ce port quasi désuet pour son usage initial est utilisé à des fins malveillantes sur le WAN et cela posait des problèmes sérieux et concrets sur le réseau. Hugues ne s'amuse pas à prendre des décisions arbitraires, personne ne met en doute, j'espère, sa décision experte et justifiée.
Le port 111 a plus de sens sur un LAN que le WAN de toute façon...
-
Et non Anonyme, ce n'est pas débile. Ce port quasi désuet pour son usage initial est utilisé à des fins malveillantes sur le WAN et cela posait des problèmes sérieux et concrets sur le réseau. Hugues ne s'amuse pas à prendre des décisions arbitraires, personne ne met en doute, j'espère, sa décision experte et justifiée.
Le port 111 a plus de sens sur un LAN que le WAN de toute façon...
Si c'est débile, sous prétexte que un outil n'est pas utilisé comme il faut, cela reviens à supprimer l'outil.
L'analogie est simple, c'est pas parce que certains utilisent un couteau pour tuer des gens qu'il faut interdire le couteau.
C'est une question plus profonde que filtrer le port 111 ou pas, sinon c'est la porte ouverte à n'importe quel port, d'Amsterdam ou d'ailleurs.
25 chez Orange, 26 chez, chez pas qui, 53, chez untel, ou autre chez tel autre. C'est débile !!!
-
parce que ça ne sert a rien à part de l'ampli ddos aujourd'hui...
ouais mais tu comprends bien qu'avec ce genre de raisonnement (qui assume que l'utilisateur final est incompétent), on ferme tout...
Ensuite on pourrait avoir autre chose sur le port 111 qu'un portmapper. Bref, a minima ce serait bien que ce soit documenté :)
-
Ensuite on pourrait avoir autre chose sur le port 111 qu'un portmapper.
En UDP ? :)
-
Portmapper c'est pas pour NIS/NFS ? On a tendance à sécuriser ( par cryptage essentiellement) la totalité des services ( http, dns etc.) peut-être sécuriser nfs ?
Tout est dit, un NFSv4-only n'a d'ailleurs pas besoin du port 111 :P.
C'est donc un faux débat pour un protocole non exclusif sur un port plus utilisé ::).
-
En UDP ? :)
Un endpoint wireguard ;D
-
Si c'est débile, sous prétexte que un outil n'est pas utilisé comme il faut, cela reviens à supprimer l'outil.
L'analogie est simple, c'est pas parce que certains utilisent un couteau pour tuer des gens qu'il faut interdire le couteau.
C'est une question plus profonde que filtrer le port 111 ou pas, sinon c'est la porte ouverte à n'importe quel port, d'Amsterdam ou d'ailleurs.
25 chez Orange, 26 chez, chez pas qui, 53, chez untel, ou autre chez tel autre. C'est débile !!!
Alors tu serais populaire dans les débats de la NRA sur le port d'arme aux US toi ;D
Sérieusement, dans le fond, c'est pas débile, mais c'est dommage ! Ce qui est débile, c'est les attaques DDOS !
Je ne sais pas pour Orange et autres, mais pour MilkyWan, le port 111 a été fermé (à ce que je sache) non pas arbitrairement pour embêter les abonnés et tirer un quelconque intérêt financier ou personnel (MW est une association à but non lucratif, et nous sommes tous bénévoles hein), mais bien parce qu'il y avait des attaques bien réelles (pas potentielles) qui exploitaient ce port en UDP, et qu'il fallait bien faire quelque chose pour assurer la stabilité et la capacité du réseau, et ce dans la mesure de nos moyens !
C'est dommage, oui, mais l'impact est quasi nul sur le principe de neutralité, si ce n'est que oui, la pratique met un petit coup dans la peinture du théorique : un port désuet sur un seul protocole (UDP) se retrouve bloqué.
La seule faute ici de MilkyWan est peut-être de ne pas avoir été clair sur ce blocage, mais quand cela a été mis en place, personne n'a pensé à l'impact sur le principe de neutralité, et comme ça ne gênait personne dans les faits, et bien personne n'y a repensé, jusqu'à aujourd'hui. Ce n'est donc absolument pas intentionnel.
Cela sera arrangé : la communication sera corrigée (la mention des ports sur la FAQ), et/ou le port 111 sera réouvert si la situation n'est plus critique.
N'oubliez pas que nous sommes bénévoles et que nous donnons la priorité du temps que nous y dédions au support de nos abonnés, à l'ouverture de raccordements, à la communications avec les OI…
-
C'est débile, autant chez Orange que chez MW.
Ensuite cela n'a aucun intérêt d'essayer de me justifier le bien fondé d'un quelconque hypothétique argumentaire sur le sujet.
Le problème est plus profond et lié à TCP/IP intrinsèquement qui permet que les DDOS soit possible.
C'est à dire que pour palier à un problème intrinsèque ( tout autant que le NAT) on a créé des usines à gaz, et on continue de le faire, en dépit du bon sens.
Et en plus je lis des argumentaires justifiant ce qui est injustifiable.
On a crée 65555 ports pour des services derrière, on les a standardisés.
Maintenant, on crée des outils pour les filtrer, ou encore le comble de l'intelligence, on change le port d'écoute, c'est tout aussi simple que le service ne tourne pas derrière. Non on continue à élaborer des usines à gaz.
Ce n'est pas incriminer MW, vous faites ce que vous pouvez avec vos connaissances à un instant donné. Le propos, est juste de vous faire remarquer, que c'est dénué de bon sens de faire cela, ensuite si les "attaques" se déplacent vers un autre port, vous faites quoi ? La course à l'échalote de la fermeture de ports ? C'est pas une solution.
-
C'est débile, autant chez Orange que chez MW.
Ensuite cela n'a aucun intérêt d'essayer de me justifier le bien fondé d'un quelconque hypothétique argumentaire sur le sujet.
Le problème est plus profond et lié à TCP/IP intrinsèquement qui permet que les DDOS soit possible.
C'est à dire que pour palier à un problème intrinsèque ( tout autant que le NAT) on a créé des usines à gaz, et on continue de le faire, en dépit du bon sens.
Et en plus je lis des argumentaires justifiant ce qui est injustifiable.
On a crée 65555 ports pour des services derrière, on les a standardisés.
Maintenant, on crée des outils pour les filtrer, ou encore le comble de l'intelligence, on change le port d'écoute, c'est tout aussi simple que le service ne tourne pas derrière. Non on continue à élaborer des usines à gaz.
Ce n'est pas incriminer MW, vous faites ce que vous pouvez avec vos connaissances à un instant donné. Le propos, est juste de vous faire remarquer, que c'est dénué de bon sens de faire cela, ensuite si les "attaques" se déplacent vers un autre port, vous faites quoi ? La course à l'échalote de la fermeture de ports ? C'est pas une solution.
Dans le fond, tu as bien raison, mais dans les faits on fait quoi ? On ne peut pas à nous tout seul redéfinir les standards et les pratiques réseau et internet !
Oui, un couteau est neutre, mais c'est interdit d'en porter un dans la rue au delà d'une certaine longueur, c'est interdit quelque soit la longueur dans une école, dans un avion…
C'est du bon sens, on fait quoi nous comme FAI ? On laisse l'attaque se passer et le réseau planter, ou on agit en prenant une mesure simple et sans réel impact sur les abonnés qui résout le problème ?
Est-ce idéal ? Absolument pas ! Mais on ne contrôle que ce qu'on peut contrôler. C'est bien pour ça que ça nous embête bien cette histoire, car on n'aime pas du tout avoir à se retrouver à bloquer un port, aussi insignifiant soit-il, c'est pas nos valeurs, mais quand la décision a été prise, c'était ça ou un réseau instable…
Le SSL et autres protocoles de sécurité et les DRMs sont dans ce sens une aberration aussi, ce sont des couches par dessus des couches, ils prennent des ressources dans le seul but de nous protéger contre des actions malveillantes (piratage, vol de donnée, etc…). Mais on en a besoin !
Après, ça fait 4 ans que ce port est bloqué… Aucune escalade ni attaque sur d'autres ports, donc pas vraiment de course à l'échalote en ce qui nous concerne.
On ne peut pas éviter la bêtise, la malveillance, et la société doit faire des choix qui affectent notre liberté…
Pour moi, la différence, c'est la transparence ou son absence : une entreprise ou un gouvernement qui va utiliser cela comme un prétexte pour faire plus que simplement protéger, pour prendre du pouvoir, restreindre et protéger des intérêts personnels crée clairement une dérive très dangereuse.
Mais une entreprise, un gouvernement (ou une association) qui va communiquer sur les mesures prises, avec un organe de contrôle (justice…) pour éviter les excès, c'est autre chose.
C'est la vie en société quoi… Équilibrer idéalisme (nécessaire) et réalisme/pragmatisme (inévitable sauf si on va dans le déni).
Bon, c'est de la philosophie au final cette histoire… On peut remercier le SIEA (qui est en panne d'ailleurs) pour cela ;D
-
Ensuite cela n'a aucun intérêt d'essayer de me justifier le bien fondé d'un quelconque hypothétique argumentaire sur le sujet.
Vous avez bien raison, tous ces gens ouverts d'esprit ça devient lassant à la longue.
-
Vous avez bien raison, tous ces gens ouverts d'esprit ça devient lassant à la longue.
Oui, je comprends pas du tout l'ironie de l'histoire.
Cela dit, ce n'est pas non plus, comme si je ne connaissais pas MW depuis quelques années.
-
Oui oui d'accord : Du coup je t'invite à monter le tien et tu comprendras pourquoi certaines décisions doivent être prises.
Ca tombe bien. Et t'etais même pas encore un spermatozoïde. Et quelque soit les décisions ont peu/doit être clair sur le sujet.
-
Tu sais quels sont les protocoles filtrés chez ton FAI et celui d'avant ? Juste pour savoir ? La réponse n'est pas "aucun" ;)
-
Bon, c'est de la philosophie au final cette histoire… On peut remercier le SIEA (qui est en panne d'ailleurs) pour cela ;D
Mais non !
1 - la communication et le contrat avec le FAI : ni fait, ni prévu.
2 - Est ce le rôle du SIEA sur l'offre activée ? Non. Et je pense que ni Kosc ni Orange s'amusent à filtrer la collecte livrée.
3 - Le SIEA peut parfaitement décrocher son téléphone et appeler le FAI et/ou couper simplement le port du client à pbs sur leur switch au titre de la sauvegarde du réseau. Ils ne savent pas faire de supervision correcte ? C'est un pb et la réponse n'est pas le filtrage généralisé.
4 - la mise en place d'un équipement de filtrage n'est pas neutre en terme de $$$ et d'impact, sans parler de son impact sur l'architecture vers laquelle tout le trafic se dirige. Imaginons qu'ils l'ont mis en coupure de la livraison FAI sur leur point de livraison de la collecte, bah ca change rien en terme d'occupation de trafic dans le réseau SIEA (puisque pour filtrer un paquet faut l'avoir reçu.)
-
Tu sais quels sont les protocoles filtrés chez ton FAI et celui d'avant ? Juste pour savoir ? La réponse n'est pas "aucun" ;)
oui c'est pour même pour ça que j'ai du me fendre d'une commande de tunnel chez Milkywan ;) Orange n'est pas non plus transparent sur le filtrage non débrayable du port 25 ou de protocole VPN. Que K-Net ait aussi bloqué des ports/protocoles en toute opacité c'est dans la lignée des mauvaises pratiques des FAI. En plus K-Net a laissé béant son problème de dégueuli WAN dont @belomo s'est fendu du diag...
La tentation est grande parce que c'est simple facile et le temps qu'on pert pas à solutionner on peut le prendre pour picoler avec les potes.
-
Mais non !
1 - la communication et le contrat avec le FAI : ni fait, ni prévu.
2 - Est ce le rôle du SIEA sur l'offre activée ? Non. Et je pense que ni Kosc ni Orange s'amusent à filtrer la collecte livrée.
3 - Le SIEA peut parfaitement décrocher son téléphone et appeler le FAI et/ou couper simplement le port du client à pbs sur leur switch au titre de la sauvegarde du réseau. Ils ne savent pas faire de supervision correcte ? C'est un pb et la réponse n'est pas le filtrage généralisé.
4 - la mise en place d'un équipement de filtrage n'est pas neutre en terme de $$$ et d'impact, sans parler de son impact sur l'architecture vers laquelle tout le trafic se dirige. Imaginons qu'ils l'ont mis en coupure de la livraison FAI sur leur point de livraison de la collecte, bah ca change rien en terme d'occupation de trafic dans le réseau SIEA (puisque pour filtrer un paquet faut l'avoir reçu.)
Attends, tu m’as mal compris (ou je me suis mal exprimé).
Je disais que le débat de fond : liberté vs sécurité est un sujet de philosophie, et je remerciait le SIEA (avec un sourire sarcastique hein) pour avoir initié (malgré eux) ce débat.
Je ne défend absolument pas la décision du SIEA (au contraire), dont ce n’est pas le rôle, point. On peut ajouter par dessus l’absence totale de communication aux OC sur cet état de fait. Ça place les OC/FAI dans des positions très délicates envers leurs abonnés, sans compter les possibles problèmes que tu mentionnes.
-
Orange n'est pas non plus transparent sur le filtrage non débrayable du port 25 ou de protocole VPN.
A quoi fais-tu référence concernant un filtrage de protocole VPN ?
-
Le débit est bridé sur les protocoles L2TP et GRE
-
Le débit est bridé sur les protocoles L2TP et GRE
En est-tu sûr? Je me souviens d'avoir obtenu le débit max de ma ligne (300 Mbit/s) en GRE over ipv6 il y a quelques mois.
C'était un tunnel temporaire, je ne l'utilise plus depuis. Par contre en ESP (IPsec) over ipv6, j'ai bien le débit max également.
Je n'ai pas de retour à faire sur L2TP, jamais utilisé sérieusement.
-
Oui absolument certain, mais ça ne touche pas 100% des clients Orange, selon le type de routeur de collecte sur lequel tu transites.
-
ok, noté, merci.
-
Oui absolument certain, mais ça ne touche pas 100% des clients Orange, selon le type de routeur de collecte sur lequel tu transites.
Merci pour la précision.
Cependant, j’essaie de suivre ce genre de sujet depuis un bon moment sans me souvenir en avoir déjà entendu parler avant, c'est un peu curieux.
En cherchant, j'ai trouvé ce post (https://lafibre.info/orange-debit/probleme-de-debit-sur-interfaces-tunnelles-type-ipip-ou-gre-ipv4-ipv6/msg716556/#msg716556) qui en parle (et dans lequel tu es intervenu), cependant le message en question laisse entendre que le problème n'est pas constaté avec certains cpe/sfp ce qui met hors de cause le réseau (Fyr me semble avoir la même interprétation (https://lafibre.info/orange-debit/probleme-de-debit-sur-interfaces-tunnelles-type-ipip-ou-gre-ipv4-ipv6/msg721340/#msg721340)).
-
En fait il y'a deux soucis, un dans la box (résolu en virant la box en effet) et un souci dans le réseau.
-
Cependant, j’essaie de suivre ce genre de sujet depuis un bon moment
Tu trouveras de nombreux sujets :
- https://lafibre.info/orange-debit/probleme-de-debit-sur-interfaces-tunnelles-type-ipip-ou-gre-ipv4-ipv6/
- https://lafibre.info/milkywan/tunnel-gre-probleme-debit-tres-bas/
- https://lafibre.info/vpn/limitation-debit-port-1723/
-
@Hugues
J'avoue avoir un peu de mal à concilier "le réseau est hors de cause" avec "souci dans le réseau".
@Vivien
Merci.
J'avais trouvé le 1er lien.
Le 2nd concerne free.
Quand au 3ème il me semble pointer vers des probables limitations box (dues aux ALG) plutôt que réseau (mais pas que cas v4 (https://lafibre.info/vpn/limitation-debit-port-1723/msg784509/#msg784509), cas v6 (https://lafibre.info/vpn/limitation-debit-port-1723/msg784511/#msg784511)).
J'ai du mal à envisager qu'il puisse y avoir ces limitations sur certains routeurs et pas sur d'autres, ça me semble assez improbable.
Pour essayer d'y voir plus clair, j'ai sollicité une connaissance chez Orange.
Pas de telle limitation connue (en fonction du port ou du protocole GRE/L2TP) dans les dslam/olt,
question posée côté routeur de collecte (raccordant directement les dslam/olt), pas de limitation connue.
également posée côté routeur cœur de réseau, pas de limitation connue.
C'est pas vraiment plus clair, comme dirait Mulder, la vérité est ailleurs.
-
@Hugues
J'avoue avoir un peu de mal à concilier "le réseau est hors de cause" avec "souci dans le réseau".
Je t’avoue que la « science » sur le sujet a pas mal évolué et que je ne repasse pas forcément pour mettre à jour mes messages, donc il est possible que certaines choses dites à l’époque s’avèrent fausses maintenant :)
-
Pour essayer d'y voir plus clair, j'ai sollicité une connaissance chez Orange.
Pas de telle limitation connue (en fonction du port ou du protocole GRE/L2TP) dans les dslam/olt,
question posée côté routeur de collecte (raccordant directement les dslam/olt), pas de limitation connue.
également posée côté routeur cœur de réseau, pas de limitation connue.
Des infos que j’ai eu chez orange, c’est bien lié a une limitation d’anciens routeurs de collecte en cours de remplacement, ce qui explique que toutes les plaques ne soient pas affectées, c’est un effet de bord lié a un traitement sur ces paquets donc pas de limite « voulue » en quelque sorte.
Difficile de rentrer dans les détails sans diffuser d’infos confidentielles après :/
-
Merci Hugues pour ces précisions.
Du coup, il n'est pas improbable qu'on puisse la contourner en utilisant PPPoE (sur vlan 835, mais on perd IPv6) plutôt que DHCP (sur vlan 832), puisque la collecte diffère un peu, je dirais que ça se tente.
-
Tu perds en MTU aussi, et en routage régionalisé… pas forcément un bon plan
-
Sauf erreur de ma part, la rfc 4638 (https://datatracker.ietf.org/doc/rfc4638/) est supportée.
-
Jamais essayé chez Orange...
-
Pour info, je suis passé au SIEA hier.
L'ACL est en fait une ACL de base des switchs Alcatel, une sorte de bundle de filtres qui sont normalement faits pour un réseau d'entreprise (d'où le blocage de bgp et de dns server)
Ils ont en lab une nouvelle version de l'ACL qui sera mise en prod sur tout le parc d'ici la fin d'année.
Le délai est long car cela doit se faire dans le cadre d'une maintenance planifiée.
Bref, rien de volontaire et ils peuvent désactiver l'ACL au cas par cas pour les clients qui seraient concernés par ce souci.
-
Ah oui, pour le port 111, non seulement la décision avait été prise en raison d'attaques DDOS, mais MW étant FAI, a le droit de prendre cette décision.
Après, oui, c'est une petite entorse à la neutralité annoncée sur la faq du site MW spécifiant qu'aucun port n'est bloqué et qu'on s'est retrouvé avec un port non courant bloqué en UDP... On ne l'avait même pas réalisé en fait.
Je suis bien d'accord que ce n'est ni important ni grave, et que le blocage de ce port apporte une sécurité et ne manque à aucun abonné.
Après, oui, on va je pense corriger cela d'une manière ou d'une autre, histoire d'être cohérent, mais ce n'est pas une urgence ni un problème de fond.
Et non Anonyme, ce n'est pas débile. Ce port quasi désuet pour son usage initial est utilisé à des fins malveillantes sur le WAN et cela posait des problèmes sérieux et concrets sur le réseau. Hugues ne s'amuse pas à prendre des décisions arbitraires, personne ne met en doute, j'espère, sa décision experte et justifiée.
Le port 111 a plus de sens sur un LAN que le WAN de toute façon...
Le problème est que si les ports sont associés à des services standards, ça n'interdit pas pour autant de les utiliser pour autre chose.
Et que du coup quand le blocage s'effectue coté opérateur (ou OI) , ben les problèmes deviennent difficile à diagnostiquer.
Le 111 est mnémotechnique, j'ai vu pas mal de gens l'utiliser en dehors du RPC. J'ai moi même été mordu un jour par un blocage du 445.
Le problème du DDOS c'est qu'on a sans arrêt de nouvelles source. Un coup c'est RPC, mais il y a eu aussi NTP, et à une époque on a eu aussi mal de SMB/Netbios.
Si demain on trouve une attaque par ampli sur Nginx, tu vas bloquer le 80 et le 443 ?
Bref, pour moi si blocage il y a il est idéalement dans la box et désactivable manuellement (Bouygues télécom fait ça par exemple de ce que j'en ai vu via le firewall intégré)
Et si dans le cas de MW il n'y a pas de box fournie et que ça devient nécessaire de le faire en cœur pour X ou Y raisons , alors il _faut_ une communication claire, immédiate et à tous les abonnés. Même si 99.9% s'en fiche, le choix d'un FAI tel que milkywan n'est pas anodin et c'est justement parce que les abonnés veulent faire autre chose que du Netflix et du web.
-
Y'a plus de blocage sur le 111 depuis, hein :)
-
Respecter les attributions des autorites du domaine, c'est bien aussi. On ne peut pas vraiment se plaindre d'ecueils a l'utilisation d'un port non prevu a cet usage.
-
Respecter les attributions des autorites du domaine, c'est bien aussi. On ne peut pas vraiment se plaindre d'ecueils a l'utilisation d'un port non prevu a cet usage.
Quelle est la différence entre le port 23, 53, 111 ou autre lorsque tu fais un bind sur AF-INET en C dessus ?
-
Quelle est la différence entre le port 23, 53, 111 ou autre lorsque tu fais un bind sur AF-INET en C dessus ?
D’un point de vue logiciel, aucun, mais je ne pense pas que pitalugue parlait de cela…
D’un point de vue réseau (interconnexion logiciels, machines, réseaux), des ports ont été définis, et je pense qu’il voulait dire qu’il est bien aussi d’utiliser les standards.
Dans la même logique, qu’elle est la différence entre une variable uint32 utilisée pour stocker l’âge du capitaine, une adresse IP, un numéro de téléphone, une adresse de pointeur au autre…
-
Bonjour,
Respecter les attributions des autorites du domaine, c'est bien aussi. On ne peut pas vraiment se plaindre d'ecueils a l'utilisation d'un port non prevu a cet usage.
D’un point de vue réseau (interconnexion logiciels, machines, réseaux), des ports ont été définis, et je pense qu’il voulait dire qu’il est bien aussi d’utiliser les standards.
alors, je l'ai peut être comprise pas comme il faudrait, mais la rfc 1700 (https://www.rfc-editor.org/rfc/rfc1700), je l'ai toujours comprise comme disant quel(s) étai(en)t le(s) port(s) par défaut utilisé(s) pour tel(s) service(s).
L'objectif étant d'éviter de devoir sonder à chaque fois les 65k d'un serveur pour savoir où donc l'admin a bien voulu mettre son service smtp, web, etc.
Sauf erreur de ma part, jamais elle n'interdit, explicitement ou non, de faire bien comme on veux, de mettre le protocole de notre choix dans le port qui nous conviens ou nous arrange.
Et c'est heureux, parce que d'un point de vue réseau, les routeurs n'en ont strictement rien a secouer la rib du bidule transporté dans tcp/443 (text/html, jpeg, json, zip, vidéos, audio, SSH, DNS, etc)
Ça ne change et ne doit absolument rien changer à la décision de routage prise selon l'entête L3.
-
Si vous ecrivez un service et que vous voulez que votre code soit operationnel sur autre chose que votre propre systeme, vous serez peut-etre amene a considerer que pour udp c'est le protocole 17, pas le 42...
Si vous ecrivez votre serveur dns et qu'il doit etre interoperable avec le reste du monde, il va bien falloir qu'il communique sur port 53.
Si un enregistrement dnssec est declare avec l'algorithme 13, on s'attend a ECDSA, pas RSA.
Donc vous pouvez toujours programmer et parametrer tout ce que vous voulez mais si vous voulez vous inscrire dans un cadre global d'interoperabilite il vous faudra suivre ce que l' Internet Assigned Numbers Authority publie. https://www.iana.org/protocols
Dans le cas d'espece, rien n'est contraint Cf RFC 6335. Mais, de maniere globale, "si ca ne marche pas c'est pour votre pomme, pas regi par le standard" (SHOULD NOT)
Inversement, il n'y a aucune juridiction mondiale qui veille au libre usage de n'importe quel protocole sur n'importe quel port.
Si vous ne respectez pas les pratiques et tombez sur un ecueil, tant pis pour vous, c'est le sens de ma remarque.
Vous pouvez toujours tenter d'exiger une liberte de comportement, mais elle sera locale, non garantie, et probablement non perenne.
La seule force de ce type de standard c'est l'organisation de son adoption et il n'y a pas d'alternative.
-
Par contre, le port par défaut de proxmox c'est 8006. Celui d'unifi c'est 8443. Et ça gêne personne.
Tu le dis toi-même:
Si vous ecrivez un service et que vous voulez que votre code soit operationnel sur autre chose que votre propre systeme, vous serez peut-etre amene a considerer que pour udp c'est le protocole 17, pas le 42...
Si vous ecrivez votre serveur dns et qu'il doit etre interoperable avec le reste du monde, il va bien falloir qu'il communique sur port 53.
Si un enregistrement dnssec est declare avec l'algorithme 13, on s'attend a ECDSA, pas RSA.
Donc vous pouvez toujours programmer et parametrer tout ce que vous voulez mais si vous voulez vous inscrire dans un cadre global d'interoperabilite il vous faudra suivre ce que l' Internet Assigned Numbers Authority publie. https://www.iana.org/protocols
Perso mon serveur SSH est sur un autre port que le 22, et j'ai pas l'intention que ce soit "interopérable avec le reste du monde". Mais j'attends tout de même de mon FAI qu'il le transporte de bout en bout sur le port que j'ai choisi (ou alors à minima documenter le blocage et en donner la raison).
Je suis pas le seul.
Par contre, je suis pas d'accord avec ça:
Dans le cas d'espece, rien n'est contraint Cf RFC 6335. Mais, de maniere globale, "si ca ne marche pas c'est pour votre pomme, pas regi par le standard" (SHOULD NOT)
Inversement, il n'y a aucune juridiction mondiale qui veille au libre usage de n'importe quel protocole sur n'importe quel port.
Si vous ne respectez pas les pratiques et tombez sur un écueil, tant pis pour vous, c'est le sens de ma remarque.
Vous pouvez toujours tenter d'exiger une liberte de comportement, mais elle sera locale, non garantie, et probablement non perenne.
Ce n'est pas au FAI de décider quel port vaut mieux que tel autre, quel protocole est filtré et tel autre non et induire ainsi des "pannes" sous prétexte qu'il n'y a pas d'obligation de transport car une RFC a marqué "SHOULD" et pas "MUST".
Pourquoi ne pas filter tout ce qui n'est pas UDP/TCP dans ce cas, sous prétexte que le reste n'est pas utilisé et donc inutile ?
J'aimerais bien l'avis de Vivien sur le sujet, mais justement pour moi ce genre de chose tends à freiner l'innovation et interdire les nouveaux usages. L'exemple que j'ai en tête c'est SCTP ou RSVP .
-
Si vous ecrivez un service et que vous voulez que votre code soit operationnel sur autre chose que votre propre systeme, vous serez peut-etre amene a considerer que pour udp c'est le protocole 17, pas le 42...
Si vous ecrivez votre serveur dns et qu'il doit etre interoperable avec le reste du monde, il va bien falloir qu'il communique sur port 53.
Si un enregistrement dnssec est declare avec l'algorithme 13, on s'attend a ECDSA, pas RSA.
Donc vous pouvez toujours programmer et parametrer tout ce que vous voulez mais si vous voulez vous inscrire dans un cadre global d'interoperabilite il vous faudra suivre ce que l' Internet Assigned Numbers Authority publie. https://www.iana.org/protocols
Dans le cas d'espece, rien n'est contraint Cf RFC 6335. Mais, de maniere globale, "si ca ne marche pas c'est pour votre pomme, pas regi par le standard" (SHOULD NOT)
Inversement, il n'y a aucune juridiction mondiale qui veille au libre usage de n'importe quel protocole sur n'importe quel port.
Si vous ne respectez pas les pratiques et tombez sur un ecueil, tant pis pour vous, c'est le sens de ma remarque.
Vous pouvez toujours tenter d'exiger une liberte de comportement, mais elle sera locale, non garantie, et probablement non perenne.
La seule force de ce type de standard c'est l'organisation de son adoption et il n'y a pas d'alternative.
Merci d'avoir précisé le sens de la remarque, parce qu'un instant on pouvait comprendre qu'il n'était pas illégitime que le réseau drop un protocole L4+ parce qu'utilisé à d'autres finalités que celles initialement prévue et normalisées.
Et pour revenir au contexte initial (blocage port 53 puis 111), dans tout les cas (sauf évidement auto préservation), ce n'est pas au réseau de décider de transporter ou non, tel ou tel protocole L4+.
Tout ce qu'on attend de lui c'est qu'il transporte L3 dans la mesure où les paquets sont correctement formatés en L3 et respectent les standards d’interopérabilité.
Si il a des soucis d'interopérabilité des couches supérieures, et bien c'est certes un problème, mais il est à traiter aux extrémités, pas dans le réseau.
-
Et c'est bien pour ça que ni le port 53, ni le port 111 ne sont bloqués :)
Dès que le blocage du port 53 par le SIEA a été signalé/repéré, Hugues a immédiatement réagi auprès d'eux.
Concernant le port 111, il a été bloqué lors d'une attaque aggressive utilisant ce port, mais cela n'ayant plus besoin d'être, il n'est plus bloqué.
Aucun port n'est bloqué ou limité chez MW. Ça n'a aucun intérêt pour nous de bloquer, au contraire.
La seule exception pouvant être pendant une campagne d'attaque impactant nos abonnés ou notre infra, si et seulement si le blocage est nécessaire et n'impacte pas plus qu'il ne protège.
Mais cette exception ne serait que temporaire, et certainement pas un premier recours.
Dans l'histoire de MilkyWan,, il n'y a eu que ce port 111 de bloqué, et pour une période seulement (et révolue). Il est à noter que cela n'a d'ailleurs impacté aucun abonné, mais ça n'aurait pas été une raison pour le laisser bloqué (on est bien d'accord).
-
Chez MW ce n’est pas le blocage de ports le plus gênant.
Pour ma part c’était le filtrage « bogons » et le routage de 10.10.10.10 qui partait je ne sais où, mais pas où je voulais à l’époque. Je ne sais pas si c’est toujours d’actualité, mais comme ce sont des bénévoles, je n’ai jamais trop insisté.
-
Le range 10.0.0.0/8 est utilisé comme range d'interco pour les tunnels et les VM chez nous, oui.
Ça ne veut pas dire qu'il est routé sur internet et encore moins annoncé.
Rien de gênant en soi, tu n'es pas supposé envoyer des paquets à destination d'IP privées sur ta route par défaut :)
-
Voilà :)
Et sur la route par défaut, au-delà de ne pas être gênant, c'est même normal et attendu qu'une adresse privée ne soit ni annoncée ni routée en fait (ou que si une telle adresse venait à être routée, elle ne soit pas annoncée publiquement).
Pour le matériel de l'infra ou les VM, oui, mais justement c'est ni via la route par défaut, ni annoncé. Les abonnés qui ont des tunnels ou des VM connaissent leurs IP privées et leur routes d'interconnexion pour y accéder.
Privé et public, c'est bien à prendre au sens propre ;)
Le caractère privé du contenu et des accès de nos abonnés est très important pour nous, bénévoles ou pas :)
-
J'ai souvenir d'avoir un /28 et que ma route default pointait sur une IP publique du /28.
Et de mémoire, c'est un tunnel que j'essayais de construire entre une de ces IP publique et une autre publique pour y faire passer un 10.10.10.0/24 et que cela se perdait quelque part, mais pas ou il faut ;D ( cela n'a plus d'importance)
Pour le DNS, cela me rappelle un problème que je t'avais remonté, sur un reverse, je n'avais rien touché et c'est tombé en panne, je ne suis pas certain que ce soit lié ( je ne suis pas sur le SIEA ).
Et cela ne provenais pas de chez moi, j'ai remonté le même sur d'autres adresses, et ce serveur DNS se porte comme un charme.
-
Mais…
Si tu avait un tunnel en 10.10.10.0/24 (ou plus large), et que tes paquets se perdaient dans la route publique par défaut, c’est que ton routeur ne routait pas le 10.10.10.0/24 vers le tunnel, mais vers la route par défaut, non ?
Bon histoire ancienne, on ne va pas insister ;D