受到了飞牛漏洞的影响，大家对安全重视起来了，这确实是一件好的事情，并且各种安全软件以及方式大家也都在探讨，积极性很大。
1、哪种情况我需要额外保护飞牛NAS？
省流：暴露公网！
解：这点相信大家都知道了，一旦将你的飞牛暴露在公网环境（指将飞牛任意一个服务端**露公网）那就存在一定的安全风险，因为NAS存放了你的资料和身份信息，这在公网环境是有非常大的磁性，加持IPV4的地址特性，任何人都可以轻轻松松编写一个脚本遍历出所有IPV4地址，外加每个IP端口都是固定的1-65535，又可以实现针对每个IP端口的扫描，比较著名的22端口是全球脚本的扫描大户，但凡你将任何SSH协议暴露到了端口（这里指不光22端口）就会面临密码暴力破解。密码这个东西是百分百是能破解出来的，他只是一个时间和概率的问题，一个强大的密码也只是理论上需要几光年的时间，但是一个弱的密码，甚至不到24小时就能破解出来。 这里为什么说强大密码是理论，因为密码的组成也是受限的，可能会有亿万分一的概率被碰撞出来，所以基于密码进行单一验证的方式它本身就不是很可靠！只是一个很强大的密码他被碰撞出来的概率也只是无限接近于0。
没有暴露公网，就一定安全吗？
省流：会安全很多，但并不一定。
解：虽然你没有暴露公网，这确实创造出来了类似于隔离了世界独属于你自己的空间，但是我相信你在这个空间里肯定需要跑出去吧（这里指的是局域网内有其他设备连接外网）。
比如你局域网内某些设备暴露在公网，但是这个设备由于设计缺陷被攻破之后，因为都在一个局域网内，它可以实现攻击你局域网内的设备，这个时候就搭建出来了一个攻击桥梁，所以你的飞牛NAS再次可能面临沦陷！
小结
所以综上所述，我们可以发现只要联网的设备他都不是一定的安全。那我们该怎么办呢？
2.1、保护飞牛NAS
所以大家只要搞清楚，你的设备只要联网他都不安全的原因，那么应对的方式其实是非常多的。以下是针对需要外网访问用户，如果你没有这个需求，那你的nas纯局域网可以忽略第二章了
2.2用的时候联网，不用的时候断网
光听标题可能会有点智*** 但是，这个做法是对的，我们可以在这个基础上进行优化一下，不需要真的说每次用的时候联网，这确实真的很麻烦，而且也反古了。。。
一、隔离环境（分离式架构）
既然直接暴露不行，断网不方便。但是我就是想既要又要！没问题！前提是你肯折腾。。。比如你搭建两个飞牛NAS，一个跑在局域网，他不连接任何局域网，路由器阻止让他进出流量，只允许局域网流量，这个NAS存放个人重要资料和身份信息照片等。另一个跑在公网环境，用于存放一些日常软件和日常用到的一些不重要的文件、临时文件，专门对外访问的；
评价：这个方法我个人感觉要看你的需求，因为这个方法实行起来需你对网络做架构，比较适合企业环境，个人成本还是有一点高，但是安全性是非常高的，也不依赖安全软件。
二、搭建虚拟局域网（V*N）
这个标题我觉得应当懂得都懂，当然不是那个V*N啊，不是🪜啊。既然物理分割对于个人成本太高了，那么结合原理我们可以进化一下
首先这个东西它本身就是合法的也是企业环境的标配，也算是将公网和局域网进行了隔离，只是在中间搭建了一个桥梁而这个桥梁多了一个身份认证关卡，所有局域网的流量进出都需要经过认证，注意这里是包含出去的流量。
v p n 作为一个桥梁它本身是需要暴露在公网环境下，所以选择一个安全性高的 v p n就非常重要
我个人比较推荐的 wireguard 就是开源安全的一款 “桥梁”他的部署非常简单，并且支持全部客户端（安卓 苹果 Windows），社区庞大。
这里先给大家一个官方文档，后续我会编写一个搭建教程，当然他很简单，所以大家也可以找一下现成的教程
Installation - WireGuard
还有目前比较火的 EasyTier - 简单、安全、去中心化的异地组网方案 也是不错的 本质也是搭建了一个虚拟局域网，只是利用了P2P特性这个桥梁不再必须要在公网的服务器上，安全性有一定的提升，会更适合作为NAS的场景。
三、使用WAF（如雷池）
这个方法其实属于是一个简单粗暴的方法，你说他有没有用？他真的有用！
但是我也可以说他没用。。。为什么？
因为WAF本身作为一个软件的存在，他的安全性完全取决于这个WAF的规则，它本身不可能是一定安全能防住的，只能说这次的飞牛漏洞他真就防住了，但是未来呢？病毒是不断进化的，这一点WAF需要做到云数据库之类的功能能够实时更新防御政策，才能实现比较好的效果，而且这也非常考验这款WAF的质量，我个人认为雷池WAF是比较信得过的，大家可以查一下这个公司的背景，我感觉不亚于360了，长亭还是非常有名，在国际比赛都是有奖项的。（最早年的时候虚拟机穿透实验好像就是这家公司，不确定。
WAF这个方案是目前比较火的，我自己也在用这种方式，因为WAF作为软件他的部署极为简单，所以诞生了一些基于这个原理的软件，但是他的安全性真的及格吗？？
3. 简单审计最近热度很高的一个waf
这个软件实际上是开源的，基于他的代码我使用地表最强的Claude Opus4.6基于您开源仓库代码进行了深度分析出了几个高危漏洞，如果作者看到最好确认一下，如果存在就及时修复。
一、备份归档使用硬编码密码
备份 ZIP 归档的加密密码被硬编码在源代码中。任何能够获得源码或二进制文件的攻击者都可以解密备份文件。备份文件中包含完整的 Redis 数据库转储（含所有配置、会话、密钥、TOTP secret、Passkey 凭据等敏感数据）。
影响:
- 攻击者获取备份文件后可解密出所有敏感数据
- 可恢复管理员 TOTP/Passkey 凭据、所有会话 token
- 可获取 ACME 证书 DNS API 凭据（如 Cloudflare API Key）
我的评价：当我第一次看到这个分析的时候实际上我赶到不意外，毕竟现在是AI盛行的时代，提示词和Code Review还是需要优化和下一点功夫的。
二、SSRF 风险 — fetchUrlMetadata 可请求内部网络
normalizeHttpUrl 仅校验了协议为 http/https，但未禁止对内部网络地址（127.0.0.1、10.x.x.x、192.168.x.x、169.254.169.254 等）的请求。管理员通过 API 设置代理映射目标时可触发对任意内网服务的探测。
此外，fetchFaviconAsDataUrl 也会对解析出的 favicon URL 发起请求，增加了 SSRF 攻击面。
影响:
- 探测内网服务端口和元信息
- 通过
169.254.169.254 访问云实例元数据服务
- 可能导致内网服务信息泄露
高危漏洞结合（备份文件可能被 SSRF 利用导出）
文件: maintenance-backup.ts
虽然备份导出 API 位于 HMAC 认证保护的管理路由下，但结合高危-1（硬编码密码）和高危-2（SSRF），如果备份文件被写入到 Web 可访问的路径，攻击者有可能通过路径推测获取备份文件。
以上只是两个高危漏洞，希望作者看到了还是尽快排查一下进行修复，其实还有几个中危漏洞。在这里我就不再说了。
对作者的一些话
其实作为一个安全工具，操作便捷和防御严密往往是需要权衡的。很多时候，用户觉得操作复杂的地方，恰恰是安全软件为了防御攻击而必须设置的关卡。
真正的防御逻辑，是把攻击者挡在门外，而不是为了方便自己，就把门虚掩着。如果一款安全软件连最基本的** 硬编码密码（导致备份数据可被轻易解密）这种低级错误都存在，那所谓的便捷，恐怕只是给黑客提供了便捷的后门吧。
建议多关注一下自己代码层面的安全审计
真正有技术含量的安全方案，会把自己的边界、前提、失效条件、适用场景讲清楚。
只有营销味很重的文案，才会把一个常规的访问控制设计包装成“零信任”“绝对安全”“比别人都强很多”。
技术不是靠形容词堆出来的。
——
Lucky Web 服务 - 通过网页认证提供比基本认证体验更好的验证防护 - 攻略分享 飞牛私有云论坛 fnOS
2026.3.31(11:50):
介于目前knock作者仍然没有意识到问题核心。
小白只觉得他功能强大，但是根本不知道他的代码全是AI写的情况下用非常傲慢的语气去公开贬低业内非常知名的lucky项目，且言论极具嘲讽和荒谬从而推销自己的产品。且我和lucky作者多次敦促fnknock作者尽早道歉并收回错误言论的情况下依旧我行我素，行为及其恶劣，我将把原图展示如下。
用fnknock的用户看来都是奔着配置简单对新人友好而来，这点我承认，既然大家都说比lucky简单，那看来应该是没错的。所以最终还是看自己需求和观点，以下只是我的观点，大家自行考虑。
简单的东西就一定可靠吗？
相反，程序如果想实现用户用起来简单势必会在代码中预设很多的操作，你可以理解为模板，当用户点击了之后就相当于执行了一系列的操作，但是这个操作你并不知道且无法控制，所以一旦出了问题或者想调整那么操作空间就很有限。如果你从头配置虽然门槛会高，但是整个流程都是在你手中的，而且调整空间也非常大，出了问题很好修改且容易举一反三，更加通用性。
2026-3-30 00:36:04
2026-3-31 11:59:35 楼主
