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.