Docker容器安全性分析( 三 ) _Docker容器

镜像拉取安全：如何保证容器镜像从镜像仓库到用户端的完整性也是镜像仓库面临的一个重要安全问题。由于用户以明文形式拉取镜像，如果用户在与镜像仓库交互的过程中遭遇了中间人攻击，导致拉取的镜像在传输过程中被篡改或被冒名发布恶意镜像，会造成镜像仓库和用户双方的安全风险。Docker已在其1.8版本后采用内容校验机制解决中间人攻击的问题。

容器虚拟化安全风险
与传统虚拟机相比，Docker容器不拥有独立的资源配置，且没有做到操作系统内核层面的隔离，因此可能存在资源隔离不彻底与资源限制不到位所导致的安全风险。
容器隔离问题
对于Docker容器而言，由于容器与宿主机共享操作系统内核，因此存在容器与宿主机之间、容器与容器之间隔离方面的安全风险，具体包括进程隔离、文件系统隔离、进程间通信隔离等。
虽然Docker通过Namespaces进行了文件系统资源的基本隔离，但仍有/sys、/proc/sys、/proc/bus、/dev、time、syslog等重要系统文件目录和命名空间信息未实现隔离，而是与宿主机共享相关资源。
针对容器隔离安全风险问题，主要存在以下两种隔离失效的情况：

攻击者可能通过对宿主机内核进行攻击达到攻击其中某个容器的目的。
由于容器所在主机文件系统存在联合挂载的情况，恶意用户控制的容器也可能通过共同挂载的文件系统访问其他容器或宿主机，造成数据安全问题。

容器逃逸攻击
容器逃逸攻击指的是容器利用系统漏洞，“逃逸”出了其自身所拥有的权限，实现了对宿主机和宿主机上其他容器的访问。由于容器与宿主机共享操作系统内核，为了避免容器获取宿主机的root权限，通常不允许采用特权模式运行Docker容器。
在容器逃逸案例中，最为著名的是shocker.c程序，其通过调用open_by_handle_at函数对宿主机文件系统进行暴力扫描，以获取宿主机的目标文件内容。由于Docker 1.0之前版本对容器能力（Capability）使用黑名单策略进行管理，并没有限制CAP_DAC_READ_SEARCH能力，赋予了shocker.c程序调用open_by_handle_at函数的能力，导致容器逃逸的发生。因此，对容器能力的限制不当是可能造成容器逃逸等安全问题的风险成因之一。所幸的是，Docker在后续版本中对容器能力采用白名单管理，避免了默认创建的容器通过shocker.c案例实现容器逃逸的情况。
此外，在Black Hat USA 2019会议中，来自Capsule8的研究员也给出了若干Docker容器引擎漏洞与容器逃逸攻击方法，包括CVE-2019-5736、CVE-2018-18955、CVE-2016-5195等可能造成容器逃逸的漏洞。

拒绝服务攻击
由于容器与宿主机共享CPU、内存、磁盘空间等硬件资源，且Docker本身对容器使用的资源并没有默认限制，如果单个容器耗尽宿主机的计算资源或存储资源（例如进程数量、存储空间等）可能导致宿主机或其他容器的拒绝服务。
1、计算型DoS攻击
Fork Bomb是一类典型的针对计算资源的拒绝服务攻击手段，其可通过递归方式无限循环调用fork系统函数快速创建大量进程。由于宿主机操作系统内核支持的进程总数有限，如果某个容器遭到了Fork Bomb攻击，那么就有可能存在由于短时间内在该容器内创建过多进程而耗尽宿主机进程资源的情况，宿主机及其他容器就无法再创建新的进程。
2、存储型DoS攻击
针对存储资源，虽然Docker通过Mount命名空间实现了文件系统的隔离，但CGroups并没有针对AUFS文件系统进行单个容器的存储资源限制，因此采用AUFS作为存储驱动具有一定的安全风险。如果宿主机上的某个容器向AUFS文件系统中不断地进行写文件操作，则可能会导致宿主机存储设备空间不足，无法再满足其自身及其他容器的数据存储需求。
网络安全风险
网络安全风险是互联网中所有信息系统所面临的重要风险，不论是物理设备还是虚拟机，都存在难以完全规避的网络安全风险问题。而在轻量级虚拟化的容器网络环境中，其网络安全风险较传统网络而言更为复杂严峻。
容器网络攻击
Docker提供桥接网络、macVLAN、覆盖网络（Overlay）等多种组网模式，可分别实现同一宿主机内容器互联、跨宿主机容器互联、容器集群网络等功能。
1、网桥模式
Docker默认采用网桥模式，利用iptables进行NAT转换和端口映射。Docker将所有容器都通过虚拟网络接口对连接在一个名为docker0的虚拟网桥上，作为容器的默认网关，而该网桥与宿主机直接相连。