一次未公开披露的重大安全漏洞修复事件，意外揭示了NAS用户自主构建纵深防御体系的可行性。通过WAF流量劫持与iptables规则配置，普通用户也能在官方响应滞后时主动加固远程访问链路。
智能速览
飞牛OS v1.1.18已静默修复FN Connect路径穿越0day漏洞，但未发布安全通告
漏洞成因在于FN Connect自动发现WebUI端口（5666/5667/8000/8001）且缺乏访问控制，易被关键词枚举利用
实测雷池WAF 9.3.2个人版在高强度防护模式下可100%拦截路径穿越攻击
通过iptables OUTPUT链将5666端口流量重定向至WAF监听端口（如8182），实现中间防护层
配置需使用局域网IP而非localhost作为上游服务器，否则FN Connect连接失败
安全加固后仍存在未知风险点，如FN Connect是否调用其他未覆盖端口尚无验证
精华内容
当厂商修复漏洞却不通知用户，安全责任就部分转移到使用者身上。这次实践表明，借助开源WAF与系统级流量调度，家庭NAS用户完全能建立可落地的主动防御机制。
漏洞本质
FN Connect设计缺陷在于其自动探测并转发本地WebUI端口（默认5666、5667，部分含8000/8001）的行为不可控。攻击者通过枚举常见子域名（nas、mynas、fn-nas等）+路径穿越payload，可绕过认证直接访问后台。实测中，未升级v1.1.18的设备对/fn/webui/…/…/etc/passwd类请求返回200，证实漏洞真实存在且可利用。
WAF部署验证
雷池WAF 9.3.2个人版在平衡模式下不拦截路径穿越，但在高强度防护模式下触发语义分析模块，对/fn/webui/…%2f…%2fetc%2fpasswd等变体请求均返回403，拦截成功率100%。日志显示，攻击流量经8182端口进入后，在WAF层被阻断，未到达NAS WebUI。对比测试中，相同攻击向量直连5666端口则成功返回敏感文件内容。
流量劫持实现
关键操作是通过iptables OUTPUT链重定向：执行iptables -t nat -A OUTPUT -p tcp --dport 5666 -j REDIRECT --to-ports 8182后，FN Connect发起的本地5666请求被强制转向WAF。验证命令iptables -t nat -L OUTPUT -n -v显示tcp dpt:5666 redir ports 8182即生效。必须配合iptables-persistent保存规则，否则重启失效。IPv6需同步配置ip6tables规则，否则存在绕过风险。
配置注意事项
上游服务器必须填写NAS局域网IP（如192.168.1.100），禁用localhost或127.0.0.1——实测填入后者会导致FN Connect连接超时。身份认证模块开启后，所有FN Connect访问需先通过WAF鉴权页，路径穿越攻击失去入口。但测试发现，若同时转发5667端口，FN Connect客户端会因协议异常断连，故当前方案仅适配5666主WebUI端口。
这次事件的价值不仅在于漏洞本身，更在于它推动普通用户从被动等待补丁转向主动构建防护能力。当厂商信息披露缺位时，技术可行的自保方案就成为刚需。未来是否会出现更轻量的容器化WAF集成方案？或者飞牛能否开放FN Connect的端口白名单控制？这些都值得持续观察。
关键评论
v1.1.18升级后实测路径穿越请求返回404，确认Nginx层已拦截，但自组网用户因不暴露公网影响有限
用雷池代理飞牛APP后无法登录，说明FN Connect客户端与WAF存在协议兼容性问题，需厂商协同优化
小白用户直接暴露公网分享学习资料等于违法，安全加固不能替代基础合规意识
