Re: [FRnOG] Attention au SLAC

2011-06-09 Par sujet Guillaume Barrot
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

2011-06-09 Par sujet Jérôme Nicolle
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

2011-06-08 Par sujet Jérôme Nicolle
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

2011-06-08 Par sujet Ionel GARDAIS
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

2011-06-08 Par sujet Guillaume Barrot
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

2011-06-08 Par sujet Radu-Adrian Feurdean
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/