Etat de l'art machines virtuelles et secu

Jerome <askme@askmyemail.com> writes:

Bonsoir,
[Serveurs dans machines virtuelles]

J'avoue que je n'en reviens toujours pas et je me pose des questions. Je
suis à la recherche d'informations sur ce style d'architecture, sur les
risques et les recommendations. Si vous avez des commentaires n'hésitez pas.

Mouaif.

Rien de bien neuf sur le fond (c'est peut etre effectivement moins
"frequent" que d'autres solutions).

Et d'un certain point de vue, je dirais que c'est la meme technique
que le chroot, mais en "plus pousse"....

Et ca a globalement les memes avantages et memes inconvenients:

- moins de machines physiques (cote prix, c'est surement un avantage,
cote securite, c'est d'abord un inconvenient, sauf si on prend un
serveur avec tout en hot swap, ou d'autres solutions "robustes"....)

- cloisonnement efficace uniquement s'il est vraiment impossible de
sortir de la machine virtuelle (il y a par exemple deja eu moyen de
sortir d'une jail Linux, par le passe...).

Par contre, ca presente quand meme des interets supplementaires,
puisqu'on peut avoir differents OS, en mettre a jour certains et pas
d'autres (au niveau OS, toujours), etc...



A +

VANHU.

Jerome wrote:

Aujourd'hui j'ai trouvé un truc hallucinant chez un client: il a remplacé
tous ses serveurs par des machines virtuelles. (...)

C'est le retour des mainframes. Que ce soit un OS virtualisant
sur une grosse machine conçue pour ça ou des machines virtuelles
du genre VMware (d'après la question ce serait un mélange des
deux):

Avantages:
- Meilleure mutualisation des ressources.
- Administration centralisée.
- Architecture exotique, "security by obscurity".

Inconvénients:
- Hardware probablement cher.
- Pour se protéger des conséquences d'un DoS, il faut mettre
des quotas sur les ressources, ce qui limite l'intérêt de la
mutualisation.
- Disponibilité moins bonne (en cas de panne HW, tout est HS).
- Pas plus sûr que les OS individuels.
- Points de défaillance sécu supplémentaires: l'OS virtualisant
et/ou le logiciel de la machine virtuelle.
- Audit difficile (*).

(*) Quand on voit deux DMZ physiquement indépendantes, il suffit
d'auditer la config du firewall pour dormir tranquille. Si toutes
les pattes du FW arrivent sur la même machine, c'est moins clair.

Problématique analogue: est-il raisonnable de mettre ses DMZ et
son réseau interne sur un même switch physique, avec des VLANs ?

AC

Bonsoir,
Aujourd'hui j'ai trouvé un truc hallucinant chez un client: il a remplacé
tous ses serveurs par des machines virtuelles. Il y a le domaine controleur,
le mail serveur interne, des serveurs internes, le mail relay internet, le
web proxy, la management firewall, un serveur d'authentification, un serveur
RAS, des serveurs web et j'en oublie. Il n'y a que le firewall qui est réél
et le routeur internet! Le tout est sur un e-serveur ibm sur os400 qui
tourne une instance de windows serveur 2003 qui tourne VmWare GSX avec une
vingtaines de serveurs virtuels la plupart sous windows 2003. Il y a 6
interfaces réseaux physiques sur le mainframe et elles sont branchées sur
chaque DMZ du firewall. Même plus besoin de switchs, ils sont virtuels!
J'avoue que je n'en reviens toujours pas et je me pose des questions. Je
suis à la recherche d'informations sur ce style d'architecture, sur les
risques et les recommendations. Si vous avez des commentaires n'hésitez pas.

Je me suis posé la même question mais pour une architecture différente :
une machine Linux avec plusieurs machines virtuelles UML (User Mode
Linux) pour chaque serveurs.

Je profite donc du post pour poser la question.

On 26 Oct 2005 09:56:19 GMT, Jerome <askme@askmyemail.com>:

Le tout est sur un e-serveur ibm sur os400 qui
tourne une instance de windows serveur 2003 qui tourne VmWare GSX avec une
vingtaines de serveurs virtuels la plupart sous windows 2003.

Deux commentaires à chaud :
- L'administration d'une machine Windows peut déjà prendre du
temps, alors 20 machines... Bon courage pour s'assurer que les 20
machines sont à jour, n'ont pas de ports inutiles ouverts, etc.
- Combien de RAM faut-il pour faire tourner tout ça ? 10 Go ?

Enfin bon, ça me paraît une méthode particulièrement onéreuse pour
obtenir un système peu stable, étant donné que n'importe laquelle des
20 machines virtuelles peut merder. Comme toi, je suis sur le cul.

Jerome égrapsen en <435e8dc6$0$31627$626a14ce@news.free.fr> :

Je suis à la recherche d'informations sur ce
style d'architecture, sur les risques et les recommendations. Si
vous avez des commentaires n'hésitez pas.

Un commentaire sûrement naïf : n'est-ce pas un peu risqué de faire
dépendre tout un réseau d'une seule machine ? En cas de problème, il
n'existe plus aucune autre machine capable de prendre le relais,
non ?

On 26 Oct 2005 12:58:08 GMT, Vincent Ramos
<siva_sans_spam@kailaasa.net.invalid>:

Un commentaire sûrement naïf : n'est-ce pas un peu risqué de faire
dépendre tout un réseau d'une seule machine ?

Sans doute, mais c'est indépendant du problème qui nous occupe ici. Si
le serveur de domaine tombe en panne, le réseau est HS, qu'il soit sur
la même machine physique que d'autres machines virtuelles ou pas.

La solution est d'ailleurs la même : deux machines identiques,
proposant les mêmes services.

On Wed, 26 Oct 2005 09:56:19 +0000, Jerome wrote:

Si vous avez des commentaires n'hésitez pas.

Juste une réflexion à froid : si une faille permettant de prendre le
contrôle du "Host" depuis le "Guest" est découverte, c'est toute
l'infrastructure qui sera compromise si un des serveurs Web publiquement
exposé se fait hacker.

C'est la même réflexion qui me fait craindre les architectures où
toutes les zones (devant le pare-feu, dans les DMZ, sur le LAN) sont sur
un même switch gérant les VLAN. Une erreur de config, un mot de passe
trop faible ou une faille de sécu sur le(s) switch(s), et hop, le
pare-feu ne sert plus à rien car on peut alors se placer dans n'importe
quelle zone.


Nicob, parano

On Wed, 26 Oct 2005 12:58:08 +0000, VANHULLEBUS Yvan wrote:

- cloisonnement efficace uniquement s'il est vraiment impossible de
sortir de la machine virtuelle (il y a par exemple deja eu moyen de
sortir d'une jail Linux, par le passe...).

Pour VmWare, il est possible de détecter depuis le "Guest" qu'on est dans
une machine virtuelle (cf. "4tphi-vmchk.c"), ce qui permet ensuite de
s'attaquer directement au serveur hébergeant le "Host" (cf. les failles
liées à l'utilisation d'OpenSSL).


Nicob

Jerome <askme@askmyemail.com> writes:

Le tout est sur un e-serveur ibm sur os400 qui tourne une instance de
windows serveur 2003 qui tourne VmWare GSX avec une vingtaines de
serveurs virtuels la plupart sous windows 2003.

Bah, il aurait pu faire plus drôle encore avec plusieurs instances
os/400 sous LPAR.

Dans le cas que tu donnes, le 400 a une carte interne optionnelle qui
est un pc dédié à l'exécution d'os ia32 (l'hôte vmware gsx dans le cas
présent)

J'avoue que je n'en reviens toujours pas et je me pose des questions. Je
suis à la recherche d'informations sur ce style d'architecture, sur les
risques et les recommendations.

Regarde du coté de Xen, la 3.0 devrait permettre l'exécution d'os non
paravirtualisés si l'hyperviseur s'exécute sur un Intel avec extensions
VT ou sur un Amd avec extensions Pacifica.
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/

En termes de sécurité, comme le dit Yvan, ce qui importe c'est de ne pas
pouvoir sortir de l'instance virtuelle en cours d'exécution. Iirc, il y
a un dossier sur la détection des environnements virtualisés dans le
dernier MISC, par contre je n'ai rien lu pour le moment sur la capacité
à s'évader d'un système virtualisé au niveau hard.

Éric Masson

--
Créons donc un groupe spécial pour les cons et les connes. Tu seras la
modératrice en chef.
-+- C in <http://www.le-gnu.net>-Je veux être le premier à y poster -+-

A. Caspis wrote:

Avantages:
- Meilleure mutualisation des ressources.
- Administration centralisée.
- Architecture exotique, "security by obscurity".
- Réduction de l'espace utilisé, de la consommation electrique, ce qui

peut etre très important
- Possibilité de créer des machines de test à la volée
- Possibilité de cloner des machines à la volée
- Possibilité de revenir à un état antérieur en un clic
- Possibilité de modifier la configuration réseau en quelques clics

Ces solutions sont particulierement pratiques pour tester les patches,
les déployer en prod et eventuellement revenir en arriere de manière
très rapide.

Inconvénients:
- Hardware probablement cher.
Le but est aussi de payer moins cher. Si on a la chance d'avoir des

serveurs qui n'ont pas leur pics de charge en même temps il suffit de
peu de puissance pour que tout marche sans qu'on se rende compte qu'on a
mutualisé les ressources.
De plus au lieu d'acheter des disques durs pour chaque machine on met un
gros SAN derriere et ça va très vite (bon c'est pas vraiment moins cher ça).
J'ai pu voir ça chez un client qui globalement avait un système moins
cher et largement plus rapide, en raison de la vitesse des accès disques.

- Pour se protéger des conséquences d'un DoS, il faut mettre
des quotas sur les ressources, ce qui limite l'intérêt de la
mutualisation.
- Disponibilité moins bonne (en cas de panne HW, tout est HS).
Exact mais peut se blinder par de la redondance et on n'a qu'une machine

à surveiller.

- Pas plus sûr que les OS individuels.
Ce n'est pas un inconvénient, par contre le point suivant l'est

- Points de défaillance sécu supplémentaires: l'OS virtualisant
et/ou le logiciel de la machine virtuelle.
- Audit difficile (*).