国民NAS 飞牛零日漏洞之后：我们需要什么样的 NAS ？

前些日子被飞牛刷屏了，因为他们的零日漏洞。对于这种事我并不意外，这种“某个厂商又被爆出高危漏洞”的新闻，在过去几年里已经见过太多次了。威联通被勒索软件批量打过，群晖也出过远程代码执行的高危洞，甚至于阿里云盘也有照片“串号”的问题。只是平时刷到这类消息的时候，大多数人都会下意识地划过去，觉得这更多是厂商的锅，恰好我们没有用这个产品，或者没有被攻击过。直到这次轮到飞牛，论坛里有人说“已经被扫到”“后台被进过”“文件目录被翻过”，甚至资料被公开售卖，我甚至想说，我只想安安静静地存个东西就那么难吗。

但是感慨的原因，并不在于某一个厂商被爆出漏洞，而在于我们一直默认家用 NAS 是一类“相对安全的设备”，但现实并不完全是这样。当我们做内网穿透、端口转发的时候，运营商会禁止我们对外提供服务，这么看来倒是一种保护了。在漫长的斗智斗勇过程中，我们也学到了不少专业知识，但如果非要用数据泄露来交学费，那实在是太过惨痛了。

先说清楚，这篇文章无意针对飞牛以及其他厂家，我也是飞牛，群晖和威联通的忠实用户。他们能在市场上有这么多用户量，靠的是真本事，这一点谁都没法否认。
但这次漏洞事件暴露出来的东西，不是换个品牌、打个补丁就能翻篇的。它让我开始琢磨一个更根本的问题：我们玩了这么多年的家用 NAS，这套远程访问的路子，是不是从架构上就有一道天花板在那摆着？

如果把情绪抽离掉，从工程视角来看，飞牛这次零日漏洞暴露出来的问题其实很清晰。攻击路径并不是“有人猜中了你的账号密码”，也不是“你没开双因素认证”。根据已公开的信息，这次事件中至少涉及一个 CVSS 评分 9.8 的严重目录遍历漏洞（CVE-2025-0510），攻击者无需任何认证即可从OS中获取敏感信息，执行任意脚本，完成从“数据窃取”到“完全控制”的整条攻击链。

从飞牛论坛用户的清理反馈来看，攻击者的持久化手段相当专业：修改系统启动脚本（system_startup.sh）植入恶意代码，加载恶意内核模块隐藏进程，给恶意文件设置 immutable 属性防止删除，甚至篡改 DNS 设置将 OTA 升级域名指向无效地址，让设备无法自动更新补丁。
有用户反馈恶意程序在凌晨三点定时激活，每隔一小时执行一次，反复清理三天才最终平息。飞牛官方虽然紧急发布了 fnOS 1.1.15 和 1.1.18 安全补丁，但对于那些已经被植入内核级后门的设备来说，补丁来得再快也已经晚了——因为攻击者早就把升级通道堵死了。
这不是飞牛独有的问题。SQL 注入是 OWASP Top 10 里最经典的漏洞类型之一，它出现在一个已经上市的 NAS 产品中，恰恰说明了一个残酷的现实：NAS 厂商的安全开发水平参差不齐，而用户对此几乎没有任何鉴别能力。放在任何一家做 NAS 的厂商身上，本质都是同一个模型下的必然风险。

我跟很多人的第一反应一样：后台开了 MFA，SSH 加了密钥认证，密码也够复杂，应该没事吧？

但这次事件让我不得不面对一个很残酷的事实：这些防护手段，防的是“有人试图登录你的账号”，而不是“有人绕过登录直接打穿你的服务”。零日漏洞的可怕之处恰恰在于，它往往发生在认证流程之外。攻击者不需要知道你的密码，不需要通过你的 MFA，他直接请求一个有漏洞的接口，就能拿到系统权限。你精心配置的那些安全措施，在这条攻击路径上根本没有出场的机会。

就像你给大门装了三道锁，但小偷是从窗户翻进来的。

这件事真正让我警醒的，是它逼我重新审视“家用 NAS 到底是什么”这个问题。我们习惯把 NAS 当成一个“带点智能的网盘”，买回来插上硬盘，装几个套件，配好远程访问，就觉得万事大吉了。

但从技术结构上看，它更像是一台长期在线的小服务器：有 Web 管理后台，有文件服务接口，有各种插件和后台服务在跑，有远程访问需求，有公网可达入口。换句话说，它具备了服务器的全部攻击面，却经常被用户用消费电子的心态来对待。我们会很自然地为了方便打开端口映射、配置 DDNS，让设备可以随时在外网访问，却很少有人真正意识到：这相当于把一台服务复杂、补丁节奏完全依赖厂商的服务器，直接放在了公网边缘，24 小时不间断地接受全球扫描器的“体检”。

飞牛的零日漏洞，其实只是把这个结构性问题放大到了所有人眼前。

我后来花了不少时间去想一个问题：为什么 NAS 的安全事故总是以这种方式发生？不是用户密码太弱，不是配置太离谱，而是厂商的某个服务组件出了洞，然后大量暴露在公网的设备被批量扫描、批量利用。

想来想去，答案其实很简单——因为传统 NAS 的远程访问模型，从根子上就是“让公网能直接打到你家设备”。无论你是通过端口映射、DDNS，还是厂商提供的云中转服务，最终都意味着你的管理面或服务面在公网有一个可被发现的入口。这个模型在便利性上没问题，但安全性完全依赖两个前提：厂商永远不出漏洞，以及用户永远配置正确。而这两个前提，在现实中从来没有同时成立过。

做过安全的人都知道一个很朴素的原则：缩小攻击面，永远优先于修补漏洞。与其指望“厂商永不出洞”，不如从架构上减少公网暴露。如果攻击者连你的设备都扫不到，那么即使系统里存在未知漏洞，被利用的概率也会断崖式下降。这不是什么高深的安全理论，这是安全工程的第一课。但遗憾的是，绝大多数消费级 NAS 的产品设计，并没有把这个原则放在优先位置。它们更关心的是“用户能不能方便地远程访问”，而不是“这种访问方式是否在架构上足够安全”。

也正因为这样，我后来开始反思一个更根本的问题：是不是我们一开始就选错了“家用私有云”的技术路线？传统 NAS 的远程访问模型，本质上是假设“公网直连 + 用户自行加固”，这在早期小规模使用时尚且可控，但随着 NAS 功能越来越复杂、用户群体越来越非技术化，这种模型注定会不断放大安全风险。它把服务器级别的安全责任，转嫁给了普通家庭用户，而这本身就是一个不太合理的设计前提。你不能一边把产品卖给“想要一个家庭网盘”的普通人，一边要求他们具备运维一台公网服务器的安全能力。

想清楚这一点之后，我重新选方案的第一标准就变了：不是功能多不多，不是品牌响不响，而是——公网能不能扫到我。在这个标准下，任何能做到“默认不暴露公网”的方案，都比传统 NAS 架构更符合我的安全预期。

后来接触到懒猫微服的时候，说实话我一开始是带着怀疑态度的。市面上打着“私有云”旗号的产品太多了，很多不过是换了个壳的 NAS。但真正让我停下来认真看的，是它的整体架构设计思路。

根据懒猫微服官方开发者文档的描述，懒猫微服的系统分为三层架构：最底层是一个极度精简的底层系统，只负责网络连接、安全认证，以及业务操作系统的启动和更新，目标是保证不管怎么升级，系统永远不会挂；中间层是业务操作系统，负责网络隔离、应用调度、资源管理；最上层是 LPK 应用层，这是懒猫自己的容器格式，官方强调这种容器格式在权限隔离与运行时控制上的安全边界更可控，并计划逐步补充网络流量审计、网络限制和用户权限控制等能力，用来尽量降低应用层对系统整体安全的影响。这种分层设计的好处很直观：底层保证稳定性，中间层保证隔离性，应用层尽量把风险限制在可控范围内，不会因为某一层出问题就牵连整个系统。

但真正让我觉得这个产品在安全思路上跟传统 NAS 拉开差距的，是它的网络传输机制。懒猫微服的远程访问分为两种模式：当终端设备所在网络具备 IPv6 或 NAT3 条件时，系统会自动与用户设备建立直连传输；当网络环境较差时，系统会自动切换到中继数据传输服务。关键在于，无论哪种模式，数据传输都采用端到端加密技术，传输内容对包括平台运营团队在内的任何第三方均不可见。而且这个穿透服务属于系统网络层能力，所有应用——包括官方应用、开发者自主开发的应用、甚至开发者搭建的虚拟机——都自动受益，不需要用户为每个服务单独配置网络穿透规则。

这意味着什么？意味着你不需要在路由器上开端口映射，不需要配置 DDNS，不需要自己搭建穿透机制或反向代理。设备是主动向外建立加密通道的，公网扫描器看到你家的公网 IP，也发现不了任何可直接访问的服务入口。这从根本上改变了攻击面模型：传统 NAS 是“我把服务摆在公网等你来连”，懒猫微服更像是“我主动出去建立连接，但外面的人看不到我”。对于这类零日漏洞的攻击场景——攻击者批量扫描公网 IP、发现暴露的管理接口、利用漏洞打进去——在这种架构下，第一步就很难成立，因为根本没有暴露在公网的入口可以被扫描到。

当然，这种“默认不暴露公网、依赖穿透与中继”的模型也不是没有代价：它对平台控制平面的稳定性依赖更强，也意味着用户在一定程度上需要信任厂商的网络基础设施能力。安全复杂度从用户侧转移到了平台侧，这对厂商自身的安全工程能力提出了更高要求。一旦平台侧出现故障，设备本身是安全的，但远程访问体验可能会受到影响，这是这种模型天然需要承担的代价。而且作为一个相对年轻的产品，它的生态成熟度跟老牌 NAS 厂商相比还有差距，自研的容器格式也需要更长时间的社区检验。这些都是选择这种架构路线之前必须接受的现实成本。

懒猫微服的理念文档里有一段话让我印象很深。它的创始人做了二十多年开源社区，他观察到的一个长期问题是：当个人数据逐步被公有云化之后，商业模式往往会不可避免地走向基于数据的变现逻辑。懒猫微服希望通过私有硬件把个人数据重新放回用户手里。这句话本身听起来像口号，但如果从产品架构反推，这确实是它很多设计选择背后的出发点——例如默认不暴露公网入口、强调端到端加密、尽量减少对第三方的信任假设。当一个产品从理念层面就把“数据尽量掌握在用户自己手里”当成优先目标，它在安全设计上的取舍，确实会和那些更偏向功能堆叠的产品不太一样。

从工程实现的角度看，懒猫微服更像是在家庭场景下尝试零信任网络的落地：默认不信任公网，默认不暴露服务，通过身份认证与加密通道来建立访问路径。它并不能保证系统永远没有漏洞——没有任何系统能做到这一点——但它把风险从“公网随意可达、被扫到就可能被打穿”，压缩到了“必须先突破身份体系和加密隧道”的范围内，攻击成本的量级明显不在一个级别上。

硬件层面的事情也值得单独提一下，因为很多人忽略了一个事实：安全能力本身是吃资源的。端到端加密、容器隔离、服务沙箱、AI 本地索引，这些能力全部打开之后，对 CPU 和内存的消耗是实打实存在的。很多入门级 NAS 为了控制成本，硬件资源本身就偏紧张，用户为了“用得顺”，最后只能关掉一部分功能，甚至包括一些安全相关的能力。懒猫的硬件定位更偏向“家庭私有云工作站”，整体资源相对充裕一些，所以在实践中更容易做到“该开的安全能力不需要为了性能被迫关闭”。这一点对安全体验的影响，其实比参数表本身更重要。

还有一点我觉得值得单独说的，是这个团队给人的感觉。

用过 NAS 的人大概都有过类似体验：遇到问题去官方论坛发帖，要么石沉大海，要么收到比较模板化的回复，很难确认对面是否真正理解你的具体场景。

懒猫这边给我的感受完全不一样。他们的一线技术支持是真正懂 Linux 的工程师在做，不是外包给念话术脚本的客服。你提一个问题，回你的人可能就是写那段代码的人，给出的不是套话，而是具体的排查思路或实现路径。用他们自己的话说，逻辑其实很简单：我们是最会玩 Linux 的那批人，你要的我们都有，花钱支持我们的客户，我们就实时响应。这种态度在国内硬件厂商里不多见，对我这种爱折腾的人来说，这种沟通方式本身就是产品体验的一部分。

实际使用下来也确实如此。懒猫有自己的用户论坛，也有比较活跃的社群，用户反馈的问题经常能看到开发团队跟进。社区里有一个长期存在的主题是“说出你的需求，我们来移植”，开发者会协助把用户常用的自托管应用移植到他们的应用体系里。官方还提供了一些社区激励机制，鼓励开发者参与生态建设。这些机制本身并不决定产品好坏，但它们让生态的扩展变成了一种可持续的系统行为，而不是完全依赖官方单点投入。

我在论坛上写了 80 多篇懒猫微服的实战连载，从开箱到进阶到炫技，写着写着就停不下来了。推荐你在论坛的攻略里感受到我折腾这台机器的状态：《懒猫智慧屏，我以为是地表最强电视盒子，结果竟然可以改装成闺蜜机？》《用懒猫微服倒推停电时间》《sunshine+moonlight 双人串流打游戏》《蓝牙音浪，懒猫开唱》《西湖邂逅后，我手把手教她玩转 NAS》《坏掉的 Windows 不要扔，硬盘插在懒猫上还能用》《服务器宕机之后，我和前端靠懒猫微服结对编程》。这些都是我在真实场景里折腾出来的记录。写着写着发现社区里其他人也在这么玩：有人用它存 Steam 游戏，有人用它替代 1Password 订阅，有人用它给大疆 Pocket3 导素材，有人用它做 24×7 在线开发机，有人用它的穿透服务让车机远程听黑群晖的歌。这些用法本身说明的不是“产品多强”，而是这种架构在家庭场景下确实覆盖了一些真实需求。如果你恰好是开发者，参与应用移植的过程本身也是学习——Docker 实践、npm 构建这些东西，社区里的工程师会直接带着你走一遍，至少在某个深夜，帮我解答了 docker 的 bind mount 和 volume 的异同和场景对比。

说回我自己现在的方案。折腾了这么一圈之后，我最终把家里的存储和服务迁到了懒猫微服上。不是因为它完美，而是因为它的安全模型让我第一次觉得“在远程访问这件事上不用操心”。不用开端口，不用配 DDNS，不用自己搭反向代理，也不用担心哪天又爆出一个新的零日漏洞就得手忙脚乱地去堵洞——因为公网本身看不到我的设备。端到端加密是默认开启的，平台侧也无法看到你的数据内容。三层系统架构把底层稳定性、业务隔离和应用安全分得比较清楚，不至于因为装了一个有问题的应用就牵连整个系统。

对我个人而言，权衡之后答案很明确：我宁可接受“平台偶尔不稳定”带来的体验波动，也不太愿意继续承担“设备 24 小时暴露在公网”这种结构性风险。前者更多是体验问题，后者本质上是安全问题，两者的风险量级并不在一个维度上。

如果一定要给这次零日漏洞事件一个更有价值的意义，那可能不是提醒我们“哪个厂商不安全”，而是提醒我们：家用 NAS 这条路，本身就存在一个被长期忽视的安全天花板。这个天花板不是靠换品牌能突破的，也不是靠多加几层认证能突破的，它是由“公网暴露”这个基本架构决定的。

这大概是这次事件教给我的最重要一课：安全这件事，靠补洞永远是被动的，靠架构才是主动的。选 NAS 不是在选品牌，而是在选默认风险模型。