L'observation des recommandations en matière de sécurité contribue à garantir l'intégrité de votre déploiement vSphere.

Recommandations générales de sécurité de la mise en réseau vSphere

En matière de sécurisation de votre environnement réseau, la première étape consiste à respecter les recommandations de sécurité générales s'appliquant à la mise en réseau vSphere. Vous pouvez ensuite vous concentrer sur des points spéciaux, comme la sécurisation du réseau à l'aide de pare-feu ou du protocole IPsec.

Recommandations pour sécuriser un environnement de mise en réseau vSphere

  • Le protocole STP (Spanning Tree Protocol) détecte les boucles et les empêche de former la topologie réseau. Les commutateurs virtuels VMware empêchent les boucles d'une autre manière, mais ne prennent pas en charge le protocole STP directement. Lorsque des modifications de topologie réseau se produisent, un certain temps est nécessaire (30 à 50 secondes) au réseau pour réapprendre la topologie. Pendant ce temps, aucun trafic ne peut être transmis. Pour éviter ces problèmes, les fournisseurs de réseaux ont créé des fonctionnalités pour les ports de commutateur afin de continuer à transférer le trafic. Pour plus d'informations, reportez-vous à l'article de la base de connaissances VMware à l'adresse https://kb.vmware.com/s/article/1003804. Consultez la documentation de votre fournisseur de réseau pour connaître les configurations de réseau et de matériel de mise en réseau appropriées.
  • Assurez-vous que le trafic NetFlow d'un Distributed Virtual Switch est envoyé uniquement aux adresses IP de collecteurs autorisés. Les exportations Netflow ne sont pas chiffrées et peuvent contenir des informations sur le réseau virtuel. Ces informations augmentent le risque d’affichage et de capture d’informations sensibles en transit par des pirates. Si une exportation Netflow est nécessaire, assurez-vous que toutes les adresses IP Netflow cibles sont correctes.
  • Assurez-vous que seuls les administrateurs autorisés ont accès aux composants de mise en réseau en utilisant des contrôles d'accès basés sur rôles. Par exemple, les administrateurs de machines virtuelles ne devraient pouvoir accéder qu'aux groupes de ports dans lesquels leurs machines virtuelles résident. Donnez aux administrateurs réseau des autorisations pour tous les composants du réseau virtuel, mais pas d'accès aux machines virtuelles. Le fait de limiter l'accès réduit le risque d'erreur de configuration, qu'elle soit accidentelle ou délibérée, et renforce les concepts essentiels de sécurité que sont la séparation des devoirs et le moindre privilège.
  • Assurez-vous que les groupes de ports ne sont pas configurés sur la valeur du VLAN natif. Les commutateurs physiques sont souvent configurés avec un VLAN natif et ce VLAN natif est souvent VLAN 1 par défaut. ESXi ne dispose pas d'un VLAN natif. Les trames pour lesquelles le VLAN est spécifié dans le groupe de ports comportent une balise, mais les trames pour lesquelles le VLAN n'est pas spécifié dans le groupe de ports ne sont pas balisées. Cela peut créer un problème, car les machines virtuelles balisées avec un 1 appartiendront au VLAN natif du commutateur physique.

    Par exemple, les trames sur le VLAN 1 d'un commutateur physique Cisco ne sont pas balisées car VLAN1 est le VLAN natif sur ce commutateur physique. Cependant, les trames de l'hôte ESXi qui sont spécifiées en tant que VLAN 1 sont balisées avec un 1. Par conséquent, le trafic de l'hôte ESXi destiné au VLAN natif n'est pas routé correctement, car il est balisé avec un 1 au lieu de ne pas être balisé. Le trafic du commutateur physique provenant du VLAN natif n'est pas visible car il n'est pas balisé. Si le groupe de ports du commutateur virtuel ESXi utilise l'ID du VLAN natif, le trafic provenant des machines virtuelles sur ce port n'est pas visible pour le VLAN natif sur le commutateur, car le commutateur attend un trafic non balisé.

  • Assurez-vous que les groupes de ports ne sont pas configurés sur des valeurs VLAN réservées par les commutateurs physiques en amont. Les commutateurs physiques réservent certains ID de VLAN à des fins internes, et n'autorisent souvent pas le trafic configuré sur ces valeurs. Par exemple, les commutateurs Cisco Catalyst réservent généralement les VLAN 1001 à 1024 et 4094. Utiliser un VLAN réservé peut entraîner un déni de service sur le réseau.
  • Assurez-vous que les groupes de ports ne sont pas configurés sur VLAN 4095, sauf si vous utilisez le balisage d'invité virtuel (VGT). Définir un groupe de ports sur VLAN 4095 active le mode VGT. Dans ce mode, le commutateur virtuel transmet toutes les trames du réseau à la machine virtuelle sans modifier les balises VLAN , en laissant la machine virtuelle les traiter.
  • Restreignez les remplacements de configuration de niveau de port sur un commutateur virtuel distribué. Les remplacements de configuration de niveau de port sont désactivés par défaut. Lorsque des remplacements sont activés, vous pouvez utiliser des paramètres de sécurité qui sont différents pour la machine virtuelle et le niveau des groupes de ports. Certaines machines virtuelles requièrent des configurations uniques, mais la surveillance est essentielle. Si les remplacements ne sont pas surveillés, n'importe quel utilisateur parvenant à accéder à une machine virtuelle avec une configuration de commutateur virtuel distribué peut tenter d'exploiter cet accès.
  • Assurez-vous que le trafic en miroir du port du commutateur virtuel distribué est envoyé uniquement aux ports du collecteur ou aux VLAN autorisés. Un vSphere Distributed Switch peut mettre en miroir le trafic provenant d'un port vers un autre pour permettre aux périphériques de capture de paquets de collecter des flux de trafic spécifiques. La mise en miroir des ports envoie une copie de l'ensemble du trafic spécifié dans un format non-chiffré. Ce trafic mis en miroir contient les données complètes dans les paquets capturés, et ceci peut compromettre les données s'il est mal dirigé. Si la mise en miroir des ports est requise, vérifiez que tous les ID de VLAN, de port et de liaison montante de destination de la mise en miroir des ports sont corrects.

Étiquetage des composants de mise en réseau vSphere

L'identification des différents composants de votre architecture de mise en réseau vSphere est critique et contribue à garantir qu'aucune erreur n'est introduite lors du développement de votre réseau.

Suivez ces recommandations :

  • Assurez-vous que les groupes de ports sont configurés avec une étiquette de réseau claire. Ces étiquettes servent de descripteur fonctionnel pour le groupe de ports et vous aident à identifier la fonction de chaque groupe de ports car le réseau devient plus complexe.
  • Assurez-vous que chaque vSphere Distributed Switch dispose d'une étiquette réseau qui indique clairement la fonction ou le sous-réseau IP du commutateur. Cette étiquette sert de descripteur fonctionnel du commutateur, tout comme un commutateur physique nécessite un nom d'hôte. Par exemple, vous pouvez étiqueter le commutateur comme étant interne pour indiquer qu'il est dédié à la mise en réseau interne. Vous ne pouvez pas modifier l'étiquette d'un commutateur virtuel standard.

Documenter et vérifier l'environnement VLAN vSphere

Vérifiez votre environnement VLAN régulièrement pour éviter les problèmes. Documentez entièrement l'environnement VLAN et assurez-vous que les ID VLAN ne sont utilisés qu'une seule fois. Votre documentation peut simplifier le dépannage et est essentielle lorsque vous souhaitez développer l'environnement.

Procédure

  1. Assurez-vous que tous les vSwitch et ID VLAN sont entièrement documentés
    Si vous utilisez le balisage VLAN sur un commutateur virtuel, les ID doivent correspondre aux ID des commutateurs VLAN externes en amont. Si les ID VLAN ne sont pas entièrement suivis, une réutilisation erronée d'ID peut permettre l'établissement de trafic entre des machines physiques et virtuelles non appropriées. De même, si les ID VLAN sont erronés ou manquants, le trafic entre les machines physiques et virtuelles peut être bloqué à un endroit où le trafic devrait normalement passer.
  2. Assurez-vous que les ID VLAN de tous les groupes de ports virtuels distribués (instances de dvPortgroup) sont entièrement documentés.
    Si vous utilisez le balisage VLAN sur un dvPortgroup, les ID doivent correspondre aux ID des commutateurs VLAN externes en amont. Si les ID VLAN ne sont pas entièrement suivis, une réutilisation erronée d'ID peut permettre l'établissement de trafic entre des machines physiques et virtuelles non appropriées. De même, si les ID VLAN sont erronés ou manquants, le trafic entre les machines physiques et virtuelles peut être bloqué à un endroit où le trafic devrait normalement passer.
  3. Assurez-vous que les ID VLAN de tous les commutateurs virtuels distribués sont entièrement documentés.
    Les VLAN privés (PVLAN) des commutateurs virtuels distribués nécessitent des ID VLAN principaux et secondaires. Ces ID doivent correspondre aux ID des commutateurs PVLAN externes en amont. Si les ID VLAN ne sont pas entièrement suivis, une réutilisation erronée d'ID peut permettre l'établissement de trafic entre des machines physiques et virtuelles non appropriées. De même, si des ID PVLAN sont erronés ou manquants, le trafic entre les machines physiques et virtuelles peut être bloqué là où vous souhaitez faire passer le trafic.
  4. Vérifiez que les liaisons de jonction VLAN sont connectées uniquement à des ports de commutateur physiques qui fonctionnent comme des liaisons de jonction.
    Lorsque vous connectez un commutateur virtuel à un port de jonction VLAN, vous devez configurer correctement le commutateur virtuel et le commutateur physique au port de liaison montante. Si le commutateur physique n'est pas configuré correctement, les trames avec l'en-tête VLAN 802.1q sont renvoyées vers un commutateur qui n'attend par leur arrivée.

Adoption de pratiques d’isolation réseau dans vSphere

Les pratiques d’isolation réseau renforcent la sécurité du réseau dans votre environnement vSphere.

Isoler le réseau de gestion vSphere

Le réseau de gestion vSphere donne accès à l'interface de gestion vSphere sur chaque composant. Les services s'exécutant sur l'interface de gestion offrent la possibilité pour un pirate d'obtenir un accès privilégié aux systèmes. Les attaques à distance sont susceptibles de commencer par l'obtention d'un accès à ce réseau. Si un pirate obtient accès au réseau de gestion, cela lui fournit une base pour mener d'autres intrusions.

Contrôlez strictement l'accès au réseau de gestion en le protégeant au niveau de sécurité de la machine virtuelle la plus sécurisée s'exécutant sur un hôte ou un cluster ESXi. Quelle que soit la restriction du réseau de gestion, les administrateurs doivent avoir accès à ce réseau pour configurer les hôtes ESXi et le système vCenter Server.

Placez le groupe de ports de gestion vSphere dans un VLAN dédié sur un commutateur standard commun. Le trafic de production (VM) peut partager le commutateur standard si le groupe de ports de gestion vSphere du VLAN n'est pas utilisé par les machines virtuelles de production.

Vérifiez que le segment de réseau n'est pas routé, à l'exception des réseaux dans lesquels se trouvent d'autres entités de gestion. Le routage d'un segment de réseau peut sembler pertinent pour vSphere Replication. Assurez-vous notamment que le trafic des machines virtuelles de production ne peut pas être routé vers ce réseau.

Contrôlez strictement l'accès à la fonctionnalité de gestion en utilisant l'une des approches suivantes.
  • Pour accéder au réseau de gestion dans les environnements particulièrement sensibles, configurez une passerelle contrôlée ou une autre méthode contrôlée. Par exemple, rendez obligatoire l'utilisation d'un VPN pour la connexion des administrateurs au réseau de gestion. N'autorisez l'accès au réseau de gestion qu'aux administrateurs approuvés.
  • Configurez des hôtes bastions qui exécutent des clients de gestion.

Isoler le trafic de stockage

Assurez-vous que le trafic de stockage IP est isolé. Le stockage IP inclut iSCSI et NFS. Les machines virtuelles peuvent partager des commutateurs virtuels et des VLAN avec les configurations de stockage IP. Ce type de configuration peut exposer du trafic de stockage IP à des utilisateurs de machine virtuelle non autorisés.

Le stockage IP est généralement non chiffré. Toute personne ayant accès à ce réseau peut afficher le trafic de stockage IP. Pour empêcher les utilisateurs non autorisés à voir le trafic de stockage IP, séparez logiquement le trafic du réseau de stockage IP du trafic de production. Configurez les adaptateurs de stockage IP sur des VLAN ou des segments de réseau séparés du réseau de gestion VMkernel pour empêcher les utilisateurs non autorisés d'afficher le trafic.

Isoler le trafic vMotion

Les informations de migration vMotion sont transmises en texte brut. Toute personne ayant accès au réseau sur lequel ces informations circulent peut les voir. Les pirates potentiels peuvent intercepter du trafic vMotion pour obtenir le contenu de la mémoire d'une machine virtuelle. Ils peuvent également transférer une attaque MITM dans laquelle le contenu est modifié pendant la migration.

Séparez le trafic vMotion du trafic de production sur un réseau isolé. Configurez le réseau de manière qu'il soit non routable, c'est-à-dire assurez-vous qu'aucun routeur de niveau 3 n'étend ce réseau et d'autres réseaux, pour empêcher un accès au réseau de l'extérieur.

Utilisez un VLAN dédié sur un commutateur standard commun pour le groupe de ports vMotion. Le trafic de production (VM) peut utiliser le même commutateur standard si le groupe de ports vMotion du VLAN n'est pas utilisé par les machines virtuelles de production.

Isoler le trafic vSAN

Lors de la configuration de votre réseau vSAN, isolez le trafic vSAN sur son propre segment de réseau de couche 2. Vous pouvez effectuer cette isolation en utilisant des commutateurs ou des ports dédiés, ou en utilisant un VLAN.

Utiliser des commutateurs virtuels avec vSphere Network Appliance API, uniquement si nécessaire

Ne configurez pas votre hôte pour envoyer des informations sur le réseau à une machine virtuelle, sauf si vous utilisez des produits qui utilisent vSphere Network Appliance API (DvFilter). Si vSphere Network Appliance API est activée, un pirate peut tenter de connecter une machine virtuelle au filtre. Cette connexion risque de donner à d'autres machines virtuelles sur l'hôte un accès au réseau.

Si vous utilisez un produit qui fait appel à cette API, vérifiez que l'hôte est correctement configuré. Reportez-vous aux sections sur DvFilter dans la documentation Développement et déploiement des solutions vSphere, des vServices et des agents ESX. Si votre hôte est configuré pour utiliser l'API, assurez-vous que la valeur du paramètre Net.DVFilterBindIpAddress correspond au produit qui utilise l'API.

Procédure

  1. Accédez à l'hôte dans l'inventaire de vSphere Client.
  2. Cliquez sur Configurer.
  3. Dans Système, cliquez sur Paramètres système avancés.
  4. Faites défiler jusqu'à Net.DVFilterBindIpAddress et vérifiez que le paramètre a une valeur vide.
    L'ordre des paramètres n'est pas strictement alphabétique. Entrez DVFilter dans la zone de texte Filtre pour afficher tous les paramètres associés.
  5. Vérifiez le paramètre.
    • Si vous n'utilisez pas les paramètres DvFilter, assurez-vous que la valeur est vide.
    • Si vous utilisez les paramètres DvFilter, assurez-vous que la valeur du paramètre est correcte. La valeur doit correspondre à celle que le produit faisant appel à DvFilter utilise.