十月三十一号的夜里，卡图图后怕了一回。他那台黑群晖跑在PVE虚拟机里，共享文件夹堆着孩子从出生到现在的照片和几年的AI家教资料，救了他的是当初的一个随手决定，数据盘用直通给了另一台Ubuntu虚拟机，群晖系统里根本看不见这块盘。勒索脚本把能看见的目录全刷成了.LOCK3D，看不见的部分一根毛都没掉。同一夜，更多人在目录里翻出read-me3.txt，而截至发稿，这波C3RB3R还没有通用解密办法。四十八小时里，能做的动作比慌有用。
今晚先关三个口
关的第一个口是端口映射。翻路由器后台，把5000、5001这两个DSM管理口的转发规则删掉，UPnP和DMZ一并关掉，自查帖里五步走的第一条就是这个。别只盯着群晖本体，有复盘记录写得明白，这波攻击有相当一部分是从Docker里映射到公网的GitLab之类服务打进容器、再摸到宿主机的。要留远程通道就换VPN，非用不可的端口改成三万四万的大号端口，22、6690这类敏感口不给公网放行。
关的第二个口是远程服务。QuickConnect先停，勾选自动端口映射的那一下，群晖会自己去动你的路由器，这是自查帖作者的原话提醒。顺手把admin和root全禁了，开启双重验证和登录失败封锁，改默认端口在老鸟眼里是基本操作。
关的第三个口是版本。群晖官方十月二十九日的公告说得很直白，这波攻击打的是还在跑过时DSM版本的机器，指向2024年12月就修掉的CVE-2024-10441，危险评分9.8；360那边则指向九月披露、月底发布补丁的两个新洞，同样是9.8分。两边的判断并不一致，眼下别赌哪边对，把DSM升到安全公告对应的版本，套件中心的组件挨个过一遍，两条路一起堵死。
哪个型号最危险，答案不在型号上
翻遍公开的受灾记录，机型从机架的RS款到桌面的老型号都有，真正共同的特征只有一个，公网暴露加长期没更新。有用户自己复盘，发现老系统的群晖在公网上裸奔好几天没挨打，多半是因为没直接映射5000和5001，万幸这两个字他写得坦诚。所以别找型号黑名单，先照镜子，你的IP在公网上挂没挂，你的DSM停在哪个版本，这两件事比机器型号决定生死。
普通快照挡不住root
这波里靠快照救回数据的人要认清一件事。教程作者说得直接，普通快照能救命，纯粹是因为首批攻击脚本写得糙，加密完就撤，忘了删快照；而任何拿着管理员密码或root权限的人，一键就能清空攒了半年的存档。堵这个漏洞的是DSM 7.2之后引入的不可变快照和WriteOnce共享文件夹，给存档上时间锁，倒计时没走完，root删不掉，恢复出厂也删不掉，快照本身只记账不拷贝，十几TB的文件两三分钟翻回出事前的状态。新型号用户按自查帖的建议，给每个文件夹排上14到20天的锁，不开白不开。老机型锁不了快照的，把备份盘写完就拔线，NAS绝非绝对安全的备份终点，这话是安全公告解读里的原话。
真中招了，四个不要和一个别
四个不要，不要删加密文件腾空间，不要重建存储池，不要信付费包解密，不要在受灾盘上继续写新数据。一个别，别急着重启。有安全研究者十月三十日在GitHub开源了c3rb3r-rescue，靠内存取证把一家公司10月24日的近49GB备份完整解开，80个项目、23名用户、9253个LFS对象，校验全过。但它不是万能钥匙，捞的是那台机器内存里残留的东西，一旦重启断电或者杀进程，密钥蒸干，取证全部白做。发现异常，先拔网线，保持开机，找专业的人镜像，再谈恢复。
我的盘法
我这只仓鼠给所有在线设备记同一条账，能被外面问到密码的机器，就当它已经被破过，早晚问题。数据在不在自己手里，就看两件事，那块盘现在拔没拔，那把时间锁还剩几天；共享文件夹的图标亮不亮，从来不作数。今晚把三个口关完，快照排上，比转发十篇恐慌帖都有用，指望黑客下次还忘删快照，那不叫备份，叫抽奖。
