J’ai procédé à la migration vers le nouveau service DNS de jeedom et même s’il est techniquement fonctionnel, il vient de me casser la possibilité d’interagir avec mon logement quand je suis au travail.
Je suis passé d’un domaine jeedom.com a un domaine eu.jeedom.link et malheureusement il semblerait que ce nom de domaine un peu exotique (normalisé, bien sur, mais exotique) est bloqué par les services qui sécurisent le réseau interne.
Evidemment j’ai remonté le problème dans mon boulot, mais c’est un grand groupe, ils n’en ont rien à faire de jeedom et de ces problématiques. Et les règles ne sont mêmes pas éditées en interne mais générées à la volée via des outils tiers, donc il est très probable que ce domaine soit interdit au dela même que du cadre de mon travail.
Je vous partagerai plus d’info si j’en ai, ce qui bloque exactement. Est ce qu’il avait été évoqué lors du déploiement de ce service de passer par des URLs plus communes (dont jeedom.com) ? Ou c’est mort ?
Surprenant, surtout de la part d’un grand groupe. Moi, il est exclus que je puisse connecter un appareil perso, donc non sécurisé selon les règles internes, au réseau du boulot.
Tu peux comme moi avoir un téléphone d’entreprise avec Android for Work pour le profil pro et le reste pour ton utilisation perso.
Mais tu peux aussi par le même principe accepter des smartphones persos: BYOD: bring your own device. Ou si le smartphone fournit la sécurisation nécessaire (chiffrement, pas de root, …) dans ce cas dans l’enclave sécurisée tu as ton profil pro).
Evidemment quel que soit le cas les règles sont celles de ton entreprise en terme d’administrateur du téléphone, déverrouillage, …
Voir avec ton service IT au boulot peut être ?
Je n’utilise pas ce service, mais si tu as la possibilité d’avoir autre chose qu’un .link peut être faire un autre test avec une autre extension…
C’est ce que j’ai dit, j’ai remonté l’info, mais jamais personne n’autorisera cette URL.
Déjà parce que les règles sont déléguées, les sites et pattern d’URL viennent de grands groupes de sécurité, et d’autres part parce que quand tu administres des parcs de 100k machines et plus, tu ne fais pas de cas particulier.
Donc tout ce que je peux dire pour l’instant c’est que jeedom.com est considéré comme une URL sûre, jeedom.link non. Et c’est pas que pour mon travail, puisque ce sont des outils type mcafee, cisco umbrella et compagnie.
D’acc, dans ce cas cela peut être une erreur stratégique de Jeedom vu l’envergure…
Ce serait intéressant d’avoir d’autres retour.
A mon échelle, le simple fait de mettre un port “exotique” style https://adresse.com:43567 dans une url http (meme https avec certificat SSL ok, etc) est inateignable depuis ma boite.
Sauf quelques fois, mais je suppose que c’est lorsque le firewall interne fait des siennes…
Jeedom ne propose que du .link pour son service de DNS ?
Connaissant le problème et les méthodes de sécurisation, il suffira peut être juste d’attendre, le fait que le nom de domaine soit récent fait qu’il n’est pas encore catégorisé, une fois fait automatiquement, il sera autorisé.
Je dis pas que c’est forcément ça mais de fortes chances.
Pour l’instant c’est la seule réponse que j’ai pu recevoir. J’ai demandé plus d’information sur quels services sécurisent les adresses accessibles ou non.
Je pense que le choix de l’URL mènera de toutes façons à le conclusion qu’elle est inutilisable en milieu professionnel.
Oui, le sens de la réponse est surtout qu’ils ne veulent pas de services privés utilisés sur la machine pro, ce qui est la politique « officielle » de 100% des services IT des boites à notre époque…
Il faut considérer que si c’était faisable avant, visiblement ils (ton service) étaient passés aux travers
non en fait c’est pas si simple que ça. Un tas de services grand public sont laissés accessibles. Si le site de jeedom s’y trouve, c’est qu’il est sur un pattern à liste noire.
Je comprends l’anglais hein, c’est pour ça que j’ai demandé plus d’info, savoir quel prestataire fournit cette règle de blocage, et pour quelle raison.
On est pas du tout ici sur une gestion en whitelist et heureusement, sinon je ne pourrai pas bosser de la journée.
Pas de raison pour une société de bloquer des sites pour le plaisir, sauf cause s’approchant de près ou de loin à la légalité… Au pire ils sont déchiffrés pour analyser les échanges et détecter les menaces.
D’ailleurs un TLD n’a pas de raison d’être plus ou moins bloqué parce qu’il est « exotique ». Dans tous les cas c’est la même chose, le serveur DNS gérant le top est consulté et ainsi de suite jusqu’au host, rien ne change que ce soit un .com , un .link un .paris ou que sais-je. Et je vois mal les DNS Root se faire blaclikster…
La seule chose qui fait qu’un site puisse être bloqué dans une société est que sa catégorisation ait été blacklistée, que le domaine ou le fqdn ait été délibérément blacklisté (blacklist manuelle) ou encore que la réputation de la machine cible (ip ou fqdn) est mauvaise (via dns filtering ou filtrage IP classique via des bases de réputation). Si derrière tu as de l’Umbrella, c’est porté par Cisco et notamment la base Talos.
Historiquement, il semblerait que Jeedom et ses sous-domaines liés aux services dns étaient tagués comme « Business et Industrie » (https://talosintelligence.com/reputation_center/lookup?search=dslkj45.dns6.jeedom.com).
Aujourd’hui, avec le .link, le domaine n’est pas encore catégorisé ( https://talosintelligence.com/reputation_center/lookup?search=dslkj45.eu.jeedom.link ). Il se peut donc que ta société bloque tout simplement les sites non catégorisés par mesure de sécurité, et que la team sécu whitelist manuellement les faux positifs non catégorisés qui sont nécessaires dans le cadre du secteur d’activité, mais c’est très rare car en général ingérable…
Une simple solution consisterait à ouvrir une demande de catégorisation chez Talos et tout devrait revenir à la normale. La plupart des autres éditeurs sécu suivront ensuite probablement tout seul (Zscaler, Bluecoat, Fortiguard etc etc).
Ah, bonne proposition, c’est vrai que je n’avais pas vérifié moi même la catégorisation du site, j’ai demandé à la personne (qui a zappé la demande avec fin de non recevoir donc …) de le faire pour moi.
Il me semble qu’il faut être client Cisco pour ce type de demandes.
C’est bon, j’ai ouvert un ticket pour catégoriser correctement le domaine jeedom.link et eu.jeedom.link.
J’ai proposé les catégories « DiY Projects,Business and Industry,Computers and Internet ».
A voir maintenant s’ils acceptent le traitement mais en tout cas c’est fait et logiquement ça devrait débloquer la situation.
