Compartir a través de

Uso del sensor basado en eBPF para Microsoft Defender para punto de conexión en Linux

  • Artículo

Se aplica a:

Nota:

A partir de Defender para punto de conexión en Linux, versión 101.2408.0000, AuditD ya no se admite como proveedor de eventos complementario. Para obtener más información, consulte las preguntas más frecuentes al final de este artículo.

El filtro de paquetes de Berkeley extendido (eBPF) para Microsoft Defender para punto de conexión en Linux proporciona datos de eventos adicionales para los sistemas operativos Linux. eBPF ayuda a abordar varias clases de problemas detectados con el proveedor de eventos AuditD y es beneficioso en las áreas de rendimiento y estabilidad del sistema.

Entre las principales ventajas se encuentran:

  • Reducción del ruido de registro relacionado con AuditD en todo el sistema
  • Reglas de eventos optimizadas para todo el sistema que, de lo contrario, provocan conflictos entre aplicaciones
  • Sobrecarga reducida para la supervisión de eventos de archivo (lectura y apertura de archivos)
  • Rendimiento mejorado de la velocidad de eventos y reducción de la superficie de memoria
  • Rendimiento optimizado para configuraciones específicas

Funcionamiento de eBPF

Con eBPF, los eventos obtenidos anteriormente del proveedor de eventos AuditD ahora fluyen desde el sensor eBPF. Esto ayuda con la estabilidad del sistema, mejora el uso de cpu y memoria y reduce el uso del disco. eBPF ayuda a reducir la posibilidad de conflictos entre aplicaciones, ya que no se requieren reglas personalizadas. Los datos relacionados con eBPF se registran en el archivo /var/log/microsoft/mdatp/microsoft_defender_core.log.

Además, el sensor eBPF usa funcionalidades del kernel de Linux sin necesidad de usar un módulo de kernel que ayude a aumentar la estabilidad del sistema.

Requisitos previos del sistema

El sensor eBPF para Microsoft Defender para punto de conexión en Linux se admite en las siguientes versiones mínimas de distribución y kernel:

Distribución de Linux Versión de distribución Versión del kernel
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

Nota:

Oracle Linux 8.8 con la versión 5.15.0-0.30.20.el8uek.x86_64 del kernel, 5.15.0-0.30.20.1.el8uek.x86_64 provocará un bloqueo del kernel cuando eBPF esté habilitado como proveedor de subsistemas complementarios. Esta versión del kernel no debe usarse para el modo eBPF. Consulte la sección Solución de problemas y diagnósticos para conocer los pasos de mitigación.

Uso de eBPF

El sensor eBPF se habilita automáticamente para todos los clientes de forma predeterminada para las versiones 101.23082.0006 del agente y versiones posteriores. Los clientes deben actualizar a una versión compatible para experimentar la característica. Cuando el sensor eBPF está habilitado en un punto de conexión, Defender para punto de conexión en Linux actualiza supplementary_events_subsystem a ebpf.

Resaltado del subsistema ebpf en el comando mdatp health

En caso de que quiera deshabilitar manualmente eBPF, puede ejecutar el siguiente comando:

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

También puede actualizar el archivo mdatp_managed.json:

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

Consulte el vínculo para obtener un archivo JSON de ejemplo detallado: establezca preferencias para Microsoft Defender para punto de conexión en Linux.

Importante

Si deshabilita eBPF o en el caso de que eBPF no se admita en ningún kernel específico, el proveedor de eventos complementario cambia a Netlink. Todas las operaciones de proceso seguirán fluyendo sin problemas, pero es posible que se pierda eventos específicos relacionados con archivos y socket que eBPF capturaría de otro modo.

También puede comprobar el estado de eBPF (habilitado o deshabilitado) en los puntos de conexión de Linux mediante la búsqueda avanzada en Microsoft Defender Portal. Los pasos son los siguientes:

  1. Vaya al portal de Microsoft Defender e inicie sesión.

  2. En el panel de navegación, vaya a Búsquedade búsqueda> avanzada.

  3. En Búsqueda avanzada, vaya a Administración de vulnerabilidades de Defender.

  4. Ejecute la consulta siguiente: DeviceTvmInfoGathering.

  5. En la salida, en la columna Campos adicionales , seleccione Mostrar más y, a continuación, busque EBPF STATUS: true.

Modo inmutable de AuditD

Para los clientes que usan AuditD en modo inmutable, se requiere un reinicio después de habilitar eBPF para borrar las reglas de auditoría agregadas por Microsoft Defender para punto de conexión. Este requisito es una limitación en el modo inmutable de AuditD, que inmoviliza el archivo de reglas y prohíbe la edición o sobrescritura. Este problema se resuelve con el reinicio.

Después del reinicio, ejecute el siguiente comando para comprobar si se borraron las reglas de auditoría:

% sudo auditctl -l

La salida del comando anterior no debe mostrar ninguna regla ni ninguna regla agregada por el usuario. En caso de que no se hayan quitado las reglas, siga estos pasos para borrar el archivo de reglas de auditoría:

  1. Cambie al modo ebpf.
  2. Quite el archivo /etc/audit/rules.d/mdatp.rules.
  3. Reinicie la máquina.

Solución de problemas y diagnósticos

Puede comprobar el estado de mantenimiento del agente ejecutando el mdatp comando health. Asegúrese de que el sensor de eBPF para Defender para punto de conexión en Linux sea compatible comprobando la versión actual del kernel mediante la siguiente línea de comandos:

uname -a

Problemas conocidos

  1. La habilitación de eBPF en la versión 8.1 de RHEL con SAP puede provocar un pánico en el kernel. Para mitigar este problema, puede realizar uno de los pasos siguientes:

    • Use una versión de distribución superior a RHEL 8.1.
    • Cambie al modo AuditD si necesita usar la versión RHEL 8.1.

  2. Con Oracle Linux 8.8 con la versión 5.15.0-0.30.20.el8uek.x86_64 del kernel, la versión 5.15.0-0.30.20.1.el8uek.x86_64 podría provocar el pánico del kernel. Para mitigar este problema, puede realizar uno de los pasos siguientes:

    • Use una versión del kernel superior o inferior a 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 en Oracle Linux 8.8 si desea usar eBPF como proveedor de subsistemas complementarios. La versión mínima del kernel para Oracle Linux es RHCK 3.10.0 y Oracle Linux UEK es 5.4.
    • Cambie al modo AuditD si necesita usar la misma versión del kernel.
sudo mdatp config  ebpf-supplementary-event-provider  --value disabled

Los dos conjuntos de datos siguientes ayudan a analizar posibles problemas y a determinar las opciones de resolución más eficaces.

  1. Recopile un paquete de diagnóstico de la herramienta del analizador de cliente mediante las siguientes instrucciones: Solución de problemas de rendimiento para Microsoft Defender para punto de conexión en Linux.

  2. Recopile un paquete de diagnóstico de depuración cuando Defender for Endpoint usa recursos elevados mediante las siguientes instrucciones: Microsoft Defender para punto de conexión en recursos de Linux.

Solución de problemas de rendimiento

Si ve un mayor consumo de recursos Microsoft Defender en los puntos de conexión, es importante identificar el proceso, el punto de montaje o los archivos que provocan la mayor parte del uso de CPU/memoria. A continuación, puede aplicar las exclusiones necesarias. Después de aplicar posibles exclusiones de antivirus, si wdavdaemon (proceso primario) sigue consumiendo los recursos, use el comando ebpf-statistics para obtener el recuento de llamadas del sistema superior:

sudo mdatp diagnostic  ebpf-statistics

Output
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

En la salida anterior, puede ver que stress-ng es el proceso superior que genera un gran número de eventos y puede dar lugar a problemas de rendimiento. Lo más probable es que stress-ng genere la llamada del sistema con el identificador 82. Puede crear un vale con Microsoft para que este proceso se excluya. En el futuro, como parte de las próximas mejoras, tendrá más control para aplicar dichas exclusiones al final.

Las exclusiones aplicadas a AuditD no se pueden migrar ni copiar a eBPF. Las preocupaciones comunes, como los registros ruidosos, el pánico del kernel y las llamadas syscall ruidosos, ya están a cargo de eBPF internamente. En caso de que quiera agregar más exclusiones, póngase en contacto con Microsoft para que se apliquen las exclusiones necesarias.

Preguntas más frecuentes: Transición a eBPF

1. ¿Por qué debería considerar la posibilidad de pasar a eBPF?

El filtro de paquetes de Berkeley extendido (eBPF) para Microsoft Defender para punto de conexión en Linux actúa como una alternativa eficaz a AuditD y aborda diversos desafíos asociados con el proveedor de eventos AuditD, a la vez que proporciona ventajas significativas en términos de rendimiento y estabilidad del sistema. Algunas de las principales ventajas son:

  • Rendimiento: eBPF mejora significativamente el rendimiento al reducir la sobrecarga en los recursos del sistema en comparación con AuditD.

  • Eficiencia de los recursos: eBPF usa menos recursos, lo que ayuda a mantener la estabilidad del sistema incluso en condiciones de carga pesada.

  • Escalabilidad: la arquitectura de eBPF es más escalable, lo que la convierte en una mejor opción para entornos con cargas de trabajo crecientes o complejas.

  • Tecnología moderna: eBPF representa una tecnología moderna y de futuro que se alinea con los futuros desarrollos de kernel de Linux, lo que garantiza un mejor soporte técnico a largo plazo.

2. ¿Cómo puedo seguir usando AuditD?

Si prefiere seguir usando AuditD:

  • Versiones admitidas: puede permanecer en Defender para punto de conexión en la versión 101.24072.0000 de Linux, que admitirá AuditD durante la validez de la compilación, que es aproximadamente nueve meses. Esto proporciona un período de transición suficiente para planear el traslado a eBPF. La fecha de expiración se puede comprobar ejecutando el comando mdatp health en el servidor Linux.

  • Long-Term Plan: aunque permanecer en la 101.24072.0000 compilación es una opción, se recomienda planear la transición a eBPF en este período de tiempo para garantizar que se beneficie de las últimas mejoras de seguridad y rendimiento y también obtenga soporte técnico continuo.

Dicho esto, nuestra recomendación sería planear una migración al uso de eBPF como proveedor de eventos principal.

3. ¿Qué ocurre si eBPF no se admite en algunos escenarios?

En los casos en los que no se admite eBPF:

  • Reserva de Netlink: el sistema vuelve a usar el proveedor de eventos de Netlink. Aunque Netlink sigue capturando eventos de proceso (por ejemplo, , execexit, fork, gido tid), no admite eventos relacionados con el sistema de archivos (por ejemplo, rename, unlink) o eventos de socket.

  • Impacto: las cargas de trabajo no se interrumpirán, pero podría perder eventos específicos relacionados con archivos y socket que eBPF capturaría de otro modo.

4. ¿Cómo puedo administrar exclusiones con las versiones actualizadas?

A continuación se muestran algunas razones comunes para colocar exclusiones para AuditD:

  • El rendimiento, ya que algunos procesos o llamadas de sistema generan mucho ruido

  • Kernel Panic, hay ocasiones en las que muchas llamadas syscalls específicamente de red o sistema de archivos provocaron el pánico del kernel.

  • Registros ruidosos, donde los registros de auditoría usan el espacio en disco. El cliente ha colocado las exclusiones de los procesos ruidosos con el fin de reducir el tamaño del registro.

Mientras que con eBPF, los dos primeros casos de uso son los candidatos para la migración. Los registros ya no son un problema con eBPF. En el caso de los dos primeros usos, puede elegir entre las siguientes opciones:

  • Póngase en contacto con el soporte técnico: póngase en contacto con Microsoft para aplicar las exclusiones del back-end.

  • Exclusiones globales: en las versiones actualizadas de Defender para punto de conexión en Linux, las exclusiones se pueden administrar con exclusiones globales. Las exclusiones globales se aplican tanto a antivirus como a EDR y se pueden configurar a través del json administrado actualmente. Para más información, consulte Configurar y validar exclusiones de Microsoft Defender para punto de conexión en Linux.

5. ¿Qué debo hacer en caso de que haya problemas?

  • Póngase en contacto con el soporte técnico: si tiene algún problema durante o después de su transición a eBPF, póngase en contacto con el soporte técnico para obtener ayuda. Nos comprometemos a garantizar una transición sin problemas y estamos disponibles para ayudar a resolver los desafíos a los que pueda enfrentarse.

  • Canales de soporte técnico: puede ponerse en contacto con el soporte técnico a través del portal de Microsoft Defender. Además, nuestros foros de knowledge base y comunidad son recursos valiosos para solucionar problemas comunes.

Vea también