基于eBPF的云環境下payload進程檢測方法

摘 要：針對目前云環境下攻擊載荷（payload）所體現出的新特征以及目前檢測方法性能損耗較高的問題，提出了一種利用eBPF技術在內核態檢測反向連接類payload進程從而定位被入侵容器的方法。該方法在內核態對服務端TCP連接進行監控，通過篩選TCP標志位定位疑似反向連接類payload進程所在容器，并對該容器進程組后續訪問文件行為進行追蹤以控制損害。實驗證明，該方法可以有效檢測出并定位被入侵容器，且其性能消耗極低，多線程性能Unixbench分數損耗僅為0.53%。

關鍵詞：eBPF；sock連接分析；payload檢測；異常容器定位；訪問文件監控

中圖分類號：TP309

文獻標志碼：A

文章編號：1001-3695（2023）07-036-2157-05

doi：10.19734/j.issn.1001-3695.2022.11.0562

Payload process detection method based on eBPF in cloud environment

Wang Shengkai，Ruan Shuhua^?，Wang Dengzhe

（School of Cyber Science amp; Engineering，Sichuan University，Chengdu 610065，China）

Abstract：Aiming at the new features of payloads in the cloud environment and the high performance loss of current detection methods，this paper proposed a method using eBPF technology to detect reverse connected payloads in the kernel state to locate the invaded container.This method monitored the TCP connection of the server in the kernel state，located the container of the suspected reverse connection class payload process by filtering the TCP flag bit，and tracked the subsequent file access behavior of the container process group to control the damage.Experiments show that this method can effectively detect and locate the intruded container，and its performance consumption is extremely low.The multi-threaded performance Unixbench score loss is only 0.53%.

Key words：eBPF；sock connection analysis；payload detection；abnormal container location；access file monitoring

隨著云計算技術的不斷發展，云平臺提供的云服務模式越來越多樣化，從IaaS、PaaS、SaaS到BaaS、FaaS，從提供基礎設備到提供一個具體的函數，資源的劃分粒度越來越細，這使得資源的利用更加高效。而相應的虛擬化技術也從最早出現的Hypervisor技術發展到容器技術，與前者相比，容器虛擬化技術的體量更小，對資源的利用率更高，但其隔離性則要差很多，因此其更易被入侵。一旦云上的容器存在漏洞，攻擊者便可能通過容器逃逸攻擊獲得云平臺的權限，進而對云上其他資源造成威脅^［1］。因此如何檢測并定位容器異常一直是業界所關注的問題。

漏洞的類型有很多種，在Linux內核使用的C語言中，存在著五種漏洞類型，即指針覆寫、緩沖區溢出、內存管理錯誤、格式化輸出、整數溢出^［2］。而針對程序漏洞進行的攻擊大致可以分為內存損壞、劫持控制流、竊取信息、非控制數據攻擊四類^［3～5］。雖然漏洞的類型不盡相同，攻擊方式也有很多，但對于漏洞的攻擊流程大致一樣，洛克希德·馬丁公司提出了一種描述網絡攻擊的模型——網絡殺傷鏈，該模型將網絡攻擊劃分為七個階段，分別是偵察跟蹤、武器構建、載荷投遞、漏洞利用、安裝植入、命令與控制、目標達成^［6］。在漏洞利用階段，攻擊者根據漏洞的原理制定不同的攻擊方法，以獲得非法控制權限；在安裝植入階段，攻擊者在被攻擊端植入payload進程來為后續控制被攻擊端做準備。

在云環境中，攻擊者所使用的payload有了新的共同特征，例如因為絕大部分的服務器是在內網中，所以公網IP是無法直接訪問該服務器的，這就導致了正向連接類的payload很難應用在云環境中，反向連接類的payload在云環境中的攻擊場景更加有效。

本文針對云環境中payload的新特征，提出了一種利用 eBPF技術監控由服務器端服務發起的連接，進而檢測出反向連接類的payload，同時對payload所在容器進行定位，并監控其后續訪問文件。

1 背景及研究現狀

本章主要對異常檢測的研究現狀以及內核態觀測技術eBPF的原理和應用場景進行分析。

1.1 異常檢測研究現狀

目前業界在異常檢測方面分為基于簽名和基于異常的兩種檢測方法^［7］。其中基于異常的檢測方法主要以系統調用序列相關信息為特征，結合自然語言處理技術，最終使用機器學習技術來對異常進行檢測^［8～10］。

除了以系統調用序列相關信息為特征外，文獻［11］使用I/O序列為特征，結合馬爾可夫模型來檢測虛擬機I/O異常；文獻［12，13］使用日志數據結合機器學習技術檢測異常，這種方式有助于跨平臺進行異常檢測；文獻［14，15］以用戶為主體對其行為進行分析，來發現異常用戶行為。

同時也有團隊在研究針對機器學習技術攻擊的方法，文獻［16］提出了一種新的攻擊方式，通過對SVM的訓練數據進行竄改，導致該模型的檢測率下降。

除了利用機器學習、自然語言處理相結合的異常檢測方法，還有利用計算機免疫學來檢測異常的方法。文獻［17］通過模擬人工內分泌系統來對異常進行檢測；文獻［18］提出了一種基于擬態防御的軟件定義網絡的安全機制。

通過對上述文獻進行分析可以發現，基于機器學習的異常檢測雖然有著很好的靈活性和自適應性，但其需要預先采集數據進行訓練，并且其檢測部分很難部署到系統底層，因此檢測過程大多要在用戶態進行，這種內核態與用戶態的頻繁切換導致這些方法在性能上有著很大的制約。在云原生技術飛速發展的現在，云上的安全越來越重要。微服務架構的問世，使得云上資源利用更加充分，對性能的要求也逐漸提高，此時各大廠商以及業界學者將目光放到了eBPF技術上，利用eBPF技術編寫內核觀測程序，以更好地處理網絡、安全、存儲和沙盒問題^［19］。

目前業界對eBPF的研究主要集中在網絡層，文獻［20，21］ 使用eBPF和XDP來對DDoS攻擊進行防護。文獻［22］利用eBPF技術來選擇DNS服務器，以防止用戶數據的泄露。文獻［23］使用eBPF技術編寫審計框架，通過自定義審計規則來保證容器的安全性。文獻［24］使用eBPF監控容器程序的上下文以檢測針對容器的入侵。文獻［25］ 通過跟蹤點監控網絡行為，解決了進入或離開虛擬機或容器的數據包可見性問題。文獻［26，27］將目光放在了云原生環境下，利用eBPF技術對微服務架構下的容器網絡性能進行監控。

1.2 eBPF工作原理

eBPF技術可以將用戶編寫的程序在內核態運行，避免了頻繁切換用戶態和內核態的性能損耗。eBPF工作流程如圖1所示。

eBPF的工作流程分為以下幾步：

a）eBPF源代碼通過LLVM編譯器編譯成eBPF字節碼。

b）eBPF加載器進程通過bpf（）系統調用創建BPF map，同時將eBPF程序送入驗證器進行檢驗，該步驟會驗證eBPF程序是否滿足一定的條件，例如：（a）除非預設非特權進程也可以加載eBPF程序，否則只有特權進程可以運行eBPF程序；（b）通過有向無環圖的深度優先搜索算法，確保該程序不存在死循環；（c）分析eBPF程序對寄存器或堆棧的影響，確保不存在越界等非法行為，確保該程序不會造成系統崩潰或者其他有害后果。

c）通過驗證后，JIT編譯器將eBPF字節碼轉譯成本地機器碼，若內核不支持JIT，則需要eBPF虛擬機先將中間碼解析成機器碼，這會消耗更多的CPU資源。

d）eBPF程序附加到追蹤點或系統事件上，等待進程觸發。

e）當進程觸發事件時，運行eBPF程序。

2 檢測方案設計

2.1 總體架構

payload進程檢測系統由采集模塊、檢測模塊、定位模塊和追蹤模塊四部分組成。采集模塊負責采集Linux中屬于Kubernetes的對外提供服務的容器進程的sock狀態信息；檢測模塊負責檢測出疑似payload的進程；定位模塊負責對疑似payload的進程所在容器進行定位；追蹤模塊則負責對異常容器進程組打開文件行為進行追蹤，進行損害控制。接下來將對原理和實現進行說明。

payload進程檢測系統總體架構如圖2所示。

一般企業租用的云服務器是云服務提供商在云平臺上使用虛擬機管理器創建的虛擬主機，由于企業無法控制云平臺，所以payload進程檢測系統部署的層次在云服務器內核層。Kubernetes是谷歌開源的一個管理容器的應用，主要用于在云端為用戶提供服務，其特點包括部署容器的自動化、可擴展性以及可移植性。本文通過在Kubernetes上部署服務來模擬云環境。

payload進程檢測系統的采集模塊和追蹤模塊使用eBPF技術在內核態獲得數據，其中所選取的事件類型為tracepoint，這些事件點是靜態的，由Linux內核開發人員負責維護，這樣就保證了在不同版本內核的Linux中有著相同的事件接口，payload進程檢測系統在不同版本下的Linux中都可以運行。

2.2 數據采集原理及實現

2.2.1 客戶端與服務端的通信

客戶端通過TCP握手協議與服務端建立連接，通過連接終止協議結束通信。在這個過程中，客戶端有五種連接狀態，分別是SYN_SENT、ESTABLISHED、FIN_WAIT1、FIN_WAIT2、TIME_WAIT，而服務端所可能的連接狀態為SYN_RCVD、ESTABLISHED、CLOSE_WAIT、LAST_ACK、CLOSED。服務端與客戶端的各階段狀態如圖3所示。

在云環境中，除需要推送信息的絕大多數服務應用都是由用戶發起請求，而服務端響應資源，因此在常規的云環境下，公網中的用戶端與內網中的服務端之間的連接應該由用戶發起。

另外由于內網與公網往往是通過代理進行通信，用戶傳輸的報文往往需要進行相應的內網地址轉換，并且一些安全網關和防火墻會對傳入流量進行限制，所以處于公網的攻擊端很難通過正向連接payload連接服務器，而讓服務器主動去連接公網的攻擊端，則可以繞開這些限制。

2.2.2 采集服務進程sock狀態信息

在eBPF的tracepoint中，inet_sock_set_state可以追蹤連接的狀態變化。采集模塊注冊該追蹤點，當進程發起或接受TCP連接時，會陷入到鉤子函數中，即已編寫的eBPF采集程序，當該程序獲得sock連接的狀態變化、源和目的地址、源和目的端口等信息后，會返回到正常執行流中，繼續執行TCP系統調用。獲取sock連接信息如圖4所示。

由于服務是與外界進行交互的接口，而云服務器內部的其他進程并不會直接暴露給外界用戶，所以只需要對服務進程進行監控。containerd并不直接創建runc（容器運行時），而是使用containerd-shim提供的接口來管理容器的基本生命周期，因此所有的服務進程都有一個名為“containerd-shim”的父進程。采集模塊根據當前進程的task_struct結構體的real_parent字段獲得其父進程信息，進而可以篩選出所有containerd-shim進程的后代進程，這些后代進程即為所需要監控的服務容器進程。而根據TCP連接的狀態標志可以篩選出由服務端主動發起的連接，根據該連接的源地址和源端口，就可以確定具體是哪個服務容器進程發起的連接。

2.3 payload進程檢測及損害控制

2.3.1 確定白名單

由于Kubernetes中kube-system命名空間下的一些系統組件會主動對外發起連接，所以需要構建白名單以防止檢測模塊產生誤報。

kube-system所包括的可能對外發送連接的系統組件為coredns、kube-apiserver、kubelet、kubectl、kube-controller、kube-scheduler。

coredns負責對DNS進行解析，在獲取服務對應地址的時候需要主動發起連接；kube-apiserver是整個集群控制資源的API入口，它負責與其他組件進行交互，因此該組件需要主動發起連接；kubelet負責對Pod進行控制，那么當它對某個服務容器進行操作時（創建、刪除等），需要主動發起連接；kube-controller是集群的管理者，當它對集群的資源配置或是故障修復時，可能會發起連接來對服務的資源進行調整；kube-scheduler是Kubernetes平臺的調度器，負責規劃服務的部署節點，在這一過程中也會有連接的發起。因此需要將這些Kubernetes的系統組件加入白名單，防止誤報。

再考慮到一些服務需要可能要與企業內網其他IP通信，所以將內網的網段設為白名單，防止誤報。

綜上所述，可以采用兩種形式的白名單，一種為進程名稱形式的白名單，構建方法可以在正常云環境中運行采集程序，將會主動發起連接的服務容器進程加入到白名單中；第二種為網段形式的白名單，可以通過手動將內網網段加入的方式構建白名單。

2.3.2 payload進程檢出及異常服務容器定位

云環境下服務端的行為是被動監聽特定端口，當服務器收到目標端口為服務端口的報文時，便通過coredns和Kubernetes的網關轉發給該服務容器。那么當服務端的服務主動發起連接時，則有很大可能是攻擊者部署的payload進程，本文實驗環境選取Cilium來作為配置Pod網絡的網絡解決方案，攻擊者與普通客戶端通信流程區別如圖5所示。

payload進程檢測系統始終監控所有的連接信息，檢測模塊通過篩選TCP狀態標志位來對所有的非白名單正向連接進行監控。定位模塊通過正向連接信息的源端口和源IP確定具體服務容器。

算法1 payload進程檢測及異常服務容器定位算法

輸入：發起或接受TCP連接的進程task_strcut結構體t、inet_sock_set_state跟蹤點參數args、進程搜索深度l、客戶端TCP狀態標志位集合s、進程名白名單c、網段白名單n、端口與服務對應表ps。

輸出：疑似payload進程的pid、進程名稱comm、狀態state、使用端口號port、所屬服務service、異常容器進程組ID列表d。

a） while lgt;0：

if t-gt;comm==“containerd-shim”：return t；

else：l--；t=t-gt;real_parent；

//在搜索深度l中，將服務容器進程篩選出來

b） if args-gt;state in s and t-gt;comm not in c and args-gt;port not in n：//檢出主動發起連接的非白名單進程

d.append（t-gt;signal-gt;pids［2］）； //記錄異常容器進程組ID

return t-gt;comm、t-gt;pid、args-gt;state、args-gt;port

//輸出異常容器進程信息

ps［args-gt;port］ //定位疑似payload進程所屬服務容器

2.4 訪問文件行為追蹤及損害控制

由于payload進程往往會作為被控制進程的一個子進程，所以追蹤模塊以疑似payload進程的進程組ID作為監控標準，對該進程組后續打開文件進行追蹤。

追蹤模塊通過sys_enter_open和sys_enter_openat這兩個追蹤點來對打開文件行為進行監控，若當前進程的進程組ID在定位模塊標記的異常進程組ID列表中時，則記錄該進程所訪問的文件，作為后續損害控制的依據。

算法2 異常服務容器定位算法

輸入：發起訪問文件行為的進程task_strcut結構體t、sys_enter_openat跟蹤點參數args、算法1輸出的異常容器進程組ID列表d。

輸出：進程的pid、進程名稱comm、進程訪問文件路徑path。

a） if t-gt;signal-gt;pids［2］ in d：

return t-gt;pid、t-gt;comm； //輸出異常進程信息

record args-gt;path //記錄異常進程組所訪問的文件

b） kill -9 pid //殺掉執行文件訪問的異常進程

3 實驗及結果分析

本章從效果及性能損耗兩方面對payload異常檢測系統進行分析，使用VMware虛擬機作為基礎環境，具體實驗環境的配置如下：

靶機CPU為Intel Core^TM i5-8400，主頻為2.8 GHz，虛擬機分配處理器個數為6個，硬盤81 GB，內存8 GB，操作系統版本為64位Debian 11，內核版本為6.0.0-3，Kubernetes client/server版本為v1.25.3，containerd版本為v1.25.0。

攻擊機使用Kali系統，內核版本為5.18.0，Metasploit版本為v6.2.20。

3.1 應用白名單及IP白名單

首先構建白名單列表，應包括應用與目的地址兩部分的白名單，其中應用包括kube-system下的系統組件，而目的地址包括本機地址、內網地址以及服務地址，具體如表1所示。

3.2 檢測效果

為驗證該檢測算法的有效性，分別選取不同的漏洞環境和payload進行相關實驗。漏洞環境分別是OFBiz：CVE：2020-9496、saltstack：CVE：2020-11651、struts2：CVE：2020-17530、GitLab：CVE：2021-22205、Spring：CVE：2022-22963。檢測結果如表2所示。

可以看出，對于不同的CVE漏洞環境以及不同的payload，該檢測系統均可以成功檢出。

Kubernetes服務空間如圖6所示，payload進程檢測系統運行效果如圖7所示。

從圖7中可以看出，入侵檢測系統成功檢測出植入在Spring服務容器的payload進程，同時也對該payload進程組后續訪問文件進行了記錄。

3.3 性能測試

為檢測該入侵檢測程序對系統性能造成的影響，采用Unixbench工具進行性能測試。

圖8為單線程性能測試，只運行一個測試程序；圖9為多線程性能測試，6個測試程序并行運行。

根據計算，其單線程性能評分測試中，檢測程序對性能影響最大的項為System Call Overhead，啟用檢測程序的平均分數損耗為2.13%，總評分損耗為2.81%；在多線程測試中，檢測程序對性能影響最大的項為Pipe Throughput，啟用檢測程序的平均分數損耗為1.07%，總評分損耗為0.53%。可以看出，payload異常檢測系統對系統性能造成了可以接受的影響。

4 結束語

本文針對云環境下payload多為反向連接類型的新特征，以及傳統檢測方法因為用戶態和內核態的頻繁切換導致的性能消耗較大的問題，提出了一種利用eBPF技術監控由服務容器進程主動發起的連接，并以此檢測payload進程并定位其所屬容器的方法。payload異常檢測系統通過白名單機制降低檢測誤報率，并使用eBPF技術對異常容器進程組后續打開文件進行追蹤，以方便后續進行損害控制。該檢測程序可以有效地發現payload，定位被入侵容器，同時對其造成的損害進行追蹤，其性能損耗可以接受。

a）通過擴展追蹤點以及其他維度的異常行為信息來更好地對被入侵容器進行檢測。

b）將eBPF作為采集程序，與機器學習技術相結合，提高檢測程序的靈活性。

c）增加payload種類，提高檢測的普適性。

參考文獻：

［1］Mattetti M，Shulman-Peleg A，Allouche Y，et al.Securing the infrastructure and the workloads of Linux containers［C］//Proc of IEEE Conference on Communications amp; Network Security.Piscataway，NJ：IEEE Press，2015：559-567.

［2］陳小全，薛銳.程序漏洞：原因、利用與緩解——以C和C++語言為例［J］.信息安全學報，2017，2（4）：41-56.（Chen Xiaoquan，Xue Rui.Cause，exploitation and mitigation of program vulnerability——C and C++ language as an example［J］.Journal of Cyber Security，2017，2（4）：41-56.）

［3］Szekeres L，Payer M，Tao W，et al.SoK：eternal war in memory［C］//Proc of IEEE Symposium on Security and Privacy.Piscataway，NJ：IEEE Press，2013：48-62.

［4］Larsen P，Homescu A，Brunthaler S，et al.SoK：automated software diversity［C］//Proc of IEEE Symposium on Security and Privacy.Piscataway，NJ：IEEE Press，2014：276-291.

［5］Chen S，Xu J，Sezer E C，et al.Non-control-data attacks are realistic threats［C］//Proc of the 14th Conference on USENIX Security Symposium.Berkeley：USENIX Association，2005：12.

［6］李凌書，鄔江興，劉文彥.SaaS云環境下基于容器指紋匿名的網絡欺騙方法［J］.信息安全學報，2022，7（2）：72-86.（Li Lingshu，Wu Jiangxing，Liu Wenyan.An anonymous network deception method based on container fingerprint modification for SaaS applications［J］.Journal of Cyber Security，2022，7（2）：72-86.）

［7］蹇詩婕，盧志剛，杜丹，等.網絡入侵檢測技術綜述［J］.信息安全學報，2020，5（4）：96-122.（Jian Shijie，Lu Zhigang，Du Dan，et al.Overview of network intrusion detection technology［J］.Journal of Cyber Security，2020，5（4）：96-122.）

［8］馮亞玲，周安民.基于系統調用的惡意軟件檢測技術研究［J］.信息安全研究，2016，2（4）：367-371.（Feng Yaling，Zhou Anmin.Research on malware detection technology based on system call［J］.Journal of Information Security Research.2016，2（4）：367-371.）

［9］詹靜，范雪，劉一帆，等.SEMBeF：一種基于分片循環神經網絡的敏感高效的惡意代碼行為檢測框架［J］.信息安全學報，2019，4（6）：67-79.（Zhan Jing，Fan Xue，Liu Yifan，et al.SEMBeF：a sensitive and efficient malware behavior detection framework based on sliced recurrent neural network［J］.Journal of Cyber Security，2019，4（6）：67-79.）

［10］Peddoju S K，Upadhyay H，Soni J，et al.Natural language processing based anomalous system call sequences detection with virtual memory introspection［J］.International Journal of Advanced Computer Science and Applications，2020，11（5）：455-460.

［11］陳興蜀，陳佳昕，趙丹丹，等.基于虛擬機IO序列與 Markov 模型的異常行為檢測［J］.清華大學學報：自然科學版，2018，58（4）：395-401.（Chen Xingshu，Chen Jiaxin，Zhao Dandan，et al.Anomaly detection based on IO sequences in a virtual machine with the Markov mode［J］.Journal of Tsinghua University：Science and Techno-logy，2018，58（4）：395-401.）

［12］張圣林，李東聞，孫永謙，等.面向云數據中心多語法日志通用異常檢測機制［J］.計算機研究與發展，2020，57（4）：778-790.（Zhang Shenglin，Li Dongwen，Sun Yongqian，et al.Unified anomaly detection for syntactically diverse logs in cloud datacenter［J］.Journal of Computer Research and Development，2020，57（4）：778-790.）

［13］梅御東，陳旭，孫毓忠，等.一種基于日志信息和 CNN-text 的軟件系統異常檢測方法［J］.計算機學報，2020，43（2）：366-380.（Mei Yudong，Chen Xu，Sun Yuzhong，et al.A method for software system anomaly detection based on log information and CNN-text［J］.Chinese Journal of Computers，2020，43（2）：366-380.）

［14］馮云，劉寶旭，張金莉，等.一種無監督的竊密攻擊及時發現方法［J］.計算機研究與發展，2021，58（5）：995-1005.（Feng Yun，Liu Baoxu，Zhang Jinli，et al.An unsupervised method for timely exfiltration attack discovery［J］.Journal of Computer Research and Development，2021，58（5）：995-1005.）

［15］孫偉，張鵬，何永全，等.內網環境下基于時空事件關聯的攻擊檢測方法［J］.通信學報，2020，41（1）：33-41.（Sun Wei，Zhang Peng，He Yongquan，et al.Attack detection method based on spatiotemporal event correlation in intranet environment［J］.Journal on Communications，2020，41（1）：33-41.）

［16］錢亞冠，盧紅波，紀守領，等.一種針對基于 SVM 入侵檢測系統的毒性攻擊方法［J］.電子學報，2019，47（1）：59-65.（Qian Yaguan，Lu Hongbo，Ji Shouling，et al.A poisoning attack on intrusion detection system based on SVM［J］.Acta Electronica Sinica，2019，47（1）：59-65.）

［17］白琳，楊超.基于激素調節免疫網絡聚類的入侵檢測系統［J］.信息安全學報，2019，4（5）：25-32.（Bai Lin，Yang Chao.Intrusion detection system based on hormone-regulated immune network clustering［J］.Journal of Cyber Security，2019，4（5）：25-32.）

［18］丁紹虎，李軍飛，季新生.基于擬態防御的 SDN 控制層安全機制研究［J］.信息安全學報，2019，4（4）：84-93.（Ding Shaohu，Li Junfei，Ji Xinsheng.Research on SDN control layer security based on mimic defense［J］.Journal of Cyber Security，2019，4（4）：84-93.）

［19］Sharaf H，Ahmad I，Dimitriou T.Extended Berkeley packet filter：an application perspective［J］.IEEE Access，2022，10：126370-26393.

［20］Vieira M A M，Castanho M S，Pacífico R D G，et al.Fast packet processing with EBPF and XDP：concepts，code，challenges，and applications［J］.ACM Computing Surveys，2020，53（1）：1-36.

［21］Rivera S，Gurbani V K，Lagraa S，et al.Leveraging eBPF to preserve user privacy for DNS，DoT，and DoH queries［C］//Proc of the 15th International Conference on Availability，Reliability and Security.New York：ACM Press，2020：1-10.

［22］Mayer A，Loreti P，Bracciale L，et al.Performance monitoring with H＾2：hybrid kernel/eBPF data plane for SRv6 based hybrid SDN［J］.Computer Networks，2021，185：107705.

［23］Lim S Y，Stelea B，Han Xueyuan，et al.Secure namespaced kernel audit for containers［EB/OL］.（2021-11-03）.https：//arxiv.org/abs/2111.02481.

［24］Fournier G，Afchain S，Baubeau S.Runtime security monitoring with eBPF［C］//Proc of the 17th SSTIC Symposium sur la Sécurité des Technologies de l’Information et de la Communication.2021.

［25］Deri L，Sabella S，Mainardi S，et al.Combining system visibility and security using eBPF［C］//Proc of Italian Conference on Cybersecurity.2019.

［26］劉暢.基于 eBPF 的容器網絡可觀測性方法與實踐［D］.杭州：浙江大學，2021.（Liu Chang.Observability method and practice of container networks based on eBPF［D］.Hangzhou：Zhejiang University，2021.）

［27］Weng Tianjun，Yang Wanqi，Yu Guangba，et al.Kmon：an in-kernel transparent monitoring system for microservice systems with eBPF［C］//Proc of IEEE/ACM International Workshop on Cloud Intelligence.Piscataway，NJ：IEEE Press，2021：25-30.