公网使用飞牛 nas 的一些安全使用小提示--感谢飞牛官方团队

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

请不要把任何和邀请码有关的内容发到 NAS 节点。

邀请码相关的内容请使用 /go/in 节点。

如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。

首先感谢飞牛官方的技术人员凌晨 2 点还在协助解决安全问题，用爱发电，真的很辛苦！！再次感谢
先说我的 nas 出现的问题：大约一周前不定时爆连接数指向一个 ip ，疑似被黑成肉鸡攻击某个站点
在群里讨论后客服积极的拉了技术群并安排了技术人员分析，由于攻击是随机时间的不好抓取，今晚 9 点正好复现，凌晨 2 点飞牛的技术人员完成了安全问题的解决。
在此也给公网使用飞牛的朋友们一些安全小意见以减少 nas 被入侵的安全风险：
web 不建议直接映射，建议使用 tailscale 等类似的组网隧道，最最安全！
如果一定要公网开放 web ，不建议使用 5666 http 的明文端口，安全人员反馈我收到的就是疑似中间人攻击，问题源自于 5666 的明文 http 注入。
建议使用 5667 的 https 端口，开启 https 强制跳转，同时签名证书来保证安全
ssh 建议是在不调整 nas 时关闭，减少风险
使用强密码，不执行不开源的来源不明的脚本。
再次感谢飞牛官方团队的技术支持，凌晨 2 点技术在线解决问题说实话真的让我很惊讶，再次感谢，也希望我的遭遇可以让其他有相同问题的朋友们可以参考

安全

飞牛

NAS

67 条回复 • 2026-01-31 15:24:56 +08:00

lyz2754509784

1 天前

附上代码
ss -tanp | awk -F'[",=]' '/users:\(\(/ {cnt[$2 ":" $6]++} END{for(i in cnt) print cnt[i], i}' | sort -nr

这样就可以看到是哪个进程在对外发包了----来自飞牛官方的技术人员

MiKing233

1 天前

2026 年了这不是常识吗, Web 服务不应允许明文 HTTP, 必须经由 TLS 加密...

pingdog

1 天前 via iPhone

…

以下疑问仅针对 OP 当前帖子的内容描述作出

常规 B/S 开发模型下，请求进入了 server/backend 不会将请求中继到公网，即使 backend 有向公网发出请求的行为，也是 hardcode 的地址，所以这个“不定时爆连接数指向一个 ip”是随机出现还是关联到某个服务。要是服务那是不是这段逻辑执行完没关闭 socket 就耗尽了。如果问题出在 server ，就类似前阵的 react2shell ，漏洞源于 react server component ，不过滤触发语句 http/https 一样打穿

wskymark

1 天前

凌晨 2 点！飞牛这公司卷成这样😢

yeh

1 天前

问题是，飞牛 drive 的端口，不就是 https 访问的端口吗？

不对外映射，难道走 fn connect ？

fn connect 的 199/年，上行也就 40m 啊

超过 40m 的宽带可多了，哪怕是舍得花 199/年，也不满足要求啊。

imlonghao

1 天前 via iPhone

将被入侵问题归因到中间人攻击那就是他们没有找到问题

MiKing233

1 天前

@yeh #5 走 fnconnect 也是 https 访问, 只不过用飞牛自己的域名, 别人知道了你的 ID 谁都能打开你的登陆界面

rockddd

1 天前

凌晨两点？没有买卖就没有伤害😑

susunus

1 天前

凌晨 2 点！好的以后不用飞牛了，避免同行因此加班

relife

1 天前

只开 ssh 公钥登录，然后用 ssh 反向代理端口访问也行

verygood

1 天前

看下来还是没找到根因

VVVYGD

1 天前

可以，飞牛。

mingtdlb

1 天前

你还是给飞牛当时处理的这帮人点两杯奶茶吧，礼轻情意重

fstab

1 天前

凌晨 2 点，说实话，
我是企业主，对于产品的服务还是挺满意的。
但是我是打工人，我只会站在打工人这边，哪怕是员工自愿加班，
或者初创公司员工持股，为了快速拿到融资或者变现而努力，但是我始终无法共情这个行为。

yanqiyu

1 天前

@pingdog 我理解是怀疑中间人拿到了密码，或者关键用户 token ，导致攻击者获得 webui 的管理员权限。然后进行的渗透。

但是说实话，正常情况下真的有这么多公网上的 MITM 吗？我其实更怀疑楼主的机器设置了弱密码被暴破了。

JqbR001

1 天前

完全不在公网访问 FN web

dushixiang

1 天前

中间人攻击？你用的哪家运营商的网络？我只见过中间人插入广告的，没见过中间人抓肉鸡的。
中间人攻击的含义是你和服务端直接的通信内容被中间人篡改了，例如你去请求某一个 http 的网页，他在中间插入了一段 js 来播放广告。
你现在说中间人攻击你的 NAS 变成肉鸡了，我只能怀疑是你得 NAS 会执行来自服务端的命令，然后这个命令被中间人篡改了，执行之后被黑客控制了。
----
所以我觉得是没找到原因，也不懂网络安全，随便找个理由糊弄你呢。

pplive

1 天前

网络安全从业者路过，我感觉中间人攻击这东西相当于内蒙古走路去西藏，麦当劳用打火机出餐，韩国战斗机空投摔炮打击日本。

dilidilid

1 天前

QNAP 公网都出过事，绿联、飞牛这种小作坊式的系统上公网提供服务出啥问题都不奇怪，个人使用的话没有任何必要开公网入口，直接在把所有公网 IPv4 inbounding 全拦了就行，出门就用 tailscale/zerotier/wireguard ，啥事没有

dilidilid

1 天前

另外强密码/证书的 SSH 比各种乱七八糟的 docker web 服务安全一百倍，sshd 真有重大 0day 漏洞那可是安全届爆炸新闻了，你的 nas 都没有价值被 0day sshd 漏洞攻击

TXisfine

1 天前

LZ 给的这些安全建议本身都很中肯。
但是中间人攻击的证据链没有公布。如果真是中间人并且成功进入了 fn 后台，那这就漏洞了吧？

godwei

1 天前

学习一波

hqt1021

1 天前 via Android

不是现在哪还流行中间人啊

Xiangliangliang

1 天前

我也是 22 号被攻击了，这个是专门针对飞牛的攻击，有什么漏洞吧，还好就放了点小姐姐，其他什么数据也没放。![fn.jpeg]( https://i.imgant.com/v2/wxkQhCb.jpeg)
给大家提个醒，别管什么服务，只要放到外网都小心一点,尽量使用隧道访问。最好装个杀毒，防止工具链有后门什么的，我是装了个免费的腾讯云主机安全 agent 。谁也靠不住，自己上点心吧。。。

ntedshen

1 天前

飞牛登录那个界面是在 websocket 里面套一层公钥加密的，这能中间人那多少得有几个仇家吧。。。
但是就这个描述来看确实是查个锤子，下次关了就得了。。。

zhengfan2016

1 天前

我 unraid 都暴露公网 5 年了，就没被打过

python35

1 天前

http 下 cookies 是明文，发生什么事情都不奇怪，实际上不需要在登陆的时候截获密钥

lyz2754509784

1 天前 via iPhone

@Xiangliangliang 我也感觉是专门针对飞牛的攻击，但是不是这块专业的我也不敢下定论，群里不少和我一样的飞牛用户也是同样的遭遇

lyz2754509784

1 天前 via iPhone

@TXisfine 感觉可能是一批针对飞牛的攻击？大约在一周前有一批用户都和我同样的问题

lyz2754509784

1 天前 via iPhone

@yanqiyu 应该不是弱密码爆破，飞牛论坛上有个样本分析，和我是 22 日凌晨属于同一次攻击的，貌似是专门针对飞牛的 5666http web 的

ImINH

1 天前

飞牛的为爱发电值得点赞！你描述的问题，很有可能已经有了“远程执行命令 RCE”、“服务器端请求伪造 SSRF”，这些问题，如果排除弱口令的可能，那基本就是有 http 服务未授权的接口，和是不是 ssl 无关。如果是一批用户可能是批量的扫描+漏洞打的，当然也有可能批量弱口令跑的。

xxbing

1 天前

我猜测应该是有未授权的命令执行漏洞
或者
插件、docker 、第三方包包含恶意代码
全部是猜测.中间人应该不太可能

lyz2754509784

1 天前 via iPhone

@pplive https://s.threatbook.com/report/file/8f2226523c594b2e17d68a05dc12702132bb1859fc4b01af378208ac8a2547dc 大佬可以帮忙分析一下么，这个是同一批攻击受害者提取的样本

lyz2754509784

1 天前 via iPhone

@yanqiyu https://s.threatbook.com/report/file/8f2226523c594b2e17d68a05dc12702132bb1859fc4b01af378208ac8a2547dc 这个是同一批攻击受害者提取的样本，大佬可以分析一下他是怎么攻击的么不是这个方面的从业者，不知道能不能复现出最早是如何进入机器的

AkinoKaedeChan

20 小时 29 分钟前

凭感觉是他们有漏洞吧，哪来那么多 MitM 。

yanqiyu

19 小时 44 分钟前

@lyz2754509784 #29 那更不可能是中间人攻击了，这么大规模 MITM 除了运营商等掌握基础设施的人没什么人能做到。有不是人人都随便连接奇怪的 WiFi ，恰好还用飞牛的

verygood

19 小时 27 分钟前

论坛好多人中招，感觉像 0day 漏洞被利用了，官方不知是不重视还是没能力朔源，这都几天了，还什么用户公网访问被利用

weicools

19 小时 22 分钟前

没做反向代理 https ？

civetcat

18 小时 31 分钟前

这么说应该是对飞牛的 5566 端口 web 服务进行了一些攻击，相对来说攻击成功的概率大一些。我还担心是随便一个端口暴露服务出去就会比较危险，我有一些简单的 docker 服务是直接开放 http 端口的

alfawei

17 小时 2 分钟前

大概率是漏洞，wd 西部数据被漏洞搞最后关闭了 livebook 系列业务。

patrickyoung

15 小时 51 分钟前

看完这个描述，不会是 MiTM ，一定是有什么漏洞的。楼主如果没有什么介意的隐私的话，可以把系统日志打包 po 上来看看

yGin

15 小时 17 分钟前

在脱敏的情况下可以透露出更多技术细节么，目前 OP 说明的一些东西感觉和 mitm 关系不是很大，特别是 OP 提到的“安全人员反馈我收到的就是疑似中间人攻击，问题源自于 5666 的明文 http 注入”，如果厂家的某个技术真这样说，那么至少这句话在我这是个减分项（不是针对打工人，而是针对企业，安全事件反馈用户的内容是应该经过内部讨论后的严谨说明）。当然也有可能 OP 描述的和技术细节有一些偏差。

OP 有提到也有其他使用 FNOS 出现类似的问题，那么建议 OP 和飞牛讨论后再考虑是否公布技术细节，如果这是一个在野的 0day ，那么公布细节会增加漏洞的传播，这种情况下我们只能希望飞牛团队能尽快修复这个洞并后续能说明漏洞细节。

epson3333

14 小时 54 分钟前

我也在使用飞牛，飞牛登录的时候不是有双重验证（ 2FA ）吗？为何这样还会被攻击

a9htdkbv

12 小时 56 分钟前

就是有漏洞，路径穿越漏洞

lyz2754509784

12 小时 53 分钟前

@yGin 路径穿越漏洞,飞牛论坛搜 0day 可以看见，1.1.15 已修复

lyz2754509784

12 小时 53 分钟前

@patrickyoung 路径穿越漏洞,飞牛论坛搜 0day 可以看见，1.1.15 已修复

a9htdkbv

12 小时 53 分钟前

最新版已经修复了这个漏洞了，但是不公告，真的太不负责了
react 和之前宝塔的 888 洞至少通过短信和邮件通知了

levelworm

8 小时 38 分钟前 via iPhone

@a9htdkbv #47
看来这个企业责任心不强。

MiKing233

8 小时 20 分钟前

@levelworm 何止是责任心不强, 是对所有使用它们系统用户的数据安全不负责任, 并且看起来至少一周前他们就已经意识到了这个漏洞, 期间一直捂着, 还用因 http 明文访问和中间人攻击来隐瞒用户, 以至于这篇贴主最开始还感谢飞牛团队, 实则是被它们忽悠蒙在鼓里信了它们找的中间人攻击这种鬼话, 想想真是讽刺

https://club.fnnas.com/forum.php?mod=viewthread&tid=53230

taikobo

6 小时 36 分钟前

自己的数据不值钱么, 用这种没经过长时间验证, 开发团队背景不明的产品

一开始在到处宣传我就觉得奇怪, 你们怎么敢用

youyouzi

5 小时 42 分钟前

凌晨 2 点加班解决问题，我看到是不是敬业，而是资本的压榨和底层牛马的心酸。

patrickyoung

5 小时 13 分钟前

还下不到历史版本，下载链接还有签名...合着全拿来防用户了...

laibin6

5 小时 1 分钟前

找到了 151.240.13.91 ip 。还是用用黑裙了

patrickyoung

4 小时 20 分钟前

找了个历史版本的 docker 看了下，其实日志还蛮多的...等一个有缘人看看能不能有日志

pmgh10

1 小时 40 分钟前

@wskymark #4 这可是掉脑袋的事儿，加个班到 2 点能糊弄过去，那也算阿弥陀佛了

Hantong

1 小时 39 分钟前

@patrickyoung 我能找到的有记录的版本是 https://iso.liveupdate.fnnas.com/x86_64/trim/fnos-1.1.11-1438.iso, 然后拿官方的那个 https://fnnas.com/api/download-sign POST JSON `{"url": "https://iso.liveupdate.fnnas.com/x86_64/trim/fnos-1.1.11-1438.iso"}` 签个名就行

patrickyoung

1 小时 28 分钟前

@Hantong 那我还是太高估他们了……下意识以为是一次性在后端生成的……闹半天单独签名 api…跟没签也没区别了…

Hantong

1 小时 17 分钟前

@patrickyoung 老兄是要逆向分析么, 这件事就缺个逆向证据进一步实锤了

kenvix

1 小时 3 分钟前

目前看来并不是 MITM 而是路径穿越漏洞。如果是大规模 MITM 意味着是运营商有内鬼，出这种事运营商比你更急。

yGin

57 分钟前

@lyz2754509784 #45 我搜了一下 1.1.15 发布时间是 1 月 22 日，updatelog 里没有提到修复这个 0day ，无论是飞牛轮胎还是一些社群网站如 nodeseek ，在本周内都有提到飞牛攻击的事，可以 Google 就出来的，包括昨晚凌晨我刷飞牛论坛也有人提到自己的 1.1.15 ，但是也出现 CPU 高占用/有大量连接/大流量等情况，并且现在社区的维护人员也提到让用户查询是否大量下载/上传任务，在 0day 贴里也有人提高到 dockermgr

这些图全是我截图的里面部分时间为相对时间。

不同的用户技术水平不一样，不是所有人都有 OP 这种能力判断自己被当作肉鸡，能发现自己 CPU 负载异常/大量连接/流量大少之又少，所以如果我们把那些最近系统组件大范围停止工作、流量异常、CPU 负载的用户都认为是被 0day 攻击的话，那么至少可以得出 1 月 22 日发布的 1.1.15 是没有解决用户被肉鸡这个事，飞牛是否有推出新的小的修订号来修正 0day 目前不清楚，但是用一个“1.1.15 已修复”的说法是非常模糊的，甚至带有误导性，让有运行着 1 月 22 日版本的用户觉得是自己安全的。

目前社区看下来普遍还是当肉鸡，没有提到被劫持数据的案例，飞牛我印象中是没有磁盘加密功能的了，如果出些大面积的数据劫持那么这次 0day 对飞牛的打击是巨大的。

目前还未发现有说自己是非公网环境下中招的，不过至少能确定昨天的疑问，就是 mitm 并不是正确的回应。

希望飞牛能尽快解决漏洞并给出官方的说明报告吧。

a9htdkbv

47 分钟前

@yGin 我猜原始入口还是这个路径穿越获取了一些敏感配置文件，升级了 1.1.15 还存在问题可能是之前被攻击的残留，我公网搭了一台 1.1.15 蜜罐机，目前还没事

yGin

34 分钟前

@a9htdkbv #61 感谢，如果是 1 月 22 日的版本发布已经修复，那我纠正我的说法，用户需要尽快更新到 1.1.15 ，而那些已经是 1.1.15 但之前被挂马的机器，是需要官方技术团本去帮用户解决木马的，毕竟用户使用你家的存储产品但因为漏洞而被入侵，这是你一个软件驱动的公司应该做的，大量的用户其实是没有能力手动清除那些马的，是需要官方出一个清除方案/专杀工具的。

不过也论证了一个事情，飞牛公司知晓自己的产品存在高危漏洞的情况下，不仅没有发出非常明显的公告让用户尽快升级，甚至还在修复版本的 updatlog 里不写这个漏洞，给人一种我不说就无人知晓的感觉。希望飞牛在黑客进行大规模数据劫持行为前能够正面、正确的面对这个事，对用户负责。

patrickyoung

19 分钟前

@a9htdkbv @yGin 原始的命令执行的问题在 1.15 还是存在的。

Hantong

12 分钟前

@patrickyoung 除了 "/app-center-static/serviceicon/myapp/{0}?size=../../../../" 这里的路径穿越还有洞?

---

https://club.fnnas.com/forum.php?mod=viewthread&tid=48354, 好像这个问题已经很久了, 不是简单的路径穿越的问题

patrickyoung

5 分钟前

Disclaimer: 仅供在自搭建的测试实例学习研究使用。

问题函数是 appcgi.dockermgr.systemMirrorAdd 和 appcgi.dockermgr.systemMirrorChange

存在在后端的 /usr/trim/bin/dockermgr

是一个 authorized RCE 。

如果论坛的用户没有弱口令，那说明这个系统前面还有一个 Authorization Bypass 。

系统架构是 Nginx 反代了一些 local unix socket (/run/*.socket) 与后端服务通信，几个端口都是到 nginx 的。

很不幸的是，这个过程全程通过 Websocket 通信，在系统本地我快速用我的测试 payload grep 了一下本地的文本格式日志和 systemd journal ，没有找到任何的日志记录。

系统在 /usr/trim/var/eventlogger_service 下面有一个 sqlite3 日志，依然是没有相关的日志。

@Hantong POC 稍后发出

a9htdkbv

4 分钟前

@Hantong 已经公网搭蜜罐骗🕳️了

patrickyoung

4 分钟前

底层的关键代码是这样的：

```
snprintf(
s,
0x2000u,
"touch /run/test-mirror.json && dockerd --registry-mirror %s --validate --config-file /run/test-mirror.json",
(const char *)v10[0]);
if ( system(s) )
{
sub_1012C0(v14, "");
sub_1012C0(v12, "");
```

稍微写过一点 linux C 的人都知道，直接拼接了用户的输入到 system() 导致了命令执行。

官方可能以为前端校验了一下 URL 格式，后端就不用管了，所以造成了问题。