理性讨论 没有绝对安全的系统

[hqt1021]

群晖发布 DSM 更新修复 Telnetd 安全漏洞 即便未启用也可能影响安全性 https://ourl.co/111713?t 2026 年 2 月 3 日 09:25

目前没有任何证据表明该漏洞已经被利用

但实际情况是 cve: https://www.txone.com/blog/cve-2026-24061-gnu-inetutils-telnet-exploitation/

当天扫了一点进行测试 大部分设备都是群晖 完整的 root shell 访问权限 里面也是被 d 狗执行了 botnet

口说无凭 这是扫了挂针的:

只能说 都是公关大师 虽然是进行了强制升级 时间未免过得太长了。而且也是不承认被利用了漏洞。感觉和飞牛的处理方式没有太大差异

[ingram22mb30]

就是为啥时至今日都不敢开放公网访问的原因！对面多牛不知道，自己多菜很清楚。

[thereone]

是的，所以要自主做好安全防护仅仅依赖单一系统的防护不知道什么时候就会被搞。

[Kirkcong]

区别大了去了
1. dsm telnet 不是默认开启的并且已经是被 ssh 替代的东西，出问题的比例在用户中不多。fnos 是默认开启的，并且官方的 fn connect 进一步加剧了该问题。
2. dsm 发布了声明，并且提供了修复方案。fnos 最开始说这是用户 http 明文传输的问题，后来压不住才承认。并且发出的系统更新有很多 bug ，有的无法升级，有的升级后无法挂载数据。
3. fnos 的这次事故本应该在一个月前就能避免的，12 月下旬就有人汇报了漏洞，官方也回应了说转交给了工程师。飞牛早就知道这个问题，但就是不修，dsm 可没有这样。
4. fnos 这次的事故是四个漏洞组合起来造成这次的问题，无论是路径穿越还是注入命令，都是基础到不能再基础的问题，而 fnos 却没有意识到。其他厂商可没有一次性爆出来 4 个这么严重的漏洞，并且造成这么严重的问题。

没有人说需要一个绝对安全的系统，而是 fnos 官方和别的厂商比起来差远了，最不可原谅的是，
1. fnos 一个月前就知道该漏洞，但没修。
2. 最开始告诉用户是 http 明文，用户自己的问题。

[sasonwong]

手动给楼上点赞，另外楼主你说的群晖不承认被利用了漏洞，有来源吗？

[richiewu]

@Kirkcong 四个漏洞组合，哪四个，我只知道没有检查输入路径

[Kirkcong]

@richiewu 我不能告诉你，否则就是提供入侵教程了。

[y1y1]

借用小红书集美的话：那能一样吗？

[hqt1021]

@sasonwong 蓝点的新闻里这么写的
但是官网我没有找到好像

[future0906]

@Kirkcong

补充一个，这个看起来 CVE 是 Upstream 的漏洞，fnOS 的是自己的系统。

[Co1e]

telnet 群晖好像默认是不行的吧
1 月 29 日发布
问题修正
修正了有关 telnetd 的安全性弱点 (CVE-2026-24061)。

[mooyo]

这个 telnet 的洞也不是群晖自己写的啊。。。

[a9htdkbv]

这篇文章的意思是不开启 telnet 不会受到这个漏洞的影响，但是“如果”还存在其他低危漏洞获得低权限账户，并“恰巧”可以通过这个低危漏洞连接到 telnet ，就可以实现提权吗？

@hqt1021 另外没看到蓝点网里面写群晖不承认被利用了漏洞呀，而且蓝点网的消息来源不好评价，之前国产 nanokvm 都被蓝点网造谣过

[a9htdkbv]

而且你截图里面是 6.2.2 的，早就已经 eol 了吧，估计没修的 cve 还有一堆。
飞牛最大的问题的是回避问题，捂着一个多月被灰产大规模利用以后才处理，如果发生初期内就和 react 一样全网公告升级，fn connect 添加拦截，提醒用户立刻关闭公网链接，说不定影响不会那么大
群晖至少每次漏洞都会披露 SA ，有 CVE 号，飞牛我至没看到有 CVE 或者 SA

[dna1982]

哈哈
中国很多人都喜欢用“没有绝对的 XX”，来避免相对的比较。
“没有绝对的安全”---所以你就可以不要相对的安全了？

[YsHaNg]

来了来了 这才对味 本来就是营销公司做什么 os

[yanqiyu]

telnet 这个年久失修的远程协议对公网暴露就是作死；而 Web UI,尤其是 nas 的 Web UI 本身就是为了对公网暴露的。安全要求一开始就不一样。

并且 fnos 这一开始就存在一系列漏洞，路径穿越（对于 NAS 而言已经很糟糕了）+关键 token 明文存储在日志/认证过程的私钥明文存储+一个 websocket 的 RCE ；至少路径穿越和 RCE 都可以单独拿一个 CVE 了。

并且这里出问题的是 Web UI ，作为设计上需要对外暴露的环节，最应该严防死守的地方。

[dilidilid]

telnet 这种古董还是不太适合和 webUI 的 critical 漏洞相提并论吧。。。

[jocover]

所以我 nas 上重要的东西都会用 yubikey 进行 openpgp 加密后才上传备份

[yinmin]

家庭/小公司的公网 ip 开放服务，有几个安全技巧推荐：

(1) 屏蔽无 sni 的 tls( https)连接。黑客盲扫是不知道你域名(sni)的，这条简单规则直接防 99.9%的黑客盲扫攻击。推荐前置 nginx ，配置 stream 模块的 map $ssl_preread_server_name ，并且不设 default 项，如果黑客发起无 sni 链接，nginx 会直接挂断 tcp 。(有个坑：如果设置不对，黑客发起无 sni 的 tls 请求后，服务器会发送证书，证书里有域名；服务器要直接挂断 tcp 不能返回证书)

(2) 对于管理平台等私有 https 网站，启用双向证书认证 mtls 。浏览器导入客户端证书后，使用起来超方便。windows 、mac 、ios 、android 浏览器都支持客户端证书认证的。推荐前置 nginx 或者 stunnel ，没有客户端证书，根本到不了后端服务。

(3) ssh over tls 。通常 ssh 仅密钥登录/关闭密码登录后是足够安全的，如果希望混淆 ssh ，或者进一步提升安全性，可以前置 nginx ，对 ssh 进行 tls 包裹。在.ssh/config 里配置 ProxyCommand 参数后，ssh 操作和原来基本一样。

(4) 公网只暴露 ssh 、tls(屏蔽"无 sni"连接)、vpn ，其他端口一律不要暴露。

抛砖引玉~~~

[yinmin]

接#19 ， 如果 fnos 的 https 服务能校验 sni ，并直接挂断"无 sni/sni 不正确"的连接，黑客也不可能这么肆无忌惮的随意攻击。