Utiliser un capteur eBPF pour Microsoft Defender pour point de terminaison sur Linux

  • S’applique à: Microsoft Defender for Endpoint Plan 1, Microsoft Defender for Endpoint Plan 2

Remarque

À partir de la version 101.2408.0000 de Defender for Endpoint sur Linux, AuditD n’est plus pris en charge en tant que fournisseur d’événements supplémentaire. Pour plus d’informations, consultez FAQ - Transition vers eBPF.

Le filtre eBPF (Berkeley Packet Filter) étendu pour Microsoft Defender pour point de terminaison sur Linux fournit des données d’événement supplémentaires pour les systèmes d’exploitation Linux. eBPF permet de résoudre plusieurs classes de problèmes rencontrés avec le fournisseur d’événements AuditD et est bénéfique dans les domaines des performances et de la stabilité du système.

Les principaux avantages sont les suivants :

  • Réduction du bruit de journal lié à AuditD à l’échelle du système
  • Des règles d’événement optimisées à l’échelle du système entraînent un conflit entre les applications
  • Réduction de la surcharge pour l’analyse des événements de fichier (lecture/ouverture de fichier)
  • Débit d’événements amélioré et empreinte mémoire réduite
  • Performances optimisées pour des configurations spécifiques

Fonctionnement d’eBPF

Avec eBPF, les événements précédemment obtenus auprès du fournisseur d’événements AuditD circulent désormais à partir du capteur eBPF. Cela contribue à la stabilité du système, améliore l’utilisation du processeur et de la mémoire, et réduit l’utilisation du disque. eBPF permet de réduire les risques de conflits entre les applications, car aucune règle personnalisée n’est requise. Les données liées à eBPF sont consignées dans le fichier /var/log/microsoft/mdatp/microsoft_defender_core.log.

En outre, le capteur eBPF utilise les fonctionnalités du noyau Linux sans nécessiter l’utilisation d’un module de noyau qui contribue à augmenter la stabilité du système.

Prérequis système

Le capteur eBPF nécessite la version 101.23082.0006 ou ultérieure de l’agent Defender for Endpoint pour Linux. Vérifiez que votre point de terminaison est mis à jour vers une version de l’assistant prise en charge avant de continuer.

Le capteur eBPF est pris en charge sur les versions minimales de distribution et de noyau suivantes :

distribution Linux Version de distribution Version du noyau
Ubuntu 16.04 4.15.0
Fedora 33 5.8.15
CentOS 7.6 3.10.0-957.10
SLES 15 5.3.18-18.47
RHEL 7.6 3.10.0-957.10
Debian 9.0 4.19.0
Oracle Linux RHCK 7.9 3.10.0-1160
Oracle Linux UEK 7.9 5.4
Amazon Linux 2 2 5.4.261-174.360
Rocky Linux 8 8.7 4.18.0-425
Rocky Linux 9 9.2 5.14.0-284
Alma Linux 8 8.4 4.18.0-305
Alma Linux 9 9.2 5.14.0-284

Remarque

Oracle Linux 8.8 avec la version du noyau 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 entraîne un blocage du noyau lorsque eBPF est activé en tant que fournisseur de sous-système supplémentaire. Cette version du noyau ne doit pas être utilisée pour le mode eBPF. Reportez-vous à la section Résolution des problèmes et diagnostics pour connaître les étapes d’atténuation.

Activer et configurer le capteur eBPF

Le capteur eBPF est automatiquement activé pour tous les clients par défaut pour les versions de l’agent et les versions 101.23082.0006 ultérieures. Les clients doivent effectuer une mise à jour vers une version prise en charge pour découvrir la fonctionnalité. Lorsque le capteur eBPF est activé sur un point de terminaison, Defender for Endpoint sur Linux met à jour supplementary_events_subsystem sur ebpf.

Mise en surbrillance du sous-système ebpf dans la commande mdatp health

Pour activer ou désactiver le fournisseur d’événements supplémentaire eBPF, exécutez la commande suivante :

sudo mdatp config ebpf-supplementary-event-provider --value [enabled/disabled]

Vous pouvez aussi désactiver le fournisseur supplémentaire d’événements eBPF en définissant ebpfSupplementaryEventProvider sur disabled dans le fichier mdatp_managed.json :

{
    "features": {
        "ebpfSupplementaryEventProvider": "disabled"
    }
}

Pour obtenir un exemple de fichier JSON détaillé, consultez Définir des préférences pour Microsoft Defender for Endpoint sur Linux.

Important

Si vous désactivez eBPF ou si eBPF n’est pas pris en charge sur un noyau spécifique, le fournisseur d’événements supplémentaire bascule vers Netlink. Toutes les opérations de processus continueront à s’effectuer en toute transparence, mais vous risquez de passer à côté d’événements spécifiques liés aux fichiers et aux sockets qu’eBPF capturerait autrement.

Vous pouvez également vérifier le statut d’eBPF (activé/désactivé) sur vos points de terminaison Linux à l’aide de la recherche avancée dans le portail Microsoft Defender. Les étapes sont les suivantes :

  1. Accédez au portail Microsoft Defender et connectez-vous.

  2. Dans le volet de navigation, accédez à Recherche>Recherche avancée.

  3. Dans Recherche avancée, accédez à Defender Vulnerability Management.

  4. Exécutez la requête suivante : DeviceTvmInfoGathering.

  5. Dans la sortie, dans la colonne Champs supplémentaires , sélectionnez Afficher plus, puis recherchez EBPF STATUS : true.

Mode d’immuabilité d’AuditD

Pour les clients qui utilisent AuditD en mode immuable, un redémarrage est nécessaire après l’activation d’eBPF afin d’effacer les règles d’audit ajoutées par Microsoft Defender pour point de terminaison. Cette exigence est une limitation en mode immuable d’AuditD, qui fige le fichier de règles et interdit la modification/le remplacement. Le redémarrage efface les règles d'audit Microsoft Defender for Endpoint qui ne peuvent pas être supprimées lorsque AuditD est en mode immuable.

Après le redémarrage, répertoriez les règles AuditD actuelles pour vérifier que les règles d’audit de Defender for Endpoint ont bien été supprimées :

% sudo auditctl -l

La sortie de la commande précédente ne doit afficher aucune règle ni aucune règle ajoutée par l’utilisateur. Si les règles n’ont pas été supprimées, procédez comme suit pour effacer le fichier de règles d’audit :

  1. Passez en mode eBPF.

  2. Supprimez le fichier /etc/audit/rules.d/mdatp.rules.

  3. Redémarrez l’ordinateur.

Résolution des problèmes et diagnostics

Vous pouvez vérifier l’état d’intégrité de l’agent en exécutant la commande mdatp health. Pour vérifier que votre version du noyau répond aux exigences du capteur eBPF répertoriées dans les conditions préalables système, vérifiez la version actuelle du noyau en exécutant la commande suivante :

uname -a

Problèmes connus

Tenez compte des problèmes connus suivants lors de l’utilisation du capteur eBPF sur Linux :

  1. Avertissement: Sur RHEL 8.1 avec SAP, l’activation d’eBPF peut provoquer une panique du noyau. Avant d’activer eBPF sur cette configuration, effectuez l’une des étapes d’atténuation suivantes :

    • Utilisez une version de distribution supérieure à RHEL 8.1.
    • Basculez en mode AuditD si vous devez utiliser la version 8.1 de RHEL.

  2. L’utilisation d’Oracle Linux 8.8 avec la version du noyau 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 peut entraîner une panique du noyau. Pour atténuer ce problème, vous pouvez effectuer l’une des étapes suivantes :

    • Utilisez une version du noyau supérieure ou inférieure à 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 sur Oracle Linux 8.8 si vous souhaitez utiliser eBPF comme fournisseur de sous-système supplémentaire. La version minimale du noyau pour Oracle Linux est RHCK 3.10.0 et Oracle Linux UEK est 5.4.

    • Passer en mode AuditD si vous devez utiliser la même version du noyau

      sudo mdatp config  ebpf-supplementary-event-provider  --value disabled

    • Les deux ensembles de données suivants permettent d’analyser les problèmes potentiels et de déterminer les options de résolution les plus efficaces.

      1. Collectez un package de diagnostic à partir de l’outil analyseur client en suivant les instructions suivantes : Résoudre les problèmes de performances pour Microsoft Defender pour point de terminaison sur Linux.

      2. Collectez un package de diagnostics de débogage lorsque Microsoft Defender for Endpoint consomme beaucoup de ressources en suivant les instructions suivantes : Ressources Microsoft Defender for Endpoint sur Linux.

  3. Le système se bloque sur Oracle Linux 7.9 exécutant Defender pour Linux lorsque ksplice est utilisé pour la mise à jour corrective du noyau en direct.

    • L’installation automatique des correctifs de Ksplice ajoute simplement une tâche cron au terminal.
    • Pour atténuer le problème de blocage, vous pouvez créer un travail cron qui arrête d’abord le service mdatp, applique une mise à jour corrective basée sur ksplice, puis démarre le service.
    • Comme la mise à jour corrective du noyau est une activité de quelques secondes, cela n’aura pas d’exposition majeure en termes de sécurité.

Résolution des problèmes de performances

Si vous constatez une augmentation de la consommation des ressources par Microsoft Defender sur vos points de terminaison, il est important d’identifier le processus/point de montage/fichiers qui sont à l’origine de la majeure partie de l’utilisation du processeur/de la mémoire. Vous pouvez ensuite appliquer les exclusions nécessaires. Après avoir appliqué d’éventuelles exclusions antivirus, si wdavdaemon (processus parent) consomme toujours les ressources, utilisez la commande ebpf-statistics pour obtenir le nombre d’appels système le plus haut :

sudo mdatp diagnostic  ebpf-statistics

L’exemple de sortie suivant montre les statistiques eBPF collectées sur un intervalle de surveillance de 20 secondes, y compris les chemins d’accès de fichiers principaux, les processus initiateurs et les ID d’appel système :

Monitor 20 seconds
Top file paths:
/var/log/microsoft/mdatp/microsoft_defender.log : 10
/var/log/microsoft/mdatp/rotated/microsoft_defender.log00001 : 2
/var/log/microsoft/mdatp/rotated/microsoft_defender.log : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374993 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374991 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374989 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374987 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374985 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374983 : 1
/home/gargank/tmp-stress-ng-rename-13550-31/stress-ng-rename-13550-31-374981 : 1

Top initiator paths:
/usr/bin/stress-ng : 50000
/opt/microsoft/mdatp/sbin/wdavdaemon : 13

Top syscall ids:
82 : 1699333
90 : 10
87 : 3

Dans la sortie mdatp diagnostic ebpf-statistics, stress-ng est le principal processus produisant un grand nombre d’événements et peut entraîner des problèmes de performances. Il est très probable que stress-ng génère l’appel système dont l’ID est 82. Vous pouvez créer un ticket avec Microsoft pour exclure ce processus.

Les exclusions appliquées à AuditD ne peuvent pas être migrées ou copiées vers eBPF. Les problèmes courants tels que les journaux bruyants, les paniques au niveau du noyau et les appels système verbeux sont déjà gérés en interne par eBPF. Si vous souhaitez ajouter d’autres exclusions, contactez Microsoft pour que les exclusions nécessaires soient appliquées.

FAQ - Transition vers eBPF

1. Pourquoi envisager de passer à l’eBPF ?

Le filtre de paquets Berkeley étendu (eBPF) pour Microsoft Defender pour point de terminaison sur Linux constitue une alternative efficace à AuditD et répond aux différents défis associés au fournisseur d’événements AuditD tout en offrant des avantages significatifs en termes de performances et de stabilité du système. Voici quelques-uns des principaux avantages :

  • Performances : eBPF améliore considérablement les performances en réduisant la surcharge sur les ressources système par rapport à AuditD.

  • Efficacité des ressources : eBPF utilise moins de ressources, ce qui permet de maintenir la stabilité du système même dans des conditions de charge importante.

  • Scalabilité : l’architecture d’eBPF est plus évolutive, ce qui en fait un meilleur choix pour les environnements avec des charges de travail croissantes ou complexes.

  • Technologie moderne : eBPF représente une technologie moderne et tournée vers l’avenir qui s’aligne sur les développements futurs Linux noyau, garantissant un meilleur support à long terme.

2. Comment puis-je continuer à utiliser AuditD ?

Si vous préférez continuer à utiliser AuditD :

  • Versions prises en charge : vous pouvez rester sur Microsoft Defender pour point de terminaison sous Linux, version 101.24072.0000, qui continuera de prendre en charge AuditD pendant la durée de validité de la version, soit environ neuf mois. Cela fournit une période de transition suffisante pour planifier votre passage à eBPF. Vous pouvez vérifier la date d’expiration en exécutant la commande mdatp health sur le serveur Linux.

  • Plan à long terme : Bien qu’utiliser la version 101.24072.0000 reste une option, nous vous recommandons de planifier votre transition vers eBPF d’ici là afin de bénéficier des dernières améliorations en matière de sécurité et de performances, tout en continuant à bénéficier du support.

Cela dit, nous vous recommandons de planifier une transition vers l’utilisation d’eBPF comme fournisseur d’événements principal.

3. Que se passe-t-il si eBPF n’est pas pris en charge dans certains scénarios ?

Dans les cas où eBPF n’est pas pris en charge :

  • Netlink Fallback : le système revient à utiliser le fournisseur d’événements Netlink. Bien que Netlink continue de capturer les événements de processus (par exemple, exec, exit, fork, gidou tid), il ne prend pas en charge les événements liés au système de fichiers (par exemple, rename, unlink) ou les événements de socket.

  • Impact : vos charges de travail ne seront pas interrompues, mais vous pourriez manquer des événements spécifiques liés aux fichiers et aux sockets qu’eBPF capturerait autrement.

4. Comment gérer les exclusions avec les versions mises à jour ?

Voici quelques raisons courantes pour placer des exclusions pour AuditD :

  • Performances dégradées, parce qu’un appel système ou un processus génère beaucoup de bruit

  • Kernel panic : il arrive que de nombreux appels système, en particulier ceux liés au réseau et au système de fichiers, provoquent un kernel panic.

  • Journaux bruyants, où les journaux d’audit utilisent trop d’espace disque. Le client a mis en place des exclusions pour les processus générant beaucoup de logs afin de réduire la taille du fichier journal.

Avec l’eBPF, les deux premiers cas d’usage se prêtent à la migration. Les journaux ne sont plus un problème avec eBPF. Pour les deux premiers cas d’utilisation, vous pouvez choisir parmi les options suivantes :

  • Contactez le support : Contactez Microsoft pour appliquer les exclusions du back-end.

  • Exclusions globales : dans les versions mises à jour de Defender pour point de terminaison sur Linux, les exclusions peuvent être gérées avec des exclusions globales. Les exclusions globales s’appliquent à l’antivirus et à l’EDR et peuvent être configurées via le json managé actuellement. Pour plus d’informations, consultez Configurer et valider les exclusions pour Microsoft Defender pour point de terminaison sur Linux.

5. Que dois-je faire en cas de problèmes ?

  • Contactez le support technique : si vous rencontrez des problèmes pendant ou après votre transition vers eBPF, contactez le support technique pour obtenir de l’aide. Nous nous engageons à assurer une transition en douceur et sommes disponibles pour vous aider à résoudre les problèmes que vous pourriez rencontrer.

  • Canaux de support : vous pouvez contacter le support via le portail Microsoft Defender. En outre, nos base de connaissances et forums de la communauté sont des ressources précieuses pour résoudre les problèmes courants.

Contenu connexe

Pour plus d’informations sur la résolution des problèmes et la gestion des ressources pour Defender pour point de terminaison sur Linux, consultez les articles suivants :

  • Last updated on