docker 重磅安全漏洞

[laminux29]

我们在使用 docker 时，一般会使用 -p / --publish 来映射端口到宿主机，然后在 iptables 的 INPUT Chain 里开一条白名单规则，允许指定的 IP 或 IP 范围来访问这个端口。

问题是，很多朋友测试能访问后，很容易偷懒，不再测试别的 IP 是否能访问了。docker 的重磅安全漏洞也就在这里出现。如果你继续测试，你会发现，不在白名单的 IP 地址，也能访问这个端口。

原因在于 docker 自行管理 iptables ，它给 iptables 里插入一大堆 Rule Chain ，绕开了 INPUT Chain 的管理。

通过以下两条命令：

iptables --list --verbose --numeric

iptables --list --verbose --numeric --table nat

可以发现 docker 插入了一堆以 DOCKER 命名的 Rule Chain 。

本来标准的软硬件防火墙，包括 iptables 、Windows 防火墙，为了安全，都是默认使用白名单制，而 docker 的防火墙却是黑名单制的，这与安全理念冲突。

建议关闭 docker 的自行管理防火墙的功能，向 /etc/docker/daemon.json 添加 "iptables": false

然后手动清理 docker 向 iptables 里添加的各种 Rule Chain

最后手动管理 docker 的防火墙，来加强安全。

[0x535]

还以为是什么呢… 标题党

[laminux29]

@0x535 并不是标题党，你可以搜一下，不少人发现这个问题。更多的人可能没发现这个问题，导致了白名单端口直接暴露在整个互联网上。

[julyclyde]

啊？ INPUT 链？为什么是 INPUT 链？

[laminux29]

@julyclyde

因为当你需要允许某个 IP 能访问本机的某个端口，正规的做法是，写一条规则插入到 INPUT 链中，比如：

iptables --insert INPUT --protocol tcp --dport 3306 --source 11.22.33.44 --jump ACCEPT

[0x535]

@laminux29 我知道有这个问题存在，十年前就有人提出过 issue ，官方认定是 feature 而不是 bug 。
再说 2025 年了，现在还有哪个主流的云服务平台是默认开放所有端口的？都直接用 iptables 这种东西管理而不是云服务提供的防火墙了，可见对自己的技术很有信心…

到你这儿成了重磅安全漏洞了，你是不是对这几个字有什么误解？

[laminux29]

@0x535

我遇到太多的场景，是需要通过 OS 内的防火墙，来给 docker instance 设置 IP 白名单，比如以下 3 种经典场景：

1.云服务器并不是从平台直接拿的，而是由同事或运维给的。他们为了图方便，把平台上的防火墙给直通，然后把防火墙的控制权下放给 OS 的内部防火墙，比如 iptables 。

2.拿到的云服务器，是测试用的专用系统，默认所有的安全规则都是清空的。比如 iptables 被清空，selinux 被关闭，直接启用 root 登录等等。

3.乙方拿到甲方机房的 2 台虚拟机，第一台用于 docker db ，第二台用于 docker web server ；甲方机房的同网段内还有其他虚拟机，乙方的 docker db 只能给乙方的 docker web server 使用，因此需要通过 iptables 设置白名单，否则有可能被甲方机房内其他服务器上的病毒或木马攻击。

至于技术信心，这个话题，只是计算机工程专业而已，没任何难度...有难度的是需要依赖数学的算法、数据分析、AI 等专业。当然，docker 官方故意恶心人，对 iptable 进行反向设计，那么无论技术多牛的人，除非纪律性拉满，把测试验证做完，否则都容易被这个问题给坑了。

在安全上，这个所谓的特性，就是重磅安全漏洞，目前已经有很多忽略测试的人被坑了。

[laminux29]

另外，防火墙，比如 iptables 、Windows 的内置防火墙，设计原理都是白名单制的。也就是默认拒绝，除非添加白名单规则。Docker 这种反向设计，会导致在系统运维时，每一种有共识的设计、逻辑、代码，都需要再验证一次，那么会导致安全这个方面的工作量被迫拉满。

举个假设的例子，Intel 与 AMD ，把加法指令，定义为计算两个操作数之和，多年以来，这种设计已经成为计算机的共识。然而，docker 官方在最近几年，出品了一款 CPU ，它把加法指令与减法指令进行互换，并且称之为 [特性] ，你觉得这是不是重磅漏洞？

[julyclyde]

@laminux29 你确认这个端口算是“本机”的？？
docker 不是 NAT 的吗？

[laminux29]

@julyclyde docker 的网络模式取决于 linux 的能力。对于 Debian 来说可以让 docker 有 nat 、host 、bridge 以及隔离。

[julyclyde]

@laminux29 唉，我觉得你还是再多读读 iptables 的资料吧
重点根本不在 docker 那头

[laminux29]

@julyclyde 我写过基于二开 iptables 的全自动化 NAT + Bridge 的管理器，我认为至少我对 iptables 的理解，比你熟悉，所以你没必要建议我再去学习 iptables 。

你还没抓住这个问题的重点，就是 docker 官方，把业内通用的防火墙白名单机制，反向设计成黑名单形式，还美名为特性。

说白了，docker 官方，没有二开 iptables 的能力。人家 VMware 在 Windows ，没有依赖 Windows 的防火墙，而是通过二开，实现了一套完整的网络管理系统，彻底解决了这个问题。docker 官方没有这个能力，依赖 iptables ，不仅瞎搞，还嘴硬，这是造成这个漏洞的本质原因。

[julyclyde]

@laminux29 好好好，都是你对

[redial39]

我是运维.
我交付的服务器,凡是安装 docker 的都不关 iptables,凡是不使用 docker 技术栈的全部 disable iptables
你要问我为什么这么操作,因为我对网络设备包括但不限于山石,飞塔,juniper,云网关,云安全组上的策略有绝对的自信
你要问我为什么对他们有自信...这不是废话么,我对机器二极管还不自信,还能对自己手敲键盘有信心吗?

[laminux29]

@redial39

你这运维很不专业。

首先，大部分 Docker 用户是家庭用户，他们会有这些专业的硬件防火墙？

其次，就算是企业级环境，有硬件防火墙，防火墙内部区域的互相攻击怎么办？

[redial39]

@laminux29
首先家庭用户不需要运维
其次家庭用户说难听点,不需要安全,不中病毒就是最大的安全
然后企业环境,正规行为都是 vlan 划分各种区域.只要在一个区域里,就是有互访需求的

[redial39]

即使是在同一个 zone 里, 机器上还有各种安全软件, 前面有 waf,定期漏扫,安骑士..我要这机器 iptables 做什么...徒增烦恼

[laminux29]

@redial39 同一个区域内的互相攻击怎么办？你明显没管理过超大规模的项目。

[redial39]

@laminux29 对