Lorsqu’un hôte VMware ESXi montre des signes d’intrusion, la priorité est d’empêcher la propagation tout en maintenant les services en ligne. Éteindre brutalement l’hyperviseur peut bloquer l’activité, provoquer des pertes de données ou interrompre des machines virtuelles critiques.
Heureusement, il existe des méthodes permettant d’isoler un serveur compromis sans stopper l’ensemble du fonctionnement. L’objectif : limiter les risques, contenir l’attaque et préserver l’accès aux machines virtuelles saines.
Identifier rapidement un hôte compromis
Avant tout, il faut détecter les signes montrant que l’hyperviseur est affecté :
- sessions Shell ouvertes sans autorisation
- pics d’activité inhabituels sur les datastores
- tâches planifiées non prévues
- fichiers système modifiés
- comportements suspects dans /var/log
Une fois la compromission confirmée, l’étape suivante est l’isolement contrôlé.
Méthode n°1 : isoler l’hôte via sa carte de gestion (pas les VM)
L’objectif est de désactiver uniquement la connectivité de l’hyperviseur tout en laissant les machines virtuelles continuer à émettre et recevoir du trafic.
Étapes recommandées
- Accéder au switch physique où est branchée la carte de gestion ESXi (Management Network).
- Désactiver uniquement le port physique utilisé pour vmk0 (Management Network).
- Vérifier que les ports uplink associés aux groupes de ports des VM restent actifs.
Résultat :
- Plus aucun accès SSH, API ou vCenter sur l’hôte compromis.
- Les machines virtuelles, elles, continuent de communiquer normalement.
Cette approche coupe le lien administratif sans impacter la production.
Méthode n°2 : passer l’hôte en “quarantine mode” dans un cluster vSphere
Si l’infrastructure utilise vSphere HA ou DRS, une option peu connue permet de bloquer l’hôte sans arrêter les VM.
Fonctionnement
Le quarantine mode limite le placement de nouvelles VM sur l’hôte et réduit les interactions avec le cluster, tout en gardant les VM actives.
Utilité en cas d’incident
- réduit la surface d’interaction de l’hôte
- empêche le déplacement de nouvelles VM
- laisse tourner uniquement le minimum nécessaire
C’est un confinement doux, adapté en cas de suspicion d’activité malveillante.
Méthode n°3 : déconnecter l’hôte du vCenter (sans l’éteindre)
Supprimer temporairement la connexion entre vCenter et l’hyperviseur empêche tout attaquant ayant compromis les API de prendre le contrôle du cluster.
Étapes
- Ouvrir vCenter
- Sélectionner l’hôte > Disconnect
- Confirmer la désactivation
Conséquences :
- plus aucune tâche distante ne peut être déclenchée sur l’hôte
- les machines virtuelles restent en activité
- l’hyperviseur fonctionne en mode autonome jusqu’à réintégration
Utile lorsque l’attaque semble exploitée via vCenter.
Méthode n°4 : isoler le trafic de gestion via un VLAN temporaire
Si l’équipe réseau peut intervenir rapidement, l’une des méthodes les plus propres consiste à basculer le Management Network dans un VLAN isolé.
Avantages
- l’hôte devient invisible depuis les autres VLAN
- seules les VM continuent à communiquer sur leurs segments normaux
- possibilité de contrôler les flux au niveau firewall
Idéal lorsque l’infrastructure est déjà segmentée.
Méthode n°5 : neutraliser temporairement les services sensibles de l’hyperviseur
VMware ESXi autorise la désactivation ciblée de services critiques susceptibles d’être exploités :
- SSH
- ESXi Shell
- vpxa (agent vCenter)
- hostd (gestion locale)
- DCUI (interface console)
En désactivant ces services :
- l’attaquant perd les points d’accès privilégiés
- les machines virtuelles restent stables
- l’hôte continue à faire tourner les workloads actifs
À manipuler avec prudence, mais très efficace en phase d’urgence.
Méthode n°6 : conserver les VM en ligne tout en fermant l’uplink problématique
Si l’intrusion semble transiter par un uplink réseau spécifique (dans un vSwitch), il est possible de couper uniquement ce lien sans affecter les VM utilisant d’autres uplinks.
Exemple :
- Uplink1 = trafic de gestion
- Uplink2 = trafic VM
- Uplink3 = trafic de stockage
- Uplink4 = vMotion
Couper uniquement Uplink1 isole la surface sensible tout en préservant le reste.
Points de vigilance lors de l’isolement
Pour éviter des effets de bord :
- vérifier que les datastores utilisés par les VM ne dépendent pas du même uplink que la gestion
- s’assurer que les VM critiques disposent d’un second uplink
- ne pas couper les ports reliés aux SAN/NAS
- éviter de déconnecter l’hôte si réintégration vCenter risque de poser problème (ex : version mismatch)
Un isolement mal réalisé peut entraîner la perte d’accès au stockage, ce qui causerait l’arrêt des VM malgré l’objectif initial.
Après l’isolement : procédures de stabilisation
Une fois l’hôte séparé du réseau sensible :
- Sauvegarder les logs (/var/log/*)
- Exporter la configuration de l’hyperviseur pour analyse
- Scanner les fichiers du datastore pour identifier
- scripts suspects
- snapshots anormaux
- fichiers .sh, .py, .so non officiels
- Vérifier les tâches planifiées dans crontab
- Comparer l’intégrité des fichiers système (/etc) avec un hôte sain
L’objectif est de comprendre l’origine de l’infiltration avant une remise en service.
A LIRE AUSSI ISO 27001 : vérifier que vos procédures informatiques sont conformes
Quand faut-il éteindre l’hôte malgré tout ?
L’arrêt complet est nécessaire uniquement lorsque :
- les datastores chiffrés commencent à être altérés
- l’hyperviseur exécute un binaire inconnu au niveau système
- les VM montrent des signes directs de compromission
- les accès stockage sont affectés
- l’attaquant a acquis un accès root persistant non contrôlable
Si ces signes apparaissent, l’isolation ne suffit plus.