请不要把任何和邀请码有关的内容发到 NAS 节点。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
这是一个创建于 1224 天前的主题，其中的信息可能已经有所发展或是发生改变。
设备信息
型号 DS220+，DSM7.0，两根网线，LAN1 LAN2
具体情况
每个小时的第 15 分钟开始到第 25 分钟之间，LAN1 和 LAN2 交替以 2MB/s （ 16Mbps ）的速度向外发送数据，10 分钟发送了大约 1.2G 的数据，实在想不明白到底什么服务需要对外发送这么大量的数据。
下图是监控数据。
已排除的可能
-
FRP，frp 的相关穿透配置仅限于 LAN1 的地址，未对 LAN2 的地址有任何穿透转发。看发送情况是 LAN1 和 LAN2 交替发送。
-
OneDrive 的同步，没有这么大的同步量，这几个周期发送了好几十 G 的数据了，OneDrive 同步任务可以排除。
-
相关 Docker 容器的网络发送，只有 FRP 容器两个。qinglong 容器一个。
-
Synology Active Insight，这玩意定期上产系统的运行信息，按理说不可能发送这么巨大的流量。
其他问题
DSM7.0 Universal Search 应用点击 检查索引数据库，会一直检查，导致 CPU 在数天内持续占用 50%左右，手动取消后占用恢复正常。
我使用 iftop 未定位到原因。各位有什么排查策略吗？
第 1 条附言 · 2021-07-26 10:04:21 +08:00
更新一下，找到问题了是MacBook时间机器备份的问题，虽然不太清楚为什么时间机器开始备份前NAS会向MacBook持续发送那么多数据。
根据老哥们的建议，没有抓包，使用docker起了个iftop容器，挂到了host网络，查看eth0的所有网络情况。
- 整点10分的时候，发现NAS起了一个445端口，持续向内网的某台机器发送数据。大约10-18Mbps的速率。
└──────────────────────────┴──────────────────────────┴───────────────────────────┴──────────────────────────┴───────────────────────────
192.168.0.108:445 => 192.168.0.104:59429 12.1Mb 7.28Mb 6.51Mb
<= 30.6Mb 16.2Mb 14.2Mb
- 定位端口445为smb端口
ash-4.4# netstat -pantu | grep 445
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 9877/smbd
tcp 0 4180 192.168.0.108:445 192.168.0.104:59429 ESTABLISHED 19533/smbd
tcp 0 0 192.168.0.105:445 192.168.0.104:61335 ESTABLISHED 5952/smbd
tcp6 0 0 :::445
- 查看MacBook的时光机器，发现每小时的定时备份的开始时间为整点第10分钟开始。
第 2 条附言 · 2021-07-26 10:04:25 +08:00
更新一下，找到问题了是MacBook时间机器备份的问题，虽然不太清楚为什么时间机器开始备份前NAS会向MacBook持续发送那么多数据。
根据老哥们的建议，没有抓包，使用docker起了个iftop容器，挂到了host网络，查看eth0的所有网络情况。
- 整点10分的时候，发现NAS起了一个445端口，持续向内网的某台机器发送数据。大约10-18Mbps的速率。
└──────────────────────────┴──────────────────────────┴───────────────────────────┴──────────────────────────┴───────────────────────────
192.168.0.108:445 => 192.168.0.104:59429 12.1Mb 7.28Mb 6.51Mb
<= 30.6Mb 16.2Mb 14.2Mb
- 定位端口445为smb端口
ash-4.4# netstat -pantu | grep 445
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 9877/smbd
tcp 0 4180 192.168.0.108:445 192.168.0.104:59429 ESTABLISHED 19533/smbd
tcp 0 0 192.168.0.105:445 192.168.0.104:61335 ESTABLISHED 5952/smbd
tcp6 0 0 :::445
- 查看MacBook的时光机器，发现每小时的定时备份的开始时间为整点第10分钟开始。
 |
1
xtx 2021-07-25 17:28:34 +08:00 via iPhone
lan1，lan2 分别连的什么？
|
 |
3
sutking 2021-07-25 17:35:07 +08:00
排除法，先排除硬件，拔一根网线留一根，看情况，然后再把另外一根插上，拔掉之前没拔的那一根，看情况；然后软件，把服务、进程挨个停掉，观察。
|
 |
4
wtks1 2021-07-25 17:38:38 +08:00 via Android
是不是装了迅雷相关的软件？
|
 |
5
SaberJack 2021-07-25 17:39:57 +08:00
能通过上级路由器看下流量包不 能的话就可以分析出来了
|
 |
6
Junzhou OP |
 |
7
wangkai0351 2021-07-25 17:46:36 +08:00
不知道群晖现在安全性做的如何，注意排查
|
 |
9
ByteCat 2021-07-25 18:18:37 +08:00
从路由器里面看不行吗，我用的高恪都可以看到数据流向
|
 |
11
512357301 2021-07-25 18:28:51 +08:00 via Android  1
有个笨办法，换端口，并且只限制某几个端口可以连外网，类似于 vps 的安全组。
我之前在 aws 搭的 win10 就出现过这种情况，怀疑是被当成肉鸡了，后来在安全组限制入站端口后，瞬间风平浪静，(不过最终也不确定是什么原因导致的，也可能是 win10 自动更新的锅) aws ec2 每月限制 15G 的进和出流量，我当时竟然能跑满。。。，限制端口后，每个月顶天了 8 个 G |
 |
13
gBurnX 2021-07-25 19:02:02 +08:00 2
上面都在答些啥。
iptraf -> netstat 找到进程。 |
 |
14
SZP1206 2021-07-25 19:03:00 +08:00 via Android
有点好奇，期待下后续
|
 |
15
matrix67 2021-07-25 21:39:45 +08:00 1
可以使用 tcptrack
tcptrack -i eth0 。 直接定位出那个端口，以及连的 ip+port 实时速率。 或者使用 nethogs 。不过这个好像是看瞬时值的。要在你抓到流量大的时候启动它，把相关进程打出来。 |
|
16
matrix67 2021-07-25 21:42:09 +08:00 1
或者 tcpdump -s 80 就采样 dump 一下包，然后丢到 wireshark 里面看那个 ip+端口占的数据最多。
楼上说的 iptraf 也是一条路子。 |
 |
17
darkaforest 2021-07-25 21:51:20 +08:00 1
直接 tcpdump 出来用 wireshark 看看不就一目了然了吗，建议敏感数据直接脱离物理网络存储，最好再加上物理防护措施。 如果觉得不值得这么干，那说明其实也没多敏感，随便它偷着往外传啥吧。
|
 |
18
ly841000 2021-07-25 22:14:59 +08:00
大家都好友善，国内厂商的话不被骂上天？！！！！！！
|
 |
19
PrinceofInj 2021-07-25 22:34:26 +08:00 1
@ly841000 两大 NAS 厂家都是台企，如果用来存储敏感数据，最好还是做好防范。
|
 |
20
geniussoft 2021-07-25 22:39:30 +08:00
@ly841000 群晖算是非常有操守的企业了，相对来说。
这边 FRP 、OneDrive 都开着，就认为一定是群晖的锅，这个推测不合理吧。 |
 |
21
vmebeh 2021-07-25 23:43:38 +08:00 via iPhone
台积电、Nvidia 也是台企，你用的 CPU 、GPU 自带后门！！！！！ 🐶
|
|
22
wangkai0351 2021-07-26 09:14:06 +08:00
@vmebeh 要是这么较真，万物皆带后门，台积电、Nvidia 敢反驳这句话吗？
|
 |
23
yesfirst 2021-07-26 09:21:44 +08:00
这个监控数据在哪里可以看？ 我是 dsm6 没找到么
|
|
24
Junzhou OP 1
@SZP1206 更新一下，找到问题了是 MacBook 时间机器备份的问题，虽然不太清楚为什么时间机器开始备份前 NAS 会向 MacBook 持续发送那么多数据。
根据老哥们的建议，没有抓包，使用 docker 起了个 iftop 容器，挂到了 host 网络，查看 eth0 的所有网络情况。 整点 10 分的时候，发现 NAS 起了一个 445 端口，持续向内网的某台机器发送数据。大约 10-18Mbps 的速率。 └──────────────────────────┴──────────────────────────┴───────────────────────────┴──────────────────────────┴─────────────────────────── 192.168.0.108:445 => 192.168.0.104:59429 12.1Mb 7.28Mb 6.51Mb <= 30.6Mb 16.2Mb 14.2Mb 定位端口 445 为 smb 端口 ash-4.4# netstat -pantu | grep 445 tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 9877/smbd tcp 0 4180 192.168.0.108:445 192.168.0.104:59429 ESTABLISHED 19533/smbd tcp 0 0 192.168.0.105:445 192.168.0.104:61335 ESTABLISHED 5952/smbd tcp6 0 0 :::445 查看 MacBook 的时光机器，发现每小时的定时备份的开始时间为整点第 10 分钟开始。 |
 |
26
Ravencus 2021-07-26 10:23:38 +08:00
好像不止是开始备份前。time machine 备份的过程中 mac 上也会有间歇性的流量下行。
|
 |
27
littlewing 2021-07-26 11:52:55 +08:00
从你的描述中我一直以为是向外网发送流量。。。。
|
|
28
Junzhou OP @littlewing 最开始也没有确认流向。。。
|
 |
29
tankren 2021-07-26 13:27:43 +08:00
shell 里面看看 top 呢
|
 |
30
smileawei 2021-07-26 14:25:35 +08:00
看看是不是装了迅雷系列的下载工具。之前有装过“玩物下载” 。然后就发现上传不正常
|
 |
31
lifanxi 2021-07-26 23:33:57 +08:00 via Android
@Junzhou 用 Docker 跑 iftop 好机智。还有个更原生的玩法，sudo synogear install，有惊喜。
|
|
32
Junzhou OP 操 还能这样啊 一会试试
|
Select Language