爆发时间：2026年10月28日起 | 影响面：群晖 DSM 全系列（含最新版 7.4.1）| 勒索家族：C3RB3R（Cerber 变种）

一、发生了什么？

从 10 月 28 日晚上开始，B 站、小红书、什么值得买、Linux.do 社区集中出现大量群晖用户求助，症状高度一致：

1. 文件一夜之间全部被加密，原扩展名后追加 .LOCK3D（或 .L0CK3D，数字 0）；

2. 每个目录下留下一封 read-me3.txt 勒索信（C3RB3R INSTRUCTIONS）；

3. 有用户半夜听见 NAS 风扇狂转，登进控制台一看——磁盘可用空间归零；

4. 甚至有运行 6 年的老玩家，RAID 6 + 本地自动备份，主数据和本机备份被一锅端。

某位受害者 NAS 里的真实一幕：几十份芯片 Datasheet、技术 PDF 全部变成 LOCK3D 文件，修改时间整齐地定格在 10 月 28 日 20:09——这就是加密程序扫盘的那一刻。

Cerber 的 Linux 新变种，代号 C3RB3R。它的勒索站点已经做成全自动流水线：

• 支持免费试解密 1 个文件（≤1024KB）证明"解密能力"；

• 自动生成比特币钱包地址和二维码，赎金 0.085 BTC，5 天不付翻倍至 0.17 BTC；

• 交易 6 次确认后自动发放解密器，全程几乎无需人工。

最扎心的一点：已确认有中招设备跑的是最新版 DSM 7.4.1-90080 Update 1。

二、是 DSM 本体 0day 吗？先别急着下结论

很多朋友第一反应是"最新版都中招，肯定是 0day"。但安全团队把话说得很克制：最新版遭到攻击，不等于最新版存在 0day。

目前掌握的事实是：

① 群晖官方 9-10 月刚修过两个 CVSS 9.8 的 Critical 漏洞（PHP2Shell）：

1. CVE-2026-109618、CVE-2026-109619

2. 影响所有装了 PHP 依赖套件的 DSM：Web Station、Calendar、MailStation、WordPress、phpMyAdmin、Joomla、MediaWiki、KodExplorer 等

3. PHP 7.3 已 EOL 无补丁，必须卸载或迁移

② 社区溯源指向的几条疑似入口：

1. Docker 容器被打穿（重灾区）：不少人在 Container Manager 里跑 GitLab、Gitea、Confluence 并映射到公网。10 月中下旬 GitLab 刚爆出 CVSS 10.0 的未授权 RCE，容器若挂载了整卷（/volume1），打穿容器等于拿下 NAS；

2. crond 定时任务潜伏引爆：有用户纳闷"前几天刚升级怎么还是被锁"——很可能是升级前已被攻破，黑客写入计划任务静默潜伏，统一触发；

3. 凭据泄露 + 内网横向：局域网里一台电脑中了钓鱼邮件，病毒读本机保存的 NAS 账号密码，走正常 SMB 协议完成加密——这就解释了为什么改了端口、开了 2FA、禁了 SSH 照样中招：门根本不在 DSM 登录这条路上。

入侵入口仍在溯源。在官方归因落地前，"只有旧版本才中招"和"升级就安全"的说法都不成立。

三、三个交学费换来的教训

教训一：RAID 不是备份。

RAID1/RAID6 防的是"盘坏"，不防"文件被加密"。加密发生在文件系统层面，两块盘只是同步了一份"完美的加密副本"。拔盘插电脑，读出来还是密文。

教训二：2FA、改端口、禁 SSH，防的是大门，不是小路。

这些措施保护的是 DSM 登录入口。攻击者拿着已泄露的凭据走 SMB，或者从容器、套件进来了，这些防线全部形同虚设。把 NAS 暴露公网，本质上就是在赌运气。

教训三：同步套件既是帮凶，也是救命绳。

有受害者眼睁睁看着 Cloud Sync 把加密文件往 OneDrive 同步——云端"备份"正在替病毒打工，把干净备份也覆盖成密文。反过来，也有人发现得早、及时停掉同步，靠网盘里那份没被覆盖的备份救回一命。真正的保险是不可被改写的离线/异地副本。

四、中招了怎么办？"黄金一小时"处置清单

立即做（按顺序）：

1. 物理拔网线——不要只软断网，关 WiFi、断聚合口；

2. 停掉 Docker 容器、Hyper Backup、Cloud Sync——防止密文同步覆盖云端备份；

3. 不删文件、不重装、不格式化、不跑 Data Scrubbing——Btrfs CoW 的历史数据块可能还没被覆写，抢救空间就在这里；

4. 保留现场证据：read-me3.txt 勒索信、2-3 个加密小样本、/var/log 日志、登录记录、crontab、容器配置；

5. 有条件就对磁盘做只读镜像，在副本上分析；

6. 打开 Snapshot Replication 快照中心，找加密发生前（如 10 月 28 日 23:30 前）的快照，有机会整体回滚；

7. 联系专业应急响应团队溯源，剥除 crond 后门后再恢复数据。

绝对别做：

1. ❌ 改后缀拿老 Cerber 解密工具乱试（加密结构已变，只会破坏现场）；

2. ❌ 信"100% 包解密、代付赎金"的中介；

3. ❌ 直接交赎金——很多人交了钱拿不到钥匙，还会被二次收割。看看勒索站点自己 FAQ 里怎么写的：

恢复优先级： 离线/异地只读备份 → Btrfs 不可变快照残留节点 → Hyper Backup 仓库底层解包 → 专业取证机构。

五、没中招的，今晚就做这 5 件事

① 收敛暴露面（最优先，一分钟都别等）

• 删掉路由器上所有 NAS 相关端口映射，关闭 UPnP；

• 关闭 QuickConnect、DDNS 直连，DSM 管理口不许公网可达；

• 远程访问一律走 VPN + IP 白名单；

• 关掉用不上的服务：SSH、Telnet、FTP、WebDAV、SMB1；

• 已经把端口映射到公网的，先做一次完整备份——攻击者可能已留了计划任务，随时二次引爆。

② 打补丁、清套件

• 套件中心核对 PHP 版本：7.4 ≥ 7.4.33-0131、8.0 ≥ 8.0.30-0122、8.1 ≥ 8.1.34-0120、8.2 ≥ 8.2.35-0171、8.3 ≥ 8.3.36-0051、8.4 ≥ 8.4.27-0051；Calendar ≥ 3.0.4-21435、MailStation ≥ 30000002.3.19-20333；

• 卸掉 PHP 7.3 和不用的第三方套件；

• 容器镜像全部升级，检查挂载点——别把 /volume1 整卷挂进容器；

• 排查 /etc/crontab、用户 cron、容器内 cron 有无异常脚本。

③ 账号与权限

• 禁用 admin 账号，新建管理员（别叫 admin/root/administrator）；

• 管理员组全量开启 MFA 双重验证；

• 开启自动封锁：5 分钟内失败 5 次封 IP；

• 密码 16 位以上完全随机——16 位随机密码即使每秒试 1 万亿次也要约 4000 万年，真正的风险是泄露而不是破解；

• 共享文件夹最小化授权：归档只读、备份目标禁止删除。

④ 备份架构（关键中的关键）

• 3-2-1 原则：3 份副本、2 种介质、1 份离线/异地；

• 用拉模式备份：备份机主动来读，NAS 侧只给只读账号、无删除权限；

• 开启 Btrfs 不可变快照，保护期设 7-14 天；

• 同步型工具（Cloud Sync/Drive）中招时会推密文上云——重要数据改用版本化/不可变目标；

• 定期做恢复演练。没恢复过的备份，等于没有备份。

⑤ 网络隔离（企业场景）

• 防火墙在 NAS 前做 ACL，仅内网段可访问；

• NAS 放独立 VLAN，不跟办公 PC 混层；

• 部署 IDS/IPS 盯异常行为：SMB 批量改名、crond 改写、外连 Tor。

六、进阶硬核加固：四道针对性防线

基础清单之外，再给想"把门焊死"的朋友四招进阶操作，每一条都针对这次事件的真实攻击面。

① 开启 DSM 防火墙，只放行国内 IP

大部分自动化勒索扫描源来自海外 VPS，直接掐掉境外流量，扫描面少一大半。

• 控制面板 → 安全性 → 防火墙，勾选"启用防火墙"；

• 新建规则：来源 IP 选择"选择位置"，勾选中国，动作允许；

• 再建一条兜底规则：来源所有，动作拒绝（规则按顺序匹配，国内放行一定要排在拒绝之前）；

• 注意先确认自己的远程访问场景（如手机 4G 流量走国内出口，不受影响；海外出差则要留好通道）。

② 更改 DSM 默认端口，改到高位

默认的 5000/5001 是全网扫描器的第一目标，改成高位端口能过滤掉 99% 的批量扫描噪音。

• 控制面板 → 登录门户 → DSM，把 HTTP/HTTPS 端口改成 40000 以上的随机五位数（例如 52371），别用 5000-65535 里的知名端口（8080、8888、50000 这些也是热门扫描目标）；

• 勾选"自动将 DSM 桌面的 HTTP 连接重定向到 HTTPS"；

• 老话重申：改端口是加高围墙，不是拆掉大门，必须配合 2FA 和强密码一起用。

③ 修改 Nginx 配置：只对 SNI 回应（防指纹扫描）

DSM 默认对任意 IP 直连、任意 Host 头都会返回登录页——扫描器一扫就知道"这是一台群晖"，等于自报家门。让 Nginx 只对携带正确 SNI（域名）的请求回应，可以有效隐身。

⚠️ 此操作需要 SSH + 修改 Nginx 配置，改错会导致 DSM 面板打不开，动手前先备份配置、按下面步骤来。

1. DSM 开启 SSH（控制面板 → 终端机和 SNMP），SSH 登录后 sudo -i 切 root；

2. 备份：cp -r /etc/nginx /etc/nginx.bak；

3. 新建拒绝配置文件 /usr/local/etc/nginx/conf.d/deny-default.conf（该目录下的 conf 会被 DSM 主配置 include，升级系统不易被覆盖）：​

   默认 server 块：IP 直连 / 错误域名 / 无效 SNI 一律拒绝

   server {

    listen 5000 default_server;

    listen 5001 default_server ssl;

    server_name _;

    ssl_reject_handshake on; # TLS 握手阶段直接拒绝无效 SNI

    return 444; # HTTP 层直接断开，不回任何内容

   }

4. 语法校验：nginx -t，看到 syntax is ok 再继续；

5. 重载：synosystemctl restart nginx（或 nginx -s reload）；

6. 验证：用 https://NAS的IP:新端口 直连应该无法建立连接，只有通过你绑定的域名（DDNS/自有域名，且 DNS 指向正确）才能打开 DSM 登录页；

7. 远程访问请配合 DDNS + 自有域名使用，路由器只映射新的高位端口。

如果嫌 SSH 改配置麻烦，还有个低配替代方案：控制面板 → 安全性 → 自动封锁 开到最严格，再把 DSM 的"地区访问限制"用防火墙规则锁死，效果打折但零风险。

④ 安装 Snapshot Replication，做好快照（最后的救命绳）

这次事件里，快照是少数能整体回滚数据的自救手段——前提是你装了、开了、保护期设对了。

套件中心搜索 "Snapshot Replication"，点击安装（上方截图所示，免费官方套件）；

• ⚠️ 前提：存储空间必须是 Btrfs 格式（ext4 不支持快照；RS1221+ 等新款默认 Btrfs，老机器可在存储管理器里查看）；

• 打开套件 → 快照 → 设置，对重要共享文件夹启用计划快照： 

¡计划：每天 1 次（生产数据频繁写的建议每 6 小时）；

¡保留策略：保留 7-14 天——这是关键！保留期太短，可能快照还没到期加密就发生了；

¡勾选"快照期间拍摄的更改可见"保持默认即可；

• 进阶：对最重要的共享文件夹设置不可变快照/延长保护期，勒索程序拿 root 权限也删不掉保护期内的快照；

• 记住快照的作用边界：同机快照防加密，不防整机损毁，快照之外仍需一份异地/离线备份（3-2-1 原则）。

七、写在最后

这次事件的定性很清楚：不是"群晖不行"，而是"公网暴露的群晖 + 没修的 Web/PHP/容器面 + 可写备份"被自动化收割。

记住四句保命话：RAID 不防加密，2FA 只防爆破，同步盘不是备份，暴露公网就是赌命。

现在最值钱的三件事：断公网、修 PHP/容器、留一份拔了线的只读备份。

如果你身边有在用群晖的朋友，把这篇文章转给他——防在前面，比事后找数据恢复公司划算一万倍。

参考来源：Solar 应急响应团队、群晖官方安全通告（PHP2Shell: CVE-2026-109618/109619）、Synology 知识中心。本文将持续跟进官方溯源结论，请关注更新。

阅读原文：点击这里