Planifier et valider la mise en miroir du trafic pour Sophos NDR

La mise en miroir du trafic fournit à Sophos NDR une copie du trafic réseau. Pour les réseaux locaux ou virtualisés, elle s’effectue généralement avec SPAN ; les sources distantes sont encapsulées avec ERSPAN sur GRE ou VXLAN ; dans AWS, elle passe par VPC > Traffic mirror sessions. L’objectif n’est pas de mettre en miroir autant de ports que possible sans discernement. NDR doit recevoir les bons flux de communication, sans boucle, doublon inutile ni chemin de destination surchargé.

La procédure sûre est la suivante :

définir les flux de communication et les limites à surveiller ;
sélectionner exactement un point d’observation approprié pour chaque flux ;
vérifier la capacité entre la source et le capteur NDR ;
commencer par mettre en miroir une petite source pilote ;
valider par étapes toute la chaîne, de la source au traitement ;
n’étendre les sources que de manière contrôlée et effectuer de nouvelles mesures après chaque modification.

Avant l’activation, la source, la direction, le filtre, la destination, la fenêtre de maintenance, le périmètre de données autorisé et la responsabilité du retour arrière doivent être approuvés et documentés. Les données mises en miroir peuvent contenir des charges utiles et d’autres informations sensibles. Il ne faut donc pas mettre largement en miroir, par précaution ou « au cas où », des segments utilisateurs, d’administration, d’identité ou d’autres segments sensibles qui ne sont pas prévus. La source pilote doit se limiter au périmètre opérationnel approuvé et conforme aux exigences de protection des données.

Sélectionner les sources et les points d’observation

Il est utile d’établir une brève matrice de couverture avant la configuration. Plutôt que de simplement répertorier tous les ports de commutateur, elle recense les flux de communication pertinents, par exemple :

des clients vers Internet et les services externes ;
des clients vers les serveurs internes ;
entre les serveurs, en particulier au-delà des limites de segments ou de zones de sécurité ;
du centre de données vers les sites distants ou les réseaux cloud ;
le trafic est-ouest entre des machines virtuelles qui ne traverse aucune liaison montante physique.

Pour chaque flux, sélectionnez un point où les deux sens sont visibles. Il s’agit généralement d’un trunk, d’un VLAN ou d’un port proche d’une limite de segment. Une liaison montante vers Internet offre une bonne visibilité sur le trafic nord-sud, mais pas sur le trafic local au sein d’un même VLAN. À l’inverse, un commutateur physique ne voit pas le trafic qui reste au sein d’un même vSwitch. Un état vert du capteur ne permet pas de déduire ces lacunes : elles doivent être déterminées à partir de la topologie et de la matrice de test.

Source et direction

Selon la plateforme, une source SPAN peut être un port, un groupe de ports ou un VLAN. Dans la mesure du possible, mettez en miroir both, c’est-à-dire le trafic entrant et sortant. La mise en miroir d’un seul sens peut masquer les réponses, les erreurs et certaines parties d’une session.

Un trunk ou un VLAN entier simplifie la couverture, mais augmente le volume de données et le risque de doublons. Les ports d’accès individuels offrent un ciblage plus précis, mais risquent davantage d’être oubliés lors du déplacement des systèmes ou lorsque les charges de travail sont dynamiques. Le choix doit donc reposer sur le flux de communication, et non sur le nombre de sources disponibles.

Destination

La destination de la mise en miroir doit exclusivement correspondre au chemin de capture du capteur NDR :

pour une machine virtuelle, le groupe de ports ou le vSwitch auquel SPAN1 ou SPAN2 est connecté ;
pour une connexion physique, le port dédié du commutateur connecté à l’interface SPAN ;
pour ERSPAN, l’adresse de destination GRE ou VXLAN configurée sur le capteur ;
dans AWS, la cible NDR SPAN Target créée par la pile CloudFormation.

L’interface d’administration ne doit pas servir de destination SPAN dans cette chaîne. Le port de destination ne doit pas non plus être utilisé comme source ordinaire ni renvoyer du trafic de production vers le réseau.

Éviter les boucles et les paquets en double

La mise en miroir des ports copie les paquets ; elle ne doit pas les réinjecter dans le chemin d’acheminement de production. Une boucle peut, par exemple, se produire si la destination SPAN est à son tour mise en miroir ou utilisée comme liaison montante ordinaire. Les doublons sont plus fréquents : le même paquet peut être capturé sur le port d’accès et la liaison montante, des deux côtés d’une limite de segment, ou simultanément par SPAN local et ERSPAN.

Avant l’activation, vérifiez donc les points suivants :

L’interface de destination sert uniquement de destination et n’est jamais une source de la même session ou d’une session qui la recouvre.
Dans la mesure du possible, un chemin de communication de bout en bout est mis en miroir à une seule limite pertinente.
Deux ports SPAN ne reçoivent pas de sources qui se recouvrent, sauf si ce recouvrement est documenté et prévu pour un test de durée limitée.
Le trafic de diffusion et de multidiffusion n’est pas collecté à plusieurs endroits d’un même domaine de couche 2.
Dans un cluster ou avec vMotion, l’hôte et la liaison montante qui reçoivent le trafic mis en miroir physiquement sont clairement identifiés. Une machine virtuelle NDR utilisant le SPAN standard d’un commutateur physique doit rester sur l’hôte ESXi qui reçoit ce trafic.
Dans AWS, seule la session nécessaire existe pour chaque ENI et chaque périmètre de trafic prévu. Vérifiez également l’ordre des sessions et les filtres.

Les doublons consomment de la capacité de capture, de tunnel et de processeur sans améliorer la couverture opérationnelle. Un quasi-doublement du débit de paquets ou d’octets après l’ajout d’une source, alors que le trafic de production n’a pas changé, est suspect. Dans ce cas, désactivez la dernière source ajoutée et recherchez les recouvrements dans la topologie.

Configurer SPAN localement ou dans l’hyperviseur

La syntaxe exacte varie selon le commutateur et l’hyperviseur. Quelle que soit la plateforme, le principe reste le même : sélectionner la source et la direction, définir une destination dédiée et s’assurer que le groupe de ports virtuel de capture autorise la réception en mode promiscuité.

Pour une session Sophos Switch, une petite configuration pilote peut, par exemple, mettre en miroir les ports 1 à 4 dans les deux sens vers le port 8 :

configure terminal
monitor session 1 destination interface gigabitethernet 0/8 allow-ingress
monitor session 1 source interface gigabitethernet 0/1 both
monitor session 1 source interface gigabitethernet 0/2 both
monitor session 1 source interface gigabitethernet 0/3 both
monitor session 1 source interface gigabitethernet 0/4 both
save
end
show monitor session 1

Les numéros d’interface sont donnés à titre d’exemple et doivent correspondre à votre câblage. Avant d’enregistrer, vérifiez que 0/8 mène uniquement au chemin de capture NDR. Pour les autres fournisseurs, utilisez leurs commandes SPAN documentées ; des noms similaires n’impliquent pas nécessairement une sémantique identique.

Pour un vSwitch standard ESXi, définissez le groupe de ports de capture sur VLAN ID 4095 et réglez Promiscuous mode sur Accept sous Security. Le trafic mis en miroir physiquement nécessite également une liaison montante dédiée entre le commutateur et le vSwitch approprié. Le trafic interne aux machines virtuelles peut nécessiter une source virtuelle de mise en miroir distincte. Avec Hyper-V, l’interface de capture NDR doit être connectée au bon vSwitch en tant que destination de la mise en miroir des ports ; vérifiez la configuration de la plateforme séparément du paramètre du capteur NDR.

Sophos NDR active SPAN Port 1 par défaut ; SPAN Port 2 est désactivé par défaut. Un deuxième port SPAN n’est utile que s’il reçoit une source distincte sans recouvrement inutile. La machine virtuelle doit disposer d’au moins 8 vCPU pour utiliser SPAN Port 2.

Utiliser ERSPAN avec GRE ou VXLAN

ERSPAN transporte les copies des sources distantes vers le capteur sur un réseau IP. Le chemin de transport fait ainsi partie de l’analyse de la capacité et des pannes : la MTU, le routage, les listes de contrôle d’accès (ACL) et une éventuelle fragmentation peuvent affecter la capture même si la session source est correctement configurée.

Dans Sophos Appliance Manager, configurez l’interface de capture appropriée sous Settings :

VXLAN

Activez Enable ERSPAN en regard du port SPAN prévu.
Sous Tunnel Protocol, sélectionnez vxlan.
Sous IP Address, saisissez l’adresse de l’interface VTEP.
Définissez VXLAN ID et VXLAN Port exactement comme sur la source d’encapsulation.
Sélectionnez Save.

GRE

Activez Enable ERSPAN en regard du port SPAN prévu.
Sous Tunnel Protocol, sélectionnez gre.
Sous IP Address, saisissez l’adresse de l’interface de destination GRE.
Saisissez le GRE Port correspondant à la configuration de la source.
Sélectionnez Save.

Les modifications apportées aux paramètres SPAN ne prennent effet qu’après le redémarrage de la machine virtuelle. Avant de la redémarrer, vérifiez si la même appliance traite d’autres intégrations, car leur collecte de données sera également interrompue. Validez ensuite de nouveau les paramètres du tunnel et le traitement.

L’utilisation conjointe de SPAN et VXLAN sur la même appliance est une architecture courante. N’utilisez simultanément VXLAN et GRE sur la même appliance que si les sources, la capacité et les domaines de panne sont clairement séparés et documentés.

Comprendre la mise en miroir du trafic dans AWS

Dans AWS, le modèle d’architecture reste le même : la Mirror Source est l’ENI de la charge de travail approuvée, et non l’ENI d’administration du capteur NDR ; la Mirror Target et le filtre doivent appartenir à l’architecture NDR déployée. Limitez le filtre au périmètre de données prévu. Le déploiement AWS proprement dit et la création de la Traffic Mirror Session sont décrits dans « Déployer Sophos NDR sur AWS » et ne sont pas repris ici.

Pour la recette, utilisez ensuite la chaîne de preuves décrite ci-dessous. La simple existence d’une session AWS ne prouve ni l’acheminement des paquets jusqu’à la destination, ni leur traitement, leur envoi ou leur détection.

Limiter la capacité avant la recette

SPAN Port 2 n’augmente pas la capacité : la machine virtuelle doit disposer d’au moins 8 vCPU pour l’activer, mais cette deuxième entrée ajoute du trafic et donc une charge de traitement. Utilisez-la uniquement pour une source distincte qui ne recouvre pas les autres. Si le débit ou la perte de paquets augmente après son activation, vérifiez si SPAN2 a introduit une charge supplémentaire ou des doublons.

« Surveiller l’état et la capacité de Sophos NDR » explique comment évaluer les indicateurs d’état, de trafic unicast et de perte, ainsi que la capacité. Pour les étapes de dépannage fondées sur les symptômes, consultez « Diagnostiquer l’Integration Appliance et le capteur NDR ». Selon la plateforme, les mesures d’augmentation de capacité peuvent inclure l’ajout de ressources processeur à la machine virtuelle ou une répartition sans recouvrement sur une autre appliance ; les autres intégrations gourmandes en ressources processeur doivent être planifiées séparément. Le simple ajout de SPAN2 n’augmente pas la capacité de traitement.

Validation : de la source à la détection

Effectuez la validation avec un hôte pilote connu et une fenêtre temporelle définie. Il est ainsi possible d’attribuer une erreur à une étape précise, plutôt que de modifier simultanément le commutateur, le tunnel, le capteur et Sophos Fusion.

1. Configuration et topologie

Comparez la source, la direction et la destination avec la matrice de couverture.
Vérifiez l’état fourni par le fabricant pour la session SPAN ou AWS.
Assurez-vous que la destination ne figure pas parmi les sources.
Pour ERSPAN, vérifiez l’adresse de destination, les paramètres GRE ou VXLAN et le chemin réseau.
Pour les plateformes virtuelles, vérifiez l’affectation de la carte réseau de capture, du groupe de ports ou du vSwitch.

2. Paquets à la destination

À l’aide d’un trafic de test unicast contrôlé provenant de l’hôte pilote, vérifiez que les paquets atteignent la destination de capture prévue. Consignez comme preuves la fenêtre temporelle, l’interface de destination, les adresses source et de destination attendues et, le cas échéant, les deux sens de circulation. Cette étape prouve que les paquets testés sont arrivés à la destination prévue, mais pas encore qu’ils ont été traités ou chargés. Le trafic de diffusion ne constitue pas à lui seul un test fiable. Si des paquets manquent, limitez d’abord l’analyse à la source, au filtre, à la direction, au transport et au groupe de ports virtuel.

3. Capture et flux sur le port SPAN prévu

Sous Sophos Appliance Manager > NDR, consignez, pour le port SPAN précisément prévu, le pourcentage de capture affiché et l’activité du graphique Total Flow pendant la fenêtre de 30 secondes. Les deux doivent coïncider dans le temps avec le trafic pilote. Cela prouve une activité sur l’entrée sélectionnée ; ces indications ne prouvent ni la capture de tous les paquets, ni l’adéquation du périmètre de données, ni la présence des deux sens de circulation, ni la réussite de l’envoi.

Selon la classification actuelle de Sophos, un port SPAN est considéré comme sain lorsqu’au moins 2 % des paquets réseau sont unicast. Cette valeur est uniquement le seuil minimal du classificateur d’état : elle permet seulement d’exclure une proportion nulle de trafic unicast dans l’échantillon observé. Un flux incorrect, partiel, dupliqué, obsolète ou inadapté à l’objectif peut lui aussi atteindre le seuil de 2 %. Cette valeur ne prouve donc ni la source et la direction attendues, ni la présence d’un trafic utile, ni la couverture, ni le pourcentage de capture affiché, ni l’envoi, ni la détection. Les anciennes références à 100 % de trafic unicast ne constituent pas l’exigence actuelle.

4. Traitement et envoi

Sous Sophos Appliance Manager > NDR, consignez le pourcentage d’envoi affiché pour la même fenêtre temporelle et comparez sa chronologie avec l’activité de capture et de flux. Cela atteste d’une activité d’envoi, mais ne prouve pas que tous les paquets mis en miroir ont été transmis ni qu’une détection sera ensuite créée. Connected confirme principalement la connexion de l’appliance et ne remplace pas ces preuves. Si les indicateurs d’état, de capture, d’envoi et de perte divergent, suivez le diagnostic systématique de l’appliance et du capteur.

5. Couverture opérationnelle

Pour chaque ligne de la matrice de couverture, générez un trafic de test ciblé et autorisé, puis consignez l’heure, l’appareil de test, le segment attendu, la source, la destination et la direction. Associez à ce test les preuves des étapes 2 à 4. Seuls ces échantillons montrent que les chemins testés sont, en principe, capturés ; ils ne prouvent rien pour les segments ou les fenêtres temporelles qui n’ont pas été testés.

6. Détection de bout en bout sans danger

Ce n’est qu’après la réussite de la recette de la mise en miroir que vous devez exécuter la procédure distincte et approuvée « Générer et vérifier une détection de test Sophos NDR sûre ». La génération du test n’est pas décrite ici. Vérifiez le résultat pour l’appareil de test et la fenêtre temporelle attendus sous Threat Analysis Center > Detections, puis reliez-le à la chaîne de preuves précédente. Une détection de test qui y est observée prouve le fonctionnement du chemin de bout en bout testé ; elle ne garantit ni la détection de toutes les techniques d’attaque ni la couverture des autres chemins.

Circonscrire les écarts étape par étape

En cas d’échec de la recette, examinez uniquement la première étape pour laquelle les preuves attendues sont absentes : le chemin réel de la source, la direction et le filtre ; puis le câblage de destination ou l’affectation de la capture virtuelle ; pour ERSPAN, le transport et la concordance des paramètres du tunnel ; ensuite la capture et le flux sur le port prévu ; enfin l’envoi et la détection. Un état vert ou une proportion d’au moins 2 % de trafic unicast ne permet de sauter aucune de ces étapes. N’apportez qu’une seule modification à la fois et effectuez de nouvelles mesures avec le même pilote et la même fenêtre temporelle.

Si seule une direction ou seul un segment manque, comparez la matrice de couverture avec le chemin physique ou virtuel réel, sans ajouter préventivement d’autres segments sensibles ou tous les ports. Si le débit est anormalement élevé, confrontez un par un les recouvrements documentés aux compteurs et à la visibilité du trafic pilote. Cette procédure s’achève avec la recette de la mise en miroir et la localisation de la panne ; en cas d’erreur du capteur, de l’envoi ou de la plateforme, poursuivez avec le diagnostic de l’appliance et du capteur.

Annuler en toute sécurité les modifications apportées par cette procédure

Avant chaque extension, consignez l’identifiant de session, les sources, les directions, les filtres, la destination, les paramètres du tunnel et les débits de référence. Le retour arrière ci-dessous concerne uniquement les nouvelles modifications de mise en miroir apportées dans le cadre de cette procédure ; il ne s’agit pas d’instructions pour supprimer une appliance, une pile cloud ou une autre infrastructure.

En cas de problème, annulez les modifications dans l’ordre inverse :

supprimez la dernière source locale ajoutée ; supprimez toute AWS Traffic Mirror Session nouvellement créée pour cette procédure ;
rétablissez le périmètre pilote documenté pour le dernier filtre étendu ;
désactivez l’ERSPAN nouvellement activé ou rétablissez les paramètres précédents du tunnel ;
désactivez SPAN Port 2 s’il a introduit la nouvelle charge ou le recouvrement ;
rétablissez la session précédente du commutateur si une mise en miroir physique a été modifiée ;
vérifiez de nouveau le flux de paquets, le taux de perte, l’état de l’intégration et le trafic pilote.

Le retour arrière des paramètres SPAN de Sophos nécessite de nouveau de sélectionner Save et de redémarrer la machine virtuelle avant que la modification prenne effet. Tenez également compte des conséquences sur les autres intégrations de la même appliance. Le retour arrière n’est terminé que lorsque l’état est non seulement de nouveau vert, mais que les chemins pilotes précédemment documentés sont aussi visibles sans nouveaux doublons ni pertes de paquets problématiques.