容器內惡意進程應用層阻斷生成研究

方圓 盛劍橋 張亮 丁鑫

摘要：容器提供了一種邏輯打包機制，以這種機制打包的應用可以脫離其實際運行的環境。利用這種脫離，不管目標環境是私有數據中心、公有云，還是開發者的個人筆記本電腦，都可以輕松、一致地部署基于容器的應用。隨著容器技術的應用，容器內的安全性也同樣面臨著威脅。而不管是什么樣的攻擊方式最終都需要以程序的方式來執行黑客的攻擊手段。進程的生成由Linux 內核接管，目前沒有對外放出進程生成管理的接口，而如果以內核級代碼進行生成管理，若出一點意外將導致整個系統崩潰，無法使用。該研究是基于容器運行的機制并結合Linux系統的特性，在應用層接管進程的生成管理，并對惡意進程的生成進行阻斷生成。

關鍵詞：容器;容器安全;進程阻斷

中圖分類號：TP393??? 文獻標識碼：A

文章編號：1009-3044（2021）28-0012-05

在云原生技術的應用廣泛下，容器技術也得到了極大的推廣。越來越多的公司把服務從本地遷到云上，服務也越來越契合云原生框架。而容器是Paas（Platform-as-a-Service，平臺即服務）的一種體現，將所需軟件整合成一個應用，一個服務。

容器技術的應用提高了應用程序的可移植性，容器中運行的應用程序可以輕松部署到多個不同的操作系統和硬件平臺。與傳統或硬件虛擬機環境相比，容器所需的系統資源更少，因為它們不包含操作系統映像。容器中的應用程序無論部署在何處，都會運行相同的應用程序，從而程序的操作得到一致和統一。

容器的虛擬技術應用在帶來方便和高效的同時，也成為黑客入侵攻擊的高地。

1研究背景

1.1背景分析

徐孝晉[1]等學者通過容器安全性弱點的研究，提到對于容器相比重量級虛擬化技術，容器技術實現的是非硬件級虛擬化;同時它的實現和設計原理是將主機內核進行隔離，相比傳統虛擬化技術具有更高的安全性。這主要在于傳統的虛擬化技術是圍繞虛擬機內核通信處理，阻斷主機內核層的通信;由于容器技術沒有使用這個限定，容器技術的主機內核呈“曝光式”，因此攻擊者也就可以直接對內（主機內核）發動惡意攻擊，無須繞行，直接參與主機內核處理的過程便是容器安全性的關鍵問題所在，隔離性不強是容器安全性弱點的比較根本的原因之一。相對于KVM虛擬化技術，容器中沒有虛擬出硬件，而是和系統共用，這也會導致系統的安全問題，同時也是容器的安全問題，并且容器自身的安全問題會感染到系統。

進一步的觀察容器各個組件的安全性，由于責任不一樣表現出不一樣的特點。根據魯濤等人[2]對容器中的網絡、鏡像、容器、倉庫、容器所依賴的Linux 內核、容器軟件本身等六個角度逐類分析其中存在的安全威脅，可以看到容器中主要組件的脆弱性不一樣，需要對各個組件有針對性地加固。

還有研究發現有因為容器自身的配置不當而引起的安全問題[3]。例如若以root 權限啟動容器，一旦攻擊者入侵容器中，即擁有了主機內核的所有功能，容器幾乎可以做主機可以做的一切。

1.2容器安全實踐

國內外對容器技術安全有著不同的定義和安全標準規范。國外起步比國內早，權威機構美國國家標準與技術研究院發布了《NIST.SP.800—190應用容器安全指南》作為國外容器安全的標準參考，目前國內在容器安全仍處研究和探索階段，主要還是依靠一些研究機構、云廠商和安全廠商，針對容器的安全性提出各自的防護意見[4]。

Dosec團隊提出通過對靜態的容器鏡像掃描，發現文件漏洞和不安全的配置信息，幫助用戶解決傳統安全軟件無法感知的容器環境問題，同時提供容器進程白名單、文件只讀保護和容器逃逸檢測功能，能有效防止容器運行時安全風險事件的發生[5]。

綠盟安全廠商提出的容器安全解決方案，包括對容器鏡像、倉庫進行漏洞掃描，對容器訪問控制，容器異常行為檢測等實現容器的防護功能[6]。

各個容器安全廠商都針對容器的特性和機制按各自的技術亮點進行安全加固。但其實，容器自身的機制也是可以通過檢測流程或者修改配置達到一定的安全加固[7]，如：容器鏡像安全機制、容器虛擬化安全機制、容器網絡安全機制等。

2容器運行時安全問題

容器運行的安全保障主要來自 Linux 自帶的三個機制：Seccomp、AppArmor、SELinux。

Seccomp（secure computing mode）于2005年首次被引入 Linux 內核。它是一種用于限制允許應用程序進行的系統調用 API 的機制。通過設置 seccomp 配置文件，讓容器在啟動的時候加載設置的seccomp 配置。配置文件內可以設置容器內進程允許和不允許的系統調用API 。容器根據設置配置內容，當容器內的進程使用了配置內不允許的系統調用API 時，seccomp 會主動切斷進程調用的系統API，從而達到限制惡意進程的使用非法的問題，但同時缺陷也是很明顯。Seccomp 配置應用范圍是整個容器而不是單個進程，在限制惡意進程使用系統調用 API，同時也在限制非惡意進程使用系統調用 API，沒辦法在 Seccomp 里面做惡意與非惡意的區別。并且根據惡意風險不斷的增強，seccomp 也需要更新配置文件，但是seccomp 不允許運行著的容器動態加載seccomp 配置文件，只能通過把容器停下，修改完配置文件再重新加載。

AppArmor（Application Armor）是可以在 Linux 內核部中啟用的少數Linux安全模塊（LSM）之一。在AppArmor中，可以將配置文件與可執行文件關聯，從而根據功能和文件訪問權限確定允許該文件執行的操作。AppArmor和其他的LSM實施強行訪問控制，而強行訪問控制由管理員設置。一旦設置成功，其他用戶將無權修改該控制或將其傳遞給另一個用戶。在某種意義上，如果自己賬戶擁有文件，則可以授予其他用戶對該文件的訪問權限（除非此文件被強制訪問控制所覆蓋），或者可以將其設置為不可通過自己的用戶賬戶寫，以防止自己無意中更改。使用強制性訪問控制使管理員可以更細地控制其系統上可能發生的情況，而這是單個用戶無法覆蓋的方式。

SELinux（Security-Enhanced Linux）是Read Hat開發的另一種LSM，但是大多數人認為它起源于美國國家安全局的項目。SELinux可以限制進程與文件和其他進程的相互作用，并且每個進程都在SELinux的作用域下。SELinux權限和常規的DAC? Linux權限之間的主要區別在于：在SELinux中權限與用戶身份無關，它們完全由標簽描述。也就是說，它們是一起工作的，因此DAC和SELinux都必須允許采取對應設置的措施。但是SE? Linux必須先在計算機上的每個文件上標記其SELinux信息，然后才能執行策略。這些策略可以指示特定域的進程對特定類型的文件具有什么訪問權限。實際上，這意味著可以限制應用程序只能訪問其自己的文件，并阻止其他任何進程訪問這些文件。如果應用程序受到威脅，即使正常的自由訪問控制允許它，SELinux也會限制可能影響的文件集。

2.1容器運行的安全風險

2.1.1混亂的容器鏡像

容器的運行依賴容器鏡像，如果容器鏡像從最開始就得不到安全保障，那運行起來的容器就更沒有安全保障。現在市面上容器鏡像有很多第三方倉庫，除了遵守基本的傳輸協議，容器鏡像安全沒有一個統一的安全檢查標準，更不用說對容器鏡像安全的檢查，達不到對容器鏡像精簡、高效、安全的要求。

2.1.2容器運行時資源占用

容器可以通過cgroup機制來控制整個容器的資源使用，但是卻沒辦法知道容器內部具體的資源占用情況。如果一個容器被黑客占據在里面跑挖礦相關的程序，僅從容器外和資源占用情況是無法知道具體容器內被哪個進程占用過高的資源，反復停止、重啟容器也無法解決這類問題。

2.1.3容器內運行病毒

黑客入侵容器中一般有兩種方式，一種是通過容器與外網之間的連接進入容器內，并留下病毒文件讓容器執行。另一種是通過容器鏡像，在容器還未真地運行起來就把病毒文件嵌入到鏡像內，當容器運行時就會把病毒文件運行起來。不管黑客用哪種方式入侵容器內，當入侵系統后往往會注入更多的工具進行攻擊，比如滲透工具或挖礦軟件等。而如果開發人員直接在容器中注入鏡像外的可執行程序則相當于繞開了鏡像安全掃描管控，一定會造成黑客在容器內利用漏洞逃逸，對主機勒索、破壞等惡意行為。

2.1.4容器啟動參數

鏡像中的entrypoint， cmd， volumes， env， ports， users， workdir參數限定了容器運行的行為，然而這些參數可以在啟動鏡像時被啟動參數所覆蓋，這就導致了容器行為無法受控。比如用戶可以以bin/bash 啟動容器從而進入容器內部shell，或掛載主機上的重要系統文件，從而帶來安全隱患和風險。

2.2容器讀寫

2.2.1文件保護

容器內部中大部分目錄都是靜態的，包括etc、lib、usr等系統目錄。關鍵的應用目錄也應該設置只讀保護以防止黑客進行篡改和攻擊。

2.2.2容器讀寫控制

容器本身允許有讀寫行為的存在。但是如果容器被黑客控制，而容器本身的讀寫控制也同時下發到容器內，那黑客的惡意病毒文件利用漏洞同樣是可以獲取對應的讀寫權限，可以針對容器的敏感數據進行讀取，同時可以通過寫的權限，破壞容器內部數據的完整性。

2.2.3環境變量加密

容器的環境變量中往往包含密碼和敏感信息，而擁有In?spect權限的用戶可以輕易地查看容器的環境變量從而導致信息的泄露。

3容器運行分析

容器是一種操作系統虛擬化形式。可以使用一個容器運行從小型微服務或軟件進程到大型應用程序的所有內容。容器包含所有必要的可執行文件、二進制代碼、庫和配置文件。但是與服務器或計算機虛擬化方法不同，容器不包含操作系統映像。因此，它們更輕便且可移植，其開銷很小。而容器的運行也是依賴主機提供的特征來做的虛擬化。

3.1容器的隔離性

容器建立在兩項關鍵技術之上：Linux Namespace 和Linux Cgroups。

Namespace 創建一個近乎隔離的用戶空間，并為應用程序提供系統資源（文件系統、網絡棧、進程和用戶ID）。Cgroup強制限制硬件資源，如CPU、內存、設備和網絡等。在Namespace 的作用下容器內部看到的資源視圖是單獨屬于容器自身，并且隔離出來的資源做的任何操作都不會影響到主機側。通過Cgroup功能，在主機側把主機本身的動態硬件資源按一定的用戶設置分配給對應的容器，控制容器運行動態資源的上限。在 Linux Namespace 和Linux Cgroups功能下對Linux主機做到靜態動態資源的分配和隔離，這并不代表容器本身就是安全的。隔離帶來了防護性，但同時也成為黑客的攻擊點。

3.2容器運行時安全

容器和VM（Virtual Machine）不同之處在于VM模擬硬件系統，每個VM都可以在獨立環境中運行OS，管理程序模擬CPU、內存、存儲、網絡資源等。容器正好與之反，雖然是一個獨立運行環境，但是與主機的任何程序都是共享CPU、內存、存儲、網絡資源，特別是共享了一個Linux 內核。這也造成了容器相對于主機而言，在運行的攻擊面也有所不同，如圖1所示。

容器一共有七個攻擊面：Linux Kernel、Namespace/Cgroups/ Aufs、Seccomp-bpf、Libs、Language VM、User Code、Container engine。

3.2.1 Linux 內核漏洞

容器的內核與宿主內核共享，使用Namespace 與Cgroups這兩項技術，使容器內的資源與宿主機隔離，所以Linux 內核產生的漏洞會導致容器逃逸。容器逃逸和內核提權只有細微的差別，需要突破namespace 的限制。在容器內運行程序，收集有幫助的信息，然后觸發漏洞去執行特權代碼，達到攬權的效果。而在容器內一旦拿到最高的權限，namespace 本身的限制是沒有意義的，同宿主側一樣可以隨意操作獲取任何信息，如圖2 所示。

3.2.2不安全的部署配置

在實際中，我們經常會遇到這種狀況：不同的業務會根據自身業務需求提供一套自己的配置，而這套配置并未得到有效的管控審計，使得內部環境變得復雜多樣，無形之中又增加了很多風險點。最常見的包括：

（1）特權容器或者以root 權限運行容器;

（2）不合理的Capability 配置（權限過大的Capability）。

3.2.3容器內部攻擊

不管容器內以什么樣的方式被入侵，所有的行為都是依靠程序作為媒介來運行其中的行為邏輯。那么只要對程序的行為進行監控，只要發現有危險的行為就中斷程序的運行。

結合容器本身的功能定義，一般只會運行指定的一個業務邏輯程序，不會再刻意加載其它的程序。只要對容器內部做程序加載監控，阻斷非指定程序的加載，就能避免惡意程序在容器內部被加載運行，從而避免了被攻擊的可能。

4應用層進程生成阻斷分析

容器本質是 Linux 下的特殊進程，與應用層的進程共享 Linux 內核。而在容器內生成進程的流程跟Linux應用層生成進程流程是一樣的，只是最終應用的環境是在容器內。

4.1進程生成基本流程

Linux 系統創建進程使用 fork（）、vfork（）、clone（）和 exec（）。 fork（）、vfork（）、clone（）在當前進程的環境下，再創建出一個新的進程運行環境，也就是子進程，并且子進程會有自己的pid，ppid與父進程區分開;而此時的進程是一個空的狀態，也就只有一個進程環境，并沒有進程運行的業務邏輯代碼。這三個函數接口是應用層封閉的內核創建進程的功能，而這三個函數接口最終都會進到內核中調用_do_fork（）來創建進程，而這三個函數接口的區別也只是對應的flag 不同。如圖3所示。

exec（）用于讀取可執行文件并載入上面新生成的進程空間內執行可執行文件內的業務邏輯代碼;一般稱之為 exec 函數族，有一系列的exec 開頭的函數接口，比如：execl（），execve（）等。 Exec（）系列函數與fork（）、vfork（）、clone（）函數接口一起使用，生成一個完整、獨立的進程。而他們時序關系如圖4所示。

4.2進程阻斷原理&Linux 系統調用Hook技術

根據3.1里面的進程生成原理，把一個可執行文件創造成執行的進程需要兩個步驟：

步驟1：使用fork（）、vfork（）、clone（）中的一個函數生成全新的進程運行環境。

步驟2：使用exec（）系列函數加載可執行文件。

而在步驟1 中，只是單純地生成程序運行環境，跟實際的業務邏輯沒有連接關系，并且沒有任何特征可以表明生成的程序運行環境是做什么用的。而在步驟2中使用exec（）系列函數是會傳入需要執行的對應業務邏輯代碼的地址;以此邏輯代碼地址找到對應的業務邏輯并做判斷，再讓exec（）系列函數的調用失敗，就可以做到不讓對應的可執行文件運行起來。而exec （）系統函數都是對系統調用中的execve（）函數做的封閉，最終都是調用的系統調用execve（）;使用Linux Hook技術替換成帶檢測進程特征的函數，就能對進程的生成做干預。

系統調用（syscall）是一個通用的概念，它既包括應用層系統函數庫的調用，也包括內核層系統提供的syscall_table提供的系統api。Hook技術是一個相對較寬的話題，因為操作系統從ring3到ring0是分層次的結構，在每一個層次上都可以進行相應的Hook，它們使用的技術方法以及取得的效果也是不盡相同的。而在容器內，本身就只有應用層的內容也就是ring3層的環境視圖，所以只能在ring3層做Hook處理，來實現系統調用的監控功能。

4.3 ring3 Hook技術之動態連接so 函數劫持

LD_PRELOAD hook 技術屬于 so 依賴劫持技術的一種實現，若要討論這種技術的技術原理先來看一下linux操作系統加載so 的底層原理，包括Linux 系統在內的很多開源系統都是基于glibc的，動態鏈接的ELF可執行文件在啟動時同時會啟動動態鏈接器（/lib/ld-linux.so.X），程序所依賴的共享對象全部由動態鏈接器負責裝載和初始化，所以這里所謂的共享庫的查找過程本質上就是動態鏈接器（/lib/ld-linux.so.X）對共享庫路徑的搜索過程。

4.3.1/etc/ld.so.cache共享庫搜索

Linux為了加速LD_PRELOAD 的搜索過程，在系統中建立了一個ldconfig程序，這個程序負責將共享庫下的各個共享庫維護一個SO-NAME（一一對應的符號鏈接），這樣每個共享庫的 SO-NAME就能夠指向正確的共享庫文件。將全部SO-NAME 收集起來集中放到/etc/ld.so.cache文件里面，并建立一個 SO- NAME 的緩存。當動態鏈接器要查找共享庫時，它可以直接從/ etc/ld.so.cache里面查找。所以，如果我們在系統指定的共享庫目錄下添加、刪除或更新任何一個共享庫，或者我們更改了/ etc/ld.so.conf、/etc/ld.preload的配置，都應該運行一次ldconfig這個程序，以便更新 SO-NAME 和/etc/ld.so.cache，很多軟件包的安裝程序在結束共享庫安裝以后都會調用ldconfig

4.3.2/etc/ld.so.preload配置搜索

Linux 動態共享庫加載器根據/etc/ld.so.preload文件中的配置順序進行逐行廣度搜索，而該配置文件中保存了需要搜索的共享庫路徑。

4.3.3環境變量搜索

在/etc/environment 文件內存放著當前程序運行環境的默認的全部環境變量值。而其中LD_LIBRARY_PATH 項根據指定的動態庫搜索路徑，Linux動態共享庫加載器會根據該選項內的值按順序進行搜索。

4.3.4 ELF文件中的配置信息搜索

任何一個動態鏈接的模塊所依賴的模塊路徑保存在“.dy?namic”段中，由DT_NEED 類型的項表示，動態鏈接器會按照這個路徑去查找DT_RPATH 所指定的路徑，編譯目標代碼時，可以對gcc加入鏈接參數“-Wl，-rpath”指定動態庫搜索路徑。

可以看到，LD_PRELOAD 是Linux 系統中啟動新進程首先要加載 so 的搜索路徑，可以影響程序的運行時的鏈接（Run? time linker），它允許你定義在程序運行前“優先加載”的動態鏈接庫。只要在通過 LD_PRELOAD 加載的.so 中編寫需要 hook 的同名函數，根據Linux對外部動態共享庫的符號引入全局符號表的處理，后引入的符號會被省略，即系統原始的.so（/lib64/ libc.so.6）中的符號會被省略。

4.4繞過基于Linux消息隊列通信的Hook模塊

消息隊列提供了一種在兩個不相關的進程之間傳遞數據的相當簡單且有效的方法，但是對于消息隊列的使用，很容易產生幾點安全風險：

（1）在創建消息隊列的時候對message queue 的權限控制沒有嚴格控制，讓任意非 root 用戶也可以從消息隊列中讀取消息。

（2）在用戶態標識消息隊列的MSGID很容易通過“ipcs”指令得到，從而攻擊者可以獲取到和Hook模塊相同的消息隊列，從中讀取消息。

（3）Linux下的消息隊列是內核態維護的一個消息隊列，每個消息只能被“取出”一次。

（4）當系統中存在多個進程同時在從同一個消息隊列中“消費”消息的時候，對消息隊列中消息的獲取的順序是一個“競態條件”，誰先獲取到消息取決進程的內核調度優先級以及接收進程自身的接收邏輯，為了提高“競態條件”的“獲勝率”，可以使用nice（-20）提高進程的靜態優先級，從而間接影響到內核調度優先級。

綜合以上四點就可以得出一種攻擊“監控軟件”本身的技術方式，如果監控軟件使用消息隊列進行日志的通信，則攻擊者可以通過這種方式強制取出隊列中的消息，從而使監控軟件的監控失效。

4.5基于ptrace（）調試技術進行API Hook

Linux 系統基于調試器（Debuger）思想在用戶層提供了一種調試機制ptrace。ptrace是一種父進程可以控制子進程運行，可以檢查和改變它的核心image，它主要用于實現斷點調試。一個被跟蹤的進程運行中，直到發生一個信號。則進程被中止，并且通知其父進程。在進程中止的狀態下，進程的內存空間可以被讀寫。父進程還可以使子進程繼續執行，并選擇是否忽略引起中止的信號。

利用Linux系統提供的ptrace（）技術，可以主動注入方式，注入程序中從而達到Hook程序的API效果。總體思路如下

（1）使用Linux Module、或者LSM掛載點對進程的啟動動作進行實時的監控，并通過Ring0-Ring3通信通知到Ring3程序有新進程啟動的動作。

（2）用ptrace函數attach 上目標進程。

（3）讓目標進程的執行流程跳轉到mmap函數來分配一小段內存空間。

（4）把一段機器碼拷貝到目標進程中剛分配的內存中去。

（5）最后讓目標進程的執行流程跳轉到注入的代碼執行。

4.6容器內進程阻斷方案可行性

從主機側看容器本身只是一個特殊的進程，而在容器內的進程也只是以容器進程為父進程生成的子系進程。而本質的進程生成的方式和方式，在上面4.1小節已經分析過，只有三種方式;并且最終換可執行加載成可執行程序，也只有唯一一種途徑;而該方法也是同樣用于容器內部的進程生成，那么在容器內部只要對唯一的途徑做攔截，再根據特征值做檢測就可以。

只要有一種技術方案可以做到在容器內部對唯一途徑的攔截，方案就可以得到實施，也就是對execve（）函數做控制監控。

而在4.3小節里面提到的四種動態連接 so 函數劫持Hook 方法，其實除4.3.4小節的方法跟運行程序本身有關，其它方法都和運行的環境變量有關。而容器運行因為命名空間的隔離性，在真實的容器內部是完全獨立于主機，那么如果通過修改環境變量的方式來做execve（）函數的劫持監控是可以的，并且不會干擾到主機的環境變量。

4.4小節中的對消息隊列通信做Hook，在容器內也是可以。同樣也是因為容器的命名空間的隔離性，會為容器單獨隔離出自己的消息隊列用來通信，所以在容器內部對消息隊列做通信 Hook也是可行的。

而4.5是使用主機上的ptrace（）調用技術做Hook，需要在主機側對容器內部的進程做實時的監控，但是也只能監控到單個的進程生成，進程的子系進程無法再進行監控。

5容器內進程阻斷

根據第4節的分析，在容器內可以應用多個Hook方案。而在4.1小節內分析的進程生成流程，真正能用在容器內Hook到execve（）系統調用API 函數的只有：LD_PRELOAD 和ptrace（）系統調用功能。

而ptrace（）功能的應用是有幾個前提條件：

（1）有一個能承載ptrace（）功能的運行程序。

（2）知道當前平臺系統可執行文件加載函數execve（）系統調用對應的映射編號。不同的Linux 內核版本對應的映射可能會不一樣，不同的硬件架構平臺不一樣，對應的映射可能會不一樣。

（3）需要承載ptrace（）功能的運行程序，要知道被監控程序的運行信息，一般都以pid為監控條件。

但在容器內，因為PID Namepace的進程隔離性，在容器內部獲取到的pid并不是真實的進程pid。使用ptrace功能就不能真實地捕獲到容器內部的進程運行情況，從而無法監控到內部的系統調用情況，更無法獲取到execve（）系統調用是否在容器內部被使用。

根據Linux對外部動態共享庫的符號引入全局符號表的處理，后引入的符號會被省略，即系統原始的.so（/lib64/libc.so.6）中的符號會被省略。而 LD_PRELOAD 是環境變量，用于動態庫的加載，動態庫加載的優先級最高，一般情況下，其加載順序為 LD_PRELOAD > LD_LIBRARY_PATH >/etc/ld.so.cache>/lib>/ usr/lib 。如圖5所示。

所以使用LD_PRELOAD 指定自己的so 來“覆蓋”系統調用接口，從而可以達到檢查系統調用接口，和參數的目的。當接口和參數特征是需要阻斷的直接阻斷返回。

6結語

云原生是為了能構建一種符合云計算特性的標準來指導云計算應用的編寫。而容器作為當前云原生架構下基礎組件之一，容器自身的安全直接影響整個云原生架構的安全性。

在享受著容器技術便利性的同時，往往會忽略對容器環境的安全加固。在彈性的容器環境中配置安全監控和防護軟件顯然是個費時費力且消耗資源的事情。雖然容器自身在設計之初就帶有一定的安全考慮因素，再加上容器廠商的二次封閉設計對安全性進行了進一步的加強，但同時也造成了一定量的攻擊面的增強。

隨著容器虛擬技術的不斷發展，容器已經作為微服務、API 服務、業務服務等多種服務的載體，并成為保護服務的最后一道安全屏障。不管是對容器自身運行的保障，還是對容器內的業務的管理，容器被攻擊的風險都是不能忽略的。

本次研究利用容器的重要特性“容器的行為都是事先預定且固化的”，那么任何超出預定范圍內的行為都代表著異常和攻擊。充分利用這個特性作為容器惡意攻擊的特點。而所有的攻擊行為都需要應用程序做行為承接點才能實施;而容器本身只是Linux 系統下的一個特殊進程，只要是進程就一定要遵守Linux進程的生成流程和機制。Linux 的系統調用接口作為內核層與應用層之間的“橋梁”，而對應的接口庫的加載優先級是存放在LD_PRELOAD 內。通過修改優先級來優先加載進程生成過濾策略，從而達到在應用層阻斷惡意進程的生成。參考文獻：

[1]徐孝晉，伍澤軍，鄧文杰，等. 基于開源平臺的docker 安全性分析 [C]//2019電力行業信息化年會論文集. 無錫 ， 2019：175-178.

[2]魯濤， 陳杰，史軍.Docker安全性研究[J].計算機技術與發展， 2018，28（6）：115-120.

[3]胡俊，李漫.容器安全解決方案探討與研究[J].網絡空間安全， 2018，9（12）：105-113.

[4]劉曉毅，王進，馮中華，等.容器云安全風險分析及防護體系設計[J].通信技術，2020，53（12）：3065-3071.

[5] DoSec安全團隊.Docker容器最佳安全實踐白皮書[R].中國： DoSec，2018.

[6]綠盟星云實驗室.綠盟科技容器安全技術報告[R].中國：綠盟科技，2018.

[7]陳偉，涂俊亮.Docker容器安全的分析研究[J].通信技術，2020， 53（12）：3072-3077.

【通聯編輯：代影】