SCI论文（www.lunwensci.com）
摘 要：容器技术的逐步发展为云原生应用部署提供了有效的轻量化解决方案,同时,容器逃逸攻击问题也成为了威胁容 器运行安全最主要的问题,但目前尚无覆盖性较强的措施对大部分容器逃逸攻击手段和威胁进行检测,本文针对生产环境面临 的 Docker 容器逃逸问题, 研究并设计基于宿主机的容器逃逸攻击检测模型 DCEA(Detect Container Escape Attacks), 从 容器的安全漏洞检测、危险配置检测、威胁行为检测及空间可信检测等方面,对容器业务上线前和上线后全方位进行监测与评 估,力求提升对于容器逃逸攻击的预防和发现能力,保障容器运行安全。
关键词：信息安全,容器,逃逸攻击,威胁检测
Research and Design of Container Escape Attack Detection Model
SU Tong
(Fuzhou University Zhicheng College, Fuzhou Fujian 350001)
【Abstract】：The gradual development of container technology provides an effective lightweight solution for cloud native application deployment, at the same time, container escape attack problem has also become the most important problem threatening container operation security, but there are currently no strong coverage measures to detect most of the container escape attack methods and threats, this paper for the production environment faced by Docker container escape problem, research and design a host-based container escape attack detection model DCEA (Detect Container Escape Attacks), from the aspects of container security vulnerability detection, dangerous configuration detection, threat behavior detection, and spatial trusted detection, monitor and evaluate all aspects of container services before and after launch, and strive to improve the prevention and detection capabilities of container escape attacks and ensure the security of container operation.
【Key words】：information security;container;escape attack;threat detection
0 引言
云原生技术的快速发展及微服务等应用架构的普及 使得以轻量级虚拟化技术为主的容器成为了当今主流 的服务部署方式之一。Docker 通过其特有的 Cgroups 和 Namespace 实现容器与宿主机间的有效隔离,在共 享内核的情况下互不干扰地运作 [1],为生产环境提供秒 级启动,弹性扩容等高可用性能。但同时,容器与宿主 机间,容器与容器间的隔离本质上是一种业务逻辑上的 弱隔离机制,存在被攻击者篡改宿主机资源,实施容器 逃逸的安全风险,这也成为了目前影响容器安全性的主 要威胁。由于实际生产环境受管理人员素质、配置合规 性、镜像安全性等多方面问题的影响,容器业务的暴露面较广,遭受逃逸攻击的可能性较大,由于目前针对容 器逃逸攻击的检测手段较少,覆盖类型单一、即时性 较弱等问题,尚无有效的手段对容器逃逸问题从运行 前到运行后进行全面检测,因此,本文针对容器逃逸 攻击主流手段,研究并设计基于宿主机的 Docker 容器 逃逸攻击检测模型 DCEA(Detect Container Escape Attacks),对容器逃逸威胁进行全方位检测,以提升容 器运行的安全性。
1 容器隔离性分析
容器采用新型虚拟化技术,通过与宿主机共享物理 内核的方式,减小系统运行开销,以实现轻量化运行。 其 Namespace 命名空间主要负责各容器内 PID、User、UTS、IPC、Network 及 Mount 的安全隔离, 使得容 器间无法感知彼此的操作,保证系统的安全。
但也由于容器的运行依赖于宿主机的内核,且存在 未完全隔离的伪文件系统,因此容器间的隔离机制具 有一定脆弱性 [2],在复杂的生产环境中可能因为镜像漏 洞、危险配置、敏感挂载等一系列问题,被攻击者利用 从而对运行中的业务逻辑进行劫持, 突破 Namespace 的封锁,以获取超出容器业务正常运行的权限,进入宿 主机执行命令。对于容器而言,逃逸攻击问题是目前造 成宿主机失陷,影响云原生环境安全的主要问题。
2 容器逃逸攻击分析
2.1 利用安全漏洞逃逸
容器与宿主机共享内核的特殊机制使得 Linux 的 内核漏洞成为被用于实施容器逃逸的突破口。攻击者能 够利用 Linux Kernel 对应版本的内核漏洞,非法突破 容器空间的限制,进入宿主机系统中执行恶意指令,以 提升权限并进行持久化操作。目前已发现多个被利用于 容器逃逸的内核漏洞, 例如攻击者曾利用 CVE-2016- 5195 脏牛内核漏洞向 VSDO 写入恶意 Shell 脚本以劫 持正常的进程调用,成功提权并实施容器逃逸,造成了 较大危害。
同时,由于容器组件的 Docker 镜像来源复杂,且 封装标准不一等问题,用户在启动容器时, Docker 镜 像本身的安全漏洞往往会给攻击者入侵容器并实施逃 逸创造条件 [3]。在 Docker 镜像特有的分层机制下,当 Rootfs 根文件系统镜像及 Apache、Redis、Nginx 等 常用组件镜像作为基础镜像层被多个容器业务镜像共享 使用时,潜藏的安全漏洞也会使得容器遭受逃逸的风险 进一步扩大 [4]。
2.2 利用高危权限逃逸
容器的权限配置不当,可能给攻击者提供写入恶意 Shell 或触发危险进程的机会,从而实施逃逸。在一般 业务场景中,容器均以普通权限模式运行,但由于管理 人员的疏忽或某些特定业务场景需要实现 Docker-in- Docker,容器可能被以 Privileged 参数的方式启动,该 特权模式允许容器访问大量宿主机设备 [5],并且不受 AppArmor 或 Seccomp 等机制的限制,一旦被攻击者 利用,其能够调用与宿主机权限相同的进程以绕过内核 的验证, 读取敏感内核文件并写入 Shellcode,实施容 器逃逸操作。
同时,Linux 内核中的 Capability 权限控制粒度 过粗,也会导致容器遭受逃逸攻击 [6]。当管理员因权 限配置不当为容器开启 CAP_SYS_ADMIN、CAP_DAC_READ_SEARCH、CAP_SYS_PTRACE 等细分权限后, 攻击者可以通过重写 devices.allow 文件非法访问设 备、绕过宿主机文件读写限制、注入恶意代码实现非法 调用等手段,对自身提权进而实施容器逃逸。
2.3 利用敏感挂载逃逸
为了方便实现容器内数据的持久化操作,以及外部 文件与容器内业务的交互,容器应用通常会采用挂载宿 主机目录的方式,以实现对重要数据的存储和调取。但 由于操作疏忽或某些特定需求,也会出现一些宿主机敏 感目录及文件被挂载到容器内的情况,可能导致被挂载 目录及文件的敏感信息被攻击者读取和篡改,突破资源 隔离机制进而被实施逃逸。
当容器挂载了敏感的文件系统 Procfs,攻击者可以 通过利用 /proc/sys/kernel/core_pattern 的特殊语法 创建隐藏后门,写入 Playload 并获得反弹 Shell,以实 现容器逃逸。当管理者将 Docker 守护进程监听的套接 字文件 docker.sock 挂载进容器内后,一旦攻击者入侵 了容器,便可以通过与 Docker 守护进程通信,创建新 容器并挂载宿主机目录的方式,逃离到容器外部。常见 的敏感挂载有 Procfs 挂载、Docker Socket 挂载、宿 主机 etc 目录或根目录挂载以及 /var/log 目录挂载等敏 感挂载 [7]。
3 检测模型架构
容器逃逸攻击技术的入侵手法较多,从检测模型上 来看,需要同时兼顾容器业务上线运行前的静态检查与 容器业务上线运行后的动态监测,才能在保证有效性和 通用性的前提下最大程度裁剪暴露给外界的攻击面,满 足容器逃逸攻击检测的安全需求。
DCEA 模型主要分为 4 大检测模块,在容器业务上 线运行前,安全漏洞检测模块通过对内核逃逸漏洞及组 件镜像漏洞的扫描,检测容器可能被利用的安全漏洞。 危险配置检测模块通过执行 Shell 脚本对容器的高危权 限及敏感挂载进行检测,并对危险配置及时发出预警。
容器业务上线运行后,检测模型对运行过程中可能 出现的威胁行为进行动态监测。一方面,威胁行为检测 模块通过调用 Falco 对容器执行的风险行为如尝试创建 敏感设备、尝试启动 Shell、企图进行提权及危险挂载 等操作进行告警 ;另一方面,空间可信检测模块通过对 容器进程所属命名空间的异常变化进行动态校验,来判 断是否容器已被实施逃逸,主要分为常规轮询检测和威 胁行为复检两部分。一旦模块检测到攻击者已绕过全部 安全机制并成功逃逸,模块将快速发出告警,以确保最 大程度降低容器逃逸造成的风险。DCEA 模型的总体架构如图 1 所示.
4 DCEA 模型主要模块
4.1 安全漏洞检测模块
容器业务上线运行前,检测模块主要对宿主机内核 及容器组件镜像可能产生的逃逸攻击漏洞进行重点检查。
一方面针对已知被用于逃逸攻击的典型内核漏洞进 行扫描以检测当前系统内核 Kernel 版本是否包含目标漏 洞。首先检测模块通过 Uname 指令检测宿主机内核版 本,提取内核版本、主修订版本、次修订版本的值,分 别得到内核版本参数 KernelVersion、MajorRevision、 MinorRevision ;其次,检测模块将宿主机的内核版本 参数与规则文件中已知逃逸漏洞的内核版本参数进行逐 一比对,当匹配到二者版本一致时,返回预警报告。部 分典型逃逸漏洞及内核版本示例如表 1 所示。
另一方面,检测模块对可能威胁容器安全的重要组 件镜像进行扫描,首先通过读取镜像的 Mainfest 文件得 到 Layer 层文件地址并解压获取分层索引,根据 Linux 各发行版本默认路径遍历查找,如 Debian Unstable 版 本文件位于 etc/apt/sources.list,Ubuntu 版本文件位 于 /etc/os-release,逐个遍历可能的各版本文件路径以查找到当前容器的 Linux 发行版本,其次根据对应发 行版本根文件系统 Rootfs 的默认软件包存储路径, 提取 Apache、Nginx、Redis、MySQL 等重要组件的软件包 及其版本号,并将当前的重要组件版本与本地 CVE 漏洞 库进行比对,一旦匹配到上述镜像中存在安全漏洞即向 客户端返回预警报告。
4.2 危险配置检测模块
容器业务上线运行前,危险配置检测模块主要针对 易被用于容器逃逸的危险权限及敏感挂载进行快速检 查,以及时预防配置不当造成的容器逃逸问题。首先检 测模块通过读取 /proc/1/status 文件以获取容器权限模 式,根据返回的 CapEff 掩码值判定该容器是否为特权 容器。其次,检测模块通过 Capsh 指令读取当前 Shell 的 Capabilities 细分权限, 并将 Capabilities 机制中开 启的各权限与规则文件进行逐一匹配,若检测到容器启 用了高危权限如 cap_sys_admin、cap_sys_ptrace、cap_ dac_read_search、cap_dac_override 及 cap_sys_module 等权限,则向客户端发出潜在风险预警。最后,危险配置 检测模块通过查找对容器内可能挂载被用于逃逸攻击的 敏感目录及文件进行匹配,包括但不限于宿主机根目录、 etc 目录、log 目录、sys 目录、proc 等目录以及 docker. sock、core_pattern 等文件,以防止攻击者通过敏感挂 载入侵宿主机,实施逃逸。
4.3 威胁行为检测模块
容器业务上线运行后,威胁行为检测模块主要通过调 用 Falco 对内核进程的异常请求进行审计,以捕获可能的 威胁行为,相比于运行于内核层的 SElinux、APPArmor 而言, Falco 能够直接在用户空间中运行,以减少对内 核层的影响,并提供更灵活的使用。首先检测模块通过 底层 Sysdig 模块及其内核组件 Tracepoint 提供的钩子 对进程的系统调用进行实时采集,并将捕获到的系统调用传输至 Falco。其次 Falco 通过遍历 yaml 规则文件, 对内核捕获到的进程行为做出匹配,以实现对系统事件 流的连续性监测,一旦发现存在威胁行为的进程,检测 模块立即向用户反馈告警,并将攻击信息发送至空间可 信检测模块进行分析。
其中检测模块针对容器逃逸攻击的敏感行为在 rules.yaml 文件中预置了通用规则,其所监测的容器异 常进程主要包括尝试运行 Shell Code、尝试读写 /etc/ shadow、尝试在 /dev 下创建非设备文件、尝试挂载敏 感目录、尝试创建特权容器或提权等。由于实际生产环 境的检测标准各不相同,管理者可通过自定义 yaml 规 则来增加或修改所需匹配的异常进程,模块将对 yaml 文件进行解析,一旦接收到内核模块的进程调用信息, 将立即对进程行为进行匹配以发现威胁。威胁行为检测 模块主要流程如图 2 所示。
4.4 空间可信检测模块
该模块作为容器逃逸攻击检测的重要一环,从命名 空间隔离机制上最大程度发现已绕过安防入侵底层宿主 机的恶意进程。由于容器进程与宿主机进程基于 PID Namespace 机制产生隔离, 若攻击者需要成功实施逃 逸,则其进程必然需要绕过 PID Namesapce 的资源隔 离, 进入宿主机 PID Namespace 内。因此, 空间可信 检测模块主要通过对容器各进程 PID Namespace 的编 号即 NS 值进行可信校验,分析容器当前进程是否运行在自身合规空间内。
空间可信检测模块分为轮询检测和异常进程复检两 部分。
一方面,空间可信检测模块将针对容器的后台守 护进程 dockerd 进行常态化的轮询以实现离散式检 测。当容器业务上线运行后,该检测模块先执行 Pgrep Dockerd 得到容器的守护进程信息,并通过执行 Pstree 获取守护进程的进程树和各进程 PID 值,进而通过查询/ proc//ns 依次获取进程树上各进程 PID Namespace 的 NS 编号, 与宿主机初始进程 PID Namespace 的 NS 编 号进行首次遍历比对,若所有进程 PID Namespace 的 NS 编号均与宿主机初始化进程 PID Namespace 的 NS 编号不同,则证明目前容器各进程所在命名空间正常, 检测模块将以上得到的各进程 PID 值与 Namespace 的 NS 编号分别进行一轮 SHA-256 加密,得到两组度量值 并拼接后,存入可信校验库。由于容器正常运行过程中 各进程 PID Namespace 不会随意改变,在之后再次轮 询校验时,检测模块通过再次读取各进程 PID 值和 PID Namesapce 的 NS 编号并进行 SHA-256 加密拼接,将 其与空间可信校验数据库进行比对,一旦发现容器内 某个 PID Namespace 的 NS 值与可信校验数据库中的 NS 值不相同,则向客户端发出逃逸告警,以确保能够 及时发现并处置威胁。空间可信校验流程如图 3 所示。
另一方面, DCEA 检测模型还将对威胁行为模块识别出的异常进程进行实时复检,以判断当前攻击者是否 已成功逃逸。空间可信检测模块接收到威胁行为检测模 块输出的异常进程 PID 值后,通过查询该容器进程对 应 PID Namespace 的 NS 编号, 将 PID 值及 NS 编号 传入可信校验流程进行复检比对,若判定容器已被成功 逃逸则反馈告警。
5 结语
容器轻量级虚拟化技术快速发展的同时,其安全性 也逐渐成为影响云原生环境的关键因素,容器特殊隔离 机制所带来的容器逃逸攻击则是威胁容器安全最主要的 问题。本文针对目前容器逃逸攻击的主要原理和手段, 从容器的安全漏洞检测、危险配置检测、威胁行为检测 以及空间可信检测等多个方面设计基于宿主机的 DCEA 检测模型,结合静态与动态检测以更大程度地增强对容 器逃逸安全问题的威胁预警和即时发现能力。随着对 容器逃逸安全问题的研究深入,检测模型在威胁横向 移动检测和攻击溯源等方面,仍然有可深入优化与探索之处。
参考文献
[1] 朱春杰.浅析安全容器技术[J].保密科学技术,2021(1):8-14.
[2] 边曼琳,王利明.云环境下Docker容器隔离脆弱性分析与研 究[J].信息网络安全,2020.20(7):85-95.
[3] 杨长茂.冯超.谷晓剑.云原生中的容器安全防护和实践[J].保 密科学技术,2021(1):36-42.
[4] 邵思思,李奎,尧海昌,等.一种基于深度学习的Docker风险 预测方法研究[J].南京邮电大学学报(自然科学版),2021.41(2): 104-112.
[5] 王亮.蔡钟伟.潘庆生.容器的安全管理[J].保密科学技术,2021 (1):23-28.
[6] 李俊灏.Docker安全性分析及安全防护[J].科技视界,2019(20): 240-241+201.
[7] 丁攀,张小梅,郭新海,等.云原生中的容器技术及其安全配置 规范[J].信息通信技术,2021.15(4): 59-64.
关注SCI论文创作发表，寻求SCI论文修改润色、SCI论文代发表等服务支撑，请锁定SCI论文网！
文章出自SCI论文网转载请注明出处：https://www.lunwensci.com/jisuanjilunwen/56363.html
