Systèmes virtualisés sont plus ou moins sûr?

18 mai 2010 par Chris Laisser une réponse »

J'ai eu la question ci-dessus demandé suffisamment de fois que je me sentais digne d'un blog. Alors que quelques années en arrière, la réponse peut avoir été «moins sûr», aujourd'hui, la réponse est «les deux». Je sais, ça sonne comme Chris étant non-incarcération, mais cette réponse n'a vraiment plus décrire avec précision l'état actuel de la technologie.

La virtualisation change tout

J'ai entendu une remarque quelques personnes que la virtualisation est sur le point d'impact de l'industrie de la même manière que l'Internet a fait dans le 90. Pour être honnête, je pense qu'il ya du mérite à cette opinion. Au début des années 90, la plupart des gens couraient IPX, AppleTalk, Netbui et une pléthore d'autres protocoles sur des réseaux fermés. À la fin des années 90, la plupart des gens couraient IP exclusivement avec une connectivité vers le monde entier. La façon dont nous avons fait des affaires, ainsi que la façon dont nous avons appliqué la sécurité, a complètement changé au cours de ces 10 ans. Tant l'administration du réseau et les compétences de sécurité qui étaient de pointe en 1990 ont toutes été inutiles, mais d'ici 1999.

La virtualisation est de commencer à rampe jusqu'à avoir le même impact sur l'industrie. Déploiement de la virtualisation nécessite une révision complète de la façon d'appliquer la sécurité. Retour dans les années 1990, les admins qui ont simplement branché sur l'Internet, sans égard à la façon dont ce serait l'impact de leur réseau, a été brûlée grand temps. Nous font la queue pour voir un résultat similaire à celui des gens d'adopter la virtualisation.

Ce qui fait la virtualisation Moins sécurisé

Le talon d'Achille de la virtualisation est dans le logiciel lui-même. Nous espérons que nous pouvons faire confiance aux logiciels de garder les systèmes invités éloignés les uns des autres, ainsi que l'hôte et / ou hyperviseur. Il ya deux problèmes majeurs avec cette attente:

  1. Aucun logiciel n'est exempt de bugs
  2. Le logiciel peut être mal configuré

Il ya quelques années de recherches fondamentales ont montré qu'ils pouvaient sortir d'un invité et prendre le contrôle complet de l'OS hôte . Alors qu'un hyperviseur est censé limiter ce type d'exposition, nous avons certainement vu des cas où même l'hyperviseur a été contournée . Nous avons même vu des cas ont été logiciels devient exploitable uniquement lorsqu'il est exécuté dans un environnement virtualisé . Ces liens montrent une petite section transversale de la virtualisation des problèmes qui ont été découverts au cours des dernières années. Google peut vous donner une liste plus complète si vous êtes intéressé.

Ainsi, un professionnel de la sécurité prudente va être prudent de confiance aveuglément logiciel pour être sûr. Le problème est les vendeurs ne prennent pas toujours cette même approche. Prenez VMware avec leur ESX (qui sera bientôt ESXi) produit comme un exemple. Beaucoup d'entre nous ont été sidérés quand un représentant de VMware a annoncé CanSecWest à ce qu'il était théoriquement impossible d'attaquer l'hyperviseur ESX . Lorsque nous supposons simplement quelque chose est incassable, quelqu'un de plus créative va trouver un moyen de passer à travers .

Un de mes plus grandes préoccupations avec ESX / ESXi de VMware, c'est que l'a conçu pour être modulaire (via VMsafe ). Sur le plan positif, cela signifie que les fournisseurs externes peuvent créer des produits pour aider à améliorer l'hyperviseur de fonctionnalité et de sécurité. Sur le plan négatif ce qui augmente considérablement les chances de mauvais code en cours d'introduction qui peut compromettre la sécurité.

Nous avons vu un bel exemple de cela dans le passé. Marcus Ranum a créé le pare-feu Gauntlet, qui à cette époque était l'un des appareils les plus sûrs et kick butt de sécurité disponibles. Lorsque trois agences lettre voulions la meilleure sécurité, ils se tournèrent vers Gauntlet. Marcus vendus Gauntlet à Network Associates (McAfee est devenu plus tard) qui a immédiatement commencé à ajouter des fonctionnalités. Il ne fallut pas longtemps avant qu'une chaîne de caractères constante des vulnérabilités étaient découverts, chacun introduit par ces nouvelles «fonctionnalités». De là, le produit a perdu sa sécurité CRED et glissé hors du radar.

Maintenant, il est certainement possible d'ajouter des fonctionnalités et garder les choses sécurisé. Le FreeBSD gens sont un excellent exemple de comment faire cela correctement. Pour assurer la sécurité qu'ils maintenir un processus de vérification très stricte . Est-elle parfaite? Absolument pas, mais leur processus de vérification a mis la barre de mise en œuvre de logiciels sécurisés. Avec un peu de chance de VMware fera similaires, mais je n'ai pas entendu de buzz autour de cet être le cas.

Obtenir votre tête droite

OK, donc on ne peut pas se fier aveuglément le logiciel de virtualisation pour garder les attaquants à distance. Nous pouvons cependant toujours prendre des précautions pour aider à minimiser l'impact si le pire se produit. Un des plus grands étapes que vous pouvez prendre est d'examiner attentivement ce qui se serveurs hébergés, et ce sont d'autres systèmes invités autorisés à circuler sur la même case. Le concept de zone de sécurité utilisé par les architectes du réseau est tout aussi applicable ici.

Une zone de sécurité est simplement une collection de systèmes qui partagent le même niveau de risque relatif. Par exemple les serveurs Web, le nom et SMTP sont généralement situés sur une zone démilitarisée, parce qu'ils partagent les mêmes tous les risques d'attaque directe. Sur la partie interne du réseau, les ordinateurs de bureau sont généralement placés dans une zone de sécurité différente de celle des serveurs. C'est parce que les serveurs ont peu ou pas d'accès à l'Internet tout en postes de travail sont généralement autorisés à communiquer directement. Cela place les postes de travail à risque élevé d'attaque que les serveurs.

Nous pouvons appliquer cette même logique lors de l'implémentation de la virtualisation. Un serveur de DMZ et un serveur interne ne devraient pas être invités sur le même matériel (CPU et de matrice de disques). Cela pourrait permettre à un attaquant de créer une route alternative dans notre réseau. Plutôt que d'avoir à passer par un pare-feu, NIDS, NIPS, appareils etc qui a été déployée sur le fil, un attaquant peut être capable d'accéder aux ressources internes via le logiciel de virtualisation. Est-ce une attaque facile? Non de ce que nous avons vu jusqu'ici. Exploite fonctionnels ont été découverts cependant, alors pourquoi présenter des risques inutiles si nous ne disposons pas d'.

Par ailleurs, ces mêmes règles zone de sécurité doit être appliquée à votre équipement réseau virtualisé. Par exemple, il est une mauvaise idée d'utiliser le même commutateur physique au VLAN de la DMZ et le réseau interne. J'ai vu un couple de clients à obtenir buter cette façon.

Ce qui fait de virtualisation plus sécurisée

Heureusement, dans une perspective de sécurité, la virtualisation n'est pas que des mauvaises nouvelles. En fait il ya quelques pratiques de sécurité très cool que vous pouvez appliquer dans un environnement virtualisé que vous ne pouvez pas faire sans elle. Ce fut l'une des raisons que nous avons commencé en utilisant la virtualisation au sein de l' Honeynet dès 2000.

Une des questions les plus grands de sécurité auxquels nous faisons face aujourd'hui est rootkits au niveau du noyau . Ce qui rend cette souche de malware si insidieux est-il transforme efficacement le système d'exploitation lui-même dans les logiciels malveillants. Cela rend la détection extrêmement difficile, comme tous les contrôles de sécurité doit passer par le noyau. Si le noyau lui-même est compromise, nous ne pouvons pas compter sur le noyau de déclarer avec exactitude les informations de sécurité. Nous finissons par avoir à arrêter le système, monter le disque sur un connu pour être un système propre, et l'exécution de nos contrôles médico-légale à partir de là. Bien sûr Oh le problème avec ce processus est qu'il ne s'adapte pas bien. Si nous avons des dizaines ou des centaines de serveurs, il n'ya tout simplement pas assez de temps dans une journée pour les vérifier tous correctement.

Comme mentionné précédemment, VMware permet maintenant des fournisseurs tiers l'accès à l'API VMsafe hyperviseur via. Cela permet l'accès à des informations d'état privilégié, comme la mémoire et le trafic réseau, sur chacun des OS invités. En branchant sur l'hyperviseur, certaines options de sécurité extrêmement cool deviendra possible.

Par exemple, disons un OS invité est attaqué par un rootkit au niveau noyau. En analysant la mémoire invité, le rootkit peut être détecté à l'extérieur du système d'exploitation virtuel. Lorsque vous effectuez les contrôles via l'hyperviseur, il ya beaucoup moins de chance qu'un rootkit peut furtivité de ses activités et passer inaperçus. Comme mentionné précédemment, il n'existe aucune option comparable à un système non virtualisé.

La fiche API crée également de nouvelles possibilités pour traiter le trafic crypté. Lorsque le chiffrement de bout en bout est employée (comme un VPN), des chèques de réseau basée sur la couche application sont facilement contournés. Votre seule option réelle a été d'exécuter un logiciel agent sur le point de fin, donc la sécurité pourrait être mise en œuvre après le processus de décryptage. Bien sûr, le problème ici est que si l'agent est attaqué, tous les paris sont ouverts. Encore une fois, en se branchant sur l'hyperviseur nous sommes dans une meilleure position pour examiner de façon plus sécuritaire de ces données.

Nous commençons tout juste à voir de nouvelles produits qui s'appuient sur ​​la fiche VMsafe API . Comme tous les produits sont relativement nouveaux, le jury est encore sur la façon dont ils peuvent être efficaces. Offrandes exécuter le Gambit du remplacement de pare-feu basés sur l'hôte et la protection de l'IDS à l'application de la politique complet. Il sera intéressant de voir comment ce produit de niche secoue l'année prochaine.

Résumé

Alors que je l'ai mentionné au début de ce post, la virtualisation a la capacité de rendre votre environnement plus ou moins sûr, selon la façon de le déployer. Si vous avez simplement commencer à courir tout sur une seule boîte, vous allez probablement obtenir buter. Si vous étendre les meilleures pratiques qui ont été développées au fil des ans dans le domaine de virtualisation, ainsi que le levier certaines des nouvelles fonctionnalités de sécurité qui sont libérés, vous pouvez réellement créer une meilleure posture de sécurité globale.

Related posts:

  1. VMware Fast Path Versus Firewalls voie lente
  2. Passivement Fingerprinting VMware Virtual Systems
  3. SANS VMware 502 vmx

Publicité

Laisser un commentaire