Docker 最新漏洞修复教程｜适合站长

适用对象：个人站长、中小型网站运维人员、使用 Docker 部署 WordPress、Halo、Typecho、宝塔面板、Nginx、MySQL、Redis、Node.js、Java、PHP 等服务的网站管理员。
文章目标：帮助站长快速判断 Docker 是否存在安全风险，并通过升级、加固配置、限制权限、检查镜像和容器运行参数等方式降低被入侵的可能性。

一、为什么站长必须重视 Docker 漏洞？

Docker 已经成为很多站长部署网站的首选方案。相比传统手动安装环境，Docker 具备部署快、迁移方便、隔离性较好、环境一致性强等优点。很多站长会使用 Docker 部署反向代理、数据库、缓存、博客系统、监控面板、网盘、邮件服务等应用。

但 Docker 并不是“天然安全”的。它本质上仍然依赖 Linux 内核、容器运行时、镜像仓库、网络规则、挂载目录和权限控制。一旦 Docker 本身、容器运行时组件、镜像或配置存在漏洞，攻击者就可能利用这些问题进行提权、逃逸、植入木马、读取敏感文件，甚至接管整台服务器。

对于站长而言，Docker 漏洞带来的风险通常包括：

• 网站被挂马、跳转、植入暗链；
• 数据库账号、网站源码、配置文件泄露；
• 服务器被用于挖矿、发垃圾邮件或攻击他人；
• Docker 容器逃逸后影响宿主机安全；
• 被攻击者长期驻留，清理后反复被入侵；
• 搜索引擎降权，网站信誉受损。

因此，Docker 漏洞修复不是“可做可不做”的优化项，而是站长服务器安全维护中的基础工作。

二、先判断你的 Docker 是否存在风险

在正式修复之前，建议先检查当前服务器 Docker 版本、运行中的容器、暴露端口和高危配置。以下命令适用于大多数 Linux 服务器。

1. 查看 Docker 版本

docker version

重点关注以下信息：

• Server Version
• containerd version
• runc version
• Docker Engine 版本

如果你的 Docker 长期没有升级，尤其是几个月甚至一年以上没有更新，就应当优先安排修复。

也可以使用：

docker info

查看 Docker 的存储驱动、运行时、Cgroup、镜像数量、容器数量等信息。

2. 查看正在运行的容器

docker ps

查看所有容器，包括已经停止的容器：

docker ps -a

站长需要重点关注：

• 是否存在自己不认识的容器；
• 是否有异常容器名称；
• 是否有奇怪镜像来源；
• 是否有异常端口映射；
• 是否有长时间运行但用途不明的容器。

如果发现陌生容器，不要急着删除，建议先记录信息：

docker inspect 容器ID或容器名
docker logs 容器ID或容器名

这些信息有助于判断是否已经被入侵。

3. 检查是否暴露 Docker API

这是很多站长服务器被入侵的重要原因。Docker API 如果暴露到公网，攻击者可能直接远程创建容器、挂载宿主机目录、写入 SSH 密钥，最终控制服务器。

检查 Docker 是否监听远程端口：

ss -lntp | grep dockerd

如果看到类似下面的监听，需要高度警惕：

0.0.0.0:2375
0.0.0.0:2376

其中 2375 尤其危险，因为它通常代表未加密、未认证的 Docker API。正常情况下，普通站长服务器不应将 Docker API 暴露到公网。

4. 检查高危容器权限

执行：

docker inspect 容器名 | grep -i privileged

如果结果中出现：

"Privileged": true

说明该容器以特权模式运行。特权容器拥有非常高的系统权限，一旦应用被攻破，攻击者更容易影响宿主机。

继续检查是否挂载了敏感目录：

docker inspect 容器名 | grep -E '"/:/|/var/run/docker.sock|/etc|/root|/home"'

以下挂载尤其危险：

• /var/run/docker.sock
• /
• /etc
• /root
• /home
• /var/lib/docker

如果业务不是强依赖，尽量不要这样挂载。

三、Docker 漏洞修复总体思路

站长修复 Docker 安全问题，不能只做“升级版本”这一件事。更合理的思路是：

1. 升级 Docker Engine、containerd、runc；
2. 关闭不必要的远程 API；
3. 移除特权容器和危险挂载；
4. 更新存在漏洞的镜像；
5. 限制容器权限和资源；
6. 检查防火墙和端口暴露；
7. 建立定期升级和备份机制。

下面逐步讲解。

四、第一步：备份网站和关键数据

在升级 Docker 或重启容器之前，务必先备份。很多站长直接执行升级命令，结果数据库容器重启失败、挂载目录写错、镜像版本不兼容，导致网站长时间无法访问。

建议至少备份以下内容：

• 网站源码目录；
• 数据库数据目录；
• Docker Compose 配置文件；
• Nginx 配置文件；
• SSL 证书；
• .env 环境变量文件；
• 定时任务脚本；
• 上传附件目录。

如果使用 Docker Compose，建议先进入项目目录：

cd /你的/docker-compose/目录

备份配置：

cp docker-compose.yml docker-compose.yml.bak

如果有 .env 文件：

cp .env .env.bak

数据库建议使用逻辑备份。例如 MySQL：

docker exec -i mysql容器名 mysqldump -uroot -p 数据库名 > backup.sql

如果不确定数据位置，可以查看容器挂载：

docker inspect 容器名

找到 Mounts 字段，确认宿主机上的真实数据目录。

五、第二步：升级 Docker Engine

不同系统升级方式略有不同。以下以常见的 Ubuntu / Debian / CentOS 系统为例。

1. Ubuntu / Debian 升级 Docker

先更新软件源：

sudo apt update

查看可升级的软件：

apt list --upgradable | grep docker

执行升级：

sudo apt install --only-upgrade docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

如果系统中没有安装官方 Docker 源，可能需要先添加官方源。对于普通站长来说，建议使用 Docker 官方仓库，而不是长期依赖系统自带的旧版本。

升级完成后查看版本：

docker version

重启 Docker：

sudo systemctl restart docker

查看 Docker 状态：

sudo systemctl status docker

确认容器是否正常恢复：

docker ps

2. CentOS / Rocky Linux / AlmaLinux 升级 Docker

更新缓存：

sudo yum makecache

或：

sudo dnf makecache

升级 Docker：

sudo yum update docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

如果使用 dnf：

sudo dnf update docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

重启服务：

sudo systemctl restart docker

检查版本：

docker version

六、第三步：升级 containerd 和 runc

很多 Docker 漏洞并不只存在于 Docker Engine，也可能出现在底层组件中，例如 containerd 和 runc。因此升级时不要只关注 Docker 主版本。

检查版本：

containerd --version
runc --version

如果通过 Docker 官方源安装，一般执行 Docker 升级时会同步更新相关组件。但如果你曾经手动安装过 containerd 或 runc，需要特别确认版本来源。

升级后重启：

sudo systemctl restart containerd
sudo systemctl restart docker

然后查看容器是否正常：

docker ps

七、第四步：关闭危险的 Docker 远程 API

如果你不需要远程管理 Docker，应确保 Docker 只通过本地 Unix Socket 工作。

检查 Docker 启动参数：

ps aux | grep dockerd

如果看到类似：

-H tcp://0.0.0.0:2375

说明 Docker API 暴露到了公网或内网，应立即处理。

常见配置位置包括：

/etc/docker/daemon.json
/lib/systemd/system/docker.service
/etc/systemd/system/docker.service.d/

查看配置：

cat /etc/docker/daemon.json

安全配置通常不需要添加 tcp://0.0.0.0:2375。如果存在类似内容，应删除或改为仅本地访问。

修改后执行：

sudo systemctl daemon-reload
sudo systemctl restart docker

再次检查：

ss -lntp | grep 2375

如果没有输出，说明端口未监听。

如果业务确实需要远程 API，至少应使用 TLS 认证、防火墙白名单和内网访问，不要裸露到公网。

八、第五步：修复容器高危运行参数

1. 避免使用特权模式

检查 Compose 文件中是否存在：

privileged: true

如果不是必须，应删除。很多网站服务，如 Nginx、MySQL、Redis、WordPress、PHP-FPM、Node.js 应用，通常不需要特权模式。

2. 避免挂载 Docker Socket

高危配置示例：

volumes:
  - /var/run/docker.sock:/var/run/docker.sock

这类配置等同于让容器具备管理宿主机 Docker 的能力。一旦容器内应用被攻击，攻击者可能借助 Docker Socket 创建高权限容器，进一步控制宿主机。

除非你运行的是 Traefik、Portainer、Watchtower 等确实需要管理 Docker 的工具，否则不建议挂载。

3. 避免挂载宿主机根目录

高危配置示例：

volumes:
  - /:/host

这会让容器读取甚至修改宿主机大量文件。普通网站部署不应这样做。

4. 使用只读挂载

如果容器只需要读取配置，可以使用只读模式：

volumes:
  - ./nginx.conf:/etc/nginx/nginx.conf:ro

:ro 表示只读，可以减少配置文件被篡改的风险。

九、第六步：更新存在漏洞的镜像

Docker 本身升级后，镜像也要更新。很多站长的网站漏洞并不是 Docker Engine 导致的，而是镜像中的 OpenSSL、glibc、curl、PHP、Node.js、Nginx、Apache、Java、Python 等组件存在漏洞。

如果使用 Docker Compose，可以在项目目录执行：

docker compose pull
docker compose up -d

旧版命令可能是：

docker-compose pull
docker-compose up -d

更新后清理无用镜像：

docker image prune

注意：不要盲目执行 docker system prune -a，它可能删除未使用镜像、缓存、网络，甚至影响回滚。生产环境建议先确认再清理。

查看镜像：

docker images

建议优先使用官方镜像或可信来源镜像，避免使用来源不明、长期不更新、下载量很低的镜像。

十、第七步：限制容器权限和资源

1. 使用非 root 用户运行容器

如果镜像支持，建议指定非 root 用户：

user: "1000:1000"

并确保挂载目录权限正确。非 root 并不能解决所有问题，但可以显著降低容器内进程被利用后的破坏力。

2. 限制 Linux capabilities

可以在 Compose 中加入：

cap_drop:
  - ALL

如果应用确实需要某些能力，再按需添加：

cap_add:
  - NET_BIND_SERVICE

普通 Web 服务一般不需要大量系统能力。

3. 设置只读根文件系统

部分无状态服务可以使用：

read_only: true

同时为需要写入的目录单独挂载临时目录或数据卷。这可以降低攻击者写入木马的可能性。

4. 限制资源

防止容器异常占满 CPU 或内存：

mem_limit: 512m
cpus: "1.0"

对于小型站点，这类限制很实用。若网站被攻击或程序死循环，资源限制可以避免整台服务器被拖垮。

十一、第八步：检查端口暴露和防火墙

站长常见错误是把数据库、Redis、Elasticsearch、面板服务直接暴露到公网。例如：

ports:
  - "3306:3306"
  - "6379:6379"

如果数据库只给同一台服务器内的应用访问，不应暴露到公网。可以改为仅容器网络内部通信，删除 ports，使用 expose 或直接通过服务名访问。

如果确实需要本机访问，可以绑定到 127.0.0.1：

ports:
  - "127.0.0.1:3306:3306"

检查当前监听端口：

ss -lntp

如果使用 UFW：

sudo ufw status

只开放必要端口，例如：

• 80：HTTP；
• 443：HTTPS；
• 22：SSH，建议改端口或限制 IP；
• 面板端口：建议限制 IP 访问。

不建议公网开放：

• 2375：Docker API；
• 3306：MySQL；
• 5432：PostgreSQL；
• 6379：Redis；
• 9200：Elasticsearch；
• 27017：MongoDB。

十二、第九步：使用工具扫描镜像漏洞

如果你维护多个站点，建议定期扫描镜像。可以使用 Trivy：

trivy image 镜像名:标签

例如：

trivy image nginx:latest

也可以扫描文件系统：

trivy fs .

扫描结果中通常会显示漏洞编号、严重等级、影响版本和修复版本。站长重点关注：

• CRITICAL
• HIGH

对于严重漏洞，应优先升级基础镜像或应用版本。

如果使用 GitHub Actions、GitLab CI 或其他自动部署工具，也可以把镜像扫描加入发布流程，避免带漏洞的镜像进入生产环境。

十三、第十步：检查是否已经被入侵

如果你的 Docker 长期未更新，或者曾经暴露过 Docker API，建议检查是否已经出现异常。

1. 查看异常容器

docker ps -a

重点关注陌生容器、异常镜像、奇怪命令。

2. 查看异常镜像

docker images

如果出现不认识的镜像，尤其是挖矿相关、随机命名镜像，需要进一步排查。

3. 查看容器日志

docker logs 容器名

如果发现大量异常请求、下载脚本、执行命令、连接陌生地址，应提高警惕。

4. 查看系统登录记录

last

查看失败登录：

lastb

部分系统可能需要 root 权限。

5. 查看定时任务

crontab -l
sudo ls -al /etc/cron*

攻击者常通过定时任务保持木马运行。

6. 查看异常进程

ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head

如果发现高 CPU 的陌生进程，尤其是挖矿程序，应立即断网排查。

十四、推荐的安全版 Docker Compose 写法

下面是一个相对安全的 Web 服务示例，适合站长参考：

services:
  web:
    image: nginx:stable-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./site:/usr/share/nginx/html:ro
      - ./certs:/etc/nginx/certs:ro
    read_only: true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges:true

这个示例体现了几个安全原则：

• 配置文件只读挂载；
• 网站静态文件只读挂载；
• 不使用特权模式；
• 禁止额外提权；
• 默认移除不必要能力；
• 只添加必要的网络绑定能力。

实际业务中并非所有容器都能直接使用 read_only: true 或 cap_drop: ALL，但站长可以逐步测试、逐步收紧权限。

十五、修复后的验证清单

完成漏洞修复后，建议按以下清单检查：

• Docker 已升级到较新稳定版本；
• containerd 和 runc 已同步更新；
• 2375 端口未暴露到公网；
• 没有无意义的 privileged: true；
• 没有危险挂载 /var/run/docker.sock；
• 数据库和 Redis 未直接暴露公网；
• 镜像已经更新到安全版本；
• 旧镜像和无用容器已清理；
• 防火墙只开放必要端口；
• 网站、数据库、证书和配置已备份；
• 容器重启后网站访问正常；
• 日志中没有明显异常请求或未知进程。

可以使用以下命令快速复查：

docker version
docker ps
docker images
ss -lntp
sudo ufw status

如果服务器使用云厂商安全组，也要同步检查安全组规则。很多站长只配置了系统防火墙，却忘了云服务器控制台里的安全组仍然开放了高危端口。

十六、站长日常维护建议

Docker 安全不是一次性工作。建议站长建立简单但长期有效的维护习惯。

1. 每月检查一次更新

每月至少执行一次：

docker version
docker compose pull

确认 Docker 和镜像是否需要升级。对于生产站点，建议先在测试环境验证，再更新正式环境。

2. 保留可回滚方案

升级前保留：

• docker-compose.yml；
• .env；
• 数据库备份；
• 镜像版本号；
• 挂载目录备份。

不要在生产环境盲目使用 latest 标签。更推荐使用明确版本，例如：

image: nginx:1.26-alpine

这样出现问题时更容易定位和回滚。

3. 最小化容器权限

能不用特权模式就不用，能只读挂载就只读，能不暴露端口就不暴露。Docker 安全最重要的原则之一就是“最小权限”。

4. 使用可信镜像

优先选择官方镜像、知名项目镜像和持续维护的镜像。不要随意运行网上复制来的不明镜像，尤其是需要挂载宿主机目录或 Docker Socket 的镜像。

5. 关注漏洞公告

建议关注：

• Docker 官方安全公告；
• Linux 发行版安全公告；
• 应用框架官方公告；
• 云厂商安全通知；
• 常用镜像维护者发布记录。

当出现高危漏洞时，应尽快评估是否影响自己的服务器。

十七、总结

对于站长来说，Docker 能显著提升部署效率，但也会带来新的安全边界和维护责任。修复 Docker 最新漏洞时，不能只停留在“升级一下 Docker”这个层面，而应同时关注 Docker Engine、containerd、runc、镜像、容器权限、端口暴露、挂载目录和防火墙策略。

最推荐的修复流程是：先备份，再升级 Docker 及运行时组件，随后关闭危险远程 API，检查并移除特权容器和危险挂载，更新业务镜像，最后通过端口检查、日志检查和漏洞扫描确认服务器状态。

如果你的网站规模不大，也不需要复杂方案。只要坚持几个原则：不暴露 Docker API、不使用不必要的特权模式、不开放数据库到公网、定期更新镜像和 Docker、做好备份，就能大幅降低被攻击的风险。对于大多数个人站长和中小网站而言，这些措施已经能够覆盖绝大部分常见 Docker 安全问题。