A: The admin console and XenServer server use TCP port 443 for ...

 
     Il y a quelques années, je n'hésitais pas à citer la virtualisation
 comme une des technologies pouvant apporter une partie des solutions
 techniques lors d'un plan de secours informatique.
 Depuis, HSC a eu l'opportunité d'auditer des architectures virtualisées,
 notamment à plusieurs reprises sur des architectures VMware, d'auditer
 la sécurité de firewalls dans des architectures virtualisées, d'auditer des
 réseaux virtualisés, d'auditer également la sécurité de SAN, interconnectés
 avec des architectures virtualisées, ainsi que de réaliser des études en
 sécurité nous ayant permis de rechercher des failles dans les logiciels
 de virtualisation, et enfin de faire des tests d'intrusion externes,
 ayant permis par exemple, d'accéder à la console de gestion de VMware
 depuis internet.
     Comme le domaine de la virtualisation a changé, mon avis est désormais
 que la virtualisation peut apporter plus de problèmes de sécurité qu'elle
 n'en résolve.
     Les processeurs récents ont intégré des fonctionnalités spécifiques au
 support de la virtualisation, Loïc Duflot (DCSSI) a montré qu'il était
 possible d'exécuter du code en dessous de l'hyperviseur de virtualisation.
 Les Pentium d'Intel sont devenus tellement complexes qu'ils ne peuvent
 être exempts de bogues de sécurité, mais qui met à jour le microcode
 de ses processeurs Intel avec les correctifs de sécurité ?
 Certes l'attaque n'est pas triviale, le code n'est pas public, mais dans
 le passé d'autres attaques non triviales se sont popularisées quelques
 années plus tard. Nous sommes donc certains de ne jamais avoir de
 virtualisation fiable à 100%, car nous ne pourrons jamais assurer que le
 processeur n'a pas de bogues permettant de faire changer d'état un
 hyperviseur de virtualisation.
     Dans les hyperviseurs eux-mêmes, des failles ont permis de lire la
 mémoire virtuelle dans une autre instance des machines virtuelles que la
 sienne, ou bien ont permis de faire exécuter du code arbitraire par
 l'hyperviseur, par exemple via des pilotes de périphériques avec des
 débordements de tampon.
     Les architectures virtualisées nous apportent en terme de réseau un
 plat de spaghettis invraisemblable, que généralement seuls les auditeurs
 de sécurité modélisent à chaque niveau de réseau, pour découvrir que
 le filtrage n'est plus là où le client le croyait. L'intégration de la
 virtualisation n'est pas neutre au niveau IP vue la complexité des flux
 indispensables pour que les logiciels de virtualisation fonctionnent :
 pour la licence, pour l'administration, etc.
     Les systèmes d'administration des systèmes de virtualisation sont
 aussi victimes des vulnérabilités habituelles comme les mots de passe
 par défaut triviaux et jamais changés pour que la maintenance fonctionne.
 L'application des correctifs de sécurité sur les serveurs est déjà
 une tâche complexe, mais alors que dire de l'application des correctifs
 de sécurité de VMware sur un système de dizaines de machines virtuelles ?
     L'organisation des rôles et des responsabilités est elle aussi plus
 complexe, faire qu'une équipe de développement qui réalise des recettes
 d'applications n'ait accès qu'à une machine virtuelle de recette et non pas à
 une machine virtuelle de production est plus facile à dire qu'à garantir
 dans une architecture virtualisée.
     Le stockage est aussi moins sécurisé avec les machines virtuelles.
 Les SAN se partitionnaient afin par exemple que les serveurs de l'ERP ne
 voient que les disques de l'ERP, que les serveurs Windows ne voient que
 les disques Windows, etc. Avec les infrastructures virtualisées, le SAN
 ne voit plus qu'une seule machine au niveau fiber channel, le pilote du
 SAN est virtualisé lui aussi pour avoir les statistiques de transfert,
 et le partitionnement du SAN ne sert plus, un hyperviseur comme VMware
 voit tous les disques et c'est un commutateur virtuel qui segmente. Même
 si une extension sur fiber channel destinée à virtualiser les adresses existe
 elle n'est généralement pas encore supportée.
     Il faut maintenant ajouter les firewalls virtuels, avec plusieurs
 machines virtuelles de filtrage dans le même équipement avec des politiques
 de filtrage distinctes. Là, le plat de spaghettis atteint son apogée, il
 faut vraiment redessiner la réalité à chaque niveau réseau pour y voir clair
 et ne pas faire d'erreur. Plus personne ne sait où est fait le traitement
 des flux, qui a accès à quoi, comment ça marche.
 
     Le manque de maîtrise est le maître mot de la virtualisation et aussi
 du "Cloud" ou du "SaaS" que l'on place au dessus. Nous remplaçons des
 opérateurs qui rackaient des serveurs et branchaient des câbles par
 des ingénieurs (?) qui doivent créer des architectures complexes à gérer.
 Les gains économiques et écologiques ne sont pas aussi évidents que le
 marketing veut le faire croire : l'administration n'est pas virtualisable,
 et les audits de sécurité ne sont pas virtualisables non plus.
     Il m'apparaît trop dangereux d'intégrer dans un même hyperviseur
 des machines virtuelles de niveaux de sécurité différents comme du
 back-office, du front-office, des machines en DMZ et des serveurs sur
 Internet. Il faut garder un minimum de segmentation maîtrisée, et
 utiliser la virtualisation dans son bastion applicatif interne, bien
 cloisonné du reste des réseaux internes et d'Internet.
 
 Pour en savoir plus, les présentations HSC sur le sujet :
 http://www.hsc.fr/ressources/prese [...] ware_2008/
 http://www.hsc.fr/ressources/prese [...] alisation/
 http://www.hsc.fr/ressources/prese [...] alisation/
 La présentation de Loïc Duflot :
 http://www.ssi.gouv.fr/fr/sciences [...] papier.pdf