从10月28日开始，群晖NAS被大规模加密的消息陆续出现，中招机器的文件后缀变成 .LOCK3D，目录里多出一封 read-me3.txt。 有人是早上打开电脑才发现的，照片、工程文件、影视库都已改不回来。群里传得最快的一句话是：最新版 DSM 也中招了，这回是 0day。知乎
先把手上的机器和这三份说法分开看。
群晖10月29日的公告指向一个旧洞：CVE-2024-10441，CVSS 9.8，系统插件守护进程可被远程利用执行代码，不需要账号密码，也不需要用户点任何东西。这个漏洞在2024年12月就已修复，官方让用户对照 SA-24:20 检查版本。 群晖安全团队同时表示，这不是新版 DSM 的零日漏洞。 它针对的是还在跑旧版 DSM 的机器，不是“所有群晖”。知乎微博
360 的分析指向另一组洞：两个今年9月披露的高危漏洞，群晖在9月18日已经发了修复更新，对应 SA-26:13。 这组洞的版本边界写得很清楚，和官方公告不是同一条线。知乎
Solar 应急响应团队接到的现场又不一样：一台受害机跑着 DSM 7.4.1-90080 Update 1，版本已经高过公开的修复线。 他们把这一轮暂列为“疑似 0day”。注意这个措辞，疑似的是攻击入口，不是已经坐实的 0day；套件、凭据、弱口令、暴露服务，都还在排查范围内。知乎
三份说法没有拼成一张完整的图。继续追问“到底是哪个洞”当然有意义，但今晚最先该回答的不是这个。
真正要命的是三件更土的事：DSM 裸挂公网、补丁和套件没跟上、备份盘长期在线可写。 漏洞决定的是“能不能进来”，公网暴露决定的是“够不够得着”。两个条件同时成立，攻击才有机会发生。知乎
Solar 在 FOFA 上查到，最近一年有约 1247 万条群晖相关服务记录、约 645 万个独立 IP。 这不是在线设备数，更不是受害数，但能说明公网上的 DSM 比想象中多。很多人的配置是“只开了一个端口”，或者用反向代理换了个域名；对扫描器来说，这和把 DSM 直接挂在公网上没有区别，反代不修漏洞，只换门牌号。知乎
一个被公开转述的案例里，一台 DS918+ 的 Web 界面直接开在公网，系统大约 18 个月没打补丁。 他有 3-2-1 备份，最后把盘拆下来挂到另一台机器，从备份恢复，重装系统了事。密码复杂、HTTPS、两步验证都有用，但它们挡不住一个不需要密码的漏洞，它们管的是另一条路。知乎
如果机器已经在加密，第一动作不是重装。10月30日出现的 c3rb3r-rescue 走的是内存取证，从还没重启的机器内存里找密钥材料；它还原过一份近 49GB 的备份，恢复了 80 个项目。 但换一台机器就得重新取一次内存，重启、断电、杀进程，都可能把这份材料弄没。同一周还出现了另一个家族，文件后缀是 .encrypt，勒索信叫 README_FOR_DECRYPT.txt，两个家族的入口是否相同，还没有定论。微博
还没中招的，按顺序做四件事。
先看门。路由器的端口映射、UPnP、DMZ 先过一遍；DSM 的 5000、5001、22、6690 不要给公网。 QuickConnect 和 DDNS 不用就关掉。确实要在外面访问，走 VPN 或 Tailscale，比把管理后台晾在公网上稳。知乎
再补洞。DSM 升到当前分支的最新版，套件也要升，尤其是套件中心里自己装的 PHP 生态；10月22日群晖还发过 PHP 的安全公告，升完 DSM 不等于结束。 另外，admin 账号禁用，两步验证、自动封锁、登录保护打开。这些不能替代补丁，只能缩小被撞上的机会。知乎
然后留后路。普通快照能救急，但拿到 root 权限的攻击者可以把它一起删掉；真正能扛住的是不可变快照和 WriteOnce。保护期官方建议填 7 到 14 天。知乎
它要求 DSM 7.2 以上、Btrfs 文件系统、2020 系列及更新的机型，DS918+、DS218+、DS1019+ 这些老机器在界面上根本没有这个选项。 网上有改配置强开的办法，别在存着重要数据的机器上试：保护期倒计时可能根本不会走，快照会变成删不掉的“钉子户”。下载目录、监控循环录像、虚拟机目录也不要开，配额要先设好，否则几天就能把盘塞满。知乎
最后，备份要有一份不跟着 NAS 一起被加密的。移动硬盘、另一台机器、云端加密备份都行，关键是别长期在线可写，并且真的做过一次还原。任务显示成功、点开是空的，这种事不比勒索少见。
关掉公网访问的代价很具体：客厅电视连着的片库，第二天可能就打不开了。但这比在 read-me3.txt 面前才发现备份也打不开，要好。
