Docker 2375 端口为什么不能对公网开放

为了让本地电脑或流水线连上服务器上的容器，不少人把 Docker 管理端口直接开到公网。这个端口没有认证，扫到就等于拿到 root。本文讲清风险、自查方法和三步加固。

部署容器时，很多人会顺手把 Docker 管理端口对外开放。本地电脑能直接连上去敲命令，流水线也能远程构建镜像，省掉每次登录的麻烦。但代价是把整台机器的控制权交给了公网。 Docker 默认的 2375 端口走明文 HTTP，不带任何身份认证。谁能连上，谁就能创建容器、把宿主机根目录挂进容器、读取任意文件，甚至直接拿到 root 权限。暴露 2375 不是开放了一个服务，而是发布了一把不需要密码的钥匙。 近期安全研究披露的细节值得警惕：有僵尸网络专门以 2375 为入口在云环境里横向传播。做法并不复杂，每隔几分钟扫描本子网和相邻网段，寻找可连通的 Docker 守护进程，命中后投放恶意容器。容器被命名为 systemd-resolved 伪装成系统服务，进程名改成 [kworker/u2:0] 混在后台，文件还用 chattr 加上不可修改属性，删完重启照样回来。 自查三条命令就够。在服务器上执行 ss -lntp | grep 2375，看是否有进程监听在 0.0.0.0；换一台机器执行 docker -H tcp://目标IP:2375 version，能返回版本信息说明无认证可直连；再到云控制台看安全组，是否有来源为 0.0.0.0/0 的 2375 规则。命中任意一条，都建议当天处理。 加固按优先级排三步。第一，远程访问改成 SSH 隧道，宿主机只监听 127.0.0.1，本地用 ssh -L 2375:127.0.0.1:2375 转发，功能不受影响。第二，确实需要远程直连的，给守护进程开启 TLS 双向认证，配置 ca.pem、server-cert.pem、server-key.pem 并要求客户端出示证书，启动参数加 --tlsverify，同时禁用裸 HTTP。第三，安全组只放行固定出口 IP，清掉 0.0.0.0/0 规则，并且不要把 docker.sock 挂进业务容器，那等于在容器里开了直达宿主机的后门。 容器本身不是安全边界。真正的边界是端口暴露面、认证方式和访问控制，这三件事管住，容器才谈得上好用。 加速IDC 的云服务器与物理服务器默认只开放业务必要端口，安全组可按来源 IP 精确收紧，需要应对外部扫描与流量攻击时，也可以叠加高防清洗能力。