Partilhar via

Utilizar o sensor baseado em eBPF para Microsoft Defender para Endpoint no Linux

  • Aplica-se a: Microsoft Defender for Endpoint Plan 1, Microsoft Defender for Endpoint Plan 2

Nota

A partir do Defender para Endpoint no Linux, a versão 101.2408.0000, AuditD já não é suportada como fornecedor de eventos suplementar. Para obter mais informações, veja as FAQs no final deste artigo.

O Filtro de Pacotes berkeley (eBPF) alargado para Microsoft Defender para Endpoint no Linux fornece dados suplementares de eventos para sistemas operativos Linux. O eBPF ajuda a resolver várias classes de problemas observados com o fornecedor de eventos AuditD e é benéfico nas áreas de desempenho e estabilidade do sistema.

Os principais benefícios incluem:

  • Dados irrelevantes de registos relacionados com Auditorias ao nível do sistema reduzidos
  • Regras de eventos otimizadas ao nível do sistema, caso contrário, estão a causar conflitos entre aplicações
  • Sobrecarga reduzida para monitorização de eventos de ficheiros (leitura/abertura de ficheiros)
  • Melhoramento do débito da taxa de eventos e redução da quantidade de memória
  • Desempenho otimizado para configurações específicas

Como funciona o eBPF

Com o eBPF, os eventos obtidos anteriormente a partir do fornecedor de eventos AuditD agora fluem do sensor eBPF. Isto ajuda na estabilidade do sistema, melhora a utilização da CPU e da memória e reduz a utilização do disco. O eBPF ajuda a reduzir a possibilidade de conflitos entre aplicações, uma vez que não são necessárias regras personalizadas. Os dados relacionados com o eBPF são registados no ficheiro /var/log/microsoft/mdatp/microsoft_defender_core.log.

Além disso, o sensor eBPF utiliza capacidades do kernel do Linux sem exigir a utilização de um módulo de kernel que ajude a aumentar a estabilidade do sistema.

Pré-requisitos do sistema

O sensor eBPF para Microsoft Defender para Endpoint no Linux é suportado nas seguintes versões mínimas de distribuição e kernel:

Distribuição do Linux Versão de distribuição Versão do 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

O Oracle Linux 8.8 com a versão de kernel 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 resultará num bloqueio de kernel quando o eBPF estiver ativado como fornecedor de subsistema suplementar. Esta versão de kernel não deve ser utilizada para o modo eBPF. Veja a secção Resolução de Problemas e Diagnóstico para obter os passos de mitigação.

Utilizar eBPF

O sensor eBPF é ativado automaticamente para todos os clientes por predefinição para versões de 101.23082.0006 agente e posteriores. Os clientes precisam de atualizar para uma versão suportada para experimentar a funcionalidade. Quando o sensor eBPF está ativado num ponto final, o Defender para Endpoint no Linux atualiza supplementary_events_subsystem para ebpf.

Realce do subsistema ebpf no comando mdatp health

Caso pretenda desativar manualmente o eBPF, pode executar o seguinte comando:

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

Também pode atualizar o ficheiro mdatp_managed.json:

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

Veja a ligação para obter o ficheiro json de exemplo detalhado – Definir preferências para Microsoft Defender para Endpoint no Linux.

Importante

Se desativar o eBPF ou, no caso de o eBPF não ser suportado em nenhum kernel específico, o fornecedor de eventos suplementar muda para o Netlink. Todas as operações de processo continuarão a fluir de forma totalmente integrada, mas poderá perder eventos específicos relacionados com o ficheiro e socket que o eBPF capturaria de outra forma.

Também pode verificar o estado do eBPF (ativado/desativado) nos pontos finais do linux através da investigação avançada no Portal do Microsoft Defender. Os passos são os seguintes:

  1. Aceda ao portal Microsoft Defender e inicie sessão.

  2. No painel de navegação, aceda a Investigação>Avançada de Investigação.

  3. Em Investigação avançada, aceda a Gestão de vulnerabilidades do Defender.

  4. Execute a seguinte consulta: DeviceTvmInfoGathering.

  5. Na saída, na coluna Campos adicionais , selecione Mostrar mais e, em seguida , procure EBPF STATUS: true.

Modo imutável de AuditD

Para os clientes que utilizam AuditD no modo imutável, é necessário reiniciar após a ativação do eBPF para limpar as regras de auditoria adicionadas pelo Microsoft Defender para Endpoint. Este requisito é uma limitação no modo imutável de AuditD, que bloqueia o ficheiro de regras e proíbe a edição/substituição. Este problema é resolvido com o reinício.

Após o reinício, execute o seguinte comando para verificar se as regras de auditoria foram limpas:

% sudo auditctl -l

O resultado do comando anterior não deve mostrar regras nem regras adicionadas pelo utilizador. Caso as regras não foram removidas, efetue os seguintes passos para limpar o ficheiro de regras de auditoria:

  1. Mude para o modo ebpf.

  2. Remova o ficheiro /etc/audit/rules.d/mdatp.rules.

  3. Reinicie o computador.

Resolução de Problemas e Diagnóstico

Pode verificar o estado de funcionamento do agente ao executar o comando de mdatp estado de funcionamento. Certifique-se de que o sensor eBPF para Defender para Endpoint no Linux é suportado ao verificar a versão atual do kernel com a seguinte linha de comandos:

uname -a

Problemas Conhecidos

  1. Ativar o eBPF na versão RHEL 8.1 com SAP pode resultar em pânico no kernel. Para mitigar este problema, pode seguir um dos seguintes passos:

    • Utilize uma versão de distribuição superior ao RHEL 8.1.
    • Mude para o modo AuditD se precisar de utilizar a versão RHEL 8.1.

  2. Utilizar o Oracle Linux 8.8 com a versão de kernel 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 poderá resultar em pânico no kernel. Para mitigar este problema, pode seguir um dos seguintes passos:

    • Utilize uma versão de kernel superior ou inferior a 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 no Oracle Linux 8.8 se quiser utilizar o eBPF como fornecedor de subsistema suplementar. A versão mínima do kernel para o Oracle Linux é RHCK 3.10.0 e Oracle Linux UEK é 5.4.

    • Mudar para o modo AuditD se precisar de utilizar a mesma versão do kernel

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

    • Os dois conjuntos de dados seguintes ajudam a analisar potenciais problemas e a determinar as opções de resolução mais eficazes.

      1. Recolha um pacote de diagnóstico da ferramenta de analisador de cliente com as seguintes instruções: Resolver problemas de desempenho de Microsoft Defender para Endpoint no Linux.

      2. Recolha um pacote de diagnóstico de depuração quando o Defender para Endpoint utiliza recursos elevados com as seguintes instruções: Microsoft Defender para Endpoint em recursos do Linux.

  3. O sistema bloqueia no Oracle Linux 7.9 com o Defender para Linux quando o ksplice é utilizado para aplicação de patches de kernel em direto.

    • A aplicação de patches de ksplice de instalação automática adiciona simplesmente uma tarefa cron ao ponto final.
    • Para mitigar o problema de bloqueio, pode criar uma tarefa cron que primeiro irá parar o serviço mdatp, aplicar a aplicação de patches baseada em ksplice e, em seguida, iniciar o serviço.
    • Uma vez que a aplicação de patches de kernel é de poucos segundos, a atividade não terá grande exposição em termos de segurança.

Resolver problemas de desempenho

Se vir um aumento do consumo de recursos ao Microsoft Defender nos pontos finais, é importante identificar o processo/ponto de montagem/ficheiros que estão a causar a maior parte da utilização da CPU/Memória. Em seguida, pode aplicar as exclusões necessárias. Depois de aplicar possíveis exclusões antivírus, se wdavdaemon (processo principal) ainda estiver a consumir os recursos, utilize o comando ebpf-statistics para obter a contagem de chamadas de 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

No resultado anterior, pode ver que stress-ng é o processo principal que gera um grande número de eventos e pode resultar em problemas de desempenho. O mais provável é que o stress esteja a gerar a chamada do sistema com o ID 82. Pode criar um pedido de suporte com a Microsoft para excluir este processo.

As exclusões aplicadas ao AuditD não podem ser migradas ou copiadas para o eBPF. Preocupações comuns, como registos ruidosos, pânico de kernel, syscalls ruidosas já são tratados internamente pelo eBPF. Caso pretenda adicionar mais exclusões, contacte a Microsoft para obter as exclusões necessárias aplicadas.

FAQs - Transição para eBPF

1. Por que deve considerar mudar para o eBPF?

O Filtro de Pacotes de Berkeley (eBPF) alargado para Microsoft Defender para Endpoint no Linux serve como uma alternativa eficiente ao AuditD e resolve vários desafios associados ao fornecedor de eventos AuditD, ao mesmo tempo que proporciona vantagens significativas em termos de desempenho e estabilidade do sistema. Alguns dos principais benefícios incluem -

  • Desempenho: o eBPF melhora significativamente o desempenho ao reduzir a sobrecarga nos recursos do sistema em comparação com o AuditD.

  • Eficiência de Recursos: o eBPF utiliza menos recursos, o que ajuda a manter a estabilidade do sistema mesmo em condições de carga pesadas.

  • Escalabilidade: a arquitetura do eBPF é mais dimensionável, tornando-a uma escolha melhor para ambientes com cargas de trabalho crescentes ou complexas.

  • Tecnologia Moderna: o eBPF representa uma tecnologia moderna e orientada para o futuro que se alinha com futuros desenvolvimentos de kernel do Linux, garantindo um melhor suporte a longo prazo.

2. Como posso continuar a utilizar o AuditD?

Se preferir continuar a utilizar o AuditD:

  • Versões Suportadas: pode permanecer no Defender para Endpoint na versão 101.24072.0000 do Linux, que irá suportar AuditD durante a validade da compilação, que é de aproximadamente nove meses. Isto fornece um período de transição suficiente para planear a sua mudança para o eBPF. A data de expiração pode ser verificada ao executar o comando mdatp health no servidor Linux.

  • Long-Term Plano: embora permanecer na 101.24072.0000 compilação seja uma opção, recomendamos que planeie a sua transição para o eBPF dentro deste período de tempo para garantir que beneficia das melhorias de segurança e desempenho mais recentes e também obter suporte contínuo.

Dito isto, a nossa recomendação seria planear uma mudança para a utilização do eBPF como fornecedor principal de eventos.

3. O que acontece se o eBPF não for suportado em alguns cenários?

Nos casos em que o eBPF não é suportado:

  • Netlink Fallback: o sistema volta a utilizar o fornecedor de eventos Netlink. Enquanto o Netlink continua a capturar eventos de processo (por exemplo, exec, exit, fork, gidou tid), não suporta eventos relacionados com o sistema de ficheiros (por exemplo, rename, unlink) ou eventos de socket.

  • Impacto: as cargas de trabalho não serão interrompidas, mas poderá perder eventos específicos relacionados com o ficheiro e socket que o eBPF capturaria de outra forma.

4. Como posso gerir exclusões com as Versões Atualizadas?

Seguem-se alguns motivos comuns para colocar exclusões para AuditD:

  • O desempenho como um processo ou syscall está a gerar muito ruído

  • Kernel Panic, há alturas em que muitas chamadas syscalls especificamente chamadas de rede/sistema de ficheiros resultaram em pânico no kernel.

  • Registos ruidosos, em que os registos de auditoria estão a utilizar o espaço em disco. O cliente colocou as exclusões para os processos ruidosos para reduzir o tamanho do registo.

Com o eBPF, os dois primeiros casos de utilização são os candidatos à migração. Os registos já não são um problema com o eBPF. No caso das duas primeiras utilizações, pode escolher entre as seguintes opções:

  • Contactar o suporte: contacte a Microsoft para aplicar as exclusões do back-end.

  • Exclusões Globais: nas versões atualizadas do Defender para Endpoint no Linux, as exclusões podem ser geridas com exclusões globais. As exclusões globais aplicam-se ao antivírus e ao EDR e podem ser configuradas através do json gerido atualmente. Para obter mais informações, consulte Configurar e validar exclusões do Microsoft Defender para Endpoint no Linux.

5. O que devo fazer caso existam problemas?

  • Contactar o Suporte: se encontrar problemas durante ou após a transição para o eBPF, contacte o suporte técnico para obter assistência. Estamos empenhados em garantir uma transição suave e estamos disponíveis para ajudar a resolver quaisquer desafios que possa enfrentar.

  • Canais de Suporte: pode contactar o suporte através do portal Microsoft Defender. Além disso, os nossos fóruns de base de dados de conhecimento e comunidade são recursos valiosos para resolver problemas comuns.

Consulte também

  • Last updated on