Condividi tramite

Usare un sensore basato su eBPF per Microsoft Defender per endpoint in Linux

  • Articolo

Nota

A partire da Defender per endpoint in Linux, versione 101.2408.0000, AuditD non è più supportato come provider di eventi supplementari. Per altre informazioni, vedere le domande frequenti alla fine di questo articolo.

EBPF (Extended Berkeley Packet Filter) per Microsoft Defender per endpoint in Linux fornisce dati sugli eventi supplementari per i sistemi operativi Linux. eBPF consente di risolvere diverse classi di problemi riscontrati con il provider di eventi AuditD ed è utile nelle aree delle prestazioni e della stabilità del sistema.

I vantaggi principali includono:

  • Riduzione del rumore del log correlato a AuditD a livello di sistema
  • Regole degli eventi ottimizzate a livello di sistema altrimenti causano conflitti tra le applicazioni
  • Riduzione del sovraccarico per il monitoraggio dell'evento file (lettura/apertura del file)
  • Velocità effettiva degli eventi migliorata e footprint di memoria ridotto
  • Prestazioni ottimizzate per configurazioni specifiche

Funzionamento di eBPF

Con eBPF, gli eventi ottenuti in precedenza dal provider di eventi AuditD ora passano dal sensore eBPF. Ciò consente di mantenere la stabilità del sistema, migliorare l'utilizzo della CPU e della memoria e ridurre l'utilizzo del disco. eBPF consente di ridurre la possibilità di conflitti tra le applicazioni in quanto non sono necessarie regole personalizzate. I dati correlati a eBPF vengono registrati nel file /var/log/microsoft/mdatp/microsoft_defender_core.log.

Inoltre, il sensore eBPF usa le funzionalità del kernel Linux senza richiedere l'uso di un modulo kernel che consente di aumentare la stabilità del sistema.

Prerequisiti di sistema

Il sensore eBPF per Microsoft Defender per endpoint in Linux è supportato nelle versioni minime di distribuzione e kernel seguenti:

Distribuzione Linux Versione di distribuzione Versione 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 kernel versione 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 comporterà il blocco del kernel quando eBPF è abilitato come provider di sottosistemi supplementari. Questa versione del kernel non deve essere usata per la modalità eBPF. Per informazioni sulla procedura di mitigazione, vedere la sezione Risoluzione dei problemi e diagnostica.

Usare eBPF

Il sensore eBPF viene abilitato automaticamente per tutti i clienti per impostazione predefinita per le versioni 101.23082.0006 dell'agente e versioni successive. I clienti devono eseguire l'aggiornamento a una versione supportata per sperimentare la funzionalità. Quando il sensore eBPF è abilitato in un endpoint, Defender per endpoint in Linux supplementary_events_subsystem a ebpf.

Evidenziazione del sottosistema ebpf nel comando di integrità mdatp

Nel caso in cui si voglia disabilitare manualmente eBPF, è possibile eseguire il comando seguente:

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

È anche possibile aggiornare il file mdatp_managed.json:

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

Fare riferimento al collegamento per informazioni dettagliate sul file json di esempio - Impostare le preferenze per Microsoft Defender per endpoint in Linux.

Importante

Se si disabilita eBPF o nel caso in cui eBPF non sia supportato in alcun kernel specifico, il provider di eventi supplementari passa a Netlink. Tutte le operazioni di processo continueranno a scorrere senza problemi, ma è possibile che si perdano eventi specifici relativi a file e socket che eBPF acquisirebbe in caso contrario.

È anche possibile controllare lo stato di eBPF (abilitato/disabilitato) negli endpoint Linux usando la ricerca avanzata nel portale di Microsoft Defender. I passaggi sono i seguenti:

  1. Passare al portale di Microsoft Defender ed eseguire l'accesso.

  2. Nel riquadro di spostamento passare a Ricerca>avanzata.

  3. In Ricerca avanzata passare a Gestione delle vulnerabilità di Defender.

  4. Eseguire la query seguente: DeviceTvmInfoGathering.

  5. Nella colonna Campi aggiuntivi dell'output selezionare Mostra altro e quindi cercare EBPF STATUS: true.

Modalità non modificabile di AuditD

Per i clienti che usano AuditD in modalità non modificabile, è necessario un riavvio dopo l'abilitazione di eBPF per cancellare le regole di controllo aggiunte da Microsoft Defender per endpoint. Questo requisito è una limitazione nella modalità non modificabile di AuditD, che blocca il file delle regole e impedisce la modifica/sovrascrittura. Questo problema viene risolto con il riavvio.

Dopo il riavvio, eseguire il comando seguente per verificare se le regole di controllo sono state cancellate:

% sudo auditctl -l

L'output del comando precedente non deve mostrare regole o regole aggiunte dall'utente. Nel caso in cui le regole non siano state rimosse, seguire questa procedura per cancellare il file delle regole di controllo:

  1. Passare alla modalità ebpf.
  2. Rimuovere il file /etc/audit/rules.d/mdatp.rules.
  3. Riavviare il computer.

Risoluzione dei problemi e diagnostica

È possibile controllare lo stato di integrità dell'agente eseguendo il mdatp comando di integrità. Verificare che il sensore eBPF per Defender per endpoint in Linux sia supportato controllando la versione corrente del kernel usando la riga di comando seguente:

uname -a

Problemi noti

  1. L'abilitazione di eBPF nella versione RHEL 8.1 con SAP potrebbe causare panico nel kernel. Per attenuare questo problema, è possibile eseguire una delle operazioni seguenti:

    • Usare una versione di distribuzione superiore a RHEL 8.1.
    • Passare alla modalità AuditD se è necessario usare la versione RHEL 8.1.

  2. L'uso di Oracle Linux 8.8 con kernel versione 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 potrebbe causare panico nel kernel. Per attenuare questo problema, è possibile eseguire una delle operazioni seguenti:

    • Usare una versione del kernel superiore o inferiore a 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 in Oracle Linux 8.8 se si vuole usare eBPF come provider di sottosistemi supplementari. La versione minima del kernel per Oracle Linux è RHCK 3.10.0 e Oracle Linux UEK è 5.4.
    • Passare alla modalità AuditD se è necessario usare la stessa versione del kernel
sudo mdatp config  ebpf-supplementary-event-provider  --value disabled

I due set di dati seguenti consentono di analizzare i potenziali problemi e determinare le opzioni di risoluzione più efficaci.

  1. Raccogliere un pacchetto di diagnostica dallo strumento analizzatore client usando le istruzioni seguenti: Risolvere i problemi di prestazioni per Microsoft Defender per endpoint in Linux.

  2. Raccogliere un pacchetto di diagnostica di debug quando Defender per endpoint usa risorse elevate usando le istruzioni seguenti: Microsoft Defender per endpoint nelle risorse Linux.

Risoluzione dei problemi di prestazioni

Se si verifica un aumento del consumo di risorse da parte di Microsoft Defender negli endpoint, è importante identificare il processo/punto di montaggio/i file che causano la maggior parte dell'utilizzo della CPU/memoria. È quindi possibile applicare le esclusioni necessarie. Dopo aver applicato possibili esclusioni antivirus, se wdavdaemon (processo padre) utilizza ancora le risorse, usare il comando ebpf-statistics per ottenere il numero massimo di chiamate di sistema:

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

Nell'output precedente è possibile notare che stress-ng è il processo principale che genera un numero elevato di eventi e può causare problemi di prestazioni. Molto probabilmente stress-ng genera la chiamata di sistema con ID 82. È possibile creare un ticket con Microsoft per escludere questo processo. In futuro, come parte dei miglioramenti futuri, si avrà più controllo per applicare tali esclusioni alla fine.

Le esclusioni applicate a AuditD non possono essere migrate o copiate in eBPF. Problemi comuni come log rumorosi, panico del kernel, syscall rumorosi sono già curati internamente da eBPF. Nel caso in cui si desideri aggiungere altre esclusioni, contattare Microsoft per ottenere le esclusioni necessarie applicate.

Domande frequenti - Transizione a eBPF

1. Perché è consigliabile passare a eBPF?

L'extended Berkeley Packet Filter (eBPF) per Microsoft Defender per endpoint in Linux funge da alternativa efficiente a AuditD e risolve varie sfide associate al provider di eventi AuditD, offrendo al tempo stesso vantaggi significativi in termini di prestazioni e stabilità del sistema. Alcuni dei vantaggi principali includono:

  • Prestazioni: eBPF migliora significativamente le prestazioni riducendo il sovraccarico sulle risorse di sistema rispetto a AuditD.

  • Efficienza delle risorse: eBPF usa meno risorse, il che consente di mantenere la stabilità del sistema anche in condizioni di carico elevato.

  • Scalabilità: l'architettura di eBPF è più scalabile, rendendola una scelta migliore per gli ambienti con carichi di lavoro in crescita o complessi.

  • Tecnologia moderna: eBPF rappresenta una tecnologia moderna e orientata al futuro che si allinea ai futuri sviluppi del kernel Linux, garantendo un supporto migliore a lungo termine.

2. Come è possibile continuare a usare AuditD?

Se si preferisce continuare a usare AuditD:

  • Versioni supportate: è possibile rimanere in Defender per endpoint in Linux versione 101.24072.0000, che supporterà AuditD durante la validità della compilazione, ovvero circa nove mesi. In questo modo è disponibile un periodo di transizione sufficiente per pianificare il passaggio a eBPF. È possibile controllare la data di scadenza eseguendo il comando mdatp health nel server Linux.

  • Long-Term Piano: anche se rimanere sulla 101.24072.0000 build è un'opzione, è consigliabile pianificare la transizione a eBPF entro questo intervallo di tempo per assicurarsi di trarre vantaggio dai miglioramenti più recenti a livello di sicurezza e prestazioni e di ottenere supporto continuo.

Detto questo, è consigliabile pianificare un passaggio all'uso di eBPF come provider di eventi primario.

3. Cosa accade se eBPF non è supportato in alcuni scenari?

Nei casi in cui eBPF non è supportato:

  • Netlink Fallback: il sistema esegue il fallback all'uso del provider di eventi Netlink. Mentre Netlink continua a acquisire eventi di processo (ad esempio, exec, exit, gidforko tid), non supporta eventi correlati al file system (ad esempio, rename, unlink) o eventi socket.

  • Impatto: i carichi di lavoro non verranno interrotti, ma si potrebbero perdere eventi specifici relativi a file e socket che eBPF acquisirebbe in caso contrario.

4. Come è possibile gestire le esclusioni con le versioni aggiornate?

Di seguito sono riportati alcuni motivi comuni per l'inserimento di esclusioni per AuditD:

  • Prestazioni in quanto alcuni syscall o processi generano molto rumore

  • Kernel Panic, ci sono momenti in cui molte chiamate syscalls in particolare di rete/file system hanno causato il panico del kernel.

  • Log rumorosi, in cui i log di controllo usano lo spazio su disco. Il cliente ha inserito le esclusioni per i processi rumorosi per ridurre le dimensioni del log.

Mentre con eBPF, i primi due casi d'uso sono i candidati per la migrazione. I log non sono più un problema con eBPF. Per i primi due casi d'uso, è possibile scegliere tra le opzioni seguenti:

  • Contattare il supporto tecnico: contattare Microsoft per applicare le esclusioni dal back-end.

  • Esclusioni globali: nelle versioni aggiornate di Defender per endpoint in Linux le esclusioni possono essere gestite con esclusioni globali. Le esclusioni globali si applicano sia all'antivirus che all'EDR e possono essere configurate tramite il json gestito attualmente. Per ulteriori informazioni, vedere Configurare e convalidare le esclusioni per Microsoft Defender per endpoint su Linux.

5. Cosa devo fare in caso di problemi?

  • Contattare il supporto tecnico: se si verificano problemi durante o dopo la transizione a eBPF, contattare il supporto tecnico per assistenza. Ci impegniamo a garantire una transizione senza problemi e siamo disponibili per risolvere eventuali problemi.

  • Canali di supporto: è possibile contattare il supporto tramite il portale di Microsoft Defender. Inoltre, i forum knowledge base e della community sono risorse preziose per la risoluzione dei problemi comuni.

Vedere anche