当前位置：

社区首页

电脑数码

存储设备

网络存储

群晖

文章详情

群晖 NAS 勒索病毒之后，我排查出家里四个裸奔点

一开头先问三个问题

你的 NAS 有没有把 5000 或 5001 端口直接对着互联网。你的备份是不是和原数据躺在同一台机器上。你的 IPv6 地址是不是默认允许任何人连进来。

这三个问题只要有一个答不上来，2026 年 10 月那轮群晖勒索事件就可能落到你家。我用两个晚上把家里的局域网重新加固了一遍，这篇记录写清楚我原来错在哪、改了什么、哪些还没改完。

二事件背景

2026 年 9 月 18 日，群晖发布安全公告 Synology-SA-26:13，修复了两个 CVSS 均为 9.8 的漏洞。CVE-2026-13639 出在登录逻辑，属于熵不足，对应 CWE-331。CVE-2026-13684 出在 SCGI，属于输出编码不当，对应 CWE-116。两个漏洞都不需要账号密码，也没有用户交互环节。

9.8 分意味着攻击者不需要什么技巧。它只需要一台机器，24 小时不停地扫全网开放 5000 和 5001 的地址，扫到就尝试利用。官方修复版本覆盖 DSM 7.4-90075、7.3.2-86009-4、7.2.2-72806-9 和 7.2.1-69057-12。补丁存在和你的设备已经升上去，是两件事。

比利时 CCB 在 2026 年 10 月 30 日的公告里，根据国内安全厂商的研判确认这两个漏洞已被在野利用来投放勒索。补丁发布后一个多月，国内还是出现大批设备中招。更麻烦的是有用户反馈，自己的系统版本比官方建议的修复版本还新，文件一样被加密。

被加密的文件会加上 .L0CK3D 后缀，每个目录里留一份 read-me3.txt 勒索信。这一段我说明一下我的处境。我没有中招，我是看到 10 月下旬集中爆发的消息之后才动手的。所以这篇文章只写看到风险之后怎么加固，不写中招之后怎么恢复。

攻击链值得拆开看一遍，因为它解释了为什么这类事件总能重复发生。第一步是全网扫描，专门找 5000 和 5001 响应的地址，这活不需要人盯，脚本一晚上能扫完一个国家的地址段。第二步是用那两个免登录漏洞进去，拿到系统权限。第三步是遍历共享目录，把文件批量加密，同时把同机挂载的备份盘一起处理。

整个过程里没有一步需要猜密码。这也解释了为什么改复杂密码、开二次验证在这轮事件里救不了人。防线要往前挪，挪到「不让人扫到」和「扫到也进不来」这两层上。

这也解释了为什么家用 NAS 会成为重灾区。大量设备装了 DSM 就把 5000 端口映射出去，图个外网方便，然后几年不动。补丁、端口、备份这三件事只要有一件没做对，扫描器就会替你发现。

三我家原来长什么样

这是我家的环境，IP 是我自己的，抄规则的时候把网段换成你家的。整个网络是扁平的 192.168.31.0/24，没有划 VLAN。

设备清单大致是这样。

主路由用爱快，地址 192.168.31.1，负责出口和 DHCP
生产 NAS 是群晖 N100，地址 .2，装了 10 个 Docker，跑笔记、相册、下载、监控这些每天都要用的服务，同时开了两个虚拟机，一个跑OpenWrt，地址 .8，负责代理分流，另一个跑雷池 SafeLine 的 WAF，地址 .32，管着 10 个站点、56 条策略。
PVE 宿主机地址 .3，J4125 处理器，16G 内存，上面三台虚拟机
- VM100 是openclaw，地址 .25
- VM101 是黑群晖冷备机，地址 .6，2T 硬盘直通，只在周六开机
- VM102 是个hermes，地址 .42，接飞书做消息推送和定时任务

对外通道有两条。公网访问走 Cloudflare，经过隧道落到 WAF，再由 WAF 反代到内网服务。外网访问 NAS 走自建 Tailscale用于drive文件同步。所有设备保持同一个网段，这套思路的逻辑是不暴露端口，外网先到内网的WAF，再由WAF反代到各个应用。

四排查出的四个裸奔点

自以为安全的网络架构，排查完我记了四个点，每个单看都不致命，凑在一起就是一次扫描打穿全家。

第一处，WAF 和生产 NAS 在同一台物理机上。当时 WAF 跑在生产 NAS 的 VMM 虚拟机里，地址就是 .32。这意味着 WAF 一旦被打穿，攻击者已经在群晖的内存空间里了，等于门卫和保险箱住一间屋。

第二处，PVE 防火墙开了开关但没有规则。三台虚拟机的网卡都勾了 firewall=1，可 /etc/pve/firewall/ 目录下空空如也，一个规则文件都没有。开关是开的，过滤不存在。这就像每扇门都装了电子锁，锁里没有录入任何权限，谁推都能进。

第三处，IPv6 入站默认全放行。WAF 和自动化助手都是 Ubuntu，ip6tables 的 INPUT 策略是 ACCEPT。多数国内宽带场景下，设备会直接从运营商拿到公网可路由的 IPv6 地址，根本不经过 NAT。所以即便路由器上的端口转发列表干干净净，这两台机器的管理端口实际上裸挂在公网上。

第四处，冷备 NAS 没有任何隔离。所有内网设备都能访问它，它自己也能随便往外出。冷备机的意义在于和生产数据分开，如果它和别的设备处在同一个信任级别，那它只是一台多出来的硬盘，谈不上备份。

这四个点里最讽刺的一点是，PVE 的防火墙开关全都打开了。那三个 firewall=1 的勾选让我很长一段时间以为自己在安全上是有动作的。勾选只代表允许这套防火墙接管这块网卡的过滤，它不生成任何规则，默认行为也不是拒绝。

五四项加固

1 把 WAF 从生产 NAS 里搬出来

原 WAF 跑在群晖的 VMM 里，和全家最重要的数据共享同一台物理机、同一个电源。我把它搬到 PVE 上，将原来的的 VM100部署的openclaw删除，我重置成干净的 Ubuntu 22.04，把雷池 SafeLine 的 10 个站点、56 条策略、cloudflared 隧道和证书管理整套迁过去。

这里的关键技巧是让新机直接接管 .32 这个地址。做法是先改虚拟机的 MAC，再改 IP，让上游看起来还是同一台设备。这样群晖白名单、Cloudflare 云端 ingress、本地 DNS 全都不用动，停机窗口只有 5 到 10 分钟。

搬完之后 WAF 和生产 NAS 分在两台物理机上。WAF 再被打穿，攻击者手里只有 PVE 这一层，碰不到群晖里的数据。

2 把 PVE 防火墙从零规则补成显式隔离

三台虚拟机名义上开了防火墙，实际没有规则。我补了 cluster.fw 放管理机白名单，host.fw 管宿主策略，再按虚拟机分别写 100.fw、101.fw、102.fw。

WAF 这份规则的作用是，除了三台管理机能 SSH 进来，只放行 HTTPS，剩下的一律丢弃。这样 WAF 自己被打穿之后也没法横向扫描内网。

[RULES] # 三台管理机允许 SSH IN SSH(ACCEPT) -source 192.168.31.22 IN SSH(ACCEPT) -source 192.168.31.30 IN SSH(ACCEPT) -source 192.168.31.39 # 放行 HTTPS，供 Cloudflare 隧道回落 IN HTTPS(ACCEPT) # 其余入站与全部出站默认丢弃 IN DROP OUT DROP

规则文件有个坑我踩了。PVE 的 .fw 文件支持用 # 做整行注释和行尾注释，但不认 iptables 的 -comment 选项。我把 iptables 的习惯直接搬进去，带 -comment 的那一行会被解析器整行丢掉。早期那批规则看着写好了，实际上没生效。重写之后我从 WAF 机内用 nmap 扫 PVE 的 8006 和 22，确认连不上才算通过。

3 把冷备 NAS 锁成白名单模式

这一节是整个加固里我认为最值钱的一步。冷备机的默认策略改成全部拒绝，入站只留四条口子，三台管理机的 5000、5001 和 445，以及生产 NAS 写 Hyper Backup 用的 6281。

[RULES] # 三台管理机访问 DSM 与 SMB IN ACCEPT -source 192.168.31.22 -p tcp -dport 5000:5001 IN ACCEPT -source 192.168.31.22 -p tcp -dport 445 IN ACCEPT -source 192.168.31.30 -p tcp -dport 5000:5001 IN ACCEPT -source 192.168.31.30 -p tcp -dport 445 IN ACCEPT -source 192.168.31.39 -p tcp -dport 5000:5001 IN ACCEPT -source 192.168.31.39 -p tcp -dport 445 # 只允许生产 NAS 写入 Hyper Backup IN ACCEPT -source 192.168.31.2 -p tcp -dport 6281 # 出站只放 DNS 与 NTP OUT ACCEPT -p udp -dport 53 OUT ACCEPT -p udp -dport 123 IN DROP OUT DROP

出站只放这两个端口是有原因的。53 是 DNS，相当于地址簿，机器要把域名翻译成 IP 才走得通。123 是 NTP，相当于对表，保证备份文件的时间戳准确。除了这两件事，冷备机不允许访问互联网。它平时不需要连互联网，也不应该连。勒索软件进来之后普遍要做的一件事就是向外联回传，出站焊死，这条路就断了。

升级 DSM 的时候需要临时下载 .pat 文件、访问 RR 引导界面，我把这 8 条规则做成禁用预设。升级时勾选启用，升完立刻取消勾选，回到锁死状态。

4 封掉 IPv6 入站

这一步是最容易被忽略的。很多人以为端口转发里没配 IPv6 就安全。IPv6 压根不走端口转发，运营商给你的设备直接就是一个公网地址。

WAF 和自动化助手这两台 Ubuntu 当时都没启用 UFW，ip6tables 的 INPUT 默认策略是 ACCEPT。我写了个脚本，把默认策略改成 DROP，只放行回包、链路本地地址和 ICMPv6。

#!/bin/bash # /usr/local/sbin/ip6tables-drop.sh ip6tables -F INPUT ip6tables -P INPUT DROP ip6tables -P FORWARD DROP ip6tables -P OUTPUT ACCEPT ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT ip6tables -A INPUT -s fe80::/10 -j ACCEPT ip6tables -A INPUT -p ipv6-icmp -j ACCEPT

链路本地那段和 ICMPv6 不能删。删掉之后邻居发现会失效，同一网段的机器互相认不出来，网络看着通实际不通。

规则重启就没了，所以要做成 systemd 服务跟着开机跑。

# /etc/systemd/system/ip6tables-drop.service [Unit] Description=ip6tables default drop After=network.target [Service] Type=oneshot ExecStart=/usr/local/sbin/ip6tables-drop.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target

写完记得 daemon-reload 再 enable，然后从另一台机器扫一下这台机的 22 和 443，确认外网连不进来才算落地。

同时还在IKUAI主路由上设置了ACL规则

怎么确认这些规则真的生效了

配置写完不算完，得上机验证。我的验证方法是三条。

第一条，从 WAF 机内往 PVE 宿主机扫 8006 和 22，期望结果是全部过滤或超时，而不是连接被拒绝。连接被拒绝说明包到了宿主机，是服务自己关掉，规则没起作用的可能性很高。超时或丢弃才是防火墙上真的拦住了。

第二条，从管理机 .22 访问冷备 NAS 的 5000，应该能打开 DSM 登录页。换一台不在白名单里的机器再试同一个地址，应该连不上。两边结果不同，白名单模式才算成立。

第三条，用手机流量断开 Wi-Fi，直接访问家里的公网 IPv6 的 22 和 443，期望结果全部超时。这一条最容易被忘记，因为在家里内网怎么测都是通的。

六备份和证书那些坑

备份这块先澄清一个概念。PVE 的 vzdump 选快照模式，最终产出一个完整的独立压缩归档文件，可以拷到移动硬盘或者另一台 NAS 上。它借一个临时快照保证备份期间虚拟机继续跑，但出来的东西是全量的，不是只存变化的部分。

顺带说清三种常见的假备份，这几种我在别人家里都见过。第一种是 RAID。RAID 解决硬盘坏了怎么办，它让一份数据同时存在多块盘上。勒索软件加密的是文件，一块盘上的文件被加密，镜像的那几块同步变成加密后的样子，RAID 整个过程忠实地把破坏复制了一遍。

第二种是同机 Hyper Backup。备份任务指向同一台 NAS 的另一个存储池，看着很专业。两份数据仍处在同一套系统、同一组账号权限之下，攻击者拿到管理员权限之后遍历目录，两个存储池一起加密。

第三种是常插着的外挂硬盘。自动备份确实方便，但那块盘一直挂着就一直是可写状态。加密程序跑起来的时候它和普通目录没有区别，一起被处理。

真正管用的是第四种，另一台机器，或者一块平时不插电的硬盘。数据到了物理上碰不到的地方，勒索软件才真的够不着。

备份圈有个 3-2-1 的说法，三份副本、两种不同介质、一份离线。我现在的状态勉强够上这个框架，vzdump 归档算一份，移动硬盘离线拷贝算第二份介质，冷备机算另一个场点。放到勒索这件事上看，第三份才是决定性的，前两份在那台机器活着的时候都可能一起被加密。

还有一件事恢复演练。备份文件存在不等于能还原，这是两个独立的问题。我打算挑个周末在 PVE 上新建一台空虚拟机，把那个 2.17GB 的归档还原到新磁盘上，看能不能正常起来进登录界面。演练必须在孤立环境里做，不能覆盖生产，否则演练本身就成了事故。

七外网访问

外网访问走自建 Tailscale，控制面 Headscale，中继 DERP 自己也搭了一套。客户端直接装在 NAS 上，手机和电脑靠它做文件同步。

这套方案的好处很直接，生产 NAS 在路由器上不需要映射任何入站端口。公网 IP 的 5000 和 5001 从外面根本访问不到，手机连 NAS 走的是加密隧道。安全模型从「开一扇门然后守着」变成「不开门，走地下通道」。

Tailscale 我装在 NAS 里，没装在路由器上。这样路由器重启或者换固件都不会动到隧道的密钥和策略，出一台设备的故障只影响那一台。代价是每台要用隧道的设备都得单独装客户端。

外网访问的另一半是 Cloudflare 那条链路。公网请求先到 Cloudflare，再通过隧道回到 WAF，WAF 验完规则才把流量转给内网服务。这条链路的安全靠三点撑着。Cloudflare 侧不放开任何源站端口，流量只从隧道出去，第二点设置常用域名仅限国内IP访问，WAF 侧那 56 条策略之外，默认动作是拦截。

这两层叠起来的效果是，即便哪天 WAF 自己出了配置漏洞，攻击者要拿到内网直连路径还是得先过 Cloudflare 那道门。我在 WAF 规则里把 WAF 访问 PVE 宿主机管理面的 8006、22、3128 全部禁掉，也是同一个思路。拿不到管理面，攻陷一台 Web 反代和拿到整台宿主机是两件难度差很远的事。