Verwenden eines eBPF-basierten Sensors für Microsoft Defender for Endpoint unter Linux

  • Artikel

Gilt für:

Der erweiterte Berkeley Packet Filter (eBPF) für Microsoft Defender for Endpoint unter Linux stellt ergänzende Ereignisdaten für Linux-Betriebssysteme bereit. eBPF kann als alternative Technologie für die Überwachung verwendet werden, da eBPF dabei hilft, verschiedene Klassen von Problemen zu beheben, die mit dem überwachten Ereignisanbieter auftreten, und ist in den Bereichen Leistung und Systemstabilität von Vorteil.

Zu den wichtigsten Vorteilen gehören:

  • Reduziertes systemweites auditd-bezogenes Protokollrauschen
  • Optimierte systemweite Ereignisregeln, die andernfalls konflikte zwischen Anwendungen verursachen
  • Reduzierter Mehraufwand für die Überwachung von Dateiereignissen (Datei lesen/öffnen)
  • Verbesserter Ereignisratendurchsatz und geringerer Speicherbedarf
  • Optimierte Leistung für bestimmte Konfigurationen

Funktionsweise von eBPF

Mit eBPF fließen Ereignisse, die zuvor vom überwachten Ereignisanbieter abgerufen wurden, nun vom eBPF-Sensor aus. Dies trägt zur Systemstabilität bei, verbessert die CPU- und Arbeitsspeicherauslastung und reduziert die Datenträgerauslastung. Wenn eBPF aktiviert ist, werden außerdem alle überwachten benutzerdefinierten Regeln entfernt, wodurch die Wahrscheinlichkeit von Konflikten zwischen Anwendungen verringert wird. Daten im Zusammenhang mit eBPF werden in der Datei /var/log/microsoft/mdatp/microsoft_defender_core.log protokolliert.

Darüber hinaus nutzt der eBPF-Sensor Funktionen des Linux-Kernels, ohne dass ein Kernelmodul verwendet werden muss, das zur Erhöhung der Systemstabilität beiträgt.

Hinweis

eBPF wird in Verbindung mit auditd verwendet, während auditd nur für Benutzeranmeldungsereignisse verwendet wird und diese Ereignisse ohne benutzerdefinierte Regeln erfasst und automatisch übertragen wird. Beachten Sie, dass auditd in zukünftigen Versionen nach und nach entfernt wird.

Systemvoraussetzungen

Der eBPF-Sensor für Microsoft Defender for Endpoint unter Linux wird für die folgenden Mindestverteilungs- und Kernelversionen unterstützt:

Linux-Verteilung Verteilungsversion Kernelversion
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

Hinweis

Oracle Linux 8.8 mit Kernelversion 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 führt dazu, dass der Kernel nicht reagiert, wenn eBPF als ergänzender Subsystemanbieter aktiviert ist. Diese Kernelversion sollte nicht für den eBPF-Modus verwendet werden. Schritte zur Entschärfung finden Sie im Abschnitt Problembehandlung und Diagnose.

Verwenden von eBPF

Der eBPF-Sensor ist für alle Kunden standardmäßig automatisch für die Agent-Versionen "101.23082.0006" und höher aktiviert. Kunden müssen auf die oben genannten unterstützten Versionen aktualisieren, um das Feature zu verwenden. Wenn der eBPF-Sensor auf einem Endpunkt aktiviert ist, aktualisiert Defender für Endpunkt unter Linux supplementary_events_subsystem auf ebpf.

Ebpf-Subsystem:Hervorhebung im Befehl

Falls Sie eBPF manuell deaktivieren möchten, können Sie den folgenden Befehl ausführen:

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

Sie können auch die mdatp_managed.json-Datei aktualisieren:

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

Eine ausführliche JSON-Beispieldatei finden Sie unter dem Link Festlegen von Einstellungen für Microsoft Defender for Endpoint unter Linux.

Wichtig

Wenn Sie eBPF deaktivieren, wechselt der ergänzende Ereignisanbieter zurück zu auditd. Wenn eBPF nicht aktiviert wird oder auf einem bestimmten Kernel nicht unterstützt wird, wechselt es automatisch zurück zu überwacht und behält alle überwachten benutzerdefinierten Regeln bei.

Sie können auch die status von eBPF (aktiviert/deaktiviert) auf Ihren Linux-Endpunkten mithilfe der erweiterten Suche im Microsoft Defender-Portal überprüfen. Die Schritte sind wie folgt:

  1. Wechseln Sie zum Microsoft Defender-Portal, und melden Sie sich an.

  2. Navigieren Sie im Navigationsbereich zu HuntingAdvanced hunting (Erweiterte> Suche).

  3. Navigieren Sie unter Erweiterte Suche zu Defender-Sicherheitsrisikomanagement.

  4. Führen Sie die folgende Abfrage aus: DeviceTvmInfoGathering.

  5. Wählen Sie in der Ausgabe in der Spalte Zusätzliche Felderdie Option Mehr anzeigen aus, und suchen Sie dann nach EBPF STATUS: true.

Unveränderlicher Modus von Auditd

Für Kunden, die auditd im unveränderlichen Modus verwenden, ist nach der Aktivierung von eBPF ein Neustart erforderlich, um die von Microsoft Defender for Endpoint hinzugefügten Überwachungsregeln zu löschen. Dies ist eine Einschränkung im unveränderlichen Überwachungsmodus, der die Regeldatei einfriert und das Bearbeiten/Überschreiben verhindert. Dieses Problem wurde mit dem Neustart behoben. Führen Sie nach dem Neustart den folgenden Befehl aus, um zu überprüfen, ob Überwachungsregeln gelöscht wurden.

% sudo auditctl -l

In der Ausgabe des obigen Befehls sollten keine Regeln oder vom Benutzer hinzugefügte Regeln angezeigt werden. Falls die Regeln nicht entfernt wurden, führen Sie die folgenden Schritte aus, um die Überwachungsregeldatei zu löschen.

  1. Wechseln in den ebpf-Modus
  2. Entfernen Sie die Datei "/etc/audit/rules.d/mdatp.rules".
  3. Starten Sie den Computer neu.

Problembehandlung und Diagnose

Sie können die Status des Agents überprüfen, indem Sie den Integritätsbefehl mdatp ausführen. Stellen Sie sicher, dass der eBPF-Sensor für Defender für Endpunkt unter Linux unterstützt wird, indem Sie die aktuelle Kernelversion mithilfe der folgenden Befehlszeile überprüfen:

uname -a

Bekannte Probleme

  1. Das Aktivieren von eBPF unter RHEL 8.1-Version mit SAP kann zu Kernel panic führen. Um dieses Problem zu beheben, können Sie einen der folgenden Schritte ausführen:

    • Verwenden Sie eine Distributionsversion, die höher als RHEL 8.1 ist.
    • Wechseln Sie in den Überwachungsmodus, wenn Sie RHEL 8.1-Version verwenden müssen.

  2. Die Verwendung von Oracle Linux 8.8 mit kernelversion 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 kann zu Kernel panic führen. Um dieses Problem zu beheben, können Sie einen der folgenden Schritte ausführen:

    • Verwenden Sie eine Kernelversion höher oder niedriger als 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 unter Oracle Linux 8.8, wenn Sie eBPF als ergänzenden Subsystemanbieter verwenden möchten. Beachten Sie, dass die Kernel-Mindestversion für Oracle Linux RHCK 3.10.0 und Oracle Linux UEK 5.4 ist.
    • Wechseln Sie in den Überwachungsmodus, wenn Sie dieselbe Kernelversion verwenden müssen
sudo mdatp config  ebpf-supplementary-event-provider  --value disabled

Die folgenden beiden Sätze von Daten helfen bei der Analyse potenzieller Probleme und bei der Bestimmung der effektivsten Lösungsoptionen.

  1. Sammeln Sie mithilfe der folgenden Anweisungen ein Diagnosepaket aus dem Clientanalysetool: Behandeln von Leistungsproblemen für Microsoft Defender for Endpoint unter Linux.

  2. Sammeln Sie ein Debugdiagnosepaket, wenn Defender für Endpunkt hohe Ressourcen nutzt, indem Sie die folgenden Anweisungen verwenden: Microsoft Defender for Endpoint für Linux-Ressourcen.

Behandeln von Leistungsproblemen

Wenn Sie eine Erhöhung des Ressourcenverbrauchs durch Microsoft Defender auf Ihren Endpunkten feststellen, ist es wichtig, den Prozess/Bereitstellungspunkt/die Dateien zu identifizieren, die die meiste CPU-/Arbeitsspeicherauslastung verbrauchen, und dann erforderliche Ausschlüsse anzuwenden. Wenn wdavdaemon (übergeordneter Prozess) die Ressourcen nach dem Anwenden möglicher AV-Ausschlüsse noch verbraucht, verwenden Sie den Befehl ebpf-statistics, um die höchste Anzahl von Systemaufrufen abzurufen:

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

In der obigen Ausgabe sehen Sie, dass stress-ng der wichtigste Prozess ist, der eine große Anzahl von Ereignissen generiert und zu Leistungsproblemen führen kann. Höchstwahrscheinlich generiert stress-ng den Systemaufruf mit der ID 82. Sie können ein Ticket bei Microsoft erstellen, um diesen Prozess auszuschließen. In Zukunft haben Sie im Rahmen der anstehenden Verbesserungen mehr Kontrolle, um solche Ausschlüsse an Ihrem Ende anzuwenden.

Ausschlüsse, die auf überwacht angewendet werden, können nicht in eBPF migriert oder kopiert werden. Häufige Probleme wie noisy logs, kernel panic, noisy syscalls werden bereits intern von eBPF erledigt. Falls Sie weitere Ausschlüsse hinzufügen möchten, wenden Sie sich an Microsoft, um die erforderlichen Ausschlüsse anzuwenden.

Siehe auch