7.2. Docker

7.2.1. 虚拟化技术与容器技术

7.2.1.1. 传统虚拟化技术

传统虚拟化技术通过添加hypervisor层，虚拟出网卡，内存，CPU等虚拟硬件，再在其上建立客户机，每个客户机都有自己的系统内核。传统虚拟化技术以虚拟机为管理单元，各虚拟机拥有独立的操作系统内核，不共用宿主机的软件系统资源，因此具有良好的隔离性，适用于云计算环境中的多租户场景。

7.2.1.2. 容器技术

容器技术可以看作一种轻量级的虚拟化方式，容器技术在操作系统层进行虚拟化，可在宿主机内核上运行多个虚拟化环境。相比于传统的应用测试与部署，容器的部署无需预先考虑应用的运行环境兼容性问题；相比于传统虚拟机，容器无需独立的操作系统内核就可在宿主机中运行，实现了更高的运行效率与资源利用率。

7.2.2. Docker

Docker是目前最具代表性的容器平台之一，具有持续部署与测试、跨云平台支持等优点。在基于Kubernetes等容器编排工具实现的容器云环境中，通过对跨主机集群资源的调度，容器云可提供资源共享与隔离、容器编排与部署、应用支撑等功能。

7.2.2.1. 基本概念

Docker有三个基本概念，镜像（Image）、容器（Container）、仓库（Repository）。镜像是一个只读的模版，由一组文件系统通过Union FS技术组成。

镜像是静态的定义，容器是从镜像创建的运行实例。容器的本质是进程，拥有自己独立的命名空间。

仓库（Repository） 是集中存放镜像文件的场所，用于存储、分发镜像。

容器可以被启动、开始、停止、删除，每个容器都是相互隔离的，可以把容器看做是一个简易版的 Linux 环境（包括root用户权限、进程空间、用户空间和网络空间等）和运行在其中的应用程序。

7.2.2.2. 组成

Docker引擎由如下主要组件构成：Docker客户端（Docker Client）、Docker守护进程（Docker daemon）、containerd以及RunC，它们共同负责容器的创建和运行。

Docker Client是和Docker Daemon建立通信客户端，Docker Client可以通过http/unix socket等方式Daemon建立通信。

Docker Daemon是容器管理的守护进程，在宿主机运行，作为服务端接受来自客户端的请求，主要功能包括镜像管理、镜像构建、REST API、身份验证、安全、核心网络以及编排。Docker daemon通过位于 /var/run/docker.sock 的本地 IPC/Unix socket 来实现Docker远程API，默认非TLS网络端口为2375，TLS默认端口为2376。

containerd 是容器技术标准化之后出现的，用于将容器运行时从 Docker Daemon 剥离。containerd 主要职责是镜像管理、容器执行。

RunC 是 Docker 按照OCF标准制定的一种具体实现，实现了容器启动与停止、资源隔离等功能。

7.2.2.3. 数据

Docker的数据主要分为持久化和非持久化数据，默认情况下非持久化存储是自动创建生命周期与容器相同，删除容器也会删除非持久化数据，在Linux环境下，非持久化数据默认存储于 /var/lib/docker/ 下。

7.2.2.4. 网络

Docker网络架构源自一种叫作容器网络模型的方案，主要由CNM、Libnetwork、网络驱动构程。

7.2.3. 安全风险与安全机制

在考虑Docker安全性的时候主要考虑以下几点

  • 内核本身的安全性及其对命名空间和cgroups的支持

  • Docker守护进程本身的攻击面

  • 内核的“强化”安全功能以及它们如何与容器进行交互

7.2.3.1. Docker安全基线

benchsec

7.2.3.2. 内核命名空间/namespace

Docker容器与LXC容器非常相似，并且具有相似的安全特性。当使用docker运行启动容器时，Docker会在后台为容器创建一组命名空间和控制组。

命名空间提供了一个最直接的隔离形式：在容器中运行的进程看不到或者无法影响在另一个容器或主机系统中运行的进程。

每个容器也有自己的网络堆栈，这意味着一个容器不能获得对另一个容器的套接字或接口的特权访问。当然，如果主机系统相应设置，容器可以通过各自的网络接口交互。如果为容器指定公共端口或使用链接时，容器之间允许IP通信。

它们可以相互ping通，发送/接收UDP数据包，并建立TCP连接，但是如果需要可以限制它们。从网络体系结构的角度来看，给定Docker主机上的所有容器都位于网桥接口上。这意味着它们就像通过普通的以太网交换机连接的物理机器一样。

7.2.3.3. Control Group

控制组是Linux容器的另一个关键组件，主要作用是实施资源核算和限制。

Cgroup 提供了许多有用的度量标准，但也有助于确保每个容器都能获得公平的内存，CPU和磁盘I/O; 更重要的是单个容器不能通过耗尽资源的方式来降低系统的性能。

因此，尽管 Cgroup 不能阻止一个容器访问或影响另一个容器的数据和进程，但它们对于抵御一些拒绝服务攻击是至关重要的。它们对于多租户平台尤其重要，例如公共和私人PaaS，即使在某些应用程序开始行为不当时也能保证一致的正常运行时间（和性能）。

7.2.3.4. 守护进程的攻击面

使用Docker运行容器意味着运行Docker守护进程，而这个守护进程当前需要root权限，因此，守护进程是需要考虑的一个地方。

首先，只有受信任的用户才能被允许控制Docker守护进程。具体来说，Docker允许您在Docker主机和访客容器之间共享一个目录;它允许你这样做而不限制容器的访问权限。这意味着可以启动一个容器，其中/host目录将成为主机上的/目录，容器将能够不受任何限制地改变主机文件系统。

这具有很强的安全意义：例如，如果通过Web服务器测试Docker以通过API配置容器，则应该更加仔细地进行参数检查，以确保恶意用户无法传递制作的参数，从而导致Docker创建任意容器。

守护进程也可能容易受到其他输入的影响，例如从具有docker负载的磁盘或从具有docker pull的网络加载映像。

最终，预计Docker守护进程将运行受限特权，将操作委托给审核良好的子进程，每个子进程都有自己的（非常有限的）Linux功能范围，虚拟网络设置，文件系统管理等。也就是说，很可能，Docker引擎本身的部分将在容器中运行。

7.2.3.5. Capability

默认情况下，Docker采用Capability机制来实现用户在以root身份运行容器的同时，限制部分root的操作。

在大多数情况下，容器不需要真正的root权限。因此，Docker可以运行一个Capability较低的集合，这意味着容器中的root比真正的root要少得多。例如：

  • 否认所有挂载操作

  • 拒绝访问原始套接字（防止数据包欺骗）

  • 拒绝访问某些文件系统操作，如创建新的设备节点，更改文件的所有者或修改属性（包括不可变标志）

  • 拒绝模块加载

  • 其他

这意味着，即使入侵者在容器内获取root权限，进一步攻击也会困难很多。默认情况下，Docker使用白名单而不是黑名单，去除了所有非必要的功能。

7.2.3.6. Seccomp

Docker使用Seccomp来限制容器对宿主机内核发起的系统调用。

7.2.4. 攻击面分析

7.2.4.1. 供应链安全

在构建Dockerfile的过程中，即使是使用排名靠前的来源，也可能存在CVE漏洞、后门、镜像被污染、镜像中的依赖库存在漏洞等问题。

7.2.4.2. 虚拟化风险

虽然Docker通过命名空间进行了文件系统资源的基本隔离，但仍有 /sys 、/proc/sys 、 /proc/bus 、 /dev 、time 、syslog 等重要系统文件目录和命名空间信息未实现隔离，而是与宿主机共享相关资源。

7.2.4.3. 利用内核漏洞逃逸

  • CVE-2016-5195

7.2.4.4. 容器逃逸漏洞

  • CVE-2021-41091

  • CVE-2019-14271 Docker cp

  • CVE-2019-13139 Docker build code execution

  • CVE-2019-5736 runC

    • Docker Version < 18.09.2

    • Version <= 1.0-rc6

  • CVE-2018-18955

7.2.4.5. 配置不当

  • 开启privileged

  • 挂载宿主机敏感目录

  • 配置cap不当

    • --cap-add=SYS_ADMIN

  • 绕过namespace

    • --net=host

    • --pid=host

    • --ipc=host

7.2.4.6. 拒绝服务

  • CPU耗尽

  • 内存耗尽

  • 存储耗尽

  • 网络资源耗尽

7.2.4.7. 危险挂载

  • 挂载 /var/run/docker.sock

  • 挂载宿主机 /dev /proc 等危险目录

7.2.4.8. 攻击 Docker 守护进程

虽然 Docker 容器具有很强的安全保护措施，但是 Docker 守护进程本身并没有被完善的保护。Docker 守护进程本身默认由 root 用户运行，并且该进程本身并没有使用 Seccomp 或者 AppArmor 等安全模块进行保护。这使得一旦攻击者成功找到漏洞控制 Docker 守护进程进行任意文件写或者代码执行，就可以顺利获得宿主机的 root 权限而不会受到各种安全机制的阻碍。值得一提的是，默认情况下 Docker 不会开启 User Namespace 隔离，这也意味着 Docker 内部的 root 与宿主机 root 对文件的读写权限相同。这导致一旦容器内部 root 进程获取读写宿主机文件的机会，文件权限将不会成为另一个问题。这一点在 CVE-2019-5636 利用中有所体现。

7.2.4.9. 其他CVE

  • CVE-2014-5277

  • CVE-2014-6408

  • CVE-2014-9357

  • CVE-2014-9358

  • CVE-2015-3627

  • CVE-2015-3630

7.2.5. 安全加固

  • 最小安装

    • 删除所有开发工具（编译器等）

  • 更新系统源

  • 启用 AppArmor

  • 启用 SELinux

  • 限制运行容器的内核功能

  • 移除依赖构建

  • 配置严格的网络访问控制策略

  • 不使用root用户启动docker

  • 不以privileged特权模式运行容器

  • 控制资源

    • CPU Share

    • CPU 核数

    • 内存资源

    • IO 资源

    • 磁盘资源

    • 硬件资源

    • 单位时间内进程数量上限

  • 使用安全的基础镜像

  • 定期安全扫描和更新补丁

  • 删除镜像中的 setuid 和 setgid 权限

    • RUN find / -perm +6000-type f-exec chmod a-s {} \;|| true

  • 配置Docker守护程序的TLS身份验证

  • 如非必要 禁止容器间通信

  • rootless Docker

  • 使用 Seccomp 限制 syscall

  • 构建环境和在线环境分开

  • 证书校验

7.2.6. Docker 环境识别

7.2.6.1. Docker内

  • MAC地址为 02:42:ac:11:00:00 - 02:42:ac:11:ff:ff

  • ps aux 大部分运行的程序 pid 都很小

  • cat /proc/1/cgroup docker的进程

  • docker 环境下存在 .dockerenv

  • 部分容器中缺少许多常用的命令如 ping 等

7.2.6.2. Docker外

  • /var/run/docker.sock 文件存在

  • 2375 / 2376 端口开启

7.2.7. 参考链接