protocoles P2P de DHT

Distributed hash table et annuaires distribués

Le problème exposé dans ce sujet a été résolu.

Bonjour,

Dans le cadre de mes études je réalise un programme nécessitant la mise en place d'un annuaire distribué de serveurs. Pour cela j'ai pris connaissance de l'existence de protocoles dit de DHT permettant le stockage de données sur des noeuds. Par exemple l'implementation Kademlia me permettrait de réaliser mon annuaire distribué (et plus même puisqu'il est question de stocker des données, mais osef).

Dans le cadre de ce protocole, un identifiant unique est utilisé par noeud, pour être capable de s'identifier auprès des autres noeuds (un noeud étant une ip, un port et ce fameux nodeId).

Dans l'implémentation kademlia (que j'espère quelqu'un ici connaît, auxquel cas personne ne répondra jamais au présent topic), le nodeId est un sha-1 aléatoire, de 160 bits donc.

Ma question est la suivante : comment stocker cet ID sur la machine de l'utilisateur ? Cet id est une donnée sensible, si l'utilisateur la modifie, il peut se faire passer pour quelqu'un d'autre, qu'il n'est pas.

D'une façon ou d'une autre, le bon fonctionnement du système passe par le fait que les identifiants restent les mêmes pour chaque noeud.

Est-ce que je me pose les bonnes questions ? ou est-ce que le fait que cet id puisse être modifié par l'utilisateur ne soit pas un problème en soi ?

Merci d'avance pour vos réponses :)

+0 -0

Je ne connais pas vraiment kademlia, mais j'ai eu l'occasion d'étudier plusieurs systèmes de DHT et si je ne me trompe pas, le fait que l'utilisateur puisse modifier son id n'est problématique que s'il veut vraiment attaquer la DHT.

Je ne sais pas si c'est le cas de kademlia, mais il y a souvent un système de réplication qui permet aux données de ne pas être perdus en cas de crash d'un serveur. Si l'utilisateur modifie de temps en temps son id, cela va être équivalent à la disparition d'un serveur (un peu comme un crash) et l'apparition d'un nouveau serveur. Rien de bien méchant.

En revanche, si l'utilisateur veut attaquer la DHT, il pourrait s'arranger pour créer un certain nombre de serveurs de manière à être en contrôle de tous les serveurs gérant une certaine donnée et de les crasher en même temps pour faire disparaître cette donnée. Pour luter contre ce genre d'attaque, il me semble qu'il est possible de restreindre la quantité d'id valides qu'un utilisateur peut avoir : par exemple, son id pourrait être le hash de son ip+port. Ou encore le hash de son ip+port avec le port restreint dans une certaine range.

En fait, un réseau distribué tel qu'un DHT hébergé par des clients auxquels on ne peut pas faire confiance ne peut fonctionner que si une assez grande partie de ces utilisateurs agissent normalement. Et seul les contraintes physiques/monétaires des attaquants font qu'il est peu probable qu'un DHT assez étendu résistera bien aux attaques.

+0 -0

Pour l'utilisation d'un hash de l'ip+port en guise d'id, ça me semble problématique, une même machine serait deux noeuds différents si elle change d'ip, ce qui peut arriver.

En fait dans le cadre de mon application, j'inclu comme noeud des utilisateurs lambda, pas forcemment des serveurs fixes toujours connectés. Ces utilisateurs sont des clients qui vont utiliser le réseau ponctuellement, mais fournir un id quand même. Ces clients peuvent changer d'ip assez facilement.

En revanche, ma deuxième idée était d'utiliser l'adresse mac des machines en guise d'id (hash des adresses). Je dis bien des car une machine possède plusieurs interfaces. Et donc problème encore, ces interfaces peuvent changer aussi…

+0 -0

Il faut bien te dire une chose : soit tu utilises une information publique (et à ma connaissance, seul l'ip et le port le sont) qui risque de changer, soit tu utilises une information privée pour générer ton id, soit tu fais une combinaison des deux.

Dans tous les cas, vu que tu ne contrôles rien, il est absolument impossible d'empêcher quelqu'un de changer d'id.

Donc, soit tu essayes de limiter les possibilités d'un potentiel attaquant en utilisant le couple ip/port, ce qui est loin d'être parfait à cause des ips dynamiques, des NATs et des machines qui changent régulièrement de réseaux. Soit, tu te dis que de toute manière, tu peux pas y faire grand chose et tu utilises un id sauvegardé dans un fichier local en te disant qu'il y a très peu de chances qu'un utilisateur bien intentionné aille le changer.

Enfin, pour éviter d'avoir trop de risques, il serait peut-être possible d'imaginer un système qui va naturellement faire peu confiance à un nœud qui n'a pas encore fait ses preuves, mais ça compliquera beaucoup la chose, en plus de ne pas vraiment résoudre le problème : un utilisateur mal intentionné pourra toujours attendre d'avoir une bonne "réputation" pour faire n'importe quoi.

Pour conclure, le concept même d'une DHT hébergé par des utilisateurs lambda n'est pas prévu pour luter contre un utilisateur mal intentionné, donc c'est plus contre-productif qu'autre chose de vouloir faire des actions spécifiques pour contrer des attaques volontaires. Finalement, la meilleur protection, c'est d'avoir une DHT qui sera très résiliente aux crash/déconnexions de client en réfléchissant bien qu'un utilisateur mal intentionné, c'est juste un crash comme un autre.

+0 -0

@blackline pas mal :p

Merci pour vos réponses, ça me fait avancer, je ne peut pas décrire tout le fonctionnement de ce que je veut faire sinon ça serait trop long et je n'ai pas le courage, mais dans le principe en fait il serait question de clients qui ne stockent rien, mais qui vont requêter des serveurs. Ces clients ne connaissent pas le réseau et donc vont devoir utiliser des serveurs particuliers qui serviront d'annuaire. Cet annuaire serait établi via l'utilisation d'un algo DHT.

Le problème est en fait à la base de pouvoir blacklister/whitelister des clients à l'utilisation des serveurs. De fait ces client possèdent un ID aussi, et s'ils en changent peuvent contourner les black/white listes.

Du coup, en donnant un ID aux clients, on pourrait les blacklister sur ip+port+id, c'est le maximum possible si on veut être plus ou moins surs d'atteindre le but (soit du blacklist de quelqu'un, soit de l'accès par whitelist d'un client)

j'espère être clair ^^"

J'ai juste un problème avec les fichiers qui stockent l'id quelque part, c'est que je me dit que tôt ou tard, quelqu'un trouvera forcement où cet id est stocké, et pourra en changer pour contourner des sécurités (il est question de stockage de fichier décentralisé, changer l'id permettrait d'avoir plusieurs identités et de contourner des quotas de stockage). Seulement, il n'y pas d'autre solution j'ai bien peur.

enfin bref je me suis mal fait comprendre j'explique mal en ne disant pas tout dés le début, mais il n'est pas question de DHT en partie hébergé par des clients lambdas, mais de DHT sur serveurs tout ce qu'il y a de plus classique, mais avec des clients qui vont intervenir en requêtant des serveurs quelconques. La question est de réguler les interventions des clients pour des raisons de répartition de charge/ de non abus du système de stockage.

+0 -0

Ben du coup, le problème reste plus ou moins le même : il n'est pas possible d'identifier "quelqu'un" de manière sûr et unique. Point.1

Et vu la difficulté qu'ont les jeux en ligne pour éviter le multi-compte, on peut facilement en conclure que tout système de "protection" se contourne relativement facilement.

Le seul système qui pourrait éviter les abus serait un système dans le même esprit que les bitcoins : les utilisateurs du réseau doivent "travailler" pour le réseau afin de l'utiliser (que ce soit pour le stockage ou la récupération de fichier). Ça pourrait aussi s'apparenter à ce qui se fait en terme de contrôle de ratio chez certains serveurs de torrent (même si le contrôle est centralisé dans ce cas).

En tout cas, le principe de DHT n'est pas prévu pour et ne te permet pas de faire du contrôle. Si tu veux ajouter cette fonctionnalité, il faudra ajouter une couche par dessus, basé sur un autre principe.

  1. en excluant, bien sûr, l'utilisation de systèmes d'identification utilisés par des états (genre carte d'identité, carte de sécu et autres). D'autant que ce n'est pas parfait non plus. ↩

+0 -0

L'avantage du hash de l'IP, c'est que les autres clients peuvent le vérifier, et donc, si je veux me faire passer pour quelqu'un d'autre, je dois forcément changer mon IP. C'est ça l'intérêt de ne se fonder que sur des données publiques: que tu ne me croies pas sur parole si je viens chez toi et te dis que je suis Albert Einstein, en plus sans avoir les outils pour le vérifier.

Le fait qu'on peut changer d'IP et donc d'ID très facilement est de toute façon un problème insoluble, donc autant en temir compte tel quel dès le début. Ca doit équivaloir à de simples connexions/déconnexions. JE suis admin d'un jeu en ligne, et honnêtement, j'ai abandonné la traque systématique des multicomptes tant qu'il n'y a pas de plainte ou de triche avérée. ca sert à rien, des petits malins qui contournent il y en aura toujours; c'est une lutte à corps perdu.

Si tu veux un système vraiment fort et pas facilement crackable, tu peux passer par des certificats cryptographiques. ET même là il y a des failles, d'une part dans les algorithmes, et d'autre part parce qu'il faut nécessairement une CA au sommet, et que celle-là est forcément faillible si elle se fait attaquer (dans ce modèle, on part toujours du principe que la CA est intouchable) Sinon il y a les modèles à la PGP, tu choisis de faire confiance à quelqu'un ou pas en fonction de ce qu'en penses tes meilleurs amis. Mais c'est compliqué, et ça ne définit pas vraiment comment ton réseau se modifie et qu'est-ce qui va faire que ton estime pour quelqu'un va effectivement monter ou descendre, ni comment tu vas faire tes premiers amis quand tu débarques dans le système.

L'inconvénient de se fonder sur des données privées comme l'adresse MAC pour générer ton ID, c'est justement que les autres clients ne peuvent pas le vérifier. En d'autres termes si je viens chez toi et que je te dis que je suis Albert Einstein, tu peux certes me dire que tu ne me crois pas, mais tu n'as pas de preuve, pas de moyen de vérifier si oui ou non effectivement je te dis une connerie. Donc à mon avis un identifiant uniquement basé sur des données publiques est indispensable sur un réseau P2P.

+0 -0

Ok Ok c'est intéressant ce que vous dites, donc se baser sur des infos publiques peut être plus intéressant pour permettre aux interlocuteurs de vérifier si la personne qui parle utilise un mauvais ID. On peut pas imaginer un système qui utilise des éléments publics ET privés ? par exemple la moitié de l'id est le hash de l'ip, et l'autre moitié des adresses mac. Comme ça on peut, bien que la personne change d'ip, et dans une certaine mesure, arriver à retrouver une même personne sur plusieurs réseaux.

En tout cas merci pour vos réponses

+0 -0

Le problème avec l'ip, c'est les NATs et de manière plus générale tous les réseaux privés qui n'ont qu'une seule ip publique. Par exemple, dans un cas comme ça, si quelqu'une veut héberger plusieurs serveurs DHT, il ne pourra pas. De même si plusieurs personnes dans une maison veulent chacun héberger un serveur DHT, il ne pourront pas. Et ce, sans parler des NATs qui rassemble parfois de grand nombre d’abonnés d'un FAI. Ça, c'est le premier problème.

Le second, c'est les changements d'ip (forcés) qui sont courant (voire très courant). Que ce soit à cause d'une ip dynamique chez son FAI, un ordi qui va changer (très) régulièrement de réseau (maison/travail/portable/amis et j'en passe). Ces cas risquent d'être beaucoup plus courants que des véritables volontés d'attaques.

Et puis ça ne résout en fait pas grand chose, vu la facilité avec laquelle on peut changer d'ip via le réseau mobile (3G/4G et autres). Sans compter qu'il y a des personnes qui ont accès à un nombre d'ip au delà du raisonnable : le MIT possède 18.0.0.0/8, IBM 9.0.0.0/8, HP en a 2, le département de défense américaine en a 13 (soit plus de 1/20 de toutes les IPv4 possibles). Et il me semble avoir entendu que certains étudiants du MIT ont "légèrement" abusés de ces ip pour "légèrement" fausser des votes en ligne. À une échelle plus faible, mais toujours notable, l'ENSEEIHT possède un /16 et nous (le club info) laisse utiliser un /21 (2048 adresses).

Donc l'utilisation de l'ip pour générer son ID ne résout aucun problème et en ajoute (les ips dynamiques). D'ailleurs, il faut aussi noter qu'il n'est pas possible de connaitre son ip publique sans utiliser un service extérieur (qui peut donc nous mentir), ce qui ajoute à la difficulté de cette solution.

+0 -0

Qu'on soit bien d'accord, il n'est pas question pour les clients lambdas qui vont être sujets à des connexions/deconnexions/changements de réseaux, d'héberger des serveurs, ce n'est pas ça :)

Le problème est juste d'identifier des clients avec un id similaire à celui qu'un système de DHT utiliserait.

C'est pour toutes ces raisons, c'est parce que le client peut changer souvent d'adresse, que plusieurs personnes peuvent utiliser la même ip publique, qu'ajouter des adresses mac dans l'id des client serait intéressant.

Si au niveau des serveurs, on peut faire la distinction entre partie ip et partie mac d'un id de client, on pourrait blacklister selon la partie IP des id (et ainsi bloquer une ip, toutes les personnes étant dans les sous-réseaux compris), les clients peuvent changer d'ip et basta. Ou bien blacklister sur la partie mac, qui va cibler plus précisemment une machine précise.

Me dire si je dis des bétises :)

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte