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