挖矿木马入侵自救：从Docker API暴露到Rootless加固实战

如果让我给那次事故总结一个关键词，不会是“挖矿木马”，也不会是“Rootless”，而是“轻敌”。我始终以为自己跑了三年 Docker，隔离做得足够好，服务器安全最多就是改改 SSH 端口的事。直到一个周三下午，CPU 告警把我打醒：top 里一个叫 kdevtmpfsi 的进程占满了所有核心，Docker 容器列表里多出了几个“自己从未创建过”的容器，其中一个还挂载了宿主的整个根目录。那一刻我才明白，这台机器早就不属于我一个人了。

这篇复盘会完整还原从挖矿木马入侵、排查清理，到最终迁移到 Docker Rootless 加固的整个过程。我会重点讲清楚攻击者是怎么借 Docker 管理口打进宿主的、为什么普通清理只是“治标不治本”，以及 Rootless 模式从原理到落地时踩过哪些坑。如果你也用 Docker 跑过线上服务，尤其是曾把 Docker API 暴露到公网，那这篇内容应该能帮你省掉一次和我一样的血泪教训。

1. 事发当天：从一条 CPU 告警开始的安全复盘

1.1 我看到的第一个异常进程

那天下午的监控告警其实很普通：服务器 CPU 使用率持续 98% 以上。我登录服务器后第一件事就是跑 top -c，结果看到一串 kdevtmpfsi 进程，每个进程都占了接近 100% 的 CPU，加起来把整台机器的核全吃满了。说实话，我当时没立刻意识到那是挖矿木马，还以为是某个 Java 应用出了死循环。

顺着进程 PID 查 /proc 下的可执行文件路径，发现进程启动目录都在 /tmp 和 /var/tmp 下面，这才觉得不对劲。正常的业务进程不会从 /tmp 启动，更不会起十几份互相“看着像兄弟”的进程。再配合系统的 load average，我可以确认这绝不是普通的性能问题，而是有人往机器上种了挖矿木马。

随后我检查了 crontab -l，里面出现了一条“从远程地址下载 shell 脚本并执行”的定时任务，大概每小时执行一次。这就解释了为什么木马进程被手动 kill 之后，过一段时间又会重新出现——它不是靠自己复活，而是靠定时任务拉起来，而且我怀疑不止一个定时任务入口。

1.2 Docker 容器列表里的“不速之客”

因为这台服务器主要跑 Docker，我的下一个动作是 docker ps -a。不看不要紧，一看冷汗就下来了：列表里有几个名字完全是随机字符串的容器，创建时间恰好是 CPU 告警之前一两个小时。更刺眼的是，我用 docker inspect 查看其中一个容器的挂载信息时，看到了这样的输出：

code复制docker inspect -f '{{.Name}} | {{.Mounts}}' <异常容器ID>
/evil_container | [{ / /host rw }]

简单说，这个容器把宿主的根目录 / 挂载到了容器内部的 /host，并且是可读写权限。容器里的命令行是运行一段 shell 脚本，脚本内容大致是往宿主机 /etc/cron.d/ 下写入定时任务、往 /root/.ssh/authorized_keys 里追加公钥，再下载挖矿程序。

那一刻我的第一反应是“容器逃逸了”。但静下来细看，并不是传统意义的逃逸，而是有人通过 Docker API 直接控制 daemon，发起了正常但恶意的容器创建指令。攻击者根本不需要逃逸，因为 Docker daemon 本身就以 root 身份运行，谁能控制 Docker API，谁就等价于拿到了宿主机的 root shell。

1.3 第一次排查时我犯了哪些错

事情发生时我的处置顺序并不理想。我先做的是直接 docker rm -f 删掉异常容器，然后 kill 掉 kdevtmpfsi 进程。结果大约 5 分钟后，监控又出现 CPU 飙升。原因很简单：我只处理了“前台”的恶意容器，却漏掉了攻击者已经写入宿主机的 cron 任务和 SSH 公钥。定时任务每几分钟就会重新拉一个新容器，或者直接下载新的木马二进制到 /tmp 执行。

第二次我决定不急着杀进程，先做证据留存。把 docker ps -a 的输出、进程列表、crontab 内容、可疑文件哈希统统保存下来。因为挖矿木马圈子经常互相“踢馆”，攻击者之间会互相删对方的文件、占资源，这种混乱现场如果不先留存，事后很难回溯完整攻击路径。

这轮排查给我最深刻的教训是：面对安全事件，动作要快，但顺序不能乱。先隔离入口、再清理持久化项、最后杀进程，顺序反了就会掉进“杀完又复活”的循环。

2. 攻击路径拆解：挖矿木马是怎么进来的

2.1 暴露在公网的 Docker API 是罪魁祸首

清理完木马后，我翻开 Docker daemon 的配置，找到了真正的根因。早前为了图方便，我在 /etc/docker/daemon.json 里加了一行配置：

code复制{
  "hosts": ["tcp://0.0.0.0:2375", "unix:///var/run/docker.sock"]
}

这行配置的本意是让我可以从办公网络远程调用 Docker 接口，方便部署容器。但我犯了一个致命错误：2375 端口是 Docker 的明文 API 端口，默认没有任何认证。也就是说，只要这台服务器有公网 IP，并且防火墙没挡住 2375，全世界任何人都可以直接向这个端口发送 Docker 操作指令。

攻击者不需要密码，不需要公私钥，只需要一条 HTTP 请求就能创建容器。扫描器在公网上会持续扫描这类未授权的 Docker API，发现后基本是秒级响应，会用自动化脚本立刻部署挖矿容器。从我的服务器日志看，扫描器发现端口到恶意容器启动，间隔可能不到一分钟。

2.2 攻击者的标准化攻击“剧本”

这类挖矿木马攻击已经非常工业化，攻击路径也几乎千篇一律，大致可以分为四步。

第一步是端口扫描。攻击者会扫描全网段的 2375、2376 等 Docker 相关端口，找到所有未加密、无鉴权的 daemon。第二步是创建恶意容器。攻击者会调用 Docker API 创建容器，通常选择基础镜像如 alpine、python，然后在创建参数中加入 -v /:/host，把宿主机整个根目录挂到容器内，再以 --privileged 方式启动。这样一来，容器里的操作就直接作用于宿主机文件系统。

第三步是写入持久化任务。恶意容器启动后，执行一段脚本完成“投毒”：往宿主机 /etc/cron.d/ 或 /var/spool/cron/ 写入定时任务，把下载挖矿木马的命令固化下来；还会修改 /root/.ssh/authorized_keys，悄悄留下后门公钥，方便之后随时登录。第四步是运行挖矿进程。木马会下载 xmrig 等挖矿程序到 /tmp，将 CPU 资源全部用于挖矿。有的木马还会先清理掉其他竞争者的进程和文件，确保自己独占服务器资源。

2.3 为什么默认 Docker 架构放大了这次风险

很多人以为 Docker 容器天然安全，因为容器提供了隔离。但实际上，Docker daemon 才是所有权限的枢纽。以默认的 rootful 模式运行 Docker 时，dockerd 进程本身就拥有宿主机 root 权限，只是 Unix socket 通常只允许 root 或 docker 组的用户访问，所以才没有出大乱子。

问题的关键在两点。第一，一旦 daemon 监听端口暴露到网络上，等于把 root 能力做成了公网 API，而且这个 API 还没有认证。第二，docker CLI 和 API 能做的事情远比我们平时用到的 docker run 多得多。创建容器时随便挂载一个宿主机目录，就能读取或篡改宿主机上的任何文件。所谓容器隔离，在这种场景下形同虚设。

所以那次攻击其实不涉及高深的容器逃逸 CVE，也不是什么 0day，而是服务器安全配置层面的基础失误。攻击者合法地通过 Docker API 创建了一个“可以操纵宿主机的容器”，仅此而已。理解了这一点，才能真正明白为什么后来我选择放弃 rootful Docker，改用 Rootless 模式。

3. 应急清理：挖矿木马清除不是“杀进程”这么简单

3.1 正确的应急响应顺序

清理挖矿木马最忌讳的就是上来就 kill。攻击者通常会在宿主机上设置多道持久化机制，比如 cron、systemd service、SSH 公钥、多份木马副本互相守护。如果你只杀了一个进程，另一个后台守护进程几分钟内就会把它重新拉起来。我的建议是严格按“封堵入口、清理持久化、删除文件、杀进程”的顺序执行。

第一步先封堵入口。因为我确认了根因是 Docker API 暴露在 2375，所以第一时间用防火墙规则阻断该端口的外部访问。如果你的场景里是 SSH 被暴力破解，那就要先改 SSH 端口并限制来源 IP，不给攻击者继续写入的通道。

第二步备份现场。把容器列表、进程列表、网络连接、crontab、authorized_keys 等关键信息保存下来。这些既能帮助分析攻击时间线，也能作为后续取证依据。我在清理时就把异常容器和木马二进制文件做了 tar 备份，没有直接删除。

第三步清理持久化。检查所有可能出现定时任务的位置，包括当前用户的 crontab、/etc/crontab、/etc/cron.d/、/etc/cron.hourly/ 等。同时检查 /root/.ssh/authorized_keys 里是否多出了不认识的公钥，如果有，先备份再删除。

第四步才是删除木马文件并结束进程。把 /tmp、/var/tmp、/usr/local/bin 等目录下新增的异常二进制文件找出来删掉，然后用 kill -9 结束残留进程。删文件要早于杀进程，避免进程在结束时重新释放文件。

3.2 挖矿木马常见的驻留位置速查表

下面是我在处理过程中反复检查的位置，整理成了一张速查表，遇到类似情况可以直接照着查。

3.3 “定时任务复活”机制的破解经验

第一次清理失败后，我专门花了几个小时研究这个木马的复活机制。常见的挖矿木马会同时采用至少两条持久化通道，比如一个 cron 任务负责下载主程序，一个 systemd service 负责守护运行，还有一个 SSH 公钥供攻击者随时回来手动操作。你只清掉 cron，守护服务还会拉起进程；只删 systemd service，cron 又会重新把文件写回去。

我当时的处理技巧是：先把所有可疑定时任务条目临时改成 # 注释掉，而不是立刻删除所有行。注释掉之后，木马进程如果尝试检查任务内容，会发现自己依赖的任务还在，不会立刻触发备用机制。接着等几分钟观察是否还有新进程出现，确认没有新进程了，再彻底删除定时任务和文件。这种方法不能保证对所有变种有效，但至少能避免“删了一条任务，立刻触发另一条任务重新写入”的尴尬。

另外，清完木马后一定要做一次系统账号和文件权限复查。我检查了 /etc/passwd 中 UID 为 0 的账号，发现没有新增后门账号，但还是建议你把 SSH 登录方式改成密钥-only，并禁用 root 密码登录。毕竟攻击者已经把公钥写入过 authorized_keys，凡是写入过公钥的密钥对都应该视为已泄露，绝不能继续使用。

4. 彻底加固：从 rootful Docker 迁移到 Rootless 模式

4.1 Rootless 模式的核心原理：给 Docker 降权

所谓 Docker Rootless，就是把原本以 root 身份运行的 dockerd 和容器，全部运行在某个普通用户的空间里。这个模式下，即使攻击者再次控制了 Docker API，他能拿到的也只是这个普通用户的权限，而不是宿主机 root 权限。

它的实现基础是 Linux 用户命名空间。简单说，普通用户 deploy（假设 UID 是 1000）启动了一个独立的用户命名空间，容器里的 root（UID 0）在这个命名空间内看起来是 root，但映射到宿主机上只是 UID 1000 的普通用户。因此容器内进程想写宿主机的 /root/.ssh、/etc/crontab 这类 root 专属目录，会直接因权限不足而失败。同时 Rootless 模式通过 RootlessKit 和 slirp4netns 解决了普通用户无法操作网络命名空间、无法挂载 overlay 文件系统等问题，让 Docker 的大部分功能在非 root 环境下照样可用。

这个方案的价值正好切中我这次的教训：之前 Docker API 之所以变成“root 入口”，是因为 rootful dockerd 的权限太大。Rootless 模式下，就算 daemon 被控制，攻击者也只是拿到一个受限账户，破坏力会被限制在用户命名空间内部。

4.2 迁移前先确认服务器到底支不支持

不是所有 Linux 服务器都能直接跑 Rootless 模式，迁移前最好先做几项检查。

第一，确认内核支持用户命名空间。可以执行 unshare -U 来测试，如果命令回显 OK 且没有报错，说明当前用户能创建用户命名空间。第二，安装依赖软件。Debian/Ubuntu 系需要安装 uidmap、dbus-user-session、slirp4netns、fuse-overlayfs。CentOS/RHEL 系则要确认内核版本和相应软件包。第三，确认系统不会禁用用户命名空间。有些最小化安装的云主机镜像可能在 /etc/sysctl.conf 或 /proc/sys/kernel/unprivileged_userns_clone 里把它设成 0，如果是这样，需要先调整内核参数。

我自己是在 Ubuntu 22.04 上操作的，用 root 身份先执行了依赖安装：

code复制apt update
apt install -y uidmap slirp4netns fuse-overlayfs dbus-user-session

然后新建一个专门运行 Docker Rootless 的普通用户。这里有一个安全上的细节：不要把这个用户加入 docker 组，也不要把这个用户加入 sudo 组。因为 Rootless 模式下用户拥有对自己命名空间的管理权，如果再给它宿主机的高权限，就等于白做降级了。

code复制useradd -m -s /bin/bash deploy
passwd deploy

4.3 Rootless Docker 的详细安装步骤

我采用的是 Docker 官方提供的 Rootless 安装脚本。整个过程都必须以普通用户身份执行，不能继续用 root 登录操作，否则脚本会拒绝运行或者创建出来的环境还是带 root 权限的。

先切换到新用户：

code复制su - deploy

然后执行官方安装脚本。这个脚本会把 Rootless 模式的 Docker 客户端和 daemon 相关文件安装到当前用户主目录的 bin 目录下：

code复制curl -fsSL https://get.docker.com/rootless | sh

安装完成后，脚本会给出下一步需要的环境变量提示。为了以后每次登录都能直接使用，我把这些变量写入了 deploy 用户的 ~/.bashrc：

code复制export PATH=/home/deploy/bin:$PATH
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock
export XDG_RUNTIME_DIR=/run/user/$(id -u)

然后重新加载配置文件，再执行 docker version 验证客户端和 daemon 是否都已就绪：

code复制source ~/.bashrc
docker version

如果能看到 Server 部分的信息，说明 daemon 已经启动并响应了。没看到也没关系，可以先手动启动 daemon，再重新验证。daemon 在 Rootless 模式下也是用户级 systemd 服务来管理的，所以可以这样启动：

code复制systemctl --user start docker
systemctl --user status docker

关键一步是让用户级服务能够开机自启。如果只执行 systemctl --user enable docker，在用户还没登录的情况下服务不会启动。需要回到 root 身份执行 loginctl 命令，让这个用户即使不登录也能维持用户会话：

code复制loginctl enable-linger deploy

4.4 旧容器数据迁移和端口映射调整

解决了 daemon 启动问题后，下一个现实问题是如何把原本 rootful Docker 里的容器和镜像迁过来。如果服务器上还有旧的 root Docker 在运行，可以先用旧环境把镜像导出，再用新环境导入：

code复制# rootful Docker 环境
sudo docker save myapp:latest -o /tmp/myapp.tar

# 切到 deploy 用户，rootless 环境
su - deploy
docker load -i /tmp/myapp.tar

容器数据卷的迁移要特别注意文件权限。rootless 容器本质上是以 deploy 用户的身份读写宿主目录，所以原本归属 root 的数据目录需要调整属主或权限。我在迁移时把业务数据目录做了一次 chown，确保 deploy 用户可以访问：

code复制sudo chown -R deploy:deploy /data/app

端口映射方面，Rootless 模式默认只允许绑定 1024 以上的端口，这是因为它本身是普通用户，没有绑定低端口的权限。如果你有服务必须监听 80 或 443，最简单的办法是让 rootless 容器映射到高位端口，比如 8080，然后由系统里另一个轻量转发进程监听 80，把流量转发到 8080。我没有给服务器开放低端口绑定，而是直接用了高位端口加外部负载均衡转发的方式，既简单又少一个权限点。

4.5 Rootless 安装中的常见坑

第一次安装 Rootless，我遇到过几个记忆深刻的报错，这里按排查频率排个序。

最常见的是“Cannot connect to the Docker daemon at unix:///var/run/docker.sock”。这个一看就知道是环境变量没生效。Rootless 模式下 DOCKER_HOST 必须指向用户自己的 socket，而不是默认的 /var/run/docker.sock。如果你之前用过 rootful Docker，docker context 可能还停在旧 context 上，可以先执行 docker context ls 看看当前 context，再切换到 rootless 环境。

第二个常见坑是安装脚本提示 slirp4netns 不存在，但明明已经装了。这多半是 PATH 里找不到可执行文件。检查一下 slirp4netns 是否装在 /usr/bin 下，或者直接重新安装对应软件包。第三个坑是 overlay 存储驱动报权限错误，这是因为普通用户无法直接挂载 overlay2，需要在系统里安装 fuse-overlayfs 并让 rootless 使用 fuse-overlayfs 作为存储驱动。我的经验是安装完 fuse-overlayfs 后重新执行一次安装脚本，让环境重新检测，通常就能解决。

第四个坑和 systemd 有关。如果你用 systemctl --user start docker 时提示 Failed to connect to bus，说明当前会话没有设置 XDG_RUNTIME_DIR，或者用户服务会话没起来。重新登录用户、确保 XDG_RUNTIME_DIR=/run/user/$(id -u)，再试一次基本都能好。还有一个容易被忽略的是，rootless 服务和旧的 rootful Docker 不能监听同一个宿主机端口。我迁移时先把旧的 rootful 容器全部停掉，才避免端口冲突。

5. 只改 Rootless 远远不够：配套加固手段同样重要

5.1 网络层收敛：别再犯裸奔 Docker API 的低级错误

Rootless 模式解决了 daemon 权限过大的结构性问题，但网络侧的管理依旧不能放松。Docker 服务本身不该绑定到公网端口，更不能启用未加密的 2375。如果你真的需要远程调用 Docker API，应该通过 SSH 隧道访问 Unix socket，或者为 TCP 端口启用 TLS。无论如何，把 ssh 到服务器的入口收得越紧越好。

除了 Docker API，容器发布端口也需要统一收敛。默认情况下，docker run -p 8080:80 会把容器端口直接暴露到宿主机所有网卡上。这意味着即使你的云安全组没放行该端口，Docker 可能通过 iptables 规则绕过一部分防火墙限制。更稳妥的做法是绑定到 127.0.0.1 或内网地址，只让反向代理能访问容器端口：

code复制docker run -d --name app -p 127.0.0.1:18080:8080 myapp:latest

这样公网流量只能先经过 Nginx/Caddy 等反向代理，再由代理转发到容器内部，攻击面大幅减小。

5.2 容器运行参数上的安全基线

我在 Rootless 模式下部署业务容器时，不再像以前一样简单 docker run 一下就跑，而是严格执行一组安全参数。下面是典型的生产容器创建命令：

code复制docker run -d \
  --name demo-app \
  --restart unless-stopped \
  --read-only \
  --user 10001:10001 \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 512 \
  -p 127.0.0.1:18080:8080 \
  myapp:latest

这些参数里，--read-only 会让容器根文件系统变成只读，即使攻击者在容器内写入文件，也无法真正持久化。--user 10001:10001 让容器内进程以普通用户身份运行，不再默认使用容器内 root。--cap-drop ALL 会删除进程所有 Linux capabilities，减少内核提权路径。--pids-limit 512 限制容器内进程数量，可以防止 fork bomb 式资源耗尽。还有 --security-opt no-new-privileges，用于阻止进程通过 setuid 等方式获得更高权限。

这些参数配合 Rootless 模式是双保险：即使单层防护被绕过，下一层还能拦截一部分危险操作。我把它们写进 docker-compose.yml 里统一管理，避免每次部署时漏掉某个参数。

5.3 日常监控与自动化巡检

安全加固不是一次性的，需要靠监控和巡检维持状态。我处理完这次事件后，给自己加了几条自动化巡检规则。

第一，cron 定时任务基线校验。写一个简单的 shell 脚本，定时计算系统所有 cron 文件的哈希值，如果发现和基线不一致，立刻告警。第二，SSH 公钥变化监控。对 /root/.ssh/authorized_keys 做文件属性监控，一旦文件被修改就通知自己。第三，Docker 异常事件监控。通过 docker events 监听容器创建、启动、exec 等高风险操作，并接入日志分析。

例如，可以用 auditd 监控几个关键敏感路径：

code复制auditctl -w /etc/crontab -p wa -k cron-change
auditctl -w /root/.ssh/authorized_keys -p wa -k ssh-key-change
auditctl -w /etc/docker -p wa -k docker-config-change

这些规则虽然简单，但能帮你第一时间发现“文件被改了”。不是所有攻击都像挖矿木马一样会把 CPU 打满，很多入侵是安静地留后门，不建立监控基线，你根本察觉不到。

6. 验证加固效果：用“攻击者思维”做一次模拟测试

6.1 在 Rootless 环境里模拟恶意行为

完成 Rootless 迁移后，我做的第一件事不是立刻把业务全部切回来，而是先用几个攻击性命令验证加固是否真的有效。我模拟了之前攻击者最典型的操作：创建一个特权容器，并把宿主机的根目录挂载进去。

code复制su - deploy
docker run --rm --privileged -v /:/host debian:bookworm-slim \
  sh -c 'id && echo try_write > /host/root/pwned && echo success || echo denied'

这段命令里，--privileged 模拟攻击者试图绕过权限限制，-v /:/host 模拟挂载宿主机根目录。执行结果很直观：容器内的 id 显示 uid=0(root)，说明在容器视角它确实是 root；但写入 /host/root/pwned 时返回了 Permission denied。因为在宿主机视角，这个“容器 root”只是普通用户 deploy，它没有权限改写 root 的 home 目录。

我还进一步测试了修改宿主机 cron 文件的情况。把 /etc 目录挂进容器尝试追加定时任务，同样会因权限不足失败。这个结果证实了 Rootless 模式的核心效果：攻击者即便控制了容器，也无法直接篡改宿主机的系统文件。

6.2 用几个命令确认当前 Docker 是 rootless 模式

为了防止以后误把 rootful Docker 当成 rootless 使用，我在运维笔记里记录了几个简单验证命令。

第一个是通过 docker context 查看当前连接环境。如果 DOCKER_HOST 指向用户级 socket，context 名称通常能看出来。更直接的办法是查看 daemon 信息中是否包含 rootless 标识：

code复制docker info 2>&1 | grep -i rootless
docker context ls

正常输出会包含类似 Rootless: true 的内容，或者 context 的 docker 主机地址是 unix:///run/user/UID/d