面向云容器安全的異常檢測技術研究綜述

范源藝 張增軍 徐成華 魏育成 蔡剛 朱科鍵

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

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

關鍵詞：云計算? 容器安全? 異常檢測? 虛擬化

中圖分類號：TP393.08? ? ? ? ? ? ? ? ? ? ? 文獻標識碼：A文章編號：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

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

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

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

1? 云容器基本概念和安全機制

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

1.1 云容器基本原理和應用

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

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

1.2 云容器安全威脅分析

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

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

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

1.2.2 逃逸攻擊

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

1.2.3 拒絕服務攻擊

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

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

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

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

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

1.3 云容器安全機制

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

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

2? 異常入侵檢測技術在云容器安全領域中的應用

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

傳統(tǒng)的異常入侵檢測技術根據(jù)檢測源可分為基于主機的異常檢測技術和基于網(wǎng)絡的入侵檢測技術。由于云環(huán)境的特殊性以及容器鏡像可靠的必要性，容器極有可能因為暴露的漏洞遭受到攻擊，因此，對容器及其鏡像進行漏洞檢測極其重要，針對容器的安全檢測技術從檢測源可分為基于主機的容器異常檢測技術、基于網(wǎng)絡的容器異常檢測技術和基于漏洞利用的容器安全檢測技術。

2.1 基于主機的容器異常入侵檢測

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

在傳統(tǒng)主機領域下基于系統(tǒng)調(diào)用的入侵檢測方案，往往針對單一特權進程的運行行為進行監(jiān)控，而在容器環(huán)境下引入了更多的安全風險。對異常識別來說，一個重要的表征是特征選取的是否合適。系統(tǒng)調(diào)用作為應用程序訪問操作系統(tǒng)服務的接口，容器的攻擊行為通?？梢酝ㄟ^系統(tǒng)調(diào)用來表現(xiàn)。當前的系統(tǒng)調(diào)用特征提取方法有兩類，第一，抽取系統(tǒng)調(diào)用子序列作為特征。第二，使用系統(tǒng)調(diào)用序列的頻率作為特征。

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

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

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

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

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

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

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

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

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

2.3 基于漏洞利用的容器安全檢測

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

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

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

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

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

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

3.2 應用數(shù)據(jù)集

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

4? 結語

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

參考文獻

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

[2] 楊文林，譚曦，郭俊廷，等.Docker脆弱性分析與安全增強[J].信息安全與技術，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] 綠盟科技星云實驗室.容器逃逸技術概覽[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] 狴犴安全團隊.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] 唐青昊，毛大鵬.云虛擬化安全攻防實踐[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)檢測[J]. 計算機應用研究，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.