Archive pour la 'virtualisation' catégorie

VMware Fast Path Versus Firewalls voie lente

30 août 2010

Beaucoup d'entre nous travaillent désormais avec les pare-feu virtuel. J'ai fait un post précédent concernant la forces et faiblesses de la sécurité dans le domaine du virtuel , mais aujourd'hui je veux parler des possibilités de pare-feu avec VMware. Il a été beaucoup d'excitation au sujet de VMware relativement nouvelle API VMsafe . Plus précisément, tout le monde se démène pour créer / déployer des pare-feu d'accès rapide. Mais toutes les implémentations sont créés égaux voie rapide? Y at-il des problèmes de sécurité à aller avec une solution d'accès rapide? Débutons notre étude et à voir.

Répartition des VMsafe

Avec la sortie de l'API VMsafe de sécurité, VMware a amélioré les options disponibles pour mettre en œuvre la sécurité dans un environnement vSphere en permettant aux fournisseurs de brancher directement sur l'hyperviseur au ring 0. VMsafe est constitué de trois composantes:

  • VDDK - inspection bloc disque. API a été publiquement libéré.
  • vCompute - CPU et la mémoire API. N'a pas été rendue publique. Inconnu où des tiers ont accès, le cas échéant.
  • vNetwork - API pour surveiller / filtre entre le vNIC et vSwitch. N'a pas été rendue publique. Au meilleur de ma connaissance, seul Altor Networks & Systems Reflex ont accès (deux vendeurs qui ont aidé dans le développement de l'API).

Plus précisément, je veux parler de l'API vNetwork. Lors du contrôle des flux de trafic réseau au sein d'un hôte ESX, il ya deux mise en œuvre possible », voie lente» et «voie rapide».

Voie lente

Voie lente est la plus simple de mise en œuvre et celui que nous utilisons depuis des années. Effectivement, cela est juste un invité VM, semblable à tout autre invité VM, fonctionnant sur l'hôte ESX. Typiquement, chaque invité est connecté à un unique vSwitch, et chacun de ces vSwitches est connecté à une vNIC unique sur le pare-feu. Ceci est similaire à une configuration de pare-feu existants, mais mis en œuvre pratiquement. Le bénéfice de l'exécution de voie lente est que vous pouvez exécuter un OS plein fouet avec tout les bibliothèques ou les services requis pour soutenir le pare-feu.

Fast Path

Fast Path est effectivement un pilote 0 anneau qui se branche directement dans le noyau hyperviseur. Cela permet à un fournisseur tiers de tirer parti de l'hyperviseur pour l'insertion entre chaque connexion vNIC / vSwitch. Parce qu'un pilote Fast Path est exécuté dans le contexte du noyau, il ajoute qu'une charge minimale pour le système. Le résultat est l'exécution de code au sein d'accès rapide est sensiblement plus rapide que le même code en cours d'exécution au sein de voie lente (donc la convention de nommage de VMware pour chaque contexte). Charge sur l'hôte ESX est minimisée, de sorte que le résultat final est que vous pouvez exécuter les invités beaucoup plus virtuel.

Rapide Vs lente

Donc il semble que vous voudriez faire tout chemin rapide, mais il ya un certain nombre de questions. Fast Path est un pilote du noyau branchant dans une minimisé l'hyperviseur, et non pas un système de soufflage d'exploitation complet. Cela limite les bibliothèques et les services du pare-feu dispose pour contrôler la circulation. De plus, nous sommes en branchant un pilote du noyau donc il doit être assuré qu'elle ne ballonnement de l'hyperviseur, d'augmenter la surface d'attaque ou d'interférer avec d'autres hyperviseurs fonctions. VMware effectue une revue de code sur tous les conducteurs voie rapide avant la libération. Donc, si je pourrait théoriquement mettre en œuvre tout mon code dans la procédure Fast Path, j'aurais besoin de l'approbation de VMware avant chaque patch ou Feature Release.

Dans cet esprit, un vendeur affirmant "voie rapide" de soutien est en réalité va finir par mettre en œuvre une partie de leur code comme voie rapide, une portion de voie lente, puis créez un connecteur entre les deux. Combien de charge est placée sur le système dépendra de combien de ce code est mis en œuvre dans le chemin rapide et dans quelle mesure il est exécuté en voie lente.

Possible déploiements Fast Path

Par exemple, un fournisseur peut choisir d'écrire un pilote d'accès rapide que le simple fait de tunnels tous les paquets de retour à un pare-feu lent cheminement mis en œuvre. Le code voie lente détermine ensuite si le trafic doit être transmis ou déposés, avec des paquets transmis étant renvoyé le code d'accès rapide pour une insertion dans le canal de contrôle hyperviseur. Alors que ce serait la méthode la plus simple de déployer chemin rapide, et sans doute la plus sûre et la plus sûre, il offrirait les avantages moins les performances. Charge du système ne serait probablement pas beaucoup mieux que la mise en œuvre une voie lente complète. Je vois cette option comme étant très attractif pour les fournisseurs de pare-feu existants, car il faudrait un minimum de modification de leur code existant tout en étant en mesure de réclamer «un soutien Fast Path».

Une autre option serait d'utiliser l'espace voie lente pour les fonctions administratives avec le pilote Fast Path agit comme le moteur pare-feu. Ainsi, par exemple l'administrateur de pare-feu créerait la politique grâce à une interface fonctionnant sur une machine virtuelle voie lente, qui serait alors poussez la politique vers le bas pour un pilote de voie rapide. Dans cette configuration, le pilote Fast Path a une copie de la politique de contrôle du trafic afin peuvent être mises en œuvre immédiatement. Le résultat est la manipulation rapide du trafic avec la charge système minimale. L'arrêt des échanges est plus volumineux de code à l'anneau 0.

Il est également possible de mettre en œuvre un mélange des deux. Par exemple je pourrais utiliser le pilote Fast Path à mettre en œuvre la politique de pare-feu, mais ensuite passer tous les «accepté» les paquets de retour au système de voie lente pour l'intrusion de vérification, de détection de virus, ou tout ce qui est nécessaire. Paquets acceptables sont ensuite transmis vers le pilote Fast Path pour l'insertion. Ainsi, dans cette configuration tous les «laisser tomber» les paquets sont traités via la procédure Fast Path, tandis que les paquets acceptés interagir avec un élément de tracé lent.

Comme une note côté, vous avez besoin de garder l'info ci-dessus à l'esprit lorsque l'on considère toutes les implémentations vNetwork, et pas seulement les pare-feu. L'API vNetwork peut également être utilisé pour l'application des politiques, la QoS, la collecte de statistiques réseau, etc Par exemple, la mise en œuvre tout premier vNetwork était réellement Lab Manager de VMware. Cet outil est utilisé pour l'approvisionnement en self-service et ne contient pas de composant pare-feu (ce qui est implémentée via vShield).

Résumé

Alors un produit qui s'intègre à VMware VMsafe peut strictement être une «voie lente» mise en œuvre, il est hautement improbable que tout produit peut être considérée uniquement comme une "voie rapide" mise en œuvre. Tout produit parcours rapide est le plus susceptible d'être un hybride. C'est juste une question de combien de code existe dans la "voie rapide" espace par rapport à la «voie lente» de l'espace. Quand un produit prétend soutenir voie rapide, vous avez besoin de creuser un peu plus loin pour analyser la mise en œuvre afin d'identifier les avantages de performance réel.

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

18 mai 2010

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.