-
IPv quoi ? :
170(8.1 %)
-
IPv4 marche très bien chez moi. Pourquoi changer ? :
598(28.6 %)
-
J'aimerais bien changer mais j'ai peur que cela ne fonctionne plus bien chez moi :
232(11.1 %)
-
Je passerais bien à IPv6 mais j'attends que LinuxFr.org le prenne en charge :
100(4.8 %)
-
Je viens de passer à l'IPv6 chez moi. Ça a l'air d'aller plus vite sur certains sites. Mais est-ce une impression ? :
71(3.4 %)
-
Je suis passé à IPv6 depuis longtemps. Je ne pense pas que je pourrai retourner en IPv4 :
128(6.1 %)
-
Tout est en IPv6 : mes serveurs, mon ordinateur, mes objets connectés. Il faut penser aux autres ! :
139(6.7 %)
-
Je suis passé à C3PO directement. :
186(8.9 %)
-
Je ne peux pas utiliser IPv6 à cause de mon FAI, à cause de mon matériel ou parce que j'ai aquaponey. :
465(22.3 %)
Total : 2089 votes
# Cette question n'a pas vraiment de sens...
Posté par Martin Peres (site web personnel) . Évalué à 10.
Euh, presque personne n'est en IPv6-only et ce n'est pas recommandé. Du coup, je pense qu'une question plus pertinente serait:
Comment se passe votre utilisation d'IPv6?
- Je n'en veux pas, IPv4 fait ce que je veux
- Mon fournisseur d'accès ne me donne pas d'IPv6 et je ne veux pas monter de tunnel, j'attend!
- Mon fournisseur d'accès me permet d'utiliser IPv6, mais je l'ai désactivé car ca m'apportait plus de problèmes que de solutions
- Je suis en Dual stack v4-v6: J'ai des problèmes de timeout avec certains sites mais je suis quand même content
- Je suis en Dual stack v4-v6: Tout se passe super
- Je suis en IPv6-only: J'ai des problèmes de timeout avec certains sites mais je suis quand même content
- Je suis en IPv6-only: Tout se passe bien
Et sur ce, je prédis que tous les utilisateurs v6 diront "Je suis en Dual stack v4-v6: J'ai des problèmes de timeout avec certains sites mais je suis quand même content". Et la majorité des autres diront "Mon fournisseur d'accès ne me donne pas d'IPv6 et je ne veux pas monter de tunnel, j'attend!".
[^] # Re: Cette question n'a pas vraiment de sens...
Posté par claudex . Évalué à 6.
Avec un nat64, ça ne pose de problème, ça évite d'avoir du dual stack partout et ça simplifie le réseau interne. Après, il suffit juste d'avoir le point de sortie en dual stack.
« 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: Cette question n'a pas vraiment de sens...
Posté par Martin Peres (site web personnel) . Évalué à 2.
Pas con ca! Merci pour l'info!
[^] # Re: Cette question n'a pas vraiment de sens...
Posté par claudex . Évalué à 4.
Et pour le côté serveur, du mets juste tes frontends en IPv4 et tous les serveurs backends peuvent être en IPv6.
« 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
# Réponses bizarres
Posté par MTux . Évalué à 10.
Heu, j'ai activé IPv6 depuis longtemps et ça cohabite de manière transparente avec IPv4, c'est tout. Je comprends pas trop le sens des réponses du questionnaire…
# Manque de temps, de compétence et aussi...
Posté par Space_e_man (site web personnel) . Évalué à 2.
J’ai dû choisir la dernière option par défaut. J’aurais en effet préféré cocher un radio bouton « J’aimerais bien passer en IPv6 car il serait temps mais je manque de compétence et de temps :( »
Par ailleurs, certaine(s?*) distribution(s) configurent Firefox de manière "pro IPv4" et "incompatible IPv6". Un spécialiste peut-il confirmer et expliquer pourquoi ?
* : Je ne souhaite pas donner de nom. La distrib’ à laquelle je pense est "largement" utilisée. Et je ne sais pas s’il n’y en a pas d’autres ; probablement que oui si l’on considère les dérivés ou variantes. Et finalement, est-ce encore le cas dans les dernières versions ?
[^] # Re: Manque de temps, de compétence et aussi...
Posté par Jiel (site web personnel) . Évalué à 4.
C'est quelle distrib' ? :-D
[^] # Re: Manque de temps, de compétence et aussi...
Posté par Space_e_man (site web personnel) . Évalué à 2.
Tout ce que je peux balancer, c'est le titre du rapport de bogue, Firefox default turns off ipv6
… et aussi la commande pour constater la chose :
…, qui donnerait quelque chose du style :
/etc/skel/.mozilla/firefox/mwad0hks.default/prefs.js:user_pref("network.dns.disableIPv6", true);
Ils disent que ce sera corrigé dans la prochaine version qui sort avant la fin du mois…
[^] # Re: Manque de temps, de compétence et aussi...
Posté par Hobgoblins Master (Mastodon) . Évalué à 4.
C’est quoi cette horreur, je n’avais pas d’opinion sur Mint, après avoir vu ça, je ne suis pas prêt de la tester.
- /etc/skel n’est pas fait pour ça, ça n’impacte que les paramètres à la création de compte, et les modifications (corrections) ne seront pas répercutées.
- Ce paramètre n’est appliqué que sur le profil par défaut à condition que le /home n’ait pas été importé.
- Firefox dispose de tout ce qu’il faut pour appliquer des options par défaut ou forcées côté système – defaultPref() ou LockPref().
- Cette modification semble faire partie d’un package qui n’a strictement rien à voir avec Firefox, mais qui en modifie un paramètre important…
# bon courage !
Posté par Benbben . Évalué à 1.
Est-ce que je suis le seul à avoir déjà essayer de taper une url dans un navigateur, même récent, avec une adresse IpV6 sans nom de domaine ?
Pour ceux qui voudrait essayer les [] sont tes amis ;-)
[^] # Re: bon courage !
Posté par EauFroide . Évalué à 0. Dernière modification le 02 mai 2016 à 12:24.
Dans un de mes conky je vois une connexion active en IPv6 utilisée par Syncthing (avec une autre machine local) et pourtant je n'arrive pas à joindre http://ipv6.monipv6.org ni vraiment à comprendre se que je dois faire pour joindre mon serveur en Ipv4 (fonctionne) et IPv6 ("L'URL n'est pas valide et ne peut être chargée.") si cela est possible (ça doit être possible si je peux joindre apache en Ipv4 alors que la machine discute en Ipv6 avec syncthing, ou alors le conky bug et affiche n'importe quoi)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# Contrôle des IPs internes
Posté par JayPee . Évalué à -8.
J'aurais répondu : "Quand il sera simple de configurer une sorte de NAT et de contrôler ce qui entre et sort de chez à partir d'un seule box" … Et donc de récupérer les fonctionnalités permises par IPV4.
[^] # Re: Contrôle des IPs internes
Posté par EauFroide . Évalué à 2.
Enfaîte un des buts d'IPv6, si je ne me trompe pas, est d'en finir avec les NAT qui ne sont PAS un gage de sécurité contrairement à une idée répandue (ça incite juste les gens à déployer des services locaux (partages et autre) accessible sans password que tout les malwares arrivant sur le réseau local vont aller se dévorer goulûment).
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Contrôle des IPs internes
Posté par jyes . Évalué à 5.
Avoir des permissions plus élevées sur un réseau local que pour le tout venant d’Internet, ça me parait quand-même pas une mauvaise approche de la sécurité. Même si j’ai un mot de passe (enfin une clé) SSH sur mes machines, je ne tiens pas à laisser tous les petits malins du monde tenter une connexion !
Mais le problème n’est pas inhérent à IPv6 (il n’est résolu par le NAT que par necessité due à la limitation du nombre d’IPv4). Il suffirait que les *boxes puissent appliquer des règles de pare-feu sur IPv6 et la sécurité ne serait pas un problème. Le problème c’est surtout que même les opérateurs qui activent l’IPv6 fournissent des *box qui font pare-feu en IPv4 seulement et rares sont ceux qui n’imposent pas leur *box.
Du coup, chez moi IPv6 activé, mais certains services « à risques » sont servis uniquement en IPv4 car je ne veux pas mettre encore un intermédiaire entre le routeur/modem et le réseau. C’est con car IPv6 résout justement pas mal de problèmes qui touchent le rôle de serveur plus que celui de client.
[^] # Re: Contrôle des IPs internes
Posté par EauFroide . Évalué à 1. Dernière modification le 02 mai 2016 à 12:48.
Si tu veux tu peux tester avec un Hidden Service SSH (qui utilise un port aléatoire et joignable seulement depuis Tor).
C'est super facile à configurer, le port n’apparaît même plus lors d'un scan nmap et le serveur ssh ne devient accessible que via l'adresse du Tor hidden Service.
Planquer SSH (pas obligatoire):
sudo nano /etc/ssh/sshd_config
passer "ListenAddress 0.0.0.0" à "ListenAddress 127.0.0.1"
Avec ça le serveur SSH n'est plus accessible/visible que depuis la boucle local 127.0.0.1. (nmap localhost = on voit SSH ; nmap ipServer = on ne voit pas SSH)
Installer l'hidden service :
sudo apt-get install tor
sudo mkdir /var/lib/tor/hidden_service
sudo mkdir /var/lib/tor/hidden_service/ssh
sudo chown debian-tor:root -R /var/lib/tor/hidden_service/
sudo chmod 700 -R /var/lib/tor/hidden_service/
Ajouter l'hidden service :
sudo nano /etc/tor/torrc
et ajouter dedans
HiddenServiceDir /var/lib/tor/hidden_service/ssh
HiddenServicePort 22 127.0.0.1:22
Redémarrer Tor et afficher l'adresse .onion de l'Hidden Service
sudo service tor restart
sudo cat /var/lib/tor/hidden_service/ssh/hostname
Rendre compatible le client :
sudo nano /etc/ssh/ssh_config
Et ajouter dedans :
Host *.onion
ProxyCommand nc -xlocalhost:9050 -X5 %h %p
Note : ça passe à travers les NAT sans problème, par contre quand Internet est inaccessible les Tor Hidden Service ne sont pas joignable.
Source : [Tuto/HowTo] Garder un contrôle discret sur son serveur avec tor et ssh
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Contrôle des IPs internes
Posté par jyes . Évalué à 3.
Merci pour le tuto, c’est vrai que je ne croyais pas les services cachés aussi simples à mettre en place.
Par contre, en matière de sécurité ça ne résout pas du tout le cas que j’exposais. Je ne souhaite pas cacher le fait que j’héberge un service, je souhaite rendre ce service inaccessible à l’extérieur d’un sous-réseau. Le *.onion rend de fait le service accessible depuis le réseau Tor, comme si je l’avais ouvert au tout Internet. Même si ce dernier ne saura pas où il est réellement hébergé, il pourra toujours tenter de s’y connecter.
[^] # Re: Contrôle des IPs internes
Posté par EauFroide . Évalué à 0. Dernière modification le 02 mai 2016 à 14:53.
De rien, au plaisir de participer :)
Oui ils sont aussi très polyvalent avec SSH (ces deux outils se complètent à merveille je trouve :) (genre ça dépanne bien quand tu veux accéder à un VNC sur une machine non exposée à internet par exemple)
Enfaîte : tant que tu ne partages pas l'adresses de ton Hidden Service, personne ne sait qu'il existe (à part le réseau Tor et encore ton HS dois être en ligne pour ça, quand ton HS est hors ligne, il n'existe tout simplement pas).
Et scanner des Hidden Service avec Nmap c'est assez compliqué (voir ici quelques infos que j'ai posté).
Par exemple je n'ai pas encore réussi à faire un scan de plage de port sur un Hidden Service et donc par exemple si tu demandes à se que le client ssh tente de se connecter sur le port 666 (ssh user@hostname.onion:666) au lieu du 22 (même si le serveur ssh tourne sur port 22), un attaquant va vraiment avoir très difficile de le trouver (et même s'il trouve le port ouvert, il faut encore arriver à identifier le dit port).
Ça fait plus d'un an que j'utilise ce système et je n'ai pas encore vu d'attaque dans mes logs (suffit de chercher après des tentatives de connexions depuis 127.0.0.1 avec cat /var/log/auth.log | grep -E '127(.[0-9]{1,3}){3}' )
Il faut se méfier, si je ne m'abuse, dans la vidéos de présentation d'IPv6 de stephane bortzmeyer on y découvre des bugs et autres qui peuvent laisser passer des paquets à travers la box et donc "dés-hermétiser" un sous réseau. Dans ton cas le SSH est protégé donc ca ne te concerne pas, mais c'est la raison pour laquelle par exemple il ne faut pas laisser une camera de surveillance sans password sur un réseau privé.
Petit bonus : La traduction d'adresses (NAT) apporte-t-elle vraiment de la sécurité ?
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Contrôle des IPs internes
Posté par Flyounet (site web personnel) . Évalué à 1.
Et un PortKnocker, c'est pas plus simple ?
[^] # Re: Contrôle des IPs internes
Posté par claudex . Évalué à 10.
Tu veux dire un firewall ? Il n'y a pas besoin de nater pour controler les flux.
« 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: Contrôle des IPs internes
Posté par DerekSagan . Évalué à 1.
Non mais pour ne pas exposer le plan d'adressage interne et l'adresse individuelle de chaque poste de travail, ça reste indispensable.
[^] # Re: Contrôle des IPs internes
Posté par EauFroide . Évalué à -2.
les FAI n'ont pas la possibilité d'attribuer une adresse choisie random dans leur plage lorsqu'un client se connecte au réseau? (puis la remettre en "loterie-accès" dés que le client disconnect) C'est une méthode longtemps utilisée en Belgique avec IPv4 et pour la vie privé c'est pas mal. (je sais pas si c'est encore d'actualité)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Contrôle des IPs internes
Posté par Sacha Trémoureux (site web personnel) . Évalué à 2.
En IPv6, les OS clients — quand un serveur DHCPv6 est fourni par le routeur — peuvent choisir une IP random au sein du /64 disponible sur la gateway si je ne dis pas de bêtise.
[^] # Re: Contrôle des IPs internes
Posté par EauFroide . Évalué à 0. Dernière modification le 02 mai 2016 à 17:08.
Est-ce que ça attribue X quantité d'IPv6 au routeur familial qu'il dispatche random à ses clients (pas cool) ou a-t-on une IP random au milieu de toutes les IPv6 du FAI (cool)?
Si c'est la première version : a-t-on X quantité d'IPv6 qui sont renouvelées tout les X temps ou lors du redémarrage du routeur ou alors les IPv6 attribuées la première fois sont-elles définitive?
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Contrôle des IPs internes
Posté par johan.cb . Évalué à 2. Dernière modification le 02 mai 2016 à 17:28.
Tu as un préfixe \64 pour tout ton réseau.
À partir de là ton linux va te générer une adresse IPv6 construite avec ton adresse MAC ainsi qu'une adresse anonyme et dynamique si tu as coché l'option.
EDIT : Firefox et autres logiciels utiliseront par défaut l'adresse dynamique.
[^] # Re: Contrôle des IPs internes
Posté par DerekSagan . Évalué à -1.
L'adresse IPv6 faite avec l'adresse MAC s'appelle link local n'est pas routable sur Internet.
Firefox ne peut utiliser l'adresse link local s'il le veut vraiment que pour parler sur le réseau local, pour aller sur Internet il ne peut pas.
https://en.wikipedia.org/wiki/Link-local_address
Quant à qualifier l'adresse dynamique d'anonyme… comment te dire… elle commence par ton préfixe /64 perso que t'a attribué ton FAI…
[^] # Re: Contrôle des IPs internes
Posté par briaeros007 . Évalué à 6.
euh non…
Il y a deux adresses qui sont construites avec les adresses mac.
L'adresse link-local, qui n'est visible que sur le réseau physique, et les adresses stateless, qui sont visibles sur le tout le net, et qui sont construites à partir
- du préfixe récupéré par le biais du neighbour protcole/routeur discovery
- de l'adresse mac
- de la chaine FFFE.
[^] # Re: Contrôle des IPs internes
Posté par Antoine . Évalué à 3.
Cette discussion montre bien à quel point IPv6 est plus difficilement compréhensible pour l'utilisateur final.
IPv4 : c'est simple, chaque interface a une adresse (par défaut), point. IPv6 : j'ai trois adresses différentes sur la même interface…
[^] # Re: Contrôle des IPs internes
Posté par johan.cb . Évalué à 1. Dernière modification le 02 mai 2016 à 21:05.
Les adresses globales ainsi que locales sont dans un premier temps générées à partir de ton adresse MAC.
Les adresses globales peuvent ensuite être dynamiques, tout comme les locales d'ailleurs.
Par contre effectivement ton préfixe sera, lui, toujours le même. Bien que le réseau de l'utilisateur soit ainsi indentifiable, l'utilisateur précis lui ne l'est pas.
EDIT : je vérifie bien chez moi que l'adresse dynamique est utilisée par Firefox et non pas la permanente générée depuis la MAC.
[^] # Re: Contrôle des IPs internes
Posté par Sacha Trémoureux (site web personnel) . Évalué à 3.
Bon, j'allais forcément dire des bêtises.
C'est pas lié au DHCPv6, c'est bien le SLAAC et en particulier les privacy extensions.
En plus de l'IP liée à l'adresse MAC, une adresse est générée aléatoirement et régulièrement par le client.
Le préfixe /64 change lui en fonction du bon vouloir du FAI. Il peut très bien être fixe.
[^] # Re: Contrôle des IPs internes
Posté par DerekSagan . Évalué à 4.
Et l'adresse IPv6 liée à l'adresse MAC est link local, c'est-à-dire qu'elle n'est pas routée sur Internet, donc pour la sécurité / vie privée on peut l'oublier.
Quant au /64, à ma connaissance tous les FAI français offrant l'IPv6 le fournissent en fixe.
Ce qui n'est pas étonnant, la rotation des IPv4 était historiquement surtout faite pour les mettre en commun: à chaque connexion d'un modem on lui donner une adresse dans le pool et il y en avait moins que d'abonnés, ça perdure encore sur certains abonnements ADSL mais à le sens de l'histoire allant vers la connexion permanente, l'IP fixe (v4 ou /64 v6) devrait devenir de plus en plus dominante.
Après, même en configurant le DHCP local pour donner des adresses random au sein du /64 (encore faut-il que la box - en général c'est elle qui fait le dhcp - le propose), on expose quand même l'IP de chaque PC/device même si elle n'est pas fixe.
Au moindre trou de sécurité dans le firewall on peut attaquer directement un PC/device précis.
Et aucune box française ne propose de firewall IPv6 aujourd'hui (pour un trou c'est un trou).
Et les 264 adresses pour chaque abonné, c'est une incitation à donner une adresse IP à chaque ampoule électrique, laquelle sera difficile à patcher et donc facile à pirater, pour éteindre la lumière ou pour rebondir sur le réseau ailleurs (lire https://fr.wikipedia.org/wiki/Machine_zombie et penser à une ampoule IPv6).
Bref IPv6 c'est bien mais l'écosystème technologique grand public n'est pas encore sec. Mais comme LinuxFR c'est pas le grand public mais l'avant-garde, on peut y aller. :)
[^] # Re: Contrôle des IPs internes
Posté par Thibault (site web personnel) . Évalué à 2.
Ce n'est pas la seule qui peut contenir la MAC. L'adresse générée par le nœud dans le cas de l'auto configuration (Stateless Address Autoconfiguration) contient le préfixe annoncé par le routeur et le host identifier peut dériver de l'adresse MAC. Et cette adresse est une adresse routée sur Internet (global unicast).
Il est possible de construire une seconde adresse "global unicast" (qui peut être temporaire) avec un host id aléatoire qui sera taguée "préférée" (et donc qui sera utilisée pour faire sortir les paquets des processus locaux qui ne précisent pas laquelle des deux IP global unicast utiliser).
[^] # Re: Contrôle des IPs internes
Posté par EauFroide . Évalué à -1.
Merci pour cette explication.
J'espère que non et que Belgacom (et les autres s'il y en a, ce n'est pas le cas de Voo second FAI belge) conservera sa politique d'adresse IP dynamique. On va maintenair la pression pour :D
Si non tout transitera par Tor même la moindre petite ampoule mdr (ou alors l'IPv4 continuera de fonctionner en interne mais le tout exposer avec IPv6 statique, j'en veux pas non plus mdr)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Contrôle des IPs internes
Posté par johan.cb . Évalué à -1. Dernière modification le 02 mai 2016 à 21:15.
Ton ou tes IPv6 fixes ne sont théoriquement pas utilisées sur l'Internet si les applications font correctement leur boulot (Firefox le fait correctement). Elles servent à avoir un moyen fixe de te joindre de l'extérieur ce qui est plutôt pas mal.
Et d'ici à ce que quelqu'un ou un robot ait analysé toute la plage de ton \64 tu auras probablement même changé de carte réseau…
Petite précision tout de même : le DHCP n'est plus utilisé en v6 si je ne me trompe pas. Ça fonctionnerait mais en tout cas ce n'est pas la méthode recommandée. Sauf ton modem qui reçoit justement son \64 en DHCPv6.
[^] # Re: Contrôle des IPs internes
Posté par EauFroide . Évalué à 1. Dernière modification le 02 mai 2016 à 21:33.
Admettons que je sois le défunt Megavidéos et que tu sois un de ces horribles belges qui, arrivé à la limite du temps de mattage de vidéos autorisé par jour, supprime ses cookies et change d'IPv4, renouvelant ainsi son identité et s'octroyant ainsi de nouvelle minutes de vidéos gratuite, plus tôt qu'acheter un abonnement.
Ben avec un /64 statique c'est fini cette racaille néo-germano-latine: il suffit de bloquer toute la plage :P
J'ai juste?
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Contrôle des IPs internes
Posté par johan.cb . Évalué à 1.
Si c'est utilisé en pratique je ne pourrai pas te le dire, mais en soit, oui ça pourrait être le cas :)
Après les avantages d'IPv6 ne sont plus à démontrer même si dans ce cas précis ça n'est pas idéale pour toi (mais pas pire qu'une IPv4 statique !).
[^] # Re: Contrôle des IPs internes
Posté par EauFroide . Évalué à -1. Dernière modification le 02 mai 2016 à 22:10.
J'ai grandis en apprennent a avoir une peur bleu de cette horreur ^ ^
Dans les MMORTS les joueurs top 100 et les chefs d'alliances ayant des IP statiques se faisaient (font toujours) souvent DDOS afin de bloquer des teams en pleine opération.
Les streameurs twitch qui jouent au RPG se plaignent d'ailleurs souvent de se faire DDOS (faute a leur IP statique).
Enfaîte, si j'ai bien compris, le problème ne vient pas d'IPv6 mais bien de l'attribution d'une plage d'IPv6 statique. Un bon FAI pourrait fournir des plages dynamiques renouvelées par exemple lors d'un reset de la box.
Si les plages statiques deviennent la norme, va falloir hacker les routeurs libre (afin de rajouter une option login/password tournant avec d'autres abonnés du FAI afin d'échanger les plages à l'insu du FAI) et n'utiliser que ces routeurs :P
PS: supprimer cookie et changer d'ip ça casse aussi l'espionnage de google (il se sent tout perdu le petit :P)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Contrôle des IPs internes
Posté par johan.cb . Évalué à 3.
Pour ton premier exemple de l'attaque DDOS, rien ne t'empêche de changer d'IPv6 toutes les quelques heures. Tu peux même prévoir le coup et attribuer 100 000 IPv6 à ta carte réseau si tu en as envie !
La seule chose qui ne changera pas est ton préfixe et à ma connaissance une attaque DDOS sur un préfixe n'est pas possible. Merci de me corriger si je me trompe par rapport à ce point !
Tu serais en fait moins emmerdé avec IPv6 dans ce cas qu'avec IPv4.
Concernant le partie sur les FAI, on dit en général d'un FAI qui attribue des préfixe IPv6 dynamiques qu'il est « mauvais », c'est ce que Orange fait en ce moment, mais il est prévu de basculer le tout en statique.
PS : avec une IP différente générée chaque fois que ton interface s'initialise, Google n'y voit que du feu également ! Bien sûr ici le préfixe restant le même, on ferait toujours le rapprochement avec ton préfixe, mais pas avec l'utilisateur !
[^] # Re: Contrôle des IPs internes
Posté par EauFroide . Évalué à -2. Dernière modification le 02 mai 2016 à 23:55.
Ben bêtement si le prefix = un abonné (à la limite une famille mais bon, au pire ça fait 8 utilisateurs), google n'a guère plus de difficultés a identifier toute ta plage IPv6 statique qu'une simple IPv4 statique.
B.Bayart faisait une même remarque pour IPv4 et ça me faisait toujours rire quand il disait que nous, belge, n'avions pas d'internet à cause de nos IP dynamique (100% des joueurs que j'ai rencontré qui ont subit de (lourdes) pertes dans des MMORTS suites a des DDOS, s'étaient toujours des français avec ip statiques ^ ^ )
Le dynamique à partir du moment où on a pigé le fonctionnement c'est comme le distribué, c'est très difficile d'abandonner :) (enfaîte je ne vois vraiment plus l’intérêt des plages/ip statiques ^ ^ )
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Contrôle des IPs internes
Posté par jnanar (site web personnel) . Évalué à 5.
Personnellement, pour subir une IP dynamique depuis des années, je préférerais largement avoir une IP statique. Ça facilite l'auto-hébergement. Pour le moment (à ma connaissance), il est impossible d'héberger son mail, d'avoir un certificat qui n'alerte pas le navigateur ou d'avoir un nom de domaine qui ne soit pas un équivalent d'un produit noip. Pire,la box v3 de proximus (le FAI le plus connu) est buggée et empêche d'héberger un serveur accessible de l'extérieur. Il y a de nombreux postes de joueurs qui ne peuvent plus joueur en ligne avec leur PlayStation 4. Visiblement, elle nécessite l'ouverture de ports sur le routeur. Donc oui, l'ipv6 apporte quelque chose mais il faut que ce soit bien implémenté et de manière générale, une IP statique est pratique si on veut bidouiller.
[^] # Re: Contrôle des IPs internes
Posté par EauFroide . Évalué à -2. Dernière modification le 03 mai 2016 à 13:15.
Si tu veux une IP statique tu peux la demander à Proximus (belgacom) ou bien aller chez Voo (ils ont de bonnes connexions mais je les évites à cause de leurs IP(v6) statiques justement ^ ^ (genre mes potes chez voo se plaignent de ne pas pouvoir profiter de l'astuce que j'ai énoncé avec les lecteurs vidéos et qui fonctionne avec d'autres trucs (les jeux Blizzard entre autre)) )
Elle est buggée où elle suit le même schéma que la BBOX 2 ?
La BBOX 2 par défaut bloque en entrée les port 23, 80 et 443, mais il suffit de suivre ce tuto pour les ouvrir
Boaf j'ai des dynamiques depuis qu'internet existe en Belgique et je bidouille depuis ce temps ^ ^
Justement, à chaque fois que je me suis fait bloqué des IP par google pour "requêtes étranges", au lieu de râler en attendant un dé-ban (qui peut prendre du temps) il m'a à chaque fois suffit de reset le routeur ^ ^
Oui et non. Ça rend ton service facilement retrouvable pour les clients (et encore, tu veux vraiment leur demander de taper une IP en barre d'URL?), autant que pour les pirates.
Actuellement j'utilise un système d'ip dynamique + DDNS, si on tente de me DDOS j'ai juste à changer d'adresse IP et temporairement stopper les DDNS et toute mon infra reste accessible via les portes cachées (Tor, Proxy, etc) sans être perturbée par l'attaque qui viserait les hostname connu :)
Note que ce point est une erreur : rien ne t'empêche prendre un nom de domaine et de faire signer le certificat TLS lié, ainsi il n'y aura pas de message d'alerte de sécurité.
Ensuite tu tape un auto-exploit juste pour démontrer a Mozzila que leur alerte de sécurité est bidon ^ ^
Ce n'est pas lié a l'IP dynamique (tu peux utiliser un nom de domaine encore une fois) mais au module anti-spam des FAI et au fait que les fournisseurs principaux de services mails peuvent te considérer comme un spam et te bloquer.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Contrôle des IPs internes
Posté par jnanar (site web personnel) . Évalué à 2. Dernière modification le 03 mai 2016 à 19:49.
D'après ce que je lis, Proximus ne propose des IP statiques que pour les offres pro qui sont excessivement chères. Tu as un lien vers cette info?
C'est un bug. Les ports sont évidemment ouverts, la procédure que tu cites est suivie mais le routage vers la machine locale ne fonctionne pas.
Moi aussi je bidouille mais certaines choses sont plus compliquées avec une ip dynamique. Si ces requêtes proviennent de ta machine, le fait que tu aies une ip dynamique n'y change rien. Je ne comprends pas l'intérêt de cet argument, mis à part une période de ban limitée si tu envoies n'importe quoi sur le réseau (est-ce un avantage?).
On a inventé les noms de domaine pour ça ;-). L'intérêt d'une IP fixe est de pouvoir avoir un nom de domaine "normal" et pas un nom de domaine en noip ou dyndns "moins sérieux".
Pour ce qui est des attaques, il suffit de mettre en place fail2ban. Vu le nombre de scans et de script kiddies qui essayent de faire tomber mon serveur domestique, une IP dynamique ne protège absolument pas des attaques.
Faire pointer un nom de domaine vers un domaine dyndns me semble contre productif. Les caches des serveurs DNS mettent plusieurs heures à se synchroniser. Faire ça revient à avoir son nom de domaine indisponible tous les trois jours…
Ça revient au même. Et étant donné que des plages entières d'IP chez OVH sont considérées comme du spam malgré SPF+ADSP+DMARC (cf ici), héberger ça sur une IP dynamique ne facilitera pas la tâche. Surtout si une IP met plusieurs semaines à sortir des listes noires…
Bref, je ne suis toujours pas convaincu de l'intérêt d'une IP dynamique mis à part ton cas particulier où cela t'évite de perdre à ton jeu. Note que tu pourrais résoudre ton problème avec une règle fail2ban en t'épargnant le reboot du routeur.
[^] # Re: Contrôle des IPs internes
Posté par EauFroide . Évalué à -1.
Non, c'est dixit leur FAV quand je les interrogé à propos du risque de voir débarquer des ip statiques quand IPv6 viendrait à débarquer (je venais de voir une vidéos de B.Bayart qui m'avait fait peur ^ ^ ). L'anecdote est qu'ils n'ont … … … pas su me répondre. ^ ^
Je suis étonné que les fournisseurs de nom de domaine ne sont pas tous compatible avec IP dynamique.
Tu peux aussi résoudre ce problème simplement en utilisant un reverse proxy sur une IP statique. :) (j'utilise ce mécanisme pour donner aux users l'impression que "tout est en un" alors que c'est disséminé sur X machines pas toujours sur le même réseaux)
Je parle des DDOS, hélas trop populaire actuellement sur le net. Si demain un million de zombie plombe une IP statique bah POUF y a plus, sur une IP dynamique suffit de renouveler et de matter les zombies se gourrer de cible :P
Pour les attaques automatisées ça ne changera rien je pense (un raspberry pi à 30€ peut scanner combien d'IP à la minutes?).
L'ip ne change que lors d'une déconnexion-reconnexion du routeur ;) généralement, à part coupure de courant, on garde la même sauf si on reboot le routeur :)
J’ai pas dis que s’était plus facile, j'ai dis que ça ne changeait rien (entre utiliser netlib.re + ip dynamique ou ip statique, la manip est pareil).
On notera que Retroshare fournit un service mail (pour user retroshare uniquement bien entendu) qui fonctionne en distribué sur IP statique/dynamique, avec full chiffrement obligatoire et le tout sans strictement rien devoir configurer ^ ^
PS : je ne suis mais alors pas du tout contre le principe d'ip/plage statique. Je suis contre l'obligation de s'en taper si on ne l'a pas demandé. :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Contrôle des IPs internes
Posté par InstallGentoo . Évalué à 3.
Et bien en fait chez Orange pour les abonnés qui ont la chance d'avoir IPv6 (pour le moment ceux qui ont la fibre et le VDSL il me semble) il y a bel et bien un firewall IPv6, très simple à configurer d'ailleurs. En revanche perso je trouve que c'est plutôt dommage car pour les machines clientes IPv6 aurait permis de faire du pair à pair qui Juste Marche et donc de lutter contre l'hyper-centralisation actuelle sur des services privateurs. Surtout qu'il est plus souple et plus efficace d'avoir un pare-feu au niveau de la machine AHMA
[^] # Re: Contrôle des IPs internes
Posté par claudex . Évalué à 3.
Du coup, tu parles plus d'un setup d'entreprise (parce qu'en privé, avec les privacy extension, l'adresse change régulièrement). Et là, tu utiliseras un proxy pour communiquer avec l'extérieur (comme en IPv4), tu ne vas pas exposer grand chose. Mais ça te laisse justement l'occasion de pouvoir adresse les machines directement pour certaines applications (comme la VoIP) mais pas pour le reste. Parce que quand tu as les couches de NAT qui s'empilent, ça devient vite difficile à débugger.
« 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: Contrôle des IPs internes
Posté par johan.cb . Évalué à 0.
En théorie avec un bon pare-feu avec de bonnes règles le proxy ne devrait même pas être utile.
Mais la plupart des pares-feu actuels (conf de Stéphane Bortzmeyer citée dans un commentaire plus haut je crois) ou du moins une grande partie ne sont pas encore totalement prêts.
[^] # Re: Contrôle des IPs internes
Posté par claudex . Évalué à 3.
Si, un bon pare-feu ne fait pas de MitM. Un proxy peut faire un joli 403 quand on tente de se connecter à un domaine interdit (car vérolé par exemple), même avec du HTTPS (le CONNNECT donne le nom de domaine, pas le path).
« 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
# Un MOOC sur IPv6
Posté par Bruno Stévant (site web personnel) . Évalué à 6.
Bonjour,
Je vous signale au passage qu'en ce moment un MOOC (cours en ligne massivement ouvert) sur IPv6 se joue sur la plateforme France Université Numérique.
Disclaimer: je suis l'un des intervenants ;)
Au programme : des cours en vidéo, un support en licence CC et des TPs pour manipuler IPv6 notamment sous Linux.
Disclaimer 2: nous n'utilisons pas les services de ProctorU, donc pas la peine de nous rappeler le problème des conditions d'utilisation de leur service ;)
# Quand est-ce que Free proposera de l'IPv6 ?
Posté par Vincent Danjean . Évalué à 0.
Le titre est un peu provocateur, mais je suis sidéré par ce qui est proposé par Free (et je ne suis pas certain que les autres FAI grand public fassent mieux mais je n'ai pas creusé). FDN et autres FAI locaux associatifs sont généralement mieux par contre.
Free semble être l'un des derniers FAI français grand public à proposer une configuration de sa box en pont (y compris en IPv4). Pour moi, c'est vraiment important. Je ne fais pas que du TCP et UDP sur ma connexion IP. Or, en mode routeur (le défaut mais surtout le seul mode sur plein de box), on a nécessairement du NAT et uniquement TCP et UDP :-( Or, quand je loue une connexion Internet, c'est pour avoir une IPv4 avec laquelle je fais ce que je veux.
Pour IPv6, la solution proposée par Free est horrible : on a certes un /64, mais
Conséquence, soit on oublie l'autoconfiguration IPv6 et on se lance dans des configurations très complexes, soit on a un réseau IPv6 plat ouvert sur l'Internet :-((((
En pratique, chez moi, j'ai trois fournisseurs IPv6 :
Le seul "problème", c'est que SixXS et Hurrican doivent être encapsulés dans du IPv4 jusqu'à leurs équipements.
Quand on dit qu'un /64 c'est beaucoup, et bien non, en IPv6, c'est peu. C'est un seul sous-réseau IPv6 si on veut utiliser l'autoconfiguration. Or, chez moi, j'ai plusieurs réseaux séparés. Mon réseau filaire et mes deux réseaux wifi (WEP pour les invités de passage, WPA pour mes mobiles/portables) sont séparés avec des règles de firewall différentes. Je veux la même sécurité en IPv6. L'offre de Free ne le permet pas du tout.
Et pourtant, ça ne semble pas compliqué. Si on reprend Free, il "suffit" de donner un /60 (par exemple) au lieu du /64 avec, pour ces 16 sous-réseaux :
Mais non, Free fait de la pub avec son "support" IPv6 alors qu'en pratique c'est inutilisable sauf cas très basiques (ou au contraire complexes avec mise en place de DHCPv6 mais aussi de NAT IPv6 car le routeur de Free s'attend à trouver toutes les machines sur un seul segment ethernet, sans routage supplémentaire)
[^] # Re: Quand est-ce que Free proposera de l'IPv6 ?
Posté par KiKouN . Évalué à 4.
Plein toi, sur certaines box ont ne peut même pas définir de route pour les réseaux locaux en IPv4.
Le problème des box, c'est que ce ne sont pas de vrais routeurs et que le mode bridge fait perdre des fonctionnalités.
[^] # Re: Quand est-ce que Free proposera de l'IPv6 ?
Posté par Hobgoblins Master (Mastodon) . Évalué à 6.
C’est complètement faux, Free fournit un /61 (8 /64 utilisables ce qui est peu mais suffisant pour beaucoup de cas), avec une Freebox (V6, je n’ai pas testé la V5) en mode bridge, dans les paramètres IPv6, cocher la case « activer IPv6 » et entrer l’adresse link-local du routeur firewall. Côté LAN de ton routeur, tu peux utiliser SLAAC sans problèmes.
Il me semble qu’avec une Freebox V5 en mode bridge, il était possible de désactiver IPv6 dans les paramètres de la box et de négocier le 6rd depuis le routeur derrière, c’est peut-être toujours d’actualité…
[^] # Re: Quand est-ce que Free proposera de l'IPv6 ?
Posté par Samuel Thibault (site web personnel) . Évalué à 1.
Mais par contre il n'y a toujours pas de firewall v6 dans la freebox. Ça je trouve ça fou. Qu'ils rendent le firewall optionnel, ça serait effectivement utile, mais par défaut il vaut mieux mettre un firewall sinon c'est un énorme trou…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.