【实战案例】从“未上锁的门“到服务器沦陷：Docker Remote API未授权访问漏洞深度解析

一、引子：一场始于"开放接口"的安全警示

在我参与的一个Web项目安全测试中，发现某域名存在安全隐患。排查后确认，该域名对应的服务器通过特定端口对外开放了Docker Remote API，且未设置访问控制机制。这一配置意味着，知晓该端口的人员可远程操作服务器上的Docker容器，存在一定的安全风险。

这类配置疏漏可能带来不良影响，如未经授权的访问、数据安全受到威胁等。好在相关团队及时采取了关闭危险端口、优化安全配置等措施，避免了潜在损失。

现实中，类似的配置问题并不少见。据行业观察，部分Docker服务器存在不同程度的Remote API配置问题，其中一些甚至处于完全开放状态。对于安全初学者而言，理解这些技术细节背后的风险或许有难度，但将其类比为生活场景就会发现：很多安全隐患的本质，其实和"没锁门"的道理相似。

二、案例分析

某公网域名对应的服务器开放了特定端口，存在Docker Remote API未授权访问的安全问题，可能导致容器被远程操作及服务器权限面临风险。

通过相关工具可实现对容器的远程控制：

之后可通过特定命令进入容器（命令示例：docker -H tcp://目标IP:端口 exec -it {容器ID或名称} /bin/bash）。

若攻击者控制容器后向宿主机敏感目录写入相关密钥文件，可能进一步获取服务器权限：

三、漏洞原理：为何"开放的API"会成为安全隐患？

Docker Remote API未授权访问问题的本质，是管理员在配置Docker时，未启用认证机制且将API端口暴露在公网。这就如同给服务器留了一个"未上锁的通道"，知晓端口的人员可能借此进行非授权操作。

1. 隐患形成的三个关键条件

若将服务器比作一栋建筑，可这样理解隐患形成的条件：

• Docker Remote API的端口就像建筑的一个侧门
• 认证机制（如密码、密钥）如同门锁
• 公网暴露意味着这扇门面向公共区域，容易被发现

当以下三个条件同时满足时，隐患便可能产生：

1. 未启用认证：侧门没有锁，任何人都能推开
2. 端口公网暴露：侧门面向公共区域，容易被找到
3. API权限过高：这扇门通往建筑的核心区域（容器和宿主机）

2. 非授权操作的一般步骤

在类似场景中，非授权访问者可能通过以下步骤实现对服务器的操作，可拆解为四个环节：

第一步：扫描发现开放端口

非授权访问者可能使用端口扫描工具在网络中寻找开放了Docker Remote API端口（常见如2375、2376等）的服务器。这就像在区域内逐个查看，寻找未锁的门。

当扫描到目标端口时，工具可能返回"端口开放且运行Docker Remote API"的信息，使其意识到存在可利用的漏洞。

第二步：通过API获取容器控制权

找到开放的API后，非授权访问者可能发送简单指令测试访问权限。例如发送GET /containers/json指令，获取服务器上所有Docker容器的列表，包括名称、状态、映射端口等信息，如同通过门缝查看内部布局。

这些信息可能让其了解如何进一步操作容器。

第三步：利用容器挂载获取宿主机权限

Docker容器和宿主机（运行Docker的服务器）之间默认是隔离的，但容器可通过"挂载"功能访问宿主机的文件系统（类似电脑的"共享文件夹"）。非授权访问者可能通过Remote API创建新容器，并将宿主机的敏感目录（如/root/.ssh/）挂载到容器中。

/root/.ssh/目录是Linux系统中存放SSH密钥的地方，若向该目录写入自己的公钥，可能通过SSH免密码登录宿主机，如同复制了大门钥匙。

第四步：对服务器进行非授权控制

一旦通过SSH登录宿主机，非授权访问者可能获得服务器的操作权限，进行删除数据、窃取信息等操作，甚至利用该服务器影响其他设备。此时服务器可能完全处于非安全状态。

3. 该类隐患被定为"高危"的原因

在安全评级中，这类隐患通常被定为"高危"，主要原因有三点：

• 操作成本低：不需要复杂技术，知晓端口即可尝试操作，入门者也能实施
• 影响范围广：不仅能控制容器，还可能突破隔离获取宿主机权限，相当于控制整个服务器
• 持续风险大：只要隐患存在，可能被反复利用，造成持续影响

四、隐患检测：初学者可掌握的自查方法

作为普通用户或企业员工，无需成为安全专家，但可通过简单方法判断负责的服务器是否存在类似风险。以下是适合初学者的自查步骤：

1. 确认服务器是否运行Docker

若不确定服务器是否安装Docker，可通过以下方式检查：

• 登录服务器后，在命令行输入docker --version，若显示版本信息（如Docker version 20.10.12），说明安装了Docker
• 若没有登录权限，可联系运维人员确认：“服务器是否使用了Docker？”

2. 检查Docker Remote API是否暴露在公网

核心是确认Docker的API端口是否能被外部网络访问，简单方法是使用在线端口扫描工具：

1. 打开在线端口扫描网站（如IP138端口扫描）
2. 输入服务器的公网IP
3. 扫描常见的Docker端口：2375（未加密API）、2376（加密API）及其他非标准端口
4. 若扫描结果显示"端口开放"，说明存在暴露风险

3. 测试是否存在未授权访问

若发现端口开放，可进一步测试是否需要认证：

1. 打开浏览器，输入http://服务器IP:端口/version（如http://目标IP:端口/version）
2. 若页面显示类似以下的Docker版本信息，说明无需认证即可访问（存在隐患）：

{
  "Version": "20.10.12",
  "ApiVersion": "1.41",
  "GitCommit": "459d0df",
  "GoVersion": "go1.16.12",
  "Os": "linux",
  "Arch": "amd64"
}

3. 若页面提示"需要登录"或显示空白，则说明启用了认证，暂时没有相关风险

五、隐患修复：四步筑牢Docker安全防线

若检测发现存在未授权访问隐患，需立即采取修复措施。关闭相关远程访问端口、重新生成SSH密钥只是基础操作，完整修复方案应包括以下四步：

第一步：紧急关闭公网暴露的API端口

最直接的方法是立即关闭面向公网的API端口，切断非授权访问路径：

1. 登录服务器，找到Docker的配置文件（通常是/etc/docker/daemon.json或/lib/systemd/system/docker.service）

2. 检查配置中是否有-H 0.0.0.0:端口的内容（这行配置允许所有IP访问该端口），例如：

   ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:端口号
   

3. 删除-H tcp://0.0.0.0:端口号这部分内容，保存配置文件

4. 重启Docker服务：systemctl restart docker

5. 再次用端口扫描工具测试，确认端口已关闭

第二步：清除可能的恶意文件（如SSH密钥）

若怀疑已被非授权访问（如案例中提到的"写入私钥"），需彻底清理可能的安全后门：

1. 检查/root/.ssh/authorized_keys文件（SSH免密登录的关键文件），删除陌生的公钥内容

2. 重新生成SSH密钥：

   # 删除旧密钥
   rm -f /root/.ssh/id_rsa /root/.ssh/id_rsa.pub
   # 生成新密钥（按提示操作，建议设置密钥密码）
   ssh-keygen -t rsa -b 4096
   

3. 检查服务器上是否有新增的陌生用户、进程或文件，及时删除可疑内容

第三步：正确配置Docker Remote API的访问控制

若业务确实需要远程管理Docker（必须开启API），需通过以下方式加固：

1. 启用TLS认证：给Docker API添加认证机制，只有持有合法证书的设备才能访问

   • 生成TLS证书（可参考Docker官方文档）

   • 修改Docker配置，启用加密访问：

     {
       "tlsverify": true,
       "tlscacert": "/etc/docker/ca.pem",
       "tlscert": "/etc/docker/server.pem",
       "tlskey": "/etc/docker/server-key.pem",
       "hosts": ["tcp://0.0.0.0:2376", "unix:///var/run/docker.sock"]
     }
     

2. 限制访问来源：通过防火墙（如iptables）只允许指定IP（如公司内网IP）访问API端口，拒绝公网直接访问

   # 只允许指定网段访问目标端口
   iptables -A INPUT -p tcp --dport 端口号 -s 指定网段 -j ACCEPT
   iptables -A INPUT -p tcp --dport 端口号 -j DROP
   

3. 使用非标准端口：将API端口从2375/2376改为不常用端口，降低被扫描到的概率

第四步：建立长期安全监控机制

隐患修复并非一劳永逸，需建立持续监控机制：

1. 定期漏洞扫描：每周用工具扫描服务器端口，确认API端口未暴露
2. 日志审计：开启Docker的操作日志，定期检查是否有陌生IP的访问记录
3. 版本更新：及时更新Docker到最新版本，修复官方已知的安全漏洞
4. 权限最小化：运行Docker容器时避免使用root权限，即使容器被非授权访问，也难以获取宿主机高权限

六、扩展学习：容器安全的三大核心原则

Docker Remote API未授权访问隐患只是容器安全问题的一个方面。对于初学者，掌握容器安全的三大原则，能从根本上降低类似风险：

1. 最小权限原则：给容器"够用就好"的权限

如同给员工分配工作时，只授予完成任务必需的权限（普通员工不需要管理员权限），Docker容器也应遵循"最小权限"：

• 运行容器时使用--user参数指定普通用户，而非默认的root用户
• 避免使用--privileged参数（该参数会给容器几乎所有宿主机权限）
• 挂载宿主机目录时，只挂载必需的目录，禁止挂载/root/、/etc/等敏感目录

2. 隔离原则：让容器与外界"适度隔离"

容器的核心价值是隔离，但隔离不是绝对的。要通过配置强化隔离效果：

• 禁止容器间的网络直接通信（使用Docker网络策略限制）
• 关闭容器的"特权模式"，防止容器突破隔离访问宿主机
• 定期检查容器与宿主机的文件共享情况，确保没有不必要的挂载

3. 生命周期管理：给容器"定期体检"

容器并非"启动后就无需管理"，需要像管理实体服务器一样进行全生命周期管理：

• 及时删除不再使用的容器和镜像，减少安全风险点
• 定期更新容器内的应用程序和依赖，修复已知漏洞
• 对运行中的容器进行安全扫描（如使用ClamAV等工具检测恶意文件）

七、总结：安全的本质是"细节+习惯"

回顾Docker Remote API未授权访问隐患的案例，会发现：多数高危隐患都源于基础配置错误。就像案例中，可能只是管理员配置Docker时多写了一行允许所有IP访问的代码，却给非授权访问者打开了方便之门。

对于安全初学者，无需一开始就掌握复杂技术，而是要养成"安全配置"的习惯：安装软件后检查默认密码是否修改、开放端口是否必要、权限设置是否合理。这些看似微小的操作，恰恰是抵御多数安全风险的第一道防线。

最后记住：网络安全没有"绝对安全"，但永远有"更安全"的选择。从现在开始，检查负责的服务器——那些可能被忽略的"未上锁的门"，或许就在某个角落。

本文是「漏洞案例」系列内容，点击专栏导航查看全部系列内容。