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

  • Gilt für:: Microsoft Defender for Endpoint Plan 1, Microsoft Defender for Endpoint Plan 2

Hinweis

Ab Version 101.2408.0000 von Defender for Endpoint unter Linux wird AuditD nicht mehr als zusätzlicher Ereignisanbieter unterstützt. Weitere Informationen finden Sie unter FAQs – Übergang zu eBPF.

Der erweiterte Berkeley Packet Filter (eBPF) für Microsoft Defender for Endpoint auf 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 zu Konflikten zwischen Anwendungen führen
  • 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 erfordert den Agent für Defender for Endpoint unter Linux in Version 101.23082.0006 oder höher. Stellen Sie sicher, dass Ihr Endpunkt auf eine unterstützte Agentversion aktualisiert wird, bevor Sie fortfahren.

Der eBPF-Sensor wird für die folgenden Mindestverteilungs- und Kernelversionen unterstützt:

Linux Verteilung Distributionsversion 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. Informationen zu Abhilfemaßnahmen finden Sie im Abschnitt Fehlerbehebung und Diagnose.

Aktivieren und Konfigurieren des eBPF-Sensors

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 auf Linux supplementary_events_subsystem auf ebpf.

Ebpf-Subsystem:Hervorhebung im Befehl

Um den ergänzenden eBPF-Ereignisanbieter zu aktivieren oder zu deaktivieren, führen Sie den folgenden Befehl aus:

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

Alternativ können Sie den zusätzlichen eBPF-Ereignisanbieter deaktivieren, indem Sie ebpfSupplementaryEventProvider in der Datei mdatp_managed.json auf disabled festlegen:

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

Eine detaillierte JSON-Beispieldatei finden Sie unter "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 Hunting>Erweiterte Suche.

  3. Navigieren 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. Ein Neustart entfernt die Microsoft Defender for Endpoint-Überwachungsregeln, die nicht entfernt werden können, wenn AuditD im unveränderlichen Modus ausgeführt wird.

Führen Sie nach dem Neustart die aktuellen AuditD-Regeln auf, um zu bestätigen, dass die Defender für Endpunktüberwachungsregeln erfolgreich 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 den Zustand des Agenten überprüfen, indem Sie den Befehl mdatp health ausführen. Um zu überprüfen, ob Ihre Kernelversion die in den Systemvoraussetzungen aufgeführten eBPF-Sensoranforderungen erfüllt, überprüfen Sie die aktuelle Kernelversion, indem Sie den folgenden Befehl ausführen:

uname -a

Bekannte Probleme

Beachten Sie die folgenden bekannten Probleme bei der Verwendung des eBPF-Sensors unter Linux:

  1. Warnung: Auf RHEL 8.1 mit SAP kann die Aktivierung von eBPF zu einer Kernel-Panik führen. Bevor Sie eBPF für diese Konfiguration aktivieren, führen Sie einen der folgenden Gegenmaßnahmen aus:

    • 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 ein Diagnosepaket aus dem Clientanalysetool, indem Sie die folgenden Anweisungen verwenden: Behandeln von Leistungsproblemen für Microsoft Defender for Endpoint auf Linux.

      2. Sammeln Sie ein Debug-Diagnosepaket, wenn Defender for Endpoint eine hohe Ressourcenauslastung verursacht, indem Sie die folgenden Anweisungen befolgen: Ressourcen zu Microsoft Defender for Endpoint unter Linux.

  3. Das System hängt auf Oracle Linux 7.9, das Defender für Linux ausführt, wenn ksplice für das Live-Kernelpatching verwendet wird.

    • Durch die automatische Installation von Patchen von ksplice wird dem Endpunkt einfach ein Cron-Auftrag hinzugefügt.
    • Um das Problem des Hängenbleibens zu beheben, können Sie einen Cron-Auftrag erstellen, der zuerst den mdatp-Dienst beendet, ksplice-basiertes Patching anwendet und dann den Dienst startet.
    • Da das Einspielen von Kernel-Patches nur wenige Sekunden dauert, stellt dies kein großes Sicherheitsrisiko dar.

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

Die folgende Beispielausgabe zeigt die eBPF-Statistiken, die über ein 20-Sekunden-Überwachungsintervall gesammelt wurden, einschließlich der wichtigsten Dateipfade, Initiatorprozesse und Systemaufruf-IDs:

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 mdatp diagnostic ebpf-statistics Ausgabe ist Stress-ng der oberste Prozess, 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.

Ausschlüsse, die auf AuditD angewendet werden, können nicht in eBPF migriert oder kopiert werden. Typische Probleme wie verrauschte Protokolle, Kernel Panic und störende Systemaufrufe werden intern von eBPF bereits behandelt. 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 auf 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 auf 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 den Netlink-Ereignisanbieter 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: Mitunter kam es vor, dass viele Systemaufrufe, insbesondere Netzwerk- und Dateisystemaufrufe, eine Kernel Panic auslösten.

  • 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 auf 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.

Verwandte Inhalte

Weitere Informationen zur Problembehandlung und Ressourcenverwaltung für Defender für Endpunkt unter Linux finden Sie in den folgenden Artikeln:

  • Last updated on