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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

请不要把任何和邀请码有关的内容发到 NAS 节点。

邀请码相关的内容请使用 /go/in 节点。

如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。

群晖发布 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

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

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

漏洞

安全性

系统

29 条回复 • 2026-02-05 00:55:43 +08:00

ingram22mb30

12 小时 27 分钟前 via Android

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

thereone

12 小时 7 分钟前

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

Kirkcong

11 小时 54 分钟前

区别大了去了
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

11 小时 41 分钟前

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

richiewu

11 小时 37 分钟前

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

Kirkcong

11 小时 35 分钟前

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

y1y1

11 小时 33 分钟前

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

hqt1021

11 小时 32 分钟前

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

future0906

11 小时 30 分钟前

@Kirkcong

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

Co1e

11 小时 19 分钟前

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

mooyo

11 小时 13 分钟前

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

a9htdkbv

11 小时 1 分钟前 via Android

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

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

a9htdkbv

10 小时 54 分钟前 via Android

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

dna1982

10 小时 34 分钟前

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

YsHaNg

10 小时 19 分钟前 via iPhone

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

yanqiyu

10 小时 13 分钟前

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

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

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

dilidilid

10 小时 1 分钟前

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

jocover

9 小时 47 分钟前 via iPhone

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

yinmin

9 小时 47 分钟前

家庭/小公司的公网 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

9 小时 44 分钟前

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

yinmin

9 小时 41 分钟前

@jocover #18 nas 上建一个带密码的 vhdx 文件，写 2 个脚本：在本地计算机自动挂接 nas 上的 vhdx 、断开 nas 上的 vhdx ，即安全又方便。

pingdog

9 小时 27 分钟前 via Android

@a9htdkbv 12# 低权限用户登入后，没法启动 telnetd 等于 0 危害，telnet 是 client ，telnetd 是 server

btw kernel 也有众多权限提升的漏洞，黑进来了，已经提升权限了，还去另外开一个 telnetd ？然后再重新用这个 telnet 漏洞进来？不如直接种后门了。。

mfaner

9 小时 21 分钟前

一般都用 ssh ，不开 telnet ，telnet 协议本身明文不安全。漏洞评分高，但是一般在路由器后面不直接面向公网。

pingdog

9 小时 19 分钟前 via Android

硬是要分个高低的建议全面阅读这两个帖子，开始大家讨论的并不是系统应不应该有漏洞，而是公众报告漏洞后厂商的响应。当厂商宣告采取措施后，v2ex 这种类比贴至少一天会有一篇，不知道为什么

“
v2ex 最开始是从这个感谢帖开始讨论他们的处理手法和漏洞猜测 /t/1189392
其后有人分享从飞牛论坛得到的更多详情 /t/1189672
”