请不要把任何和邀请码有关的内容发到 NAS 节点。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
邀请码相关的内容请使用 /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 出现的问题：大约一周前不定时爆连接数指向一个 ip ，疑似被黑成肉鸡攻击某个站点
在群里讨论后客服积极的拉了技术群并安排了技术人员分析，由于攻击是随机时间的不好抓取，今晚 9 点正好复现，凌晨 2 点飞牛的技术人员完成了安全问题的解决。
在此也给公网使用飞牛的朋友们一些安全小意见以减少 nas 被入侵的安全风险：
web 不建议直接映射，建议使用 tailscale 等类似的组网隧道，最最安全！
如果一定要公网开放 web ，不建议使用 5666 http 的明文端口，安全人员反馈我收到的就是疑似中间人攻击，问题源自于 5666 的明文 http 注入。
建议使用 5667 的 https 端口，开启 https 强制跳转，同时签名证书来保证安全
ssh 建议是在不调整 nas 时关闭，减少风险
使用强密码，不执行不开源的来源不明的脚本。
再次感谢飞牛官方团队的技术支持，凌晨 2 点技术在线解决问题说实话真的让我很惊讶，再次感谢，也希望我的遭遇可以让其他有相同问题的朋友们可以参考
 | 1 lyz2754509784 OP  1 附上代码 ss -tanp | awk -F'[",=]' '/users:\(\(/ {cnt[$2 ":" $6]++} END{for(i in cnt) print cnt[i], i}' | sort -nr 这样就可以看到是哪个进程在对外发包了----来自飞牛官方的技术人员 |
 | 2 MiKing233 12 小时 47 分钟前 2026 年了这不是常识吗, Web 服务不应允许明文 HTTP, 必须经由 TLS 加密... |
 | 3 pingdog 11 小时 53 分钟前 via iPhone … 以下疑问仅针对 OP 当前帖子的内容描述作出 常规 B/S 开发模型下，请求进入了 server/backend 不会将请求中继到公网，即使 backend 有向公网发出请求的行为，也是 hardcode 的地址，所以这个“不定时爆连接数指向一个 ip”是随机出现还是关联到某个服务。要是服务那是不是这段逻辑执行完没关闭 socket 就耗尽了。如果问题出在 server ，就类似前阵的 react2shell ，漏洞源于 react server component ，不过滤触发语句 http/https 一样打穿 |
 | 4 wskymark 9 小时 6 分钟前 1 凌晨 2 点！飞牛这公司卷成这样 |
 | 5 yeh 8 小时 45 分钟前 问题是，飞牛 drive 的端口，不就是 https 访问的端口吗？ 不对外映射，难道走 fn connect ？ fn connect 的 199/年，上行也就 40m 啊 超过 40m 的宽带可多了，哪怕是舍得花 199/年，也不满足要求啊。 |
 | 6 imlonghao 8 小时 39 分钟前 via iPhone 6 将被入侵问题归因到中间人攻击那就是他们没有找到问题 |
 | 8 rockddd 7 小时 19 分钟前 1 凌晨两点？没有买卖就没有伤害 |
 | 9 susunus 7 小时 7 分钟前 凌晨 2 点！ 好的以后不用 飞牛了， 避免同行因此加班 |
 | 10 relife 7 小时 3 分钟前 只开 ssh 公钥登录，然后用 ssh 反向代理端口访问也行 |
 | 11 verygood 6 小时 49 分钟前 看下来还是没找到根因 |
 | 12 VVVYGD 6 小时 31 分钟前 可以，飞牛。 |
 | 13 mingtdlb 6 小时 29 分钟前 你还是给飞牛当时处理的这帮人点两杯奶茶吧，礼轻情意重 |
 | 14 fstab 6 小时 1 分钟前 凌晨 2 点，说实话， 我是企业主，对于产品的服务还是挺满意的。 但是我是打工人，我只会站在打工人这边，哪怕是员工自愿加班， 或者初创公司员工持股，为了快速拿到融资或者变现而努力，但是我始终无法共情这个行为。 |
 | 15 yanqiyu 5 小时 53 分钟前 @pingdog 我理解是怀疑中间人拿到了密码，或者关键用户 token ，导致攻击者获得 webui 的管理员权限。然后进行的渗透。 但是说实话，正常情况下真的有这么多公网上的 MITM 吗？我其实更怀疑楼主的机器设置了弱密码被暴破了。 |
 | 16 JqbR001 5 小时 1 分钟前 完全不在公网访问 FN web |
 | 17 dushixiang 4 小时 47 分钟前 1 中间人攻击？你用的哪家运营商的网络？我只见过中间人插入广告的，没见过中间人抓肉鸡的。 中间人攻击的含义是你和服务端直接的通信内容被中间人篡改了，例如你去请求某一个 http 的网页，他在中间插入了一段 js 来播放广告。 你现在说中间人攻击你的 NAS 变成肉鸡了，我只能怀疑是你得 NAS 会执行来自服务端的 命令，然后这个命令被中间人篡改了，执行之后被黑客控制了。 ---- 所以我觉得是没找到原因，也不懂网络安全，随便找个理由糊弄你呢。 |
 | 18 pplive 4 小时 30 分钟前 网络安全从业者路过，我感觉中间人攻击这东西相当于内蒙古走路去西藏，麦当劳用打火机出餐，韩国战斗机空投摔炮打击日本。 |
 | 19 dilidilid 4 小时 30 分钟前 1 QNAP 公网都出过事，绿联、飞牛这种小作坊式的系统上公网提供服务出啥问题都不奇怪，个人使用的话没有任何必要开公网入口，直接在把所有公网 IPv4 inbounding 全拦了就行，出门就用 tailscale/zerotier/wireguard ，啥事没有 |
| 20 dilidilid 4 小时 28 分钟前 另外强密码/证书的 SSH 比各种乱七八糟的 docker web 服务安全一百倍，sshd 真有重大 0day 漏洞那可是安全届爆炸新闻了，你的 nas 都没有价值被 0day sshd 漏洞攻击 |
 | 21 TXisfine 3 小时 18 分钟前 LZ 给的这些安全建议本身都很中肯。 但是中间人攻击的证据链没有公布。如果真是中间人并且成功进入了 fn 后台，那这就漏洞了吧？ |
 | 22 godwei 3 小时 4 分钟前 学习一波 |
 | 23 hqt1021 2 小时 51 分钟前 via Android 不是现在哪还流行中间人啊 |
 | 24 Xiangliangliang 2 小时 41 分钟前 我也是 22 号被攻击了，这个是专门针对飞牛的攻击，有什么漏洞吧，还好就放了点小姐姐，其他什么数据也没放。 给大家提个醒，别管什么服务，只要放到外网都小心一点,尽量使用隧道访问。最好装个杀毒，防止工具链有后门什么的，我是装了个免费的腾讯云主机安全 agent 。谁也靠不住，自己上点心吧。。。 |
 | 25 ntedshen 2 小时 30 分钟前 飞牛登录那个界面是在 websocket 里面套一层公钥加密的，这能中间人那多少得有几个仇家吧。。。 但是就这个描述来看确实是查个锤子，下次关了就得了。。。 |
 | 26 zhengfan2016 2 小时 16 分钟前 我 unraid 都暴露公网 5 年了，就没被打过  |
 | 27 python35 2 小时 3 分钟前 http 下 cookies 是明文，发生什么事情都不奇怪，实际上不需要在登陆的时候截获密钥 |
| 28 lyz2754509784 OP @Xiangliangliang 我也感觉是专门针对飞牛的攻击，但是不是这块专业的我也不敢下定论，群里不少和我一样的飞牛用户也是同样的遭遇 |
| 29 lyz2754509784 OP @TXisfine 感觉可能是一批针对飞牛的攻击？大约在一周前有一批用户都和我同样的问题 |
| 30 lyz2754509784 OP @yanqiyu 应该不是弱密码爆破，飞牛论坛上有个样本分析，和我是 22 日凌晨属于同一次攻击的，貌似是专门针对飞牛的 5666http web 的 |
 | 31 ImINH 1 小时 35 分钟前 飞牛的为爱发电值得点赞！你描述的问题，很有可能已经有了“远程执行命令 RCE”、“服务器端请求伪造 SSRF”，这些问题，如果排除弱口令的可能，那基本就是有 http 服务未授权的接口，和是不是 ssl 无关。如果是一批用户可能是批量的扫描+漏洞打的，当然也有可能批量弱口令跑的。 |
 | 32 xxbing 1 小时 30 分钟前 我猜测应该是有未授权的命令执行漏洞 或者 插件、docker 、第三方包 包含恶意代码 全部是猜测.中间人应该不太可能 |
| 33 lyz2754509784 OP @pplive https://s.threatbook.com/report/file/8f2226523c594b2e17d68a05dc12702132bb1859fc4b01af378208ac8a2547dc 大佬可以帮忙分析一下么，这个是同一批攻击受害者提取的样本 |
| 34 lyz2754509784 OP @yanqiyu https://s.threatbook.com/report/file/8f2226523c594b2e17d68a05dc12702132bb1859fc4b01af378208ac8a2547dc 这个是同一批攻击受害者提取的样本，大佬可以分析一下他是怎么攻击的么 不是这个方面的从业者，不知道能不能复现出最早是如何进入机器的 |
Select Language