VMware NSX : DFW et les VMware Tools

VMware NSX embarque une fonctionnalité de firewall distribué appelé DFW : Distributed Firewall, avec laquelle les règles de firewall sont automatiquement poussées et distribuées sur la totalité de l’environnement NSX. La gestion de vos flux et de vos règles firewall devient alors centralisée, simplifiée.

Le but de cet article est montrer cette fonctionnalité DFW.
Ainsi nous allons créer une règle DFW qui devra bloquer le traffic ICMP (ping) depuis un serveur APP vers un pool de 3 serveurs WEB.

Schéma de la Topologie

VM	ESX	VXLAN
LAB-APP-172.16.10.31	ESX-COMPUTE-62	APP 5002 – 172.16.10.0/24
LAB-WEB-172.16.20.31	ESX-COMPUTE-63	WEB 5001 – 172.16.20.0/24
LAB-WEB-172.16.20.32	ESX-COMPUTE-63	WEB 5001 – 172.16.20.0/24
LAB-WEB-172.16.20.33	ESX-COMPUTE-63	WEB 5001 – 172.16.20.0/24

La règle représentée en bleu sur le schéma, sera distribuée sur les esx-compute-62 et esx-compute-63 et devra bloquer le traffic ICMP depuis la VM APP (esx-compute-62) vers les VMs WEB (esx-compute-63).

1) Création de la Règle (Allow)

Nous commençons par la création de la règle APP-31-to-WEB (ALLOW)

Source : LAB-APP-172.16.10.31
Destination : LAB-WEB-172.16.20.31 / LAB-WEB-172.16.20.32 / LAB-WEB-172.16.20.33
Service : ICMP Echo & ICMP Reply
Action : Allow (pour l’instant)

La règle est appliquée !

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_16h57_23.png$

2) Vérification de la Règle (Allow)

Pour confirmer que la règle DFW APP-31-to-WEB fonctionne, tentons de ping nos VMs WEB depuis la VM APP :
– Ping LAB-WEB-172.16.20.31 : OK
– Ping LAB-WEB-172.16.20.32 : OK
– Ping LAB-WEB-172.16.20.33 : OK

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_16h59_56.png$
Comme annoncé, le ping depuis la VM LAB-APP-172.16.10.31 vers le pool des VMs WEB fonctionne, ce qui est normal car l’action est en Allow.
Bloquons maintenant le flux en passant l’action de la règle en BLOCK !

3) Modification Action : Allow to Block

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_17h00_40.png$

4) Vérification de la règle (Block)

En passant l’action en Block, le ping depuis la VM APP vers les VMs WEB devrait ne plus fonctionner.
Confirmons cela en réalisant le même test de ping depuis la VM APP vers les VMs WEB :
– Ping LAB-WEB-172.16.20.31 : NOK
– Ping LAB-WEB-172.16.20.32 : NOK
– Ping LAB-WEB-172.16.20.33 : OK

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_17h01_48.png$
Le ping vers la VM WEB LAB-172.16.20.33 fonctionne toujours. Pourquoi ? On a pourtant placé la règle en Block ICMP.

5) Récupérer le RULE-ID de la règle

Analysons la règle DFW directement au niveau des esx-compute-62 et esx-compute-63 pour en avoir le cœur net.
Chaque règle DFW fait référence à un RULE-ID, pratique pour de l’analyse de logs ou lorsque l’on souhaite repérer rapidement une règle firewall comme c’est le cas ici.

Le Rule-ID n’est pas visible par défaut. Pour l’afficher, il suffit de cocher Rule ID sur la droite de la page.
La règle APP-31-to-WEB a le Rule-ID : 1016

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_17h11_31.png$

6) Lister les filtres présent sur un ESX : summarize-dvfilter

La commande summarize-dvfilter permet de lister tous les filtres présents sur l’ESX.

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_17h09_19.png$

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_17h10_23.png$
Avec VMware NSX, les filtres sont appliqués aux vnics des VMs. Chaque vnic embarque 3 slots, donc 3 filtres qui sont les suivants :
Slot 0 = DVFilter (Distributed Virtual Filter)
Slot 1 = sw-sec (Switch Security)
Slot 2 = VMware-sfw (DFW firewall rules)

Le slot 2 est celui qui nous intéresse car c’est celui où les filtres firewall sont appliqués. Les filtres au niveau du slot 2 sont représentés de la manière suivante : nic-xxxx-eth[x]-vmware-sfw.2

La comamnde summarize-dvfilter est d’autant plus importante car elle nous permet de récupérer : l’UUID de la VM, le vcUuid.
Cet UUID va nous permettre de lier un filtre à une VM et par conséquent de récupérer les règles de firewall appliqué à une VM.

esx-compute62

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_17h06_29.png$
À l’aide de la commande esxtop (n=network), on peut voir que la VM LAB-APP-172.16.10.31 est bien sur l’esx-compute-62.
Notez le PORT-ID de la VM LAB-APP-172.16.10.31 : 83886089 (trouvé également à l’aide de la commande summarize-dvfilter).

esx-compute63

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_17h09_58.png$
Les VMs WEB sont bien présentes sur l’esx esx-compute-63.
VM-LAB-172.16.20.31 Port-ID : 83886086
VM-LAB-172.16.20.32 Port-ID : 83886087
VM-LAB-172.16.20.33 Port-ID : 83886088

7) Récupérer les Filtres DFW (slot 2) : vsipioctl getfilters

La commande vsipioctl getfilters permet de lister tous les filtres firewall trouvés, donc au niveau du slot 2 d’une vnic.

esx-compute62

Sur l’esx-compute-62, la commande vsipioctl getfilters nous renvoi le filtre suivant : nic-546842-eth0-vmware-sfw.2.
La commande nous donne également le VM UUID du filtre, c’est à dire la VM sur laquelle est appliqué ce filtre.
Le VM UUID trouvé est le même que le VcUuid de la VM LAB-APP trouvé par la commande summmarize-dvfilter.

Ce filtre correspond donc bien à la VM LAB-APP-172.16.10.31.
On comprend donc que le filtre nic-546842-eth0-vmware-sfw.2 est appliqué à la vnic de la VM APP.

esx-compute63

Sur l’esx-compute-63, la commande vsipioctl getfilters nous renvoie 3 filtres, un filtre pour chacune des VM WEB :
LAB-WEB-172.16.20.31 : nic-94006-eth0-vmware-sfw.2
LAB-WEB-172.16.20.32 : nic-543439-eth0-vmware-sfw.2
LAB-WEB-172.16.20.33 : nic-548132-eth0-vmware-sfw.2

Dans cet exemple, nous avons pris le filtre de la VM LAB-WEB-172.16.20.31 : nic-94006-eth0-vmware-sfw.2

8) Lister les Règles DFW : vsipioctl getrules

Pour lister toutes les règles DFW appliqués au niveau du filtre de la VM APP il suffit de taper :vsipioctl getrules –f nic-546842-eth0-vmware-sfw.2

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_17h18_35.png$

La commande nous renvoi toutes les règles appliquées à ce filtre. Ici on retrouve, la RULE 1016 qui est notre règle APP-31-to-WEB.
La rule 1016 drop les paquets ICMP echo (0) et reply (8) depuis la source ip-vm-462 vers la destination dst1016.

Comme vous pouvez le voir, nous n’avons pas d’adresse IPs ni en source ni en destination au niveau de la règle.
Pour la rule 1016, on a:
– from addrset ip-vm-462
– to addrset dst1016

D’où cela vient ? Cela représente quoi ?
Pourquoi n’avons nous pas les adresses IPs de la VM APP en source (from) et celles des VMs WEB en destination (to)?

Lorsque l’on a créé notre règle 1016, nous avons pour la source et la destination, sélectionné des objets VMs et non pas des adresses IPs comme pour un Firewall traditionnel.

Avec VMware NSX et DFW, vous avez la possibilité de renseigner tout types d’objets vCenter lors de la mise en place de vos règles. Vous pouvez comme on l’a fait ici sélectionné une VM, mais vous pouvez sélectionner un Cluster entier, un Datacenter, un PortGroup, n’importe quoi ..

En sélectionnant des objets, NSX Manager doit au moment de la création d’une règle firewall, récupérer à l’aide de l’API vCenter, l’adresse IP de(s) VM(s) pour autoriser/refuser le flux.
Pour notre règle 1016, NSX Manager doit récupérer les adresses IPs des VMs APP et WEB.

9) Trouvez l’ID d’une VM

Pour retrouver l’ID d’une VM, vous pouvez utiliser PowerCLI

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_17h41_28.png$

Vous pouvez également utiliser le MOB du vCenter (API Browser).
Content > group-d1(datacenters)>vm-id>

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_17h41_48.png$

10) Lister les adresses liées aux rules : vsipioctl getaddrsets

La commande vsipioctl getaddrsets –f nic-546842-eth0-vmware-sfw.2 (slot 2 de la VM APP) permet de lister les adresses liées aux rules trouvées via la commande vsipioctl getrules –f nic-546842-eth0-vmware-sfw.2.

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_17h18_35.png$

Dans notre cas, pour la rule 1016, on aimerait savoir ce qui se cache derrière l’adresse ip-vm-462 et derrière l’adresse dst1016.
addrset ip-vm-462 = 172.16.10.31 (VM APP)
addrset dst1016 = 172.16.20.31 (VM WEB31) et 172.16.20.32 (VM WEB32)

Cependant, on ne trouve pas l’adresse 172.16.20.33 (web33) dans notre adresse dst1016.

Étant donné qu’on ne trouve pas l’adresse IP de la VM WEB33 au sein de l’addrset dst1016, la règle DFW 1016 ne peut pas appliquer et ainsi bloquer le traffic ICMP depuis la VM APP vers la VM WEB33.

C’est donc là que les VMware Tools jouent un rôle crucial !NSX Manager a besoin que les VMware Tools soient installé sur les VMs pour pouvoir récupérer leurs adresses IPs.Sans les VMware Tools, NSX Manager ne peut pas récupérer l’adresse IP de la VM.

C’est pour cela qu’on n’a pas l’adresse IP de la VM WEB33.

11) Modifier la règle DFW

Pour corriger cela, il est possible de remplacer l’objet VM par l’adresse IP de la VM. Cependant, on perd tout l’intêret de VMware NSX et de la manipulation des objets. On revient un peu à un firewall « standard ».

Ici on niveau de notre rule APP-to-WEB, on a remplacé l’objet VM (LAB-WEB-172.16.20.33) par son adresse IP directement.

$C:\Users\igor\Desktop\vinception\Screenpresso\2016-05-05_17h43_16.png$