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 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. 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
