Korzystanie z sensora opartego na eBPF dla Ochrona punktu końcowego w usłudze Microsoft Defender w systemie Linux

Uwaga

Począwszy od wersji 101.2408.0000 usługi Defender for Endpoint dla systemu Linux, AuditD nie jest już obsługiwany jako dodatkowy dostawca zdarzeń. Aby uzyskać więcej informacji, zobacz Często zadawane pytania — przejście do eBPF.

Rozszerzony filtr pakietów Berkeley (eBPF) dla usługi Microsoft Defender dla punktu końcowego w systemie Linux zapewnia dodatkowe dane o zdarzeniach 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:

  • Ograniczenie ogólnosystemowego nadmiaru wpisów w dziennikach związanych z AuditD
  • 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)
  • Zwiększono przepustowość przetwarzania zdarzeń i zmniejszono 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 wykorzystuje możliwości jądra Linux bez konieczności używania modułu jądra, który pomaga zwiększyć stabilność systemu.

Wymagania wstępne systemu

Czujnik eBPF wymaga agenta usługi Defender for Endpoint dla systemu Linux w wersji 101.23082.0006 lub nowszej. Przed kontynuowaniem upewnij się, że punkt końcowy został zaktualizowany do obsługiwanej wersji agenta.

Czujnik eBPF jest obsługiwany w następujących minimalnych wersjach dystrybucji i jądra:

dystrybucja 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ć instrukcje ograniczania ryzyka.

Włączanie i konfigurowanie czujnika eBPF

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

Wyróżnienie podsystemu ebpf w poleceniu mdatp health

Aby włączyć lub wyłączyć dodatkowego dostawcę zdarzeń eBPF, uruchom następujące polecenie:

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

Alternatywnie możesz wyłączyć dodatkowego dostawcę zdarzeń eBPF, ustawiając wartość ebpfSupplementaryEventProvider na disabled w pliku mdatp_managed.json:

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

Aby uzyskać szczegółowy przykładowy plik JSON, zobacz 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) na punktach końcowych z systemem Linux za pomocą 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ń>Wyszukiwanie zagrożeń zaawansowane.

  3. W obszarze Zaawansowane wyszukiwanie zagrożeń przejdź do Zarządzanie lukami w zabezpieczeniach w usłudze Microsoft 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.

Niezmienialny tryb AuditD

W przypadku klientów korzystających z funkcji AuditD w trybie immutable po włączeniu eBPF wymagane jest ponowne uruchomienie systemu, aby usunąć reguły inspekcji dodane przez Ochrona punktu końcowego w usłudze Microsoft Defender. To wymaganie wynika z ograniczenia trybu niezmiennego w AuditD, który zamraża plik reguł i uniemożliwia jego edytowanie lub nadpisywanie. Ponowne uruchomienie powoduje wyczyszczenie reguł inspekcji Ochrona punktu końcowego w usłudze Microsoft Defender, których nie można usunąć, gdy funkcja AuditD jest w trybie niezmiennym.

Po ponownym uruchomieniu wyświetl listę bieżących reguł AuditD, aby potwierdzić, że reguły inspekcji usługi Defender for Endpoint zostały pomyślnie 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

Możesz sprawdzić stan agenta, uruchamiając polecenie mdatp health. Aby sprawdzić, czy wersja jądra spełnia wymagania czujnika eBPF wymienione w temacie Wymagania wstępne systemu, sprawdź bieżącą wersję jądra, uruchamiając następujące polecenie:

uname -a

Znane problemy

Podczas korzystania z czujnika eBPF w systemie Linux należy pamiętać o następujących znanych problemach:

  1. Ostrzeżenie: W systemie RHEL 8.1 z SAP włączenie eBPF może spowodować awarię jądra. Przed włączeniem protokołu eBPF w tej konfiguracji wykonaj jedną z następujących czynności zaradczych:

    • 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 programie Oracle Linux 8.8, jeśli chcesz użyć eBPF jako dostawcy dodatkowego podsystemu. Minimalna wersja jądra dla Oracle Linux to RHCK 3.10.0, a dla Oracle Linux UEK — 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 za pomocą narzędzia Client Analyzer, korzystając z następujących instrukcji: Rozwiązywanie problemów z wydajnością usługi Ochrona punktu końcowego w usłudze Microsoft Defender w systemie Linux.

      2. Zbierz pakiet diagnostyczny do debugowania, gdy Ochrona punktu końcowego w usłudze Microsoft Defender zużywa dużo zasobów, korzystając z następujących instrukcji: Zasoby dotyczące Ochrona punktu końcowego w usłudze Microsoft Defender w systemie Linux.

  3. System zawiesza się w systemie Oracle Linux 7.9 z uruchomionym Defender for Linux, gdy narzędzie Ksplice jest używane do dynamicznego łatania jądra.

    • Automatyczne instalowanie poprawek narzędzia Ksplice po prostu dodaje zadanie cron na urządzeniu końcowym.
    • Aby rozwiązać problem z zawieszaniem, możesz utworzyć zadanie cron, które najpierw zatrzyma usługę mdatp, zastosuje stosowanie poprawek opartych na technologii ksplice, a następnie uruchomi usługę.
    • Ponieważ stosowanie poprawek jądra trwa kilka sekund, więc nie będzie to miało dużego narażenia pod względem bezpieczeństwa.

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

Następujące przykładowe dane wyjściowe pokazują statystyki eBPF zebrane w 20-sekundowym interwale monitorowania, w tym główne ścieżki plików, procesy inicjatora i identyfikatory wywołań systemowych:

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

mdatp diagnostic ebpf-statistics W danych wyjściowych 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.

Nie można migrować ani kopiować wykluczeń stosowanych do funkcji AuditD do platformy eBPF. Typowe problemy, takie jak nadmiarowe logi, awarie jądra i nadmiarowe wywołania systemowe, są już obsługiwane wewnętrznie 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 usługi Ochrona punktu końcowego w usłudze Microsoft Defender w systemie Linux stanowi wydajną alternatywę dla AuditD i eliminuje różne problemy 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 to nowoczesna technologia zorientowana na przyszłość, zgodna z przyszłym rozwojem jądra Linux, zapewniająca lepsze długoterminowe wsparcie.

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

  • Plan długoterminowy: Choć pozostanie przy kompilacji 101.24072.0000 jest możliwe, zalecamy zaplanowanie przejścia na eBPF w tym okresie, aby skorzystać z najnowszych usprawnień w zakresie bezpieczeństwa i wydajności, a także zapewnić sobie dalsze wsparcie.

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 przełącza się z powrotem na dostawcę zdarzeń Netlink. Mimo że usługa Netlink nadal przechwytuje zdarzenia procesu (na przykład , exec, exitfork, , gidlub tid), nie obsługuje zdarzeń związanych z systemem plików (na przykład rename, unlink) lub zdarzeń gniazda.

  • Wpływ: Twoje obciążenia robocze nie zostaną zakłócone, ale możesz nie zarejestrować określonych zdarzeń związanych z plikami i gniazdami, które w przeciwnym razie zarejestrował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 systemowe lub proces powoduje duże zakłócenia

  • Panika jądra — zdarza się, że wiele wywołań systemowych, zwłaszcza wywołań sieciowych i związanych z systemem plików, powodowało panikę jądra.

  • Nadmiernie rozbudowane dzienniki, w przypadku których dzienniki audytu zajmują miejsce na dysku. Klient umieścił wykluczenia dla hałaśliwych procesów w celu zmniejszenia rozmiaru dziennika.

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

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 nasza baza wiedzy i fora społeczności są cennymi źródłami pomocnymi w rozwiązywaniu typowych problemów.

Aby uzyskać więcej informacji na temat rozwiązywania problemów i zarządzania zasobami dla Defender dla punktu końcowego w systemie Linux, zobacz następujące artykuły: