核心防护是禁用或严格限制docker remote api的tcp监听（如2375/2376），生产环境应仅监听unix:///var/run/docker.sock；必须远程访问时，须绑定可信内网地址、启用tls双向认证，或通过ssh隧道代理，辅以docker-user防火墙规则前置封堵。
核心是堵住 docker remote api 的 tcp 端口（默认 2375/2376），不能让它裸奔在公网或内网任意位置。
禁用或严格限制 2375/2376 监听地址
Docker 守护进程默认只监听 unix:///var/run/docker.sock，这是安全的。一旦通过 -H tcp://0.0.0.0:2375 或 daemon.json 中配置 "hosts": ["tcp://0.0.0.0:2375"]，就等于把 root 权限交到网络上。
- 生产环境应完全禁用 TCP 监听：删掉 daemon.json 中的 tcp 地址，或注释
ExecStart行里的-H tcp://... - 若必须远程调用（如 CI/CD），只绑定到可信内网接口，例如
-H tcp://192.168.10.10:2375，绝不用0.0.0.0 - 重启守护进程后，用
ss -tlnp | grep :2375验证监听地址是否已收缩
用 DOCKER-USER 链做前置封堵
即使误开了 2375，也能靠防火墙规则第一时间拦截——DOCKER-USER 是 Docker 流量进入前的最后一道可控闸门，规则不会被容器启停覆盖。
- 直接丢弃所有公网对 2375 的访问：
iptables -I DOCKER-USER -i eth0 -p tcp --dport 2375 -j DROP - 如需保留跳板机访问，先放行再封死：
iptables -I DOCKER-USER -i eth0 -s 10.20.30.40 -p tcp --dport 2375 -j ACCEPT，再补一条 DROP 规则 - 务必用
-I插入顶部，用DROP（不是 REJECT），避免向扫描器暴露端口存在
启用 TLS 认证强制双向验证
如果业务强依赖远程 API，不能只靠 IP 限制，必须上加密+认证。
- 生成 CA、服务端证书（dockerd 使用）和客户端证书（curl / docker CLI 使用）
- 在 daemon.json 中配置：
"tls": true, "tlscacert": "...", "tlscert": "...", "tlskey": "...", "tlsverify": true - 客户端必须带证书调用：
curl --cert client.pem --key client-key.pem https://host:2376/version - 未提供有效证书的连接会被服务器直接拒绝，连握手都通不过
替代方案：用 SSH 隧道代理 API 请求
不暴露任何新端口，复用已加固的 SSH 通道，零额外攻击面。
- 本地执行：
ssh -L 12375:/var/run/docker.sock user@prod-server - 之后用
docker -H tcp://127.0.0.1:12375 ps即可操作远端 Docker - 所有流量走 SSH 加密，权限由 SSH 密钥控制，无需改 Docker 配置
- 适合运维批量管理、临时排障等低频但高危场景
