Udostępnij za pośrednictwem

Używanie czujnika opartego na platformie eBPF do Ochrona punktu końcowego w usłudze Microsoft Defender w systemie Linux

  • Artykuł

Dotyczy:

Uwaga

Począwszy od usługi Defender for Endpoint w systemie Linux, wersja 101.2408.0000, funkcja AuditD nie jest już obsługiwana jako dostawca zdarzeń uzupełniających. Aby uzyskać więcej informacji, zobacz często zadawane pytania na końcu tego artykułu.

Rozszerzony filtr pakietów Berkeley (eBPF) dla Ochrona punktu końcowego w usłudze Microsoft Defender w systemie Linux udostępnia dodatkowe dane zdarzeń dla systemów operacyjnych Linux. eBPF pomaga rozwiązać kilka klas problemów występujących z dostawcą zdarzeń AuditD i jest korzystne w obszarach wydajności i stabilności systemu.

Najważniejsze korzyści to:

  • Zmniejszenie szumu dziennika związanego z inspekcją w całym systemie
  • Zoptymalizowane reguły zdarzeń dla całego systemu w przeciwnym razie powodują konflikt między aplikacjami
  • Mniejsze obciążenie związane z monitorowaniem zdarzeń pliku (odczyt/otwieranie pliku)
  • Ulepszona przepływność szybkości zdarzeń i mniejsze zużycie pamięci
  • Zoptymalizowana wydajność dla określonych konfiguracji

Jak działa eBPF

W przypadku eBPF zdarzenia uzyskane wcześniej od dostawcy zdarzeń AuditD są teraz przepływane z czujnika eBPF. Pomaga to w stabilności systemu, poprawia wykorzystanie procesora CPU i pamięci oraz zmniejsza użycie dysku. eBPF pomaga zmniejszyć możliwość konfliktów między aplikacjami, ponieważ nie są wymagane żadne reguły niestandardowe. Dane związane z eBPF są rejestrowane w pliku /var/log/microsoft/mdatp/microsoft_defender_core.log.

Ponadto czujnik eBPF korzysta z możliwości jądra systemu Linux bez konieczności korzystania z modułu jądra, który pomaga zwiększyć stabilność systemu.

Wymagania wstępne systemu

Czujnik eBPF dla Ochrona punktu końcowego w usłudze Microsoft Defender w systemie Linux jest obsługiwany w następujących minimalnych wersjach dystrybucji i jądra:

Dystrybucja systemu Linux Wersja dystrybucji Wersja jądra
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

Uwaga

Oracle Linux 8.8 z jądrem w wersji 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 spowoduje zawieszenie jądra, gdy eBPF jest włączony jako dostawca dodatkowego podsystemu. Ta wersja jądra nie powinna być używana w trybie eBPF. Zapoznaj się z sekcją Rozwiązywanie problemów i diagnostyka, aby uzyskać informacje o krokach ograniczania ryzyka.

Korzystanie z eBPF

Czujnik eBPF jest automatycznie włączany dla wszystkich klientów domyślnie dla wersji agenta i nowszych 101.23082.0006 . Aby korzystać z tej funkcji, klienci muszą zaktualizować ją do obsługiwanej wersji. Po włączeniu czujnika eBPF w punkcie końcowym usługa Defender for Endpoint w systemie Linux aktualizuje supplementary_events_subsystem ebpf.

Wyróżnienie podsystemu ebpf w poleceniu mdatp health

Jeśli chcesz ręcznie wyłączyć eBPF, możesz uruchomić następujące polecenie:

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

Możesz również zaktualizować plik mdatp_managed.json:

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

Zapoznaj się z linkiem, aby uzyskać szczegółowy przykładowy plik json — ustawianie preferencji dla Ochrona punktu końcowego w usłudze Microsoft Defender w systemie Linux.

Ważna

Jeśli wyłączysz eBPF lub w przypadku, gdy eBPF nie jest obsługiwany na żadnym konkretnym jądrze, dostawca zdarzeń uzupełniających przełącza się do usługi Netlink. Wszystkie operacje procesu będą nadal bezproblemowo przepływać, ale możesz przegapić określone zdarzenia związane z plikami i gniazdami, które w przeciwnym razie przechwyciłby eBPF.

Możesz również sprawdzić stan eBPF (włączone/wyłączone) w punktach końcowych systemu Linux przy użyciu zaawansowanego wyszukiwania zagrożeń w portalu Microsoft Defender. Kroki są następujące:

  1. Przejdź do portalu Microsoft Defender i zaloguj się.

  2. W okienku nawigacji przejdź do pozycji Wyszukiwanie zagrożeń zaawansowanych>.

  3. W obszarze Zaawansowane wyszukiwanie zagrożeń przejdź do Zarządzanie lukami w zabezpieczeniach w usłudze Defender.

  4. Uruchom następujące zapytanie: DeviceTvmInfoGathering.

  5. W danych wyjściowych w kolumnie Dodatkowe pola wybierz pozycję Pokaż więcej, a następnie poszukaj pola EBPF STATUS: true.

Tryb niezmienny auditD

W przypadku klientów korzystających z funkcji AuditD w trybie niezmiennym po włączeniu eBPF wymagane jest ponowne uruchomienie, aby wyczyścić reguły inspekcji dodane przez Ochrona punktu końcowego w usłudze Microsoft Defender. To wymaganie jest ograniczeniem niezmiennego trybu AuditD, który blokuje plik reguł i uniemożliwia edytowanie/zastępowanie. Ten problem został rozwiązany podczas ponownego uruchamiania.

Po ponownym uruchomieniu uruchom następujące polecenie, aby sprawdzić, czy reguły inspekcji zostały wyczyszczone:

% sudo auditctl -l

Dane wyjściowe poprzedniego polecenia nie powinny zawierać żadnych reguł ani reguł dodanych przez użytkownika. W przypadku, gdy reguły nie zostały usunięte, wykonaj następujące kroki, aby wyczyścić plik reguł inspekcji:

  1. Przełącz się do trybu ebpf.
  2. Usuń plik /etc/audit/rules.d/mdatp.rules.
  3. Uruchom ponownie maszynę.

Rozwiązywanie problemów i diagnostyka

Stan kondycji agenta można sprawdzić, uruchamiając polecenie kondycji mdatp . Upewnij się, że czujnik eBPF dla usługi Defender dla punktu końcowego w systemie Linux jest obsługiwany przez sprawdzenie bieżącej wersji jądra przy użyciu następującego wiersza polecenia:

uname -a

Znane problemy

  1. Włączenie eBPF w wersji RHEL 8.1 z oprogramowaniem SAP może spowodować panikę jądra. Aby rozwiązać ten problem, możesz wykonać jeden z następujących kroków:

    • Użyj wersji dystrybucji wyższej niż RHEL 8.1.
    • Przełącz się do trybu AuditD, jeśli musisz użyć wersji RHEL 8.1.

  2. Korzystanie z systemu Oracle Linux 8.8 z jądrem w wersji 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 może spowodować panikę jądra. Aby rozwiązać ten problem, możesz wykonać jeden z następujących kroków:

    • Użyj jądra w wersji wyższej lub niższej niż 5.15.0-0.30.20.el8uek.x86_64, 5.15.0-0.30.20.1.el8uek.x86_64 w systemie Oracle Linux 8.8, jeśli chcesz użyć eBPF jako dodatkowego dostawcy podsystemu. Minimalna wersja jądra dla systemu Oracle Linux to RHCK 3.10.0, a oracle Linux UEK to 5.4.
    • Przełącz się do trybu AuditD, jeśli musisz użyć tej samej wersji jądra
sudo mdatp config  ebpf-supplementary-event-provider  --value disabled

Poniższe dwa zestawy danych pomagają analizować potencjalne problemy i określać najbardziej efektywne opcje rozwiązywania problemów.

  1. Zbierz pakiet diagnostyczny z narzędzia analizatora klienta, korzystając z następujących instrukcji: Rozwiązywanie problemów z wydajnością Ochrona punktu końcowego w usłudze Microsoft Defender w systemie Linux.

  2. Zbierz pakiet diagnostyczny debugowania, gdy usługa Defender for Endpoint korzysta z wysokich zasobów, korzystając z następujących instrukcji: Ochrona punktu końcowego w usłudze Microsoft Defender na zasobach systemu Linux.

Rozwiązywanie problemów z wydajnością

Jeśli widzisz zwiększone zużycie zasobów przez Microsoft Defender w punktach końcowych, ważne jest, aby zidentyfikować proces/punkt instalacji/pliki, które powodują większość użycia procesora CPU/pamięci. Następnie można zastosować niezbędne wykluczenia. Jeśli po zastosowaniu możliwych wykluczeń antywirusowych wdavdaemon (proces nadrzędny) nadal używa zasobów, użyj polecenia ebpf-statistics, aby uzyskać najwyższą liczbę wywołań systemowych:

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

W poprzednich danych wyjściowych widać, że stress-ng jest głównym procesem generującym dużą liczbę zdarzeń i może powodować problemy z wydajnością. Najprawdopodobniej stress-ng generuje wywołanie systemowe o identyfikatorze 82. Aby wykluczyć ten proces, możesz utworzyć bilet w firmie Microsoft. W przyszłości w ramach nadchodzących ulepszeń masz większą kontrolę nad stosowaniem takich wykluczeń na końcu.

Nie można migrować ani kopiować wykluczeń stosowanych do funkcji AuditD do platformy eBPF. Typowe problemy, takie jak hałaśliwe dzienniki, panika jądra, hałaśliwe syscalls, są już wewnętrznie obsługiwane przez eBPF. Jeśli chcesz dodać kolejne wykluczenia, skontaktuj się z firmą Microsoft, aby zastosować niezbędne wykluczenia.

Często zadawane pytania — przejście do eBPF

1. Dlaczego warto rozważyć przejście do eBPF?

Rozszerzony filtr pakietów Berkeley (eBPF) dla Ochrona punktu końcowego w usłudze Microsoft Defender w systemie Linux służy jako wydajna alternatywa dla inspekcji i rozwiązuje różne wyzwania związane z dostawcą zdarzeń AuditD, zapewniając jednocześnie znaczące korzyści pod względem wydajności i stabilności systemu. Niektóre z kluczowych korzyści to:

  • Wydajność: eBPF znacznie zwiększa wydajność, zmniejszając obciążenie zasobów systemowych w porównaniu z auditD.

  • Efektywność zasobów: eBPF zużywa mniej zasobów, co pomaga utrzymać stabilność systemu nawet w warunkach dużego obciążenia.

  • Skalowalność: architektura eBPF jest bardziej skalowalna, co czyni ją lepszym wyborem dla środowisk z rosnącymi lub złożonymi obciążeniami.

  • Nowoczesna technologia: eBPF reprezentuje nowoczesną, przyszłościową technologię, która jest zgodna z przyszłymi zmianami jądra systemu Linux, zapewniając lepszą długoterminową obsługę.

2. Jak mogę nadal używać funkcji AuditD?

Jeśli wolisz kontynuować korzystanie z funkcji AuditD:

  • Obsługiwane wersje: możesz pozostać w usłudze Defender for Endpoint w systemie Linux w wersji 101.24072.0000, która będzie obsługiwać funkcję AuditD podczas ważności kompilacji, która wynosi około dziewięciu miesięcy. Zapewnia to wystarczający okres przejściowy, aby zaplanować przejście do eBPF. Datę wygaśnięcia można sprawdzić, uruchamiając polecenie mdatp health na serwerze z systemem Linux.

  • Long-Term Plan: Podczas pozostawania w 101.24072.0000 kompilacji jest opcja, zalecamy planowanie przejścia do eBPF w tym przedziale czasu, aby zapewnić korzyści z najnowszych ulepszeń zabezpieczeń i wydajności, a także uzyskać dalszą pomoc techniczną.

Mimo to zalecamy zaplanowanie przejścia do korzystania z eBPF jako podstawowego dostawcy zdarzeń.

3. Co się stanie, jeśli eBPF nie jest obsługiwany w niektórych scenariuszach?

W przypadkach, gdy eBPF nie jest obsługiwany:

  • Netlink Fallback: system powraca do korzystania z dostawcy zdarzeń Netlink. Mimo że usługa Netlink nadal przechwytuje zdarzenia procesu (na przykład , exec, forkexit, , gidlub tid), nie obsługuje zdarzeń związanych z systemem plików (na przykład rename, unlink) lub zdarzeń gniazda.

  • Wpływ: Obciążenia nie zostaną zakłócone, ale można pominąć określone zdarzenia związane z plikami i gniazdami, które w przeciwnym razie przechwyciłby eBPF.

4. Jak mogę zarządzać wykluczeniami za pomocą zaktualizowanych wersji?

Poniżej przedstawiono niektóre typowe przyczyny umieszczania wykluczeń dla funkcji AuditD:

  • Wydajność, ponieważ niektóre wywołanie lub proces generuje dużo szumu

  • Panika jądra, istnieją czasy, w których wiele wywołań syscalls w szczególności sieci/ systemu plików spowodowało panikę jądra.

  • Hałaśliwe dzienniki, w których dzienniki inspekcji wykorzystują miejsce na dysku. Klient umieścił wykluczenia dla hałaśliwych procesów w celu zmniejszenia rozmiaru dziennika.

W przypadku eBPF pierwsze dwa przypadki użycia są kandydatami do migracji. Dzienniki nie są już problemem z platformą eBPF. W przypadku pierwszych dwóch przypadków użycia można wybrać następujące opcje:

  • Skontaktuj się z pomocą techniczną: skontaktuj się z firmą Microsoft, aby zastosować wykluczenia z zaplecza.

  • Wykluczenia globalne: w zaktualizowanych wersjach usługi Defender for Endpoint w systemie Linux wykluczeniami można zarządzać za pomocą wykluczeń globalnych. Globalne wykluczenia mają zastosowanie zarówno do oprogramowania antywirusowego, jak i EDR i mogą być obecnie konfigurowane za pośrednictwem zarządzanego pliku json. Aby uzyskać więcej informacji, zobacz Konfigurowanie i weryfikowanie wykluczeń usługi Ochrona punktu końcowego w usłudze Microsoft Defender w systemie Linux.

5. Co należy zrobić w przypadku wystąpienia problemów?

  • Skontaktuj się z pomocą techniczną: Jeśli podczas przejścia do platformy eBPF lub po niej wystąpią problemy, skontaktuj się z pomocą techniczną w celu uzyskania pomocy. Dokładamy wszelkich starań, aby zapewnić płynne przejście i jesteśmy dostępni, aby pomóc w rozwiązywaniu wszelkich wyzwań, przed którymi możesz się zmierzyć.

  • Kanały pomocy technicznej: możesz skontaktować się z pomocą techniczną za pośrednictwem portalu Microsoft Defender. Ponadto nasze fora baza wiedzy i społeczności są cennymi zasobami do rozwiązywania typowych problemów.

Zobacz też