vCenter Server 9.0 (Broadcom/VMware vSphere)

Rationale

Cette règle autorise les administrateurs vSphere (postes conformes, groupes SSO vCenter restreints) et les outils d'automatisation (PowerCLI, Terraform vSphere, Ansible VMware) à atteindre la VCSA en HTTPS sur le port 443 (vSphere Client HTML5 et API REST/SDK). La VCSA étant un serveur interne contrôlé, ssl_inbound_inspection déchiffre le trafic entrant pour détecter les exploits visant vCenter Server (T1190 — nombreuses CVE critiques historiques : CVE-2021-21985, CVE-2021-22005, CVE-2023-34048, etc.) et les uploads malveillants. L'identité est restreinte par groupe SSO vCenter (moindre privilège). Risque critique (risk 5) : compromettre la VCSA permet de pivoter vers l'ensemble des hôtes ESXi via vpxd↔vpxa (T1210). Cette règle couvre aussi la redirection depuis le port HTTP 80 (voir règle 3).

Profils de sécurité

Rationale

La VAMI (vCenter Appliance Management Interface, port 5480) est le seul moyen de gérer les paramètres système de la VCSA : sauvegarde, configuration réseau, NTP, certificats TLS, mises à jour OS de l'appliance et activation/désactivation du SSH. Elle est structurellement obligatoire (sans elle, la VCSA ne peut pas être administrée hors du vSphere Client) et distincte de l'interface de gestion vSphere 443. L'accès est restreint aux administrateurs système uniquement (groupe d'annuaire plus étroit que la règle 1). ssl_inbound_inspection couvre les exploits (T1190, T1078). Risque critique (risk 5) : l'accès à la VAMI permet la reconfiguration complète de la VCSA, y compris l'activation du SSH et la modification des certificats SSO.

Profils de sécurité

Rationale

La VCSA redirige automatiquement le port 80 vers HTTPS 443 (vSphere Client). Aucune donnée applicative ne transite en clair : la session est immédiatement redirigée. L'IPS en mode block (high) détecte les tentatives d'exploitation visant la couche HTTP de redirection. Le déchiffrement est non applicable : le flux HTTP n'est pas chiffré et la redirection intervient avant tout échange de données.

Profils de sécurité

Rationale

La VCSA pilote les hôtes ESXi via le canal bidirectionnel vpxd↔vpxa. Le port TCP 902 (port de gestion ESXi) véhicule le transfert de données, la configuration et la console de machine virtuelle (MKS — Mouse/Keyboard/Screen via vSphere Client). Le port TCP 443 est utilisé par vpxd pour les API de gestion des agents vpxa côté ESXi. Le heartbeat de disponibilité UDP 902 est couvert par la règle 4b. Le déchiffrement est désactivé (exclusion cert_pinned_app) : les hôtes ESXi présentent des certificats d'équipement vSphere et un proxy MITM briserait le canal d'authentification mutuelle vpxd↔vpxa. L'IPS détecte les exploits visant les services de gestion ESXi (T1210). Risque critique (risk 5) : ce canal est le vecteur principal de pivot depuis la VCSA vers les hôtes ESXi.

Profils de sécurité

Rationale

Le heartbeat de disponibilité UDP 902 entre la VCSA (vpxd) et les hôtes ESXi (vpxa) permet la détection rapide des hôtes indisponibles dans vSphere. Ce flux est fondamental pour la gestion de la haute disponibilité vSphere HA et la surveillance de l'état des hôtes ESXi dans vCenter. L'IPS en mode default détecte les anomalies de protocole sur ce flux UDP sans bloquer les sondes vpxd légitimes.

Profils de sécurité

Rationale

La résolution DNS est structurellement obligatoire pour la VCSA : l'installation échoue si les enregistrements A/PTR de son FQDN ne sont pas résolus. En exploitation, DNS est requis pour joindre les hôtes ESXi gérés, les contrôleurs Active Directory (intégration SSO vCenter), et le service dl.broadcom.com (mises à jour vLCM). Le flux est restreint vers un résolveur interne contrôlé (pas de résolution directe vers Internet). Le profil dns_security avec sinkhole atténue le tunneling DNS depuis la VCSA si elle était compromise. TCP/53 (réponses DNSSEC ou >512 octets) est traité avec la même règle si le pare-feu supporte multi-protocole ; sinon, dupliquer pour tcp/53.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si la synchronisation NTP directe est configurée sur la VCSA (via la VAMI ou vcsa-util). La VCSA peut synchroniser son horloge via l'hyperviseur hôte ESXi (mode VMware Tools), mais la synchronisation NTP directe est fortement recommandée en production. NTP est critique pour la validité des certificats TLS vSphere, l'authentification SSO/Kerberos vCenter, la cohérence des journaux d'événements et le fonctionnement de vSphere HA (élection master). L'IPS en mode default détecte les anomalies de protocole NTP (amplification, mode hors norme).

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si le service SSH de la VCSA a été explicitement activé via la VAMI pour une opération de maintenance. Le SSH est désactivé par défaut sur la VCSA dans vSphere 9.0 (bonne pratique de sécurité Broadcom) et doit être re-désactivé après intervention. Cette règle doit être activée avec une politique de durée limitée (fenêtre de maintenance). Le déchiffrement ssh_proxy permet d'inspecter les commandes exécutées via le tunnel SSH (détection d'exfiltration ou de commandes suspectes sur le shell root VCSA). L'accès est restreint aux hôtes de gestion conformes et au groupe d'administration le plus étroit (T1133). log_start est activé pour tracer toute ouverture de session SSH.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si Auto Deploy vCenter est en place pour le déploiement automatisé d'hôtes ESXi sans état (stateless ESXi). Auto Deploy distribue les images ESXi, les profils de configuration et les règles d'assignation vSphere aux hôtes en cours de provisioning : les hôtes se connectent à la VCSA sur les ports TCP 6501 (service Auto Deploy HTTP) et 6502 (service Auto Deploy HTTPS) pour recevoir leur image système. L'antivirus et l'IPS inspectent les flux entrants. Le déchiffrement est désactivé (cert_pinned_app) car les hôtes ESXi en boot réseau utilisent des certificats vSphere que le proxy ne peut pas impersonner. Si le provisioning utilise UEFI HTTPS Boot (boot moderne ESXi 7+), il passe par TCP 443 (règle 1) et cette règle peut rester désactivée.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si Auto Deploy vCenter utilise le boot PXE legacy (BIOS ou iPXE classique). Le TFTP (UDP 69) permet le téléchargement du fichier de boot iPXE lors du démarrage PXE d'un hôte ESXi en provisioning. Cette règle est inutile si le boot réseau UEFI HTTPS (nouveau défaut ESXi 7+) est configuré, ce dernier passant entièrement par HTTPS (règle 1 ou règle 8). TFTP est un protocole non chiffré : limiter son usage au réseau de gestion segmenté et envisager la migration vers le boot UEFI HTTPS pour éliminer ce flux.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si vSphere Lifecycle Manager (vLCM) est activé pour piloter les mises à jour et vérifier la conformité des hôtes ESXi gérés. vLCM expose un dépôt HTTPS de patches et d'images ESXi depuis la VCSA vers les hôtes. Si ce flux est bloqué, les vérifications de conformité vLCM et les remédiations échouent silencieusement. Port HTTPS 9087 : flux principal depuis vSphere 7/vLCM (remplace le port HTTP hérité 9084). ssl_inbound_inspection permet l'inspection antivirus et sandboxing du contenu distribué (vecteur supply chain si la VCSA est compromise).

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si vLCM utilise encore le port HTTP hérité (9084) pour des hôtes ESXi en mode de compatibilité, ou le port d'accès au magasin de configuration des hôtes (8083). En vSphere 7+/vLCM courant, le flux principal passe par HTTPS 9087 (règle 10) ; ces ports sont des résidus d'héritage. Note : 9084 étant HTTP non chiffré, envisager la migration vers 9087/HTTPS pour éliminer ce flux et fermer cette règle.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si vSphere Replication est déployé (VR Appliance). Ce flux SOAP (TCP 8043) permet à la VCSA de piloter l'appliance vSphere Replication : configuration des politiques de réplication, monitoring, orchestration des basculements. Il est distinct du trafic de réplication de données inter-ESXi (NBD/NFC), qui relève d'une fiche dédiée aux hôtes ESXi. ssl_inbound_inspection inspecte les flux HTTPS SOAP entrants vers la VCSA.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si l'agent SNMP de la VCSA est activé et qu'un système de supervision réseau (NMS) effectue du polling. SNMP v3 avec authentification et chiffrement est fortement recommandé pour une infrastructure vSphere (les MIB vCenter exposent des informations sensibles sur l'infrastructure). L'accès doit être restreint à l'adresse IP du NMS. L'IPS en mode default surveille les anomalies de protocole SNMP (tentatives de walk non autorisées).

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si l'envoi de traps SNMP est configuré sur la VCSA vers un récepteur de traps (NMS). La VCSA émet des traps SNMP UDP vers le NMS pour signaler des événements d'infrastructure vSphere. Préférer SNMP v3 avec authentification. L'IPS en mode default surveille les anomalies.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si la collecte syslog non chiffrée est configurée sur la VCSA ET que la version courante est vCenter Server 9.x (supporté). AVERTISSEMENT DE VERSION : le syslog non chiffré sur UDP/TCP 514 est supporté dans vCenter Server 9.x mais est bloqué et non supporté à partir de vCenter Server 9.1. Si une montée de version vers 9.1+ est prévue, migrer vers syslog TLS (règle 16, port 1514) AVANT la mise à niveau de la VCSA. Syslog non chiffré expose les journaux vCenter à l'interception et à la falsification sur le réseau de gestion — préférer la règle 16 en toutes circonstances. L'IPS surveille les anomalies sur le flux.

Profils de sécurité

Rationale

CONDITIONNEL — À activer si la collecte de logs syslog chiffrée TLS est configurée sur la VCSA. Recommandé en vCenter Server 9.x, et obligatoire à partir de vCenter Server 9.1 (le syslog non chiffré sur 514 étant bloqué dès cette version). Voie de migration recommandée depuis la règle 15. Le déchiffrement est désactivé (cert_pinned_app) car le collecteur syslog TLS utilise un certificat d'équipement vSphere pour l'authentification mutuelle.

Profils de sécurité

Rationale

La VCSA et vLCM téléchargent les mises à jour vCenter Server et les patches/images ESXi depuis dl.broadcom.com, dépôt authentifié Broadcom (token par compte support, KB 431697). C'est le seul flux sortant vers Internet et un vecteur critique de chaîne d'approvisionnement (T1195.002) : ssl_forward_proxy est obligatoire pour permettre à l'antivirus et au sandboxing d'inspecter les paquets téléchargés. url_filtering bloque les catégories à risque et les sites non catégorisés. ALLOW-LIST DE DÉPLOIEMENT : autoriser uniquement dl.broadcom.com (dépôt actif depuis avril 2025). NE PAS autoriser les anciens domaines VMware retirés (depot.vmware.com, hostupdate.vmware.com, vapp-updates.vmware.com — HTTP 403 depuis le 23 avril 2025, KB 390098). Note de déploiement : dl.broadcom.com utilise un token d'authentification par compte support ; configurer l'exclusion d'inspection SSL sur ce domaine spécifique au niveau du proxy déployé (KB 431697), pas une exclusion générale de déchiffrement dans cette règle. Risque élevé (risk 4) : vecteur supply chain à large rayon d'impact sur la VCSA et l'ensemble des hôtes ESXi gérés.

Profils de sécurité

Rationale

Durcissement : les tentatives de communication en clair (HTTP) vers les interfaces de gestion des hôtes ESXi sont bloquées silencieusement. Les hôtes ESXi modernes (vSphere 7+) n'exposent leurs interfaces de gestion qu'en HTTPS (port 443, règle 4 — canal vpxd↔vpxa) ; un flux HTTP interne vers un hôte ESXi est soit un résidu de configuration hérité, soit une tentative de contournement du chiffrement (T1557 — interception en vol, vol d'identifiants vCenter/ESXi). Le log en haute priorité signale toute tentative pour investigation. Note : cette règle cible les flux internes VCSA <-> hôtes ESXi ; la redirection HTTP 80 vers HTTPS pour les clients administrateurs (vSphere Client) est couverte par la règle 3 (sens entrant).