@julyclyde

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

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

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

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

@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 进行反向设计，那么无论技术多牛的人，除非纪律性拉满，把测试验证做完，否则都容易被这个问题给坑了。

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

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

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

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

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

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

@redial39

你这运维很不专业。

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

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