J’étais passé à coté lors de la sortie de NSX-T 3.1 et ça valait le coup d’en parler : vous pouvez désormais créer vos propres listes blanches de domaines accessibles à vos machines dans vos règles NSX. Voyons ça de plus près.
Jusqu’à NSX-T 3.0, il était déjà possible de rajouter du filtrage par FQDN dans vos matrices de flux, mais uniquement via une liste prédéfinie de domaines. Celle-ci ne se limitait qu’à certains grands noms du cloud (Microsoft, AWS et quelques autres) et restait donc une fonction plus qu’accessoire depuis les débuts. Avec la version 3.1 sortie en septembre dernier, on dispose ENFIN de la possibilité d’ajouter à loisir des domaines personnels.
Tout se joue au niveau des Context Profiles (qui travaillent pour la plupart au niveau 7, ceci expliquant donc cela). La première chose à faire consiste à “tracer la résolution DNS” au niveau du distributed firewall. Vous devez, dans l’ordre, procéder d’abord à l’interception des flux DNS, les laisser passer (ALLOW), afin que le moteur statefull soit au courant de ce que vous avez résolu des adresses en particulier. Ensuite, en dessous de ces premières règles, vous rajoutez votre filtre FQDN règle avec un, là aussi, un context profile en précisant le ou les domaines ainsi que votre apply-to classique et la target souhaitée (allow ou deny typiquement).
Un exemple valant mieux que de long discours, on va utiliser un use-case simple. Vous voulez autoriser une VM Debian à accéder uniquement à ses repositories principaux pour les mises à jours, et uniquement cela. Pour se faire, 2 règles sont nécessaires, ça peut ressembler à cela :
La première règle met en place le suivi de résolution DNS avec l’aide d’un context profile de type “DNS”. La seconde consiste à créer de toute pièce un nouveau context profile qui va regrouper la liste des domaines ad-hoc que vous souhaitez autoriser, par exemple :
1
2
deb.debian.org
security.debian.org
Je vous conseille dans un premier temps de créer le context profile depuis la section “Inventory” de l’interface NSX. En effet, même si vous pouvez en théorie le faire directement depuis les règles de filtrage, vous allez devoir ouvrir de nombreuses sous-fenêtres pour spécifier tout cela. Quelques empilements d’assistants de moins ne seront pas de trop. Voici la cinématique de création :
Vous noterez que j’ai rajouté un domaine supplémentaire à deb.debian.org et security.debian.org, *.fastlydns.net. En effet, il peut être nécessaire d’y revenir plusieurs fois si vous devez ouvrir des services complexes ou imbriqués. Vous le savez sans doute mais les poupées gigognes des services DNS publics sont souvent nombreuses. Pour le coup, les repos que j’ai choisi pour ma Debian11 utilisent les services d’un CDN dont les url se terminent par fastlydns.net. C’est une des limites du service de FQDN filtering de NSX, on ne peut filtrer que des domaines, pas des url complètes (ça commence à arriver sur la 3.2 et c’est limité aux service routers de nos TIER0/TIER1, pas au DFW dans son ensemble (merci à Alexis pour la précision, https://twitter.com/alagoutte). Ça s’explique en grande partie à cause de la complexité nécessaire à l’analyse d’url, le Deep Packet Inspection étant indispensable dans ce cas.
A noter aussi que vous pouvez évidemment faire du FQDN filtering avec autre chose que du http. La plupart des protocoles L7 au dessus de TCP et UDP sont possibles. ICMP n’est quant à lui pas pris en charge.
Pour toute précision, vous pouvez consulter la doc VMware officielle, ici.
Allez voir aussi ici, chez un bloggeur NSX et sécurité qu’il est bien dans le dedans.
MAJ: Enfin, un conseil, ça semble globalement une évidence dans tout système de filtrage basé sur des règles, mais faites bien attention à leur ordre. En particulier, vérifiez bien que la règle qui va matcher la partie “tracking” de la résolution DNS est bien la PREMIERE, dans le contexte de sécurité. Ça arrive même aux meilleurs, mais une règle sans context profile qui va matcher, qu’elle soit spécifique aux flux DNS ou pas (genre, je laisse passer tous les réseaux d’un réseau de confiance en full ip, au hasard), ne sera pas utilisable et rendra votre context profile “FQDN” non applicable. Je le dit, parce que ça va mieux en le disant, mais aussi car c’est exactement ce qui nous est arrivé récemment au boulot, et pourtant, on est les meilleurs en NSX-T, c’est bien connu ^^.
J’avais tellement la tête dans le guidon que je n’avais pas repéré cette nouvelle fonction avant qu’un de mes collègues ne retombe dessus récemment, bien vu, Romain !
