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

  • Artykuł

Dotyczy:

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 może służyć jako alternatywna technologia do inspekcji, ponieważ eBPF pomaga rozwiązać kilka klas problemów występujących u dostawcy zdarzeń poddanych inspekcji i jest korzystna w dziedzinie 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ń z inspekcji są teraz przesyłane z czujnika eBPF. Pomaga to w stabilności systemu, poprawia wykorzystanie procesora CPU i pamięci oraz zmniejsza użycie dysku. Ponadto po włączeniu eBPF wszystkie reguły niestandardowe związane z inspekcją są eliminowane, co pomaga zmniejszyć możliwość konfliktów między aplikacjami. 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.

Uwaga

eBPF jest używany w połączeniu z inspekcją, natomiast inspekcja jest używana tylko w przypadku zdarzeń logowania użytkownika i przechwytuje te zdarzenia bez żadnych reguł niestandardowych i przepływa je automatycznie. Należy pamiętać, że inspekcja będzie stopniowo usuwana w przyszłych wersjach.

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

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 domyślnie automatycznie włączany dla wszystkich klientów dla wersji agenta "101.23082.0006" i nowszych. Klienci muszą zaktualizować tę funkcję do wyżej wymienionych obsługiwanych 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, dostawca zdarzeń uzupełniających przełączy się z powrotem do inspekcji. Jeśli platforma eBPF nie zostanie włączona lub nie będzie obsługiwana na żadnym konkretnym jądrze, automatycznie przełączy się z powrotem do inspekcji i zachowa wszystkie reguły niestandardowe z inspekcją.

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 obszaru Zarządzanie lukami w zabezpieczeniach usługi 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 inspekcji

W przypadku klientów korzystających z inspekcji 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. Jest to ograniczenie niezmienialnego trybu inspekcji, które blokuje plik reguł i uniemożliwia edytowanie/zastępowanie. Ten problem został rozwiązany podczas ponownego uruchamiania. Po ponownym uruchomieniu uruchom poniższe polecenie, aby sprawdzić, czy reguły inspekcji zostały wyczyszczone.

% sudo auditctl -l

Dane wyjściowe powyższego polecenia nie powinny zawierać żadnych reguł ani żadnych reguł dodanych przez użytkownika. Jeśli reguły nie zostaną usunięte, wykonaj następujące kroki, aby wyczyścić plik reguł inspekcji.

  1. Przełącz do trybu ebpf
  2. Usuń plik /etc/audit/rules.d/mdatp.rules
  3. Ponowne uruchamianie maszyny

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 inspekcji, 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. Należy pamiętać, że 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 inspekcji, 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 wzrost zużycia zasobów przez Microsoft Defender w punktach końcowych, ważne jest, aby zidentyfikować proces/punkt instalacji/pliki, które zużywają najwięcej użycia procesora CPU/pamięci, a następnie zastosować niezbędne wykluczenia. Po zastosowaniu możliwych wykluczeń AV, jeśli wdavdaemon (proces nadrzędny) nadal korzysta z 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 powyższych 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.

Wykluczeń stosowanych do inspekcji nie można migrować ani kopiować do 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.

Zobacz też