Je me suis aperçu hier soir qu’un ordinateur sur un réseau domestique relié à internet par une Freebox était par défaut accessible en IPv6 depuis internet. Pour parler en des termes plus concrets : il est possible d’ouvrir une connexion sur la machine depuis internet.

Par exemple, on peut faire un ping et ça répond. Ou on peut ouvrir une connexion SSH.

Il y a une option “activer le firewall IPv6” dans l’interface de configuration de la Freebox qui permet de bloquer le trafic IPv6 entrant mais cette option semble être désactivée par défaut (voir l’image). C’est un choix de Free que je trouve un peu cavalier car l’utilisateur à gros doigts se retrouve exposé sans le savoir, contrairement à l’IPv4 qui a l’effet secondaire bénéfique de cacher les appareils du réseau local tant qu’aucune redirection de port n’est configurée dans la NAT.

Je ne sais pas ce qu’il en est des box des autres FAI mais ça vaut le coup d’aller vérifier. Surtout si le réseau héberge des machines sous linux, lesquelles ont fréquemment un serveur SSH actif par défaut (qui, circonstance aggravante accepte souvent les connexions par mot de passe par défaut) ou s’il comporte des caméras IP à la sécurité douteuse (coucou le mot de passe admin en carton).

Pour relativiser toutefois : les machines du réseau local sont certes accessibles publiquement mais encore faut il connaître leur IPv6 pour pouvoir les atteindre. La découverte par la force brute est peu probable, étant donné la taille gigantesque de l’espace d’adresse IPv6 (il y a de l’ordre de 10^38 adresses possibles). Et même en connaissant les 8 premiers octets du préfixe (ce que le FAI attribue à son abonné), il reste encore les 8 derniers à découvrir, ce qui représente de l’ordre de 10^19 possibilités. A raison de 100 essais par seconde, il faudrait plus de trois milliards d’années pour les essayer toutes. Le plus gros risque à mon avis, c’est qu’un attaquant exploite des IPv6 qui auraient fuité par ailleurs, lors de l’attaque d’un service web grand public qui conserverait de telles infos dans ses bases de données ou dans ses logs, par exemple.

Pour savoir si vous êtes à risque, il vous faut :

  • connaître l’IPv6 d’un appareil du réseau à vérifier. C’est visible sur la page https://www.mon-ip.com/, vue depuis la machine considérée. C’est aussi visible depuis un terminal avec ipconfig /all sous windows ou ifconfig sous linux. Dans ce cas, ignorez les adresses de type “link-local” qui débutent par fe80::, celles-ci ne sont pas routables. Si la machine est publiquement accessible, elle aura plusieurs autres adresses dont les 8 premiers octets (c’est à dire, les quatre premiers mots séparés par deux-points) sont identiques. Prenez-en une parmi celles-là.
  • une machine sur un autre réseau, qui a une connexion IPv6 (c’est fréquent de nos jours). A défaut, vous pouvez connecter un ordinateur en wifi sur la connexion partagée d’un téléphone relié au réseau de données de l’opérateur mobile. Ca produira le même effet. Depuis cet ordinateur, tentez un ping avec l’adresse choisie plus haut. Si ça répond, la machine est accessible publiquement.
  • fendrax@jlai.luOP
    link
    fedilink
    Français
    arrow-up
    1
    ·
    6 months ago

    Je m’auto-réponds : tu pensais peut-être au CGN pour faire un tunnel IPv6 => IPv4 comme visible ici? Dans ce cas, tu n’as pas vraiment de l’IPv6, correct ? Est-ce que les appareils de ton réseau ont une IPv6 (autre que des link-local en fe80:, j’entends) ?

    • Syl@jlai.lu
      link
      fedilink
      Français
      arrow-up
      1
      ·
      6 months ago

      J’avais configuré mon routeur en direct (R7000 avec freshtomato) pour récupérer les ip et les assigner à mes périphériques.

      Oui je suis sûr, cherche red-by-sfr CGNAT.

      • fendrax@jlai.luOP
        link
        fedilink
        Français
        arrow-up
        2
        ·
        6 months ago

        Je viens de revérifier. Peut-être que j’ai mal interprété ton premier message. Mais je tiens à éviter toute confusion : CGNAT n’existe pas en ipv6. Si tu as du CGNAT, c’est sur la partie stack ipv4 fournie par SFR en parallèle de la stack ipv6. C’est contraignant parce que l’ipv4 est plus facile à gérer que l’ipv6 donc on la préfère quand c’est possible.

        Le support semble pouvoir rebasculer en ipv4 full stack (en insistant pas mal). Et sinon la solution ultime c’est d’abandonner l’ipv4 et de migrer totalement vers l’ipv6 qui permet un accès total. Tes services ne seront alors plus accessibles en ipv4. Je ne sais pas à quel point c’est encore gênant en 2024, ça.

        • Syl@jlai.lu
          link
          fedilink
          Français
          arrow-up
          2
          ·
          6 months ago

          oui j’ai pas non plus été très clair, effectivement le CGNAT est pour l’IPv4 (je ne m’en rappelais plus moi-même). Et oui je suis repassé un IPv4 (donc sans IPv6) car j’avais besoin de faire de la redirection de port. J’ai un proxy Signal d’installé (la campagne #IRanASignalProxy lors de la Révolution en Iran) et celui ci n’était plus accessible avec le CGNAT. Idem pour torrent.

          • fendrax@jlai.luOP
            link
            fedilink
            Français
            arrow-up
            4
            ·
            6 months ago

            Et par curiosité, tu as essayé d’utiliser uniquement ipv6 ? Je me demande si ça serait encore une contrainte aujourd’hui. Est-ce qu’il y a encore des serveurs sur internet qui ne sont accessibles qu’en ipv4 ? Ou inversement des clients qui sont seulement ipv4 ?

            Puisqu’il n’y a plus d’ipv4 disponible, je me dis qu’il doit déjà y avoir des particuliers qui n’ont que de la v6, non ? Le CGNAT n’est qu’un pansement qui retarde l’inéluctable.

            • Syl@jlai.lu
              link
              fedilink
              Français
              arrow-up
              2
              ·
              6 months ago

              ouais… on n’est pas prêt je pense. J’utilise un routeur avec un firmware custom pour bloquer les pubs, et ça utilise des filtres avec IPv4 (pour dnsmasq). Donc faut déjà que tout le monde y passe.
              On est dans la même situation que le passage à Python 3.

              • fendrax@jlai.luOP
                link
                fedilink
                Français
                arrow-up
                1
                ·
                6 months ago

                ça utilise des filtres avec IPv4

                Que veux-tu dire ? Le filtrage se fait en général sur le nom de domaine, pas sur l’IP. Je doute que tes filtres soient vraiment des listes d’IPv4 à bannir.

                • Syl@jlai.lu
                  link
                  fedilink
                  Français
                  arrow-up
                  1
                  ·
                  6 months ago

                  host file, qui assigne un nom de domaine à l’ip 0.0.0.0 rt donc bloque la résolution.

                  • fendrax@jlai.luOP
                    link
                    fedilink
                    Français
                    arrow-up
                    1
                    ·
                    6 months ago

                    Cette technique marche aussi en ipv6. Je crois que l’équivalent consiste à mapper le domaine sur ::.

                    D’ailleurs si ce n’est pas fait, le simple mapping vers 0.0.0.0 ne garantit le blocage que si tous les clients sont uniquement ipv4. Ça se fait rare de nos jours. Un client ipv6 continuerait à obtenir la vraie ipv6 du domaine.