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

Articolo
05/01/2024

Si applica a:

EBPF (Extended Berkeley Packet Filter) per Microsoft Defender per endpoint in Linux fornisce dati sugli eventi supplementari per i sistemi operativi Linux. eBPF può essere usato come tecnologia alternativa da controllare perché eBPF consente di risolvere diverse classi di problemi riscontrati con il provider di eventi controllato ed è vantaggioso nelle aree delle prestazioni e della stabilità del sistema.

I vantaggi principali includono:

Riduzione del rumore del log correlato al controllo 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 controllati 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. Inoltre, quando eBPF è abilitato, vengono eliminate tutte le regole personalizzate correlate al controllo, riducendo così la possibilità di conflitti tra le applicazioni. 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.

Nota

eBPF viene usato in combinazione con auditd, mentre auditd viene usato solo per gli eventi di accesso utente e acquisisce questi eventi senza regole personalizzate e li scorre automaticamente. Tenere presente che il controllo verrà rimosso gradualmente nelle versioni future.

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

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 dell'agente "101.23082.0006" e versioni successive. I clienti devono eseguire l'aggiornamento alle versioni supportate sopra indicate per sperimentare la funzionalità. Quando il sensore eBPF è abilitato in un endpoint, Defender per endpoint in Linux supplementary_events_subsystem a ebpf.

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, il provider di eventi supplementari torna a controllato. Nel caso in cui eBPF non venga abilitato o non sia supportato in alcun kernel specifico, tornerà automaticamente a controllato e manterrà tutte le regole personalizzate controllate.

È 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:

Passare al portale di Microsoft Defender ed eseguire l'accesso.
Nel riquadro di spostamento passare a Ricerca>avanzata.
In Ricerca avanzata passare a Gestione vulnerabilità di Defender.
Eseguire la query seguente: DeviceTvmInfoGathering.
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 il controllo in modalità non modificabile, è necessario un riavvio dopo l'abilitazione di eBPF per cancellare le regole di controllo aggiunte da Microsoft Defender per endpoint. Si tratta di una limitazione nella modalità non modificabile di controllo, 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 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 vengono rimosse, seguire questa procedura per cancellare il file delle regole di controllo.

Passare alla modalità ebpf
Rimuovere il file /etc/audit/rules.d/mdatp.rules
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

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à di controllo se è necessario usare la versione RHEL 8.1.
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. Si noti che la versione minima del kernel per Oracle Linux è RHCK 3.10.0 e Oracle Linux UEK è 5.4.
- Passare alla modalità di controllo 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.

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.
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/file che utilizza la maggior parte dell'utilizzo della CPU/memoria e quindi applicare le esclusioni necessarie. Dopo aver applicato possibili esclusioni av, se wdavdaemon (processo padre) utilizza ancora le risorse, usare il comando ebpf-statistics per ottenere il numero di chiamate di sistema superiore:

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.

Condividi tramite