Déployer Sophos NDR sur VMware ESXi ou Hyper-V

Sophos NDR s’exécute sur ESXi ou Hyper-V sous la forme d’une Integration Appliance virtuelle. La machine virtuelle nécessite deux chemins clairement séparés : MGMT obtient une adresse IP normale et communique avec Sophos Fusion (anciennement Sophos Central) ou Sophos Data Lake ; SPAN1 et, éventuellement, SPAN2 reçoivent uniquement des copies en miroir du trafic à inspecter. Par conséquent, une machine virtuelle opérationnelle ou l’état Connected dans Central ne confirme pas encore que NDR voit les paquets.

Procédure rapide : vérifiez les prérequis et la capacité, créez la configuration NDR dans Sophos Fusion, préparez la mise en miroir adaptée à la plateforme, déployez l’image générée une seule fois, attendez la fin du premier démarrage et du redémarrage automatique, puis validez séparément les chemins de gestion et SPAN.

Limite importante : le chemin SPAN n’est pas en ligne et ne doit pas servir de réseau de gestion. La mise en miroir est configurée sur le commutateur et l’hyperviseur ; l’appliance NDR ne modifie pas le trafic de production d’origine. Pour Hyper-V, aucune commande PowerShell externe de mise en miroir n’est délibérément fournie ici. Mettez en œuvre la conception dans Hyper-V conformément aux recommandations approuvées de Microsoft et de Sophos, puis vérifiez-la avec un trafic de test réel.

Vérifier impérativement les prérequis

Les exigences minimales suivantes s’appliquent d’abord aux deux plateformes :

un droit de licence Sophos Network Detection and Response integration license pack actif dans le tenant utilisé ;
4 processeurs virtuels, 16 GB de RAM et 160 GB de stockage ;
les indicateurs de processeur pdpe1gb pour Packet Capture et avx2 pour les fonctions de machine learning ;
un réseau de gestion dédié avec DHCP ou une adresse statique, DNS, une passerelle par défaut et un accès Internet sortant ;
des chemins SPAN préparés pour recevoir des copies bidirectionnelles de toutes les classes de trafic approuvées : trafic virtuel interne et trafic physique externe, si les deux font partie du périmètre de surveillance convenu ;
une attribution documentée des responsabilités pour Central, l’hyperviseur, les commutateurs physiques et la liste d’autorisation du pare-feu.

Si le périmètre approuvé ne comprend effectivement qu’une seule de ces classes de trafic, documentez explicitement cette limite. Un seul chemin SPAN ne doit alors pas être considéré comme couvrant l’autre classe.

N’installez aucun Sophos Agent supplémentaire ni aucun autre agent antimalware sur l’appliance. Sophos gère les mises à jour du système d’exploitation, de la sécurité et de l’appliance. Les exigences internes de mise à jour corrective ou de durcissement ne doivent pas modifier cet état géré sans validation préalable.

Limites des plateformes

VMware ESXi nécessite :

ESXi 6.7 Update 3 ou une version ultérieure ;
VM hardware version 11 ou une version ultérieure ;
un mode EVC Skylake ou ultérieur si Enhanced vMotion Compatibility est utilisé ;
aucun déploiement dans VMware Cloud, car celui-ci n’est pas pris en charge.

Les indicateurs de processeur doivent rester visibles dans la machine virtuelle avec le mode EVC sélectionné. Un processeur physique récent ne suffit pas si EVC masque les fonctionnalités requises.

Microsoft Hyper-V nécessite :

Hyper-V 6.0.6001.18016, correspondant à Windows Server 2016, ou une version ultérieure ;
la désactivation de Processor Compatibility Mode ;
au maximum 8 cœurs de processeur et 32 GB de RAM par machine virtuelle NDR ;
au maximum un nœud NUMA et un socket de processeur.

Les limites d’Hyper-V ne constituent pas une recommandation visant à toujours attribuer le maximum de ressources à la machine virtuelle. Elles évitent une topologie NUMA non prise en charge.

Dimensionner la machine virtuelle selon le trafic

La taille standard avec 4 processeurs virtuels est prévue pour une appliance exclusivement dédiée à NDR, jusqu’aux valeurs indicatives suivantes :

500 Mbit/s ;
70'000 paquets par seconde ;
1'200 flux par seconde.

Pour une charge élevée atteignant 1 Gbit/s, 300'000 paquets par seconde ou 4'500 flux par seconde, utilisez 8 processeurs virtuels. SPAN2 nécessite également au moins 8 processeurs virtuels. Si la charge dépasse ces valeurs, répartissez-la entre plusieurs appliances NDR placées à des points appropriés du réseau ; n’augmentez pas les ressources d’une machine virtuelle unique au-delà des limites documentées.

Si d’autres intégrations de collecteurs de journaux s’exécutent sur la même appliance, planifiez leur charge séparément. NDR réserve avec une priorité élevée deux processeurs lorsque 4 processeurs virtuels sont utilisés, et trois lorsque 8 processeurs virtuels sont utilisés. D’autres intégrations peuvent néanmoins solliciter ces processeurs. Avec 16 GB de RAM, les intégrations de collecteurs de journaux ne peuvent en utiliser que 2 GB au total. Quel que soit le nombre d’intégrations, une appliance accepte au maximum 8'000 événements de journal par seconde. Une seule intégration NDR est possible par appliance.

Autoriser les connexions sortantes

Si le pare-feu prend en charge les caractères génériques, l’appliance doit pouvoir accéder aux destinations suivantes :

Destination	Port et protocole
`*.sophos.com`	TCP 443 et TCP 22
`*.amazonaws.com`	TCP 443
`*.ntp.org`	UDP 123
`sophossecops.jfrog.io`	TCP 443
`yum.oracle.com`	TCP 443, facultatif

yum.oracle.com est facultatif, car l’appliance utilise le miroir Sophos JFrog si cette destination est inaccessible. N’étendez pas aveuglément les caractères génériques à d’autres zones. Si le pare-feu n’autorise pas les caractères génériques, ajoutez à la liste d’autorisation, avant le changement, la liste complète et actuelle des noms d’hôte Sophos propres à la région, puis vérifiez-la depuis la zone MGMT au moyen de tests DNS et de connectivité. Une liste abrégée ou copiée depuis une autre région ne constitue pas une solution de remplacement sûre.

Créer l’intégration et l’image dans Sophos Fusion

Dans Sophos Fusion, ouvrez Threat Analysis Center > Integrations > Marketplace.
Sélectionnez Sophos Network Detection and Response (NDR).
Sous Data Ingest (Security Alerts), cliquez sur Add Configuration.
Dans Step 1, saisissez un nom unique et une description pour l’intégration.
Dans Step 2, sélectionnez une appliance existante ou cliquez sur Create new appliance. Une appliance existante ne doit pas déjà comporter une autre intégration NDR.
Pour une nouvelle appliance, choisissez un Appliance name unique, une description et la plateforme appropriée, VMware ESXi ou Microsoft Hyper-V.
Sous Internet-facing network port settings, configurez DHCP ou Manual. Une adresse attribuée par DHCP doit être réservée.
Dans Step 3, saisissez un Exclusion list name. Ce nom est obligatoire même si la liste est vide au départ.
Cliquez sur Save pour terminer.

Pour Manual, renseignez les champs IP address, Subnet mask, Gateway address, DNS 1 et, éventuellement, DNS 2. Voici un exemple interne :

IP address: 10.0.252.5
Subnet mask: 255.255.255.0
Gateway address: 10.0.252.1
DNS 1: 10.0.252.53
DNS 2: 10.0.252.54

Remplacez ces valeurs par des adresses disponibles et des serveurs DNS accessibles depuis votre propre réseau de gestion. Vérifiez au préalable l’adresse statique par rapport au pool DHCP, à l’IPAM et aux hôtes existants.

Sous Domain exclusions, vous pouvez saisir un nom de domaine. Protocol exclusions comporte un champ pour le protocole principal, par exemple TCP ou UDP, et un champ pour le sous-protocole, par exemple facebook ; lorsque les deux sont renseignés, Central les joint par un seul point. N’excluez pas un protocole principal entier dans le seul but de réduire le volume de données. Chaque exclusion nécessite un faux positif confirmé ou une décision de capacité justifiée, un responsable et une date de révision.

Après l’enregistrement, sélectionnez le téléchargement propre à la plateforme dans la colonne Actions : Download OVA file pour ESXi ou le paquet ZIP pour Hyper-V. L’état affiché à gauche de l’intégration devient Waiting for deployment. L’image contient la configuration propre à l’appliance et ne doit pas être réutilisée pour d’autres tenants ou appliances.

Déployer sur VMware ESXi

1. Préparer les groupes de ports SPAN

Pour le trafic virtuel interne, créez un groupe de ports dédié sur le vSwitch standard concerné :

Ouvrez Networking > Virtual switches et sélectionnez le vSwitch prévu.
Sous Port groups, cliquez sur Add port group.
Attribuez-lui un nom unique.
Définissez VLAN ID sur 4095.
Sous Security, définissez Promiscuous mode sur Accept.
Enregistrez le groupe de ports.

Pour le trafic mis en miroir depuis un commutateur physique, utilisez un vSwitch distinct avec son propre groupe de ports SPAN, selon le même modèle. Sous vSwitch topology, utilisez Add uplink pour attribuer une carte réseau physique disponible. Reliez directement le port de destination dédié à la mise en miroir sur le commutateur physique à cette carte réseau de l’hôte ESXi.

Sur le commutateur physique, sélectionnez uniquement les ports ou VLAN approuvés comme sources de mise en miroir et choisissez les deux directions. Le port de destination transporte les copies vers la carte réseau ESXi et ne doit pas servir simultanément de port d’accès, de trunk ou de gestion normal. La syntaxe exacte du commutateur dépend du fabricant et ne doit pas être copiée depuis un exemple destiné à un autre modèle.

Si SPAN physique et vMotion sont utilisés ensemble, la machine virtuelle NDR doit rester sur l’hôte ESXi dont la carte réseau physique reçoit le trafic mis en miroir. Une migration involontaire vers un autre hôte peut supprimer silencieusement le chemin SPAN alors que MGMT continue de fonctionner.

2. Importer l’OVA et affecter les interfaces

L’OVA téléchargé est lié à cette configuration Central et ne peut être utilisé qu’une seule fois. Pour un remplacement ou un nouveau déploiement, générez un nouvel OVA dans Central.

Sur l’hôte ESXi, ouvrez Virtual Machines > Create/Register VM.
Sélectionnez Deploy a virtual machine from an OVF or OVA file.
Saisissez un nom de machine virtuelle et sélectionnez ndr-sensor.ova.
Sélectionnez Standard comme type de stockage, puis choisissez le datastore prévu.
Sous Deployment options, affectez soigneusement les réseaux :
- SPAN1 : premier groupe de ports SPAN préparé ;
- SPAN2 : deuxième groupe de ports SPAN, s’il est réellement nécessaire ;
- SYSLOG : pour une appliance exclusivement dédiée à NDR, sélectionnez un groupe de ports temporaire, puis déconnectez l’adaptateur après l’importation ;
- MGMT : groupe de ports de gestion avec DHCP ou les paramètres réseau statiques saisis dans Central.
Définissez Disk Provisioning sur Thin.
Activez Power on automatically.
Ignorez Additional settings sans apporter de modification, puis cliquez sur Finish pour lancer l’importation.

Avant de mettre la machine virtuelle sous tension pour la première fois, documentez de nouveau l’affectation, l’état de la liaison et les adresses MAC de toutes les cartes réseau virtuelles. MGMT ne doit pas se trouver sur un groupe de ports SPAN. Si SPAN2 est utilisé, la machine virtuelle doit disposer d’au moins 8 processeurs virtuels.

Déployer sur Microsoft Hyper-V

1. Préparer la conception de la mise en miroir

Avant d’exécuter le script, déterminez la fonction de chaque vSwitch :

un vSwitch normal pour MGMT, avec DHCP ou le chemin réseau statique prévu ;
un chemin de destination pour SPAN1 ;
éventuellement, un deuxième chemin de destination pour SPAN2, avec au moins 8 processeurs virtuels ;
aucun chemin SYSLOG actif, sauf si la même appliance traite aussi des intégrations tierces approuvées.

Pour Hyper-V, la configuration de la mise en miroir se compose conceptuellement de quatre éléments : un port de mise en miroir du trafic, une SPAN Virtual Interface connectée au vSwitch, l’extension Microsoft NDIS Capture Extension activée et les modes de mise en miroir Source et Destination correctement définis. La mise en œuvre dépend de la version de Windows/Hyper-V, du type de vSwitch et de la source du trafic à mettre en miroir. Par conséquent, ne reprenez pas de commandes PowerShell non vérifiées provenant d’autres environnements.

Avant de démarrer NDR, l’équipe responsable de la plateforme vérifie le chemin prévu au moyen d’un test rapide de déploiement fondé sur un flux de test bidirectionnel connu. La copie doit parvenir au chemin de destination prévu sans modifier le flux de production d’origine. Ce n’est qu’ensuite que ce vSwitch est sélectionné comme destination SPAN dans le script Sophos. Ce test unique ne confirme pas la couverture complète de la mise en miroir.

2. Extraire le ZIP et exécuter le script Sophos

Extrayez le ZIP téléchargé depuis Central dans un dossier local protégé de l’hôte Hyper-V. Il contient des disques virtuels, seed.iso et ndr-sensor.ps1.
Dans ce dossier, lancez ndr-sensor.ps1 avec Run with PowerShell.
Lorsque Security Warning s’affiche, vérifiez le fichier local téléchargé directement depuis Central et autorisez son exécution avec Open.
Saisissez un nom de machine virtuelle unique.
Vérifiez le nouveau répertoire de machine virtuelle affiché dans le chemin par défaut des disques virtuels, puis saisissez C pour le créer.
Indiquez 4 processeurs pour la taille standard, ou 8 pour une charge élevée ou SPAN2.
Indiquez 16 GB de RAM comme valeur standard ; ne dépassez pas la limite Hyper-V de 32 GB.
Dans la liste numérotée des vSwitches, sélectionnez d’abord le vSwitch MGMT.
Pour SYSLOG sur une appliance exclusivement dédiée à NDR, sélectionnez un vSwitch temporaire, puis déconnectez cet adaptateur après la création.
Sélectionnez le vSwitch préparé pour SPAN1 et, si prévu, celui de SPAN2.
Attendez que le message Installation Completed Successfully s’affiche, puis appuyez sur une touche quelconque pour quitter le script.
Ouvrez la nouvelle machine virtuelle dans Hyper-V Manager et, avant de la démarrer, vérifiez le processeur, la RAM, les cartes réseau, les vSwitches connectés et l’adaptateur SYSLOG déconnecté.

Les disques virtuels générés par Sophos et seed.iso forment un ensemble. Ne remplacez pas des fichiers individuels par des fichiers de même nom provenant d’un téléchargement antérieur.

Premier démarrage et test rapide de déploiement

Lors du premier démarrage, l’appliance vérifie les réseaux affectés et l’accès Internet, puis redémarre automatiquement. Ce processus peut prendre jusqu’à dix minutes.

N’interrompez pas le premier démarrage ni le redémarrage automatique. La mise hors tension manuelle de la machine virtuelle pendant cette période peut la laisser dans un état incomplet et ne constitue pas une étape de dépannage.

Effectuez le test technique rapide de déploiement dans l’ordre suivant :

Console de la machine virtuelle : le démarrage se termine sans boucle persistante d’erreurs ou de redémarrages.
Chemin de gestion : l’adresse MGMT configurée ou réservée, DNS, NTP et les destinations sortantes requises sont accessibles.
Chemin de contrôle Central : sous Threat Analysis Center > Integrations > Configured > Integration Appliances, ou sur la page de l’intégration NDR, l’appliance passe de Waiting for deployment à Connected.
Chemin SPAN : pour chaque chemin SPAN déployé, générez dans les deux directions un flux de test inoffensif, annoncé au préalable, entre deux systèmes de test connus. Sur le commutateur ou l’hyperviseur, Source, Direction et Destination doivent correspondre au changement ; sur l’appliance, l’adaptateur SPAN affecté doit recevoir du trafic.
Plausibilité : comparez la plage horaire, les adresses source et de destination, ainsi que la direction du flux de test observé. Le chemin déployé concerné n’est confirmé pour ce test rapide que si ces valeurs correspondent.
Charge : lors d’une première période de charge appropriée, comparez le débit, les paquets et les flux au niveau de dimensionnement sélectionné. L’état Connected ne constitue pas une preuve de capacité.

Une détection artificielle unique n’est pas nécessaire pour le test rapide de déploiement. L’essentiel est de disposer d’un chemin de gestion stable et de confirmer la présence d’un trafic bidirectionnel sur l’interface SPAN appropriée. Le flux de test capturé dans Packet Capture ne contient ni logiciel malveillant ni données client réelles.

Ce test rapide ne confirme que les chemins spécifiquement testés. La recette complète de toutes les sources, de tous les VLAN, de toutes les directions et de toutes les classes de trafic prévus relève du runbook distinct Planifier et valider la mise en miroir du trafic pour Sophos NDR ; ni Connected ni un seul flux réussi ne sont considérés ici comme une preuve de couverture complète de la mise en miroir.

Résoudre les problèmes selon les symptômes

L’état reste sur Waiting for deployment

Vérifiez que l’image appropriée, nouvellement téléchargée depuis cette configuration, a été déployée.
Vérifiez la console et l’état d’alimentation de la machine virtuelle, puis laissez le premier démarrage se dérouler sans interruption pendant au moins dix minutes.
Comparez la carte réseau virtuelle MGMT, le groupe de ports ou le vSwitch, ainsi que la réservation DHCP ou les champs statiques.
Vérifiez DNS, la passerelle, NTP, TCP 443, TCP 22 et UDP 123 depuis le réseau de gestion, conformément à la liste d’autorisation.
Ne redéployez qu’après ces vérifications. Sur ESXi, un OVA nouvellement généré est nécessaire ; ne réimportez pas l’OVA déjà utilisé.

Connected, mais aucun trafic NDR

Sur ESXi, vérifiez d’abord l’affectation de SPAN1/SPAN2, VLAN ID 4095, Promiscuous mode: Accept, l’uplink physique et le port de destination de la mise en miroir. Si vous utilisez vMotion, vérifiez que la machine virtuelle s’exécute toujours sur l’hôte auquel la carte réseau SPAN est connectée.

Sur Hyper-V, l’équipe responsable de la plateforme vérifie la SPAN Virtual Interface, l’extension NDIS Capture Extension, le mode Source/Destination et le vSwitch sélectionné dans le script Sophos. N’ajoutez pas de règles de pare-feu ni de commandes de mise en miroir inventées sur la base de simples suppositions.

Sur les deux plateformes, ne réduisez pas immédiatement le filtre de test : vérifiez d’abord les compteurs de l’adaptateur et un flux bidirectionnel clairement identifiable. Le trafic MGMT sur l’adaptateur MGMT ne prouve pas le bon fonctionnement de SPAN.

Une seule direction ou un seul réseau est visible

La source de mise en miroir doit inclure l’émission et la réception.
Avec un routage asymétrique, le chemin de retour peut emprunter un autre uplink.
Le trafic virtuel interne et le trafic physique externe peuvent nécessiter des chemins SPAN distincts.
Si SPAN2 est configuré, le deuxième vSwitch ou groupe de ports doit être correctement affecté et au moins 8 processeurs virtuels doivent être disponibles.

Répétez exactement le même flux de test après chaque correction. Vous pourrez ainsi déterminer clairement quelle modification a produit un effet.

Dragonfly reste sur Pending

Si Central affiche déjà Connected, mais que NDR ne fonctionne pas, vérifiez l’état du service Dragonfly dans la Sophos VA Console. Avant cette étape, l’accès à la console locale doit avoir été mis en place conformément au runbook distinct Exploiter Sophos NDR Integration Appliance et le capteur. Ne réutilisez pas à cette fin les identifiants de l’hyperviseur ou de Central sans les valider ; ce runbook de déploiement ne crée ni ne divulgue d’identifiants locaux de l’appliance.

En cas d’état Pending dans un cluster EVC ESXi, vérifiez d’abord le mode EVC et les fonctionnalités de processeur visibles. Sandy Bridge n’est pas pris en charge pour cet usage ; Skylake ou une version ultérieure, ainsi que pdpe1gb et avx2, sont requis.

Sur Hyper-V, vérifiez également Processor Compatibility Mode, les limites de processeur et de RAM, ainsi que la topologie, qui ne doit pas comporter plus d’un nœud NUMA et d’un socket de processeur. Ne tentez pas de « réparer » la machine virtuelle en ajoutant des processeurs ou de la RAM au-delà des limites prises en charge.

Des paquets ou des résultats manquent sous charge

Comparez le débit, les paquets et les flux actuels aux limites de dimensionnement. Si une destination SPAN est plus lente que l’ensemble de ses sources, des paquets peuvent être perdus dans la copie alors que le trafic de production se poursuit sans interruption. Dans ce cas, réduisez la sélection des sources, répartissez les chemins SPAN ou utilisez plusieurs appliances. Des exclusions étendues de protocoles ne remplacent pas un dimensionnement approprié.

Retour arrière local limité de ce déploiement

Les étapes suivantes constituent une recommandation prudente de retour arrière local pour le déploiement passif décrit ici. Elles ne forment pas une procédure complète de mise hors service ou de retrait documentée par Sophos. Le retour arrière est délibérément limité aux objets de capteur et de mise en miroir nouvellement créés dans le cadre du changement :

Enregistrez les éléments probants des tests et les derniers états connus : état Central, ressources de la machine virtuelle, affectation des interfaces, sources et directions de mise en miroir.
Désactivez d’abord la session SPAN ou de mise en miroir sur le commutateur ou l’hyperviseur. Ne supprimez ni ne recâblez les ports source, les VLAN ou les vSwitches de production lors de cette opération.
Vérifiez que le trafic d’origine continue de fonctionner et qu’aucune copie n’arrive plus sur le chemin de destination NDR.
Arrêtez ensuite proprement la machine virtuelle NDR.
Ne supprimez les groupes de ports, les vSwitches, les uplinks ou les fichiers de machine virtuelle dédiés qu’après avoir confirmé qu’ils sont utilisés exclusivement par cette appliance. Les objets de gestion ou de production partagés restent en place.
Annulez la réservation DHCP statique, la liste d’autorisation du pare-feu et les enregistrements DNS sous forme de changements distincts, après avoir vérifié leurs références.

L’intégration ou l’appliance dans Central n’est pas supprimée dans le cadre de ce retour arrière local. Une telle suppression sort du cadre de ce retour arrière de déploiement et nécessite un processus de retrait distinct, validé et approuvé. De même, un OVA existant n’est pas considéré comme une image de retour arrière : générez une nouvelle image dans Central pour un nouveau déploiement ESXi.

Après l’échec d’un premier démarrage, le retour arrière local limité consiste donc à arrêter la mise en miroir, mettre la machine virtuelle hors tension, annuler uniquement les objets réseau clairement associés à ce changement et déterminer la cause avant un nouveau déploiement. Ne transformez pas spontanément un test NDR passif en une autre conception réseau ou en un chemin en ligne.