Question Une personne utilisant le même serveur DNS que moi peut-elle pirater mes domaines?


Lorsque j'enregistre un nouveau domaine, je l'envoie à mon fournisseur d'hébergement en lui attribuant ses serveurs de noms de domaine dans les paramètres du registraire. Par exemple, avec Digital Ocean, j’ai saisi les informations suivantes:

ns1.digitalocean.com
ns2.digitalocean.com
ns3.digitalocean.com

J'ajoute ensuite les paramètres de domaine dans l'enregistrement A de mon serveur. Je viens de penser que quiconque sur le même fournisseur d'hébergement peut ajouter un enregistrement A avec un domaine que je possède.

Y at-il quelque chose empêchant cela de se produire? Si 2 serveurs différents utilisant le même serveur de noms de domaine tentent de se attribuer un domaine par le biais des enregistrements A, où le domaine sera-t-il résolu lorsque vous l'introduisez dans le navigateur? qu'est-ce qui empêche les collisions de noms de domaine sur le même serveur DNS?


42
2017-12-19 06:25


origine


Digital Ocean l’empêche, d’une part. Juste essayer entrer un enregistrement A pour un domaine vous ne pas posséder. - Michael Hampton♦
La question est de savoir comment savent-ils à qui appartient le domaine? est-ce premier arrivé, premier servi? ainsi, quiconque ajoute l’enregistrement A en premier peut utiliser le domaine? - Eran Galperin
@EranGalperin Bonjour! Je suis un employé de DigitalOcean. La première personne à ajouter un domaine à son compte peut définir des enregistrements pour celui-ci, mais nous disposons d'une procédure pour établir la propriété en cas de conflit. - Jacob
@ Jacob Merci! C'est bon à savoir - Eran Galperin
Les problèmes de ce type expliquent pourquoi les plus gros fournisseurs de DNS (comme Network Solutions) sont également des registraires DNS. Ils peuvent gérer les deux étapes à la fois et s'assurer que tout est synchronisé. - Barmar


Réponses:


Ne vous occupez jamais de la section commentaires ci-dessous, et ne vous occupez jamais des réponses précédentes dans l'historique des modifications. Après environ une heure de conversation avec des amis (merci @joeQwerty, @Iain et @JourneymanGeek), et quelques remarques joviales, nous sommes allés au fond de votre question et de la situation dans son ensemble. Désolé pour la brusquerie et mal comprendre la situation complètement au début.

Passons en revue le processus:

  1. Tu achètes wesleyisaderp.com à, disons, NameCheap.com.
  2. Namecheap en tant que votre registraire sera l'endroit où vous peuplerez vos enregistrements NS. Supposons que vous souhaitiez réellement héberger la zone DNS sur Digital Ocean.
  3. Vous pointez les enregistrements NS de votre nouveau domaine brillant vers ns1.digitalocean.com et ns2.digitalocean.com.
  4. Cependant, supposons que j'ai pu déterminer que vous aviez enregistré ce domaine, et en outre que vous avez changé vos disques NS en Digital Ocean. Ensuite, je vous ai battu sur un compte Digital Ocean et j'ai ajouté la zone wesleyisaderp.com à la mienne.
  5. Vous essayez d'ajouter la zone dans *votre* compte, mais Digital Ocean dit que la zone existe déjà dans leur système! Oh non!
  6. Je nomme wesleyisaderp.com à wesleyisbetterthanyou.com.
  7. L'hilarité s'ensuit.

Certains amis et moi avons joué ce scénario avec exactitude, et oui, cela fonctionne. Si @JoeQwerty achète un domaine et le pointe vers les serveurs de noms Digital Ocean, mais que cette zone a déjà été ajoutée à mon compte, je suis le maître de la zone et je peux en faire ce que je veux.

Cependant, considérez que quelqu'un doit d'abord ajouter la zone à son compte DNS, puis vous devez pointer vos enregistrements NS vers les serveurs de noms du même hôte pour que tout ce qui ne va pas se passer. De plus, en tant que propriétaire du domaine, vous pouvez changer les enregistrements NS à tout moment et éloigner la résolution de l'hôte de la zone incorrecte.

La probabilité que cela se produise est un peu faible pour le moins. Il est dit que, statistiquement, vous pouvez mélanger un jeu de 52 cartes à jouer et obtenir un ordre qu'aucun autre humain n'a jamais eu, et aucun autre humain ne le fera jamais. Je pense que le même raisonnement existe ici. La probabilité que quelqu'un exploite cela est si faible et il existe de meilleurs raccourcis, que cela ne se produira probablement pas dans la nature.

De plus, si vous possédez un domaine chez un registraire et que quelqu'un entre en collision avec une zone telle qu'un fournisseur tel que Digital Ocean, je suis sûr que si vous fournissez une preuve de propriété, ils demanderaient à la personne qui a créé le fichier. zone dans leur compte pour le supprimer car il n'y a aucune raison pour qu'il existe car ils ne sont pas le propriétaire du nom de domaine.

Mais qu'en est-il des enregistrements

La première personne à avoir une zone, par exemple Digital Ocean, sera celle qui la contrôle. Vous ne pouvez pas avoir plusieurs zones identiques sur la même infrastructure DNS. Ainsi, par exemple, en utilisant les noms idiots ci-dessus, si wesleyisaderp.com est une zone de Digital Ocean, personne d'autre sur l'infrastructure DNS de Digital Ocean ne pourra l'ajouter à son compte.

Voici la partie amusante: j’ai vraiment ajouté wesleyisaderp.com à mon compte Digital Ocean! Allez-y et essayez de l'ajouter à la vôtre. Cela ne fera aucun mal.

Par conséquent, vous ne pouvez pas ajouter un enregistrement A à wesleyisaderp.com. C'est tout a moi.

Mais qu'en est-il ...

Comme l'a souligné @Iain ci-dessous, le point 4 ci-dessus est en réalité trop détaillé. Je n'ai pas à attendre ou complot ou régime du tout. Je peux juste faire milliers des zones d'un compte, puis asseyez-vous et attendez. Techniquement. Si je crée des milliers de domaines et que j'attends qu'ils soient enregistrés, j'espère qu'ils utiliseront les hôtes DNS sur lesquels j'ai défini mes zones ... peut-être que je peux faire quelque chose de mal? Peut être? Mais probablement pas?

Toutes mes excuses à Digital Ocean & NameCheap

Notez que Digital Ocean et NameCheap ne sont pas uniques et n'ont aucun rapport avec ce scénario. C'est un comportement normal. Ils sont irréprochables sur tous les fronts. Je viens de les utiliser car c'était l'exemple donné, et ce sont des marques très connues.


57
2017-12-19 06:31



Je suppose que si vous voulez vraiment jouer avec quelqu'un, vous pouvez le configurer, par exemple. un A et un MX RR avec de très longues TTL, pointant vers un hôte que vous contrôlez et martelez des serveurs DNS publics communs (comme ceux de Google, peut-être?). Une variante de l'empoisonnement du cache ... - α CVn
Il est également facile de montrer la propriété du domaine en modifiant les serveurs sur lesquels on pointe le serveur. Ainsi, même si quelqu'un le faisait, il pourrait être éclairci assez rapidement si son service à la clientèle est efficace. - JamesRyan
Les enregistrements @JamesRyan TXT sont utilisés pour prouver la propriété dans des cas comme celui-ci. - Iain
@ Wesley C'est correct. Nous avons une procédure en place pour gérer les cas de conflits de zones avec notre service DNS. - Jacob
Une situation étrange où cela pourrait être plus probable est où le domaine était précédemment enregistré et utilisé à Digital Ocean, puis caduc / n’a pas été renouvelé, mais la zone n’a pas été supprimée de digitalocean. Quelqu'un l'utilise ensuite comme un «nouveau» domaine (ignorant qu'il appartenait auparavant), puis tente de créer la zone dans Digital Ocean. Cela ne pourrait être évité que si l'hôte DNS purge périodiquement les zones pour lesquelles il n'est plus le serveur de noms. (sans les méthodes de résolution de conflit susmentionnées) - Ashley Steel


En plus de l'excellente réponse de Wesley, j'aimerais ajouter qu'il existe déjà une solution pour empêcher cela. Cela s'appelle DNSSEC.

Les bases sont les suivantes:

  • Vous enregistrez votre domaine (je vais aller avec le nom éminent wesleyisaderp.com ici, juste parce que.)
  • Vous enregistrez vos serveurs de noms auprès de votre registraire, généralement via une interface Web à laquelle vous vous authentifiez avec un combo nom d'utilisateur / mot de passe.
  • Vous créez également une paire de clés publique / privée et vous téléchargez votre clé publique sur votre registraire sous la forme d'un enregistrement DNSKEY. (C’est ainsi que le registraire peut configurer la chaîne de confiance sur les serveurs racine pour le domaine de niveau supérieur - dans ce cas, les serveurs racine pour .com.) Encore une fois, vous transférez ceci lorsque vous êtes connecté avec votre propre combo nom d'utilisateur / mot de passe, de sorte qu'il est connecté à votre (vos) domaine (s) et non à quelqu'un d'autre.
  • Vous allez sur le serveur de noms, vous entrez vos enregistrements et vous signez le fichier de zone obtenu avec votre clé privée. Ou, si vous avez une interface Web avec votre service d'hébergement DNS, vous téléchargez la clé privée sur eux afin qu'ils puissent signer le fichier de zone.
  • Lorsque Wesley essaie si brutalement de détourner votre domaine et de le nommer à CNAME wesleyisbetterthanyou.com, ses enregistrements ne seront pas acceptés par les serveurs de domaine racine .com car ils ne sont pas signés avec la bonne clé. Si votre fournisseur d’hébergement DNS est malin, il le vérifiera immédiatement et ne lui permettra même pas d’ajouter des enregistrements à ce domaine à moins de disposer de la bonne clé privée.
  • Lorsque vous entrez vos propres dossiers, ils sont signés par la bonne touche, ils vont donc fonctionner.
  • Vous pouvez maintenant vous asseoir et rire de Wesley.

(Dans le cas d'origine, celui décrit par Wesley, l'erreur principale serait que Digital Ocean n'ait pas vérifié la propriété d'un domaine avant de permettre à quelqu'un de configurer des enregistrements DNS pour ce domaine. Malheureusement, ils ne sont pas les seuls dans ce domaine. Je sais d'au moins un registraire suédois avec les mêmes problèmes.)


31
2017-12-19 09:31



Curieux, comment un fournisseur d’hébergement de zone DNS autre que DNSSEC pourrait-il vérifier la propriété avant de permettre la création d’une zone? J'ai également essayé d'utiliser Amazon Route53 et je peux créer la zone de mon choix. - Wesley
Ils ne le feront probablement pas, il faudrait une vérification différée des essais et des erreurs. Juste deviner, supprimer-sur-erreur pourrait toujours être possible avec certaines astuces ux (écran de fumée). - Sampo Sarrala
@ Wesley, je n'ai pas envisagé les mécanismes. Mais à tout le moins, une sorte de vérification du record Whois, ou le même type de vérification que les vendeurs de certificats SSL bon marché fonctionneraient. S'ils peuvent le faire, pourquoi ne pas les sociétés d'hébergement? - Jenny D
@JennyD Commodité, surtout! Ce type de piratage de domaine est suffisamment rare et suffisamment détectable pour qu'il soit plus facile de le réparer quand il se produit que de faire en sorte que chaque utilisateur légitime franchisse des obstacles pour le prévenir. - duskwuff
@duskwuff Quand commodité et conflit de sécurité l'emporte généralement sur la commodité ... Je conviens que le détournement de domaine risque d'être rare - mais qu'en est-il des erreurs simples, sans intention perverse? IMAO, il est téméraire des hébergeurs DNS de ne faire aucune forme de vérification. - Jenny D


Tout ira bien tant que vous revendiquez la propriété du domaine chez DigitalOcean (c'est-à-dire que vous l'associez à votre compte) avant de dire au bureau d'enregistrement d'utiliser ses serveurs de noms.

Si quelqu'un a déjà associé votre domaine à son compte, vous le saurez avant que les serveurs de noms DigitalOcean fassent autorité. Et si cela se produit, discutez avec DigitalOcean de la possibilité de supprimer cette personne de son compte.

Conformément aux meilleures pratiques, {ns1, ns2, ns3} .DigitalOcean.com ne fait pas office de résolveurs récursifs pour les domaines hébergés ailleurs. S'ils le faisaient et si les serveurs hébergés par DigitalOcean les utilisaient comme résolveurs à usage général, le problème serait beaucoup plus grave. Bien que cela soit réputé être une mauvaise pratique, il n’est probablement pas si difficile de trouver des fournisseurs d’hébergement qui se trompent, ce qui ouvre la voie à des abus.


5
2017-12-19 10:07



Ainsi, si DigitalOcean ne fait pas encore autorité pour le domaine et que plusieurs clients potentiels prétendent être propriétaires du domaine, comment DigitalOcean saurait-il quel client potentiel dit la vérité? Vont-ils donner le premier accès pour créer des enregistrements et une date limite pour mettre à jour les enregistrements NS afin de prouver le contrôle du domaine? Ou vont-ils donner à chacun des clients potentiels un sous-ensemble différent de serveurs faisant autorité à mettre dans les enregistrements NS? - kasperd
@kasperd les propriétaires légitimes pointent les enregistrements NS où ils le souhaitent, puis configurent par exemple un enregistrement TXT qui prouve qu'ils sont les propriétaires, car il contient des informations uniques fournies par le fournisseur de services. Certes un peu palabre, mais dans les rares cas où cela pourrait se produire, il est un peu plus facile que de faire prouver son appartenance par tout le monde avant de les amener à bord. - Iain
@kasperd Souvent, l'enregistrement whois identifie le propriétaire légitime, bien que certaines personnes aient parfois des raisons de masquer cette information. Dans tous les cas, si vous dites à DO d'associer le domaine à votre compte afin de lui donner autorité, NE donnez probablement à l'imposteur qu'un calendrier pour mettre à jour le bureau d'enregistrement ou renoncer à l'association de domaine chez DO. Le propriétaire légitime devra peut-être attendre un peu, c'est tout. - mc0e


Je pense que ce problème signifie que personne ne devrait utiliser de tels serveurs de noms (tels que celui de Digital Ocean) comme résolveurs, car tout le monde peut créer un serveur de noms pour un domaine existant. La bataille pour le contrôle du domaine est sans importance car la propriété du domaine peut être prouvée facilement, mais le fait que quelqu'un puisse par exemple diriger n'importe quel domaine existant qui n'est PAS déjà hébergé sur Digital Ocean vers n'importe où.

En bout de ligne: ne faites pas confiance aux serveurs DNS de tout service d'hébergement ne nécessitant pas de preuve de la propriété du domaine (cela peut se faire facilement et rapidement, par exemple, à l'aide de la méthode suggérée ci-dessus: en ajoutant d'abord un enregistrement TXT avec une certaine valeur sur le domaine , c’est ce que Microsoft O365 et Google font par exemple).


0
2017-12-16 21:10