Débugguez vos règles firewall NSX-T

Quand on commence à faire de la production sur NSX-T (tout comme sur d’autres systèmes sécurisés), il est plus qu’utile de disposer d’outils de troubleshooting fiables et “temps réels”. Même si VMware Log Insight fait partie des systèmes de logging recommandés avec NSX-T, difficile au départ de tout maîtriser et souvent, un bon petit “tail” sur un log en fichier texte est finalement un moyen efficace et assez simple de debugguer et de vérifier ce qui se passe. Après une session extrêmement intéressante avec le support NSX-T de VMware (merci en particulier à Anaëlle qui se reconnaitra, si elle passe par là), je vous propose de partager les découvertes que j’ai fait concernant le debugguing des policies/règles DFW et Edge sur NSX-T.

Le préalable à ce debugging consiste à activer le logging sur les règles firewall que vous souhaitez checker. pour ce faire, il faut aller dans l’interface NSX-T, onglet “Security”, vous placer sur la règle en question et enfin commuter le paramètre “log” logging sur “Yes” :

Une fois fait, à chaque fois que cette règle “match”, quel que soit le contexte, une trace est envoyée au système de logging adéquat. Si votre règle fait partie des politiques de micro-segmentation – elles sont donc opérées par le Distributed Firewall de NSX-T – les traces sont envoyées dans le fichier /var/log/dfwpktlogs.log de l’ESXi sur lequel s’exécute la VM qui a déclenché le “match” à l’instant T. Si par contre, la règle fait partie de vos règles Nord-Sud – donc dépendantes de votre Service Router associé au TIER0/TIER1 concerné – dans ce cas, c’est dans le /var/log/syslog du edge-node actif où tourne votre routeur.

Dans les deux cas, les traces en questions vous indiquent le numéro de la règle qui a matché, l’ip source, l’ip destination et les ports TCP/UDP associés. Pour ESXi ça donne un truc comme ça :

L’id de la règle matchée apparait juste après le “match PASS” ou le “TERM”. Dans l’exemple, on discerne la 7202 et la 7193. Vous remarquerez au passage que ce format de log est relativement standard, il est facile de l’injecter dans une suite type Elastic/Logstash/Kibana par exemple (si vous ne voulez pas utiliser Log Insight). Pour retrouver le nom de votre règle, il faut aller dans la section “Advanced Networking & Security->Security->Distributed Firewall” et déployer vos règles, Vous aurez accès à leur ID. Malheureusement, jusqu’à la 2.4.1, a ma connaissance, l’ID n’est visible qu’à cet endroit dans l’interface graphique :

Pour la partie Edge, vu que c’est un peu noyé dans le syslog général, il faut filtrer tout cela :

La encore pour obtenir le nom de la règle à partir de son ID, rendez-vous “Advanced Networking & Security->Security->Routers”, cliquez sur le routeur concerné et placez-vous dans l’onglet “Services->Edge firewall”. Oui, ok, c’est un peu lourd, mais je pense que ça devrait s’arranger avec les futures versions de NSX-T… on ne sait jamais, peut-être dès la 2.5 qui devrait sortir incessamment à l’heure où j’écris ces lignes (1er Août 2019) :

Vous l’aurez compris, un concentrateur de log est particulièrement utile pour ce genre de traces, mais si vous voulez allez vite à la source de l’information, cela peut vous aider :)

D’autre part, j’ai également découvert, via cette session, de nouvelles commandes sur ESXi directement en lien avec la gestion des règles NSX-T (mais aussi NSX-V) mais aussi le suivi des flow IP, d’une manière plus générale.

La première, summarize-dvfilter vous permet d’obtenir, pour chaque VM tournant sur la machine, la liste de ses “slots” dvFilter (si ça vous intéresse de creuser cette notion, rendez-vous ici sur un excellent billet de VMware qui explique la chaine “IO network” sur ESXi entre la VM et la carte réseau de l’hyperviseur). Par exemple, un petit extract de cette commande sur une de nos machines de production :

Ce qui nous intéresse ici c’est le nom des dvFilters implantés sur la VM “linuxtst”. Vous pouvez voir ici que le slot “2” est actuellement attaché, c’est celui qu’on va utiliser pour la suite. Une fois votre nom de slot trouvé, vous pouvez l’utiliser avec d’autres commandes tout aussi intéressantes. Par exemple, la commande “vsipioctl getflows -f nom_de_votre_slot” vous affiche les flux IP actuellement référencés sur la VM. Exemple :

Vous pouvez aussi récupérer l’ensemble des règles bas-niveau implantées sur le slot :

Vous noterez ici que les règles macros que l’on peu être amené à mettre en place sur NSX sont éclatées par protocole et doublés pour IPv4 et IPv6 (si vous avez laissé cette option activé dans les règles en question). Ca permet de pouvoir vérifier que toutes ces règles sont bien légitimes et que vous n’avez pas une règle parasite matchant cette VM alors qu’elle ne devrait pas. Bref, encore un excellent moyen de débugguer un flux capricieux ou un pb de sécurité sur une machine.

Les GUID des sets d’addresses (IP, Mac) peuvent être retrouvés avec la même commande vsipioctl mais avec la directive getaddrsets (merci à Alexis pour le rappel) :

Au passage, ça m’a permit de retrouver une règle qui prenait un peu ses aises et matchait des VMs non souhaitées, celle correspondant à l’ID 7228…

Avec tout cela et sans l’aide de VMware Log Insight (cela fera l’objet d’un autre billet sans doute), vous êtes déjà capable à la main, à l’ancienne, de vous dépatouiller de soucis d’accès ou de non accès à certaines VMs en production, voir d’identifier des trous dans votre sécurité, que ce soit vis à vis de la microsegmentation (DFW) ou sur les Service Routers de vos TIERx.