VMWARE ESXi - 5.0.1 User Manual [fr]

Sécurité vSphere

Mise à jour 1

ESXi 5.0

vCenter Serveur 5.0

Ce document prend en charge la version de chacun des produits répertoriés, ainsi que toutes les versions publiées par la suite jusqu'au remplacement dudit document par une nouvelle édition. Pour rechercher des éditions plus récentes de ce document, rendezvous sur : http://www.vmware.com/fr/support/pubs.

FR-000789-00

Sécurité vSphere

Vous trouverez la documentation technique la plus récente sur le site Web de VMware à l'adresse :

http://www.vmware.com/fr/support/pubs/

Le site Web de VMware propose également les dernières mises à jour des produits.

N’hésitez pas à nous transmettre tous vos commentaires concernant cette documentation à l’adresse suivante :

docfeedback@vmware.com

Copyright © 2009–2012 VMware, Inc. Tous droits réservés. Ce produit est protégé par les lois américaines et internationales relatives au copyright et à la propriété intellectuelle. Les produits VMware sont protégés par un ou plusieurs brevets répertoriés à l'adresse http://www.vmware.com/go/patents-fr.

VMware est une marque déposée ou une marque de VMware, Inc. aux États-Unis et/ou dans d'autres juridictions. Toutes les autres marques et noms mentionnés sont des marques déposées par leurs propriétaires respectifs.

VMware, Inc.

3401 Hillview Ave. Palo Alto, CA 94304 www.vmware.com

2 VMware, Inc.

VMware, Inc.

100-101 Quartier Boieldieu 92042 Paris La Défense France www.vmware.com/fr

Table des matières

À propos de ce guide 5

Sécurité pour systèmes ESXi 7

Architecture ESXi et fonctions de sécurité 7 Ressources de sécurité et informations 14

Sécurisation des configurations d' ESXi 15

Sécurisation du réseau avec des pare-feu 15 Sécurisation des machines virtuelles avec des VLAN 20 Sécurisation des ports de commutateurs standard 25 Sécurité du protocole Internet 27 Sécurisation du stockage iSCSI 31 Niveau de sécurité du chiffrement 34

Sécurisation de l'interface de gestion 35

Recommandations générales de sécurité 35 ESXi 36 ESXi 41

Authentification et gestion d'utilisateurs 43

Sécuriser ESXi via l'authentification et les autorisations 43 Gestion des utilisateurs de vSphere 44 Gestion des groupes de vSphere 48 Exigences de mots de passe 50 Assignation d'autorisations 50 Attribution de rôles 62 Utiliser Active Directory pour gérer les utilisateurs et les groupes 67 Utiliser vSphere Authentication Proxy 69

VMware, Inc.

Chiffrement et certificats de sécurité pour ESXi et vCenter Server 75

Activer le contrôle de certificats et vérifier les empreintes hôtes 76 Générer de nouveaux certificats pour ESXi 76 Remplacer un certificat d'hôte par défaut par un certificat signé par une autorité de certification 77 Télécharger un certificat SSL et une clé à l'aide d'un HTTPS PUT 78 Charger une clé SSH à l'aide d'un HTTPS PUT 78 Charger une clé SSH à l'aide d'une commande vifs 79 Configurer les délais d'attente SSL 79 Modifier les paramètres proxy Web ESXi 80

Mode verrouillage 85

Comportement du mode verrouillage 86

Sécurité vSphere

Configurations du mode verrouillage 86 Activation du mode verrouillage à l'aide de vSphere Client 87 Activation du mode verrouillage à partir de l'interface utilisateur de la console directe 87 Utilisation du Shell ESXi 88

Meilleures pratiques pour la sécurité des machines virtuelles et des hôtes 91

Recommandations destinées aux machines virtuelles 91 Considérations relatives à la sécurité d'Auto Deploy 96 Niveau de sécurité et complexité des mots de passe de l'hôte 96

Index 99

4 VMware, Inc.

À propos de ce guide

Sécurité vSphere fournit des informations sur la sécurisation de votre environnement vSphere® pour VMware® vCenter® Server et VMware ESXi.

Pour vous permettre de protéger votre installation ESXi™ , cette documentation décrit les fonctions de sécurité intégrées à ESXi et les mesures que vous pouvez prendre pour la protéger des attaques.

Public cible

Ces informations s'adressent à toutes les personnes désirant protéger leur configuration ESXi. Elles sont destinées aux administrateurs Windows ou Linux expérimentés qui maîtrisent les technologies de machine virtuelle et les opérations de centre de données.

VMware, Inc.

Sécurité vSphere

6 VMware, Inc.

Sécurité pour systèmes ESXi 1

CPU

mémoire

stockage

réseau de matériel

carte

ESXi

virtuel

machine

virtuel

machine

virtuel

machine

virtuel

machine

VMware Virtualisation Couche (VMkernel)

Virtuel Mise en réseau Couche

ESXi est développé avec une priorité de sécurité renforcée. VMware garantit la sécurité de l'environnement ESXi et entoure l'architecture système d'un niveau élevé de sécurité.

Ce chapitre aborde les rubriques suivantes :

« Architecture ESXi et fonctions de sécurité », page 7

« Ressources de sécurité et informations », page 14

Architecture ESXi et fonctions de sécurité

Les composants et l'architecture globale d'ESXi sont conçus pour garantir la sécurité du système ESXi entier.

Sous l'angle de la sécurité, ESXi contient trois composants principaux : la couche de virtualisation, les machines virtuelles et la couche réseau virtuelle.

Figure 1-1. Architecture ESXi

VMware, Inc.

Sécurité vSphere

Sécurité et couche de virtualisation

VMware a conçu la couche de virtualisation (appelée VMkernel) pour l'exécution des machines virtuelles. Cette couche contrôle les composants matériels que les hôtes utilisent et planifie l'allocation des ressources matérielles sur les différentes machines virtuelles. Comme VMkernel est totalement dédié à la prise en charge des machines virtuelles uniquement, l'interface avec VMkernel est strictement limitée à l'API nécessaire à la gestion des machines virtuelles.

ESXi offre une protection VMkernel supplémentaire pour les fonctions suivantes :

Durcissement de la mémoire

Intégrité du module noyau

TPM (Trusted Platform Module)

Le noyau ESXi, les applications utilisateur et les composants exécutables (pilotes et bibliothèques, par exemple) se trouvent à des emplacements mémoire aléatoires, non prévisibles. Cette fonction, associée aux protections mémoire des microprocesseurs, rend plus difficile l'utilisation de la mémoire par un code malveillant à des fins d'exploitation des vulnérabilités.

Grâce à la signature numérique, l'intégrité et l'authenticité des modules, pilotes et applications sont les mêmes que si ces éléments étaient chargés par VMkernel. Cette signature permet à ESXi d'identifier les fournisseurs des modules, pilotes ou applications concernés, et de vérifier s'ils sont dotés d'une certification VMware.

Chaque fois qu'ESXi démarre, il mesure VMkernel et un sous-ensemble des modules chargés (VIB) et stocke les mesures dans le PCR (Platform Configuration Register) 20 du module TPM. Ce comportement est activé par défaut et ne peut pas être désactivé. Le support matériel de cette fonction est complètement testé et pris en charge par VMware et ses partenaires OEM.

REMARQUE Les VIB ne sont pas tous mesurés dans le cadre de ce processus.

La fonction VMware TPM/TXT qui exploite le support matériel totalement testé est adaptée à une validation technique qui montre la surveillance de certaines valeurs PCR TPM en signalant les modifications de valeur entre deux redémarrages. Des solutions tierces peuvent utiliser cette fonction pour détecter les modifications des mesures VIB stockées dans ces PCR dans les cas suivants :

Endommagement des images mesurées

Mises à jour inattendues ou non autorisées ou autres types de modifications apportées aux images mesurées

Sécurité et machines virtuelles

Les machines virtuelles sont les conteneurs dans lesquels sont exécutés les systèmes d'exploitation invités et les applications. Dès la conception, toutes les machines virtuelles VMware sont isolées les unes des autres. Cette isolation permet l'exécution en toute sécurité de plusieurs machines virtuelles malgré le partage de composants matériels. Ces machines affichent à la fois une bonne capacité d'accès aux composants matériels et des performances ininterrompues.

Même si un utilisateur possède des privilèges d'administrateur d'accès au système d'exploitation invité d'une machine virtuelle, il ne peut pas contourner cette couche d'isolation pour accéder à une autre machine virtuelle sans posséder les privilèges explicitement accordées par l'administrateur système ESXi. Avec l'isolation des machines virtuelles, en cas de défaillance d'un système d'exploitation invité, les autres machines virtuelles de l'hôte continuent de fonctionner. La panne du système d'exploitation invité n'affecte pas :

La capacité des utilisateurs à accéder aux autres machines virtuelles

8 VMware, Inc.

CPU mémoire disque réseau et

cartes vidéo

SCSI

contrôleur

souris CD/DVD clavier

Machine virtuelle

Système d'exploitation

Ressources de la machine virtuelle

app app app app app

Matériel - carte réseau

relie des machines virtuelles au réseau physique

Réseau physique

virtuel Mise en réseau carte

ESXi

Machine virtuelle

virtuel Mise en

réseau carte

Machine virtuelle

VMkernel

Virtuel Mise en réseau Couche

Commutateur virtuel

relie des machines virtuelles entre elles

Chapitre 1 Sécurité pour systèmes ESXi

La capacité des machines virtuelles opérationnelles à accéder aux ressources dont elles ont besoin

Les performances des autres machines virtuelles

Chaque machine virtuelle est isolée des autres machines virtuelles exécutées sur le même équipement. Bien que les machines virtuelles partagent des ressources physiques (unité centrale, mémoire ou dispositifs d'E/S, par exemple), un système d'exploitation invité de machine virtuelle individuelle ne peut détecter aucun périphérique autre que les périphériques virtuels mis à sa disposition.

Figure 1-2. Isolation des machines virtuelles

VMkernel s'interpose entre les ressources physiques ; par ailleurs, tous les accès aux composants matériels s'effectuent via VMkernel ; les machines virtuelles ne peuvent donc pas contourner ce niveau d'isolation.

Une machine physique communique avec les autres machines d'un réseau via l'utilisation d'un adaptateur réseau. De la même façon, une machine virtuelle communique avec les autres machines virtuelles du même hôte via un commutateur virtuel. Une machine virtuelle communique également avec le réseau physique (y compris avec les machines virtuelles situées sur d'autres hôtes ESXi) via un adaptateur réseau physique.

Figure 1-3. Mise en réseau virtuel via l'utilisation de commutateurs virtuels

Les caractéristiques suivantes s'appliquent à l'isolation de machines virtuelles au sein d'un contexte réseau :

Si une machine virtuelle ne partage pas de commutateur virtuel avec une autre machine virtuelle, elle est totalement isolée des réseaux virtuels de l'hôte.

Si aucun adaptateur réseau physique n'est configurée pour une machine virtuelle, celle-ci est totalement isolée des réseaux physiques.

Si vous utilisez les mêmes mesures de sécurité (pare-feu, logiciel anti-virus, notamment) pour assurer la protection d'une machine virtuelle d'un réseau que celles destinées à protéger une machine physique, la machine virtuelle bénéficie du même niveau de sécurité que la machine physique.

VMware, Inc. 9

Sécurité vSphere

Vous pouvez renforcer la protection des machines virtuelles via la configuration de réservations de ressources et de limites sur l'hôte. Par exemple, grâce aux contrôles de ressources détaillés disponibles dans ESXi, vous pouvez configurer une machine virtuelle afin qu'elle puisse systématiquement recevoir 10 % minimum des ressources en unité centrale de l'hôte, mais sans jamais excéder 20 %.

Les réservations et limites de ressources protègent les machines virtuelles contre toute diminution de performances résultant de la consommation excessive, par une autre machine virtuelle, des ressources matérielles partagées. Par exemple, si l'une des machines virtuelles d'un hôte subit une attaque de déni de service (DoS), la limite de ressource appliquée à cette machine évite que les autres machines virtuelles ne soient affectées par la capture d'une quantité importante de ressources matérielles. De la même façon, la réservation de ressources appliquée à chaque machine virtuelle permet, en cas de forte demande de ressources émanant de la machine virtuelle cible de l'attaque DoS, de préserver suffisamment de ressources sur les autres machines virtuelles pour leur permettre de continuer à fonctionner.

Par défaut, ESXi impose une réservation de ressources via l'application d'un algorithme de distribution qui répartit les ressources hôte disponibles de façon équitable entre les différentes machines virtuelles, tout en conservant un certain pourcentage de ressources en vue de leur utilisation par les autres composants système. Ce comportement par défaut offre une protection naturelle efficace contre les attaques de type DoS et DDoS (Distributed Denial of Service). Vous pouvez définir les réservations et limites de ressources individuellement, ce qui permet de personnaliser le comportement par défaut pour obtenir une distribution différenciée au sein de la configuration de machines virtuelles.

Sécurité et couche réseau virtuelle

La couche de réseau virtuelle inclut des adaptateurs réseau virtuelles et des commutateurs virtuels. ESXi utilise la couche réseau virtuelle pour les communications entre les machines virtuelles et leurs utilisateurs. Par ailleurs, les hôtes utilisent cette couche pour communiquer avec les SAN iSCSI, les espaces de stockage NAS, entre autres.

Les méthodes utilisées pour sécuriser un réseau de machines virtuelles dépendent du système d'exploitation invité installé, de la présence ou non d'un environnement sécurisé, ainsi que d'un certain nombre d'autres facteurs. Les commutateurs virtuels offrent un niveau de protection élevé lorsqu'ils sont utilisés avec d'autres mesures de sécurité (installation de pare-feu, notamment).

ESXi prend également en charge les réseaux VLAN IEEE 802.1q, que vous pouvez utiliser pour renforcer la protection du réseau de machines virtuelles ou la configuration de stockage. Les VLAN permettent de segmenter un réseau physique : ainsi, deux machines du même réseau physique peuvent s'envoyer mutuellement des paquets ou en recevoir (sauf s'ils se trouvent sur le même réseau VLAN).

10 VMware, Inc.

réseau de matériel carte 1

Mise en réseau externe Mise en réseau interne

réseau de matériel

carte 2

ESXi

Machine virtuelle 1

serveur de pare-feu

serveur Web

serveur d'applications

serveur de pare-feu

commutateur standard commutateur standard

commutateur standard

Machine virtuelle 2

Machine virtuelle 3

Machine virtuelle 4

Chapitre 1 Sécurité pour systèmes ESXi

Créer une DMZ réseau sur un hôte ESXi

La création d'une zone démilitarisée (DMZ) réseau sur un hôte est un exemple d'utilisation des fonctions d'isolation et de mise en réseau virtuel d'ESXi pour configurer un environnement sécurisé.

Figure 1-4. DMZ configurée sur un hôte ESXi

Dans cet exemple, quatre machines virtuelles sont configurées en vue de créer une zone démilitarisée virtuelle sur le commutateur standard 2 :

les machines virtuelles 1 et 4 sont équipées d'un pare-feu et sont connectées à des adaptateurs virtuels via des commutateurs standard. Ces deux machines virtuelles font l'objet d'un multihébergement.

La machine virtuelle 2 est exécutée en tant que serveur Web, tandis que la machine virtuelle 3 est exécutée en tant que serveur d'applications. Ces deux machines virtuelles font l'objet d'un hébergement mono.

Le serveur Web et le serveur d'applications occupent la DMZ entre les deux pare-feu. Le passage entre ces deux éléments est le commutateur standard 2, qui connecte les pare-feu aux serveurs. Ce commutateur ne possède pas de connexion directe aux éléments situés hors de la zone démilitarisée ; il est isolé du trafic externe via les deux pare-feu.

D'un point de vue opérationnel, le trafic externe Internet entre dans la machine virtuelle 1 via l'adaptateur réseau 1 (acheminé par le commutateur standard 1) ; il est alors vérifié par le pare-feu installé sur cette machine. Si le pare-feu autorise le trafic, celui-ci est acheminé vers le commutateur standard situé au sein de la zone démilitarisée (commutateur standard 2). Puisque le serveur Web et le serveur d'applications sont également connectés à ce commutateur, ils peuvent traiter des requêtes externes.

Le commutateur standard 2 est également connecté à la machine virtuelle 4. Cette machine virtuelle permet de bénéficier d'un pare-feu entre la DMZ et le réseau interne de l'entreprise. Ce pare-feu filtre les paquets en provenance du serveur Web et du serveur d'applications. Si un paquet est vérifié, il est acheminé vers l'adaptateur réseau 2 via le commutateur standard 3. L'adaptateur réseau 2 est connecté au réseau interne de l'entreprise.

Lorsque vous créez une DMZ sur un seul hôte, vous pouvez utiliser des pare-feu assez légers. Dans cette configuration, une machine virtuelle ne peut pas exercer un contrôle direct sur une autre machine virtuelle, ni accéder à sa mémoire ; toutefois, toutes les machines virtuelles restent connectées via un réseau virtuel. Or, ce réseau peut être utilisé pour la propagation de virus ou être la cible d'autres types d'attaques. La sécurité des machines virtuelles dans la zone démilitarisée revient donc à séparer les machines physiques connectées au même réseau.

VMware, Inc. 11

réseau physique

adaptateurs

Externe

Mise en réseau 1

Interne

Mise en réseau 2

Externe

Mise en réseau 2

Interne

Mise en réseau 1

ESXi

VM 2

interne

utilisateur

VM 3

interne

utilisateur

VM 4

interne

utilisateur

VM 5

interne

utilisateur

VM 6

pare-feu

serveur

VM 7

Web

serveur

VM 8

pare-feu

serveur

VM 1

FTP

serveur

Mise en réseau interneMise en réseau externe DMZ

Sécurité vSphere

Création de plusieurs réseaux sur un hôte ESXi

Le système ESXi a été conçu pour vous permettre de connecter certains groupes de machines virtuelles au réseau interne, ainsi que d'autres groupes au réseau externe, et enfin d'autres groupes aux deux réseaux, le tout sur le même hôte. Cette capacité est une extension de l'isolation de machines virtuelles ; elle est associée à une optimisation de la planification d'utilisation des fonctions de réseau virtuel.

Figure 1-5. Réseaux externes, réseaux internes et DMZ configurée sur un hôte ESXi unique

Dans la figure, l'administrateur système a configuré un hôte dans trois zones différentes de machine virtuelle : sur le serveur FTP, dans les machines virtuelles et dans la zone démilitarisée (DMZ). Chacune de ces zones a une fonction spécifique.

Serveur FTP

La machine virtuelle 1 est configurée avec logiciel FTP et sert de zone de rétention des données envoyées de et vers des ressources extérieures (formulaires et collatéraux localisés par un fournisseur, par exemple).

Cette machine virtuelle est associée à un réseau externe uniquement. Elle possède son propre commutateur virtuel et sa propre carte de réseau physique, qui lui permettent de se connecter au réseau externe 1. Ce réseau est réservé aux serveurs utilisés par l'entreprise pour la réception de données issues de sources externes. Par exemple, l'entreprise peut utiliser le réseau externe 1 pour recevoir un trafic FTP en provenance de leurs fournisseurs, et pour permettre à ces derniers d'accéder aux données stockées sur des serveurs externes via FTP. Outre la machine virtuelle 1, le réseau externe 1 sert les serveurs FTP configurés sur différents hôtes ESXi du site.

12 VMware, Inc.

Chapitre 1 Sécurité pour systèmes ESXi

La machine virtuelle 1 ne partage pas de commutateur virtuel ou de carte de réseau physique avec les machines virtuelles de l'hôte ; par conséquent, les autres machines virtuelles ne peuvent pas acheminer de paquets de et vers le réseau de la machine virtuelle 1. Cette restriction évite les intrusions, qui nécessitent l'envoi de trafic réseau à la victime. Plus important encore : un pirate ne peut pas exploiter la vulnérabilité naturelle du protocole FTP pour accéder aux autres machines virtuelles de l'hôte.

Machines virtuelles internes

DMZ

Les machines virtuelles 2 à 5 sont réservées à une utilisation interne. Ces machines virtuelles traitent et stockent les données confidentielles des entreprises (dossiers médicaux, jugements ou enquêtes sur la fraude, par exemple). Les administrateurs systèmes doivent donc leur associer un niveau maximal de protection.

Elles se connectent au réseau interne 2 via leur propre commutateur virtuel et leur propre carte réseau. Le réseau interne 2 est réservé à une utilisation interne par le personnel approprié (responsables de dossiers d'indemnisation ou juristes internes, par exemple).

Les machines virtuelles 2 à 5 peuvent communiquer entre elles via le commutateur virtuel ; elles peuvent aussi communiquer avec les machines virtuelles du réseau interne 2 via la carte réseau physique. En revanche, elles ne peuvent pas communiquer avec des machines externes. Comme pour le serveur FTP, ces machines virtuelles ne peuvent pas acheminer des paquets vers ou les recevoir depuis les réseaux des autres machines virtuelles. De la même façon, les autres machines virtuelles de l'hôte ne peuvent pas acheminer des paquets vers ou les recevoir depuis les machines virtuelles 2 à 5.

Les machines virtuelles 6 à 8 sont configurées en tant que zone démilitarisée (DMZ) ; le groupe marketing les utilise pour publier le site Web externe de l'entreprise.

Ce groupe de machines virtuelles est associé au réseau externe 2 et au réseau interne 1. L'entreprise utilise le réseau externe 2 pour les serveurs Web qui hébergent le site Web de l'entreprise et d'autres outils Web destinés à des utilisateurs externes. Le réseau interne 1 est utilisé par le service marketing pour publier le contenu du site Web de l'entreprise, pour effectuer des téléchargements et pour gérer des services tels que des forums utilisateur.

Puisque ces réseaux sont séparés du réseau externe 1 et du réseau interne 2, et que les machines virtuelles n'ont pas de point de contact partagé (commutateurs ou adaptateurs), il n'y a aucun risque d'attaque de ou vers le serveur FTP ou le groupe de machines virtuelles internes.

Grâce à l'isolation des machines virtuelles, à la bonne configuration des commutateurs virtuels et à la séparation des réseaux, l'administrateur système peut inclure les trois zones de machines virtuelles sur le même hôte ESXi et être rassuré quant à l'absence de violations de données ou de ressources.

L'entreprise met en œuvre l'isolation au sein des groupes de machines virtuelles via l'utilisation de plusieurs réseaux internes et externes, et via la séparation des commutateurs virtuels et des adaptateurs réseau physiques de chaque groupe.

Aucun des commutateurs virtuels ne fait le lien entre les différentes zones de machines virtuelles ; l'administrateur système peut donc éliminer tout risque de fuite de paquets d'une zone à l'autre. Au niveau de sa conception même, un commutateur virtuel ne peut pas transmettre directement des paquets vers un autre commutateur virtuel Pour acheminer des paquets d'un commutateur virtuel vers un autre, les conditions suivantes doivent être réunies :

Les commutateurs virtuels doivent être connectés au même réseau local physique.

VMware, Inc. 13

Sécurité vSphere

Les commutateurs virtuels doivent se connecter à une machine virtuelle commune, qui peut être utilisée pour la transmission de paquets.

Or, aucune de ces situations ne se vérifie dans l'exemple de configuration. Si les administrateurs système souhaitent vérifier l'absence de chemin commun de commutateur virtuel, ils peuvent rechercher les éventuels points de contact partagés via l'examen de la disposition des commutateurs réseau dans vSphere Client.

Pour protéger les ressources des machines virtuelles, l'administrateur système diminue le risque d'attaque DoS et DDoS en configurant une réservation de ressources, ainsi qu'une limite applicable à chaque machine virtuelle. Il renforce la protection de l'hôte ESXi et des machines virtuelles en installant des pare-feu sur la partie frontale et la partie principale de la zone démilitarisée (DMZ), en vérifiant que l'hôte est protégé par un pare-feu physique et en configurant les ressources de stockage réseau de telle sorte qu'elles bénéficient toutes de leur propre commutateur virtuel.

Ressources de sécurité et informations

Pour obtenir des informations complémentaires sur la sécurité, consultez le site Web de VMware.

Le tableau répertorie les rubriques liées à la sécurité et indique l'emplacement des informations complémentaires correspondantes.

Tableau 1-1. Ressources de sécurité VMware disponibles sur le Web

Rubrique Ressource

Politique de sécurité VMware, alertes de sécurité actualisées, téléchargements de sécurité et discussions sur des thèmes liés à la sécurité

Politique de l'entreprise en matière de réponse sécuritaire

Politique de support logiciel tiers http://www.vmware.com/fr/support/policies/

Information générale sur la virtualisation et la sécurité

Standards de sécurité et de conformité, ainsi que solutions partenaires et contenu détaillé sur la virtualisation et la conformité

Informations sur la technologie de protection de machines virtuelles VMsafe, incluant une liste de solutions partenaires

http://www.vmware.com/fr/technical-resources/virtualizationtopics/security

http://www.vmware.com/fr/support/policies/security_response.html

VMware s'engage à vous aider à maintenir un environnement sécurisé. Dans ce cadre, les problèmes de sécurité sont corrigés rapidement. La politique VMware en matière de réponse sécuritaire fait état de notre engagement lié à la résolution d'éventuelles vulnérabilités de nos produits.

VMware prend en charge un grand nombre de systèmes de stockage et d'agents logiciels (tels que les agents de sauvegarde ou les agents de gestion système). Vous trouverez la liste des agents, outils et autres logiciels prenant en charge ESXi en cherchant

http://www.vmware.com/vmtn/resources/ les guides de compatibilité

ESXi. Il existe sur le marché un nombre de produits et de configurations tel

quel VMware ne peut pas tous les tester. Si un produit ou une configuration spécifique ne figure pas dans l'un des guides de compatibilité, contactez le Support technique, qui pourra vous aider à résoudre les problèmes rencontrés ; en revanche, il ne pourra pas vous garantir que ce produit ou cette configuration peut être utilisé. Vous devez toujours évaluer les risques de sécurité liés aux produits ou aux configurations non pris en charge.

Centre virtuel de ressources techniques de sécurité VMware

http://www.vmware.com/fr/technical-resources/virtualizationtopics/security

http://www.vmware.com/fr/technical-resources/virtualizationtopics/security/compliance

http://www.vmware.com/fr/technical-resources/virtualizationtopics/security/vmsafe/security_technology

14 VMware, Inc.

Sécurisation des configurations d'

ESXi 2

Vous pouvez prendre des mesures pour promouvoir un environnement sécurisé pour vos hôtes ESXi, vos machines virtuelles et vos SAN iSCSI. Prenez en compte la planification de la configuration réseau du point de vue de la sécurité et les mesures que vous pouvez prendre pour protéger les composants de votre configuration des attaques.

Ce chapitre aborde les rubriques suivantes :

« Sécurisation du réseau avec des pare-feu », page 15

« Sécurisation des machines virtuelles avec des VLAN », page 20

« Sécurisation des ports de commutateurs standard », page 25

« Sécurité du protocole Internet », page 27

« Sécurisation du stockage iSCSI », page 31

« Niveau de sécurité du chiffrement », page 34

Sécurisation du réseau avec des pare-feu

Les administrateurs de sécurité utilisent des pare-feu pour protéger le réseau ou les composants sélectionnés dans le réseau des intrusions.

Les pare-feu contrôlent l'accès aux périphériques dans leur périmètre en fermant toutes les voies de communication, excepté pour celles que l'administrateur désigne explicitement ou implicitement comme autorisées. Les voies, ou ports, que les administrateurs ouvrent dans le pare-feu autorisent le trafic entre les périphériques sur les différents côtés du pare-feu.

IMPORTANT Le pare-feu ESXi d'ESXi 5.0 n'autorise pas le filtrage par réseau du trafic vMotion. Par conséquent, vous devez établir des règles sur votre pare-feu externe pour vous assurer qu'aucune connexion entrante ne peut être réalisée vers le socket vMotion.

Dans un environnement de machines virtuelles, vous pouvez planifier la disposition des pare-feu entre les composants.

Les machines physiques telles que les systèmes vCenter Server et les hôtes ESXi.

Une machine virtuelle et une autre (par exemple, entre une machine virtuelle agissant en tant que serveur Web externe et une machine virtuelle connectée à votre réseau interne de l'entreprise).

Une machine physique et une machine virtuelle, notamment lorsque vous placez un pare-feu entre un adaptateur réseau physique et une machine virtuelle.

VMware, Inc.

Sécurité vSphere

La manière dont vous utilisez des pare-feu dans une configuration ESXi dépend de la manière dont vous planifiez l'utilisation du réseau et du niveau de sécurité dont certains composants ont besoin. Par exemple, si vous créez un réseau virtuel où chaque machine virtuelle est dédiée à l'exécution d'une suite de tests de référence différents pour le même service, le risque d'accès non autorisé d'une machine virtuelle à une autre est minime. Par conséquent, une configuration où des pare-feu sont présents entre les machines virtuelles n'est pas nécessaire. Cependant, pour empêcher l'interruption d'un test exécuté sur un hôte externe, vous devez définir la configuration afin qu'un pare-feu soit présent au point d'entrée du réseau virtuel pour protéger tout l'ensemble de machines virtuelles.

Pare-feux pour configurations avec vCenter Server

Si vous accédez aux hôtes ESXi via vCenter Server, vous protégez généralement vCenter Server avec un parefeu. Ce pare-feu fournit une protection de base à votre réseau.

Un pare-feu peut se trouver entre les clients et vCenter Server. vCenter Server et les clients peuvent se trouver également derrière un pare-feu, en fonction de votre déploiement. L'important est de s'assurer qu'un pare-feu est présent sur ce que vous considérez être un point d'entrée pour le système.

Pour obtenir la liste complète des ports TCP et UDP, y compris ceux de vSphere vMotion™ et vSphere Fault Tolerance, consultez « Ports TCP et UDP pour l'accès de gestion », page 19.

Les réseaux configurés avec vCenter Server peuvent recevoir des communications via vSphere Client ou des clients de gestion réseau tiers utilisant SDK pour communiquer avec l'hôte. En fonctionnement normal, vCenter Server écoute les données de ses hôtes gérés et de ses clients sur les ports indiqués. vCenter Server suppose également que ses hôtes gérés écoutent les données de vCenter Server sur les ports indiqués. Si un pare-feu est présent entre l'un de ces éléments, vous devez vous assurer que le pare-feu a des ports ouverts pour prendre en charge le transfert des données.

Vous pouvez également inclure des pare-feu à un grand nombre d'autres points d'accès du réseau, en fonction de la manière dont vous envisagez d'utiliser le réseau et du niveau de sécurité nécessaire aux différents périphériques. Sélectionnez les emplacements de vos pare-feu en fonction des risques de sécurité que vous avez identifiés pour votre configuration réseau. Vous trouverez ci-après une liste des emplacements de parefeu commune aux implémentations ESXi.

Entre vSphere Client ou un client de gestion réseau tiers et vCenter Server.

Si vos utilisateurs accèdent aux machines virtuelles via un navigateur Web, entre le navigateur Web et l'hôte ESXi.

Si vos utilisateurs accèdent aux machines virtuelles via vSphere Client, entre vSphere Client et l'hôte ESXi. Cette connexion s'ajoute à la connexion entre vSphere Client et vCenter Server, et elle nécessite un port différent.

Entre vCenter Server et les hôtes ESXi.

Entre les hôtes ESXi de votre réseau. Bien que le trafic entre les hôtes soit généralement considéré comme sécurisé, vous pouvez ajouter des pare-feu entre eux si vous vous inquiétez des défaillances de sécurité de machine à machine.

Si vous ajoutez des pare-feu entre les hôtes ESXi et envisagez de migrer les machines virtuelles entre les serveurs, faites un clonage ou utilisez vMotion. Vous devez également ouvrir des ports dans les pare-feu qui divisent l'hôte source des hôtes cibles afin que la source et les cibles puissent communiquer.

Entre les hôtes ESXi et le stockage réseau tel que le stockage NFS ou iSCSI. Ces ports ne sont pas spécifiques à VMware et vous pouvez les configurer en fonction des spécifications de votre réseau.

16 VMware, Inc.

Chapitre 2 Sécurisation des configurations d' ESXi

Pare-feu pour configurations sans vCenter Server

Si vous connectez des clients directement à votre réseau ESXi au lieu d'utiliser vCenter Server, la configuration de votre pare-feu est assez simple.

Les réseaux configurés sans vCenter Server reçoivent des communications par l'intermédiaire des mêmes types de clients que si vCenter Server était présent : vSphere Client ou des clients de gestion de réseau tiers. Les besoins du pare-feu sont en majeure partie identiques, mais il y a plusieurs différences clés.

Tout comme pour les configurations comprenant vCenter Server, assurez-vous qu'un pare-feu est présent pour protéger votre couche ESXi ou, en fonction de votre configuration, vos clients et votre couche ESXi. Ce pare-feu fournit une protection de base à votre réseau. Les ports du pare-feu que vous utilisez sont identiques à ceux que vous utiliseriez si vCenter Server était présent.

La licence pour ce type de configuration fait partie du module ESXi que vous installez sur chacun des hôtes. Comme la licence réside sur le serveur, un serveur de licences distinct n'est pas nécessaire. Un parefeu entre le serveur de licences et le réseau ESXi n'est donc pas nécessaire.

Connexion à vCenter Server via un pare-feu

Le port que vCenter Server utilise pour écouter le transfert de données de son client est le port 443. Si un parefeu se trouve entre vCenter Server et ses clients, vous devez configurer une connexion au travers de laquelle vCenter Server peut recevoir des données à partir des clients.

Pour permettre à vCenter Server de recevoir des données de vSphere Client, ouvrez le port 443 dans le parefeu pour permettre le transfert de données de vSphere Client vers vCenter Server. Contactez l'administrateur système du pare-feu pour plus d'informations sur la configuration des ports dans un pare-feu.

Si vous utilisez vSphere Client et que vous ne souhaitiez pas utiliser le port 443 comme port pour la communication client à vCenter Server, vous pouvez passer sur un autre port en modifiant les paramètres vCenter Server dans vSphere Client. Pour en savoir plus sur la manière de modifier ces paramètres, consultez la documentation Gestion de vCenter Server et des hôtes.

Connexion à la console de la machine virtuelle via un pare-feu

Lorsque vous connectez votre client à des hôtes ESXi via vCenter Server ou utilisez une connexion directe à l'hôte, certains ports sont requis pour la communication utilisateur et administrateur avec les consoles des machines virtuelles. Ces ports prennent en charge différentes fonctions client, communiquent avec différentes couches sur ESXi et utilisent différents protocoles d'authentification.

Port 902

Il s'agit du port que vCenter Server considère comme disponible pour la réception des données provenant d'ESXi. vSphere Client utilise ce port pour fournir une connexion pour les activités de la souris, du clavier, de l'écran (MKS) du système d'exploitation invité sur les machines virtuelles. C'est par ce port que les utilisateurs interagissent avec les systèmes d'exploitation et les applications invités de la machine virtuelle. Le port 902 est le port que vSphere Client considère comme disponible pour l'interaction avec les machines virtuelles.

VMware, Inc. 17

ESXi

vSphere Client

Port 443

vmware-hostd

vmware-authd

machine virtuelle

fonctions de gestion

machine virtuelle console

Port 903

pare-feu

Sécurité vSphere

Le port 902 connecte vCenter Server à l'hôte via VMware Authorization Daemon (vmware-authd). Ce démon multiplexe les données du port 902 au destinataire approprié pour le traitement. VMware ne prend pas en charge la configuration d'un port différent pour cette connexion.

Port 443

vSphere Client et SDK utilisent ce port pour envoyer des données aux hôtes gérés par vCenter Server. Par conséquent, vSphere Client et SDK, s'ils sont connectés directement à ESXi, utilisent ce port pour prendre en charge toutes les fonctions de gestion relatives au serveur et à ses machines virtuelles. Le port 443 est le port que les clients considèrent comme disponible lors de l'envoi de données à ESXi. VMware ne prend pas en charge la configuration d'un port différent pour ces connexions.

Le port 443 connecte les clients à l'hôte ESXi via le service Web Tomcat ou SDK. Le processus hôte multiplexe les données du port 443 au destinataire approprié pour le traitement.

Port 903

vSphere Client utilise ce port pour fournir une connexion pour les activités MKS du système d'exploitation invité sur les machines virtuelles. C'est par ce port que les utilisateurs interagissent avec les systèmes d'exploitation et les applications invités de la machine virtuelle. Le port 903 est le port que vSphere Client considère comme disponible pour l'interaction avec les machines virtuelles. VMware ne prend pas en charge la configuration d'un port différent pour cette fonction.

Le port 903 connecte vSphere Client à une machine virtuelle spécifique configurée sur ESXi.

L'image qui suit présente les relations entre les fonctions de vSphere Client, les ports et les processus.

Figure 2-1. Utilisation des ports pour les communications client avec ESXi

18 VMware, Inc.

Si un pare-feu se trouve entre votre système vCenter Server et l'hôte géré par vCenter Server, ouvrez les ports 443 et 903 du pare-feu pour permettre le transfert des données aux hôtes ESXi à partir de vCenter Server et aux hôtes ESXi à partir de vSphere Client.

Pour plus d'informations sur la configuration des ports, consultez l'administrateur système du pare-feu.

Chapitre 2 Sécurisation des configurations d' ESXi

Connexion des hôtes ESXi via des pare-feu

Si un pare-feu se trouve entre deux hôtes ESXi et que vous souhaitez autoriser des transactions entre les hôtes ou utiliser vCenter Server pour effectuer des activités sources ou cibles, telles que du trafic vSphere High Availability (vSphere HA), une migration, un clonage ou vMotion, vous devez configurer une connexion par laquelle les hôtes gérés peuvent recevoir des données.

Pour configurer une connexion pour recevoir des données, ouvrez les ports au trafic des services tels que vSphere High Availability, vMotion, et vSphere Fault Tolerance. Reportez-vous à « Ports TCP et UDP pour

l'accès de gestion », page 19 pour obtenir une liste de ports. Consultez l'administrateur système du pare-feu

pour plus d'informations sur la configuration des ports.

Ports TCP et UDP pour l'accès de gestion

vCenter Server, les hôtes ESXi et d'autres composants réseau sont accessibles à l'aide de ports TCP et UDP prédéterminés. Si vous gérez des composants réseau à partir de l'extérieur d'un pare-feu, vous pouvez être invité à reconfigurer le pare-feu pour autoriser l'accès sur les ports appropriés.

Le tableau répertorie les ports TCP et UDP et l'objectif et le type de chaque port. Les ports qui sont ouverts par défaut lors de l'installation sont suivis de la mention « (par défaut) ».

Tableau 2-1. Ports TCP et UDP

Port Objectif Type de trafic

22 (par défaut) Serveur SSH TCP entrant

53 (par défaut) Client DNS UDP entrant et

sortant

68 (par défaut) Client DHCP UDP entrant et

sortant

161 (par défaut) serveur SNMP UDP entrant

80 (par défaut) vSphere Fault Tolerance (FT) (TCP sortant, UDP)

Accès HTTP Port Web TCP non sécurisé par défaut généralement utilisé en association avec

le port 443 comme serveur frontal pour accéder aux réseaux ESXi à partir du Web. Le port 80 redirige le trafic vers une page de destination HTTPS (port 443).

Gestion WS

123 Client NTP UDP sortant

427 (par défaut) Le client CIM utilise le Service Location Protocol, version 2 (SLPv2) pour

rechercher des serveurs CIM.

443 (par défaut) Accès HTTPS

Accès vCenter Server aux hôtes ESXi Port Web SSL par défaut Accès vSphere Client à vCenter Server Accès vSphere Client aux hôtes ESXi Gestion WS Accès vSphere Client à vSphere Update Manager Connexions clients de gestion de réseau tiers à vCenter Server Accès clients de gestion de réseau tiers à des hôtes

902 (par défaut) Accès de l'hôte aux autres hôtes pour la migration et l'approvisionnement

Trafic d'authentification pour ESXi et trafic de la console distante (xinetd/vmware-authd)

Accès vSphere Client aux consoles des machines virtuelles Connexion (pulsation) de mise à niveau d'état (UDP) à partir dESXi vers vCenter

Server

TCP entrant TCP sortant, UDP

UDP entrant et sortant

TCP entrant

TCP entrant et sortant, UDP sortant

VMware, Inc. 19

Sécurité vSphere

Tableau 2-1. Ports TCP et UDP (suite)

Port Objectif Type de trafic

903 Trafic de la console distante généré par l'accès utilisateur aux machines virtuelles

1234, 1235 (par défaut)

2049 Transactions provenant des périphériques de stockage NFS

3260 Transactions vers les périphériques de stockage iSCSI TCP sortant

5900-5964 Protocole RFB qui est utilisé par les outils de gestion tels que VNC UDP entrant et

5988 (par défaut)

5989 (par défaut)

8000 (par défaut)

8100, 8200 (par défaut)

8182 Trafic entre les hôtes pour vSphere High Availability (HA) TCP entrant et

sur un hôte spécifique. Accès vSphere Client aux consoles des machines virtuelles Transactions MKS (xinetd/vmware-authd-mks)

Réplication vSphere TCP sortant

Ce port est utilisé sur l'interface VMkernel.

Transactions CIM sur HTTP TCP entrant

Transactions XML CIM sur HTTPS UDP entrant et

Requêtes de vMotion UDP entrant et

Trafic entre les hôtes pour vSphere Fault Tolerance (FT) TCP entrant et

TCP entrant

UDP entrant et sortant

sortant

sortant, UDP

sortant, UDP entrant et sortant

En plus des ports TCP et UDP, vous pouvez configurer d'autres ports en fonction de vos besoins.

Sécurisation des machines virtuelles avec des VLAN

Le réseau peut être l'une des parties les plus vulnérables d'un système. Votre réseau de machines virtuelles nécessite autant de protection que votre réseau physique. Vous pouvez augmenter la sécurité de votre réseau de machines virtuelles de différentes manières.

Si votre réseau de machines virtuelles est connecté à un réseau physique, il peut être soumis à des défaillances du même degré qu'un réseau constitué de machines physiques. Même si le réseau de machines virtuelles est isolé de tout réseau physique, les machines virtuelles du réseau peuvent être soumises à des attaques d'autres machines virtuelles du réseau. Les contraintes de sécurisation des machines virtuelles sont souvent identiques à celles des machines physiques.

Les machines virtuelles sont isolées les unes des autres. Une machine virtuelle ne peut pas lire ou écrire sur la mémoire d'une autre machine virtuelle, accéder à ses données, utiliser ses applications, etc. Cependant, dans le réseau, toute machine virtuelle ou groupes de machines virtuelles peut toujours être la cible d'un accès non autorisé à partir d'autres machines virtuelles et peut nécessiter une protection supplémentaire par des moyens externes.

Vous pouvez ajouter ce niveau de sécurité de différentes manières.

Ajout d'une protection par pare-feu à votre réseau virtuel en installant et en configurant des pare-feu hébergés sur hôte sur certaines ou la totalité de ses machines virtuelles.

Pour une plus grand efficacité, vous pouvez configurer des réseaux Ethernet privés de machines virtuelles ou des réseaux virtuels. Avec les réseaux virtuels, vous installez un pare-feu hébergé sur hôte sur une machine virtuelle à la tête du réseau virtuel. Cela sert de tampon de protection entre l'adaptateur réseau physique et les machines virtuelles restantes du réseau virtuel.

20 VMware, Inc.

Chapitre 2 Sécurisation des configurations d' ESXi

L'installation d'un pare-feu hébergé sur hôte sur les machines virtuelles à la tête des réseaux virtuels est une bonne pratique de sécurité. Cependant, comme les pare-feu hébergés sur hôte peuvent ralentir les performances, équilibrez vos besoins en sécurité par rapport aux performances avant de décider d'installer des pare-feu hébergés sur hôte sur des machines virtuelles ailleurs dans le réseau virtuel.

Conservation de différentes zones de machines virtuelles au sein d'un hôte sur différents segments du réseau. Si vous isolez des zones de machines virtuelles sur leurs propres segments de réseau, vous réduisez les risques de fuite de données d'une zone de machines virtuelles à la suivante. La segmentation empêche diverses menaces, y compris l'usurpation d'adresse ARP (Address Resolution Protocol), dans laquelle un attaquant manipule la table ARP pour remapper les adresses MAC et IP, obtenant ainsi accès au trafic réseau de et vers un hôte. Les attaquants utilisent l'usurpation ARP pour générer des dénis de service, pirater le système cible et interrompre le réseau virtuel.

La planification soignée de la segmentation réduit les chances de transmissions de paquets entre les zones de machines virtuelles, ce qui empêche les attaques de reniflement qui nécessitent l'envoi de trafic réseau à la victime. Par conséquent, un attaquant ne peut pas utiliser un service non sécurisé sur une zone de machines virtuelles pour accéder aux autres zones de machines virtuelles de l'hôte. Vous pouvez implémenter la segmentation à l'aide de l'une des deux approches suivantes, chacune d'entre elles ayant des avantages différents.

Utilisez des adaptateurs réseau physiques séparés pour des zones de machines virtuelles afin de garantir que les zones sont isolées. Conserver des adaptateurs réseau physiques séparés pour des zones de machines virtuelles est probablement la méthode la plus sécurisée et moins susceptible de subir une configuration incorrecte après la création des segments initiaux.

Configurez des réseaux locaux virtuels (VLAN) pour protéger votre réseau. Comme les VLAN disposent de presque tous les avantages de sécurité inhérents à l'implémentation de réseaux séparés physiquement sans surcharge matérielle, ils offrent une solution viable pouvant vous économiser les coûts de déploiement et d'entretien de périphériques, câblages, etc. supplémentaires.

Les VLAN sont un schéma de réseau standard IEEE avec des méthodes de balisage spécifiques qui permettent le routage des paquets uniquement vers les ports faisant partie du VLAN. S'ils sont configurés correctement, les VLAN fournissent un moyen fiable pour protéger un ensemble de machines virtuelles des intrusions accidentelles et nuisibles.

Les VLAN vous permettent de segmenter un réseau physique afin que deux machines du réseau ne puissent pas transmettre et recevoir des paquets à moins de faire partie du même VLAN. Par exemple, les enregistrements de comptabilité et les transactions font partie des informations internes les plus sensibles d'une entreprise. Dans une entreprise dont les employés des ventes, des expéditions et de la comptabilité utilisent tous des machines virtuelles sur le même réseau physique, vous pouvez protéger les machines virtuelles du service de comptabilité en configurant des VLAN.

VMware, Inc. 21

VM3 VM4

Commutateur standard

VM5

Commutateur standard

VM6 VM7 VM8

Commutateur standard

VM0 VM1 VM2

Commutateur standard

VM9 VM10 VM11

VM12 VLAN

VM13 VLAN

VM14 VLAN

Commutateur standard

Routeur

Hôte 1

Hôte 3

Hôte 4

Hôte 2

Commutateur 1

Commutateur 2

Plusieurs VLAN sur le même commutateur

virtuel Diffusion

Domaines A et B

VLAN A

Diffusion Domaine A

VLAN B

Diffusion Domaine B

Sécurité vSphere

Figure 2-2. Exemple de disposition de VLAN

Dans cette configuration, tous les employés du service de comptabilité utilisent des machines virtuelles dans un VLAN A et les employés des ventes utilisent des machines virtuelles dans VLAN B.

Le routeur transmet les paquets contenant les données de comptabilité aux commutateurs. Ces paquets sont balisés pour une distribution sur le VLAN A uniquement. Par conséquent, les données sont confinées à une diffusion dans le domaine A et ne peuvent pas être acheminées pour une diffusion dans le domaine B à moins que le routeur ne soit configuré pour le faire.

Cette configuration de VLAN empêche les forces de vente d'intercepter les paquets destinés au service de comptabilité. Elle empêche également le service de comptabilité de recevoir des paquets destinés au groupes de ventes. Les machines virtuelles prises en charge par un seul commutateur virtuel peuvent se trouver sur des VLAN différents.

Considérations relatives à la sécurité pour les VLAN

La manière dont vous configurez les VLAN pour sécuriser des parties du réseau dépend de facteurs tels que le système d'exploitation invité et la façon dont votre équipement réseau est configuré.

ESXi dispose d'une implémentation VLAN complète conforme IEEE 802.1q. VMware ne peut pas faire de recommandations spécifiques sur la manière de configurer des VLAN, mais il existe des facteurs à prendre en compte lors de l'utilisation d'un déploiement VLAN dans le cadre de votre stratégie d'application de la sécurité.

22 VMware, Inc.

Chapitre 2 Sécurisation des configurations d' ESXi

VLAN faisant partie d'une plus vaste implémentation de sécurité

Les VLAN sont des moyens efficaces de contrôler où et dans quelle mesure les données sont transmises sur le réseau. Si un attaquant parvient à accéder au réseau, il est susceptible d'être restreint au VLAN servant de point d'entrée, réduisant le risque encouru par le réseau dans sa globalité.

Les VLAN fournissent une protection uniquement par le fait qu'ils contrôlent la manière dont les données sont acheminées après avoir traversé les commutateurs et être entrées dans le réseau. Vous pouvez utiliser des VLAN pour sécuriser la couche 2 de votre architecture réseau (couche de liaison de données). Cependant, la configuration des VLAN ne protège pas la couche physique de votre modèle réseau ou tout autre couche. Même si vous créez des VLAN, fournissez une protection supplémentaire en sécurisant votre matériel (routeurs, hub, etc.) et en chiffrant les transmissions de données.

Les VLAN ne remplacent pas les pare-feu dans vos configurations de machines virtuelles. La plupart des configurations réseau comprenant des VLAN incluent également des pare-feu. Si vous incluez des VLAN dans votre réseau virtuel, assurez-vous que les pare-feu que vous installez prennent en charge les VLAN.

Configuration correcte des VLAN

Une configuration incorrecte de l'équipement et des défauts du matériel réseau, des microprogrammes ou des logiciels risquent de créer un VLAN susceptible de subir des attaques VLAN Hopping.

Le VLAN hopping survient lorsqu'un attaquant avec accès autorisé à un VLAN crée des paquets qui simulent des commutateurs physiques en transmettant des paquets à un autre VLAN auquel l'attaquant n'est pas autorisé à accéder. La vulnérabilité à ce type d'attaque provient généralement d'un commutateur mal configuré pour un fonctionnement en VLAN natif, dans lequel le commutateur peut recevoir et transmettre des paquets non marqués.

Pour empêcher le VLAN hopping, conservez votre équipement à niveau en installant les mises à jour matérielles et des microprogrammes au fur et à mesure de leur mise à disposition. Par conséquent, respectez les recommandations des meilleures pratiques de votre fournisseur lorsque vous configurez votre équipement.

Les commutateurs standard VMware ne prennent pas en charge le concept de VLAN natif. Toutes les données transmises à ces commutateurs sont marquées de manière adéquate. Cependant, comme les autres commutateurs du réseau peuvent être configurés pour un fonctionnement en VLAN natif, les VLAN configurés avec des commutateurs standard peuvent toujours être vulnérables au VLAN hopping.

Si vous envisagez d'utiliser des VLAN pour renforcer la sécurité du réseau, désactivez la fonction de VLAN natif pour tous les commutateurs à moins que vous n'ayez une raison impérative pour faire fonctionner les VLAN en mode natif. Si vous devez utiliser un VLAN natif, reportez-vous aux consignes de configuration du fournisseur pour cette fonction.

Protection des commutateurs standard et VLAN

Les commutateurs standard VMware assurent une protection contre certaines menaces pour la sécurité du VLAN. En raison de la manière dont certains commutateurs standard sont conçus, ils protègent les VLAN contre un grand nombre d'attaques, dont un grand nombre implique le VLAN hopping.

Disposer de cette protection ne garantit pas que la configuration de vos machines virtuelles n'est pas vulnérable à d'autres types d'attaques. Par exemple, les commutateurs standard ne protègent pas le réseau physique contre ces attaques : ils protègent uniquement le réseau virtuel.

VMware, Inc. 23

Sécurité vSphere

Les commutateurs standard et les VLAN peuvent protéger des types d'attaques suivants.

Saturation MAC

Attaques 802.1q et de balisage ISL

Attaques à double encapsulation

Saturation d'un commutateur avec des paquets contenant des adresses MAC balisées comme provenant de sources différentes. De nombreux commutateurs utilisent une table de mémoire adressable par contenu pour détecter et stocker l'adresse source de chaque paquet. Lorsque la table est pleine, le commutateur peut passer dans un état totalement ouvert dans lequel chaque paquet entrant est diffusé sur tous les ports, permettant à l'attaquant de voir tout le trafic du commutateur. Cet état peut provoquer une fuite des paquets sur les VLAN.

Bien que les commutateurs standard de VMware stockent la table d'adresses MAC, ils n'obtiennent pas les adresses MAC du trafic observable et ne sont pas vulnérables à ce type d'attaque.

Force un commutateur à rediriger des cadres d'un VLAN à un autre en amenant le commutateur à agir comme un tronçon et à diffuser le trafic aux autres VLAN.

Les commutateurs standard de VMware n'effectuent pas la jonction dynamique requise pour ce type d'attaque et ne sont pas par conséquent vulnérables.

Survient lorsqu'un attaquant crée un paquet à double encapsulation dans lequel l'identifiant de VLAN dans la balise interne est différent de l'identifiant de VLAN dans la balise externe. Pour des raisons de compatibilité descendante, les VLAN natifs ôtent la balise externe des paquets transmis sauf s'ils sont configurés pour ne pas le faire. Lorsque le commutateur d'un VLAN natif ôte la balise externe, seule la balise interne reste et cette balise interne achemine le paquet à un VLAN différent de celui identifié par la balise externe maintenant manquante.

Attaques de force brute multidiffusion

Les commutateurs standard de VMware rejettent les cadres à double encapsulation qu'une machine virtuelle tente d'envoyer sur un port configuré pour un VLAN spécifique. Par conséquent, ils ne sont pas vulnérables à ce type d'attaque.

Implique l'envoi d'un grand nombre de cadres multidiffusion à un VLAN connu presque simultanément pour surcharger le commutateur afin qu'il autorise par erreur la diffusion de certains cadres sur d'autres VLAN.

Les commutateurs standard de VMware ne permettent pas aux cadres de quitter leur domaine de diffusion correspondant (VLAN) et ne sont pas vulnérables à ce type d'attaque.

24 VMware, Inc.

Chapitre 2 Sécurisation des configurations d' ESXi

Attaques l'arbre recouvrant

Attaques à trame aléatoire

Comme de nouvelles menaces de sécurité continuent à se développer, ne considérez pas cela comme une liste exhaustive des attaques. Vérifiez régulièrement les ressources de sécurité de VMware sur le Web pour en savoir plus sur la sécurité, les alertes de sécurité récentes et les tactiques de sécurité de VMware.

Spanning-Tree Protocol (STP) cible, qui est utilisé pour contrôler le pontage entre des parties du LAN. L'attaquant envoie des paquets Bridge Protocol Data Unit (BPDU) qui tentent de modifier la topologie du réseau, en se définissant comme le pont racine. En tant que pont racine, l'attaquant peut renifler le contenu des cadres transmis.

Les commutateurs standard de VMware ne prennent pas en charge STP et ne sont pas vulnérables à ce type d'attaque.

Implique l'envoi d'un grand nombre de paquets dans lesquels les adresses de source et de destination restent identiques, mais dans lesquels les zones sont modifiées aléatoirement en longueur, type ou contenu. L'objectif de cette attaque est de forcer les paquets à être réacheminés par erreur vers un VLAN différent.

Les commutateurs standard de VMware ne sont pas vulnérables à ce type d'attaque.

Sécurisation des ports de commutateurs standard

Tout comme pour les adaptateurs réseau physiques, un adaptateur réseau virtuel peut envoyer des cadres qui semblent provenir d'une machine différente ou emprunter l'identité d'une autre machine afin de pouvoir recevoir des cadres réseau destinés à cette machine. Par conséquent, tout comme les adaptateurs réseau physiques, un adaptateur réseau virtuel peut être configuré afin de recevoir des cadres destinés à d'autres machines.

Lorsque vous créez un commutateur standard pour votre réseau, vous ajoutez des groupes de ports pour imposer une configuration de règles pour les machines virtuelles et les systèmes de stockage reliés au commutateur. Vous créez des ports virtuels via vSphere Client.

Dans le cadre de l'ajout d'un port ou d'un groupe de ports à un commutateur standard, vSphere Client configure un profil de sécurité pour le port. Vous pouvez utiliser ce profil de sécurité pour garantir que l'hôte empêche les systèmes d'exploitation invités de ses machines virtuelles d'emprunter l'identité d'autres machines sur le réseau. Cette fonction de sécurité est implémentée afin que le système d'exploitation invité responsable de l'emprunt d'identité ne détecte pas que l'emprunt d'identité a été empêché.

Le profil de sécurité détermine le niveau de puissance avec lequel vous appliquez la protection contre l'emprunt d'identité et les attaques d'interception sur les machines virtuelles. Pour utiliser correctement les paramètres du profil de sécurité, vous devez comprendre les bases du contrôle des transmissions par les adaptateurs réseau virtuels et la manière dont les attaques sont bloquées à ce niveau.

Chaque adaptateur réseau virtuel a sa propre adresse MAC qui lui est attribuée lors de la création de l'adaptateur. Cette adresse est appelée adresse MAC initiale. Bien que l'adresse MAC initiale puisse être reconfigurée à partir de l'extérieur du système d'exploitation invité, elle ne peut pas être modifiée par le système d'exploitation invité. Par ailleurs, chaque adaptateur dispose d'une adresse MAC effective qui filtre le trafic réseau entrant avec une adresse MAC de destination différente de l'adresse MAC effective. Le système d'exploitation invité est responsable de la définition de l'adresse MAC effective et fait généralement correspondre l'adresse MAC effective à l'adresse MAC initiale.

Lors de l'envoi de paquets, un système d'exploitation place généralement l'adresse MAC effective de son propre adaptateur réseau dans la zone de l'adresse MAC source du cadre Ethernet. Il place également l'adresse MAC pour l'adaptateur réseau récepteur dans la zone d'adresse MAC de destination. L'adaptateur récepteur accepte les paquets uniquement lorsque l'adresse MAC de destination dans le paquet correspond à sa propre adresse MAC effective.

VMware, Inc. 25

Sécurité vSphere

Lors de la création, l'adresse MAC effective de l'adaptateur réseau et l'adresse MAC initiale sont identiques. Le système d'exploitation de la machine virtuelle peut remplacer l'adresse MAC effective par une autre valeur à tout moment. Si un système d'exploitation modifie l'adresse MAC effective, son adaptateur réseau reçoit le trafic réseau destiné à la nouvelle adresse MAC. Le système d'exploitation peut envoyer des cadres avec une adresse MAC source usurpée à tout moment. Cela signifie qu'un système d'exploitation peut bloquer les attaques nuisibles sur les périphériques dans un réseau en empruntant l'identité d'un adaptateur réseau que le réseau récepteur autorise.

Vous pouvez utiliser des profils de sécurité de commutateur standard sur les hôtes pour vous protéger contre ce type d'attaque en définissant trois options. Si vous modifiez un paramètre par défaut pour un port, vous devez modifier le profil de sécurité en éditant les paramètres du commutateur standard dans vSphere Client.

Modifications d'adresse MAC

Le paramètre pour l'option [Modifications d'adresse MAC] affecte le trafic qu'une machine virtuelle reçoit.

Lorsque cette option est définie sur [Accepter] , ESXi accepte les demandes de modification de l'adresse MAC effective en une adresse différente de l'adresse MAC initiale.

Lorsque cette option est définie sur [Rejeter] , ESXi n'honore pas les demandes de modification de l'adresse MAC effective en une adresse différente de l'adresse MAC initiale, qui protège l'hôte contre l'emprunt d'identité MAC. Le port que l'adaptateur virtuel a utilisé pour envoyer la demande est désactivé et l'adaptateur virtuel ne reçoit plus de cadres jusqu'à ce que l'adresse MAC effective soit remplacée par l'adresse MAC initiale. Le système d'exploitation invité ne détecte pas que le changement d'adresse MAC n'a pas été honoré.

REMARQUE L'initiateur iSCSI repose sur la capacité à obtenir les modifications d'adresse MAC de certains types de stockage. Si vous utilisez iSCSI ESXi et avez un stockage iSCSI, définissez l'option [Modifications d'adresse MAC] sur [Accepter] .

Dans certaines situations, vous pouvez avoir un besoin légitime d'attribuer la même adresse MAC à plusieurs adaptateurs, par exemple, si vous utilisez l'équilibrage de la charge réseau Microsoft en mode monodiffusion. Lorsque l'équilibrage de la charge réseau Microsoft est utilisé en mode multidiffusion standard, les adaptateurs ne partagent pas les adresses MAC.

Les paramètres de changement des adresses MAC affectent le trafic sortant d'une machine virtuelle. Les modifications d'adresse MAC surviennent si l'émetteur est autorisé à les faire, même si les commutateurs standard ou une machine virtuelle réceptrice ne permet pas les changements d'adresses MAC.

Transmissions forgées

Le paramètre pour l'option [Transmissions forcées :] affecte le trafic transmis à partir d'une machine virtuelle.

Lorsque cette option est définie sur [Accepter] , ESXi ne compare pas les adresses MAC sources et les adresses MAC effectives.

Pour se protéger d'un emprunt d'identité MAC, vous pouvez définir cette option sur [Rejeter] . Si vous effectuez cette opération, l'hôte compare l'adresse MAC source étant transmise par le système d'exploitation avec l'adresse MAC effective pour son adaptateur pour voir si elles correspondent. Si les adresses ne correspondent pas, ESXi rejette le paquet.

Le système d'exploitation invité ne détecte pas que son adaptateur de réseau virtuel ne peut pas envoyer de paquets à l'aide de l'adresse MAC usurpée. L'hôte ESXi intercepte les paquets avec des adresses usurpées avant leur livraison, et le système d'exploitation invité peut supposer que les paquets sont rejetés.

26 VMware, Inc.

Fonctionnement en mode promiscuité

Le mode promiscuité élimine le filtrage de réception que l'adaptateur de réseau virtuel effectuerait afin que le système d'exploitation invité reçoive tout le trafic observé sur le réseau. Par défaut, l'adaptateur de réseau virtuel ne peut pas fonctionner en mode promiscuité.

Bien que le mode promiscuité puisse être utile pour le suivi de l'activité réseau, c'est un mode de fonctionnement non sécurisé, car les adaptateurs en mode promiscuité ont accès aux paquets, même si certains de ces paquets sont reçus uniquement par un adaptateur réseau spécifique. Cela signifie qu'un administrateur ou un utilisateur racine dans une machine virtuelle peut potentiellement voir le trafic destiné à d'autres systèmes d'exploitation hôtes ou invités.

REMARQUE Dans certaines situations, vous pouvez avoir une raison légitime de configurer un commutateur standard pour fonctionner en mode promiscuité (par exemple, si vous exécutez un logiciel de détection des intrusions réseau ou un renifleur de paquets).

Sécurité du protocole Internet

La sécurité du protocole Internet (IPsec) sécurise les communications IP provenant de et arrivant sur l'hôte. Les hôtes ESXi prennent en charge IPsec avec IPv6.

Lorsque vous configurez IPsec sur un hôte, vous activez l'authentification et le chiffrement des paquets entrants et sortants. Le moment et la manière de chiffrer le trafic IP dépend de la manière dont vous configurez les associations de sécurité du système et les stratégies de sécurité.

Chapitre 2 Sécurisation des configurations d' ESXi

Une association de sécurité détermine comment le système chiffre le trafic. Lorsque vous créez une association de sécurité, vous spécifiez la source et la destination, les paramètres de chiffrement, un nom pour l'association de sécurité.

Une stratégie de sécurité détermine le moment auquel le système doit chiffrer le trafic. La stratégie de sécurité comprend les informations de source et de destination, le protocole et la direction du trafic à chiffrer, le mode (transport ou tunnel) et l'association de sécurité à utiliser.

Ajout d'une association de sécurité

Ajoutez une association de sécurité pour définir des paramètres de chiffrement pour le trafic IP associé.

Vous pouvez ajouter une association de sécurité à l'aide de la commande vicfg-ipsec de vSphere CLI.

Dans la procédure, --server= un nom de serveur et un mot de passe. D'autres options de connexion, telles qu'un fichier de configuration ou de session, sont prises en charge. Pour obtenir une liste des options de connexion, reportez-vous à Initiation aux interfaces de ligne de commande vSphere.

Prérequis

Installez vCLI ou déployez la machine virtuelle de vSphere Management Assistant (vMA). Reportez-vous à la section Initiation aux interfaces de ligne de commande vSphere. Pour le dépannage, exécutez les commandes

esxcli dans ESXi Shell.

Procédure

Dans l'invite de commande, saisissez vicfg-ipsec --server= des options suivantes.

server_name

spécifie le serveur cible. Le serveur cible spécifié vous invite à saisir

server_name

--add-sa avec une ou plusieurs

Option Description

--sa-src source address

--sa-dst destination address

VMware, Inc. 27

Spécifiez l'adresse source. Spécifiez l'adresse de destination.

Sécurité vSphere

Exemple : Commande de nouvelle association de sécurité

Option Description

--sa-mode mode

--spi security parameter index

--ealgo encryption algorithm

--ekey encryption key

--ialgo authentication algorithm

--ikey authentication key

name

Spécifiez le mode, soit transport ou tunnel. Spécifiez l'index des paramètres de sécurité. Celui-ci identifie l'association

de sécurité à l'hôte. Ce doit être un hexadécimal avec un préfixe 0x. Chaque association de sécurité que vous créez doit disposer d'une combinaison unique de protocole et d'index de paramètres de sécurité.

Spécifiez l'algorithme de chiffrement à l'aide d'un des paramètres suivants.

3des-cbc

aes128-cbc

null

null aucun chiffrement.

Spécifiez la clé de chiffrement. Vous pouvez entrer des clés en tant que texte ASCII ou en tant qu'hexadécimal avec un préfixe 0x.

Spécifiez l'algorithme d'authentification, soit hmac-sha1 ou hmac- sha2-256.

Spécifiez la clé d'authentification. Vous pouvez entrer des clés en tant que texte ASCII ou en tant qu'hexadécimal avec un préfixe 0x.

Indiquez un nom pour l'association de sécurité.

L'exemple suivant contient des sauts de ligne supplémentaires pour des raisons de lisibilité.

vicfg-ipsec --server=

--sa-src 3ffe:501:ffff:0::a

--sa-dst 3ffe:501:ffff:0001:0000:0000:0000:0001

--sa-mode transport

--spi 0x1000

--ealgo 3des-cbc

--ekey 0x6970763672656164796c6f676f336465736362636f757432

--ialgo hmac-sha1

--ikey 0x6970763672656164796c6f67736861316f757432 sa1

server_name

--add-sa

Suppression d'une association de sécurité

Vous pouvez supprimer une association de sécurité de l'hôte.

Vous pouvez supprimer une association de sécurité à l'aide de la commande vicfg-ipsec.

Prérequis

Assurez-vous que l'association de sécurité que vous souhaitez utiliser n'est pas actuellement utilisée. Si vous essayez de supprimer une association de sécurité en cours d'utilisation, l'opération de suppression échoue.

server_name

spécifie le serveur cible. Le serveur cible spécifié vous invite à saisir

esxcli dans ESXi Shell.

28 VMware, Inc.

Chapitre 2 Sécurisation des configurations d' ESXi

Procédure

Dans l'invite de commande, saisissez

vicfg-ipsec --server=

server_name

--remove-sa

security_association_name

Liste des associations de sécurité disponibles

ESXi peut fournir une liste de toutes les associations de sécurité disponibles pour l'utilisation par les règles de sécurité. Cette liste inclut les associations de sécurité créées par l'utilisateur et les associations de sécurité que VMkernel a installées à l'aide d'Internet Key Exchange.

Vous pouvez obtenir une liste des associations de sécurité disponibles à l'aide de la commande vicfg-ipsec.

Dans la procédure, --server=

server_name

spécifie le serveur cible. Le serveur cible spécifié vous invite à saisir un nom de serveur et un mot de passe. D'autres options de connexion, telles qu'un fichier de configuration ou de session, sont prises en charge. Pour obtenir une liste des options de connexion, reportez-vous à Initiation aux interfaces de ligne de commande vSphere.

Prérequis

esxcli dans ESXi Shell.

Procédure

Dans l'invite de commande, saisissez vicfg-ipsec --server=

server_name

-l.

ESXi affiche une liste de toutes les associations de sécurité disponibles.

Création d'une règle de sécurité

Créez une règle de sécurité pour déterminer le moment auquel utiliser les paramètres d'authentification et de chiffrement définis dans une association de sécurité.

Vous pouvez ajouter une règle de sécurité à l'aide de la commande vicfg-ipsec de vSphere CLI.

server_name

spécifie le serveur cible. Le serveur cible spécifié vous invite à saisir

Prérequis

Avant de créer une règle de sécurité, ajoutez une association de sécurité comportant les paramètres d'authentification et de chiffrement appropriés décrits dans « Ajout d'une association de sécurité », page 27.

esxcli dans ESXi Shell.

Procédure

Dans l'invite de commande, saisissez vicfg-ipsec --server=

server_name

--add-sp et une ou plusieurs

des options suivantes.

Option Description

--sp-src source address

--sp-dst destination address

VMware, Inc. 29

Spécifiez l'adresse IP source et la longueur du préfixe.

Spécifiez l'adresse de destination et la longueur du préfixe.

Sécurité vSphere

Option Description

--src-port port

--dst-port port

--ulproto protocol

--dir direction

--action action

--sp-mode mode

--sa-namesecurity association

name

Spécifiez le port source. Le port source doit être un nombre compris entre 0

et 65 535.

Spécifiez le port de destination. Le port source doit être un nombre compris

entre 0 et 65 535.

Spécifiez le protocole de couche supérieure à l'aide d'un des paramètres

suivants.

tcp

udp

icmp6

toutes

Spécifiez la direction dans laquelle vous souhaitez surveiller le trafic à l'aide

de in ou out.

Définissez l'action à prendre lorsque le trafic avec les paramètres spécifiés

est rencontré à l'aide des paramètres suivants.

none : Ne faites rien

discard : Ne permettez pas l'entrée ou la sortie de données.

ipsec : Utilisez les informations d'authentification et de chiffrement fournies dans l'association de sécurité pour déterminer si les données

proviennent d'une source de confiance. Spécifiez le mode, soit tunnel ou transport. Indiquez le nom de l'association de sécurité pour la règle de sécurité à utiliser.

Indiquez un nom pour la règle de sécurité.

Exemple : Commande de nouvelle règle de sécurité

L'exemple suivant contient des sauts de ligne supplémentaires pour des raisons de lisibilité.

vicfg-ipsec --server=

--sp-src 2001:db8:1::/64

--sp-dst 2002:db8:1::/64

--src-port 23

--dst-port 25

--ulproto tcp

--dir out

--action ipsec

--sp-mode transport

--sa-name sa1 sp1

server_name

--add-sp

Suppression d'une règle de sécurité

Vous pouvez supprimer une règle de sécurité de l'hôte ESXi.

Vous pouvez supprimer une règle de sécurité à l'aide de la commande vicfg-ipsec.

Dans la procédure, --server=

server_name

un nom de serveur et un mot de passe. D'autres options de connexion, telles qu'un fichier de configuration ou de session, sont prises en charge. Pour obtenir une liste des options de connexion, reportez-vous à Initiation aux interfaces de ligne de commande vSphere.

spécifie le serveur cible. Le serveur cible spécifié vous invite à saisir

Prérequis

Assurez-vous que la règle de sécurité que vous souhaitez utiliser n'est pas actuellement utilisée. Si vous essayez de supprimer une règle de sécurité en cours d'utilisation, l'opération de suppression échoue.

30 VMware, Inc.

+ 74 hidden pages