在 Linux 上針對適用於適用於端點的 Microsoft Defender 使用 eBPF 型感應器

適用於 Linux 上 適用於端點的 Microsoft Defender 的擴展 Berkeley Packet Filter (eBPF) 為 Linux 操作系統提供補充事件數據。 eBPF 有助於解決 AuditD 事件提供者所看到的數類問題，並且在效能和系統穩定性方面非常有用。

主要優點包括：

• 減少全系統 AuditD 相關日誌雜訊
• 優化全系統事件規則，否則會導致應用程式之間發生衝突
• 減少檔案事件 (檔案讀取/開啟) 監控的額外負荷
• 提高事件速率吞吐量並減少記憶體佔用
• 針對特定配置的最佳化效能

eBPF 的運作方式

使用 eBPF，先前從 AuditD 事件提供者取得的事件現在會從 eBPF 感應器流出。 這有助於提高系統穩定性，提高 CPU 和記憶體利用率，並減少磁碟使用。 eBPF 有助於減少應用程式之間發生衝突的可能性，因為不需要自訂規則。 與 eBPF 相關的資料會記錄到 /var/log/microsoft/mdatp/microsoft_defender_core.log 檔案中。

此外，eBPF 感測器使用 Linux 核心的功能，無需使用有助於提高系統穩定性的核心模組。

系統必要條件

下列最低散發版和核心版本支援適用於 Linux 適用於端點的 Microsoft Defender 的 eBPF 感應器：

使用 eBPF

依預設，eBPF 感應器會自動為所有客戶啟用，適用於客服專員版本 101.23082.0006 及更新版本。 客戶需要更新到支援的版本才能體驗該功能。 在端點上啟用 eBPF 感應器時，Linux 上的適用於端點的 Defender 會supplementary_events_subsystem更新為 ebpf。

如果您想手動停用 eBPF，則可以執行下列命令：

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

您也可以更新mdatp_managed.json檔案：

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

請參閱連結，以取得詳細的範例 json 檔案 - 設定 Linux 上適用於端點的 Microsoft Defender 喜好設定。

您也可以在 Microsoft Defender 入口網站中使用進階搜捕，檢查 Linux 端點上啟用/停用) 的 eBPF 狀態 (。 步驟如下：

1. 移至 Microsoft Defender 入口網站並登入。

2. 在導覽窗格中，移至 [搜尋>進階搜尋]。

3. 在 [進階搜捕] 底下，移至 [Defender 弱點管理]。

4. 執行下列查詢： DeviceTvmInfoGathering。

5. 在輸出的 [其他欄位] 欄中，選取 [ 顯示更多]，然後尋找 [EBPF STATUS： true]。

AuditD 的不可變模式

對於在不可變模式中使用 AuditD 的客戶，在啟用 eBPF 之後必須重新開機，才能清除適用於端點的 Microsoft Defender 所新增的稽核規則。 此需求是 AuditD 不可變模式的限制，它會凍結規則檔案並禁止編輯/覆寫。 此問題已透過重新啟動解決。

重新啟動後，執行下列命令以檢查是否已清除稽核規則：

% sudo auditctl -l

上一個命令的輸出不應顯示任何規則或任何使用者新增的規則。 如果未移除規則，請執行下列步驟來清除稽核規則檔案：

1. 切換到 ebpf 模式。

2. 移除檔案 /etc/audit/rules.d/mdatp.rules。

3. 重新啟動機器。

疑難排解和診斷

您可以執行 mdatp health 命令來檢查代理程式健康狀態。 使用下列命令列檢查目前的核心版本，以確定 Linux 上適用於端點的 Defender 的 eBPF 感應器：

uname -a

已知問題

1. 在 RHEL 8.1 版本上使用 SAP 啟用 eBPF 可能會導致核心震驚。 若要減輕此問題，您可以採取下列其中一個步驟：

   • 使用高於 RHEL 8.1 的發行版版本。
   • 如果您需要使用 RHEL 8.1 版本，請切換至 AuditD 模式。

2. 使用 Oracle Linux 8.8 搭配核心版本 5.15.0-0.30.20.el8uek.x86_64、5.15.0-0.30.20.1.el8uek.x86_64 可能會導致核心異常。 若要減輕此問題，您可以採取下列其中一個步驟：

   • 如果您想要使用 eBPF 作為補充子系統提供者，請在 Oracle Linux 8.8 上使用高於或低於 5.15.0-0.30.20.el8uek.x86_64、5.15.0-0.30.20.1.el8uek.x86_64 的核心版本。 Oracle Linux 的最低核心版本為 RHCK 3.10.0，而 Oracle Linux UEK 為 5.4。

   • 如果您需要使用相同的核心版本，請切換至 AuditD 模式

     sudo mdatp config  ebpf-supplementary-event-provider  --value disabled
     

   • 以下兩組資料有助於分析潛在問題並確定最有效的解決方案。

     1. 使用下列指示，從用戶端分析器工具收集診斷套件：針對 Linux 上 適用於端點的 Microsoft Defender 的效能問題進行疑難排解。

     2. 當適用於端點的 Defender 使用高資源時，請使用下列指示來收集偵錯診斷套件：Linux 資源上的適用於端點的 Microsoft Defender。

3. 當 ksplice 用於即時核心修補時，系統會在執行適用於 Linux 的 Defender 的 Oracle Linux 7.9 上停止回應。

   • ksplice 的自動安裝修補只是將 cron 作業新增至端點。
   • 若要減輕當機問題，您可以建立 cron 作業，該作業會先停止 mdatp 服務、套用 ksplice 型修補、然後啟動服務。
   • 由於內核修補是幾秒鐘的活動，因此這在安全性方面不會有重大影響。

疑難排解效能問題

如果您看到端點上的 Microsoft Defender 資源耗用量增加，請務必識別造成大部分 CPU/記憶體使用率的進程/掛接點/檔案。 然後，您可以套用必要的排除項目。 套用可能的防病毒排除項後，如果父進程) 仍在耗用資源 (，請 wdavdaemon 使用ebpf-statistics命令取得最高系統呼叫計數：

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

在先前的輸出中，您可以看到 stress-ng 是產生大量事件的最上層處理程序，可能會導致效能問題。 最有可能的是，stress-ng正在生成ID為82的系統呼叫。 您可以使用 Microsoft 建立票證，以排除此程式。 未來，作為即將推出的增強功能的一部分，您可以更多控制權來在終端套用此類排除。

套用至 AuditD 的排除項目無法移轉或複製至 eBPF。 eBPF 內部已經解決了雜訊日誌、核心恐慌、雜訊系統呼叫等常見問題。 如果您想要新增任何進一步的排除項目，請連絡 Microsoft 以套用必要的排除項目。

常見問題 - 過渡到 eBPF

1. 為什麼要考慮遷移到 eBPF？

適用於 Linux 上 適用於端點的 Microsoft Defender 的擴展 Berkeley Packet Filter (eBPF) 可作為 AuditD 的有效替代方案，解決與 AuditD 事件提供者相關的各種挑戰，同時在效能和系統穩定性方面提供顯著優勢。 一些主要好處包括 -

• 效能：eBPF 與 AuditD 相比，透過減少系統資源的開銷來顯著提高效能。

• 資源效率：eBPF 使用更少的資源，即使在重負載條件下也有助於保持系統穩定性。

• 可擴展性：eBPF 的架構更具可擴展性，使其成為工作負載不斷增長或複雜的環境的更好選擇。

• 現代技術：eBPF 代表了一種現代的、前瞻性的技術，與未來的 Linux 核心發展保持一致，確保更好的長期支援。

2. 如何繼續使用 AuditD？

如果您偏好繼續使用 AuditD：

• 支援的版本：您可以保留在 Linux 版本 101.24072.0000 上的適用於端點的 Defender，這會在組建有效期間支援 AuditD，這大約是九個月。 這提供了足夠的過渡期來規劃您遷移到 eBPF。 可以通過在 Linux 服務器上運行命令 mdatp health 來檢查到期日期。

• Long-Term 計劃：雖然保留 101.24072.0000 建置是一種選擇，但我們建議您在此時間範圍內規劃過渡到 eBPF，以確保您受益於最新的安全性和效能改進並獲得持續支援。

也就是說，我們的建議是計劃使用 eBPF 作為主要事件提供者。

3. 如果某些場景不支援 eBPF 會怎樣？

如果不支援 eBPF，請執行下列操作：

• Netlink 後援：系統會回退為使用 Netlink 事件提供者。 雖然 Netlink 會繼續擷取處理程序事件，例如 (、 、 、 或) tid ，但它不支援檔案系統相關事件，例如、) unlink 或 Socket 事件 (rename。 gidforkexitexec

• 影響：您的工作負載不會中斷，但您可能會錯過 eBPF 會擷取的特定檔案和套接字相關事件。

4. 如何使用更新版本管理排除項目？

以下是對 AuditD 進行排除的一些常見原因：

• 某些系統呼叫或進程產生大量雜訊時的性能

• 內核恐慌，有時很多系統調用，特別是網絡/文件系統調用，導致內核恐慌。

• 嘈雜的記錄，稽核記錄會耗盡磁碟空間。 客戶為嘈雜的處理程序放置了排除項，以減少日誌大小。

而使用 eBPF 時，前兩個使用案例是移轉的候選案例。 日誌不再是 eBPF 的問題。 對於前兩個使用案例，您可以從下列選項中選擇：

• 連絡支援人員：聯絡 Microsoft 以套用後端的排除項目。

• 全域排除：在 Linux 上適用於端點的 Defender 的更新版本中，可以使用全域排除來管理排除。 全域排除項目同時適用於防病毒軟體和 EDR，目前可以透過受控 json 進行設定。 如需詳細資訊，請參閱設定及驗證 Linux 上適用於端點的 Microsoft Defender 排除項目。

5. 如果出現問題，我該怎麼辦？

• 聯繫支持： 如果您在過渡到 eBPF 期間或之後遇到任何問題，請聯繫技術支持尋求幫助。 我們致力於確保平穩過渡，並隨時協助解決您可能面臨的任何挑戰。

• 支援管道：您可以透過 Microsoft Defender 入口網站連絡支援人員。 此外，我們的知識庫和社群論壇是解決常見問題的寶貴資源。

另請參閱

• 針對 Linux 上 適用於端點的 Microsoft Defender 的效能問題進行疑難排解
• 適用於端點的 Microsoft Defender on Linux 資源