内容摘要：Docker的2375端口暴露在公网上，比你想的还要危险。这不是危言耸听——我见过不止一个团队，因为图省事直接`docker -H tcp://0.0.0.0:2375` 启动守护进程，结果整个宿主机

Docker的授权2375端口暴露在公网上，比你想的访问还要危险。这不是漏洞危言耸听——我见过不止一个团队，因为图省事直接`docker -H tcp://0.0.0.0:2375` 启动守护进程，修复结果整个宿主机被攻击者当成了免费云主机。授权

攻击者拿到这个端口，访问意味着什么？漏洞他可以直接`docker ps` 看你的容器列表，`docker exec -it 容器id /bin/bash` 进到容器内部。修复更狠的授权是，他拉一个`ubuntu`镜像，访问挂载宿主机的漏洞根目录到容器里，然后`chroot` 进去，修复你的授权服务器密码、密钥、访问数据库文件，漏洞全都成了他的囊中之物。这比SSH被爆破还可怕，因为Docker API默认没有认证机制，连密码都不用猜。

修复的第一件事，别让2375裸奔。最直接的办法是改`/etc/docker/daemon.json`，把`hosts` 从`tcp://0.0.0.0:2375` 改成只监听本地socket：

{  "hosts": ["unix:///var/run/docker.sock"] } 

改完重启docker服务，公网上的2375端口就彻底关掉了。但如果你确实需要远程管理，比如用Portainer或者CI/CD工具连Docker，那得走TLS加密通道。生成CA证书、服务端证书、客户端证书，配置好`tlsverify`、`tlscacert`、`tlscert`、`tlskey` 这四个参数。具体命令Docker官方文档写得很清楚，照着做就行。配完之后，客户端连接得带上证书，像这样：

docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=tcp://你的服务器IP:2376 version 

这里有个细节很多人忽略——2376是TLS端口，别再用2375了。如果你在云服务商的安全组里还开着2375，赶紧关掉。我有次排查客户的问题，发现他们安全组规则里2375和2376都放行了，结果TLS配置好了，但攻击者照样能从2375进来，因为那个端口还在监听。检查一下`netstat -tlnp | grep docker`，确保只有你想要的端口在监听。

还有个更隐蔽的坑——Docker API不止监听TCP端口，还可能通过`iptables` 规则被转发。有些人在宿主机上用`firewalld` 或者`ufw`，但Docker会自己往`iptables` 里插规则，绕过防火墙。所以光改`daemon.json` 不够，得确认`iptables -L -n` 里没有奇怪的ACCEPT规则放行外部IP访问2375。更稳妥的办法是，在`daemon.json` 里加上`"iptables": false`，让Docker不要乱动防火墙规则，然后你自己用`iptables` 或`firewalld` 精确控制端口访问。

修复完记得验证，别以为改完配置就万事大吉。用`curl -k https://你的IP:2376/version` 测试TLS连接是否正常，再试试不带证书访问，应该返回`client sent an HTTP request to an HTTPS server` 之类的错误。如果返回的是正常的JSON数据，那说明TLS没生效，回去检查配置。

最后说个真实案例。去年有个创业公司的服务器被挖矿程序入侵，CPU飙到100%。排查后发现就是2375端口裸奔，攻击者用API创建了一个容器，里面跑着门罗币挖矿脚本，还挂载了宿主机的`/root/.ssh` 目录，把SSH公钥都改了。他们花了整整两天才恢复服务，业务损失远超过那台服务器本身的价格。所以别觉得“我就内部用一下，不对外开放”就没事——很多攻击者全网扫描2375端口，你只要暴露在公网上，不到一小时就会被扫描到。

修复动作不复杂，但得做彻底。改配置、关端口、上TLS、验证防火墙规则，一步都不能少。安全这东西，懒一次就够你喝一壶的。