Auteur Sujet: DNS filtré sur le réseau SIEA ? (Lu 11141 fois)

Hugues · « **Réponse #60 le:** 24 septembre 2022 à 14:54:27 »

Tu perds en MTU aussi, et en routage régionalisé… pas forcément un bon plan

matrix-bx · « **Réponse #61 le:** 24 septembre 2022 à 15:19:15 »

Sauf erreur de ma part, la rfc 4638 est supportée.

Hugues · « **Réponse #62 le:** 24 septembre 2022 à 15:31:41 »

Jamais essayé chez Orange...

Hugues · « **Réponse #63 le:** 06 octobre 2022 à 22:37:17 »

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.

obinou · « **Réponse #64 le:** 22 octobre 2022 à 16:47:29 »

Citation de: bolemo le 21 septembre 2022 à 13:53:18

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.

Hugues · « **Réponse #65 le:** 22 octobre 2022 à 17:21:50 »

Y'a plus de blocage sur le 111 depuis, hein

pitalugue · « **Réponse #66 le:** 22 octobre 2022 à 20:19:23 »

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.

Anonyme · « **Réponse #67 le:** 22 octobre 2022 à 20:30:49 »

Citation de: pitalugue le 22 octobre 2022 à 20:19:23

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 ?

bolemo · « **Réponse #68 le:** 23 octobre 2022 à 00:07:27 »

Citation de: Anonyme le 22 octobre 2022 à 20:30:49

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…

matrix-bx · « **Réponse #69 le:** 23 octobre 2022 à 06:51:41 »

Bonjour,

Citation de: pitalugue le 22 octobre 2022 à 20:19:23

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.

Citation de: bolemo le 23 octobre 2022 à 00:07:27

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, 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.

pitalugue · « **Réponse #70 le:** 23 octobre 2022 à 10:59:55 »

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.

obinou · « **Réponse #71 le:** 23 octobre 2022 à 11:25:34 »

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:

Citation de: pitalugue le 23 octobre 2022 à 10:59:55

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:

Citer

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 .