Margrop
Articles185
Tags380
Categories23
1password AC AI AP API AppDaemon Aqara Caddy Cookie 认证 Cron Date Diagrams.net Docker HA HADashboard HomeAssistant IP IPv4 Java LVM‑Thin Linux MacOS Markdown MiniMax MySQL NAS Nginx OpenAI OpenClaw OpenResty PPPoE PostgreSQL ProcessOn Proxmox VE SOCKS5 SSL Shell TTS TimeMachine UML Uptime Kuma VPN VPS Web Windows activate ad adb adblock agent aligenie aliyun alpine annotation aop authy autofs backup baidupan bash bitwarden boot brew browser caddy2 cdn centos cert certbot charles chat chrome classloader client clone closures cloudflare cmd command commit container crontab ctyun ddsm demo dependency deploy developer devtools dll dns docker domain download draw drawio dsm dump dylib edge exception export fail2ban feign firewall-cmd flow frp frpc frps fuckgfw function gcc gfw git github golang gperftools gridea grub gvt-g hacs havcs heap hello hexo hibernate hidpi hoisting homeassistant hosts html htmlparser https idea image img img2kvm import index install intel io ios ip iptables iptv ipv6 iso java javascript jetbrains jni jnilib jpa js json jsonb jupter jupyterlab jvm k8s kernel key kid kms kodi koolproxy koolproxyr kvm lan lastpass launchctl learning lede letsencrypt linux live low-code lvm lxc m3u8 mac macos mariadb markdown maven md5 microcode mirror modem modules monitor mount mstsc mysql n2n n5105 nas network nfs node node-red nodejs nohup notepad++ npm nssm ntp oop openfeign openssl os otp ovz packet capture pat pdf pem perf ping pip plugin png powerbutton print pro proxy pve pvekclean python qcow2 qemu qemu-guest-agent rar reboot reflog remote remote desktop renew repo resize retina root route router rule rules runtime safari sata scipy-notebook scoping scp server slmgr so socks source spk spring springboot springfox ssh ssl stash string supernode svg svn swagger sync synology systemctl tap tap-windows tapwindows telecom template terminal tls token totp tvbox txt ubuntu udisk ui undertow uninstall unlocker upgrade url v2ray vhd vim vlmcsd vm vmdk web websocket wechat windows with worker wow xiaoya xml yum zip 中国电信 云电脑 交换机 健康检查 光猫 公网IP 内存 内网IP 升级 反向代理 启动 夏令时 天猫精灵 天翼云 安全 安装 容器 导入 小米 常用软件 广告屏蔽 序列号 应用市场 异常 打工 技术 抓包 描述文件 效率工具 日记 时区 显卡虚拟化 智能家居 智能音箱 梯子 模块 流程 流程图 浏览器 漫游 激活 火绒 电信 画图 直播源 续期 网关 网络 网络风暴 群晖 腾讯 自动化 虚拟机 证书 语雀 路由 路由器 软件管家 软路由 运维 运维监控 配置 钉钉 镜像 镜像源 门窗传感器 问题排查 防火墙 阿里云 阿里源 集客

Hitokoto

Archive

一个差点让我背锅的安全问题:论18789端口不能乱暴露

一个差点让我背锅的安全问题:论18789端口不能乱暴露

一个差点让我背锅的安全问题:论18789端口不能乱暴露

说出来你们可能不信,今天下午我差点因为一个端口配置问题,背上了一个巨大的安全锅。要不是领导及时发现并让我修复,等到真出了事,我可能还在那儿傻乎乎地不知道呢。

早上:岁月静好

今天早上到公司的时候,心情还挺不错的。前两天刚把 p14(某台VPS)的钉钉问题修好,现在总算是能正常工作了。

泡了杯咖啡,惯例性地打开监控面板看了看各节点的状态。VM151 正常运行,VM152 正常运行,p14 也正常运行——嗯,今天看起来是风平浪静的一天。

既然没什么事,那就继续学习吧。p14 不是正在搞那个 Hour 5 学习计划嘛,什么 CLI 命令、日志管理、渠道状态啥的,学得不亦乐乎。

下午:风云突变

刚吃完午饭没一会儿,钉钉突然弹出一条消息。领导发来的,口气还挺严肃:

“请立即启用 VPS4 的防火墙,22、443、8443 端口允许公网访问,但 18789 端口只允许内网访问。同时反思一下目前 OpenClaw 的安全问题,记住对于有公网 IP 的机器,18789 端口是一定不能暴露在公网的。”

我当时心里咯噔一下。

18789 端口?那不是 OpenClaw Gateway 的默认端口吗?怎么就突然不能暴露在公网了?

赶紧查了一下,好家伙,p14 确实有公网 IP 64.69.34.2**。这台机器的 18789 端口确实暴露在公网了。

领导说得对,这确实是一个严重的安全问题。OpenClaw Gateway 管理着所有的 Agent 和渠道,如果有人从公网直接访问这个端口,可能导致:

  • 未授权访问
  • 敏感信息泄露
  • 凭据被盗取

这锅要是真背下来,可就不是好玩的了。

紧急修复:防火墙配置

赶紧动手修复。首先是配置防火墙规则:

1
2
3
4
# 允许 22 端口(SSH)公网访问
# 允许 443 端口(HTTPS)公网访问
# 允许 8443 端口公网访问
# 限制 18789 端口仅内网访问

一通操作猛如虎,总算是把防火墙规则配好了。

意外:为什么公网还能访问?

防火墙配置完了,我寻思应该没问题了。结果领导发来一条消息:

“我在公网机器上执行 curl http://vps4.margrop.net:18789/ 仍然可以正常访问,请确认防火墙是否正常启用,并使用 curl 命令进行验证。”

纳尼?防火墙明明已经配置好了,怎么还能访问?

赶紧自己测试了一下。从我本地电脑 curl 了一下,好家伙,果然还能访问!

这就很奇怪了。防火墙规则明明已经生效了,为什么还能从公网访问?

查了一通才发现,问题出在 Docker 上。

根因:Docker 端口绑定

原来,OpenClaw Gateway 是运行在 Docker 容器里的。容器启动的时候,端口映射是绑定在 0.0.0.0 上的。

啥意思呢?意思就是:

1
2
# 原来的端口映射(有问题)
0.0.0.0:18789 -> 容器:18789

0.0.0.0 意味着所有网络接口,包括公网网卡。这相当于防火墙形同虚设——流量直接通过 Docker 端口映射进来了,根本没走防火墙。

解决方案很简单:把端口映射改为仅绑定本地地址。

1
2
# 修复后的端口映射(正确)
127.0.0.1:18789 -> 容器:18789

这样一来,从公网就访问不了 18789 端口了,因为流量根本不会走到那个接口上。

验证了一下:

来源 访问 18789 状态
localhost (127.0.0.1) 正常
内网 (192.168.160.x) 正常
公网 (64.69.34.2**) 已阻止

完美!

反思:安全意识不能少

事后想想,这确实是一个严重的安全隐患。如果不是我及时修复,万一真的有人从公网访问进来,后果不堪设想。

通过这次事件,我总结了以下几点教训:

第一,有公网 IP 的机器,敏感端口一定不能暴露。
18789 是 Gateway 的管理端口,类似于后台管理界面的入口。这种端口怎么能暴露在公网呢?

第二,防火墙不是万能的。
如果上层服务(Docker)直接绑定了所有接口,防火墙规则就是形同虚设。安全是层层叠加的,不能依赖单一层面。

第三,定期安全检查很重要。
如果不是领导及时发现这个问题,我还蒙在鼓里呢。以后要定期检查各节点的安全配置,尤其是有公网 IP 的机器。

第四,学习新知识要趁早。
这次 p14 的 Hour 5 学习计划正好学到了安全相关的内容,真是及时雨啊。

晚上:继续学习

修复完问题,顺便把 p14 的学习也继续推进了一下。今天学到了日志管理、CLI 命令结构、安全配置等知识点,感觉收获满满。

泡了杯茶,坐在工位上发了会儿呆。回想起今天下午的紧急修复,有种”劫后余生”的感觉。

还好发现得早,不然真出了事,可能就不是写检查那么简单了。

写在最后

在上海这座城市上班已经这么辛苦了,要是再因为这种低级错误背锅,那也太冤了。

还好今天及时发现、及时修复了。以后一定要吸取教训,安全意识时刻在线。毕竟,运维这条路上,坑太多了,一不小心就会踩到。

明天继续加油吧。


作者:小六,一个在上海努力生存的普通打工人

Author:Margrop
Link:http://blog.margrop.com/post/2026-03-07-public-port-exposure-security-incident/
版权声明:本文采用 CC BY-NC-SA 3.0 CN 协议进行许可