Laboratoires d’essai en ligne VMware - HOL-1803-02-NET


Présentation du laboratoire en ligne HOL-1803-02-NET : VMware NSX - Pare-feu distribué et micro-segmentation

Instructions concernant le déroulement du laboratoire


Remarque : il vous faudra plus de 90 minutes pour suivre ce laboratoire. Durant cette session, vous pourrez terminer un maximum de 2 ou 3 modules.  Les modules sont indépendants. Vous pouvez donc commencer au début du module de votre choix, puis enchaîner les modules dans l’ordre qui vous convient. Utilisez le sommaire pour accéder au module choisi.

Le sommaire est disponible dans l’angle supérieur droit du manuel du laboratoire.

Ce laboratoire vous propose de découvrir différents cas d’usage de VMware NSX et de la micro-segmentation, et notamment d’examiner plus en détail le pare-feu distribué et l’interface utilisateur Service Composer.  Les cas d’usage étudiés incluent en particulier des solutions de réduction de réseaux segmentés, de regroupement intelligent de serveurs et de sécurité axée sur l’utilisateur.

Liste des modules du laboratoire :

 Responsables du laboratoire :

  • Module 1 : Chris Cousins, ingénieur système en chef, États-Unis
  • Module 2 : Chris Cousins, ingénieur système en chef, États-Unis
  • Module 3 : Chris Cousins, ingénieur système en chef, États-Unis
  • Module 4 : Chris Cousins, ingénieur système en chef, États-Unis

 

Vous pouvez télécharger ce manuel de laboratoire sur le site des documents des laboratoires d’essai en ligne, accessible ici :

http://docs.hol.vmware.com

Ce laboratoire peut être disponible dans d’autres langues.  Le document suivant vous aidera à définir vos préférences linguistiques et à déployer un manuel localisé pour votre laboratoire :

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Emplacement de la console principale

 

  1. La zone délimitée par un cadre ROUGE correspond à la console principale.  Le manuel de laboratoire apparaît dans l’onglet affiché sur la droite de la console principale.
  2. Des consoles supplémentaires peuvent être utilisées pour certains laboratoires. Elles s’affichent alors dans des onglets distincts en haut à gauche. Vous pourrez, au besoin, être invité à ouvrir une console supplémentaire spécifique.
  3. Au début de votre laboratoire, le minuteur est réglé sur 90 minutes.  Vous ne pouvez pas sauvegarder le laboratoire.  Toutes les tâches doivent être effectuées durant la session de laboratoire.  Vous avez toutefois la possibilité de cliquer sur EXTEND pour obtenir un délai supplémentaire.  Si vous effectuez ce laboratoire dans le cadre d’un événement VMware, vous avez droit à deux prolongations, pour un délai supplémentaire total de 30 minutes.  Chaque clic vous donne droit à 15 minutes supplémentaires.  En dehors des événements VMware, vous pouvez prolonger la durée du laboratoire jusqu’à 9 heures et 30 minutes. Chaque clic vous donne droit à une heure supplémentaire.

 

 

Méthodes alternatives à la saisie de données au clavier

Au cours de ce module, vous serez invité à saisir du texte dans la console principale. Outre la saisie directe au clavier, vous disposez de deux méthodes alternatives facilitant l’entrée de données complexes.

 

 

Vous pouvez cliquer sur un élément de texte dans le manuel de laboratoire pour le faire glisser dans la fenêtre de console active.

 
 

Vous pouvez également cliquer sur du texte et des commandes CLI (Command Line Interface) directement à partir du manuel du laboratoire, pour les faire glisser dans la fenêtre active de la console principale.  

 

 

Accès au clavier international en ligne

 

Vous pouvez également utiliser le clavier international en ligne proposé dans la console principale.

  1. Cliquez sur l’icône représentant un clavier dans la barre d’outils Lancement rapide de Windows.

 

 

Invite ou filigrane d’activation

 

Au moment de démarrer le laboratoire, vous remarquerez peut-être sur le bureau un filigrane indiquant que Windows n’est pas activé.  

L’un des principaux avantages de la virtualisation réside dans la possibilité de transférer et d’exécuter une machine virtuelle sur n’importe quelle plate-forme.  Les laboratoires d’essai en ligne tirent parti de cette capacité, qui nous permet de les exécuter depuis différents Data Centers.  Cependant, ces Data Centers ne sont pas tous dotés des mêmes processeurs, ce qui a pour effet de déclencher un contrôle d’activation Microsoft via Internet.

Rassurez-vous, VMware et ses laboratoires d’essai en ligne sont en parfaite conformité avec les conditions de licence de Microsoft.  Le laboratoire que vous suivez est un pod autonome ne disposant pas de l’accès complet à Internet dont Windows a besoin pour vérifier l’activation.  L’absence d’un accès complet à Internet provoque l’échec de ce processus automatisé, d’où l’apparition du filigrane.

Ce problème superficiel est sans incidence sur votre laboratoire.  

 

 

Observez la partie inférieure droite de l’écran

 

Vérifiez que toutes les routines de démarrage ont été exécutées et que le laboratoire est prêt à démarrer. Si l’état affiché est différent de « Ready », patientez pendant quelques minutes.  Si le laboratoire n’est toujours pas à l’état « Ready » au bout de 5 minutes, demandez de l’aide.

 

Module 1 : Présentation de Service Composer et du pare-feu distribué (45 minutes)

Présentation du pare-feu distribué et de la micro-segmentation


Le pare-feu distribué de NSX est un pare-feu intégré dans le noyau de l’hyperviseur de façon à offrir la visibilité et le contrôle requis sur les charges de travail et les réseaux virtualisés. Vous pouvez créer des règles de contrôle d’accès basées sur : des objets VMware vCenter, tels que les Data Centers, les clusters et les noms de machines virtuelles ; des constructions réseau, telles que les adresses ou ensembles d’adresses IP, les VLAN (groupes de ports DVS), les VXLAN (commutateurs logiques), les groupes de sécurité, ainsi que les informations d’appartenance aux groupes d’utilisateurs Active Directory. Les règles de pare-feu sont contrôlées au niveau de la VNIC de chaque machine virtuelle pour assurer un contrôle d’accès cohérent, même lors du déplacement de la machine virtuelle via vMotion. De par son intégration dans l’hyperviseur, ce pare-feu offre des débits proches de ceux d’une connexion directe, de façon à permettre une consolidation plus poussée des charges de travail sur les serveurs physiques. Sa conception distribuée se traduit par une architecture évolutive permettant d’étendre automatiquement la capacité de pare-feu au fur et à mesure que des hôtes sont ajoutés au Data Center.

La micro-segmentation est assurée par le composant de pare-feu distribué de NSX. Le pare-feu distribué fonctionne au niveau de la couche du noyau de l’hyperviseur ESXi et traite les paquets à une vitesse proche de celle d’une connexion directe. Chaque machine virtuelle dispose de son propre contexte et de ses propres règles de pare-feu. La mobilité des charges de travail (vMotion) est totalement prise en charge via le pare-feu distribué, et les connexions actives restent intactes pendant le déplacement. Cette fonctionnalité de sécurité avancée sécurise le réseau du Data Center en isolant chaque groupe de machines virtuelles associé sur un segment réseau logique distinct, ce qui permet à l’administrateur de protéger par pare-feu le traffic échangé entre les segments du Data Center (trafic est-ouest). Un tel dispositif restreint la capacité des pirates informatiques à se déplacer latéralement au sein du Data Center.  

Ce module obéit au plan suivant :

Fonctionnalités élémentaires du pare-feu distribué 

Mécanisme de détection d’adresse IP amélioré pour la fonction de pare-feu

Appliquer la sécurité de manière logique avec Service Composer

Commencez le module à partir de votre poste de travail. Celui-ci constitue votre jump box de centre de contrôle au sein de l’environnement virtuel. C’est à partir de ce poste de travail que vous allez accéder à l’instance de vCenter Server Appliance déployée dans votre Data Center virtuel.

Remarque : vous trouverez sur le bureau un fichier nommé README.txt.  Celui-ci contient la liste des comptes utilisateur et des mots de passe à utiliser pour l’ensemble des terminaux virtuels et des VM intervenant dans le laboratoire.


 

Avis à l’utilisateur concernant la section Présentation du pare-feu distribué et de la micro-segmentation

Si vous avez déjà effectué le Module 6, « Pare-feu distribué », du laboratoire HOL-1803-01-NET, il importe de noter que la section intitulée « Pare-feu distribué » du présent laboratoire ne fait que répéter ce module : il n’est donc pas nécessaire de la suivre à nouveau dans le cadre du présent laboratoire.  Si vous souhaitez ignorer cette section, vous trouverez ci-dessous un lien permettant de passer directement à la section suivante.

Cliquez ici pour ignorer le module « Mécanisme de détection d’adresse IP amélioré pour les machines virtuelles et fonctionnalité SpoofGuard ».

 

 

 

Méthodes alternatives à la saisie de données au clavier

Au cours de ce module, vous serez invité à saisir du texte dans la console principale. Outre la saisie directe au clavier, vous disposez de deux méthodes alternatives facilitant l’entrée de données complexes.

 

 

Accéder à vSphere Web Client

 

  1. Ouvrez vSphere Web Client à l’aide de l’icône Google Chrome située sur le bureau.

 

 

Configurer des règles d’accès à une application Web

Vous allez maintenant configurer l’accès avec pare-feu distribué à une application 3 tiers. Cette application dispose de deux serveurs Web, ainsi que d’un serveur d’application et d’un serveur de base de données. Les deux serveurs Web sont également desservis par un équilibreur de charge.

 

 

Création de Groupes de sécurité 3 tiers

 

  1. Cliquez sur Service Composer.

Service Composer est un outil intégré qui définit un nouveau modèle de consommation des services de réseau et de sécurité dans les environnements virtuels et Cloud. Les règles peuvent ainsi être activées simplement via la visualisation et la consommation de services intégrés ou disponibles sous une forme améliorée via des solutions tierces. Des fonctionnalités d’exportation/importation permettent également d’assurer la reproductibilité de ces mêmes règles, de façon à faciliter la récupération d’un environnement en cas de problème. L’un des objets favorisant cette reproductibilité est le groupe de sécurité.  Service Composer et les groupes de sécurité seront présentés plus en détail dans un module ultérieur intitulé « Présentation de Service Composer et du pare-feu distribué ».

 

 

Création de règles d’accès 3 tiers

 

Vous allez maintenant ajouter des règles afin d’autoriser l’accès à la VM Web, puis configurer l’accès entre les niveaux.  

  1. Dans le menu de gauche, sélectionnez Firewall.

 

 

Redémarrer la session PuTTY pour web-01a

 

  1. Cliquez sur l’icône Session dans le coin supérieur gauche.
  2. Cliquez sur Restart Session.

 

 

Topologie après ajout des règles de pare-feu distribué pour l’application 3 tiers

 

Ce diagramme indique le point d’application relatif du pare-feu déployé au niveau de la VNIC.  Bien que le pare-feu distribué soit un module de noyau chargeable de l’hôte vSphere ESXi, les règles sont appliquées au niveau de la carte réseau virtuelle (vNIC) de la VM cliente.  Conçue pour accompagner la VM durant les migrations vMotion, cette protection s’exerce en continu et ne laisse aucune « fenêtre d’opportunité » durant laquelle la VM serait vulnérable aux attaques.

 

 

Restaurer l’environnement du laboratoire à l’issue du module

 

Avant d’enchaîner sur le module suivant, vous devez redéfinir la règle par défaut sur Allow.

  1. Rétablissez l’action de la règle par défaut sur Allow.
  2. Publiez les modifications.

 

Mécanisme de détection d’adresse IP amélioré pour les machines virtuelles et fonctionnalité SpoofGuard


Une fois synchronisé avec vCenter Server, NSX Manager collecte les adresses IP de toutes les machines virtuelles clientes vCenter. Si une machine virtuelle a été compromise, il se peut que son adresse IP soit usurpée et que des transmissions malveillantes contournent les règles de pare-feu.

Vous pouvez créer une règle SpoofGuard pour certains réseaux afin d’autoriser les adresses IP rapportées et de les modifier si nécessaire pour empêcher l’usurpation. SpoofGuard fait intrinsèquement confiance aux adresses MAC de machines virtuelles collectées à partir des fichiers VMX et de vSphere SDK. Du fait de son fonctionnement indépendant des règles de pare-feu, SpoofGuard peut être utilisé pour bloquer le trafic considéré comme usurpé.

SpoofGuard prend en charge les adresses IPv4 et IPv6. Avec IPv4, la règle SpoofGuard prend en charge une seule adresse IP par carte réseau virtuelle. IPv6 permet l’affectation de plusieurs adresses IP à une carte réseau virtuelle. La règle SpoofGuard surveille et gère les adresses IP rapportées par vos machines virtuelles selon l’un des modes suivants :

Ce mode laisse passer l’ensemble du trafic provenant de vos machines virtuelles tout en élaborant une table des affectations de carte réseau virtuelle à adresse IP. Nous pouvons examiner cette table à notre convenance et apporter des modifications aux adresses IP. Ce mode approuve automatiquement toutes les adresses IPv4 et IPv6 affectées à une carte réseau virtuelle.

Ce mode bloque l’ensemble du trafic jusqu’à approbation de chaque affectation de carte réseau virtuelle à adresse IP.

Remarque : SpoofGuard autorise intrinsèquement les requêtes DHCP quel que soit le mode actif. Cependant, en mode d’inspection manuelle, le trafic ne peut passer qu’après approbation de l’adresse IP affectée par le protocole DHCP.

SpoofGuard intègre une règle par défaut générée par le système qui s’applique aux groupes de ports et aux réseaux logiques non couverts par les autres règles SpoofGuard. Tout réseau nouvellement ajouté reçoit automatiquement cette règle par défaut jusqu’à ce que l’administrateur ajoute le nouveau réseau à une règle existante ou crée une règle spécifique pour celui-ci.

Le fonctionnement du pare-feu distribué de NSX exige la détection des adresses IP des objets spécifiés comme source ou comme destination.  Avant NSX 6.2, cette tâche était assurée à l’intérieur de la VM par la suite VMtools. Cet exercice vous montrera comment détecter des adresses IP à l’aide de VMtools et de la fonctionnalité Trust On First Use.


 

Examen des paramètres SpoofGuard

 

Cliquez sur l’onglet de navigateur vSphere Web Client.

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Networking & Security.

 

 

Découverte de SpoofGuard

 

  1. Cliquez sur SpoofGuard dans le volet de navigation.

 

 

Activer la détection d’adresse IP avec l’option « Arp Snooping »

 

  1. Cliquez sur Change.

 

 

Migrer Linux-01a de son commutateur vDS vers un nouveau commutateur logique

Nous devons tout d’abord migrer la VM linux-01a de son commutateur vDS existant vers un commutateur logique afin de pouvoir exploiter les capacités de détection d’adresse IP de SpoofGuard.

 

 

Revenir à la section « Networking & Security »

 

  1. Dans le volet de navigation, cliquez sur le bouton Back de l’historique jusqu’à retrouver l’interface de configuration de NSX.

 

 

Vérifier que la VM Linux-01a a été détectée via la fonctionnalité ARP Snooping

 

  1. Sélectionnez SpoofGuard dans le menu de navigation.
  2. Cliquez sur Default Policy.
  3. Sélectionnez Active Virtual NICs dans le menu déroulant « View ».
  4. Saisissez lin dans le champ de recherche et appuyez sur Entrée afin de filtrer la liste et de la réduire à la VM linux-01a.

Notez que le champ « Source » indique TOFUARP (Trust On First Use ARP) pour l’adresse 192.168.120.115.

 

 

SpoofGuard : conclusion

Voilà qui conclut cette section intitulée « Mécanisme de détection d’adresse IP amélioré pour les machines virtuelles et fonctionnalité SpoofGuard ».  Nous avons mené à bien la migration d’une machine virtuelle dans l’environnement NSX, puis fait appel à SpoofGuard pour détecter l’adresse IP de cette VM via la nouvelle fonctionnalité ARP Trust On First Use.

 

Présentation des groupes de sécurité


Nous allons maintenant nous pencher plus avant sur les fonctionnalités de groupe de sécurité, découvertes dans la section « Présentation du pare-feu distribué et de la micro-segmentation ».  Les groupes de sécurité NSX offrent un moyen de regrouper et définir logiquement les actifs que vous souhaitez protéger. Ces groupes de sécurité peuvent être de type statique (composés de machines virtuelles déterminées) ou dynamique, auquel cas l’appartenance peut être définie selon différentes méthodes :

Notez que l’appartenance aux groupes de sécurité évolue en permanence. Par exemple, une machine virtuelle qui reçoit la balise AntiVirus.virusFound est d’abord transférée dans le groupe de sécurité « Quarantine » mais, une fois le virus traité et la balise levée, la VM est retirée du groupe de sécurité Quarantine.


 

Accéder à Service Composer

 

  1. Cliquez sur Service Composer dans le volet de gauche.

 

 

Afficher la liste des membres

 

  1. Cliquez sur le nombre affiché dans la colonne Virtual Machines pour le nouveau groupe de sécurité Web Security Group.

Remarque : le nombre 6 doit être affiché dans la colonne « Virtual Machines » pour le groupe Web Security Group, qui contient toutes les VM dont le nom contient « WEB », sans tenir compte de la casse et tous réseaux IP confondus.

  1. Cliquez sur le bouton X situé dans le coin supérieur droit de la boîte de dialogue pour fermer celle-ci.

 

Présentation des règles de sécurité


Les règles de sécurité de NSX peuvent être définies comme une collection de ces différentes configurations de services : règles de pare-feu, services de terminal et services d’introspection réseau.  Les règles de pare-feu définissent le trafic autorisé à destination, en provenance ou à l’intérieur du groupe de sécurité.  Les services de terminal peuvent être implémentés via des services de fournisseurs de solutions tiers, tels que les services antivirus ou de gestion des vulnérabilités. Les services d’introspection réseau sont des services qui surveillent votre réseau, tels que le service IPS.

Lors du déploiement d’un service dans NSX, le fournisseur tiers sélectionne la catégorie de services appropriée. Un profil de service par défaut est créé pour chaque modèle de fournisseur.

Remarque Lorsque vous devez associer une même règle de sécurité à plusieurs groupes de sécurité, créez un groupe de sécurité générique regroupant tous ces groupes enfants et appliquez la règle de sécurité commune à ce groupe générique. Le pare-feu distribué de NSX fera ainsi une utilisation plus efficace de la mémoire de l’hôte VMware ESXi.


 

Créer une règle de sécurité

 

  1. Sélectionnez l’onglet Security Policies dans le volet Service Composer .
  2. Cliquez sur l’icône Create Security Policy.
  3. Saisissez Block Web-to-Web Traffic dans le champ Name.
  4. Cliquez sur Firewall Rules dans le volet de gauche.

 

 

Vérifier la synchronisation des règles de pare-feu

 

  1. Cliquez sur Firewall.

 

 

Test de la connectivité entre machines virtuelles Web avec Putty

 

Nous allons maintenant tester la communication et l’accès entre les VM Web qui constituent l’application 3 tiers. Notre premier test va consister à ouvrir une console pour web-01a et à envoyer une requête ping à web-02a.

  1. Cliquez sur le raccourci PuTTY dans la barre des tâches du poste de travail. 
  2. Sélectionnez web-01a.corp.local.
  3. Cliquez sur Open.

 

Examen du canevas Service Composer


Service Composer propose une vue Canevas affichant l’ensemble des groupes de sécurité définis dans l’instance NSX Manager sélectionnée. Cette vue présente également des informations détaillées, telles que la liste des membres de chaque groupe de sécurité et la politique appliquée à ce groupe.

Cette section de présentation de Service Composer vous invite à explorer un système partiellement configuré de façon à visualiser les mappages entre groupes de sécurité et objets de règle de sécurité au niveau le plus général depuis la vue Canevas.


 

Vue graphique du canevas Service Composer

 

 

  1. Cliquez sur Service Composer.
  2. Cliquez sur Canvas.

Tous les groupes de sécurité de l’instance NSX Manager sélectionnée (hormis ceux qui sont imbriqués dans un autre groupe de sécurité) sont présentés avec les règles qui leur sont appliquées. Le menu déroulant de NSX Manager répertorie toutes les instances de NSX Manager dans lesquelles un rôle a été attribué à l’utilisateur actuellement connecté.

Chaque rectangle figurant sur le canevas correspond à un groupe de sécurité, et les icônes qui se trouvent dans ce rectangle représentent les membres du groupe de sécurité et fournissent des détails sur la règle de sécurité mappée à ce groupe de sécurité.

 

 

Conclusion du module 1


Voilà qui conclut le module 1, consacré à Service Composer et au pare-feu distribué.  Nous avons créé des groupes de sécurité de type statique et de type dynamique, appliqué des règles de sécurité statiques ou dynamiques et notamment des règles de pare-feu, et nous avons fait appel à SpoofGuard pour détecter les VM et les autoriser à accéder au réseau sans exécuter la suite VMTools.


 

Restaurer l’environnement du laboratoire à l’issue du module 1

 

Avant de terminer le module 1, vous devez supprimer la règle créée durant cette section.

  1. Accédez de nouveau à Service Composer.
  2. Sélectionnez l’onglet Security Policies.
  3. Cliquez avec le bouton droit sur la ligne Block Web-to-Web Traffic.
  4. Sélectionnez l’option Delete. Lorsque le message « Remove security policy? » vous est présenté, cliquez sur Yes.

 

 

Module 1 terminé

Félicitations ! Vous avez terminé le module 1.

Si vous souhaitez en savoir plus sur les fonctionnalités de routage et la configuration de NSX, rendez-vous dans le Centre de documentation NSX 6.3 via l’URL suivante :

Passez à n’importe lequel des modules suivants :

Liste des modules du laboratoire :

Responsable du laboratoire :

 

 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Module 2 : Démonstration de la fonctionnalité de réduction des applications 3 tiers (15 minutes)

Sécurisation des architectures réduites à l’aide de la fonctionnalité de pare-feu distribué de NSX


Ce module vous montre comment la fonctionnalité de pare-feu distribué intégrée dans NSX permet aux clients de réduire une architecture réseau n-tier traditionnelle à un réseau unique sans hiérarchie tout en maintenant l’isolation des applications.  Cette fonctionnalité est indispensable pour faire évoluer votre dispositif de sécurité d’un modèle axé sur le réseau à un modèle axé sur les charges de travail. Vous utiliserez à cette fin deux applications distinctes (HR et Finance) déployées sur un même commutateur logique et sur un même sous-réseau.   

Vous serez amené à effectuer les tâches de configuration et les tests suivants :

À la fin de ce module de laboratoire, vous aurez établi que le pare-feu distribué de NSX a sécurisé les applications en les isolant l’une de l’autre, tandis que la communication intra-application continue de fonctionner normalement sur la même infrastructure réseau.  


 

Examen d’un exemple d’architecture réseau

 

Avant de réduire un réseau d’application 3 tiers à un réseau unique, examinons un exemple d’application 3 tiers segmentée en sous-réseaux individuels de façon à assurer une isolation de couche 3 entre les niveaux Web, application et base de données.  Il importe de noter qu’aucune règle de pare-feu ne protégeait la communication entre les VM résidant au sein d’un même domaine de couche 2, ni même entre les différents niveaux de l’application.  Les entreprises cherchant à faire évoluer horizontalement leur environnement pour intégrer plusieurs de ces charges de travail n-tier ont deux possibilités : déployer des sous-réseaux supplémentaires, ou déployer plusieurs composants applicatifs (par exemple, les bases de données de différentes applications) dans un même domaine de couche 2.  

À titre d’exemple, une entreprise peut faire coexister les composants de base de données de différentes applications sur le réseau « DB-Tier ».  En ce cas, les pare-feu traditionnels n’assurent aucune protection entre ces bases de données.  Un utilisateur autorisé à accéder à la VM d’une base de données risque d’avoir accès à une autre base de données déployée sur le même réseau.  Le pare-feu distribué de NSX permet aux entreprises de réduire la totalité de la structure de leur réseau à un unique segment de couche 2 en assurant simultanément les fonctionnalités de communication intra-application et d’isolation inter-application.

 

 

Accéder à vSphere Web Client

 

  1. Cliquez sur le raccourci Google Chrome dans la fenêtre de la console principale.

 

 

Vérification du fonctionnement de l’application Finance

 

  1. Ouvrez un nouvel onglet dans Chrome.
  2. Cliquez sur le favori Finance DB App.

Vérifiez que vous avez bien accès à la base de données du département financier relative aux centres de coûts.  Vous devez normalement recevoir des données de la VM fin-web-01a.

 

 

Vérification du fonctionnement de l’application HR

 

  1. Ouvrez un nouvel onglet dans Chrome.
  2. Cliquez sur le favori HR DB App.

Vérifiez que vous avez bien accès à la base de données RH relative à la rémunération des collaborateurs.

 

 

Lancer une console distante pour la VM fin-web-01a

 

  1. Cliquez sur l’onglet « vSphere Web Client ».
  2. Cliquez sur fin-web-01a.corp.local.
  3. Cliquez sur l’onglet Summary.
  4. Cliquez sur l’icône Roue dentée, puis sur Launch Remote Console.

 

 

Revenir à la session vSphere Web Client

 

  1. Cliquez sur l’icône de navigateur vSphere Web Client dans la barre des tâches.

 

 

Revenir à vSphere Web Client

 

  1. Cliquez sur l’icône de navigateur vSphere Web Client dans la barre des tâches.

 

 

Accéder à la configuration du pare-feu

 

  1. Dans le volet de navigation de gauche, cliquez sur Firewall.

 

 

Créer le groupe de sécurité HR App

 

  1. Sélectionnez Security Group dans le menu déroulant Object Type.
  2. Cliquez sur New Security Group pour définir le groupe de sécurité HR App.

 

 

Créer le groupe de sécurité Finance App

 

  1. Sélectionnez Security Group dans la liste déroulante Object Type.
  2. Cliquez sur New Security Group pour définir le groupe de sécurité Finance App.

 

 

Ajouter une nouvelle règle de pare-feu

 

  1. Cliquez sur l’icône Signe plus vert de la section Collapsed App Tier Rules pour ajouter une nouvelle règle.

 

 

Publier les modifications

 

  1. Cliquez sur Publish Changes pour déployer les nouvelles règles de pare-feu sur les VM et les hôtes concernés.

 

 

Vérification du fonctionnement de l’application Finance

 

  1. Cliquez sur l’onglet HOL- Finance Department.
  2. Cliquez sur le bouton Refresh.

Vérifiez que vous avez bien accès à la base de données du département financier relative aux centres de coûts.

 

 

Vérification du fonctionnement de l’application HR

 

  1. Cliquez sur l’onglet HOL - HR Department.
  2. Cliquez sur le bouton Refresh.

Vérifiez que vous avez bien accès à la base de données HR Department Database.

 

 

Restaurer l’environnement du laboratoire avant de commencer le module suivant

 

Avant de passer au module suivant, vous devez supprimer les règles de pare-feu.    

  1. Cliquez sur l’onglet de navigateur vSphere Web Client.

 

Conclusion du module 2


Voilà qui conclut le module 2, qui vous a montré la marche à suivre pour isoler les applications à l’aide du pare-feu distribué de NSX afin de définir un réseau unique sans hiérarchie.  Au cours de ce module, nous vous avons montré que le fait de réduire un réseau d’application 3 tiers à un commutateur logique NSX unique n’empêche aucunement NSX d’assurer une sécurité zéro confiance via son pare-feu distribué.  Nous avons commencé ce laboratoire en vérifiant la communication entre les VM des applications HR et Finance, toutes déployées sur le même réseau.  Nous avons ensuite défini des règles de pare-feu à l’échelle de groupements logiques de VM dans le but d’empêcher la communication entre les applications HR et Finance, puis nous avons vérifié la mise en œuvre des règles ainsi créées en testant la communication de VM à VM entre les deux piles d’application ainsi qu’à l’intérieur de chaque pile.   Après avoir établi que les applications étaient isolées l’une de l’autre, nous avons supprimé les règles de pare-feu de façon à restaurer l’environnement du laboratoire pour les besoins d’un autre module.

Nous espérons que vous avez apprécié cette présentation des fonctionnalités d’isolation des applications et de sécurité zéro confiance offertes par le pare-feu distribué de NSX.


 

Vous avez terminé le module 2.

Félicitations ! Vous avez terminé le module 2.

Si vous souhaitez en savoir plus sur les fonctionnalités de routage et la configuration de NSX, rendez-vous dans le Centre de documentation NSX 6.3 via l’URL suivante :

Passez à n’importe lequel des modules suivants :

Liste des modules du laboratoire :

Responsable du laboratoire :

 

 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Module 3 - Groupement intelligent (30 minutes)

Regroupement intelligent


Module 3 : Regroupement intelligent


 

Introduction

L’arrivée en fin de support de plates-formes d’entreprise aussi importantes que Windows XP, Windows 2000 Server ou Windows Server 2003 constitue un défi majeur pour les entreprises dont les activités quotidiennes reposent sur l’exécution d’applications stratégiques. Ainsi, lorsque Microsoft a mis fin au support de Windows 2003 en juillet 2015, la sécurité de plusieurs millions de serveurs d’entreprise a été mise en péril.

Les départements informatiques qui utilisent un système d’exploitation en fin de support ont probablement introduit des risques de sécurité importants dans leur environnement, à moins de s’être pleinement préparés à migrer vers une nouvelle plate-forme ou à mettre en place des contrôles compensatoires. Une fois les hackers informés de la décision de fournisseurs de plates-formes comme Microsoft de ne plus signaler ni corriger les vulnérabilités, les systèmes concernés deviennent rapidement une cible privilégiée pour les attaques, si bien que les risques liés à l’utilisation d’une plate-forme au-delà de sa date de fin de support ne font que croître avec le temps et l’augmentation du nombre de nouveaux problèmes découverts et laissés sans correctif.

NSX peut vous aider à atténuer les risques engendrés par les systèmes d’exploitation en fin de support en renforçant la sécurité au moyen du pare-feu distribué et de Service Composer. Au cours de ce laboratoire, vous allez vous appuyer sur des groupes de sécurité NSX pour circonscrire les VM Windows XP et leur appliquer des règles de pare-feu de façon à les protéger dans un environnement simulé.  

Ce module obéit au plan suivant :

Responsable du laboratoire :

Module 3 : Chris Cousins, ingénieur système en chef, États-Unis

 

 

Se connecter aux machines virtuelles en fin de support


Nous allons utiliser des VM Windows XP pour déterminer le niveau de sécurité actuel de l’accès aux ressources externes et internes.


 

Se connecter à vSphere Web Client

 

Si vous n’êtes pas déjà connecté à vSphere Web Client :

(Normalement, la page d’accueil est celle de vSphere Web Client.  Si ce n’est pas le cas, cliquez sur l’icône Google Chrome de vSphere Web Client dans la barre des tâches.)

  1. Saisissez administrator@vsphere.local dans le champ « User name ».
  2. Saisissez VMware1! dans le champ « Password ».
  3. Cliquez sur Login.
  1. En cliquant sur les épingles, vous pouvez réduire les volets de tâches afin de bénéficier d’un espace d’affichage plus important dans le volet principal.  Vous pouvez également réduire le volet de gauche pour optimiser l’espace disponible.

 

 

Se connecter aux machines virtuelles en fin de support

 

  1. Sélectionnez Home.
  2. Sélectionnez VMs and Templates.

 

 

Vérifier l’accès interne

 

Lancer le navigateur Mozilla à partir du bureau.

  1. Cliquez sur le lien Customer DB-App pour lancer l’application interne.

 

 

Ouvrir une invite de commande pour tester l’accès externe

 

La VM de la console de contrôle se trouve à l’extérieur de l’environnement virtuel utilisé pour ce laboratoire. Elle représente à ce titre un service externe à notre environnement. Nous allons par conséquent utiliser l’adresse IP du centre de contrôle (192.168.110.10) pour désigner les services Internet en général.

  1. Cliquez sur le menu Démarrer.
  2. Cliquez sur Invite de commande.

Si l’icône « Invite de commande » n’apparaît pas dans le menu,  cliquez sur « Exécuter », puis saisissez « cmd » et appuyez sur Entrée pour ouvrir une invite de commande.

 

Création d’un groupe de sécurité


Après avoir découvert la vulnérabilité potentielle liée au fait que des VM en fin de support ont accès à des ressources externes, il nous faut trouver un moyen de sécuriser ces VM. Nous allons faire appel aux groupes de sécurité de NSX pour identifier rapidement les machines exécutant un système d’exploitation en fin de support, puis sécuriser ces machines en appliquant des règles appropriées.


 

Créer un groupe de sécurité

 

  1. Cliquez sur l’onglet de navigateur vSphere Web Client.
  2. Cliquez sur l’icône Home.
  3. Sélectionnez Networking & Security.

 

Restreindre l’accès des VM


Nous allons maintenant appliquer des règles permettant de restreindre l’accès externe des VM.


 

Appliquer une règle

 

Service Composer.

  1. Sélectionnez le groupe de sécurité Windows XP EOS que nous avons créé précédemment.
  2. Cliquez sur l’icône Apply Policy.

 

 

Configurer la 1re règle de pare-feu

 

  1. Champ « Name » : Access Internal Resources
  2. Champ « Action » : Allow
  3. Champ « Source » : Policy’s Security Group
  4. Champ « Destination » : cliquez sur Change.

 

 

Ajouter une règle de pare-feu supplémentaire

 

Nous venons de créer un groupe de sécurité qui autorise les VM XP à accéder aux services internes (c’est-à-dire aux applications internes). Il nous faut cependant ajouter une règle autorisant l’accès entre les services internes, ainsi que modifier la règle de pare-feu par défaut de façon à bloquer tous les autres accès, et notamment les accès externes.

  1. Cliquez sur Firewall pour accéder aux règles de pare-feu.

 

 

Modifier la règle de pare-feu par défaut

 

Dans la liste des règles de pare-feu, localisez la règle nommée « Default Rule ». La règle de pare-feu par défaut se trouve dans la section « Default Firewall Rule ».

  1. Cliquez sur la flèche déroulante pour développer la section Default Firewall Rule.
  2. Cliquez sur l’icône Crayon dans la colonne « Action » de la règle par défaut.
  3. Sélectionnez Block comme action.
  4. Cliquez sur Save.

 

Vérifier les restrictions sur les accès émanant des VM Windows XP


Nous venons de mettre des règles en place pour les VM Windows XP en fin de support. Nous pouvons maintenant procéder au test de l’accès aux services internes et externes.


 

Rouvrir la console de win-xp-01a

 

  1. Cliquez sur l’onglet de navigateur win-xp-01a.

 

 

Vérifier que l’accès externe est bloqué

 

  1. Rouvrez l’invite de commande sur le bureau de win-xp-01a.
  2. Dans la fenêtre d’invite de commande, entrez la commande ping 192.168.110.10.
  3. Vérifiez que l’accès au centre de contrôle est désormais bloqué.
ping 192.168.110.10

Nous voyons maintenant que la VM win-xp-01a a accès aux services internes, mais que tout accès aux services externes lui est interdit en vertu des règles associées au groupe de sécurité.

 

 

Restaurer l’environnement du laboratoire à l’issue du module : redéfinir la règle par défaut sur « Allow »

 

  1. Développez la section « Default Section Layer3 ».
  2. Cliquez sur l’icône Crayon dans la colonne « Action » de la règle par défaut.
  3. Sélectionnez l’action Allow.
  4. Cliquez sur Save.

 

Conclusion du module 3


 Félicitations ! Vous avez terminé le module 3.

Ce module nous a montré comment utiliser le groupement intelligent pour conteneuriser rapidement les systèmes d’exploitation en fin de support via des groupes de sécurité.  Une fois les groupes de sécurité mis en place, nous pouvons nous en servir pour créer des règles de pare-feu permettant de restreindre les accès en entrée et en sortie pour les machines virtuelles contenues dans ces groupes. Les groupes de sécurité constituent un outil polyvalent, et peuvent être réutilisés pour modifier les règles existantes ou créer de nouvelles règles à mesure que nos exigences de sécurité évoluent.

Si vous souhaitez en savoir plus sur les groupes de sécurité de NSX, rendez-vous dans le Centre de documentation NSX 6.3 via l’URL suivante :

Liste des modules du laboratoire :

Responsable du laboratoire :


 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Module 4 - Sécurité axée sur l’utilisateur dans les scénarios avec jump box (45 minutes)

Sécurité axée sur l’utilisateur dans les scénarios avec jump box


Module 4 :

Sécurité axée sur l’utilisateur dans les scénarios avec jump box


 

Introduction

Dans ce module de laboratoire, vous allez créer des règles de pare-feu à l’aide de la fonctionnalité NSX de pare-feu basé sur l’identité. Cette fonctionnalité nécessite une connexion à Active Directory depuis NSX Manager. NSX Manager analyse le journal des événements du serveur Active Directory afin de déterminer les informations d’authentification et les événements de connexion. Lorsqu’un utilisateur se connecte à une VM, celle-ci peut être instantanément affectée à un groupe de sécurité en fonction du groupe Active Directory auquel l’utilisateur appartient.  En conjuguant groupes de sécurité et règles de pare-feu, nous sommes en mesure de contrôler efficacement les accès au sein de notre environnement.

Ce laboratoire fait intervenir deux groupes Active Directory et deux utilisateurs distincts. Le premier utilisateur est un administrateur réseau qui doit pouvoir accéder à toutes les applications de l’environnement, tandis que le second est un gestionnaire RH qui n’a besoin d’accéder qu’à une application Web dédiée au service des ressources humaines.      

 

Ce module obéit au plan suivant :

Responsable du laboratoire :

Module 4 : Chris Cousins, ingénieur système en chef, États-Unis

 

Explorer le lien entre NSX et Active Directory


NSX établit un lien avec Active Directory afin de s’appuyer sur les groupes Active Directory pour la création de règles de pare-feu basées sur l’identité.


 

Lancer le navigateur et vSphere Web Client

 

 

 

Explorer le lien entre NSX et Active Directory

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Networking & Security.

 

 

Synchronisation Active Directory

 

  1. Cliquez sur l’icône Engrenage.
  2. Cliquez sur l’icône Roue dentée pour recevoir les mises à jour d’Active Directory.  Le statut « Success » et la date du jour doivent s’afficher.

Notez que cette opération peut prendre de 2 à 3 minutes.

Maintenant que la connexion à Active Directory est configurée et synchronisée, vous pouvez commencer à utiliser les groupes Active Directory dans vos règles de sécurité.

 

Introspection client NSX


Avant de créer des règles de pare-feu basées sur l’identité, nous devons configurer l’introspection client NSX.


 

Déployer l’introspection client

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Networking & Security.

 

 

Onglet « Service Deployments »

 

  1. Sélectionnez Installation.
  2. Sélectionnez l’onglet Service Deployments.
  3. Cliquez sur l’icône + pour déployer l’introspection client.

 

 

Assistant de déploiement de l’introspection client

 

  1. Sélectionnez le service Guest Introspection.
  2. Cliquez sur Next.

 

  1. Sélectionnez RegionA01-COMP02.
  2. Cliquez sur Next.

 

  1. Conservez la valeur par défaut.
  2. Cliquez sur Next.

 

 

Début de la collecte de données

 

  1. Cliquez sur Finish.

Attendez quelques minutes que l’installation soit terminée, puis vérifiez que celle-ci a abouti au sein du cluster.

 

 

 

Vérifier l’installation de l’introspection client sur les hôtes

 

  1. Cliquez sur l’icône Home.
  2. Cliquez sur Hosts and Clusters.

 

  1. Développez le dossier RegionA01-COMP02.
  2. Vérifier que la VM d’introspection client est opérationnelle et qu’elle bien a été déployée sur l’hôte esx-03a.corp.local.
  3. Vérifiez qu’une adresse IP a été affectée à la VM d’introspection client.

 

Utiliser des objets de sécurité basés sur des groupes Active Directory


  1. Les objets de sécurité sont définis selon des critères d’appartenance à des groupes Active Directory et interviennent dans l’application des règles de sécurité.

 

Créer un objet de sécurité basé sur des groupes Active Directory

 

  1. Placez le pointeur de la souris sur le bouton Home.
  2. Cliquez sur Networking & Security.

 

 

Créer une section de règles de pare-feu

 

  1. Dans le volet de navigation, cliquez sur le lien Firewall.
  2. Cliquez sur l’icône Add Section dans la section Flow Monitoring & Traceflow Rule.

 

 

Ajouter une règle pour l’administrateur réseau

 

  1. Cliquez sur l’icône Add rule dans la section de règles nouvellement créée.
  2. Cliquez sur la flèche déroulante pour développer cette nouvelle section.
  3. Cliquez sur l’icône Crayon dans la colonne Name pour modifier la nouvelle règle.

 

 

Ajouter une règle pour le gestionnaire RH

 

  1. Cliquez sur la flèche déroulante pour développer la section « AD Based Firewall Rules ».
  2. Cliquez sur l’icône Add Rule.

 

Définir des règles de pare-feu pour les applications internes


Les applications internes de ce laboratoire nécessiteront des règles supplémentaires autorisant la communication entre les niveaux d’application.


 

Ajouter une règle de pare-feu supplémentaire

 

Nous avons créé des règles de pare-feu autorisant les gestionnaires RH et les administrateurs réseau à accéder aux applications appropriées selon leur rôle. Il nous faut cependant ajouter une règle autorisant l’accès entre les services internes, ainsi que modifier la règle de pare-feu par défaut de façon à bloquer tous les autres accès, et notamment les accès externes.

  1. Cliquez sur Firewall pour accéder aux règles de pare-feu.

 

 

Modifier la règle de pare-feu par défaut

 

Afin de bloquer tout trafic indésirable, nous devons activer le blocage au sein de la règle de pare-feu par défaut. La règle de pare-feu par défaut se trouve dans la section « Default Firewall Rule ».

  1. Cliquez sur la flèche déroulante pour développer la section « Default Firewall Rule ».
  2. Cliquez sur l’icône Crayon dans la colonne Action de la règle par défaut.
  3. Sélectionnez Block comme action.
  4. Cliquez sur Save.

 

Tester les règles basées sur l’identité des utilisateurs


Pour tester les règles nouvellement créées, nous allons devoir nous connecter à la VM win12-jump sous différentes identités Active Directory.


 

Tester la règle basée sur l’identité de l’utilisateur

 

Pour tester les nouvelles règles basées sur l’identité, vous allez ouvrir une console pour la VM de jump box (win-12-jump) déployée dans le domaine, et vous connecter à cette VM en tant que membre du groupe AppConfiguration puis du groupe Human Resources d’Active Directory.  L’utilisateur Netadmin est membre du groupe AppConfiguration et est donc autorisé à se connecter à toutes les applications et tous les niveaux d’application internes. L’utilisateur HRadmin est membre du groupe Human Resources et n’est donc autorisé à se connecter qu’à ces deux applications Web : HR ou Finance.  Vous allez vous connecter tour à tour sous ces deux identités et observer les résultats obtenus lorsque vous tentez d’accéder à différentes applications 3 tiers.

  1. Cliquez sur le bouton Home.
  2. Cliquez sur l’icône VMs and Templates.

 

 

Ouvrir une console pour la jumb box

 

Développez les conteneurs « RegionA01 » et « Discovered virtual machines » afin de localiser la VM win12-jump.

  1. Développez Misc VMs.
  2. Cliquez avec le bouton droit sur win12-jump.
  3. Cliquez sur Open Console.

 

 

Changer d’utilisateur

 

  1. Cliquez sur Send Ctrl+Alt+Delete.
  2. Cliquez sur Other user.

 

 

Se connecter en tant que NetAdmin

 

  1. Saisissez le nom d’utilisateur NetAdmin.
  2. Saisissez le mot de passe VMware1!  (y compris le signe « ! »).
  3. Cliquez sur la flèche.

 

Conclusion du module 4


Félicitations ! Vous avez terminé le module 4.

Ce laboratoire nous a montré comment utiliser les fonctionnalités de pare-feu basé sur l’identité intégrées dans NSX pour contrôler l’accès aux applications internes.  Nous avons créé des règles de pare-feu basées sur Active Directory pour un administrateur réseau ainsi que pour un gestionnaire RH. Ces règles autorisent uniquement le gestionnaire RH à se connecter à l’application Web HR via le protocole HTTP.  En revanche, elles autorisent l’administrateur réseau à se connecter à n’importe laquelle des applications via le protocole de son choix.  Nous pouvons ainsi nous assurer que chaque utilisateur accès aux applications appropriées avec le niveau de privilèges correspondant à son rôle dans l’organisation.

Si vous souhaitez en savoir plus sur les fonctionnalités de pare-feu basé sur l’identité de NSX, rendez-vous dans le Centre de documentation NSX 6.3 via l’URL suivante :

Liste des modules du laboratoire :

Responsable du laboratoire :


 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Module 5 : Gestionnaire de règles d’application de NSX (30 minutes)

Module 5 : Gestionnaire de règles d’application



 

Introduction

Le gestionnaire de règles d’application est un jeu d’outils nouvellement introduit dans NSX 6.3 qui exploite les données de flux en temps réel pour accélérer et optimiser la planification de la micro-segmentation et l’implémentation des modèles de sécurité zéro confiance. Le gestionnaire de règles d’application propose une solution inédite pour sécuriser des applications nouvelles ou existantes dont l’échelle dépasse la capacité de prise en charge de Log Insight, ou des environnements trop réduits pour pouvoir être pris en charge par vRealize Network Insight (vRNI).

Le gestionnaire de règles d’application recueille en temps réel les données des flux entrants, sortants ou échangés entre les charges de travail applicatives pour permettre la création de modèles de sécurité axés sur les applications. Ce gestionnaire est capable de surveiller jusqu’à 30 VM par session, et 5 sessions peuvent être exécutées simultanément. Le gestionnaire de règles d’application offre également une visibilité sur les flux bloqués et sur les règles de pare-feu qui bloquent le trafic.  

Le workflow du gestionnaire de règles d’application comprend trois étapes :

  1. Sélection des machines virtuelles (VM) qui constituent l’application et sont à surveiller. Une fois le gestionnaire configuré, tous les flux entrants et sortants d’un ensemble déterminé de VNIC présentes sur ces VM sont surveillés. Il est possible d’exécuter simultanément jusqu’à cinq sessions de collecte de flux.
  2. Arrêt de la surveillance afin de générer les tables de flux. Les flux sont analysés en vue de révéler les interactions entre les VM. Il est possible de filtrer les flux de façon à limiter les enregistrements de flux à un ensemble de données actif de taille réduite.
  3. Utilisation des tables de flux pour créer des objets de groupement tels que groupes de sécurité, ensembles d’adresses IP, services ou groupes de services, et règles de pare-feu.

Responsable du laboratoire :

Module 5 : Chris Cousins, ingénieur système en chef, États-Unis

 

Micro-segmentation orientée applications



 

Lancer le navigateur Chrome et vSphere Web Client

 

  1. Double-cliquez sur l’icône Chrome présente sur le bureau.

 

 

Se connecter à vSphere Web Client

 

Si vous n’êtes pas déjà connecté à vSphere Web Client :

(Normalement, la page d’accueil est celle de vSphere Web Client. Si ce n’est pas le cas, cliquez sur l’icône Google Chrome de vSphere Web Client dans la barre des tâches.)

  1. Saisissez administrator@vsphere.local dans le champ « User name ».
  2. Saisissez VMware1! dans le champ « Password ».
  3. Cliquez sur Login.

 

 

Exploration du gestionnaire de règles d’application

 

  1. Sélectionnez Home.
  2. Sélectionnez Networking & Security.

 

 

Sélectionner « Flow Monitoring »

 

  1. Sélectionnez Flow Monitoring.

 

 

Démarrer une nouvelle session pour HR_App

 

  1. Sélectionnez l’onglet Application Rule Manager.
  2. Cliquez sur Start New Session pour commencer à collecter les données de flux d’application.

 

 

Sélectionner les machines virtuelles de l’application HR_DB_App

 

  1. Champ « Session Name » : HR_DB_App.
  2. Sélectionnez Virtual Machine dans la liste déroulante « Object Type ».
  3. Saisissez hr dans le champ de recherche.
  4. Sélectionnez hr-web-01a.corp.local, hr-db-01a.corp.local et hr-app-01a.corp.local.
  5. Cliquez sur la flèche vers la droite.
  6. Cliquez sur OK.

 

 

Générer des flux de trafic - ICMP

 

Le gestionnaire de règles d’application collecte maintenant les données de flux provenant des trois machines virtuelles de l’application HR_App. Plus vous laisserez le processus de collecte s’exécuter longtemps, plus vous aurez de données à analyser. Dans le cadre de ce laboratoire, nous allons collecter des données de flux pendant trois minutes. Pour générer des données de flux :

  1. Ouvrez une session Putty et sélectionnez hr-web-01a.corp.local.
  2. Sur la ligne de commande, saisissez ping -c 2 172.16.60.12.
  3. Ouvrez la fenêtre Command Prompt sur la console principale.
  4. ping 172.16.60.10
ping -c 2 172.16.60.12
ping 172.16.60.10

 

 

Générer des flux de trafic supplémentaires - HTTPS

 

  1. Ouvrez un nouvel onglet dans Chrome.
  2. Cliquez sur le favori HR DB App.
  3. Actualisez la page à plusieurs reprises.

 

 

Collecte de données - Arrêt

 

Dans les trois minutes qui suivent, des flux doivent apparaître dans la console de surveillance des flux. Le nombre de flux varie d’un laboratoire à un autre.

  1. Au bout de trois minutes, cliquez sur Stop.
  2. Cliquez sur Yes pour confirmer.

 

 

Examiner les données de flux

 

Nous apercevons ici des adresses IP source et de destination, ainsi que des services tels que HTTP, HTTPS, etc.

 

 

Démarrer une nouvelle session pour Finance_DB_App

Avant d’analyser les données collectées pour HR_App, nous allons configurer une seconde session pour Fin_App afin de mettre en pratique l’exécution simultanée de plusieurs sessions de collecte de données de flux.

 

 

Démarrer une session pour Finance_DB_App

 

  1. Cliquez sur Start New Session.

 

 

Sélectionner les machines virtuelles de l’application Finance_App

 

  1. Champ « Session Name » : Finance_DB_App.
  2. Sélectionnez Virtual Machine dans la liste déroulante « Object Type ».
  3. Saisissez fin dans le champ de recherche.
  4. Sélectionnez fin-web-01a.corp.local, fin-db-01a.corp.local et fin-app-01a.corp.local.
  5. Cliquez sur la flèche vers la droite.
  6. Cliquez sur OK.

 

 

Collecte des données pour Finance_App

 

Le gestionnaire de règles d’application collecte maintenant les données de flux provenant des trois machines virtuelles de l’application Finance_App. Plus vous laisserez le processus de collecte s’exécuter longtemps, plus vous aurez de données à analyser. Dans le cadre de ce laboratoire, nous allons collecter des données de flux pendant trois minutes. Pour générer des données de flux, ouvrez un onglet Chrome, cliquez sur le favori Finance DB App et actualisez la page à plusieurs reprises. Dans les trois minutes qui suivent, des flux doivent apparaître dans la console de surveillance des flux. Le nombre de flux varie d’un laboratoire à un autre.

  1. Cliquez sur Stop.
  2. Cliquez sur Yes.

 

 

Examiner les sessions

 

Nous constatons que le gestionnaire de règles d’application a bien collecté des données de flux pour les machines virtuelles des deux applications : HR_DB_App et Finance_DB_App.

 

 

Examiner les sources

 

  1. Cliquez sur Source pour examiner les VNIC sous surveillance.

 

 

Examiner la durée de collecte des données de flux

 

  1. Cliquez sur Flows pour consulter l’heure de début et la durée de la collecte.

 

 

Lancer l’analyse des flux pour Finance_DB_App

 

  1. Cliquez sur Analyze pour analyser les données de flux collectées.

 

 

Lancer l’analyse des flux pour HR_App

 

Lorsque vous en avez terminé avec l’analyse des données de flux pour Finance_DB_App :

  1. Sélectionnez HR_DB_App dans le menu déroulant « Session ».
  2. Cliquez sur Analyze.

 

 

Vérifier que l’analyse des données est terminée

 

  1. Vérifiez qu’une coche verte est affichée au-dessus de la mention Analysis Complete. Cette coche confirme que l’analyse des données a abouti.

 

 

Vue traitée pour HR_DB_App

 

Après avoir analysé et traité les données de flux, NSX a remplacé les adresses IP par les noms des VM correspondantes, ce qui facilite le mappage logique des flux entre objets.

 

 

Règles de pare-feu pour HR_DB_App

 

Nous allons utiliser les informations fournies par le gestionnaire de règles d’application pour établir la micro-segmentation des machines virtuelles dans ou entre les applications HR_DB_App et Finance_DB_App. Voyons si hr-web-01a peut communiquer avec hr-db-01a.

  1. Ouvrez une session Putty pour hr-web-01a.corp.local.
  2. Cliquez sur hr-db-01a.corp.local dans la colonne « Destination » afin de récupérer son adresse IP.
  3. Nous voyons ici l’adresse IP 172.16.60.12 ainsi que les informations relatives à la VNIC.
  4. Envoyez une requête ping à 172.16.60.12. Cette requête ping doit aboutir sans perte de paquets.
ping -c 2 172.16.60.12

Nous venons d’établir que la machine virtuelle HR_DB_App web-01a a la possibilité de communiquer avec la machine virtuelle db-01a. Une telle situation est loin d’être idéale ! Nous allons maintenant configurer les règles de pare-feu appropriées pour contrôler le trafic entre les machines virtuelles des trois niveaux d’application.

 

 

Nouvelles règles de pare-feu

 

  1. Sélectionnez le flux présentant les valeurs suivantes : 192.168.110.10 dans la colonne « Source », hr-web-01a.corp.local dans la colonne « Destination » et SSH dans la colonne « Service ».
  2. Cliquez sur l’icône Roue dentée.
  3. Sélectionnez Create Firewall Rule.

 

 

Règle Control Center to HR_Web

 

  1. Dans le champ « Name », saisissez Control Center to HR_Web.
  2. Cliquez sur Selecten regard de « Service ».

 

 

Sélectionner les services

 

  1. Saisissez https dans le champ de recherche.
  2. Sélectionnez HTTPS.
  3. Cliquez sur la flèche vers la droite.
  4. Vérifiez que SSH et HTTPS ont bien été sélectionnés.
  5. Cliquez sur OK.

 

 

Vérifier la configuration

 

  1. Vérifiez que votre configuration correspond à cette capture d’écran, puis cliquez sur OK.

 

 

Configurer la règle de pare-feu HR_Web to HR_App

 

  1. Sélectionnez la ligne sur laquelle hr-app-01a apparaît dans la colonne « Destination ».
  2. Cliquez sur la roue dentée (menu « Actions ») et sélectionnez Create Firewall Rule.  

 

 

Nouvelle règle de pare-feu : HR_Web to HR_App

 

  1. Dans le champ « Name », saisissez HR_Web to HR_App.
  2. Conservez la valeur par défaut dans tous les autres champs et cliquez sur OK.

 

 

Configurer une nouvelle règle de pare-feu : HR_App to HR_DB

 

  1. Sélectionnez la ligne sur laquelle hr-db-01a apparaît dans la colonne « Destination ».
  2. Cliquez sur l’icône Roue dentée et sélectionnez Create Firewall Rule.
  3. NE sélectionnez PAS la ligne sur laquelle ICMP Echo apparaît dans la colonne « Service ».

 

 

Nouvelle règle de pare-feu : HR_App to HR_DB

 

 

 

Publier les règles de pare-feu

 

  1. Sous « Flow Details », sélectionnez l’onglet Firewall Rules. Nous retrouvons ici les règles de pare-feu que vous venez de créer.
  2. Cette vue permet également de modifier ou supprimer des règles de pare-feu.
  3. Cliquez sur Publish.

 

 

Indiquer un nom

 

  1. Champ « Session Name » : HR_DB_App.
  2. Sélectionnez Default Section Layer 3.

 

 

Examiner la règle de pare-feu HR_DB_App

 

  1. Sélectionnez Firewall dans le volet de navigation.

 

 

Règles de pare-feu relatives aux trois niveaux de HR_DB_App

 

Cet écran nous permet de vérifier les règles de pare-feu que nous venons de configurer dans le gestionnaire de règles d’application. Nous allons ensuite tester HR_DB_App pour vérifier que la page Web reste accessible et que le trafic non sécurisé a été bloqué.

 

 

Modifier la règle de pare-feu par défaut

 

  1. Sous la règle par défaut, cliquez sur l’icône Crayon pour modifier cette règle.
  2. Champ « Action » : Block.
  3. Cliquez sur Save.

 

  1. Publiez les modifications.

 

 

Vérifier le fonctionnement de HR_DB_App

 

Si vous aviez fermé l’onglet « HOL-HR Department » :

  1. Ouvrez un nouvel onglet dans Chrome.
  2. Cliquez sur le favori HR DB App.

Vérifiez que vous avez bien accès à la base de données RH relative à la rémunération des collaborateurs.

 

 

Ouvrir une invite de commande

 

Voyons s’il est possible de faire parvenir des requêtes ping au serveur Web, au serveur d’application et au serveur de base de données depuis la console principale :

  1. ping 172.16.60.10
  2. ping 172.16.60.11
  3. ping 172.16.60.12
ping 172.16.60.10
ping 172.16.60.11
ping 172.16.60.12

Nous constatons que le trafic ICMP est bloqué. Seul le trafic HTTPS est autorisé.

Remarque : dans le cadre de ce laboratoire, nous avons configuré la règle de pare-feu web-01a de sorte qu’elle accepte le trafic SSH, ce qui nous permet d’accéder à la machine virtuelle via Putty pour effectuer le test suivant.

 

 

Ouvrir Putty

 

ping -c 2 172.16.60.12
  1. ping -c 2 172.16.60.12
  2. Après une dizaine de secondes, appuyez sur les touches Control+C pour arrêter le test ping.

Nous constatons que le trafic de web-01a à db-01a a été bloqué !

 

Conclusion du module 5


Félicitations ! Vous avez terminé le module 5.

Si vous souhaitez en savoir plus sur le gestionnaire de règles d’application de NSX, rendez-vous dans le Centre de documentation NSX 6.3 via l’URL suivante :

Liste des modules du laboratoire :

Responsable du laboratoire :

  • Module 1 : Chris Cousins, ingénieur système en chef, États-Unis
  • Module 2 : Chris Cousins, ingénieur système en chef, États-Unis
  • Module 3 : Chris Cousins, ingénieur système en chef, États-Unis
  • Module 4 : Chris Cousins, ingénieur système en chef, États-Unis

 

Comment terminer le laboratoire

 

Pour terminer votre laboratoire, cliquez sur le bouton END.  

 

Conclusion

Merci d’avoir participé aux laboratoires d’essai en ligne VMware. Visitez le site http://hol.vmware.com/ pour poursuivre ce laboratoire en ligne.

SKU du laboratoire : HOL-1803-02-NET

Version : 20180417-114041