Comment les règles basées sur IP (par exemple, les interdictions / filtres) sont-elles affectées une fois que IPv6 devient la norme?

Étant donné que les sites Stack Exchange interdisent l'IP , je me demande s'il existe une opinion ou une stratégie commune sur l'élaboration de règles basées sur l'IP d'un utilisateur afin de dicter les comportements.

Avec IPv4, vous avez quelques éléments que vous pouvez supposer de manière assez fiable sur une IP donnée:

1. Les adresses IP qui partagent un sous-réseau peuvent très bien être le même utilisateur
2. Bien que les adresses IP puissent être réutilisées pour divers points de terminaison réels, il est relativement peu probable que vous voyiez des connexions en double provenant d'une adresse IP qui ne sont pas le même utilisateur, ou au moins le même foyer / organisation (en gros, une connexion partagée)
3. il n'est pas facile pour un utilisateur d'obtenir une nouvelle adresse IP publique (il y a ici une barrière de taille moyenne)

Avec IPv6, pouvez-vous assumer tout cela? J'imagine au moins que le deuxième point ne serait plus vrai puisque NAT'ing est censé disparaître essentiellement avec IPv6 car il y aura suffisamment d'adresses IP pour quiconque en veut un.

Si vous disposez d'un ensemble de stratégies IP, quelles considérations devez-vous prendre en compte pour IPv6, le cas échéant, en raison des différences entre les deux?

Avec IPv6, je ne pense pas qu'il existe une solution parfaite. Mais il y a un certain nombre de choses à considérer:

• Les FAI distribueront probablement des /64sous-réseaux à des clients individuels. (Il y en aura assez pour faire le tour.)
• Les lieux de travail en auront probablement au moins un /64par bureau.
• Les FAI offrant des liens strictement point à point peuvent choisir d'utiliser des préfixes entre /64et /126. (Voir pourquoi ils n'utilisent pas / 127 en général ) Ce serait probablement soit un FAI à courte vue, soit celui qui veut facturer plus cher pour un plein /64. Il n'y a vraiment aucune raison pour que chaque point de terminaison (qui pourrait être un réseau client complet) ne soit pas un /64.
• En supposant que la plupart des sous-réseaux d'utilisateurs finaux IPv6 seront sur un /64, on pourrait regarder le bit 6 dans l'identifiant d'interface (voir la section 3.2.1 de la RFC 4941 ) pour vérifier s'il a probablement été généré sur la base d'un identifiant globalement unique (adresse MAC). Ce n'est pas infaillible, évidemment. Mais si ce bit est défini, cela indique probablement que l'adresse a été générée à partir d'une adresse MAC. Ainsi, on pourrait bloquer les adresses IPv6 sur la base des 64 derniers bits, et les utilisateurs pourraient être bloqués quel que soit le sous-réseau dont ils proviennent. (Il vaut peut-être mieux utiliser cela comme un "indice", car les adresses MAC, bien que supposées être uniques au monde, ne sont pas toujours pratiques. De plus, elles sont facilement usurpées. Mais toute personne suffisamment avertie pour s'attaquer aux problèmes trouverait probablement plus facile de prenez un /64et obtenez de toute façon 2 ^ 64 adresses uniques.)
• Si des adresses de confidentialité sont utilisées ... pas grand-chose à faire, sauf bloquer cette adresse pendant une courte période. Cela va probablement changer bientôt de toute façon. Prenez en compte la partie réseau de la /64à ce stade, mais méfiez-vous car vous pourriez bloquer le siège social de quelqu'un.

Je dirais que la meilleure façon serait de regarder d'abord les adresses individuelles, puis de prendre en compte les 64 derniers bits de l'adresse et les modèles d'abus de /64sous-réseaux particuliers afin de mettre en œuvre une stratégie de blocage. Résumer:

• Commencez par bloquer /128les adresses IP individuelles (comme vous le faites probablement aujourd'hui avec IPv4)
• Si vous remarquez un modèle d'abus d'une adresse non confidentielle dans les 64 derniers bits d'une adresse, utilisez-le comme un indicateur puissant dans votre algorithme de blocage. Quelqu'un pourrait basculer entre des FAI ou des sous-réseaux. (encore une fois, faites attention à cela, car les MAC ne sont pas nécessairement uniques - quelqu'un pourrait usurper votre ordinateur pour exploiter votre algorithme). Cela ne fonctionnerait également que contre les abuseurs qui ne savent pas comment IPv6 fonctionne. ;-)
• Si vous remarquez un modèle d'abus d'un particulier /64, bloquez le tout /64avec un bon message d'erreur afin que l'administrateur du réseau incriminé puisse faire tout le travail qui doit être fait de son côté.

Bonne chance.

Les hypothèses que vous énumérez:

Les adresses IP qui partagent un sous-réseau peuvent très bien être le même utilisateur

Cela continue d'être vrai - en fait, si les FAI attribuent des sous-réseaux IPv6 à leurs clients, cela devient encore plus vrai.

Bien que les adresses IP puissent être réutilisées pour divers points de terminaison réels, il est relativement peu probable que vous voyiez des connexions en double à partir d'une adresse IP qui ne sont pas le même utilisateur, ou au moins le même foyer / organisation (en gros, une connexion partagée)

Continue à tenir (s'applique en fait à l'ensemble du sous-réseau comme décrit ci-dessus).

Il n'est pas facile pour un utilisateur d'obtenir une nouvelle adresse IP publique (il existe ici une barrière de taille moyenne)

Ne s'applique pas autant à une adresse IP individuelle, mais s'applique à un sous-réseau distribué par un FAI.

Donc, fondamentalement, nous examinons les interdictions de sous-réseau où nous avons actuellement des interdictions IP, en supposant que les FAI distribuent des sous-réseaux à tous leurs utilisateurs. Si, à la place, les utilisateurs obtiennent des adresses IPv6 individuelles (une par utilisateur), nous examinons des interdictions IPv6 uniques, ce qui peut entraîner une table d'interdiction beaucoup plus longue (et des problèmes de performances associés) s'il y a beaucoup d'utilisateurs mal comportés.
Dans les deux cas, une interdiction IP devient un outil plus granulaire (c'est-à-dire moins de risque de bloquer un groupe d'utilisateurs d'un FAI qui a un pool dynamique en raison d'une mauvaise conduite d'une personne), ce qui, à mon avis, est une bonne chose ...

Wikipédia / MediaWiki adoptent une politique de blocage d'un ensemble / 64 lorsqu'ils bloquent la cinquième IP au sein de ce / 64.

Cinq semble être la règle générale standard que d'autres adoptent - les quelques DNSBL que j'ai vus adoptent la même politique.

Je n'ai pas vu de plans pour agréger les blocs au-dessus de a / 64, même si obtenir un / 48 ou un / 56 est assez facile, même pour une organisation modeste. Bien sûr, les spammeurs ont actuellement souvent un / 24 (IPv4), donc je m'attends à ce qu'ils commencent à saisir de gros morceaux d'espace IPv6.

Les adresses IP qui partagent un sous-réseau peuvent très bien être le même utilisateur

Toujours vrai, en fait encore plus vrai avec la v6.

Bien que les adresses IP puissent être réutilisées pour divers points de terminaison réels, il est relativement peu probable que vous voyiez des connexions en double à partir d'une adresse IP qui ne sont pas le même utilisateur, ou au moins le même foyer / organisation (essentiellement, une connexion partagée)

Probablement encore plus vrai avec la v6 que la v4.

il n'est pas facile pour un utilisateur d'obtenir une nouvelle adresse IP publique (il y a ici une barrière de taille moyenne)

Dans la plupart des cas, plutôt que des adresses individuelles, les FAI distribueront des blocs d'adresses. Il est facile pour un client de se déplacer dans son bloc. Plus difficile (mais loin d'être impossible) d'obtenir un nouveau bloc.

Le plus difficile est que les tailles d'allocation aux clients varient énormément. Certains FAI distribuent des adresses individuelles, certains blocs / 64, certains / 56 blocs, certains / 48 blocs.

Cela rendra difficile l'élaboration d'une politique d'interdiction / limitation sensée qui fonctionnera pour tous les FAI. Est-ce "chaud" / 48 un seul agresseur qui a trouvé un FAI qui a distribué de gros blocs ou est-ce un grand groupe d'utilisateurs sur un fournisseur mobile radin qui donne des adresses individuelles.

PS Refuser d'implémenter IPv6 n'est pas vraiment une solution non plus, car avec l'épuisement IPv4, de plus en plus de clients seront derrière une certaine forme de NAT de niveau FAI.

Je pense que cela dépendra fortement de ce que feront les FAI. Vont-ils continuer à fournir aux utilisateurs des adresses IP dynamiques réelles? Si ce n'est pas le cas, ou si chaque utilisateur obtient son propre ip / sous-réseau exclusivement, les IP commenceront à être à peu près les mêmes qu'une plaque d'immatriculation.

Quand je compris que l' IPv6 allait augmenter le nombre d'adresses IP d' un grand nombre , mais pas d' augmenter le nombre de ports par hôte, j'étais d' abord perplexe. Étant donné que les ordinateurs deviennent de plus en plus puissants et deviennent ainsi plus capables de desservir un grand nombre de connexions simultanées, le fait de se limiter à un maximum de 65 535 ports par adresse IPv6 semblait être "le prochain goulot d'étranglement".

Ensuite, j'y ai réfléchi une fois de plus et j'ai réalisé qu'il était trivial d'affecter plusieurs IPv6 à une interface physique et de cette façon de contourner cette limite du nombre de ports pouvant se connecter à l'hôte. En fait, à bien y penser, vous pouvez assez facilement attribuer des adresses IPv6 1024 ou 4096 à votre hôte, puis répartir vos services de manière aléatoire sur différents ports sur toutes les adresses, ce qui rend les scanners de port plus difficiles (au moins en théorie) .

Maintenant, les tendances comme la virtualisation des hôtes (plusieurs hôtes virtuels plus petits sur un hôte physique relativement puissant) et les appareils portables (pensez que les mobiles connectés à IPv6 à tout le monde sur la planète) feront probablement contre cela, la plupart des hôtes du futur Internet utiliseront probablement assez quelques ports et n'ont donc besoin que d'une seule adresse IPv6 par hôte.

(Mais la possibilité de "se cacher" dans un grand pool d'adresses IPv6, dont vous êtes le propriétaire et que vous pouvez choisir au hasard, fournit toujours une couche de sécurité, même si elle est certes mince dans la plupart des circonstances)