Auteur Sujet: IPv6 pour LaFibre.info ce 1er janvier 2016  (Lu 142876 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
IPv6 pour LaFibre.info ce 1er janvier 2016
« Réponse #120 le: 07 janvier 2016 à 16:13:08 »
oui c'est comme la mauvaise foi ou admettre qu'on s'est trompé, ca n'existe pas aussi.
Chez toi, non ça n'existe pas en effet.

corrector

  • Invité
IPv6 pour LaFibre.info ce 1er janvier 2016
« Réponse #121 le: 07 janvier 2016 à 16:15:33 »
"hum, plus foireuse que ca analogie pas possible être"...
mékilékon

ca sera peut-etre l'occasion pour les fabricants de box de jeter Linux et d'utiliser BSD et IPFW  ;D
Que fait "IPFW" face à un protocole qu'il ne reconnait pas?

ou pas car iptables supporte déja n'importe quel numéro de protocol (option -p). Faut juste qu'ils adaptent leur UI.
Et donc, que doit faire un pare-feu face à un protocole qu'il ne connait pas?

Darklight

  • Abonné Free adsl
  • *
  • Messages: 648
  • Free non-dégroupé (77)
IPv6 pour LaFibre.info ce 1er janvier 2016
« Réponse #122 le: 07 janvier 2016 à 19:26:04 »
Citation de: corrector
Encore une fois, une classe A soit un /8 c'est >1 ‰ de l'espace total d'adressage, attribué à une seule entité.

Mathématiquement il est évident que cela représente peu mais c'est quand même une ressource rare maintenant, un /8 serait apprécié par n'importe quel opérateur qui se replie en CG-NAT ou équivalent pour assurer sa survie en IPv4. En v6 ce sont les RFC qui nous poussent à avoir besoin des /56 pour un réseau complet, en maths l'ordre de grandeur ne fait plus beaucoup de différence avec un /64, les deux sont énormes!

Citation de: Darklight
Le seul inconvénient est qu'il faut maintenant compter en puissance de dix
Citation de: corrector
Non, en puissance en 16!
Pas d'accord, quand on compte le nombre d'IP, on les compte avec des chiffres donc en base 10, ainsi des puissances de 10 sont plus pratiques pour les yeux ^^

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
IPv6 pour LaFibre.info ce 1er janvier 2016
« Réponse #123 le: 07 janvier 2016 à 20:18:56 »
Que fait "IPFW" face à un protocole qu'il ne reconnait pas?
Et donc, que doit faire un pare-feu face à un protocole qu'il ne connait pas?

Il laisse passer ou pas. Le but c'est de pouvoir créer un règle qui laisse passer ou pas un protocol qui n'est pas udp ou tcp.

L'aspect 'connaitre' le protocol est un raffinement qui n'est pas forcement nécessaire, d'autant qu'on ne fait pas de NAT.

En sortie:

En udp et tcp on track un quintuplet (proto, ip source, port source, ip dest, port dest) car cela offre plus de sécurité et ca permet de fonctionner en tandem avec un NAT.

Avec n'importe quel protocol on peut juste tracker un triplet [proto, ip source, ip dest]. Meme avec UDP et TCP d'ailleurs, si on n'a pas de NAT on peut simplifier le firewall et juste tracker [proto, ip source, ip dest]: on sait que source a chercher a joindre dest et on laisse passer si y'a une règle qui le permet et le retour aussi si cette règle est statefull et on ignore complètement les n° ports.

Apres rien n'empeche de faire des firewall plus 'customisables' ou programmables pour entrer plus dans les détails d'un protocol inconnu mais cela aura un coût en performance et en complexité.

De toute facon un protocol n'a pas forcement de numéro de port, c'est un concept propre au protocol lui-meme.

En entrée:

en regles entrantes c'est pareil (ce qu'on appelle a confusion "ouverture de port" en IPv4).
TCP et UDP servent a tellement d'usages que firewaller aussi le numéro de port a son importance. 
En IPv6 on peut aussi oublier les ports: on peut utiliser une IP par service par exemple.

ex:
en IPv4 on va ouvrir sur le firewall le port TCP 80 vers un serveur web interne car si on n'ouvre tout TCP et pas que TCP port 80 ca expose tout les services TCP du serveur ce qui n'est pas forcement bon (donc le firewall doit connaitre TCP et savoir ou est le numéro de port dans le paquet). En IPv6 on peut faire pareil et on va faire pareil le plus souvent (par habitude principalement).
Mais on peut faire différent: le serveur a plusieurs IPv6 et une seul est utilisée pour le service Web a destination de l’extérieur.
Dans ce cas ouvrir dans le firewall que cette IP avec TCP complet ne pose pas vraiment plus de probleme et en plus ca rend le firewall plus efficace (il check un triplet au lieu d'un quintuplet). on pourrait meme ouvrir tout les protos pour cette IP en fait, c'est encore plus simple.
L'idée est qu'on a tellement d'adresses dispos qu'on peut s'en servir aussi pour faire de la sécurité.
bref faut pas raisonner comme en IPv4 encore une fois.

Darklight

  • Abonné Free adsl
  • *
  • Messages: 648
  • Free non-dégroupé (77)
IPv6 pour LaFibre.info ce 1er janvier 2016
« Réponse #124 le: 07 janvier 2016 à 20:51:46 »
Citer
Mais on peut faire différent: le serveur a plusieurs IPv6 et une seul est utilisée pour le service Web a destination de l’extérieur.
Dans ce cas ouvrir dans le firewall que cette IP avec TCP complet ne pose pas vraiment plus de probleme et en plus ca rend le firewall plus efficace (il check un triplet au lieu d'un quintuplet). on pourrait meme ouvrir tout les protos pour cette IP en fait, c'est encore plus simple.
Le seul problème intrinsèque aux ports écoutés sur un serveur c'est que ça retire une sécurité qu'IPv4 contraignait à répondre par le manque d'adresses, si l'OS est compromis dans le cas d'une faille ou d'une négligence en sécurité, autoriser tous les ports TCP d'une IP ça expose entre autres les services TCP écoutants sur toutes les IP du serveur, et aux ports additionnels lancés par un logiciel tiers/espion qu'on maîtrise pas.

Mais ça simplifie l'administration, et la gestion de plusieurs sites web est aisée, mais je pense qu'en TCP il est incontournable de garder les ports dans le firewall.

La logique voudrait que le serveur soit parfaitement configuré avec les services inaccessibles de l'extérieur écoutant sur ::1,  mais c'est pas toujours le cas.

butler_fr

  • Client Bbox adsl
  • Modérateur
  • *
  • Messages: 3 605
  • FTTH orange
IPv6 pour LaFibre.info ce 1er janvier 2016
« Réponse #125 le: 07 janvier 2016 à 21:01:01 »
Bon moi je suis un peu à la bourre mais

je vous souhaite à tous une très bonne année!

super le forum en ipv6!   :)

longue vie à lafibre.info!

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
IPv6 pour LaFibre.info ce 1er janvier 2016
« Réponse #126 le: 07 janvier 2016 à 21:34:41 »
Le seul problème intrinsèque aux ports écoutés sur un serveur c'est que ça retire une sécurité qu'IPv4 contraignait à répondre par le manque d'adresses, si l'OS est compromis dans le cas d'une faille ou d'une négligence en sécurité, autoriser tous les ports TCP d'une IP ça expose entre autres les services TCP écoutants sur toutes les IP du serveur, et aux ports additionnels lancés par un logiciel tiers/espion qu'on maîtrise pas.

Mais ça simplifie l'administration, et la gestion de plusieurs sites web est aisée, mais je pense qu'en TCP il est incontournable de garder les ports dans le firewall.

La logique voudrait que le serveur soit parfaitement configuré avec les services inaccessibles de l'extérieur écoutant sur ::1,  mais c'est pas toujours le cas.

Je ne comprend pas bien ton exemple. si l'OS est compromis c'est cuit de toute façon...
en quoi exposer tout TCP sur une IP, expose les autres IP ? ou tu parles d'exposer en sortie du firewall (aka empêcher de sortir) ?

Perso je ne crois pas qu'il soit incontournable de garder les ports dans le firewall.
J'imagine l'avenir comme une histoire d'IP et oui/non on laisse passer, quelque soit le protocol et les ports. C'est tellement plus simple et universel.
Bien sur, je peux complètement me tromper d'autant qu'on va se trainer IPv4 un bon moment...

Mais je vois ca déjà apparaître du coté développeur ou la forte tendance est  a l'isolation en 'container' (facon Docker).
Avec IPv6 ca colle parfaitement en plus.
Je ne serais pas surpris dans quelques années de voir se généraliser cela a tout, y compris les OS desktop, les objets connectés, les box, etc.
un container = une application = une IP (ou meme plusieurs). L'isolation port/proto se faire a la frontière du container.
Sécurité simplifiée partout. on crypte toutes les comms en plus. les firewalls si il en reste n'auront qu'a filter sur les IP entre elles et rien d'autre.
et il n'y a qu'IPv6 pour rendre cela possible vu le nombres d'adresses que cela va demander.

On peut déjà expérimenter cela en desktop d'ailleurs. Sur Linux on peut facilement faire tourner Chrome dans un container (voir des exemples ici https://blog.jessfraz.com/post/docker-containers-on-the-desktop/ ou la directement ) et meme:  container(chrome) -> linux(vm virtual box) -> Windows(host+serveur x11). Si on a IPv6, le Chrome dans le container peut avoir sa propre IP (qui peut être également être dans un autre /64 si le host sait faire de la délégation de prefix ...donc filer un /56 a du grand public a du sens pour l'avenir. un 'PC' pourrait requérir un /60 par exemple).
Meme Microsoft s'y met, coté serveur en 2016 pour le moment mais ca vient.

Darklight

  • Abonné Free adsl
  • *
  • Messages: 648
  • Free non-dégroupé (77)
IPv6 pour LaFibre.info ce 1er janvier 2016
« Réponse #127 le: 07 janvier 2016 à 22:18:41 »
Non je parle du fait que sur les serveurs (ou ordinateurs) il y a parfois besoin pour des applications d'écouter sur un port et non sur une IP spécifique, surtout pour des solutions propriétaires comme Windows où un firewall reste indispensable. Donc toutes les IP attribuées à une carte réseau du même serveur peuvent écouter le même port, tandis qu'un firewall permet de centraliser la gestion réseau et les ports, il faudrait le faire au cas pas cas sur les applications et c'est pas tout le temps possible.

par ailleurs même si une machine est compromise, laissons le moins de manœuvre possible aux attaquants.

corrector

  • Invité
IPv6 pour LaFibre.info ce 1er janvier 2016
« Réponse #128 le: 08 janvier 2016 à 05:53:07 »
Il laisse passer ou pas. Le but c'est de pouvoir créer un règle qui laisse passer ou pas un protocol qui n'est pas udp ou tcp.
OK maintenant je comprends.

L'aspect 'connaitre' le protocol est un raffinement qui n'est pas forcement nécessaire, d'autant qu'on ne fait pas de NAT.
Je n'avais pas envisagé une seconde que le "besoin" (ou désir) de filtrage ne soit pas lié à un besoin de filtrer sur les ports.

En sortie:

En udp et tcp on track un quintuplet (proto, ip source, port source, ip dest, port dest) car cela offre plus de sécurité et ca permet de fonctionner en tandem avec un NAT.
(proto, ip source, port source) permet aussi de faire du SNAT, netfilter gère ça aussi. Ce qui veut dire que tu dois pouvoir ça via la Freebox par exemple en 6in4 (je n'ai pas testé).

http://lxr.free-electrons.com/source/net/netfilter/nf_nat_proto_unknown.c

C'est un SNAT très limité, évidemment :

28 static void unknown_unique_tuple(const struct nf_nat_l3proto *l3proto,
 29                                  struct nf_conntrack_tuple *tuple,
 30                                  const struct nf_nat_range *range,
 31                                  enum nf_nat_manip_type maniptype,
 32                                  const struct nf_conn *ct)
 33 {
 34         /* Sorry: we can't help you; if it's not unique, we can't frob
 35          * anything.
 36          */
 37         return;
 38 }

Avec n'importe quel protocol on peut juste tracker un triplet [proto, ip source, ip dest].
Ce que fait conntrack :

34 static bool generic_pkt_to_tuple(const struct sk_buff *skb, unsigned int nhoff,
 35                                  struct nf_conntrack_tuple *tuple)
 36 {
 37         memset(&tuple->src.u3, 0, sizeof(tuple->src.u3));
 38         memset(&tuple->dst.u3, 0, sizeof(tuple->dst.u3));
 39
 40         return true;
 41 }
Pas de numéros de port connus => données à 0

http://lxr.free-electrons.com/source/net/netfilter/nf_conntrack_l3proto_generic.c

Meme avec UDP et TCP d'ailleurs, si on n'a pas de NAT on peut simplifier le firewall et juste tracker [proto, ip source, ip dest]: on sait que source a chercher a joindre dest et on laisse passer si y'a une règle qui le permet et le retour aussi si cette règle est statefull et on ignore complètement les n° ports.

Apres rien n'empeche de faire des firewall plus 'customisables' ou programmables pour entrer plus dans les détails d'un protocol inconnu mais cela aura un coût en performance et en complexité.
Aucune box ne proposera ça!

Pour la performance, il y a un système très optimisé de filtrage de paquets disponible dans linux.

De toute facon un protocol n'a pas forcement de numéro de port, c'est un concept propre au protocol lui-meme.
Oui, 6in4 n'a pas de concept de port.

corrector

  • Invité
IPv6 pour LaFibre.info ce 1er janvier 2016
« Réponse #129 le: 08 janvier 2016 à 06:42:56 »
Mathématiquement il est évident que cela représente peu
Peu? Tu plaisantes j'espère?

mais c'est quand même une ressource rare maintenant, un /8 serait apprécié par n'importe quel opérateur qui se replie en CG-NAT ou équivalent pour assurer sa survie en IPv4.
Ben oui, évidemment.

En v6 ce sont les RFC qui nous poussent à avoir besoin des /56 pour un réseau complet, en maths l'ordre de grandeur ne fait plus beaucoup de différence avec un /64, les deux sont énormes!
Bien sûr un réseau local IPv6 de /64 comporte beaucoup plus d'adresses distinctes qu'une classe A en IPv4 (1099511627776 fois plus). Mais pour vraiment comparer avec une classe A, calcule ce que ça représente en occupation de l'espace d'adresse IPv6 de 128 bits :

occupation de /64 = 2**-64 ~ 5e-20
occupation de /56 = 2**-56 ~ 1e-17

ou bien alors en occupation de l'espace assignable (Global Unicast Address = 2000::/3) soit 125 bits d'adressage :

occupation de /64 = 2**-61 ~ 4e-19
occupation de /56 = 2**-53 ~ 1e-16

Cela fait 1/10.000.000.000.000.000 de l'espace global unicast par abonné.

corrector

  • Invité
IPv6 pour LaFibre.info ce 1er janvier 2016
« Réponse #130 le: 08 janvier 2016 à 07:50:24 »
Non je parle du fait que sur les serveurs (ou ordinateurs) il y a parfois besoin pour des applications d'écouter sur un port et non sur une IP spécifique, surtout pour des solutions propriétaires comme Windows où un firewall reste indispensable.
Que veux-tu dire? Windows intègre un pare-feu.

Pourquoi il faudrait un pare-feu pour des solutions proprio et pas pour des solutions libres?

Tu n'as pas confiance dans les solutions proprio, mais tu les utilises quand même? Et même tu les connectes au réseau des réseaux?

Tu as confiance dans le code libre?

Donc toutes les IP attribuées à une carte réseau du même serveur peuvent écouter le même port, tandis qu'un firewall permet de centraliser la gestion réseau et les ports, il faudrait le faire au cas pas cas sur les applications et c'est pas tout le temps possible.
Bien sûr qu'il faut faire "au cas pas cas" : comment veux-tu faire du filtrage autrement?

corrector

  • Invité
IPv6 pour LaFibre.info ce 1er janvier 2016
« Réponse #131 le: 08 janvier 2016 à 07:57:33 »
Perso je ne crois pas qu'il soit incontournable de garder les ports dans le firewall.
J'imagine l'avenir comme une histoire d'IP et oui/non on laisse passer, quelque soit le protocol et les ports. C'est tellement plus simple et universel.
Si c'est simple et universel, quel intérêt? Et pourquoi pas intelligible et élégant pendant qu'on y est?

Le paramétrage d'un pare-feu doit être imbitable. Des dizaines de lignes de commandes iptables que même son auteur ne saurait relire et expliquer. Des interdictions faisant exception à des autorisations faisant exception à des interdictions. Des blocages de choses qu'on autorise deux lignes plus loin.

C'est le jeu!