为什么这个端口等同于 root
Docker 守护进程的管理接口是「用 API 执行任意容器操作」的能力：能起容器，就能启动一个挂载宿主机根目录的特权容器，随后读写宿主机的任意文件。这个接口早期默认走未加密的 TCP，也没有认证。所以 2375 出现在公网上不是一次普通暴露，而是把整台主机的控制权交出去；2376 只是换了加密通道，同样需要客户端证书保护。
基本信息
| 加固项 | 容器运行时管理接口 |
|---|---|
| 适用平台 | Linux（Docker Engine） |
| 风险等级 | 高 |
| 基线 | 不对外暴露 TCP 管理接口，本机访问走 unix socket |
| 默认套接字 | /var/run/docker.sock（本机，权限受控） |
典型使用场景
- 暴露面核查：确认主机上没有监听在 TCP 上的容器管理接口
- 事件响应：发现暴露立即按疑似已被利用的机器排查
- CI/CD 评估：需要远程构建时改用更安全的接入方式
- 变更复核：修改守护进程启动参数后确认端口真的消失
- 合规整改：容器运行时属于主机资产的一部分，同样纳入暴露面清单
核查与整改
核查与整改
ss -tlnp | grep -E ':2375|:2376 '
ps -ef | grep -E 'dockerd.*(-H|tcp://)' | grep -v grep
grep -E 'ExecStart' /usr/lib/systemd/system/docker.service | head -3
systemctl show docker.service -p ExecStart | head -3 # 现代系统查看实际启动参数暴露形态对照
| 形态 | 识别方式 | 风险说明 |
|---|---|---|
| 明文 TCP 2375 | ss 显示监听 2375 | 无加密无认证，直接可用 API 操作宿主机 |
| TLS TCP 2376 | ss 显示监听 2376 | 有加密但仍需双向证书，配置不当同样可被调用 |
| unix 套接字 | 以文件形式存在于本机 | 默认形态，权限控制后可接受，注意属组权限 |
| 启动参数中的远程监听 | 查看服务启动参数 | 参数一旦写入就长期存在，需从配置层面移除 |
已经暴露过的机器要按疑似被入侵来排查：检查是否存在异常的特权容器、来源不明的镜像、新增的挂载点与计划任务。这类接口被调用时通常不会留下显眼告警，靠事后翻查痕迹，所以发现暴露与实际是否被利用无关，排查动作必须跟上。
改完启动参数要重载服务单元并重启守护进程，只删参数不重启，旧进程仍在监听；如果是套接字激活的方式，还要确认套接字单元没有把监听重新拉起。整改后必须用一条新命令确认端口确实消失，而不是凭改动动作判断。
需要远程管理时怎么做
确需远程管理的场景，正确顺序是：启用双向 TLS 并严格校验客户端证书、只在内网或管理网段监听、把访问权限收敛到少数构建节点，并考虑用受限代理代替直接暴露守护进程接口。无论采用哪种方式，都不要把管理接口放在能路由到公网的地址上，这一条比任何认证配置都更关键。