曹占涛，文 欣，周 俊

（成都卫士通信息产业股份有限公司，四川 成都 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容器集群环境的非侵入式反病毒模型。为克服传统反病毒软件只能基于宿主机或放入业务容器内进行检测的问题，本文设计了恶意分析和策略管理分离的机制，容器采用边车挂载策略管理模块，将业务容器和恶意分析服务解耦。另外，本文模型会进行恶意行为动态检测，在容器集群环境，当发现恶意行为时，则提取新恶意特征，并上报反病毒管理服务，可以迅速通知所有节点进行查杀。但如不启动这些功能，恶意文件会对容器集群构成重大风险。