Surveiller l’état et la capacité de Sophos NDR

Un état Sophos NDR vert constitue une vérification intermédiaire importante, mais ne prouve ni que la couverture de la mise en miroir est complète, ni que la chaîne de détection fonctionne. Pour obtenir une évaluation fiable, il faut examiner séparément six groupes de signaux : Sophos Fusion, Appliance Manager, l’entrée SPAN, le téléversement, les ressources de calcul et de stockage et, le cas échéant, l’Investigation Console, qui est un composant autonome.

Vérification rapide : commencez par consulter l’état NDR dans Sophos Fusion. Dans Appliance Manager, sous NDR, vérifiez ensuite les valeurs de chaque port SPAN attendu, la valeur Uploaded et l’historique des flux. Sous Status, vérifiez le CPU, la mémoire, le disque racine et le disque de données. L’avertissement jaune spanX: packets being dropped signifie que plus de 10 % des paquets réseau traités par NDR sont rejetés. Un port SPAN vert satisfait actuellement au critère de classification du produit, à savoir au moins 2 % de paquets de monodiffusion. Aucune de ces informations ne prouve à elle seule que tous les réseaux prévus sont mis en miroir ou qu’une détection parvient au bout de la chaîne.

Associer chaque indicateur à son rôle

Dans Sophos Fusion, ouvrez Appliance Manager en accédant à Threat Analysis Center > Integrations > Configured > Integration Appliances. Sur la ligne de l’appliance, sélectionnez les trois points, puis Open Appliance Manager. L’en-tête affiche notamment Version, K3S Helm Chart version, Uptime et System ID. Consignez ces informations dans chaque rapport d’incident, car deux appliances présentant des symptômes apparemment similaires peuvent utiliser des versions logicielles différentes ou avoir des durées de fonctionnement différentes.

Utiliser l’état Fusion comme point de départ

Sophos Fusion distingue trois états :

• Rouge : l’intégration NDR ne fonctionne pas. NDR containers not ready, <specific container names> indique que certaines applications ne sont pas prêtes. Upload to s3 failed ... concerne le téléversement vers le cloud. spanX: unhealthy span concerne l’entrée du trafic provenant de l’équipement réseau qui assure la mise en miroir.
• Jaune : l’intégration fonctionne, mais présente des erreurs. spanX: packets being dropped s’affiche lorsque plus de 10 % des paquets réseau sont rejetés.
• Vert : l’intégration reçoit du trafic SPAN et traite les données des paquets sans erreur signalée. Un port SPAN est actuellement considéré comme sain si au moins 2 % des paquets observés sont des paquets de monodiffusion.

Ces deux pourcentages n’ont pas le même dénominateur et ne doivent pas être mis en balance. Le seuil de 2 % sert à classifier la composition du trafic qui arrive au capteur. Il ne signifie ni que 2 % de l’ensemble du trafic de l’entreprise suffit, ni que NDR peut en perdre 98 %. « Au moins 2 % » inclut exactement 2 %. En revanche, le message relatif aux rejets décrit la proportion des paquets déjà reçus par NDR que le traitement ne peut pas prendre en charge faute de ressources. Sophos documente cet avertissement pour une valeur supérieure à 10 %, et non pour une valeur « supérieure ou égale à 10 % ».

Important : le seuil de plus de 10 % correspond à un état du produit, et non à un objectif ou à un budget de perte acceptable. Même une valeur inférieure au seuil de signalement peut indiquer une dégradation par rapport à votre propre référence. De même, un port vert peut fournir un trafic mal ou incomplètement mis en miroir tant que le mélange observé satisfait au critère de classification de la monodiffusion.

Vérifier séparément l’entrée SPAN et le téléversement

Dans Appliance Manager, l’onglet NDR indique une valeur de capture pour chaque port SPAN configuré. SPAN Port 2 ne s’affiche que si un deuxième port a été configuré. Le graphique global Network Flows utilise des intervalles de 30 secondes.

Ces indicateurs répondent à trois questions distinctes :

1. Le trafic arrive-t-il sur chaque port SPAN attendu ? Une valeur absente ou qui change soudainement de manière importante doit conduire à vérifier en premier lieu le commutateur source, la session de mise en miroir ou SPAN, l’affectation de l’interface réseau virtuelle ainsi que les VLAN ou groupes de ports récemment modifiés.
2. Le mélange de trafic est-il plausible ? L’état vert confirme uniquement le critère actuel de classification de la monodiffusion. L’historique des flux doit également correspondre aux heures habituelles, aux sites concernés et aux pics de trafic attendus.
3. NDR peut-il traiter les paquets ? Le message jaune relatif aux rejets signale un goulot d’étranglement du traitement. Il ne correspond ni à un port miroir surchargé, ni à une perte de paquets sur le chemin de production.

Le pourcentage de téléversement, également visible dans l’onglet NDR, correspond à une étape en aval. Une entrée SPAN saine associée à une baisse du téléversement n’indique pas la même catégorie de panne qu’un port SPAN qui ne reçoit aucun trafic. Si le message Upload to s3 failed. Request was received but an error code was returned s’affiche, vérifiez l’accès Internet sortant de l’appliance ainsi que les règles du pare-feu et du proxy web. NDR téléverse les données vers un compartiment S3 au moyen d’une URL présignée. Si l’erreur persiste après la correction de la configuration réseau ou du proxy, contactez le support Sophos.

Pour les intégrations de collecteurs de journaux tiers, les cartes sous Integrations comptabilisent les valeurs Received, Filtered, Accepted et Uploaded. Ces compteurs syslog ne correspondent ni à la valeur de téléversement NDR, ni à la valeur de capture SPAN. Ils restent néanmoins importants, car une intégration de collecte de journaux très sollicitée et exécutée sur la même appliance consomme les ressources CPU et mémoire de cette appliance.

Évaluer le CPU, la mémoire et le stockage

Sous Status, Appliance Manager indique l’utilisation du CPU, de la mémoire, du disque racine et du disque de données. Avec NDR, il est normal que certains cœurs du CPU soient constamment utilisés à pleine capacité : le Data Plane Development Kit (DPDK) fonctionne en mode d’interrogation sur des cœurs réservés. Il recherche continuellement des paquets au lieu d’attendre des interruptions lorsqu’il est inactif.

Sophos fournit deux exemples précis :

• Sur une machine virtuelle dotée de 4 cœurs de CPU, un cœur reste utilisé à 100 %.
• Sur une machine virtuelle dotée de 8 cœurs de CPU, deux cœurs restent utilisés à 100 %.

Une telle utilisation par cœur ne constitue donc pas, à elle seule, la preuve d’une surcharge et ne disparaît pas nécessairement lorsque le trafic est faible. À l’inverse, le fait que « DPDK soit normal » ne doit pas servir à expliquer toute utilisation élevée du CPU. La situation devient critique lorsque plusieurs facteurs se combinent : hausse du trafic, saturation d’autres cœurs, message packets being dropped, baisse du téléversement ou historique des flux qui s’écarte de la référence.

Les recommandations de capacité suivantes s’appliquent aux appliances virtuelles :

Ces trois mesures doivent être prises en compte ensemble. Un environnement peut rester sous la limite de bande passante tout en générant un grand nombre de paquets par seconde si ceux-ci sont très petits. Si les valeurs dépassent le profil High, Sophos recommande de déployer plusieurs appliances virtuelles sur le réseau.

Ces valeurs s’appliquent à une machine virtuelle qui exécute uniquement NDR. En cas de charge élevée, chaque intégration supplémentaire de collecte de journaux hébergée sur l’appliance nécessite environ 400 Mo de RAM et peut consommer des ressources CPU supplémentaires. Vérifiez donc également les cartes sous Integrations avant d’augmenter les ressources. En cas de charge mixte durable, il peut être plus judicieux de répartir les services entre plusieurs appliances que d’ajouter continuellement des ressources à la même machine virtuelle.

La documentation produit utilisée pour cet article ne fixe aucun seuil d’avertissement général pour la mémoire, le disque racine ou le disque de données. Il serait donc trompeur de présenter un pourcentage arbitraire comme une limite Sophos. Les facteurs déterminants sont l’évolution, la marge disponible et les symptômes simultanés. Si l’utilisation du disque augmente continuellement, ne supprimez pas manuellement de fichiers ou de conteneurs. Commencez par consigner l’état et la période concernée et, si la cause reste incertaine, conservez les journaux destinés au support Sophos.

Établir une référence exploitable

Un instantané ne permet pas de distinguer les variations quotidiennes normales du début d’une surcharge. Après la mise en service et après chaque modification importante, consignez donc des points de mesure comparables :

• la date, l’heure et le fuseau horaire, ainsi que la phase de charge attendue ;
• la couleur affichée dans Fusion et le texte exact du message ;
• la valeur de capture de chaque port SPAN configuré ;
• le pourcentage de téléversement et la forme de l’historique des flux ;
• le CPU par cœur et dans son ensemble, la mémoire, le disque racine et le disque de données ;
• le nombre de vCPU et la quantité de RAM attribués à la machine virtuelle ;
• les valeurs estimées ou mesurées sur le système source en Mbit/s, paquets/s et flux/s ;
• les intégrations tierces exécutées simultanément et leur activité ;
• les modifications apportées au commutateur, à l’hyperviseur, au proxy, au pare-feu ou à l’appliance.

Il est utile d’effectuer les mesures pendant une période calme, sous une charge de travail normale et lors d’un pic connu. L’objectif n’est pas de définir une valeur cible universelle, mais de comparer la même appliance dans des conditions similaires. Une baisse soudaine sur un port SPAN devient ainsi visible même si Fusion affiche encore un état vert. Après une modification de la capacité, n’établissez une nouvelle référence qu’une fois l’état stabilisé.

Résoudre les problèmes dans un ordre sûr

1. Consigner l’étendue du problème : notez l’appliance et le port SPAN concernés, l’heure de début, le texte exact affiché dans Fusion et la dernière modification. Conservez des captures d’écran ou des mesures avant tout redémarrage.
2. Vérifier l’entrée : en cas de message unhealthy span, d’absence de flux ou d’écart par rapport à la référence du port, vérifiez d’abord la source de mise en miroir, le port de destination ou l’interface réseau virtuelle, ainsi que les réseaux attendus. Ajouter des ressources CPU ne corrigera pas une source SPAN mal configurée.
3. Vérifier le téléversement : en cas d’erreur de téléversement S3, contrôlez l’accès Internet sortant, le pare-feu et le proxy web. À l’inverse, un téléversement réussi ne corrige pas une couverture de mise en miroir incomplète.
4. Vérifier la capacité : lorsque les rejets dépassent 10 %, comparez le profil de trafic, les autres cœurs utilisés à pleine capacité, l’allocation de vCPU et les intégrations exécutées sur la même appliance. Pour une machine virtuelle, attribuez des vCPU supplémentaires ; le profil High documenté prévoit 8 vCPU. Pour du matériel certifié, vous pouvez déployer une appliance supplémentaire et répartir le trafic SPAN. Avant toute répartition du trafic, un plan de couverture approuvé est obligatoire : il doit affecter clairement chaque réseau, VLAN et source de mise en miroir prévus à l’appliance cible, afin d’éviter les lacunes et les doublons involontaires. En cas de charges de travail mixtes, NDR et les collecteurs de journaux peuvent être répartis sur des appliances distinctes.
5. Délimiter la portée d’un redémarrage : si NDR ne fonctionne toujours pas correctement après la résolution de la cause, vous pouvez envisager un redémarrage ciblé de NDR conformément aux instructions d’exploitation ou de dépannage applicables. Le traitement NDR normal est interrompu pendant le redémarrage ; celui-ci ne remplace pas une correction de la capacité. Le redémarrage ou l’arrêt de l’ensemble de la machine virtuelle a une portée plus large et ne doit pas constituer la première étape du dépannage.

Si vous modifiez les vCPU ou la répartition du trafic, faites-le pendant une fenêtre de maintenance approuvée et conformément aux exigences de la plateforme de virtualisation utilisée. N’effectuez qu’une modification à la fois afin que son effet reste mesurable. Après avoir réparti le trafic, vérifiez le plan de couverture pour chaque port SPAN résultant et validez également le parcours de test de bout en bout approuvé.

Ne pas confondre l’Investigation Console avec l’appliance NDR

L’Investigation Console est un composant distinct. Son état ne démontre ni celui de l’intégration NDR, ni l’exhaustivité des sources SPAN, ni la bonne transmission des données. Cet article se limite donc à préciser cette séparation : le trafic SPAN, le téléversement NDR, DPDK et les rejets de paquets se vérifient au niveau de l’intégration NDR et dans Appliance Manager ; la vérification et le dépannage de l’Investigation Console relèvent de la documentation d’exploitation propre à cette console.

Valider après chaque action

Répétez les vérifications sous une charge comparable à celle de la mesure initiale. Une correction n’est considérée comme efficace que lorsque :

• Fusion affiche l’état attendu sans le précédent message rouge ou jaune ;
• chaque port SPAN attendu est visible et correspond de nouveau à son propre historique de référence ;
• le critère de classification de la monodiffusion n’a pas été utilisé à tort comme preuve de couverture ;
• le message signalant plus de 10 % de paquets rejetés ne réapparaît pas ;
• le téléversement et les Network Flows restent stables pendant une période d’observation significative ;
• les ressources CPU hors des cœurs DPDK attendus, la mémoire, le disque racine et le disque de données présentent une marge suffisante ;
• les intégrations tierces exécutées sur la même appliance continuent de traiter les données attendues ;
• après une répartition du trafic, chaque réseau, VLAN et source de mise en miroir prévus alimente exactement l’appliance désignée conformément au plan de couverture approuvé, et le parcours de test de bout en bout approuvé fonctionne.

Ces contrôles valident l’état opérationnel, mais pas encore l’intégralité de la chaîne de détection. La preuve de bout en bout nécessite en outre un test NDR approuvé et la vérification de la détection qui en résulte.

Quand faire appel au support Sophos

Faites appel au support Sophos si les conteneurs ne deviennent pas prêts, si une erreur de téléversement S3 persiste malgré la validation du chemin Internet et du proxy, si un port SPAN reste unhealthy malgré la correction de la configuration de la source, si les rejets de paquets réapparaissent après une augmentation appropriée de la capacité, ou si les indicateurs de ressources et les messages d’état se contredisent.

Préparez au minimum les informations suivantes pour l’escalade :

• le nom de l’appliance, son System ID, sa Version, sa K3S Helm Chart version et son Uptime ;
• le texte exact de l’état et de l’erreur, avec l’heure de début et le fuseau horaire ;
• le port SPAN concerné, les valeurs de capture et de téléversement, ainsi que l’historique des flux ;
• le CPU par cœur, la mémoire, le disque racine et le disque de données avant et après l’intervention ;
• l’allocation de la machine virtuelle, le profil de trafic observé et les intégrations exécutées sur la même appliance ;
• les modifications récentes apportées au commutateur, à l’hyperviseur, au pare-feu ou au proxy ;
• les actions effectuées et leurs résultats mesurables ;
• pour les problèmes concernant une Investigation Console distincte, les éléments exigés par sa documentation d’exploitation.

Les mots de passe, les clés privées et les autres identifiants ne doivent pas figurer dans le ticket. N’exécutez pas de commandes Kubernetes de bas niveau et ne modifiez pas manuellement les conteneurs sur la base de simples soupçons ; en cas de message NDR containers not ready, rassemblez les observations disponibles et coordonnez la suite avec le support Sophos.