L'unicité des adresses IP : la fin du rêve HADOPIen ?

Posté par (page perso) . Modéré par baud123.
Tags : aucun
20
8
juin
2010
Justice
Les 5 gus dans un garage avaient réussi à casser le pare-feu OpenOffice.org. Les voilà qui fabriquent véritablement des adresses IP au détour de leur bagnole défoncée... La loi adorée de tous les internautes - HADOPI - les menace de pister leurs IP, ces « cartes d'identité » côté réseau. Quelques-uns avaient découvert le greffon Firefox Modify Headers qui permet d'ajouter, modifier et filtrer les en-têtes HTTP d'une requête. Bon, le petit problème est que cette solution n'était pas pleinement satisfaisante car ne fonctionnant pas dans tous les cas.

Ensuite, des gens de l'INRIA ont publié une étude des échanges sur BitTorrent, révélant la possibilité de connaître près de 150 millions d'adresses IP et identifier aussi bien les plus gros contributeurs de contenus que les plus gros téléchargeurs. Même être caché derrière Tor ne suffit pas visiblement, comme ils l'avaient décrit précédemment. Malheureusement pour les employés de la rue de Texel, la méthode de l'INRIA ne peut être utilisée légalement.

Par la suite, plusieurs ont vanté les mérites de SeedFuck : le logiciel de torrent poisonning. Autrement dit, il vous permet de noyer votre IP dans un flot de fausses adresses IP générées de manière aléatoire.

Voici donc venir la combinaison d'un Modify Headers et d'un SeedFuck : IPFuck est le dernier-né dans la grande famille des logiciels proof Of concept (pOc). Comme l'explicite sa description, il s'agit d'un générateur d'adresses IP aléatoires ayant pour but l'HTTP poisonning. Ainsi, grâce à cet addon Firefox, vous pouvez envoyer, en plus de votre véritable adresse IP, trois autres générées au hasard.

L'auteur explique qu'il est impossible de masquer sa véritable adresse IP (ce qu'il appelle le Transport Layer, la couche Transport du modèle TCP/IP) : si elle est modifiée, les paquets se perdront. En revanche, les trois autres (celles venant de ce qu'il appelle l'Application Layer, la couche Application du modèle TCP/IP) peuvent être changées sans conséquence pour votre navigation : vous choisissez les règles dans l'onglet Options et c'est fait. IPFuck est distribué sous les termes de la licence GPL.

Décidément, HADOPI n'est pas encore sorti de l'auberge.
  • # IPFuck

    Posté par . Évalué à 6.

    Mais si le poste se trouve derrière un routeur, ces fausses requêtes ne peuvent pas atteindre le serveur web sans que le routeur ne les modifie lui-même, non ?

    Je suis pas expert en réseau mais j'ai suivis les conférences de Benjamin Bayard qui explique ça.

    Normalement ce type d'artifice ne fonctionnera que si le poste est connecté directement à internet, mais ce type de configuration tend à disparaître avec l'utilisation des box.
    • [^] # Re: IPFuck

      Posté par . Évalué à 10.

      c'est une gentille fumisterie, comme en témoignent les commentaires et explications de son blog.

      en gros il rajoute des champs comme HTTP_X_FORWARDED_FOR à une requête HTTP classique. avec une adresse ip farfelue.

      du coup les gens à képis en face (en les supposant très très bas de plafond), ils vont croire que cette requête passe par un proxy (toi) et que le messan pirate vient en fait de HTTP_X_FORWARDED_FOR. ils vont donc courir après cette connexion imaginaire et te foutre la paix.

      si tu as l'impression que ça ne vole pas très haut, par exemple parce que peu de monde garde ce genre de champ dans son /etc/var/log/apache*ou parce que on viendra quand faire chier le propriétaire du proxy (réel ou pas) pour le fermer sur l'air de sécuriser la connexion machin tout ça, tu n'as sûrement pas tout à fait tort...
    • [^] # Re: IPFuck

      Posté par (page perso) . Évalué à 0.

      Je pense qu'il y'a une petite confusion dans ce que tu as compris:

      L'adresse IP te servant à te connecter à internet ne peut pas etre modifiée sous peine de ne plus recevoir la reponse. Prenons le cas d'une lettre, tu écrits l'adresse du destinataire et au dos ton adresse pour que l'on puisse te répondre.

      Les analyses HADOPI pour le peux qu'on en connaissent 'ouvrent' et lit le contenu de ta lettre (Deep Packet Inspection), le principe de l'IPFuck est de transmettre des informations qui trompes le système. Le routeur ne modifie pas le contenu du paquet, juste l'adresse de l'envelope. C'est pour cette raison que l'IPFuck fonctionne uniquement sur le traffic HTTP en essayant de faire croire a HADOPI que ton réseau contient un proxy HTTP (relais de la poste).
      Mais le proprietaire du proxy se doit de sécuriser sa connexion cqfd.

      Ce que Benjamin Bayard as vous expliquer c'est qu'il est difficile disolé un individu derrière une addresse IP externe. Dans les réseau universitaire, ou professionnel il n'est pas rare d'avoir quelques centaines d'utilisateurs (adresses internes). Retrouver la personne correspondante nécessite souvent des ressources supplémentaire et ne permet pas avec certitude d'identifier la personne (c.f. mot de passe volé ...)

      La technique de IPFuck & Seedfuck est d'essayer générer des faux positives afin d'augmenter le cout (temps & financier) d'Hadopi.

      Je ne pense pas qu'Hadopi supporte le protocole RFC-1149 sa doit être praticable sur Paris avec des débit nettement supérieure à la fibre optique :)

      http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

      • [^] # Re: IPFuck

        Posté par . Évalué à 10.

        Les analyses HADOPI pour le peux qu'on en connaissent 'ouvrent' et lit le contenu de ta lettre (Deep Packet Inspection), le principe de l'IPFuck est de transmettre des informations qui trompes le système.

        HADOPI même ne réalise aucune détection et donc certainement pas de la DPI. La DPI nécessite la participation active des ISP. Dans le cadre d'HADOPI, le travail de détection et de remontée des IP est laissé à la charge des ayant-droits c'est-à-dire de leurs prestataires. Et du peu qu'on connait de leurs techniques, c'est surtout de la collecte d'adresses IP en participant aux réseaux P2P et en y introduisant des leurres. La seule obligation légale pour les ISP c'est de bloquer les titulaires des adresses IP validée par HADOPI après avoir été remontées par les prestataires des ayant-droits. C'est aussi pour ça que tout le monde dit que la contrefaçon va se reporter vers des réseaux privés ou le téléchargement direct (et pas le streaming, abus de langage que j'entends beaucoup).

        Bref, IPFuck c'est rigolo deux minutes dans la veine du "on est plus malin que vous" mais ça sert à rien. Et si c'est pour dire "vous voyez bien que l'IP n'est pas une preuve valable justifiant un régime de contravention", on rentre dans une boucle juridique très amusante où soit 1) l'IP est une données personnelle donc identifiable mais pas collectable au nom de la vie privée soit 2) l'IP n'est pas une donnée personnelle donc pas identifiable (et caduque pour la justice) mais alors rien ne justifie de ne pas laisser n'importe qui la collecter...

        Interesting times.
        • [^] # Re: IPFuck

          Posté par (page perso) . Évalué à -1.

          Oups, je me suis mélangé les pédales, en Angleterre ils vont utilisé le DPI ou assimilé sur les FAI de plus de 400K utilisateurs.

          http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

      • [^] # Re: IPFuck

        Posté par . Évalué à 3.

        Dans les réseau universitaire, ou professionnel il n'est pas rare d'avoir quelques centaines d'utilisateurs (adresses internes). Retrouver la personne correspondante nécessite souvent des ressources supplémentaire et ne permet pas avec certitude d'identifier la personne (c.f. mot de passe volé ...)

        Et sur les accès 3G derrière un NAT, quand plusieurs téléphones mobiles ont la même IP? Ils répondent quoi au juge?

        Ça expliquerait pourquoi ils limitent fortement l'usage: pour ne pas remplir des disques durs de logs :]

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: IPFuck

          Posté par . Évalué à 4.

          Et sur les accès 3G derrière un NAT, quand plusieurs téléphones mobiles ont la même IP? Ils répondent quoi au juge?

          Exactement la même chose que les autres : 'vous nous avez demandé qui utilisait l'IP x.y.z.t, voici les données avec toutes les IP NATées qui étaient derrière celle-là, dites-nous laquelle des IP NATées vous concerne et on vous dira qui c'est'.
          • [^] # Re: IPFuck

            Posté par (page perso) . Évalué à 0.

            Tout le trafic HTTP passe par des proxy, ca laisse des logs tout ca. Si vous regardez de plus près dans votre 'dossier' de certificat SSL, des certificats de votre opérateur ont été pré-installé ce qui fait qu'il pourrait faire de l'attaque de l'homme du milieu sur les connexions HTTPS et les loggues également.

            Pour ce qui est des connections, l'adresse source, de destination, port source et port de destination ainsi que l'heure de connexion est en soit unique permettant d'identifier la source de la connection. La question se posant est ce que les connexions sont loguées à cause de leur statut d'opérateur mobile. Sous linux, le module ulog2 permet d'enregistrer les données dans une base de données SQL.

            http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

            • [^] # Re: IPFuck

              Posté par (page perso) . Évalué à 0.

              J'ai oublié d'écrire sur le cout d'un disque qui est globalement pas très important, qu'elle est la période maximum de rétention autorisée par la CNIL ?

              http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

              • [^] # Re: IPFuck

                Posté par . Évalué à 4.

                En qualité d'hébergeur, tu es déjà obligé de garder tes logs 1An, il me semble, afin que ça reste à disposition des autorités.

                Ensuite, comme tu dois tout déclarer à la CNIL, c'est elle qui t'indique la durée maximale de rétention de ces données au cas par cas. La loi dis en effet «pour une durée appropriée à l'objectif de la rétention». Vive les loi claires! :)

                source: http://wiki.auto-hebergement.fr/dokuwiki/lois/contraintes_et(...)égaux


                Après, le régime des opérateurs est surement légèrement différent. Et ils peuvent surement se permettre de péter au nez de la CNIL si ils le souhaitent…
            • [^] # Re: IPFuck

              Posté par . Évalué à 4.

              Si vous regardez de plus près dans votre 'dossier' de certificat SSL, des certificats de votre opérateur ont été pré-installé ce qui fait qu'il pourrait faire de l'attaque de l'homme du milieu sur les connexions HTTPS et les loggues également.

              Non, quand bien même le certificat serait préinstallé (j'ai un gros doute sur mon linux ;) ), il ne permettra pas de faire du mitm.

              Sinon, merci à Gniarf pour l'explication un peu plus claire que tout ce qu'on a pu voir repris à tort et à travers. L'idée est de feinter les serveurs pour qu'ils loggent la fausse ip plutôt que celle du proxy : ça me semble un fumble, la plupart des serveurs que je connaisse loggeront l'ip du proxy, sans même préciser que c'est un proxy :).
              • [^] # Re: IPFuck

                Posté par . Évalué à 3.

                Non, le but est juste de logguer 4 adresses IP par requete. C'est tout et ça va pas plus loin.
                • [^] # Re: IPFuck

                  Posté par . Évalué à 2.

                  Personne ne logge les HTTP_X_FORWARDED_FOR... A part du bruit, ça n'ira pas bien loin. Et de toute façon, tu es probablement responsable de défaut de sécurisation de ta connexion si tu as un proxy ouvert à tous (d'ailleurs, c'est probablement illégal pour la même raison d'être un noeud tor désormais), donc faire croire que tu es seulement proxy ne sert pas à grand chose.
                  • [^] # Re: IPFuck

                    Posté par (page perso) . Évalué à 1.

                    d'ailleurs, c'est probablement illégal pour la même raison d'être un noeud tor désormais
                    En revanche, il reste possible d'utiliser GNUnet...
                  • [^] # Re: IPFuck

                    Posté par . Évalué à 1.

                    Comment ça c'est illégal (d'être un noeud Tor). C'est une projection dans l'avenir ou c'est réellement le cas ? Est ce que tu as une source qui justifie cela ?
                    • [^] # Re: IPFuck

                      Posté par . Évalué à 0.

                      C'est une simple interprétation (assez large cela dit) de ce que peut être le "défaut de sécurisation", qui n'est pas défini par la loi.

                      Mais en gros, vu qu'un noeud tor permet potentiellement à un tiers d'utiliser ta connexion pour faire des trucs malhonnêtes, un juge qui n'y comprend rien se fera facilement enfumer et considèrera que c'est un défaut de sécurisation.
                      • [^] # Re: IPFuck

                        Posté par . Évalué à 3.

                        En l'occurrence il sera interdit d'être un noeud de sortie Tor. Parce que tant que tu es un noeud interne, normalement tu ne devrais pas avoir de problème.
              • [^] # Re: IPFuck

                Posté par . Évalué à 6.

                Non, quand bien même le certificat serait préinstallé (j'ai un gros doute sur mon linux ;) ), il ne permettra pas de faire du mitm.

                Ben... si? En admettant que Orange ait effectivement installé une CA sur ton poste, et en admettant que megashare.com ou rapidupload.net ait un mode HTTPS pour tromper l'ennemi, qu'est ce qui empêche Orange de proxy-fier les requêtes à destination de ces deux serveurs, après les avoir muni de certificats signés par leur CA et correspondant bien au nom requis? Évidemment, si tu regardes l'autorité signataire des certificats concernés, tu pourras déceler le pot au roses (et encore : rien n'empêche de rajouter une CA intermédiaire dont l'Organisation serait un truc plus crédible que "Orange Ltd")

                Bref, je ne vois pas bien comment le pékin lambda pourra flairer l'embrouille.
                • [^] # Re: IPFuck

                  Posté par . Évalué à 0.

                  Bref, je ne vois pas bien comment le pékin lambda pourra flairer l'embrouille.

                  Effectivement, vu comme ça :). Ca impose juste un dns menteur, et aussi que l'utilisateur n'a pas déjà accédé au site (sinon, le navigateur devrait détecter que le certificat est probablement falsifié, car différent de celui connu, cela dit, les navigateurs sont moins paranos qu'ssh, du coup, je ne suis pas sûr du comportement dans ce cas).

                  Cela dit, les opérateurs s'installent vraiment en tant que CA racine ?
                  • [^] # Re: IPFuck

                    Posté par . Évalué à 5.

                    Pas besoin de DNS menteur si tu passes deja par un proxy. Sinon justement les navigateurs ne previennent pas quand un certificat change.

                    Et finalement pas besoin de certificat racine, le gestion des clés SSL est tellement mal foutu qu'un certificat intermédiaire peut signer n'importe quoi (mais oui en pratique je pense qu'ils rajoutent un certif racine dans la base de données du téléphone, rien que pour éviter de payer des certificats pour certains services).
                • [^] # Re: IPFuck

                  Posté par . Évalué à 1.

                  J'ai peut être pas tout compris, mais les CA doivent être authentifiés eux aussi, pour que ce soit fiable.

                  Genre ton navigateur possède les certificats des plus gros CA par défaut, ce qui permet d'échanger avec le CA sans que FAI puisse intervenir, en authentifiant le CA d'une part, et en cryptant les échanges avec (vrai) le CA d'autre part.

                  Pour contrer ça, il faudrait que le FAI fournisse lui même le navigateur, ou qu'il fasse du MIDM quand tu le télécharge.
                  • [^] # Re: IPFuck

                    Posté par . Évalué à 4.

                    J'ai peut être pas tout compris, mais les CA doivent être authentifiés eux aussi, pour que ce soit fiable.

                    Sauf les racines. C'est tout le problème : il faut bien commencer par faire confiance à quelqu'un pour te dire à quoi faire confiance. Ce dilemme "de la poule et de l'oeuf" se règle en considérant par défaut un certain nombre de CAs "de base" comme étant fiables.

                    Mais rien n'empêche d'en rajouter, plein de gens font ça pour garder la main sur leur PKI et/ou éviter de payer une fortune pour une CA intermédiaire "reconnue".

                    Si je regarde la liste des CA reconnues par mon Firefox, j'ai entre autres :

                    * America Online Inc.
                    * AOL Time Warner Inc.
                    * Deutsche Telekom AG
                    * Microsoft Internet Authority

                    Ainsi que quelques CA gouvernementales (Pays-bas, Japon, Taiwan).

                    Est-ce que tu penses vraiment que, là-dessus, il n'y en a pas un qui se laisserait tenter par une opération "intox'" d'envergure?

                    Sans parler du fait qu'il était question pour le gouvernement français de fournir leur propre CA. Ce qui serait assez génial à plein d'égards (notamment pour les collectivités territoriales, leur permettre d'avoir des certificats SSL reconnus sans gaspiller l'argent du contribuable), mais ça simplifierait beaucoup ce genre d'attaque.

                    C'est aussi pour ça que, le plus souvent, je préfère faire ajouter à mes administrés une CA maison, dont je suis sûr, que de dépendre d'une CA tierce qu'il pourrait être utile, un jour, de supprimer de la liste des racines.
                    • [^] # Re: IPFuck

                      Posté par . Évalué à 2.

                      Ça dépend aussi d'un truc : tous les CA racines authentifient tous les sites, ou les sites choisissent le CA ?

                      Il me semble que c'est plutôt de la deuxième manière que ça se passe. Du coup le FAI ne peut spoofer que les sites qui l'ont choisit comme authentificateur racine ...
                      • [^] # Re: IPFuck

                        Posté par . Évalué à 3.

                        Oui et non. Quand un site présente un certificat, ce dernier comporte les informations nécessaires pour trouver sa CA. Mais si on spoofe un site, il suffit de présenter un autre certificat (qui lie à une CA plus coopérative) et tout passe comme une lettre à la poste.

                        Parce que par la nature même d'SSL, tu ne peux pas changer une communication en cours. Donc si tu fais du MITM, tu interceptes _tout_. Y compris l'envoi du certificat serveur.
                        • [^] # Re: IPFuck

                          Posté par . Évalué à 2.

                          OK, si c'est le site lui même qui annonce son CA, il y a effectivement une faille.
                          • [^] # Re: IPFuck

                            Posté par (page perso) . Évalué à 4.

                            Tu imagine, si tu devais interroger tous les distributeurs de certificat pour savoir s'ils ont un certificat pour ce site? Bonjour le lag. Et s'il y en a 2 qui répondent oui, tu fais confiance auquel? (surtout que mme michu, elle fera plus confiance à Belgacom (nom qu'elle connait) qu'à Verisign qui doit sûrement être un truc de pirate.)

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                            • [^] # Re: IPFuck

                              Posté par . Évalué à 2.

                              Non, son idée c'est de vérifier par rapport aux CA installées sur la machine, je présume. Ce qui ne serait pas si idiot, si ce n'est qu'une vérification de certificat prend du temps, et qu'il y a quand même plusieurs dizaines d'autorités sur le navigateur moyen.
                              • [^] # Re: IPFuck

                                Posté par (page perso) . Évalué à 3.

                                C'est ce qui se fait pour l'instant, ou alors je n'ai pas compris ce que tu veux dire.

                                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                                • [^] # Re: IPFuck

                                  Posté par . Évalué à 2.

                                  Si je ne m'abuse, le certificat "annonce" sa CA (ou sa chaîne de confiance le cas échéant). Ce que lui proposait, c'était d'ignorer systématiquement cette information et de tester _chaque_ CA reconnue par la machine sur le-dit certificat.
                                  • [^] # Re: IPFuck

                                    Posté par (page perso) . Évalué à 3.

                                    Étant donné que le certificat est signé par l'émetteur, il n'y en aura qu'un seul qui répondra ok, et c'est celui pour lequel on l'annonce. Dans le cas ou ton fai fait un man in the middle, il ne rajoute pas une ligne dans le certificat, il le remplace totalement, ça ne changerait donc rien.

                                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: IPFuck

                  Posté par (page perso) . Évalué à 1.

                  > Évidemment, si tu regardes l'autorité signataire des certificats concernés, tu pourras déceler le pot au roses (et encore : rien n'empêche de rajouter une CA intermédiaire dont l'Organisation serait un truc plus crédible que "Orange Ltd")

                  Sur un téléphone 3G de *base* il est tres difficile de pouvoir consulté le certificat SSL en question. Ne possédant pas de iChose je ne saurais dire. Sur le n900 c'est relativement simple, le nom du CA est montré a chaque nouvelle connexion https.

                  Mozilla a *récemment* audité les CA distribué avec firefox et ont eu quelques surprise.. ( http://groups.google.com/group/mozilla.dev.security.policy/b(...) )

                  http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

            • [^] # Re: IPFuck

              Posté par . Évalué à 3.

              Pour ce qui est des connections, l'adresse source, de destination, port source et port de destination ainsi que l'heure de connexion est en soit unique permettant d'identifier la source de la connection.

              Ah bon? Fixons les choses. Supposons qu'une entorse à la loi ait été faite sur le site X.

              Ce site a loggué une adresse IP, éventuellement quelques infos sans valeur de preuve car falsifiables côté utilisateur (User Agent), et c'est à peu près tout.

              Les ports source et de destination, je ne les ai jamais vu dans les logs d'un serveur. Ça ne sert à rien de les logguer.

              En fait, pour discriminer deux utilisateurs qui sont allés sur le même serveur, au même moment, derrière la même IP publique, il faudrait logguer tout le contenu des paquets.

              Et si SSL est utilisé, ça ne suffit même pas: avec deux connexions SSL partant du même NAT vers le même serveur, ni les logs du FAI, ni les logs du serveur, ne peuvent dire qui est qui.

              Ces considérations devraient nous éviter le scénario catastrophe décrit ici: https://linuxfr.org//~nicolas_o/28809.html

              THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

              • [^] # Re: IPFuck

                Posté par (page perso) . Évalué à 1.

                > En fait, pour discriminer deux utilisateurs qui sont allés sur le même serveur, au même moment, derrière la même IP publique, il faudrait logguer tout le contenu des paquets.

                Coupable tous les deux !! C'est tellement plus simple... !
                Non plus sérieusement dans le monde pro ce genre d'information est très utile voire indispensable pour traquer toutes sortes d'incidents. Quand aux logiciels de l'hadopi qui surveilleront l'usage illégale de p2p, ils collecteront très certainement ce genre d'information au minimum pour être exploitable devant un juge. Enfin j'espère que ce soit un pré-requis mais qu'il n'arrive pas à le remplir et finir sur des vis de forme.

                Comme dit une personne précédemment, techniquement les méthodes cités n'empecheront certainement pas les coupures de connexions mais ont le mérite d'être redécouverte, et peut être donner le gout au réseau a quelques un... et qui sait les logiciels Hadopi ne sont peut être pas compatible IPv6 ... :)

                http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

  • # Guerre sans fin

    Posté par (page perso) . Évalué à 10.

    Les pirates utilisent des boardz et du FTP? La police fait des descentes et fait fermer les boardz.

    Les pirates utilisent du P2P? Les députés votent des lois liberticides et les FAI collaborent.

    Les pirates utilisent des sites de téléchargement direct? La police peut fermer les sites nationaux et le gouvernement peut mettre en place un filtrage national, toujours avec la collaboration des FAI.

    Les pirates utilisent du P2P anonyme? Leurs protocoles seront interdits et filtrés.

    Les pirates utilisent du P2P privé d'ami à ami? Idem.

    Les pirates utilisent les mails? Les mails seront interdits et remplacer par fessedebook.

    Les pirates se passent des disques durs de main en main? Les disques durs seront interdits, le cloudcomputing via un ipad sera la seule informatique tolérée.

    http://devnewton.bci.im

    • [^] # Re: Guerre sans fin

      Posté par (page perso) . Évalué à 4.

      les pirates ils sont quand même vachement bien équipés en connexion réseau sur leur Galion ;-)
      • [^] # Re: Guerre sans fin

        Posté par . Évalué à 5.

        Ils peuvent se le permettre, c'est ce qu'ils achètent avec les trillions d'euros que les majors estiment avoir perdu...
        • [^] # Re: Guerre sans fin

          Posté par . Évalué à 2.

          Autre étape à rajouter, les pirates sont désormais appelé cyberterroriste, cella fait encore plus peur et permet de faire passer plus facilement de nouvelles lois liberticides.
  • # Petit retour sur IPFuck

    Posté par (page perso) . Évalué à 5.

    Son auteur a posté ce billet ce matin : http://blog.p4ul.info/2010/06/petit-retour-sur-ipfuck/
    • [^] # Re: Petit retour sur IPFuck

      Posté par (page perso) . Évalué à 6.

      Bonsoir,

      ce que je trouve le plus intéressant, c'est :
      Par contre vous pouvez utiliser IPFuck, en le réglant sur une plage d’IP américaine par exemple, pour visionner du contenu réservé aux résidents des Etats-Unis…

      Petit test pour le fun : paramètrez IPFuck pour choisir une IP qui commence par 68 et allez sur le site officiel de South Park voir les épisodes (« Full episodes »). Désactivez IPFuck et rafraichissez la page ?

      Un autre test ? : laissez la plage IP entre 0.0.0.0 et 255.255.255.255 et allez sur ce site : http://geotool.flagfox.net/ A chaque rafraichissement vous êtes citoyen d’un nouveau pays !


      A bientôt
      Grégoire
  • # Réalisme d'une telle mesure

    Posté par (page perso) . Évalué à 3.

    Il faut être réaliste : un site codé par quelqu'un de compétent n'utilisera pas X-Forwarded-For comme information fiable. Par contre plein de sites l'utilisent oui, mais ça ne veux pas dire qu'ils ne stockent pas non plus votre vraie IP (Remote Addr).

    Par exemple à mon boulot (grand site français), nous nous basons sur Remote Addr pour tout ce qui est géolocalisation etc. par contre dans les logs on stocke Remote Addr + X-Forwarded-For, bien que comme démontré, c'est très facile à forger.

    Ceci dit ce IPFuck m'a donné une idée : et si les sites hébergés n'avaient pas accès à l'IP du client ?

    Voilà donc ce que j'ai fait : http://blogs.kd2.org/bohwaz/?2010/06/09/322-php-ip-utils-nor(...)

    Avec ça, le header REMOTE_ADDR et autres headers du genre sont remplacés par une adresse IP aléatoire générée à l'aide de la véritable adresse IP comme seed. Ainsi pour le code PHP en dessous, ça ne change rien au niveau logique, sauf qu'il ne peut avoir accès à la véritable IP du client. On peux imaginer le même genre de mécanisme via un module Apache d'ailleurs, et même peut-être que ça existe déjà ?

    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: Réalisme d'une telle mesure

      Posté par . Évalué à 2.

      Avec ça, le header REMOTE_ADDR et autres headers du genre sont remplacés par une adresse IP aléatoire générée à l'aide de la véritable adresse IP comme seed. Ainsi pour le code PHP en dessous, ça ne change rien au niveau logique, sauf qu'il ne peut avoir accès à la véritable IP du client.

      Au début, je n'ai pas très bien compris ton explication, mais en allant voir ton lien, j'ai capté : tu fais un hash de l'IP, représenté également comme une IP.

      Ça peut être pas mal ... Par contre, en IPv4, ça doit être facile de faire une rainbow table pour retrouver l'IP d'origine. Bon, par contre, en IPv6 ...

      Enfin, petite remarque : ta normalisation d'IPv6 ne suit pas, selon moi, la RFC que j'avais vu à ce sujet (on n'étend pas tout "bêtement"). Vu que tu dis juste "following the RFC", je ne sais pas à laquelle tu te réfères.
      • [^] # Re: Réalisme d'une telle mesure

        Posté par . Évalué à 2.

        Par contre, en IPv4, ça doit être facile de faire une rainbow table pour retrouver l'IP d'origine.

        Faut rajouter du sel spécifique au site ou au serveur l'hébergeant.
        • [^] # Re: Réalisme d'une telle mesure

          Posté par (page perso) . Évalué à 1.

          Oui évidemment, c'est juste une base de travail :)

          « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: Réalisme d'une telle mesure

        Posté par (page perso) . Évalué à 1.

        Pour info j'ai suivi la RFC 4291 qui dis :

        Note that it is not necessary to write the leading zeros in an
        individual field, but there must be at least one numeral in every
        field (except for the case described in 2.).

        In order to make writing addresses containing zero
        bits easier, a special syntax is available to compress the zeros.
        The use of "::" indicates one or more groups of 16 bits of zeros.
        The "::" can only appear once in an address. The "::" can also be
        used to compress leading or trailing zeros in an address.

        Là ça fait juste l'inverse.

        Je connaît pas d'autre RFC qui parle du sujet, mais si tu as plus d'infos je serais heureux de corriger mon code et mon cerveau :)

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

        • [^] # Re: Réalisme d'une telle mesure

          Posté par . Évalué à 2.

          Je connaît pas d'autre RFC qui parle du sujet, mais si tu as plus d'infos je serais heureux de corriger mon code et mon cerveau :)

          Bon, impossible de retrouver le papier où j'avais vu ça ... (il me semblait que c'était une RFC ...) C'était en gros pour avoir une forme canonique d'IPv6, en explicitant les cas ambigus comme quand on a deux suites de 0 (sur 16 bits) séparés, laquelle compresser en :: (j'ai souvenir de "celle de gauche") ; qu'on "compresse" toujours un maximum ; etc. Mais bon, tant pis.
          • [^] # Re: Réalisme d'une telle mesure

            Posté par (page perso) . Évalué à 1.

            Là c'est de la décompression justement, c'est pour normaliser pour le stockage. L'utilité étant d'avoir toujours la même longueur / syntaxe de chaîne (plus facile à parser/stocker).

            Par exemple ::1 devient 0000:0000:0000:0000:0000:0000:0000:0001. Donc c'est pas très utile de savoir ça justement, car si l'adresse IP est bien compressée elle sera bien décompressée en un truc valide. Bon du coup je sais pas si le terme normaliser est adapté par contre...

            Ceci dit si tu retrouve ça m'intéresse quand même :)

            « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

            • [^] # Re: Réalisme d'une telle mesure

              Posté par . Évalué à 2.

              L'utilité étant d'avoir toujours la même longueur / syntaxe de chaîne (plus facile à parser/stocker).

              Avoir toujours la même "syntaxe" d'adresse est le but de la "norme" dont je parlais : elle expliquaient comment compresser l'adresse de manière à ce qu'une adresse donnée n'ait qu'une et une seule forme. Le truc était fait dans l'optique de comparaison d'adresse. Ça permet d'avoir une forme canonique (j'avoue que je confond toujours ce mot avec "normalisé" : ton utilisation de ce mot est donc tout à fait bonne pour moi, en fait ...).

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.