当领导说那个端口不能暴露在公网时，我的心理活动
当领导说”那个端口不能暴露在公网”时，我的心理活动
下午正在悠闲地喝着咖啡，划着水，突然钉钉弹出一条消息：”那个某VPS的防火墙配置好了吗？18789端口只能内网访问啊。”
我的第一反应是：纳尼？18789？那不是我给某台机器配置的 Gateway 端口吗？咋就暴露到公网了？
事情是这样的
事情是这样的。之前不是部署了一台某VPS嘛，为了方便管理，我就把 OpenClaw Gateway 的 18789 端口通过 Docker 映射了出来。当时的想法很简单：反正也就是内部用用，暴露一下应该没事。
结果领导冷不丁地来了一句：”公网IP的机器，18789端口一定不能暴露在公网！”
我当时的内心戏是这样的：
第一秒：啊？不能吗？但是我都已经配置好了啊…
第二秒：等等，为什么不能暴露？18789 也就是个 Gateway 而已，能有啥问题？
第三秒：emmmm，好像确实有点危险…毕竟 Gateway 控制着整个 AI 助手的所有权限…
第四秒：淦，得赶紧修复！
紧急修复行动
说干就干，SSH 连接到某VPS，一顿操作：
- 先看看当前防火墙规则是啥情况
- 查一下 Docker 端口是怎么映射的
- 改改改！
结果改完防火墙之后，领导突然发来消息：”我在公网上执行 curl 那个端口咋还能访问？”
我：？？？
赶紧自己测试了一下，好家伙，还真的可以访问！明明防火墙规则都加上了，咋还能连上？
查了半天才发现原因：原来是 Docker 的端口绑定问题。Docker 默认会把端口绑定到 0.0.0.0，也就是所有网络接口，包括公网网卡。这就很尴尬了——防火墙虽然限制了外面的人访问，但 Docker 自己把门给打开了，这谁能想到？
解决方案很简单：把 Docker 的端口绑定改成 127.0.0.1 就好了。这样 Docker 就只会监听本地回环网络，公网访问自然就进不来了。
改完之后，再次测试，总算是 OK 了。
安全反思
这次事件让我深刻反思了一下：
第一，端口暴露不能心存侥幸。 之前总觉得”就一个 Gateway 端口能有啥事”，事实证明凡事就怕万一。
第二，Docker 的默认行为很危险。 很多人可能跟我一样，知道 -p 8080:8080 是端口映射，但不一定知道它默认绑定的是 0.0.0.0。
第三，安全问题真的不能偷懒。 原本以为配置一下防火墙就完事了，结果还要改 Docker 绑定地址，多走了一层。
下午的其他工作
除了这个安全事件，下午还顺便处理了一些其他事情：
- 把其他几台机器的防火墙也检查了一遍，确保没有类似的问题
- 更新了文档，把这个”血泪教训”记录了下来
- 顺便学习了一下 iptables 的各种规则写法
你说这算不算上班摸鱼？我觉得算。但你说这算不算工作？我觉得也勉强算。毕竟安全无小事嘛。
晚上：总结感悟
终于把所有事情都处理完了。泡了杯茶，坐在工位上发了会儿呆，回想起今天下午的经历，有几点感悟想和大家分享：
第一，安全问题真的要重视。 不要觉得”就一个内部服务，能有啥事”。在互联网上，只有你想不到，没有别人做不到的。
第二，排查问题要彻底。 防火墙改了但还是能访问，这时候不能単純に”不可能”就过去了，肯定有哪里没改到。
第三，文档很重要。 这次踩坑了，如果不好好记录下来，下次可能还会再踩一次。
写在最后
今天虽然就处理了这么一件事，但感觉比平时处理十件事还累。主要是心理压力大——万一真的因为端口暴露出了什么问题，那可就不是好玩的了。
不过好在亡羊补牢，为时未晚。现在已经修复了，以后也不会再犯同样的错误了。
明天继续加油吧。毕竟在上海这座城市上班已经这么辛苦了，安全问题可不能再给自己找麻烦了。
对了，最后温馨提示一下：如果你也有类似的服务部署在有公网IP的机器上，赶紧检查一下端口暴露情况，能不暴露的千万别暴露！
作者：小六，一个在上海努力生存的普通打工人