范源藝 張?jiān)鲕? 徐成華 魏育成 蔡剛 朱科鍵

DOI：10.16660/j.cnki.1674-098X.2103-5640-1373

摘? 要：隨著云計(jì)算的快速發(fā)展，容器技術(shù)越來(lái)越多地引起廣泛關(guān)注。同時(shí)容器也面臨著很多安全風(fēng)險(xiǎn)而且對(duì)容器入侵檢測(cè)技術(shù)的研究尚處于探索研究階段。本文從云容器的背景技術(shù)出發(fā)，分析了容器安全領(lǐng)域中面臨的各種風(fēng)險(xiǎn)問(wèn)題，進(jìn)而從容器漏洞、主機(jī)、網(wǎng)絡(luò)3個(gè)層面論述了容器異常入侵檢測(cè)技術(shù)的最新發(fā)展和在容器安全領(lǐng)域中的深入應(yīng)用。另外，本文歸納了容器安全領(lǐng)域中面向深度學(xué)習(xí)算法的數(shù)據(jù)集現(xiàn)狀以及現(xiàn)用的容器安全商業(yè)解決方案，最后，展望了異常檢測(cè)技術(shù)在容器安全領(lǐng)域的發(fā)展趨勢(shì)和應(yīng)用前景。

關(guān)鍵詞：云計(jì)算? 容器安全? 異常檢測(cè)? 虛擬化

中圖分類(lèi)號(hào)：TP393.08? ? ? ? ? ? ? ? ? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1674-098X（2021）05（a）-0118-08

Survey of Cloud Container Security Oriented Anomaly Detection Technology

FAN Yuanyi1，2? ?ZHANG Zengjun2? XU Chenghua2，3? WEI Yucheng3，4? CAI Gang2? ZHU Kejian1，2

（1. University of Chinese Academy of Sciences， Beijing， 100049? China; 2. Aerospace Information Research Institute， Chinese Academy of Sciences， Beijing， 100190? China;3. GEODO（Beijing）， Beijing 100190 China; 4. Shenzhen Research Center of Digital City Engineering， beijing， 100190? China）

Abstract： With the rapid development of cloud computing， container technology is attracting wide attentions. However， containers also face many unknown security risks， the research on container intrusion detection technology is still in the preliminary exploration stage. This paper analyzes the various risks in the container security field on the basis of the background technology of cloud container， and further discusses the latest development of container anomaly intrusion detection technology and its deep-going applications in the container security field from three aspects of container vulnerability， host and network. Moreover， the status of data sets for deep learning algorithms in container security field and the current container security business solutions are summarized. Finally， we very briefly conclude the future trend and application perspectives of anomaly detection technology in the field of container security field.

Key Words： Cloud computing; Container security; Anomaly detection; Virtualization

基于云計(jì)算的容器技術(shù)，或稱(chēng)為“云容器”。云容器技術(shù)是云計(jì)算領(lǐng)域最近發(fā)展起來(lái)的一項(xiàng)重要技術(shù)，介于傳統(tǒng)分配計(jì)算資源的進(jìn)程和虛擬機(jī)技術(shù)之間，是一類(lèi)輕量化且高度隔離的虛擬化技術(shù)。云容器技術(shù)在特定操作系統(tǒng)內(nèi)核上直接分配存儲(chǔ)資源，可以允許更加便攜的資源部署與快捷的應(yīng)用執(zhí)行，不僅可以實(shí)現(xiàn)跨平臺(tái)、標(biāo)準(zhǔn)化、微型化、敏捷化的交付，還可提高資源的利用率，具有十分廣闊的應(yīng)用前景。

同時(shí)，處于發(fā)展初期的云容器在實(shí)際應(yīng)用過(guò)程中存在著諸多問(wèn)題，其中安全問(wèn)題尤為突出。容器安全工具和程序相較于以往針對(duì)永久性應(yīng)用程序的安全軟件需要具備更高的可見(jiàn)性，目前還較為匱乏。針對(duì)云容器潛在的入侵安全隱患，入侵檢測(cè)是預(yù)防和解決問(wèn)題的第一步。由于目前還處于云容器發(fā)展初期，所以有必要細(xì)致地歸類(lèi)容器安全問(wèn)題并分析相關(guān)入侵檢測(cè)技術(shù)的應(yīng)用情況，為該領(lǐng)域的后續(xù)研究提供參考依據(jù)。

本文結(jié)合實(shí)例全面介紹現(xiàn)有的典型云容器入侵檢測(cè)技術(shù)，旨在作出詳盡總結(jié)與分析，拓展了本領(lǐng)域關(guān)于云容器安全的研究調(diào)查。本文的組織結(jié)構(gòu)如下：第一節(jié)概述了關(guān)于云容器、容器安全的背景知識(shí);第二節(jié)分析入侵檢測(cè)技術(shù)在云容器安全領(lǐng)域的應(yīng)用;第三節(jié)總結(jié)入侵檢測(cè)技術(shù)在云容器安全領(lǐng)域常用的數(shù)據(jù)集以及常用的容器安全商業(yè)方案;第四節(jié)提出了應(yīng)用領(lǐng)域未解決的一些問(wèn)題和即將遇到的挑戰(zhàn)。

1? 云容器基本概念和安全機(jī)制

云計(jì)算給互聯(lián)網(wǎng)帶來(lái)了巨大的變革，分布式應(yīng)用程序和基礎(chǔ)設(shè)施逐漸從以虛擬機(jī)（VM）為中心轉(zhuǎn)向以容器為中心。傳統(tǒng)虛擬機(jī)通過(guò)模擬計(jì)算機(jī)硬件來(lái)實(shí)現(xiàn)虛擬化[1]，同一平臺(tái)的每個(gè)虛擬機(jī)具有獨(dú)立的操作系統(tǒng)、物理資源等，當(dāng)虛擬機(jī)數(shù)量過(guò)多時(shí)會(huì)對(duì)平臺(tái)的性能和內(nèi)存造成影響。而容器技術(shù)是輕量級(jí)的虛擬化，屬于操作系統(tǒng)級(jí)別的虛擬化，許多容器可以共享計(jì)算機(jī)的操作系統(tǒng)內(nèi)核，達(dá)到類(lèi)似硬件虛擬化的效果而無(wú)額外操作系統(tǒng)的開(kāi)銷(xiāo)，從而提高了服務(wù)器效率并降低了服務(wù)器成本。

1.1 云容器基本原理和應(yīng)用

容器技術(shù)的虛擬化依托于 Linux 內(nèi)核的 LXC技術(shù)，輔以命名空間技術(shù)（Namespaces）隔離不同的容器[2]。同一主機(jī)上的各個(gè)容器對(duì)應(yīng)單個(gè)服務(wù)應(yīng)用，容器內(nèi)僅包含應(yīng)用程序和必要的運(yùn)行庫(kù)，并共享宿主機(jī)內(nèi)核，對(duì)主機(jī)系統(tǒng)的 CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)等資源進(jìn)行隔離、分配和管理。這樣，每個(gè)容器都可以視為獨(dú)立的操作系統(tǒng)，從而使系統(tǒng)架構(gòu)更加簡(jiǎn)單高效。

容器在高性能計(jì)算、大數(shù)據(jù)分析應(yīng)用等眾多領(lǐng)域得到廣泛應(yīng)用。如今，超級(jí)計(jì)算平臺(tái)的開(kāi)發(fā)者利用容器需要能夠輕松部署他們自己開(kāi)發(fā)的軟件或者虛擬機(jī)集群的解決方案。游戲“Pokemon GO”使用kubernetes集群部署在Google云平臺(tái)，根據(jù)流量的波動(dòng)情況靈活創(chuàng)建或銷(xiāo)毀容器，使得其能夠有效地服務(wù)于百萬(wàn)用戶(hù)，基于容器的開(kāi)發(fā)為用戶(hù)提供了更好的體驗(yàn)。容器在醫(yī)療行業(yè)也得到了廣大應(yīng)用，Boonma[3]等人使用容器化部署數(shù)據(jù)分析平臺(tái)來(lái)分析醫(yī)療保健和生物醫(yī)學(xué)數(shù)據(jù)。在未來(lái)云計(jì)算乃至整個(gè)信息技術(shù)領(lǐng)域的發(fā)展中，容器將以其高效、便捷的特性扮演不可替換的角色[1]。

1.2 云容器安全威脅分析

容器作為現(xiàn)下流行的應(yīng)用程序部署平臺(tái)，其易于部署的特性造成容器容易出現(xiàn)各種安全威脅，由目前的研究現(xiàn)狀看來(lái)，典型的云容器安全事件主要集中在以下幾個(gè)方面。

1.2.1 基于內(nèi)核漏洞的安全威脅

安全漏洞廣泛存在于官方鏡像和社區(qū)鏡像中，舊版本的漏洞可能會(huì)暴露在各種類(lèi)型的攻擊（例如，拒絕服務(wù)、特權(quán)提升、執(zhí)行任意代碼），并且漏洞會(huì)由于鏡像之間的依賴(lài)關(guān)系而傳播。再者容器鏡像通常沒(méi)有訪問(wèn)限制，默認(rèn)設(shè)置為root權(quán)限[4]，這樣不僅會(huì)引發(fā)容器運(yùn)行時(shí)的入侵攻擊，還有可能在被入侵后進(jìn)行特權(quán)提升，造成不可預(yù)估的嚴(yán)重后果。若在容器使用root權(quán)限時(shí)遭到入侵者攻擊容器時(shí)，則入侵者有可能獲得整個(gè)系統(tǒng)的控制權(quán)限。

1.2.2 逃逸攻擊

容器逃逸指攻擊者通過(guò)劫持容器化業(yè)務(wù)邏輯獲得容器內(nèi)某種權(quán)限下的命令執(zhí)行能力，攻擊者利用這種命令執(zhí)行能力，借助一些手段進(jìn)一步獲得該容器所在直接宿主機(jī)上某種權(quán)限下的命令執(zhí)行能力[5]。如利用CVE-2019-5736 攻擊先前對(duì)其具有寫(xiě)訪問(wèn)權(quán)的現(xiàn)有容器，進(jìn)行exec操作可以獲取到宿主機(jī)的runC執(zhí)行時(shí)的文件句柄并修改掉runc的二進(jìn)制文件，從而獲取到宿主機(jī)的root執(zhí)行權(quán)限[6]。

1.2.3 拒絕服務(wù)攻擊

容器的拒絕服務(wù)攻擊當(dāng)單個(gè)容器耗盡宿主機(jī)的計(jì)算資源或存儲(chǔ)資源（例如進(jìn)程數(shù)量、存儲(chǔ)空間等）可能導(dǎo)致宿主機(jī)或其他容器的拒絕服務(wù)[7]。Fork Bomb是一類(lèi)典型的針對(duì)計(jì)算資源的拒絕服務(wù)攻擊手段，其可通過(guò)遞歸方式無(wú)限循環(huán)調(diào)用fork（）系統(tǒng)函數(shù)快速創(chuàng)建大量進(jìn)程[8]。由于內(nèi)核支持的進(jìn)程總數(shù)有限，當(dāng)某個(gè)容器遭到了Fork Bomb攻擊，那么就有可能存在由于短時(shí)間內(nèi)在該容器內(nèi)創(chuàng)建過(guò)多進(jìn)程而耗盡宿主機(jī)進(jìn)程資源的情況，宿主機(jī)及其他容器就無(wú)法再創(chuàng)建新的進(jìn)程。

1.2.4 針對(duì)組網(wǎng)模式容器網(wǎng)絡(luò)攻擊

容器內(nèi)部的數(shù)據(jù)包經(jīng)過(guò)虛擬網(wǎng)絡(luò)接口對(duì)到達(dá)虛擬，實(shí)現(xiàn)同一子網(wǎng)內(nèi)不同容器間的通信。若容器間沒(méi)有防火墻等保護(hù)機(jī)制，則攻擊者可通過(guò)某個(gè)容器對(duì)宿主機(jī)內(nèi)的其他容器進(jìn)行ARP欺騙、嗅探、廣播風(fēng)暴等攻擊，導(dǎo)致信息泄露、影響網(wǎng)絡(luò)正常運(yùn)行等安全后果。

1.2.5 網(wǎng)絡(luò)拒絕服務(wù)（DoS）攻擊

由于網(wǎng)絡(luò)虛擬化的存在，在宿主機(jī)內(nèi)部的容器之間可以直接發(fā)起網(wǎng)絡(luò)拒絕服務(wù)攻擊。當(dāng)攻擊者通過(guò)某個(gè)容器向其他容器發(fā)起拒絕服務(wù)攻擊時(shí)會(huì)對(duì)其他容器的網(wǎng)絡(luò)數(shù)據(jù)處理能力造成影響。另外，若在容器外部使用包含大量受控主機(jī)的僵尸網(wǎng)絡(luò)向某一個(gè)目標(biāo)容器發(fā)送大量數(shù)據(jù)包進(jìn)行分布式拒絕服務(wù)攻擊，將可能占滿宿主機(jī)的網(wǎng)絡(luò)帶寬資源，造成宿主機(jī)和其他容器的拒絕服務(wù)[7]。

1.3 云容器安全機(jī)制

容器作為云計(jì)算新型的虛擬化技術(shù)，有其獨(dú)特的安全機(jī)制。容器安全機(jī)制可分為鏡像安全、Docker Daemon安全、內(nèi)核安全和一些附加機(jī)制[9]。鏡像文件是用來(lái)創(chuàng)建容器的可讀模板，鏡像安全需要用戶(hù)確保下載的鏡像源是可信的，且未被篡改過(guò)的。因此， 保證Docker的鏡像安全至關(guān)重要。Docker Daemon是Docker容器運(yùn)行的核心服務(wù)，而容器服務(wù)的運(yùn)行需要root權(quán)限，因此一旦相關(guān)的組件被攻擊者攻陷，那么攻擊者就會(huì)獲取root權(quán)限。Docker? Daemon安全需要避免與其相關(guān)的組件被攻擊者攻陷進(jìn)而獲取容器服務(wù)運(yùn)行的root權(quán)限。內(nèi)核安全通過(guò)命名空間和CGroups分別實(shí)現(xiàn)對(duì)容器資源隔離和資源限制的功能。命名空間隔離了進(jìn)程之間可訪問(wèn)的資源集合，實(shí)現(xiàn)對(duì)容器環(huán)境中的資源進(jìn)行方方面面的隔離，并且容器中的操作不會(huì)對(duì)宿主機(jī)產(chǎn)生影響。CGroups可以用來(lái)限制、計(jì)算、隔離一組進(jìn)程的資源，其余附加機(jī)制如權(quán)限機(jī)制可以提供細(xì)粒度的權(quán)限訪問(wèn)控制。

然而現(xiàn)有的容器安全機(jī)制不足以全部解決云容器的安全威脅。Xin Lin[10]等人篩選88個(gè)典型漏洞對(duì)現(xiàn)有容器機(jī)制的安全性進(jìn)行評(píng)估，結(jié)果證明，56.82%的漏洞在默認(rèn)配置下仍能被成功利用，從容器內(nèi)部發(fā)起攻擊。因此，僅通過(guò)容器內(nèi)核機(jī)制地?zé)o法保證容器安全，入侵檢測(cè)作為防范潛在安全問(wèn)題的有效手段，對(duì)于彌補(bǔ)容器安全機(jī)制在實(shí)際云環(huán)境中的不足。

2? 異常入侵檢測(cè)技術(shù)在云容器安全領(lǐng)域中的應(yīng)用

對(duì)容器進(jìn)行入侵檢測(cè)的首要步驟是安裝安全監(jiān)控進(jìn)行容器信息數(shù)據(jù)采集，入侵檢測(cè)技術(shù)的可靠與否很大程度上取決于采集的前期數(shù)據(jù)是否準(zhǔn)確?，F(xiàn)有的容器安全監(jiān)控主要分為兩類(lèi)，第一類(lèi)方案借鑒傳統(tǒng)主機(jī)在系統(tǒng)中添加安全服務(wù)的方式，通過(guò)在容器中添加監(jiān)視代理監(jiān)控其異常行為;第二類(lèi)方案采用無(wú)代理監(jiān)控方式在容器外部對(duì)容器進(jìn)行監(jiān)控。大部分學(xué)者在進(jìn)行容器入侵檢測(cè)方法的研究中會(huì)采用這些檢測(cè)工具幫助完成獲取容器信息。如Alex Borhani[11]認(rèn)為Falco[12]和sysdig[13]結(jié)合是容器化機(jī)及其編排環(huán)境中理想的開(kāi)源異常檢測(cè)框架，驗(yàn)證了在容器化及其編排環(huán)境中下檢測(cè)異常，對(duì)存在的異常發(fā)出警報(bào)并對(duì)該事件響應(yīng)消除異常的可行性。后者采用無(wú)代理監(jiān)控方式，可減少因?yàn)樘砑颖O(jiān)控代理服務(wù)而引入的額外攻擊面，并且可以彌補(bǔ)一些檢測(cè)工具在容器中對(duì)未知惡意軟件檢測(cè)的缺失。如金逸靈[14]采用無(wú)監(jiān)控代理分層處理容器各層文件，實(shí)現(xiàn)在容器外部的主機(jī)用戶(hù)層提取容器鏡像、未運(yùn)行和運(yùn)行中容器內(nèi)的待測(cè)軟件。

傳統(tǒng)的異常入侵檢測(cè)技術(shù)根據(jù)檢測(cè)源可分為基于主機(jī)的異常檢測(cè)技術(shù)和基于網(wǎng)絡(luò)的入侵檢測(cè)技術(shù)。由于云環(huán)境的特殊性以及容器鏡像可靠的必要性，容器極有可能因?yàn)楸┞兜穆┒丛馐艿焦?，因此，?duì)容器及其鏡像進(jìn)行漏洞檢測(cè)極其重要，針對(duì)容器的安全檢測(cè)技術(shù)從檢測(cè)源可分為基于主機(jī)的容器異常檢測(cè)技術(shù)、基于網(wǎng)絡(luò)的容器異常檢測(cè)技術(shù)和基于漏洞利用的容器安全檢測(cè)技術(shù)。

2.1 基于主機(jī)的容器異常入侵檢測(cè)

針對(duì)主機(jī)的容器安全入侵檢測(cè)，根據(jù)檢測(cè)類(lèi)型的不同可進(jìn)一步分為基于容器系統(tǒng)調(diào)用和基于容器系統(tǒng)資源的容器異常檢測(cè)方法。

在傳統(tǒng)主機(jī)領(lǐng)域下基于系統(tǒng)調(diào)用的入侵檢測(cè)方案，往往針對(duì)單一特權(quán)進(jìn)程的運(yùn)行行為進(jìn)行監(jiān)控，而在容器環(huán)境下引入了更多的安全風(fēng)險(xiǎn)。對(duì)異常識(shí)別來(lái)說(shuō)，一個(gè)重要的表征是特征選取的是否合適。系統(tǒng)調(diào)用作為應(yīng)用程序訪問(wèn)操作系統(tǒng)服務(wù)的接口，容器的攻擊行為通常可以通過(guò)系統(tǒng)調(diào)用來(lái)表現(xiàn)。當(dāng)前的系統(tǒng)調(diào)用特征提取方法有兩類(lèi)，第一，抽取系統(tǒng)調(diào)用子序列作為特征。第二，使用系統(tǒng)調(diào)用序列的頻率作為特征。

Abed[15]等人提出使用系統(tǒng)調(diào)用來(lái)檢測(cè)容器環(huán)境中的惡意應(yīng)用程序，使用基于頻率的方法，每個(gè)系統(tǒng)調(diào)用序列都被維護(hù)為一個(gè)n-gram，以考慮系統(tǒng)調(diào)用發(fā)生的比例，同時(shí)考慮系統(tǒng)調(diào)用發(fā)生的順序，結(jié)果取得很高的召回率100%，以及很低的誤報(bào)率2%。Siddharth Srinivasan[16]在此基礎(chǔ)上提出了一種概率實(shí)時(shí)n-gram入侵檢測(cè)方法。系統(tǒng)調(diào)用的每個(gè)序列都以n-gram的形式維護(hù)，計(jì)算這些n-gram出現(xiàn)的概率累積用于該次監(jiān)視容器會(huì)話的總體相對(duì)n-gram概率。實(shí)驗(yàn)結(jié)果顯示，該方法的準(zhǔn)確度介于87%～97%，召回率介于78%～100%，誤報(bào)率介于0%～14%，這種方法可以檢測(cè)在Docker容器中運(yùn)行的應(yīng)用程序中發(fā)生的特洛伊木馬（Trojan）攻擊，DoS、DDoS和SQL注入等攻擊時(shí)實(shí)現(xiàn)更高的準(zhǔn)確性。

J. Flora[17]提出一種使用攻擊注入來(lái)評(píng)估容器中入侵檢測(cè)技術(shù)的有效性，文章對(duì)幾種典型的機(jī)器學(xué)習(xí)方法進(jìn)行實(shí)驗(yàn)比較，包括STIDE[18]、BoSC[19]和HMM[20]，其中STIDE和HMM是基于系統(tǒng)調(diào)用序列的方法，BoSC是基于系統(tǒng)調(diào)用頻率的方法。結(jié)果顯示，容器中BoSC和STIDE的召回率達(dá)到97%，而HMM的召回率僅達(dá)到70%，HMM的性能從召回率和精度上明顯低于前者，但HMM分類(lèi)器的訓(xùn)練時(shí)間較短。對(duì)于更復(fù)雜的工作負(fù)載，誤報(bào)率會(huì)明顯下降，其中BoSC比STIDE的效果更好，表明基于頻率的方法更適用于此環(huán)境，而基于序列的方法具有多種組合方式從而需要更長(zhǎng)的時(shí)間學(xué)習(xí)。

隨著容器數(shù)目的增加和減少，在動(dòng)態(tài)容器環(huán)境中同時(shí)監(jiān)測(cè)多個(gè)資源，能夠及時(shí)對(duì)異常檢測(cè)以保證云服務(wù)的質(zhì)量至關(guān)重要。Zhuping Zou[21]提出一種基于優(yōu)化iForest算法的容器多維資源異常檢測(cè)方法，該算法對(duì)容器的CPU使用率、內(nèi)存使用率、磁盤(pán)讀寫(xiě)速率和網(wǎng)絡(luò)速度4項(xiàng)資源監(jiān)控，在iForest算法的基礎(chǔ)上作出改進(jìn)，采用加權(quán)特征選擇而非隨機(jī)特征的選擇方法為監(jiān)控上述4項(xiàng)指標(biāo)。同時(shí)設(shè)置資源度量，系統(tǒng)根據(jù)資源度量為每個(gè)資源指標(biāo)分配一個(gè)權(quán)重。如果容器應(yīng)用程序嚴(yán)重依賴(lài)于資源度量，系統(tǒng)將為該資源度量分配一個(gè)較大的值。因此，如果一個(gè)權(quán)值較大的資源度量處于異常狀態(tài)，則更容易選擇它作為特征來(lái)劃分?jǐn)?shù)據(jù)集，從而更準(zhǔn)確地識(shí)別出異常。實(shí)驗(yàn)結(jié)果表明，改進(jìn)后的算法在CPU使用率和網(wǎng)絡(luò)速度的異常檢測(cè)率最好可達(dá)到100%，效果最好;而磁盤(pán)讀寫(xiě)率的異常檢測(cè)率最低為76%且有著最高的5%誤報(bào)率，效果較差。

由于人工神經(jīng)網(wǎng)絡(luò)可以自適應(yīng)、自學(xué)習(xí)已知的輸入數(shù)據(jù)和輸出數(shù)據(jù)集合，抽象出其內(nèi)在聯(lián)系，從而得到新的映射關(guān)系。Chin-Wei Tien[22]等人使用神經(jīng)網(wǎng)絡(luò)的方法對(duì)Docker編排平臺(tái)K8S進(jìn)行異常檢測(cè)。該方法通過(guò)原始監(jiān)視日志和硬件資源信息對(duì)容器內(nèi)存、系統(tǒng)調(diào)用、文件I/O、網(wǎng)絡(luò)I/O進(jìn)行檢測(cè)。KubAnomaly由4個(gè)全連接層組成，從第一層到第三層使用線性指數(shù)單元ELU作為激活函數(shù)，最后一層使用softmax作為激活函數(shù)。實(shí)驗(yàn)結(jié)果表明，該算法可達(dá)到98%的檢測(cè)率，且能夠有效的檢測(cè)出注入攻擊和拒絕服務(wù)攻擊。

基于容器系統(tǒng)資源的異常檢測(cè)模型也可以考慮組件之間的關(guān)系，從而避免誤報(bào)率高的情況發(fā)生。Chengzhi Lu[23]團(tuán)隊(duì)提出了一種云容器中基于圖相似性的異常檢測(cè)與根源定位方法。通過(guò)監(jiān)控應(yīng)用程序中每個(gè)組件的響應(yīng)時(shí)間和資源使用情況，構(gòu)造異常檢測(cè)和定位的系統(tǒng)的狀態(tài)圖。邊緣權(quán)重表示響應(yīng)時(shí)間或者系統(tǒng)性能指標(biāo)，圖的頂點(diǎn)分別表示容器中運(yùn)行組件的頂點(diǎn)和物理機(jī)的頂點(diǎn);圖的邊分別表示組件之間存在關(guān)系的有向邊，邊的權(quán)重表示啟動(dòng)組件的響應(yīng)時(shí)間或表示組件與物理機(jī)的關(guān)聯(lián)，邊的權(quán)重表示組件的資源利用率。狀態(tài)圖的3種變化：應(yīng)用組件丟失、物理機(jī)丟失、邊緣權(quán)重變化以確定系統(tǒng)狀態(tài)是否正常。實(shí)驗(yàn)表明，這種方法召回率可達(dá)到80%，不僅可以反映出容器應(yīng)用的整體狀態(tài)，并且可以準(zhǔn)確定位異常。

除上述異常檢測(cè)方法以外，基于主機(jī)的容器安全入侵檢測(cè)還可以對(duì)特定行為進(jìn)行異常檢測(cè)。簡(jiǎn)志強(qiáng)[2]針對(duì)docker面臨的被惡意用戶(hù)利用內(nèi)核漏洞進(jìn)行攻擊的行為，提出一種基于進(jìn)程所屬命名空間狀態(tài)的檢測(cè)方法檢測(cè)容器逃逸，這種方式也可看作為基于容器安全機(jī)制的異常檢測(cè)方法。由于docker容器的本質(zhì)是進(jìn)程，容器內(nèi)的進(jìn)程相當(dāng)于守護(hù)進(jìn)程的子進(jìn)程，通過(guò)獲取當(dāng)前進(jìn)程的狀態(tài)標(biāo)識(shí)與初始化進(jìn)程（宿主進(jìn)程）的狀態(tài)標(biāo)識(shí)進(jìn)行對(duì)比，如果相同則判定異常。這種方法能夠有效檢測(cè)出容器逃逸攻擊行為，但不能對(duì)容器的其他安全風(fēng)險(xiǎn)作出有效檢測(cè)。Gao X[24]提出了檢測(cè)容器環(huán)境中信息泄漏通道的解決方案，該方案能夠檢測(cè)到云容器主機(jī)中的內(nèi)部威脅，然而這些威脅只包括與信息泄露相關(guān)的攻擊，不能有效地檢測(cè)其他類(lèi)型的攻擊，如web服務(wù)攻擊。

2.2 基于網(wǎng)絡(luò)的容器異常入侵檢測(cè)

隨著網(wǎng)絡(luò)流量的增加以及攻擊變得更加廣泛復(fù)雜，研究者們提出蜜罐作為輔助工具研究云計(jì)算中的基于網(wǎng)絡(luò)的容器安全入侵檢測(cè)算法。蜜罐是放置在網(wǎng)絡(luò)中的誘餌系統(tǒng)，一旦受到攻擊或者破壞，與攻擊者的交互會(huì)被記錄下來(lái)，是網(wǎng)絡(luò)安全中常用的技術(shù)手段。

Elazazy[25]等人首次將蜜罐引入云計(jì)算中，實(shí)現(xiàn)了在云環(huán)境下Docker容器上實(shí)現(xiàn)HoneyProxy框架部署。HoneyProxy是一種基于SDN控制器全局所有內(nèi)部流量的蜜網(wǎng)，當(dāng)HoneyProxy連接在同一云服務(wù)器上的HoneyFarm時(shí)，每個(gè)蜜罐都在一個(gè)docker容器中為每個(gè)唯一的IP提供服務(wù)，因此每個(gè)攻擊會(huì)話都可以在一個(gè)容器中隔離，并能夠在不同類(lèi)型的容器之間切換，從而在不被懷疑的情況下欺騙攻擊者蜜罐的存在。這種容器與新一代蜜網(wǎng)結(jié)合的防御機(jī)制可以檢測(cè)并記錄攻擊者的行為，有助于發(fā)現(xiàn)新的攻擊技術(shù)和零日漏洞。Andronikos Kyriakou[26]等人通過(guò)T-Pot[27]分別在Linux主機(jī)、Windows主機(jī)和Web應(yīng)用程序部署蜜罐，并通過(guò)整合Virus Total實(shí)現(xiàn)對(duì)所有惡意軟件樣本的自動(dòng)分析，進(jìn)而實(shí)現(xiàn)在多個(gè)蜜罐部署下的docker容器攻擊者行為的實(shí)時(shí)監(jiān)測(cè)。Krishnaveni S[28]等人提出一種基于機(jī)器學(xué)習(xí)和蜜罐數(shù)據(jù)集的集成方法實(shí)現(xiàn)對(duì)云容器進(jìn)行網(wǎng)絡(luò)入侵檢測(cè)和分類(lèi)，作者使用樸素貝葉斯、支持向量機(jī)和Logistic回歸作為基礎(chǔ)分類(lèi)器對(duì)測(cè)試實(shí)例進(jìn)行分類(lèi)，再使用多數(shù)投票算法集成分類(lèi)模型。實(shí)驗(yàn)表明，當(dāng)分別使用樸素貝葉斯算法的檢測(cè)率和召回率均為88%;支持向量機(jī)算法的支持率88%，召回率90%;邏輯回歸算法的檢測(cè)率和召回率83%;而當(dāng)使用集成方法時(shí)，準(zhǔn)確率達(dá)到93%，召回率為92%，驗(yàn)證了這種使用多分類(lèi)器的組合的集成方法使網(wǎng)絡(luò)系統(tǒng)中的入侵檢測(cè)準(zhǔn)確率更高。

2.3 基于漏洞利用的容器安全檢測(cè)

目前常用的容器漏洞檢測(cè)方案通過(guò)容器鏡像掃描進(jìn)行靜態(tài)漏洞檢測(cè)，這些靜態(tài)鏡像掃描工具將包和鏡像版本與遠(yuǎn)程的公共漏洞庫(kù)和CVE數(shù)據(jù)庫(kù)進(jìn)行匹配檢測(cè)庫(kù)中已存在的漏洞。然而不能檢測(cè)到現(xiàn)有CVE數(shù)據(jù)庫(kù)中未包含的漏洞，如未公開(kāi)紕漏的漏洞、零日漏洞。

Soonhong Kwon[29]提出基于通過(guò)容器鏡像中易受攻擊的軟件包和漏洞信息的組合關(guān)系，利用靜態(tài)檢測(cè)工具Clair[30]完成Docker鏡像漏洞檢測(cè)工作后，將Docker鏡像的元數(shù)據(jù)與從一組資源接收的軟件包漏洞信息進(jìn)行比較，以檢測(cè)不安全的已知漏洞。漏洞檢測(cè)結(jié)果包括已分析的Docker鏡像的層ID、鏡像名稱(chēng)、存在的漏洞總數(shù)、未批準(zhǔn)的漏洞數(shù)，CVE嚴(yán)重性，易受攻擊的軟件包名稱(chēng)和版本，以及CVE信息。同時(shí)在漏洞評(píng)分系統(tǒng)（CVSS，Common Vulnerability Scoring System）[31]的基礎(chǔ)上根據(jù)公式分配漏洞嚴(yán)重性得分，對(duì)CVE嚴(yán)重性進(jìn)行評(píng)估。然而由于執(zhí)行靜態(tài)分析的局限性，不能檢測(cè)容器在運(yùn)行期間發(fā)生的異常。

Olufogorehan Tunde-Onadele[32]等人提出動(dòng)靜態(tài)結(jié)合的容器漏洞檢測(cè)方法，其中利用系統(tǒng)調(diào)用頻率和機(jī)器學(xué)習(xí)的方法進(jìn)行容器漏洞利用動(dòng)態(tài)檢測(cè)。作者借助輕量級(jí)開(kāi)源跟蹤工具sysdig[13]對(duì)收集容器系統(tǒng)調(diào)用日志。從原始系統(tǒng)調(diào)用跟蹤日志在同等的采樣時(shí)間間隔內(nèi)分別提取系統(tǒng)調(diào)用頻率特征和系統(tǒng)調(diào)用執(zhí)行時(shí)間特征，分別作為系統(tǒng)調(diào)用頻率向量和系統(tǒng)調(diào)用時(shí)間向量，通過(guò)無(wú)監(jiān)督學(xué)習(xí)算法進(jìn)行異常檢測(cè)，如KNN，Kmeans、KNN-PCA以及SOM自組織神經(jīng)網(wǎng)絡(luò)[33]的方法。實(shí)驗(yàn)漏洞數(shù)據(jù)集分為6類(lèi)漏洞類(lèi)型：返回shell并執(zhí)行任意代碼、執(zhí)行任意代碼、泄露憑證信息、消耗過(guò)多的CPU、程序崩潰、特權(quán)提升。結(jié)果表明，通過(guò)無(wú)監(jiān)督機(jī)器學(xué)習(xí)方法的動(dòng)態(tài)異常檢測(cè)方案，K-NN的漏洞檢測(cè)率最差為32%，KNN-PCA結(jié)合的漏洞檢測(cè)率有所提高，Kmeans的漏洞檢測(cè)率為68%，SOM的漏洞檢測(cè)率最高可達(dá)到75%;除此之外，K-NN只能檢測(cè)到執(zhí)行任意代碼，無(wú)法檢測(cè)其他類(lèi)型的漏洞，KNN-PCA和Kmeans可以檢測(cè)到除特權(quán)提升外其他5種的漏洞類(lèi)型，SOM可以檢測(cè)到所有的漏洞類(lèi)型。對(duì)于Clair靜態(tài)分析工具的檢出率僅為11%，通過(guò)靜態(tài)和動(dòng)態(tài)結(jié)合的方法漏洞覆蓋率可提高到86%。

3? 容器檢測(cè)工具和數(shù)據(jù)集

3.1 常用的商業(yè)容器檢測(cè)工具

隨著容器在實(shí)際應(yīng)用中的普及，越來(lái)越多的開(kāi)發(fā)人員搭建云平臺(tái)環(huán)境完成便捷高效的開(kāi)發(fā)工作，在實(shí)際搭建容器化環(huán)境中，往往需要部署安全監(jiān)控方案來(lái)保障云平臺(tái)安全。目前常用的容器檢測(cè)方案可大致分為靜態(tài)容器鏡像分析和動(dòng)態(tài)運(yùn)行檢測(cè)兩類(lèi)。靜態(tài)檢測(cè)方案主要是通過(guò)容器鏡像掃描進(jìn)行靜態(tài)漏洞檢測(cè)，常用的容器靜態(tài)鏡像掃描工具有Clair[30]、Anchore[34]、Banyan Collector[35]、Dockerscan[36]、OpenSACP[37]，這些靜態(tài)鏡像掃描工具將包和鏡像版本與遠(yuǎn)程的公共漏洞庫(kù)和CVE數(shù)據(jù)庫(kù)進(jìn)行匹配檢測(cè)庫(kù)中已存在的漏洞。然而不能檢測(cè)到現(xiàn)有CVE數(shù)據(jù)庫(kù)中未包含的漏洞，如未公開(kāi)紕漏的漏洞、零日漏洞。容器動(dòng)態(tài)運(yùn)行檢測(cè)是在容器運(yùn)行時(shí)監(jiān)測(cè)容器行為，通過(guò)一些策略來(lái)規(guī)定系統(tǒng)調(diào)用、訪問(wèn)主機(jī)資源等進(jìn)程允許或不允許的行為，進(jìn)而完成檢測(cè)。常見(jiàn)的容器動(dòng)態(tài)檢測(cè)工具有strace實(shí)用程序、Sysdig[13]、 Falco[12]、cAdvisor[38]、The Road to Twistlock 2.0[39]、NeuVector[40]。但這些規(guī)則策略一般都是需要預(yù)定義的，在實(shí)際場(chǎng)景應(yīng)用中有很大的束縛性。

3.2 應(yīng)用數(shù)據(jù)集

目前使用神經(jīng)網(wǎng)絡(luò)方法在容器安全領(lǐng)域中逐漸開(kāi)始應(yīng)用，根據(jù)檢測(cè)對(duì)象的不同采用的方法模型也不盡相同，據(jù)統(tǒng)計(jì)，大部分作者采用公開(kāi)數(shù)據(jù)集用來(lái)驗(yàn)證模型的準(zhǔn)確性，采用私人容器數(shù)據(jù)集論證算法的可靠性。目前用于容器安全領(lǐng)域的公開(kāi)數(shù)據(jù)集有KDD、UNM、CERT、ADFA-LD。除此之外，德國(guó)電信公司DTAG[27]創(chuàng)建一個(gè)基于docker容器的可用于網(wǎng)絡(luò)入侵檢測(cè)的多蜜罐數(shù)據(jù)集，Martin Grimmer[42]發(fā)布了在容器環(huán)境下獲取的基于現(xiàn)代主機(jī)的入侵檢測(cè)數(shù)據(jù)集LID-DS數(shù)據(jù)集。

4? 結(jié)語(yǔ)

容器對(duì)于云計(jì)算的發(fā)展至關(guān)重要，而目前容器安全技術(shù)的研究仍在處于起步階段，容器入侵檢測(cè)方法尚不成體系。通過(guò)本文對(duì)容器入侵檢測(cè)的各種方法進(jìn)行闡述和分析發(fā)現(xiàn)，根據(jù)目前面向云容器的入侵檢測(cè)技術(shù)，在針對(duì)容器資源的入侵檢測(cè)和基于漏洞掃描的容器入侵檢測(cè)方面發(fā)展較快，并取得較好的檢測(cè)效果。隨著技術(shù)的深入，一些學(xué)者逐漸采用深度神經(jīng)網(wǎng)絡(luò)學(xué)習(xí)的方法進(jìn)行檢測(cè)云容器入侵問(wèn)題，并且在相同實(shí)驗(yàn)環(huán)境下，取得了更好的檢測(cè)效果。隨著未來(lái)對(duì)容器安全研究增多，必將需要更多的評(píng)估及對(duì)比實(shí)驗(yàn)。然而由于缺乏容器公開(kāi)數(shù)據(jù)集，從一定程度上限制了神經(jīng)網(wǎng)絡(luò)在容器安全領(lǐng)域的發(fā)展。另外，云容器特定行為攻擊的研究異常檢測(cè)方法策略較少，未來(lái)隨著對(duì)容器安全研究的深入，或許可以針對(duì)云容器中各個(gè)特定攻擊行為進(jìn)行精準(zhǔn)檢測(cè)分析，甚至引入深度神經(jīng)網(wǎng)絡(luò)的方法進(jìn)行智能檢測(cè)。這在目前還缺乏關(guān)鍵性的突破，有望成為未來(lái)的研究熱點(diǎn)。

參考文獻(xiàn)

[1] 簡(jiǎn)智強(qiáng).Docker容器安全監(jiān)控系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[D].重慶：重慶郵電大學(xué)，2017.

[2] 楊文林，譚曦，郭俊廷，等.Docker脆弱性分析與安全增強(qiáng)[J].信息安全與技術(shù)，2016，7（4）：21-23.

[3] Boonma P，Natwichai J，Khwanngern K， et al.DAHS：A Distributed Data-as-a-Service Framework for Data Analytics in Healthcare[C]//International Conference on P2p. Springer， Cham，2018.

[4] Eric Carter. Sysdig 2019 Container Usage Report： New Kubernetes and security insights. [EB/OL].2019. https：//sysdig.com/blog/sysdig-2019-container-usage-report/

[5] 綠盟科技星云實(shí)驗(yàn)室.容器逃逸技術(shù)概覽[EB/OL].2020-02-21. https：//www.nsfocus.com.cn/list-92-1.html

[6] A. Jerbi， Mitigating High Severity RunC Vulnerability （CVE-2019-5736） [EB/OL]. https：//blog.aquasec.com/runc-vulnerability-cve-2019-5736. [Accessed： 12-Dec-2019]

[7] 狴犴安全團(tuán)隊(duì).Docker容器安全性分析[EB/OL]. 2019-12-15. https：//www.freebuf.com/articles/system/221319.html

[8] fork bomb[EB/OL]. 1994-12-14. http：//foldoc.org/fork+bomb

[9] 唐青昊，毛大鵬.云虛擬化安全攻防實(shí)踐[M].北京：電子工 業(yè)出版社，2018.

[10] Lin， Xin & Lei， Lingguang & Wang， Yuewu，et al. 2018. A Measurement Study on Linux Container Security： Attacks and Countermeasures[C]//In Proceedings of the 34th Annual Computer Security Applications Conference （ACSAC '18）. Association for Computing Machinery， New York， NY， USA， 418–429.

[11] Borhani， A.. Anomaly detection， alerting， and incident response for containers[J]. SANS Institute InfoSec Reading Room. 2017

[12] Falco[EB/OL].2016.https：//falco.org/

[13] Sysdig[EB/OL]. http：//www.sysdig.org/， 2016.

[14] 金逸靈，陳興蜀，王玉龍.基于LSTM-CNN的容器內(nèi)惡意軟件靜態(tài)檢測(cè)[J]. 計(jì)算機(jī)應(yīng)用研究，2020，37（12）：190-193，197.

[15] Abed A S， Clancy C， Levy D S. Intrusion detection system for applications using linux containers[C]//International Workshop on Security and Trust Management. Springer， Cham， 2015： 123-135.

[16] S Srinivasan， A Kumar， M Mahajan. Probabilistic Real-Time Intrusion Detection System for Docker Containers： 6th International Symposium， SSCC 2018， Bangalore， India， September 19–22， 2018， Revised Selected Papers[M].? 2019.

[17] J.Flora P.Gon alves and N Antunes， Using Attack Injection to Evaluate Intrusion Detection Effectiveness in Container-based Systems[C] //2020 IEEE 25th Pacific Rim International Symposium on Dependable Computing （PRDC）， Perth， WA， Australia， 2020， pp. 60-69，

[18] S.A.Hofmeyr， S. Forrest， A. Somayaji， Intrusion detection using sequences of system calls[J]. Journal of Computer Security， 1998.

[19] S.Abed， C.Clancy，D.S.Levy， Intrusion detection system for applications using linux containers[C]// International Workshop on Security and Trust Management， pp. 123-135， 2015.

[20] Warrender，S.Forrest， B. Pearlmutter， Detecting intrusions using system calls： alternative data models[C]// IEEE Symposium on Security and Privacy， 1999.

[21] Zou Z ，? Y? Xie，? Huang K ， et al. A Docker Container Anomaly Monitoring System Based on Optimized Isolation Forest[J]. IEEE Transactions on Cloud Computing， 2019， PP（99）：1-1.

[22] Tien， C‐W， Huang， KubAnomaly： Anomaly detection for the Docker orchestration platform with neural network approaches. [C]//Engineering Reports. 2019; 1：e12080.

[23] Lu C ，? Ye K ，? Chen W ， et al. ADGS： Anomaly Detection and Localization Based on Graph Similarity in Container-Based Clouds[C]// 2019 IEEE 25th International Conference on Parallel and Distributed Systems （ICPADS）. IEEE， 2019.

[24] Xing G ，? Gu Z ，? Kayaalp M ， et al. ContainerLeaks： Emerging Security Threats of Information Leakages in Container Clouds[C]// IEEE/IFIP International Conference on Dependable Systems & Networks. IEEE， 2017.

[25] Elazazy， A. HoneyProxy Implementation in Cloud Environment with Docker Container HoneyFarm[D]. Tartu： University of Tartu， 2018

[26] Kyriakou A ，? Sklavos N . Container-Based Honeypot Deployment for the Analysis of Malicious Activity[C]// Global Information Infrastructure and Networking Symposium （GIIS18）. 2018.

[27] T-Pot： A Multi-Honeypot Platform [EB/OL]. 2015-03-17 http：//dtag-dev-sec.github.io/mediator/feature/2015/03/17/concept.html

[28] Krishnaveni S，Prabakaran S . Ensemble approach for network threat detection and classification on cloud computing[J]. Concurrency and Computation Practice and Experience， 2019.

[29] S.Kwon， J. Lee， DIVDS： Docker Image Vulnerability Diagnostic System[J]. in IEEE Access， vol. 8， pp. 42666-42673， 2020

[30] Clair[EB/OL]. https：//github.com/coreos/clair， 2017.

[31] CVSS[EB/OL].https：//www.first.org/cvss/

[32] O.Tunde-Onadele， J. He， T. Dai and X. Gu， A Study on Container Vulnerability Exploit Detection[C]// 2019 IEEE International Conference on Cloud Engineering （IC2E）， Prague， Czech Republic， 2019：121-127.

[33] T.Kohonen.The self-organizing map[J]. Neurocomputing， vol. 21， no.1-3， pp. 1–6， 1998.

[34] Anchore[EB/OL].https：//github.com/anchore/anchore-engine，2017

[35] Banyan Collector[EB/OL].https：//github.com/banyanops/collector， 2018.

[36] Dockscan[EB/OL]. https：//github.com/kost/dockscan， 2018.

[37] OpenSCAP Container Compliance[EB/OL].https：//github.com/OpenSCAP/container- compliance， 2016.

[38] cAdvisor[EB/OL]. https：//hub.docker.com/r/google/cadvisor/， 2018.

[39] The Road to Twistlock 2.0： Runtime Radar for Runtime Defense[EB/OL]. https：//www.twistlock.com/2017/04/11/road-twistlock- 2-0-runtime-radar/.

[40] NeuVector[EB/OL]. https：//neuvector.com/， 2018.

[41] Grimmer， M.， R hling， M.， Kreu el， D.， & Ganz， S. （2019）. A Modern and Sophisticated Host Based Intrusion Detection Data Set.