Récemment, j’ai été missionné pour mettre en place une infrastructure PKI (Public Key Infrastructure) Microsoft chez l’un de nos clients. Lors de l’installation du certificat sur l’autorité de certification subordonnée, j’ai rencontré un message d’erreur inattendu : “Impossible de vérifier la chaîne de certificats. Voulez-vous ignorer l’erreur et continuer ? La fonction de révocation n’a pas pu vérifier la révocation car le serveur de révocation était déconnecté. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)”

“Cannot verify the certificate chain. Do you want to ignore the error and continue? The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)”

Après investigation, j’ai découvert que mon point de distribution de certificats (CDP) comportait un chemin d’accès inhabituel, comme vous pouvez le voir partiellement dans la capture de l’URL ci-dessous. J’ai réalisé que les variables insérées lors de la configuration du CDP et de l’AIA (Authority Information Access) n’étaient pas interprétées, mais restaient telles que je les avais saisies initialement.

Ce qui était surprenant, c’est que j’avais déjà effectué cette procédure dans mon lab sans rencontrer ce problème. La configuration semblait similaire à celle du client, à l’exception que j’utilisais une installation fraîche de Windows Server 2019 (directement depuis l’ISO), tandis que le client employait son modèle de Windows Server 2022 en français.

Suspectant que la différence de langue pouvait être un facteur, j’ai modifié les extensions pour le CDP et l’AIA du client en utilisant mes variables en anglais, mais cela n’a pas résolu le problème.

Pour approfondir mon analyse, j’ai installé un Windows Server 2022 en français from scratch dans mon laboratoire et, à ma surprise, j’ai rencontré le même problème que celui observé chez le client. Cette situation m’a laissé dans l’incertitude : était-ce la version 2022 de Windows Server en elle-même qui posait problème, ou était-ce spécifiquement la version française qui était en cause ?

Afin d’écarté l’OS, j’ai installé un nouveau serveur sous Windows Server 2022, mais cette fois en version américaine. Après avoir effectué les modifications nécessaires sur le CDP et l’AIA, j’ai enfin obtenu le résultat escompté : les variables étaient correctement interprétées et le chemin de l’URL était correct !”

En résumé, cette expérience m’a enseigné une leçon importante concernant les installations des systèmes d’exploitation Microsoft, en particulier en ce qui concerne les infrastructures PKI. Il semble que l’utilisation de versions en français de Windows Server peut introduire des anomalies spécifiques qui ne sont pas présentes dans les versions anglaises. Ces différences peuvent conduire à des problèmes inattendus, particulièrement dans des configurations techniques complexes comme celle d’une PKI.

Ainsi, il est prudent de considérer l’utilisation des versions anglaises de Windows Server pour des installations critiques, afin d’éviter des problèmes de compatibilité ou de configuration qui pourraient être uniques aux versions localisées. Cette précaution pourrait épargner du temps et des efforts considérables lors du déploiement et de la maintenance d’infrastructures informatiques complexes.

Dans le monde du numérique, les menaces à la sécurité sont aussi inévitables que changeantes. Après le récent épisode avec AMD, nous voilà maintenant face à des vulnérabilités concernant Intel et Supermicro. La réactivité est notre meilleure alliée face à ces défis. Alors, voyons comment Nutanix orchestre sa riposte.

Intel et Supermicro : Deux Visages de la Vulnérabilité
La vulnérabilité chez Intel, baptisée “Downfall”, bien que sérieuse avec un score CVSS de 6.5, semble moins alarmante que celle identifiée dans le firmware Supermicro BMC IPMI qui affiche un score de 8.3. Chez Supermicro, les failles permettent des attaques telles que l’injection de commandes ou le Cross-Site Scripting (XSS), des menaces non négligeables qui exigent une attention immédiate.

Nutanix a rapidement pris la mesure des enjeux. Pour la vulnérabilité Supermicro, une mise à jour du firmware BMC est en élaboration pour les plateformes G6 et G7. G8 et G9 n’étant pas impactés. Du côté d’Intel, la situation reste inchangée, mais Nutanix fait preuve de transparence en tenant ses utilisateurs informés de la situation.

La révélation de ces vulnérabilités récentes souligne l’importance d’une veille constante et d’une communication efficace pour garantir la sécurité de nos systèmes. En partageant promptement ces informations, Nutanix contribue à établir un périmètre de vigilance face aux menaces extérieures.


Les vulnérabilités récentes sont un rappel de l’importance d’adopter une démarche proactive en matière de sécurité. La mise à jour régulière de nos systèmes et le suivi des recommandations des fournisseurs sont cruciaux. Nutanix, en se confrontant directement à ces défis, guide la communauté vers une infrastructure plus robuste et sécurisée.

Sources : https://download.nutanix.com/alerts/Security_Advisory_0030.pdf

https://download.nutanix.com/alerts/Security_Advisory_0028.pdf

Lors d’une session de formation partenaire chez Nutanix, un problème a fréquemment été soulevé par de nombreux consultants présents : le non-fonctionnement de l’option de déploiement automatique en masse des Nutanix Guest Tools (NGT) via Prism Central. Ce sujet est crucial car le déploiement des NGT est souvent une étape essentielle dans l’optimisation des environnements Nutanix.

La nécessité d’utiliser le port 2074 pour la communication réseau est bien connue, car avant la version AOS 6.6, les machines virtuelles (VMs) avaient besoin de communiquer avec les Controller VMs (CVMs) via ce port, ce qui pouvait représenter une contrainte significative dans certains environnements.

Cependant, il existe également des prérequis spécifiques liés au système d’exploitation invité (Guest OS) qui ne sont pas toujours clairement indiqués. Bonne nouvelle : ces contraintes sont allégées avec la sortie de la version AOS 6.6.

Pour ceux qui déploient des serveurs Windows, il y a une autre considération technique à prendre en compte : Windows Remote Manager Service (WinRM). Selon la documentation officielle de Nutanix :

Note: Windows Remote Manager Service (winrm) is required to install NGT from Prism Central only. It is not required when you upgrade NGT or install NGT manually by logging in to the guest VM.

Cependant, ce qui n’est pas forcément évident, c’est le détail du protocole de communication que WinRM utilise. Comme indiqué dans la base de connaissances de Nutanix sur “How To Configure WinRM for Remote Management“, Windows est configuré par défaut pour utiliser le protocole HTTP, qui opère sur le port 5985. Or, Prism Central s’attend à une communication sur le port 5986, qui utilise le protocole HTTPS, plus sécurisé.

Ce petit détail peut être source de complications lors de tentatives de déploiement automatique de NGT depuis Prism Central. Il est donc essentiel de configurer WinRM pour utiliser HTTPS afin d’assurer une communication fluide et sécurisée.

Mais comme indiqué dans la KB How To Configure WinRM for Remote Management, par défaut Windows est configuré en HTTP qui correspond au port 5985, mais comme vous pouvez le voir sur le tableau du dessus, Prism s’attend à communiquer sur le port 5986 donc en HTTPS.

Toutes les commandes de cet article sont exécutées depuis une invite PowerShell élevée.

Solution : Configurer le transport HTTPS

  1. Lancez PowerShell en tant qu’administrateur.
  2. Listez la configuration WinRM actuelle. Par défaut (nouvelle installation), seul le listener HTTP doit être configuré PS C:\> winrm e winrm/config/listener
  3. Liste des sockets ouverts. Par défaut (nouvelle installation), vous devriez voir le port 5985 en écoute : PS C:\> netstat -na | findstr 598 Vous devriez avoir un listener HTTP configuré avec les paramètres par défaut et le port 5985 en écoute.
  4. Autoconfigurez WinRM. Cela réinitialise le listener HTTP existant aux paramètres par défaut et effectue d’autres opérations de configuration nécessaires. PS C:\> winrm quickconfig
  5. Activez l’authentification de base pour WinRM PS C:\> winrm set winrm/config/service/auth "@{Basic=""true""}"
  6. Créez un certificat SSL auto-signé et configurez le transport HTTPS de WinRM. Les trois commandes ci-dessous se basent les unes sur les autres.
    • PS C:\> $my_hostname = [system.net.dns]::gethostname()
    • PS C:\> $my_certificate = new-selfsignedcertificate -dnsname $my_hostname -certstorelocation cert:\localmachine\my
    • PS C:\> winrm create winrm/config/listener?address=*+transport=https "@{hostname=""$my_hostname"";certificatethumbprint=""$($my_certificate.thumbprint)""}"
  7. Validez à nouveau avec PS C:\> winrm e winrm/config/listener PS C:\> netstat -na | findstr 598 Vous devriez maintenant avoir des listeners HTTP et HTTPS configurés avec les paramètres par défaut et les ports 5985 et 5986 en écoute.
  8. Validez et/ou configurez le pare-feu Windows pour autoriser les connexions entrantes.
    • Expérimentez et déterminez pour quel(s) profil(s) vous souhaitez autoriser l’accès. Pour cet article, les commandes ci-dessus ajoutent les règles aux trois profils.
    • Liste des règles de pare-feu existantes. Recherchez les règles répertoriées pour les ports 5985 et 5986 et vérifiez qu’elles sont activées pour tous les profils
    • PS C:\> Get-NetFirewallPortFilter -Protocol TCP | Where { $_.localport -match '598' } | Get-NetFirewallRule
    • Si les ports de l’étape précédente sont absents, ajoutez l’une ou l’autre des nouvelles règles de pare-feu ci-dessous (en fonction de ce qui manque ci-dessus)
      • PS C:\> New-NetFirewallRule -name "Windows Remote Management (HTTP-In)" -displayname "Windows Remote Management (HTTP-In)" -description "Règle entrante pour la gestion à distance de Windows via WS-Management. [TCP 5985]" -group "Gestion à distance de Windows" -Program "System" -protocol TCP -localport "5985" -action Allow -profile Domaine,Privé,Public
      • PS C:\> New-NetFirewallRule -name "Windows Remote Management (HTTPS-In)" -displayname "Windows Remote Management (HTTPS-In)" -description "Règle entrante pour la gestion à distance de Windows via WS-Management. [TCP 5986]" -group "Gestion à distance de Windows" -Program "System" -protocol TCP -localport "5986" -action Allow -profile Domaine,Privé,Public
    • Vous devriez maintenant avoir des listeners HTTP et HTTPS configurés avec les paramètres par défaut et les ports 5985 et 5986 en écoute. Utilisez l’étape 1 ci-dessus pour valider l’ajout de ces règles après avoir exécuté ces éléments.

Une fois WinRM correctement configuré pour accepter les demandes HTTPS, les obstacles au déploiement de NGT via Prism Central devraient être significativement réduits. Assurez-vous simplement de respecter les autres prérequis systèmes et réseau, même si WinRM est souvent le point bloquant dans ce processus.

Astuce : Le port 5986 doit être ouvert pour permettre la communication HTTPS entre Prism Central et les serveurs Windows.

Pour les administrateurs qui déploient NGT sur des serveurs Linux, la tâche est généralement plus simple. Le seul prérequis clé est l’ouverture du port 22, ce qui facilite grandement le processus de déploiement.

Si vous êtes comme moi, toujours à l’affût des dernières actualités tech, vous avez probablement entendu parler de cette récente faille de sécurité chez AMD, nommée “The speculative Return Stack Overflow (SRSO)”. Ça vous rappelle quelque chose ? Oui, je parle de Spectre et Meltdown. Alors, qu’est-ce qui distingue SRSO de ces deux-là ?

Le problème en quelques mots :

Certains processeurs AMD sont vulnérables à une attaque appelée SRSO, qui pourrait permettre à des personnes mal intentionnées d’accéder à des infos qu’ils ne devraient pas. Cela ressemble un peu aux failles Spectre et Meltdown qui ont fait la une il y a quelques années, où les attaquants pouvaient exploiter des vulnérabilités matérielles pour accéder à des données sensibles.

Spectre, Meltdown et SRSO : Quelles différences ?

  • Spectre et Meltdown : Ces failles exploitaient des vulnérabilités dans la manière dont les processeurs effectuent certaines optimisations, permettant aux attaquants de lire la mémoire d’autres programmes.
  • SRSO : Cette nouvelle attaque est une attaque par canal latéral spéculatif qui peut entraîner une exécution spéculative à une adresse contrôlée par un attaquant. Bien que similaire dans la nature, les détails techniques et les méthodes d’exploitation diffèrent.

Comment se protéger ?

AMD est déjà sur le coup et a sorti des mises à jour pour contrer cette faille. Mon conseil ? Mettez à jour vos systèmes dès que possible. Et comme toujours, gardez vos logiciels à jour et restez vigilants.

Sources

AMD Advisory : AMD-SB-7005
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html
Lenovo HX
https://support.lenovo.com/us/en/product_security/LEN-134879#ThinkAgile
Dell XC – https://www.dell.com/support/kbdoc/en-us/000216612/dsa-2023-228-security-update-for-dell-amd-based-poweredge-server-vulnerabilities
HPE DX – https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=hpesbhf04495en_us

Enfin de retour à la maison après cette semaine passée à Chicago pour participer au .Next Nutanix.

Je retiendrai deux annonces majeures. Tout d’abord, Nutanix Central : une solution basée sur le cloud qui fournit une console unique pour la visibilité, la surveillance et la gestion des infrastructures publiques, sur site, hébergées ou en périphérie. À mesure que les organisations gèrent de plus en plus d’environnements diversifiés et distribués, Nutanix Central étend le modèle d’exploitation cloud universel de la plateforme Nutanix Cloud, brisant les silos et simplifiant la gestion des applications et des données n’importe où, tout en offrant une sécurité intégrée et une portabilité des licences. A voir jusqu’où cette nouvelle console centralisera les fonctionnalités et éliminera les inconvénients liés à l’utilisation de plusieurs Prism Central.

Ensuite, il y a le Projet Beacon : une gamme de services de plateforme centrés sur les données de niveau Platform-as-a-Service (PaaS), disponibles nativement partout, que ce soit sur Nutanix ou sur le cloud public natif. L’objectif du Projet Beacon est de dissocier l’application et ses données de l’infrastructure sous-jacente, permettant aux développeurs de créer des applications une fois et de les exécuter n’importe où.

Ces annonces sont soutenues par plusieurs améliorations sous-jacentes, telles que la technologie Nutanix Multicloud Snapshot. Cette technologie permettra la mobilité des données entre différents clouds en permettant de sauvegarder directement les instantanés dans les objets S3 des hyperscalers natifs du cloud, en commençant par AWS S3. Cela facilitera la protection, la récupération et la mobilité des données hybrides multicloud. De plus, Nutanix Objects s’intègre désormais à Snowflake, offrant aux organisations la possibilité d’utiliser Snowflake Data Cloud pour analyser directement les données stockées dans Nutanix Objects. Cela garantit que les données restent locales et accélère le temps de valorisation. Il convient de noter que cette fonctionnalité est actuellement en cours de développement, il est donc difficile de savoir quand elle deviendra une réalité concrète.

En outre, il y a Nutanix pour Kubernetes (NDK) qui fournit aux clients un contrôle évolutif sur les applications et les données natives du cloud. Initialement livré avec Nutanix Cloud Infrastructure (NCI), NDK apportera toute la puissance du stockage de niveau entreprise, des instantanés et de la reprise après sinistre (DR) de Nutanix à Kubernetes. Cela accélérera le développement d’applications conteneurisées pour les charges de travail persistantes en introduisant la provision de stockage, les instantanés et les opérations de DR dans les pods Kubernetes et les espaces de noms d’applications.

Bien sûr, je n’ai pas encore eu l’occasion de mettre la main sur un Nutanix Central, donc en attendant de vous faire part de mon propre retour, voici un lien intéressant sur le site de Nutanix à ce sujet : Lien vers Nutanix Central.

Voici également un autre lien intéressant pour en savoir plus sur NDK : Lien vers NDK.

Puis Nutanix Multicloud Snapshot Technology (MTS) la solution de snapshot multicloud -> Lien vers MTS

Et enfin, pour les membres de la communauté des Nutanix Technology Champions, dont je fais partie, un petit mot spécial. Nous avons été mis à l’honneur avec un superbe slide reprenant tous les membres. C’est une véritable reconnaissance pour notre communauté, qui est gérée de main de maître par Angelo Luciani.

Pour ce qui est de la suite, le prochain événement se déroulera à Barcelone en 2024. Il est donc temps de marquer cette date dans nos calendriers et de nous préparer à découvrir les prochaines avancées passionnantes de Nutanix.

En conclusion, le .Next Nutanix a été une expérience riche en annonces et en nouveautés. Nutanix Central et le Projet Beacon ouvrent de nouvelles perspectives dans la gestion des infrastructures et des données, tandis que Nutanix pour Kubernetes (NDK) offre un contrôle évolutif pour les applications conteneurisées. Les améliorations telles que Nutanix Multicloud Snapshot et l’intégration de Nutanix Objects avec Snowflake ajoutent encore plus de valeur à la plateforme Nutanix.

Je suis impatient de voir ces innovations se concrétiser et d’explorer les possibilités qu’elles offriront aux entreprises.