为查硬盘温度打开日志，我发现NAS被撞库40小时

本来只想看一眼硬盘温度。听说温度每升高10°C，硬盘故障概率大约增加23%，于是我打开群晖DS1621xs+上的DSM，准备检查风扇。顺手点开日志中心之后，风扇成了最不重要的事。

有人已经连续近两天、每隔10到40秒尝试登录这台NAS。没有一次成功，但这些请求根本不该到达设备。我的家庭实验室放在CGNAT后面（至少我以为如此），远程访问交给Tailscale处理，NAS上该查的安全设置也查过。问题出在我自己搭的、后来忘掉的一个东西上。

日志中心里的40小时

轮换的IP地址每隔10到40秒换一个用户名，每一次尝试都失败。日志中心的“连接”分类是一整面警告墙，每条都是同一句话换了几个空：“用户[admin]从[IP]通过[密码]登录[DSM]失败，原因是授权失败。”接着是administrator、marketing、muhasebe（土耳其语里的“会计”），然后是一串名字：melvin、charlene、marcelo。日志里没有一条试过我真正的用户名，这也是我事后还能笑出来的唯一原因。

按NAS时钟，第一次尝试落在9月26日20:38:04。那台机器的时区被设成波哥大且不启用夏令时，实际是东部时间21:38，修正它成了清单上又一件小事。最后一次尝试出现在9月28日下午3:17，从第一次到最后一次大约42小时。

撞库是概率游戏，NAS登录页是软目标

撞库就是把用户名和密码往登录页上砸，直到有一组对上，用的通常是其他泄露事件里流出的组合。严格说，轮换admin、marketing这类通用名更接近密码喷洒，但打法和工具是一样的。机器人不会累，也不在乎目标是银行还是别人柜子里的机器。

NAS之所以值得下手，是因为它通常装着主人最在意的一切。进了DSM，就拿到了文件、备份，往往还能借道进入网络里的其他设备。

那个被遗忘的端口转发

我第一个怀疑对象是QuickConnect——当无法直连NAS时，它可以经群晖服务器中转，所以CGNAT拦不住它。我关掉它，盯着日志中心，尝试还在继续。eero上的UPnP本来就是关的，DSM的路由器配置页面里也没有规则，所以也不是它。

于是我确认自己到底是不是在CGNAT后面。桌面端一条命令就能定论：curl -4 ifconfig.me。返回的地址和eero报告的WAN IP一致，且不在CGNAT使用的100.64.0.0/10范围内，说明中间没有任何地址转换。接着我关掉手机Wi-Fi，用LTE加载那个地址，应答的是一个nginx错误页：“400 Bad Request。明文HTTP请求被发往了HTTPS端口。”那是DSM自己的Web服务器，也就是说我的NAS在跟互联网对话。

洞藏在eero应用里，塞在NAS的地址保留项中。它转发80端口，是我为一次临时的nginx测试装的，只为验证一件完全不相干的事。测试早就没了，转发还在。

我无意中给NAS开了道防火墙口子，然后忘得一干二净。从局域网访问NAS的80端口，DSM会直接把你弹到登录页。所以nginx测试消失之后，守在那个转发后面的就是DSM，日志中心里的登录尝试说明机器人找到了它。我在下午3:16左右删掉转发，最后一次失败尝试出现在3:17。

当时DSM还挂着一张不正确的自签名证书。那能吓退浏览器前的人，但机器人不在乎证书警告，所以它没帮我挡下任何东西。

我以为自己在CGNAT后面，我错了

我的eero直接插在Verizon Fios的ONT上，前面没有别的路由器。公网地址由eero自己持有，这意味着eero上任何转发都直通互联网。CGNAT会静默阻断对家庭服务器的入站连接，在它后面，那个旧的80端口转发指向的是一片不可达的空处。而有了真实的公网IPv4地址，它就是一道活的门。

我不知道这条线路具体什么时候不再处于CGNAT之后。但扫描器扫互联网很快：Unit 42的一项蜜罐研究里，320个暴露的蜜罐有80%在24小时内被攻陷，全部在一周内沦陷。那项研究覆盖的是SSH、RDP这类服务，不是DSM登录页，所以它无法给我的切换时间定日期。不过我最合理的猜测是，变化发生在9月26日之前不久，而不是几周之前。日志中心没有攻击开始之前的历史记录，我无法证明任何一种可能。

为什么DSM的自动封锁一个都没拦住

DSM的自动封锁全程开着，基本没起作用。按群晖文档，它在某个IP于设定分钟数内超过设定失败次数后封锁该IP。对付一个闷头猛砸的地址很有效。

这次攻击不是那个打法。在一个六分钟的样本里，来自四个网段的14个地址轮流上阵，每一个大概都停在阈值之下。群晖也说明，自动封锁会忽略每个IP最初的几次失败尝试。自动封锁值得继续开着，但它不是分布式攻击的防线，这次也没救到我。真正管用的是把路封掉。

之后我怎么锁上这台NAS

转发删掉后，我让QuickConnect保持关闭，并打开了DSM防火墙。我设了两条允许规则，一条给我的局域网网段，一条给Tailscale的100.64.0.0/10网段，其余全部设为拒绝访问。整套设置就这些，但花掉的时间还是比我预想的多。

群晖没把这件事做简单。规则藏在配置文件里，只能通过“编辑规则”按钮进入，而且不点“应用”就不生效，这一点很容易漏掉。设完用手机LTE测一遍，确认登录页会超时。

双因素认证一直是真正的兜底。好消息是，我的群晖账号和DSM账号本来就都开了2FA。我看过的每一次尝试都止步于密码阶段，第二因素根本没轮到出场。但如果哪个机器人猜中了密码，它仍会撞上一道过不去的提示。

有个小插曲：我在局域网登录时勾过“不再询问”，听起来像是削弱了防护。其实没有，因为群晖的2FA文档写明，记住的设备只在同一账号、同一浏览器登录时才作数。

在运营商替你改之前，先去看端口转发

吓人的不是我NAS被攻击这件事，而是我没碰过那个转发，它却在我这条线路不再处于CGNAT之后自己醒了过来。一条我认定无害的规则，在没有任何警告的情况下变成了一个活的登录页。

所以今天就去翻一遍路由器的端口转发，包括像我这样藏在设备地址保留项里的那些。然后用手机LTE查一下公网IP，确认没有任何东西应答。如果你需要从外面访问NAS，用Tailscale替代QuickConnect，就能在不暴露任何端口的情况下到达。