【报告解读系列二】容器环境脆弱性分析

阅读： 46

容器技术基于容器主机操作系统的内核，通过对CPU、内存和文件系统等资源的隔离、划分和控制，实现进程之间透明的资源使用。因此，容器主机的安全性对整个容器环境的安全有着重要的影响。

1.   概述

最近有很多关于容器安全性的讨论，尤其是当在生产环境中部署使用容器的时候。容器环境所面临的大多数安全威胁，和非容器环境存在的威胁在本质上基本是一致的。只不过基于容器的某些特性，出现了一些新的场景和攻击面。

那么对于容器环境来说，都有什么样的安全威胁呢？总结起来可以从以下三个方面来进行简单划分。

（1）基础设施/运行环境是否是安全的。容器技术是基于容器主机操作系统内核实现的资源隔离，相比较vm来讲，容器对主机的操作系统有了更多的权限，因此诸如OS的安全补丁、API、权限、认证、隔离等问题对容器的安全性有着很大的影响。

（2）容器的镜像是否是安全的。关于容器镜像的安全性，比如像镜像的漏洞、恶意程序等问题，之前的文章《 容器镜像的脆弱性分析 》已经进行了比较全面的分析，这里就不再过多介绍了。

（3）容器运行时是否是安全的。比如容器中是否运行了非法的进程、是否遭到了DDoS攻击、是否发生了逃逸等。

2. 容器环境脆弱性分析

本小节将从三个方面，简单介绍容器基础设施/运行环境的安全性。

2.1 容器逃逸

容器逃逸攻击与虚拟机逃逸攻击相似，利用虚拟化软件存在的漏洞，通过容器获取主机权限入侵主机，以达到攻击主机的目的。这里通过容器入侵主机的逃逸，一方面包括在容器中获取到更多的主机权限；另一方面包括不完善的隔离存储。

具体地，一些PoC工具，如Shocker，可展示如何从Docker容器逃逸并读取到主机某个目录的文件内容。Shocker攻击的关键是执行了系统调用open_by_handle_at函数，Linux手册中特别提到调用open_by_handle_at函数需要具备CAP_DAC_READ_SEARCH能力，而Docker1.0版本对Capability使用黑名单管理策略，并且没有限制CAP_DAC_READ_SEARCH能力，因而引发了容器逃逸的风险。

2.2 容器网络

Docker默认采用预设的桥接网络驱动，一个docker0的网桥将所有容器连接该网桥，docker0网桥扮演着路由和NAT的角色，容器间通信都会经过容器主机。

默认情况下，这种桥接采用黑名单的方式，即同一主机上的容器之间是允许所有通信的，用户根据业务需求添加访问控制规则。如果各容器之间没有防火墙保护，攻击者就可以利用主机内部网络进行容器间的ARP欺骗、嗅探、广播风暴等攻击。

2.3 拒绝服务

默认情况下容器可以使用主机上的所有资源，如果某个容器以独占方式访问或消耗主机的大量资源，则该主机上的其它容器就会因为缺乏资源而无法正常运行。

DoS攻击可针对任何资源，例如计算资源、存储资源、网络资源等，下面分别以这三种资源进行说明。

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

Fork Bomb也是自2015年到现在Docker社区一直讨论的问题，目前最好的方法是限制内存的使用（–kernel-memory=#M），但是，当在与加密文件一起使用时可能会偶尔出现问题。

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

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

3. CIS Benchmark

CIS针对Docker和Kubernetes，分别提出了安全基准文档，用于对Docker和Kubernetes运行环境进行安全审计。

下面本文将通过两个例子，介绍在默认情况下容器环境的安全风险。

3.1 Docker默认配置风险

宿主机采用Ubuntu 16.04.4 LTS（4.4.0-116-generic，x86_64）。

参照Docker官方的安装文档https://docs.docker.com/install/linux/docker-ce/ubuntu/#set-up-the-repository，安装Docker。版本如下图所示。

使用docker-bench-security（https://github.com/docker/docker-bench-security）对其进行检查。

检查结果如下表所示：

从上表的结果中可以看出，检查结果总计可以划分为三类：

（1）通知提示（INFO/NOTE）。比如针对2.6的检查，要求确保配置了对Docker daemon访问的TLS认证。而测试环境默认启动的Docker daemon是没有启动TCP监听服务的，因此，对于该条目，设置为通知提示。

（2）通过（PASS）。比如针对2.2的检查，要求确保Docker日志级别设置为“INFO”，Docker默认的日志级别符合该要求，因此检查结果为PASS。

（3）警告（WARN）。比如针对2.1的检查，要求连接在默认网桥上Docker实例之间的网络流量，是要限制其之间的网络访问。而Docker的默认配置，是允许所有实例通信的，因此该条目提示为告警级别。

由于在CIS的标准中，第5章是针对Container Runtime的，在主机上没有容器实例运行时，这一大项的检测是跳过的，因此所有的数据都是0。这种情况下，针对全部的74项检测，除去通知级别的38项，剩下的36项检测中，告警的有12项，比例达到了 33% 。主要包括以下内容。

（1）主机配置检查

确保为存储Docker文件，创建一个单独的分区（逻辑卷）

确保Docker daemon要将审计的能力进行配置，在/etc/audit/audit.rules文件中添加一条审计规则：–w /usr/bin/docker –k docker。

确保对docker文件和目录进行审计，在/etc/audit/audit.rules文件中添加一条审计规则：–w /var/lib/docker –k docker。

同样是对Docker文件和目录进行审计的检查，在/etc/audit/audit.rules文件中添加一条审计规则：–w /etc/docker –k docker。

（2）Docker daemon配置检查

确保容器间在默认的桥接网络上，采用白名单方式实现通信。将docker daemon启动参数（ /etc/docker/daemon.json ）icc设置为false。

确保在Docker守护进程中启用用户命名空间，将启动参数userns-remap设置为default。

确保启用Docker客户端命令的认证授权，Docker默认是没有对客户端命令进行授权管理的功能，这里需要借助第三方插件实现。Docker官方给出的插件主要包括Casbin AuthZ Plugin、HBM plugin和Twistlock AuthZ Broker这三种。可以采用以下命令运行插件：

# docker run -d -v /var/lib/authz-broker/policy.json:/var/lib/authz-broker/policy.json -v /run/docker/plugins/:/run/docker/plugins twistlock/authz-broker

然后在docker daemon启动参数（ /etc/docker/daemon.json ）中的authorization-plugins设置为authz-broker。

确保配置了集中式和远程的日志记录。在docker daemon启动参数（ /etc/docker/daemon.json ）中的log-driver设置为syslog，log-opts设置为{

“syslog-address” : ” = tcp://192.x.x.x”。

确保容器实例可以支持无守护进程运行，也就是说，docker daemon在关闭或者恢复时，不会停止容器，并且可以在daemon重新启动后重新接管。

将docker daemon启动参数（ /etc/docker/daemon.json ）中的live-restore设置为true。

Docker引擎提供了两种将主机端口转发到容器端口的方式：DNAT和Userland Proxy。默认情况下，Userland Proxy已启用。

将docker daemon启动参数（/etc/docker/daemon.json）中的userland-proxy设置为false。

确保限制容器获取新的权限。

将docker daemon启动参数（/etc/docker/daemon.json）中的no-new-privileges设置为true。

（4）Docker镜像和构建文件检查

确保启用了Docker的内容信任，默认情况下，内容信任是被禁止的。可以通过修改环境变量来进行设置，export DOCKER_CONTENT_TRUST=1。

考虑到这里的检测，并未覆盖到第5章中Container Runtime相关的内容，因此在测试环境中，我们运行一个容器，再来进行一下测试，结果如下表所示。

# docker run -d -p 80:80 –read-only -v $(pwd)/nginx-cache:/var/cache/nginx -v $(pwd)/nginx-pid:/var/run nginx（ https://hub.docker.com/_/nginx/ ，以只读模式运行nginx）

对比这两个结果可以发现，1/2/3/6/7这五部分的结果是完全一样的，第四部分原来的2个PASS的内容变成了WARN，第五部分的内容进行了检测。至于第五部分的内容，涉及到运行时，不同的容器可能结果会不同，因此这里不再详细分析。第四部分由PASS转为WARN的2项是：

默认情况下，容器以root权限运行，并且以容器中的用户root身份运行，应确保容器镜像的Dockerfile包含USER指令，或者在USER指令前通过useradd命令添加特定用户。

确保将HEALTHCHECK指令添加到Docker镜像中，进而能够对运行的容器实例进行运行状况检查。默认情况下，HEALTHCHECK未进行设置。

3.2 Kubernetes默认配置风险

采用两节点使用Kubeadm部署Kubernetes v1.12.1。

Master节点检测结果如下表所示。

Worker节点检测结果如下表所示。

由于篇幅的限制，这里就不再对结果进行详细分析了。

点击此链接，下载《2018绿盟科技容器安全技术报告》完整版。

容器安全的全球威胁分析

添加好友，备注“ 进群 ”，加入 容器安全技术交流群 ，通过后会拉您入群。

绿盟科技星云实验室致力于云计算安全，研究方向主要包括：公有云/政务云/行业云/私有云等云计算系统的相关安全问题以及安全解决方案的研究、SDN/NFV等虚拟化网络安全问题的研究、Docker/Kubernetes/Service Mesh/Serverless等云原生相关安全问题及安全解决方案研究、5G在接入安全、切片网络安全、隐私保护等方面的安全问题以及安全解决方案研究、边缘计算在计算、存储、网络等方面的安全问题以及安全解决方案研究等新技术和新领域。在课题研究上，承担并完成了多个国家、省、市以及行业重点单位的创新研究课题。