基于容器集群的反病毒模型*

曹占濤，文 欣，周 俊

（成都衛士通信息產業股份有限公司，四川 成都 610041）

0 引言

Linux 容器，例如Docker[1]、LXC[2]、Containerd[3]，依靠內核namespaces 和cgroups 來隔離容器內的應用程序，提供了比虛擬機更輕量化的虛擬化方案，使容器性能達到了接近原生的性能并且優于虛擬機[4-5]。近年來，Linux 容器及容器編排工具Kubernetes 已成為事實上的云原生基礎設施，提供了一種充分利用云計算資源的工作負載方法。

由于容器共享主機內核，每個容器都通過共享內核對整個物理內存及存儲進行有效映射，因此，信息泄漏將有可能擴展到同一物理機上運行的所有其他容器。另外，在基于Kubernetes 的容器集群環境中，容器更容易橫向擴容，且可在不同宿主機間漂移，當容器內可能存在惡意軟件時，容器相較于傳統虛擬機技術的攻擊面增大。顯然，在容器技術流行的同時，基于容器的系統也比虛擬機面臨更多的安全挑戰[6]。

為克服安全威脅，國際互聯網安全中心（Center for Internet Security）提供了基于Docker 和Kubernetes的安全基準。此基準提供了定義公正、明確并基于一致性的行業最佳實踐，通過此實踐可以增強安全性，以最小化攻擊面。然而，此基準更傾向于降低第三方惡意攻擊的影響，并不能很好地處理惡意軟件對系統的破壞。

傳統虛擬機環境采用反病毒軟件可以最大限度地減少惡意軟件造成的損害。反病毒軟件為系統中的所有文件、進程提供實時惡意軟件檢測功能。如果反病毒軟件檢測到惡意軟件，則將原始文件放入安全區，從而阻止惡意軟件執行以降低對系統的損壞。如用戶需要進一步訪問，則可由用戶進行選擇。

容器環境區別于傳統虛擬機，在基于Kubernetes 的容器集群環境中，為了解決惡意文件造成的損害，一個可行的方案是在每個運行容器中安裝反病毒軟件，但其會導致反病毒軟件和業務容器耦合，同時還將造成靜態資源（進程啟動后占用的最小固定系統資源）浪費。另外一個可行的方案是在宿主機安裝反病毒軟件，然而基于Linux 環境的容器通常用于在多租戶云環境中運行應用程序，不同租戶的容器共享相同的主機內核，但出于監視目的，在容器不可知的情況下，更改容器內容并不可取，因為會干擾容器內應用程序的正常運行。

隨著云原生技術的普及，容器集群得到了越來越廣泛的應用，然而當前的反病毒技術并不是為容器集群而設計。為解決此問題，本文設計了可應用于Linux 容器集群環境的非侵入式反病毒模型。模型采用惡意分析服務、策略管理分離機制，實現多容器共用惡意分析服務，在降低耦合度的同時，可節約靜態資源；模型可以動態進行容器行為監測，發現惡意特征，并通知整個容器集群；模型策略管理模塊采用邊車模式掛載，將業務容器和策略管理解耦。

1 背景及需求

1.1 容器及容器集群

近年來，隨著云平臺的發展和普及，大多數企業都有自己的數據中心。但是，隨著云平臺的不斷擴展，虛擬機存在運行效率低、啟動慢等問題[7]。為了緩解這些問題，容器[8]作為一種新的虛擬化技術應運而生。與傳統虛擬機相比，容器更輕量級，能夠快速創建和銷毀[9]，因此基于容器的虛擬化技術已成為云環境中部署應用程序的關鍵技術[8]。

在容器集群中，為便于管理，多種容器集群管理服務應運而生，用戶可以使用Docker Swarm 或Kubernetes 等，輕松部署多個容器集群節點。其中Kubernetes 是谷歌發布的，是用于容器的開源集群管理器。Kubernetes 解耦了應用容器與其運行的系統，這種解耦簡化了應用程序開發，用戶只需要關注內核和內存等抽象資源，而且還簡化了數據中心的運營[10]。隨著容器及容器集群技術的普及，騰訊云、阿里云等越來越多的云服務提供商，開始在云服務提供容器及基于Kubernetes 的容器編排服務。

1.2 容器全生命周期安全

容器供應鏈和傳統軟件供應鏈不同，容器場景下，統一交付物為鏡像，鏡像一旦交付，將會在容器集群環境中被大規模應用。由于交付標準的統一性，容器簡化了開發供應鏈的管理，但也增大了攻擊面。

容器的整個生命周期由構建和運行兩部分組成，在容器的構建階段，攻擊者可以對鏡像進行污染，包括對構建文件的后門植入。在運行階段惡意文件的上傳、下載，或靜態檢測無法檢測到的惡意軟件都會對容器運行時的安全造成傷害。

Wist 等人[11]分析了Docker Hub 社區庫中2 173個鏡像，發現有68%的鏡像至少包含1 個高度或嚴重漏洞。在容器生命周期中，可在鏡像構建完成后和運行前這段時間，進行鏡像漏洞掃描。近年來，已經涌現了大量的方案來進行鏡像文件漏洞檢測，例如Trivy、Clair等工具已廣泛應用于容器漏洞掃描。

對于軟件運行，在傳統虛擬機時代，針對動態運行時惡意文件的監測相對比較成熟，而容器在運行階段，會面對比傳統虛擬機更大的攻擊面，但目前針對如何對容器環境的惡意文件進行監測的相關研究還較少。

1.3 容器環境反病毒技術

惡意軟件是指可以危害計算機系統或網絡的程序代碼[12]。惡意代碼具有感染計算機文件或已安裝軟件程序的趨勢。惡意軟件檢測技術可以分為基于簽名、基于行為和基于啟發式[13]的惡意軟件檢測技術三類。基于簽名的技術通過搜索不同字節序列來識別惡意軟件的特定部分；基于行為的方法通過觀察計算機軟件的行為以確定它是否有害；基于啟發式的技術通過學習、分析來檢查軟件異常行為。

反病毒軟件通常作為單個系統單元運行，會檢測已知的惡意軟件，然后實時阻止惡意軟件，并在可能的情況下恢復原始文件。在傳統物理機及虛擬機環境中，惡意軟件檢測方案比較成熟，涌現了大量的成功案例。

隨著容器的廣泛應用，容器平臺急需反病毒軟件來提供可靠的安全功能。然而，目前針對容器平臺的反病毒技術在提供安全功能方面存在局限性。在容器環境中，當用戶訪問容器文件時，容器引擎會將用戶訪問的虛擬文件路徑（容器路徑）更改為絕對文件路徑（宿主機路徑），并在內核中生成待處理的輸入/輸出（Input/Output，I/O）。內核監控文件I/O 并將文件路徑傳遞給反病毒引擎，反病毒引擎就可以對此文件執行惡意軟件分析。但是，由于容器平臺的隔離特性，容器中執行的應用程序進程或文件獨立于其他容器或主機。傳統反病毒引擎如果基于宿主機，由于其無法直接訪問容器，在容器不知情的情況下，直接對文件進行處理，則可能會造成容器無法正常運行。

近年來有學者對如何基于容器環境進行惡意文件查殺進行了研究，例如Abed 等人[14]設計了一種稱為基于主機型的入侵檢測系統（Host-based Intrusion Detection System，HIDS）檢測容器行為異常，然而其偏向于異常分類的設計，未說明異常行為檢測后如何和容器交互，以及如何在容器集群中使用此方法。Han 等人[15]設計了一種基于windows的單容器惡意文件檢測框架，其通過基于windows的interrupt request level 技術監測文件產生，文件產生后通知容器提取文件特征。然而此方法需將文件特征提取模塊和策略模塊在鏡像制作階段預置在容器內，并和業務容器產生耦合性，即文件特征提取模塊和策略模塊的升級需要將業務鏡像重新制作。另外，該方法未涉及如何在基于Linux 的容器環境使用，也未涉及如何在容器集群環境中進行惡意文件檢測。

2 容器集群反病毒模型

在本節中，首先介紹容器集群反病毒模型的整體架構，其次詳細介紹模型各個組件的組成。

2.1 總體框架

為了解決Linux 環境下，容器集群環境中惡意文件和惡意行為檢測面臨的問題，設計了容器集群反病毒模型。該方法不同于過去的惡意文件或惡意行為檢測方法，過去的一些方法需要和業務容器高度耦合，并且會導致系統消耗增大，而本模型在不改變現有容器集群部署方法的情況下，提供了和業務容器解耦的反病毒模型，并提供了新惡意特征快速全集群同步的功能。整體架構如圖1 所示，本模型主要由4 個模塊協作完成，包括反病毒驅動、惡意分析服務、策略管理、反病毒管理服務。

圖1 容器集群反病毒模型

2.2 反病毒驅動模塊

Linux 內核是實現監視/可觀察性的理想場所。由于容器共用宿主機內核，當用戶訪問容器文件時，容器引擎會將用戶訪問的虛擬文件路徑（容器路徑）映射到絕對文件路徑（宿主機路徑），并在內核中生成待處理的I/O，通過宿主機可以監測到容器內的系統調用。傳統的內核追蹤檢測，基于內核驅動進行追蹤系統調用。近年來，擴展的伯克利包過濾器（Extended Berkeley Packet Filter，eBPF）[16]已添加到Linux 內核中，在不影響內核安全性、不需要任何額外內核模塊的前提下，提供了內核的可編程性，即內核可以對其進行動態編譯。eBPF 通過一種軟件定義的方式，支持豐富的內核探針類型，并提供了強大的動態追蹤能力。

本模型的反病毒驅動模塊，采用基于eBPF 的內核追蹤技術，動態監測Linux 系統調用。反病毒驅動內置可配置的監測規則庫，對Linux 系統調用行為進行監控。在實時監測系統調用過程中，當監測到規則庫中已有的系統調用或系統調用組合，則將監測到的進程id、函數參數等通知惡意分析服務。

2.3 惡意分析服務

惡意分析服務交互序列如圖2 所示，惡意分析服務工作流程如圖3 所示。惡意分析服務收到反病毒驅動上報的信息后，將進行兩個方面的分析：（1）惡意文件檢測；（2）惡意行為檢測。

圖2 惡意分析服務交互序列

圖3 惡意分析服務工作流程

2.3.1 惡意文件檢測

當收到反病毒驅動上報的文件創建操作后，惡意文件分析服務調用惡意文件檢測引擎，對文件提取特征進行特征分析，判斷其是否為惡意文件。如果是惡意文件，則依據容器引擎采用的文件系統，轉換出基于容器的相對路徑，獲得文件所屬容器id，及文件在容器內的路徑。如容器已掛載文件策略模塊，則通知對應業務容器文件策略模塊，依據文件惡意程度，并結合業務容器的判斷來決定文件的下一步操作。值得注意的是，惡意分析服務可以嵌入任何成熟的惡意文件分析引擎。

2.3.2 惡意行為檢測

惡意分析服務接收到反病毒驅動模塊上報的惡意行為后，則依據反病毒驅動上報的參數和容器引擎，判斷此行為對應的容器及進程文件，通知策略服務，依據行為的惡意程度和業務容器的判斷，綜合確定后續是刪除還是放行此文件。如被判斷為惡意文件，則對此進程文件提取特征，將特征通知反病毒管理服務，反病毒管理服務更新特征庫，通知集群的各個節點更新本地特征庫，并對相應容器進行主動掃描。

2.4 策略管理

在過去的一些惡意文件分析方法中，在制作業務鏡像時，需要把策略管理模塊預制入鏡像內，造成極大的耦合性，當策略模塊需要修改時，業務需要重新打包鏡像。與過去的方法不同，在本模型中，策略管理模塊采用邊車模式。容器啟動時，如果需要使用惡意文件掃描服務，則可以選擇邊車模式掛載。

在本模型中，業務用戶可以通過文件策略管理模塊，獲取上報的惡意文件信息。對惡意程度不高的文件，業務邏輯可以依據自身需求決定此惡意文件的下一步處理策略。如果業務用戶判斷其為正常文件，則通知惡意分析服務放行此文件。如果判斷為惡意文件，則通知惡意文件分析邏輯對此文件進行隔離或刪除。

2.5 反病毒管理服務

反病毒管理服務主要進行特征管理及惡意警告日志管理。

惡意特征有兩個來源，一個為管理員從外部導入的已發現的惡意特征，另外一個為通過惡意分析服務分析獲得的新特征。當有新特征發現時，則通知所有容器節點，讓其更新本地特征庫和本地節點，更新本地特征庫后，即進行相應的主動掃描。

當惡意分析服務發現惡意行為或惡意文件時，會通知管理服務，記錄警告日志。同時容器對惡意文件的處理行為也會通知管理服務，由管理服務記錄日志，以供后期審核使用。

3 對比分析

在本節，主要針對安全性、易用性、靜態資源消耗（進程啟動后占用的最小固定系統資源）3 個方面，將本文所提方法與已有的方法AV-TS、AV-CP 進行對比，并通過對比，介紹本文設計的容器集群反病毒模型的優勢。

AV-TS 為傳統反病毒軟件，應用于容器集群環境，一般需要在每個容器部署一個反病毒軟件。

AV-CP 為文獻[15]中設計的反病毒模型，是一種基于windows 的單容器惡意文件檢測框架，其通過基于windows 的interrupt request level 技術，監測文件產生。

對比結果如表1 所示，其中對比指標依據能力對比分為3 個級別：1 是最低分，代表效果最差；2表示中等；3 是最高分，代表效果最好。

表1 結果對比

3.1 安全性分析

反病毒軟件的一個特點是，為了保證系統的安全，需要隨著新病毒的出現，快速更新病毒庫。病毒庫的更新，對安全性具有至關重要的作用，不同方法的安全性對比如下文所述：

（1）AV-TS。由于反病毒軟件是業務用戶在制作鏡像時放入，不同的業務用戶可能使用不同的反病毒軟件，更新策略不同。另外，容器會在不同節點漂移，并且容器重啟會導致本地更新消失，為病毒庫的更新增加了難度，導致不能及時發現新病毒。

（2）AV-CP。由于策略模塊和特征提取模塊均在容器內部，如果策略模塊和特征提取模塊需要更新，則需要業務容器配合修改，并重新制作鏡像。在大規模容器集群環境中，需要快速更新算法和策略，如果需要業務重新制作鏡像，將對業務的運行產生巨大負面影響，所以將導致安全性策略無法實時進行更新。

（3）本文設計的方法。該方法中的病毒庫由病毒庫管理模塊控制，所有容器共享，可以實時將最新病毒庫更新下發到宿主機。惡意分析服務采用容器共享方案，在宿主機進行共享。策略模塊和業務容器解耦，采用邊車模式，如果策略算法更新，容器只需重啟，則可使用最新算法。

3.2 易用性分析

基于kubernetes 容器集群，容器可以依據資源需求，在不同節點間進行調度。另外當業務容器掛掉，也會自動拉起。

反病毒軟件不僅要考慮安全性，也要考慮用戶使用的便利性。傳統反病毒軟件，需要業務容器在制作鏡像時，將反病毒軟件放入其中。當容器重啟后，已有動態更新的病毒庫將會消失，如果需要保持更新的病毒特征不丟失，則需要重新制作鏡像，將最新的病毒特征放入其中。防止最新病毒特征丟失的另外一個方法是，將病毒庫掛載在分布式存儲設備中，然而不同的業務容器可能使用不同的反病毒軟件，不僅需要增加額外的設備，還會導致存儲管理更為復雜。

AV-CP 是為單容器環境設計的反病毒系統，需要將文件特征提取模塊和策略模塊內置于容器內。然而文件提取模塊及策略模塊和業務并不是一個廠商發布，當文件特征提取模塊和策略模塊需要更新時，業務鏡像也需要做相應更新。

本文設計的反病毒模型相對于其他方法，易用性更好，這是因為惡意分析服務集成了文件特征提取模塊，病毒庫和惡意分析服務部署在宿主機，可以多容器共享。另外，策略管理和業務容器分離，并采用邊車模式掛載進行策略管理，減小了和業務容器的耦合度。

3.3 靜態資源占用分析

本章節將通過由m個節點，每個節點有n個容器組成的容器集群場景，分析本模型對系統性能的影響。一般反病毒軟件由反病毒驅動、惡意分析服務、文件特征提取、策略管理、反病毒管理服務五部分組成。對于此五部分，本文分別定義其占用的靜態資源為a，b，c，d，e。

傳統反病毒軟件應用于容器環境，需要在每個容器部署，此時需要部署m×n個反病毒軟件，共占用靜態資源為(a+b+c+d+e)×m×n。

AV-CP 并不適用于容器集群環境時，但是本文對AV-CP 進行擴展，即單宿主機的容器共用反病毒引擎和病毒分析服務，容器部分可以橫向擴展，使其適用于多容器環境，則其對靜態資源的最低消耗為(a+b+(c+d)×n)×m+e。

本文設計的模型中，惡意分析服務集成了文件特征提取模塊，同時反病毒驅動、惡意分析服務、反病毒管理服務在同一宿主機上的容器均可共享。在多容器環境中，對于靜態資源的最低消耗為(a+b+c+d×n)×m+e，低于其他方案。

4 結語

本文針對容器集群提供了一種可應用于Linux容器集群環境的非侵入式反病毒模型。為克服傳統反病毒軟件只能基于宿主機或放入業務容器內進行檢測的問題，本文設計了惡意分析和策略管理分離的機制，容器采用邊車掛載策略管理模塊，將業務容器和惡意分析服務解耦。另外，本文模型會進行惡意行為動態檢測，在容器集群環境，當發現惡意行為時，則提取新惡意特征，并上報反病毒管理服務，可以迅速通知所有節點進行查殺。但如不啟動這些功能，惡意文件會對容器集群構成重大風險。