Rappelez-vous. Mais si, rappelez-vous là, il y a quelques jours, on avait mis le doigt sur un comportement très bizarre et inquiétant du NAT NSX-T. Nous venons d’avoir un retour officiel du support VMware. C’est bien un bug connu, mais sa portée est plus large qu’initialement constaté par les équipes NSX. petite explication …
Ce bug est déjà référencé, Voici le KB#79428 daté de début Juin 2021 qui précise le comportement déclaré officiellement par VMware. Il s’agit en fait d’un souci d’interprétation des champs du formulaire de NAT de GUI NSX-T. Les champs « service » et « translated ports » sont inversés ! j’ai envie de dire « tout simplement » (j’ai aussi envie de dire BOUH, private joke, coucou Antoine).
Par contre, contrairement à ce que dit l’article, même avec des installation fraiches 3.0, 3.1 sans upgrade le problème existe bel et bien toujours. C’est la portée du KB qui doit et va être revue (grand merci à Fabien pour son aide et son action auprès de l’ingéniering NSX-T). On devrait avoir des nouvelles encore plus précises dans les jours/semaines qui viennent.
Voici ce qui se passe pour illustrer le souci. Vous créez une règle simple qui autorisé un NAT vers du SSH sur une machine cible :
Ici le NAT est posé sur l’IP virtuelle 172.28.27.2 et pointe vers l’IP native de la VM 172.28.28.100. Le service choisi est donc le port 22 (SSH)
Voila ce que la règle de NAT devient quand elle est implantée sur le service NAT du tier1 :
edge1> get firewall 0262376a-c931-4404-8b52-01fe230e32c6 ruleset rules
Thu Oct 21 2021 UTC 17:36:41.958
DNAT rule count: 1
Rule ID : 536871940
Rule : in protocol tcp postnat from any to ip 172.28.27.2 dnat ip 172.28.28.100 port 22
Vous notez que le port 22 n’existe pas dans la partie source (donc ANY port, par défaut), en revanche elle est précisé dans la destionation (port 22).
Dans la pratique le firewall du tier1 interprète cette directive comme : j’écoute sur tous les ports source de l’IP NAT mais je redirige tous ce que je reçois sur le port 22.
Si je viens rajouter le port 22 dans le champ « translated port », tout rentre dans l’ordre car le port 22 coté NAT est, cette fois ci, correctement positionné.
edge1> get firewall 0262376a-c931-4404-8b52-01fe230e32c6 ruleset rules
Thu Oct 21 2021 UTC 17:40:43.592
DNAT rule count: 1
Rule ID : 536871940
Rule : in protocol tcp postnat from any to ip 172.28.27.2 port 22 dnat ip 172.28.28.100 port 22
Au final, l’hypothèse « L7 » tombe à l’eau car cela n’a pas grand chose à voir… La question est maintenant : est-ce que c’est dangereux ? Comme ça en première analyse je dirais : oui et non. Oui, car le fait d’exposer très largement une réponse POSITIVE à un scan sur le net attire forcément l’attention des éventuels script-kiddies, voir pire. Non, dans le sens ou la sécurité elle-même, n’est pas spécialement compromise : c’est bien uniquement le service firewall du tier qui répond et non la machine elle-même. La VM reste protégée de la même façon.
En tout état de cause et avant que ce bug soit résolu, je vous conseille fortement, par précaution, de revoir un maximum vos politiques de NAT qui n’ont pas de translated port renseigné ^^. Rappelez-vous aussi que ce bug n’existe pas quand vous utilisez les API NSX…
Merci à Arnaud, Alexis, Wilfried, Fabien, Luc, Gaël pour leur aide !
La GUI c’est pour les faibles, t’asson …
EDIT du 22 Novembre: VMware a créé un nouveau KB reflétant la situation. C’est documenté et donc, le bug est bien confirmé. Je précise aussi que contrairement à ce que je pensais le bug EST AUSSI PRESENT VIA L’API ! Donc, faites gaffe à vos NAT ^^. L’article : https://kb.vmware.com/s/article/86356?lang=en_US.