PAAS容器安全防护

Posted 2022-12-02 玛卡巴卡巴巴亚卡

一、风险和挑战

1、脆弱性和安全

（1）软件风险

a、局域网攻击

从网络实现来看，Docker 支持多种组网模式，在默认的桥接模式组网下，即同一主机上
创建的容器都桥接挂在网桥 docker0 上，这样同一主机上的容器之间可以构成局域网，
因此针对局域网的 ARP 欺骗、嗅探、广播风暴等攻击方式将会对这些容器造成安全威
胁。所以在一个主机上部署多个容器需要进行合理的网络配置，设置访问控制规则，实现
网络之间的隔离和边界。

b、拒绝服务攻击

容器实例共享主机的资源，也就是说底层的 CPU、内存和磁盘等资源由主机操作系统进
行统一的调度和分配。如果不对每个容器的可用资源进行有效的限制和管理，就会造成容
器之间资源使用不均衡，严重时可能导致主机和集群资源耗尽，造成拒绝服务。

c、有漏洞的系统调用

Docker 与虚拟机的主要区别是，Docker 与主机共用一个操作系统内核，如果主机内核
存在横向越权或者提权漏洞，尽管容器是以非特权模式运行的，但容器中的攻击者还是可以利用内核漏洞逃逸到主机，进行恶意行为操作。

d、特权模式共享root权限

既然容器与宿主机共用一个操作系统内核，当以特权模式运行容器时，容器内的 root 用
户也就拥有了主机的 root 权限，进而可以在容器中进行几乎无限制的操作。

e、未隔离的文件系统

虽然 Docker 已经对文件系统进行隔离，但是有一些重要的文件暂时没有被隔离，如
/sys,/proc/sys,/proc/bus 等

（2）API接口安全

按照 Docker 的实现架构，Docker 服务默认监听在 Unix Socket 上，比如
unix:///var/run/docker.sock ， 为了实现集群管理，Docker 官方还提供了一个远程管
理接口的 REST API，允许通过 TCP 远程访问 Docker 服务。
例如在使用 Docker Swarm 时，Docker 节点上会开放一个 TCP 端口 2375，绑定在
0.0.0.0 上。
开启这种没有任何加密和访问控制的 Docker Remote API 服务是非常危险的。尤其
是将默认的 2375 端口暴露到互联网中，一旦被攻击者发现，攻击者无需认证即可访问到
容器数据，从而导致敏感信息泄露；也可以恶意删除容器上的数据，或可进一步利用容器
自身特性，直接访问主机上的敏感信息，获取服务器 root 权限，对敏感文件进行修改并
最终完全控制服务器

（3）有毒的安全镜像

开发者通常会在 Docker 官方的 Docker Hub 仓库下载镜像，这些镜像一部分来源于
开发镜像内相应软件的官方组织，但还有大量镜像来自第三方组织甚至个人。在整个应用
生命周期中，开发人员、测试人员和运维人员会根据不同需求下载并运行镜像，所以在容
器运行前进行镜像检查非常重要。
除了 Docker Hub 外，还有大量的第三方镜像仓库，如国内的网易 163、中国科学
技术大学、daoclud、阿里云等。这些第三方镜像仓库，在提供方便获取镜像的同时，也
带来了潜在的安全风险。例如，下载镜像内软件本身是否包含漏洞，下载的镜像是否被恶
意的植入后门，镜像在传输过程中是否被篡改。

a、镜像使用包含漏洞的软件

b、攻击者上传恶意镜像

如果有黑客在制作镜像时植入木马、后门等恶意软件，并将恶意镜像上传至 Docker Hub
等公共仓库，那么用户的容器环境从一开始就已经不安全了，后续更没有什么安全可言。
比如 Docker 对镜像不安全的处理管道，Docker 支持三种压缩算法，分别是 gzip、
bzip2、xz 。gzip 和 bzip2 使用 Go 的标准库，所以相对安全；xz 由于没有使用原生的
Go 去实现，又由于其使用由 C 编写的 XZ Utils 开源项目，所以存在 C 程序恶意写入的
可能，一旦被写入会导致执行任意代码漏洞，而只要有一个漏洞，执行 docker pull 拉取
镜像时就有可能导致整个系统沦陷

（4）容器隔离失败

由于容器与主机共享内核，可能会存在容器隔离失效的安全风险，主要有以下几种场
景：
攻击者只要攻破容器操作系统内核，就可访问到主机上的文件系统，或进入其它容
器，导致容器隔离失效。
主机的文件系统可以被挂载到多个容器的目录里，那么不同的容器就可以访问同一个
目录。例如只要进入某个容器中，就可以通过共同挂载目录，访问其它容器的文件系统，
这样可能会引起信息泄露或内容篡改等安全问题。

2、安全威胁

（1）容器逃逸

利用虚拟化软件存在漏洞，通过容器获取主机权限入侵主机。Shocker，执行了系统调用 open_by_handle_at 函数可从 Docker 容器逃逸并读取到主机某个目录的文件内容。Linux 手册中特别提到调用 open_by_handle_at 函数需要具备 CAP_DAC_READ_SEARCH 能力，而 Docker1.0 版本对 Capability 使用黑名单管理策略，并且没有限制 CAP_DAC_READ_SEARCH 能力，因而引发了容器逃逸的风险。

（2）容器网络攻击

目前 Docker 总共提供三种不同的网络驱动，分别是桥接网络（Bridge
Network），MacVLAN，覆盖网络（Overlay Network），三种网络驱动都存在着安全
风险。
第一种是 Docker 预设的桥接网络驱动，一个 docker0 的网桥将所有容器连接该网桥，
docker0 网桥扮演着路由和 NAT 的角色，容器间通信都会经过容器主机。如果各容器之
间没有防火墙保护，攻击者就可以利用主机内部网络进行容器间相互攻击。
第二种是 MacVLAN，这是一种轻量级网络虚拟化技术，MacVLAN 与主机的网络接口连
接，MacVLAN 相比于桥接网络驱动加强了与实体网络的隔离性，但是在该网络驱动中，
同一个虚拟网络下的容器之间没有进行权限管控，攻击者可以轻易获得容器权限并进行网
络攻击。
第三种是 Overlay Network，主要是利用 VXLAN 技术，在不同主机之间的
Underlay 网络之上再组成新的虚拟网络。这种网络架构在分布式的编排框架中常常用
到，在快速构建分布式容器集群的同时，也存在着一些弊端。最为明显的是 VXLAN 网络
上的流量没有加密，传输内容很容易被攻击者盗取或篡改。

不过 Docker 使用者可以在设定 IPsec Tunnel 参数时，选择加密来保证容器网络的安
全。此外，与前两种驱动一样，Overlay Network 模式下容器间的连接并未有效控制，
这也是目前容器网络普遍存在的问题，可能会导致如 ARP 欺骗、嗅探、广播风暴等攻
击。

（3）拒绝服务攻击

由于容器在技术实现上基于主机内核，采用共享主机资源的方式，因此面向容器的拒
绝服务攻击（DoS）威胁程度更高。例如，默认情况下容器可以使用主机上的所有内存，
如果某个容器以独占方式访问或消耗主机的大量资源，则该主机上的其它容器就会因为缺
乏资源而无法正常运行。
DoS 攻击可针对任何资源，例如计算资源、存储资源、网络资源等，下面分别以这三种资
源进行说明。

a、计算资源

Fork Bomb1 是一个很典型的计算型 DoS 攻击场景，主机内核正常情况下只能支持
一定数量的进程，如果某个容器内的进程组新建过多进程，消耗了主机上的所有进程资
源，那其它的容器就没有资源来创建新的进程，甚至会危及主机的正常工作。

b、存储资源

在容器技术的实现中，通过 mount 命名空间实现了文件系统的隔离。但是文件系统
隔离仅仅是一个非常基本的要求。不建议使用 AUFS 做存储驱动，虽然 AUFS 创建出的
容器文件系统互相隔离，但是在存储空间方面却没有任何限制。换言之，一个容器如果不
断写文件，将会写满存储介质，其它容器将无法执行写操作，导致拒绝服务攻击。

c、网络资源

容器内网络带宽耗尽也是其中一种，攻击者使用大量的受控主机向被攻击目标（容器）发送大量的网络数据包，以占满容器的网络宽带，并消耗容器主机的网络数据处理能力，达到拒绝服务的目的。

3、容器应用安全

（1）微服务安全

微服务由于将传统的单体应用模块拆分为众多的服务，其端口数量的暴涨必然导致攻
击面增多。对于传统的单体应用架构，访问权限、授权机制、隔离审计等只需要做好一道
入口的防护即可。
而对于微服务架构来说由于含有多个服务，故每个服务的访问都要进行适当的监控管
理和保护。可以想象下，如果在众多的微服务中泄露了某个身份验证令牌或接收了伪造的
访问凭证，那整个系统都会陷入威胁中，这些威胁无疑增加了安全防护的难度。
微服务通常由许多服务构成，虽然微服务提倡隔离、轻量、独立开发部署、业务间松
耦合等，但有时服务间是需要紧密相联的，比如多个服务间共享数据。这些服务之间的联
系在微服务架构中通常是以点对点的形式呈现，随着这些联接的增多，如果其中一个服务
因安全漏洞被攻破，那么其它联接的服务也会受到牵连，从而整个系统都会落入攻击者手
中。
此外，微服务通常使用容器作为载体，应用被打包成镜像，并以容器的方式分布式地
运行在微服务架构中，容器自身有许多安全威胁，比如从容器逃逸宿主机，容器网络攻击等。

（2）DevOps安全

DevOps 这种开发和运营的新模式，缩短了软件生命周期各个环节的等待时间，减少
了很多重复性、手工性的工作，使得解决问题的成本明显降低，提高了敏捷开发的效率。
但敏捷之余忽略安全，这会是一个危险的信号，而且正在不断的被验证着

二、境界容器安全整体防护思路

1、模型

 针对容器出现的风险和威胁，传统防护手段已经失效，纵观容器的生命周期，容器存
在的三个形态为：模板、镜像和容器。应用容器是由模版文件先进行编译成镜像，镜像通
过运行变成容器，最终容器方式运行其中的应用。
在整个容器的安全生命周期中，我们采用自动检测、自动分析、自动处理的方式来防
御整个容器生命周期中所遇到的安全威胁。
在防护技术上我们使用到智能检测、机器学习与威胁预测等先进的方法来确保容器及
容器内应用安全。

2、整体产品框架和主要功能

 对容器全生命周期安全管控，需要涉及到容器的各个环节，通过一套容器安全管理平
台对容器镜像文件的制作过程、容器运行的过程以及容器内应用进行全自动的安全检测、
预警与防护，其中包括：

（1）模板文件的安全防护

对模板文件进行自动的安全审查，识别出模板文件中危险的安全行为，如非法添加了
恶意文件、越权的访问以及被禁止的端口映射等等，同时还需要对模板文件中的行为动作
进行合规审查，以发现不符合行业规范和等级保护要求。

（2）镜像文件安全防护

对制作的镜像文件进行静态和动态的安全扫描，以发行镜像文件中的安全漏洞、木马
病毒、涉密的文件及环境变量，从而保证进入生产环境的镜像是安全的，还需对镜像的来
源和历史操作行为进行分析，对非法来源和有安全问题的镜像禁止运行

（3）容器运行保护

对容器运行过程进行全程的安全监控，进而对容器访问宿主机的资源进行细粒度的控
制，防止有越权访问破坏容器隔离性的行为。

（4）容器内应用保护

对容器内应用的安全漏洞识别、网络威胁检测，从而保证容器内应用的安全。

（5）容器运行环境的保护

对容器的相关运行环境，如镜像仓库、容器守护进程、容器编排集成工具进行安全风
险识别及控制。

三、容器镜像安全

1、镜像深度扫描

每个容器镜像都是由一系列的“镜像层”组成的，需要对其解包后安全分析扫描以发
现安全漏洞。我们从 cve 漏洞、木马病毒、可疑历史操作、敏感信息泄露、以及是否是可
信任镜像等多个维度对镜像文件进行深度分析。
镜像检测的核心是已知系统 CVE 检测。扫描器获取到镜像后，将它分离成相应的层
和软件包（Package）。然后这些 Package 将与多个 CVE 数据库 Package 的名称和版
本进行对比，从而判定是否存在漏洞。

而对镜像中的文件进行分层提取后，同时逐层进行恶意代码检测。主要检测
webshell 和木马病毒。我们采用 3 种检测方式，分别如下：
• 模糊哈希
• yara 规则
• 机器学习的 CNN-Text-Classfication 分类算法
通过模糊哈希算法来匹配 docker 镜像中的文件内容，对于可疑的文件进行打分。同
时使用病毒引擎，进行恶意代码识别，还使用 CNN-Text-Classfication 分类算法对文件
进行检测。三种检测方法都有相应的权重，最终会根据打分结果来判断文件是否是木马病
毒文件。
通过对镜像文件进行解包后，从 manifest.json 中读取历史操作信息。将历史操作信
息发送到扫描器分析层，进行安全分析，对于可疑历史操作会进行标注并触发报警。
通过 manifest.json 读取 layer 信息。对 layer 信息进行分析，提取 layer 中文件内
容，对证书格式文件进行内容匹配。检测是否存在信息泄露风险。
对镜像的证书标签和仓库来源进行可信检测，以排除从不可信的仓库或者直接安装的
容器镜像。

2、镜像运行安全策略

当发现有安全问题的容器镜像时，防护容器可以通过禁止其运行来达到防护的效果：
支持镜像运行的安全策略如下：

• 发现镜像以 root 用户运行禁止运行
• 发现镜像有指定的安全级别的漏洞禁止运行
• 发现镜像内有指定某 CVE 漏洞禁止运行
• 发现镜像内有木马病毒禁止运行
• 发现镜像内有特定的软件包版本禁止运行
• 发现镜像内有非信任镜像禁止运行
• 发现镜像内有私有证书禁止运行

四、容器运行安全

1、容器网络安全检测

容器网络安全检测模块主要用于抓取容器直接的连接信息、容器所在机器的 pod 信
息和容器中的进程信息。
容器网络安全检测模块分为网络探针层、网络收集层、连接绘制层。
网络探针层通过 ebpf 来抓取网络连接信息，如果获取不到，则调用 conntrack 系统
命令来获取网络连接。网络探针层通过 k8s api 来进行服务发现，获取服务信息。网络探
针层从/proc 获取进程信息。网络探针层将以上抓取的网络信息发送到网络收集层。
网络收集层定时将以上网络信息拍摄快照，入库。链接绘制层通过分析网络快照信
息，绘制出容器之间的连接关系。
可对异常的网络流量进行分析预警，如异常的出入站流量，大流量等等

 2、集群内网络隔离

境界容器安全防护平台中的服务微隔离功能实现了集群内部东西向流量的访问控制。
在集群中部署的防护容器会探测发现所有 POD 和服务，识别出集群内部 POD、服务之间
的流量转发路径。通过配置 kubernetes 的 networkpolicy 和自定义的 iptables 流量转
发规则，来阻断、放行指定流量，达到对集群内部服务、POD 之间东西向流量控制的目
的。

五、容器内应用安全

1、集群内服务自动发现

在 k8s 集群中，服务是运行在 Pod 中的。Pod 在运行中可能会重建，IP 可能会变。
Service 可以将 pod IP 封装起来，即使 Pod 发生重建，依然可以通过 Service 来访问
Pod 提供的服务。利用 kube-dns 插件，我们可以通过域名来访问集群内的 Service，解
决了 Service 自动发现的问题。
我们的应用扫描器会自动通过 api 来获取 k8s 集群中的服务，并将服务所对应的域名
和端口信息加入到应用扫描队列交给应用扫描器进行扫描

2、服务及应用自动扫描

扫描任务获取器定时从任务队列中获取扫描任务，并交给爬虫模块对应用程序进行页
面抓取以获取页面文件与目录信息。同时通过端口扫描模块，获取所对应的服务以及版本
信息。之后通过指纹识别模块识别出应用程序的名称以及版本信息。将以上信息收集后交
由通用漏洞检测模块以及 exploit 检测模块检测应用程序漏洞。最终通过漏洞汇总模块将
发现的应用程序漏洞入库。具体流程如下：

3、服务及应用手动扫描

与服务及应用自动扫描流程类似，也可在页面中配置相应ip和端口，对指定应用程序漏洞扫描。

• sql 注入

• xss

• 命令执行

• 文件包含

• csrf

• ssrf

• 文件上传

• 敏感信息泄露

• 未验证的重定向与转发

• 失效的身份认证与会话管理

• 越权访问

六、容器安全合规检查

1、容器CIS合规检查

从主机安全配置、docker 守护进程配置、docker守护程序文件配置、容器镜像和构建文件、容器运行时保护、docker 安全操作、docker集群配置等 7 个方面对容器 cis 进行合规检查。

2、集群CIS合规检查

包含master节点、work节点方面