Freigeben über

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

  • Artikel

Hinweis

Ab Defender für Endpunkt unter Linux, Version 101.2408.0000, wird AuditD nicht mehr als ergänzender Ereignisanbieter unterstützt. Weitere Informationen finden Sie in den häufig gestellten Fragen am Ende dieses Artikels.

Der erweiterte Berkeley Packet Filter (eBPF) für Microsoft Defender for Endpoint unter Linux stellt ergänzende Ereignisdaten für Linux-Betriebssysteme bereit. eBPF hilft bei der Behebung mehrerer Klassen von Problemen, die mit dem AuditD-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 AuditD-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. eBPF trägt dazu bei, die Wahrscheinlichkeit von Konflikten zwischen Anwendungen zu verringern, da keine benutzerdefinierten Regeln erforderlich sind. 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.

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

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 Agent-Versionen 101.23082.0006 und höher aktiviert. Kunden müssen auf eine unterstützte Version 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 oder in dem Fall, dass eBPF für einen bestimmten Kernel nicht unterstützt wird, wechselt der ergänzende Ereignisanbieter zu Netlink. Alle Prozessvorgänge werden weiterhin nahtlos ausgeführt, aber Sie können bestimmte datei- und socketbezogene Ereignisse verpassen, die eBPF andernfalls erfassen würde.

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. Wechseln Sie unter Erweiterte Suche zu Defender Vulnerability Management.

  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. Diese Anforderung ist eine Einschränkung im unveränderlichen Modus von AuditD, 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 vorherigen 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 Sie 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 AuditD-Modus, 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. Die Kernel-Mindestversion für Oracle Linux ist RHCK 3.10.0 und Oracle Linux UEK 5.4.
    • Wechseln Sie in den AuditD-Modus, 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 einen erhöhten Ressourcenverbrauch durch Microsoft Defender auf Ihren Endpunkten feststellen, ist es wichtig, den Prozess/Bereitstellungspunkt/die Dateien zu identifizieren, die den Großteil der CPU-/Arbeitsspeicherauslastung verursachen. Anschließend können Sie die erforderlichen Ausschlüsse anwenden. Verwenden Sie nach dem Anwenden möglicher Antivirenausschlüsse, wenn wdavdaemon (übergeordneter Prozess) die Ressourcen immer noch verbraucht, 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 vorherigen Ausgabe können Sie sehen, 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 AuditD 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.

Häufig gestellte Fragen : Übergang zu eBPF

1. Warum sollten Sie die Umstellung auf eBPF in Betracht ziehen?

Der erweiterte Berkeley Packet Filter (eBPF) für Microsoft Defender for Endpoint unter Linux dient als effiziente Alternative zu AuditD und löst verschiedene Herausforderungen im Zusammenhang mit dem AuditD-Ereignisanbieter und bietet gleichzeitig erhebliche Vorteile in Bezug auf Leistung und Systemstabilität. Zu den wichtigsten Vorteilen gehören :

  • Leistung: eBPF verbessert die Leistung erheblich, indem der Mehraufwand für Systemressourcen im Vergleich zu AuditD reduziert wird.

  • Ressourceneffizienz: eBPF verwendet weniger Ressourcen, was dazu beiträgt, die Systemstabilität auch bei hohen Lastbedingungen aufrechtzuerhalten.

  • Skalierbarkeit: Die eBPF-Architektur ist skalierbarer, sodass es eine bessere Wahl für Umgebungen mit wachsenden oder komplexen Workloads ist.

  • Moderne Technologie: eBPF stellt eine moderne, zukunftsorientierte Technologie dar, die sich an zukünftigen Linux-Kernelentwicklungen orientiert und eine bessere langfristige Unterstützung gewährleistet.

2. Wie kann ich AuditD weiterhin verwenden?

Wenn Sie AuditD weiterhin verwenden möchten:

  • Unterstützte Versionen: Sie können Defender für Endpunkt unter Linux, Version 101.24072.0000, beibehalten, die AuditD während der Gültigkeitsdauer des Builds unterstützt, die ungefähr neun Monate beträgt. Dies bietet einen ausreichenden Übergangszeitraum, um Ihren Wechsel zu eBPF zu planen. Das Ablaufdatum kann durch Ausführen des Befehls mdatp health auf dem Linux-Server überprüft werden.

  • Long-Term Plan: Obwohl es eine Option ist, den 101.24072.0000 Build zu verwenden, empfehlen wir, Ihren Übergang zu eBPF innerhalb dieses Zeitrahmens zu planen, um sicherzustellen, dass Sie von den neuesten Sicherheits- und Leistungsverbesserungen profitieren und auch weiterhin Support erhalten.

Es empfiehlt sich jedoch, eine Umstellung auf die Verwendung von eBPF als primären Ereignisanbieter zu planen.

3. Was geschieht, wenn eBPF in einigen Szenarien nicht unterstützt wird?

In Fällen, in denen eBPF nicht unterstützt wird:

  • Netlink-Fallback: Das System greift auf die Verwendung des Netlink-Ereignisanbieters zurück. Netlink erfasst zwar weiterhin Prozessereignisse (z. B exec. , exit, fork, gidoder tid), unterstützt jedoch keine Dateisystemereignisse (z. B rename. , unlink) oder Socketereignisse.

  • Auswirkung: Ihre Workloads werden nicht unterbrochen, aber Sie könnten bestimmte datei- und socketbezogene Ereignisse verpassen, die eBPF andernfalls erfassen würde.

4. Wie kann ich Ausschlüsse mit den aktualisierten Versionen verwalten?

Im Folgenden finden Sie einige häufige Gründe für das Platzieren von Ausschlüssen für AuditD:

  • Leistung, da einige Syscalls oder Prozesse viel Rauschen erzeugen

  • Kernel panic, es gibt Zeiten, in denen viele Syscalls speziell Netzwerk-/Dateisystemaufrufe zu Kernel panic geführt haben.

  • Verrauschte Protokolle, bei denen Überwachungsprotokolle den Speicherplatz belegen. Der Kunde hat die Ausschlüsse für die lauten Prozesse platziert, um die Protokollgröße zu reduzieren.

Bei eBPF sind die ersten beiden Anwendungsfälle die Kandidaten für die Migration. Protokolle sind bei eBPF kein Problem mehr. Für die ersten beiden Anwendungsfälle können Sie eine der folgenden Optionen auswählen:

  • Wenden Sie sich an den Support: Wenden Sie sich an Microsoft, um die Ausschlüsse aus dem Back-End anzuwenden.

  • Globale Ausschlüsse: In den aktualisierten Versionen von Defender für Endpunkt unter Linux können Ausschlüsse mit globalen Ausschlüssen verwaltet werden. Globale Ausschlüsse gelten sowohl für Antivirensoftware als auch für EDR und können derzeit über den verwalteten JSON-Code konfiguriert werden. Weitere Informationen finden Sie unter Konfigurieren und Überprüfen von Ausschlüssen für Microsoft Defender für Endpunkt unter Linux.

5. Was sollte ich tun, wenn Probleme auftreten?

  • Support kontaktieren: Wenn während oder nach der Umstellung auf eBPF Probleme auftreten, wenden Sie sich an den technischen Support, um Unterstützung zu erhalten. Wir sind bestrebt, einen reibungslosen Übergang zu gewährleisten und stehen zur Verfügung, um alle Herausforderungen zu lösen, denen Sie begegnen können.

  • Supportkanäle: Sie können den Support über das Microsoft Defender-Portal kontaktieren. Darüber hinaus sind unsere Wissensdatenbank- und Communityforen wertvolle Ressourcen für die Behandlung häufiger Probleme.

Siehe auch