Re: [FRnOG] Attention au SLAC
Soyons clair, je ne dis pas que le SLAAC c'est la solution geniale pour les serveurs, mais l'IP fixe ne l'est peut-etre plus non plus (a part pour des cas ou tu attaques ton serveur via l'IP, comme des DNS, Radius etc.). Pour le reste oui je connais GSLB ou des intercos de Datacenter en niveau 2, et honnêtement entre les deux, je préfère la première solution, qui finalement converge *globalement* très bien (effectivement tu n'ais pas a l'abris d'un TTL non respecte ou d'un cache de 20j, mais d’expérience c'est assez rare). Quant a du routage sur un serveur, la majorité des gens savent gérer du routage sur un parc de plusieurs centaines de routeurs, et le fait que tu ais plusieurs centaines de serveurs sur un site serait différent ? Sans outillage adapte je veux bien, mais je doute qu'un hébergeur de plusieurs centaines de serveurs fassent ça a la main. Pour la solution de Facebook, ce n'est pas la solution idéale, mais elle a l'interet de permettre de passer rapidement un site en v6, ce qui peut intéresser pas mal de gens en ces temps de v6 Day. Le 8 juin 2011 22:20, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.neta écrit : On Wed, 8 Jun 2011 21:29:50 +0200, Guillaume Barrot guillaume.bar...@gmail.com said: Question : que fait le technicien sur le WWN de SAN si c'est pas la même chose ? Il rend pas sa baie SAN accessible en FC au monde entier.. Deuxio, de nouveaux serveurs arrivent avec la possibilité de cloner la conf hard (wwn, mac etc, ex : UCS Cisco). On peut espérer que ça se généralise. Bonjour le bordel quand on clone la conf hard sur deux unites differentes. De plus, quel intérêt de conserver la même @IP pour tous les serveurs attaques sur une URL ? Du push DNS au DDNS les solutions pour conserver le nom en changeant l'IP existent depuis longtemps. Ah bon ? Tu sais comment updater le cache DNS des ISPs de la planete, surtout pour ceux qui decident de ne pas trop respecter le TTL ? Et enfin, si tu virtualises pas de soucis, or c'est pas déconnant sur un certain nombre de serveurs frontaux internet. Il y a des choses qu'on virtualise, il y a des choses (parfois meme exposes publiquement) qu'on virtualise pas. Bref une faille de niveau 2 me semble peu dangereuse vis a vis des autres failles plus faciles a utiliser (rootkit sur un serveur Linux mal patché par exemple, ou SQL injection sur une infra n-tiers mal configurée). . L'IP fixe, c'est simple et maîtrisée, mais ça pose un gros problème : c'est fixe, et lie a ton plan d'adressage. Maintenant, si tu utilises des serveurs virtuels, et que tu souhaites pouvoir les déplacer d'un site A a un site B sans trop de contraintes, sachant que tes utilisateurs s'y connectent via une URL, tu as deux solutions : - un vlan étendu ou tout autre solution de Datacenter Interconnect de l'EoMPLS a des trucs plus exotiques comme OTV ou Fabricpath de Cisco - un adressage dynamique et des updates du DNS (via DDNS ou du GSLB par exemple) Le choix c'est soit la complexité d'un niveau 2 étendu (ça parait simple comme ça ...), soit la complexité d'une IP dynamique (et le comment je gère mes règles firewall etc.) troll Quand on fume un peu trop la moquette, on finit par faire du cloud (cloud de fummee *ET* cloud computing). /troll Plus serieusement, est-ce que tu as jamais eu a gerer les choses dont tu parles ? Si oui, dans quel type d'environnement ? Je me rappelle avoir vu tourner un vieux VAX de chez DEC avec une config rigolote : le service porté sur une loopback, et les interfaces réseaux non configurées prenait une IP dans le linklocal (169.254.x.x), et un daemon RIP qui tournait en standard == tu pouvais joindre ton service sans pour autant connaitre les @IPs des interfaces. La même chose en IPv6 avec un daemon RIPng ou OSPFv3, c'est pas bien compliqué a mettre en place vu comment le linklocal est bien globalement bien géré. Et gérer le SLAAC sur une loopback pour le coup :D 1: C'est pas bien complique pour une machine. Commence a ajouter des zeros a la fin et ca change radicalement. 2: SLAAC sur une loopback, ca doit etre fun. Un tres bon sujet pour ce vendredi. Autre solution, toute bête : pas de v6 sur les serveurs (cf la presentation d'IPv6 at Facebook sur le site du Nanog http://www.nanog.org/meetings/nanog50/presentations/Tuesday/NANOG50.Talk9.lee_nanog50_atlanta_oct2010_007_publish.pdf ). Pas mal de serveurs en frontal internet étant en ferme derrière des loadbalancers, c'est généralisable. Ca fait juste poudre dans les yeux. Je me souviens avoir teste FB over IPv6 a l'epoque et la premiere connexion c'etait le douche gele (Facebook has detected that you are trying to connect from an un-familiar location : San Francisco, California - avec en cadeau l'IP du proxy v6-v4 et tout le cirque d'identification des amis dans des photos avec leurs chiens et chats). -- Cordialement, Guillaume BARROT
Re: [FRnOG] Attention au SLAC
Le 8 juin 2011 21:29, Guillaume Barrot guillaume.bar...@gmail.com a écrit : Pour utiliser une faille de niveau 2 sur le serveur, il faut s'en approcher très prés ! On a eu le même raisonnement sur une éventuelle faille de niveau 2 sur un vswitch vmware. Pour l'attaquer, il faudrait envisager une sorte de buffer overflow (pas de buffer sur un vswitch, mais bon, j'ai dit une sorte), donc être en niveau 2 avec ce vswitch. Autrement dit, le hacker a pris le contrôle de ton routeur, ou d'un serveur dans le même vlan, au hasard une VM. Bref une faille de niveau 2 me semble peu dangereuse vis a vis des autres failles plus faciles a utiliser (rootkit sur un serveur Linux mal patché par exemple, ou SQL injection sur une infra n-tiers mal configurée). Le problème n'est pas tant la probabilité qu'une faille de niveau 2 soit exploitable, bien que certaines puissent l'être à cause de la complexité de certains NIC tels que ceux faisant du TCP offload ou la fragilité de certains drivers (vielles implémentations des marvell, RTL8168 ou atlansic sous Linux par exemple), que les informations autres que ça peut réveler. Exemples type : - Si je vois deux machines dont une avec un chip dont le driver a une faille connue qui facilite une montée en privilège, j'attaquerais en priorité celle là - Si le serveur est d'une marque connue pour numéroter ses ports d'une certaine façon et que l'un des ports est bridgé sur le iKVM intégré à la carte mère, je sais que je peux faire une attaque par rebond dessus - Si enfin le chip en lui même est vulnerable à des attaques par charge (mauvais comportement du triplet chip/os/driver sur certains paterns de trafic), je vais lui bourrer le moi avec des paquets de la taille qui va bien avec le payload qui va bien juste pour solliciter un max de CPU sans même me faire chier à analyser la couche applicative Conclusion, que les failles existent réellement ou pas, qu'elles soient connues ou pas, elles peuvent exister, donc par principe, montrer sa MAC sur un lien direct à l'Internet sauvage (par opposition à civilisé), c'est juste un risque inutile, donc une mauvaise idée. -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Attention au SLAC
Bonjour, Un premier feedback concernant World IPv6 day, plus particulièrement ce qui semble être une mauvaise pratique : l'utilisation de SLAAC (StateLess Address Auto-Configuration) sur des serveurs publics. J'y vois deux problèmes majeurs, sur lesquels j'aimerai avoir vos impressions : - Scenario de reprise après incident : panne matérielle Le serveur tombe en rade, le service doit migrer sur une nouvelle machine physique, quelle est la probabilité que le technicien en charge pense à (voir puisse) cloner l'adresse MAC de l'ancien serveur, et donc maintenir la même adresse publique ? Au mieux, ça fait perdre quelques minutes sur la remontée, au pire c'est impossible (hébergeur ne le permettant pas, driver ou OS bugué), dans quel cas le délai de reprise après incident est fonction du délai de propagation DNS. - Exposition de faille de sécurité L'adresse étant composée depuis la MAC de l'interface réseau, ça expose des caractéristiques matérielles de la machine, et donc des failles potentielles sur le hardware ou les drivers associés, cas typique permettant une attaque en déni de service ciblé (et non distribué) Dans les deux cas, ça me semble représenter un risque trop grand pour que l'usage de SLAAC soit considéré comme pertinent sur des serveurs publics. Ca expose aussi un défaut d'implémentation pour les hébergeurs de serveurs dédiés principalement : les mécanismes d'attribution d'adresses doivent prévoir une association manuelle de l'adresse aux machines, justement pour prévoir ce genre de cas de figure. Est ce le cas chez vous ? Enfin, à tout hasard, est ce que ce problème potentiel a déjà été analysé ? Auriez vous des pointeurs à proposer ? Bon IPv6 day ;) -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Attention au SLAC
Bonjour, Pareil : serveur == IP fixe non auto-configurée (ni stateless ni statefull DHCPv6). Et pour faire joli et se souvenir (un peu) de l'IPv6 du serveur au cas ou, un nommage type net_prefix:subnet::service:instance i.e. : fe80:1234:fe37:400::53:1 fe80:1234:fe37:400::53:2 pour deux serveurs DNS (oui, ce sont des IP link-local, c'est juste pour l'exemple). Ionel Le 8 juin 2011 à 13:47, Frédéric VANNIÈRE a écrit : Bonjour, Un premier feedback concernant World IPv6 day, plus particulièrement ce qui semble être une mauvaise pratique : l'utilisation de SLAAC (StateLess Address Auto-Configuration) sur des serveurs publics. J'y vois deux problèmes majeurs, sur lesquels j'aimerai avoir vos impressions : [...] Enfin, à tout hasard, est ce que ce problème potentiel a déjà été analysé ? Auriez vous des pointeurs à proposer ? Un serveur se doit d'avoir une IP fixe donc chez nous nous avons désactivé l'autoconfiguration et mis des IPv6 fixes comme en v4. Par contre, nous gardons RA (router advertissement) afin d'avoir 2 passerelles ipv6 en haute disponibilité car HSRP/VRRP ne fonctionne pas sur certains Cisco en v4+v6. Frédéric; -- Frédéric VANNIÈRE
Re: [FRnOG] Attention au SLAC
Bonjour, Le 8 juin 2011 13:31, Jérôme Nicolle jer...@ceriz.fr a écrit : Bonjour, Un premier feedback concernant World IPv6 day, plus particulièrement ce qui semble être une mauvaise pratique : l'utilisation de SLAAC (StateLess Address Auto-Configuration) sur des serveurs publics. J'y vois deux problèmes majeurs, sur lesquels j'aimerai avoir vos impressions : - Scenario de reprise après incident : panne matérielle Le serveur tombe en rade, le service doit migrer sur une nouvelle machine physique, quelle est la probabilité que le technicien en charge pense à (voir puisse) cloner l'adresse MAC de l'ancien serveur, et donc maintenir la même adresse publique ? Au mieux, ça fait perdre quelques minutes sur la remontée, au pire c'est impossible (hébergeur ne le permettant pas, driver ou OS bugué), dans quel cas le délai de reprise après incident est fonction du délai de propagation DNS. Question : que fait le technicien sur le WWN de SAN si c'est pas la même chose ? Deuxio, de nouveaux serveurs arrivent avec la possibilité de cloner la conf hard (wwn, mac etc, ex : UCS Cisco). On peut espérer que ça se généralise. De plus, quel intérêt de conserver la même @IP pour tous les serveurs attaques sur une URL ? Du push DNS au DDNS les solutions pour conserver le nom en changeant l'IP existent depuis longtemps. Et enfin, si tu virtualises pas de soucis, or c'est pas déconnant sur un certain nombre de serveurs frontaux internet. - Exposition de faille de sécurité L'adresse étant composée depuis la MAC de l'interface réseau, ça expose des caractéristiques matérielles de la machine, et donc des failles potentielles sur le hardware ou les drivers associés, cas typique permettant une attaque en déni de service ciblé (et non distribué) Pour utiliser une faille de niveau 2 sur le serveur, il faut s'en approcher très prés ! On a eu le même raisonnement sur une éventuelle faille de niveau 2 sur un vswitch vmware. Pour l'attaquer, il faudrait envisager une sorte de buffer overflow (pas de buffer sur un vswitch, mais bon, j'ai dit une sorte), donc être en niveau 2 avec ce vswitch. Autrement dit, le hacker a pris le contrôle de ton routeur, ou d'un serveur dans le même vlan, au hasard une VM. Bref une faille de niveau 2 me semble peu dangereuse vis a vis des autres failles plus faciles a utiliser (rootkit sur un serveur Linux mal patché par exemple, ou SQL injection sur une infra n-tiers mal configurée). Dans les deux cas, ça me semble représenter un risque trop grand pour que l'usage de SLAAC soit considéré comme pertinent sur des serveurs publics. Ca expose aussi un défaut d'implémentation pour les hébergeurs de serveurs dédiés principalement : les mécanismes d'attribution d'adresses doivent prévoir une association manuelle de l'adresse aux machines, justement pour prévoir ce genre de cas de figure. Est ce le cas chez vous ? L'IP fixe, c'est simple et maîtrisée, mais ça pose un gros problème : c'est fixe, et lie a ton plan d'adressage. Maintenant, si tu utilises des serveurs virtuels, et que tu souhaites pouvoir les déplacer d'un site A a un site B sans trop de contraintes, sachant que tes utilisateurs s'y connectent via une URL, tu as deux solutions : - un vlan étendu ou tout autre solution de Datacenter Interconnect de l'EoMPLS a des trucs plus exotiques comme OTV ou Fabricpath de Cisco - un adressage dynamique et des updates du DNS (via DDNS ou du GSLB par exemple) Le choix c'est soit la complexité d'un niveau 2 étendu (ça parait simple comme ça ...), soit la complexité d'une IP dynamique (et le comment je gère mes règles firewall etc.) Je me rappelle avoir vu tourner un vieux VAX de chez DEC avec une config rigolote : le service porté sur une loopback, et les interfaces réseaux non configurées prenait une IP dans le linklocal (169.254.x.x), et un daemon RIP qui tournait en standard == tu pouvais joindre ton service sans pour autant connaitre les @IPs des interfaces. La même chose en IPv6 avec un daemon RIPng ou OSPFv3, c'est pas bien compliqué a mettre en place vu comment le linklocal est bien globalement bien géré. Et gérer le SLAAC sur une loopback pour le coup :D Autre solution, toute bête : pas de v6 sur les serveurs (cf la presentation d'IPv6 at Facebook sur le site du Nanoghttp://www.nanog.org/meetings/nanog50/presentations/Tuesday/NANOG50.Talk9.lee_nanog50_atlanta_oct2010_007_publish.pdf ). Pas mal de serveurs en frontal internet étant en ferme derrière des loadbalancers, c'est généralisable. Bref c'est pas un sujet simple, et y a pas de solution miracle malheureusement ! Enfin, à tout hasard, est ce que ce problème potentiel a déjà été analysé ? Auriez vous des pointeurs à proposer ? Bon IPv6 day ;) -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Cordialement, Guillaume BARROT
Re: [FRnOG] Attention au SLAC
On Wed, 8 Jun 2011 21:29:50 +0200, Guillaume Barrot guillaume.bar...@gmail.com said: Question : que fait le technicien sur le WWN de SAN si c'est pas la même chose ? Il rend pas sa baie SAN accessible en FC au monde entier.. Deuxio, de nouveaux serveurs arrivent avec la possibilité de cloner la conf hard (wwn, mac etc, ex : UCS Cisco). On peut espérer que ça se généralise. Bonjour le bordel quand on clone la conf hard sur deux unites differentes. De plus, quel intérêt de conserver la même @IP pour tous les serveurs attaques sur une URL ? Du push DNS au DDNS les solutions pour conserver le nom en changeant l'IP existent depuis longtemps. Ah bon ? Tu sais comment updater le cache DNS des ISPs de la planete, surtout pour ceux qui decident de ne pas trop respecter le TTL ? Et enfin, si tu virtualises pas de soucis, or c'est pas déconnant sur un certain nombre de serveurs frontaux internet. Il y a des choses qu'on virtualise, il y a des choses (parfois meme exposes publiquement) qu'on virtualise pas. Bref une faille de niveau 2 me semble peu dangereuse vis a vis des autres failles plus faciles a utiliser (rootkit sur un serveur Linux mal patché par exemple, ou SQL injection sur une infra n-tiers mal configurée). . L'IP fixe, c'est simple et maîtrisée, mais ça pose un gros problème : c'est fixe, et lie a ton plan d'adressage. Maintenant, si tu utilises des serveurs virtuels, et que tu souhaites pouvoir les déplacer d'un site A a un site B sans trop de contraintes, sachant que tes utilisateurs s'y connectent via une URL, tu as deux solutions : - un vlan étendu ou tout autre solution de Datacenter Interconnect de l'EoMPLS a des trucs plus exotiques comme OTV ou Fabricpath de Cisco - un adressage dynamique et des updates du DNS (via DDNS ou du GSLB par exemple) Le choix c'est soit la complexité d'un niveau 2 étendu (ça parait simple comme ça ...), soit la complexité d'une IP dynamique (et le comment je gère mes règles firewall etc.) troll Quand on fume un peu trop la moquette, on finit par faire du cloud (cloud de fummee *ET* cloud computing). /troll Plus serieusement, est-ce que tu as jamais eu a gerer les choses dont tu parles ? Si oui, dans quel type d'environnement ? Je me rappelle avoir vu tourner un vieux VAX de chez DEC avec une config rigolote : le service porté sur une loopback, et les interfaces réseaux non configurées prenait une IP dans le linklocal (169.254.x.x), et un daemon RIP qui tournait en standard == tu pouvais joindre ton service sans pour autant connaitre les @IPs des interfaces. La même chose en IPv6 avec un daemon RIPng ou OSPFv3, c'est pas bien compliqué a mettre en place vu comment le linklocal est bien globalement bien géré. Et gérer le SLAAC sur une loopback pour le coup :D 1: C'est pas bien complique pour une machine. Commence a ajouter des zeros a la fin et ca change radicalement. 2: SLAAC sur une loopback, ca doit etre fun. Un tres bon sujet pour ce vendredi. Autre solution, toute bête : pas de v6 sur les serveurs (cf la presentation d'IPv6 at Facebook sur le site du Nanog http://www.nanog.org/meetings/nanog50/presentations/Tuesday/NANOG50.Talk9.lee_nanog50_atlanta_oct2010_007_publish.pdf ). Pas mal de serveurs en frontal internet étant en ferme derrière des loadbalancers, c'est généralisable. Ca fait juste poudre dans les yeux. Je me souviens avoir teste FB over IPv6 a l'epoque et la premiere connexion c'etait le douche gele (Facebook has detected that you are trying to connect from an un-familiar location : San Francisco, California - avec en cadeau l'IP du proxy v6-v4 et tout le cirque d'identification des amis dans des photos avec leurs chiens et chats). --- Liste de diffusion du FRnOG http://www.frnog.org/
