安全风险
和挑战
脆弱性
和安全风险分析作为容器技术的一种具体实现，Docker 近年来受到越来越多的关注，在某种程度上，Docker 已经成为了容 器技术的代表。Docker 在设计上，采用了常见的 Client/Server（C/S）架构，在 Docker 主机运行 Docker 服务程 序（Docker Daemon），Docker Client 根据需求向 Docker 服务程序发出相关的请求，其架构如下图所示。本节 将以 Docker 为例，介绍容器的脆弱性和安全风险。
Client Docker Host Regis
try
dockerbuild Docker Daemon redis nginx
dockerpull ubuntu tomcat dockerrun Containers Images
Container redis
Container nginx
Container ubuntu
Container
软件风险
作为一款软件，Docker 在软件设计及代码实现上，会有一些安全风险，本小节分别从 Docker 的软件设计和 代码漏洞两个层面分析其存在的安全风险。 3.1.1.1 软件设计 Docker 的设计虽然实现了良好的操作系统 级隔离，但同时也存在很多安全隐患，比如其默认的组网模式以 及与主机共享操作系统内核、共享主机资源、采用 Linux Capabilities 机制、隔离的不充分等，接下来分别对以上 几种安全隐患可能导致的攻击作以说明。（1）局域网 攻击从网络实现来看，Docker 支持多种组网模式，在默认的桥接模式组网下，即同一主机上创建的容器都桥接 挂在网桥 docker0 上，这样同一主机上的容器之间可以构成局域网，因此针对局域网的 ARP欺骗、嗅探、广播 风暴等攻击方式将会对这些容器造成安全威胁。所以在一个主机上部署多个容器需要进行合理的网络配置，设置 访问控制规则，实现网络之间的隔离和边界。 （2）拒绝服务攻击 容器实例共享主机的资源，也就是说底层的 CPU、内存和磁盘等资源由主机操作系统进行统一的调度和分配。 如果不对每个容器的可用资源进行有效的限制和管理，就会造成容器之间资源使用不均衡，严重时可能导致主机 和集群资源耗尽，造成拒绝服务。
（3）有漏洞的系统调用 Docker 与虚拟机的主要区别是，Docker 与主机共用一个操作系统内核，如果主机内核存在横向越权或者提 权漏洞，尽管容器是以非特权模式运行的，但容器中的攻击者还是可以利用内核漏洞逃逸到主机，进行恶意行为 操作。 （4）特权模式共享 root 权限 既然容器与宿主机共用一个操作系统内核，当以特权模式运行容器时，容器内的 root 权限，进而可以在容器中进行几乎无限制的操作。 （5）未隔离的文件系统 虽然 Docker 已经对文件系统进行隔离，但是root 用户也就拥有了主机 有一些重要的系统文件暂时没有被隔离，如 /proc/bus sys，/proc/sys，等。
针对以上可能造成的攻击，Docker 已有了对应防护方案，只要根据防护方案做好相应配置即可以避免以上 问题，具体可参考官网文档 [39]，此处由于篇幅限制，不再赘述。 3.1.1.2 软件漏洞 根据国家信息安全漏洞库 [40] 的统计，截至 2018 年 7 月 31 日，Docker 相关的漏洞共 38 个，其中包括 Cisco、boot2docker、Jenkins 等厂商产品或开源项目。 图 3.2 显示了所有漏洞的发布数量随时间的分布情况，从图中可以看出，每年都会有一定数量的 Docker 漏 洞公布出来，说明软件在漏洞上并没有减少的趋势，还是存在一定的安全风险。
8ñ, 21% 8个, 21%
2014
2015
2016 5ñ, 13% 6个, 16%
2017 2018
11个, 29%
在所有标注了危害等级的 33 个安全漏洞中，中危及以上的漏洞占比达到 90% 以上，高危和超危漏洞占 36%。CVSS 评分 10 分的超危漏洞就包括 4 个，其中 CVE-2014-9357 出现在 Docker 1.3.2 版本中，远程攻击者 可借助 LZMA(.xz)归档的 Dockerfile 中特制的‘image’或‘build’，利用该漏洞以 root 权限执行任意代码； CVE-2016-9223 是 Cisco CloudCenter Orchestrator 中的 Docker Engine 配置安全漏洞，该漏洞源于程序没有正确 配置文件，远程攻击者可利用该漏洞提升权限在受影响的系统中部署 Docker 容器。图 3.3 显示了所有漏洞的风 险程度汇总。
1 数据统计截至 2018-7-31。
图 3.4 对所有漏洞可能造成的安全风险进行了统计分析，从图中可以看出，Docker 漏洞隐藏的风险主要包括 权限和访问控制、后置链接、资源管理错误、输入验证等。比如 Docker Engine 1.12.2 版本中存在的 CVE-2016- 8867 漏洞就是权限和访问控制威胁例子，该漏洞源于启用的环境条件配置了错误的条件策略。攻击者可借助恶 意的镜像利用该漏洞绕过用户许可，访问文件系统容器或挂载磁盘中的文件。
信息泄露 输入验证 资源管理错误 跨站请求伪造 竞争条件 权限许可/访问控制 路径遍历 后置链接 代码注入
API 接口安全
按照 Docker 的实现架构，Docker 服务默认监听在 Unix Socket 上，比如 unix:///var/run/docker.sock，为了 实现集群管理，Docker 官方还提供了一个远程管理接口的 REST API，允许通过 TCP 远程访问 Docker 服务。 1 数据统计截至 2018-7-31。 2 数据统计截至 2018-7-31。
例如在使用 Docker Swarm 时，Docker 节点上会开放一个 TCP 端口 2375，绑定在 0.0.0.0 上。Docker 服 务作为守护进程运行在后台，这个守护进程默认会采用非加密端口的形式，将服务监听端口 2375 暴露出来， 也可以通过执行以下启动参数 dockerd -H=0.0.0.0:2375 -H unix:///var/run/docker.sock 让 Docker 监听本地所 有地址的 2375 端口，这样本地守护进程就可以执行接收到的 Docker 命令请求。例如，通过执行 docker –H tcp://HOST 主机上所有的 Docker 实例。既然能够执行 docker ps 命令， 那么同样可以执行 docker run 、docker rm 等。 但是开启这种没有任何加密和访问控制的 Docker Remote API 服务是非常危险的。尤其是将默认的 2375 端 口暴露到互联网中，一旦被攻击者发现，攻击者无需认证即可访问到容器数据，从而导致敏感信息泄露；也可以 恶意删除容器上的数据，或可进一步利用容器自身特性，直接访问主机上的敏感信息，获取服务器 root 权限，对 敏感文件进行修改并最终完全控制服务器。 2018 年 5 月 -7 月我们利用绿盟威胁情报中心（NTI）[41] 对全网的 2375 端口进行检索，发现这段时间暴露 在互联网上的 2375 端口地址达 337 个。图 3.5 显示了在全球范围内暴露主机的分布情况，从图中可以看出， 主机暴露数据覆盖多达 29 个国家，这个数据一方面说明了 Docker 的受欢迎程度，另一方面也说明了用户对于 Docker 的使用还不是很规范，需要规范操作来规避风险。
针对前述 337 个服务的 IP 地址，本文针对地理区域进行了统计。从图 3.4 中可以看出，在全球范围内，互 联网上暴露的 Docker 服务主要分布于中国、美国以及德国，其中中国有 197 个 IP 地址以 52% 位居第一，美国 有 65 个 IP 地址以 17% 位居第二，德国有 19 个 IP 以 7%位居第三。 从图 3.6 中可以看出，在中国范围内，互联网上暴露的 Docker 服务主机主要存在浙江、北京以及广东。其 中浙江有 57 个 IP 占比 29%，北京有 43 个 IP 占比 22%，广东有 35 个 IP 占比 18%。
针对前述暴露的 337 个 Docker 服务 IP，我们对其域名服务分布情况进行了统计，其中不乏某些知名公有云 厂商的 IP 地址。 需要说明的是，将 2375 端口暴露在互联网属于错误配置，而非 Docker 的漏洞。关于这个问题，在 Docker 官方使用文档中也有明确的警告：如果将 Docker 服务绑定到一个互联网的 TCP 端口，将可能使得恶意用户获取 主机的 root 权限。 Warning: Changing the default docker daemon binding to a TCP port or Unix docker user group will increase your security risks by allowing non-root users to gain root access on the host. Make sure you control access to docker. If you are binding to a TCP port, anyone with access to that port has full Docker access; so it is not advisable on an open network.
除了对 Docker Daemon 远程访问端口 2375 暴露情况进行分析外，我们在 2018 年 7 月也分析了 Kubernetes 的暴露服务情况，利用 NTI对全网的 6443 端口（Kubernets 的 API Server 默认 SSL 端口）进行扫描分析，发现 这段时间暴露在互联网上的 Kubernetes 服务达 12803 个。图 3.8 显示了在全球范围内的 Kubernetes 服务暴露分 布情况。
与 Docker Daemon 远程访问端口 2375 相似，全网范围内暴露 Kubernetes 服务主要分布在美国、中国以及 德国，其中美国以 4886 个暴露的服务占比 38% 位居第一，中国以 2582 个暴露的服务占比 20% 位居第二，德国 以 1423 个暴露的服务占比 11% 位居第三。这些服务主要部署在亚马逊、阿里云等公有云服务上。
由图 3.10 可见，国内互联网上暴露的 Kubernetes 服务主机主要存在于北京、浙江以及广东等省市。其中北 京以 695 个暴露的服务占比 27% 位居第一，浙江以 635 个暴露的服务占比 25% 位居第二，广东以 274 个暴露的 服务占比 11% 位居第三。 由上可见，目前国内外的容器编排系统发展迅速，基于其部署特性，互联网上多见于公有云、数据中心，编 排系统服务的暴露分布也与容器服务、云服务的发展趋势所匹配。正因为容器和容器编排系统大量部署，相当多 的服务被暴露在互联网上，增加了攻击面，其中又有很大一部分服务缺乏基本的安全配置和加固，导致很容易被 攻击者利用，破坏系统的可用性和完整性，又有可能被利用对第三方发动各类攻击。
