晚上八点半我正想从外面连回家里那台飞牛NAS找部电影结果Web管理页死活打不开转圈转了十几秒才蹦出半个页面。本来以为只是系统卡了SSH登上去一看top里有个叫xmrig的进程占着200%的CPU——那一刻我才意识到这台飞牛 NAS 是被薅去挖矿了。这台机器我用了大半年日常跑着 qBittorrent、Jellyfin为了接萤石摄像头还专门用 Docker 部署了 EasyNVR另外装了 Ollama 放个小模型也开了 iventoy 做网络装机。功能是挺全但也就是因为“功能全、端口多、映射广”最后成了肉鸡。这篇文章是这次事件的完整复盘从断网隔离、日志取证、流量溯源到清理修复、系统加固最后整理成一份可以直接拿去用的一键检测脚本。如果你也在用飞牛 NAS或者其他基于 Debian 的自建 NAS建议认真看完踩过的坑真的不想让你再踩一遍。1. 事件现场从小卡顿到大麻烦1.1 异常第一现场CPU飙高、面板卡顿我先说一下事发时的具体状态。那天晚上准备看一部存好的电影打开飞牛的App连接速度明显比平时慢。点开文件列表转了几秒才加载出来。Web后台也一样登录页面能出但输入账号密码之后一直转圈之后进去了也是各种卡。因为我这台机器之前跑过一段时间的内网监控存储我对 CPU 占用比较敏感平时看 Jellyfin 转码也就那样不可能同时让面板这么卡。当时第一反应不是“系统坏了”而是“可能被什么东西占了资源”。SSH 连上去之后先敲了top好家伙一个xmrig进程直接吃了 200% CPU一条命令瞬间就让头绪清晰了一半这是矿机木马。xmrig是门罗币的挖矿程序跑在 Linux 上很常见几乎成了 NAS 被入侵后的“标配”。攻击者把挖矿程序丢进来占 CPU 挖矿。如果你发现 NAS 风扇狂转、外网访问突然变慢、面板打开变得迟钝那大概率就是中了这一类的招。1.2 飞牛NAS为什么会成为攻击目标很多人会觉得“我就是一个家庭 NAS谁会来黑我”这是最大的错觉。攻击者根本不挑目标他们用的是全互联网IP扫描只要你的 22 端口暴露在公网或者某个 Docker 端口直接映射了出去就会被扫描器盯上。结合我自己的情况总结下来飞牛 NAS 容易被盯上的几个原因默认开启 SSH很多人图省事没有改端口22 端口直接怼到公网。管理员密码简单或者开了账号密码登录给爆破留了机会。Docker 容器端口直接暴露比如 qBittorrent 的 Web UI、EasyNVR 的 HTTP 端口全都能从外网访问。飞牛系统本身是基于 Debian 的系统组件和 Docker 镜像如果长期不更新漏洞修复慢。很多人把 NAS 当“种菜机”和“下载机”装了各种第三方应用和容器范围一大攻击面自然就大了。说白了家庭 NAS 的暴露面和一台云服务器没什么区别。攻击者不讲情面也不管你是公司还是家里扫到端口就试密码试不进去就试漏洞试不进去再换下一台自动化程度高得惊人。1.3 发现被黑后的第一反应清单当你意识到 NAS 可能被入侵时第一反应很重要。我这次踩了点坑总结出一个较合理的处理顺序记录现场信息把看到的异常进程名、PID、占用率、可疑连接IP先记下来。别急着杀进程先留证据。断网隔离把 NAS 从公网断开这里指的是断掉外部访问入口而不是把整个机器断电。保留原始日志断网后先把/var/log/auth.log、syslog、Web面板日志等关键日志备份出来。再考虑清理备份完证据之后才去杀进程、删文件。不要一上来就重启。重启会让内存中的恶意进程消失一些临时文件也可能被清掉导致你失去排查的依据。后面细说为什么。2. 断网排查先“断臂求生”保住证据2.1 我的断网操作顺序我当时是先关掉了路由器上对外的端口映射然后登录 NAS 把防火墙临时设置为拒绝外部访问整个过程要保证局域网还能访问。为什么这么做因为排查还需要通过 SSH 和 Web 面板查看信息如果直接把机器断电等于所有线索都没了。具体操作顺序可以这样在路由器后台删掉或禁用所有指向 NAS 的端口转发规则尤其是 22、80/443、8080 这些常见端口。如果 NAS 本身有防火墙立即开启默认拒绝来自 WAN 侧的连接。保留局域网访问能力SSH 和面板都从内网访问这样排查不会中断。如果路由器没有端口映射但 NAS 是通过 DMZ 主机暴露的也要把 DMZ 关掉。对于已经建立的异常外网连接记录下来后面梳理攻击路径要用。如果你用的是飞牛自带的面板那么在“网络设置”里可以直接改防火墙规则临时开启“仅内网访问”是最快的兜底方案。提示断网不是让你拔网线。拔掉网线会让 SSH 会话断开正在执行的排查命令会被打断如果还没把证据备份完损失就大了。2.2 现场取证哪些文件和日志必须先备份断网后我先把这些关键信息备份到 U 盘或者内网另一台机器上。这一步非常重要尤其是当你想搞清楚攻击者到底做了什么的时候。/var/log/auth.logSSH 登录日志能看出有没有爆破、有没有成功登录。/var/log/syslog和/var/log/messages系统运行日志看异常服务和进程的启动痕迹。飞牛 Web 面板日志一般也在/var/log下按面板服务名区分。/etc/passwd、/etc/shadow检查有没有被新增的账号。crontab列表攻击者经常用计划任务来做持久化每个用户的 crontab 都要看。Docker 容器列表和 inspect 信息docker ps -a和docker inspect记录当前容器状态。当前进程的二进制文件对于可疑进程用cp /proc/PID/exe /tmp/evidence/把正在执行的程序复制一份出来。系统启动项systemctl list-unit-files | grep enabled查看有没有可疑的 systemd 服务常驻。在这一步我没有急着清理任何东西只是把数据完整拷贝出来放到一个不会被感染的位置。因为后面清理完很可能需要对照这些文件去确认哪些是恶意文件、哪些是正常的。2.3 断网后最容易犯的三个错误第一个错误是重启。机器一重启内存里的挖矿进程是没了但 cron 任务、systemd 服务、SSH 后门这些持久化设置还在等于明天醒来又变肉鸡。而且进程日志全没了客户机IP、时间线全断没法溯源。第二个错误是“只杀进程不改入口”。很多新手看到xmrig一把kill掉就觉得完事了。结果第二天起来cron 任务又把它拉起来了。还有人是把那个文件删了但 SSH 弱口令没改攻击者过一会儿又爆破进来了等于白干。第三个错误是“局域网内设备不隔离”。如果你的 NAS 和内网其他设备连在一个网段攻击者完全可以利用 NAS 做跳板扫描你的电脑、摄像头、电视盒子。我当时排查时还特意把所有内网设备的网络连接都过了一遍这个习惯后来证明很重要。3. 流量溯源一步步还原攻击路径3.1 查看网络连接找出正在通信的外部IP断网完成之后我回到局域网开始通过 SSH 仔细翻这台机器的网络连接。这一步的核心目的是搞清楚恶意程序在和谁通信。用ss命令就能看得很清楚ss -antp重点关注ESTAB状态、以及对端地址不是192.168.x.x的连接。如果你看到一大堆连到境外 IP 的 TCP 连接那基本就是木马在回传数据或者连接矿池。我当时用这条命令过滤出了所有“非内网”的活跃连接ss -antp | grep ESTAB | grep -v 192.168. | grep -v 127.0.0.1结果发现一个 IP 地址在不断的向外发送数据PID 对应的正是那个xmrig。再用lsof -p PID看这个进程打开的网络连接和文件就能进一步确认它不是误报。还可以通过whois或者 IP 归属查询来看连接 IP 的来源地。如果是个陌生的境外 IP基本可以断定是有问题的。不过国内也有一堆扫描器和矿池不能光靠归属地判断。3.2 查找异常进程木马藏在哪里除了top里明显异常的xmrig我还做了几件事来排查是否有其他隐藏进程ps aux --sort-%cpu | head -20注意看一下%CPU最高的几个进程的启动路径。正常的系统进程一般都在/usr/bin、/bin、/sbin下如果在/tmp、/dev/shm、/var/tmp这类临时目录下那基本可以判定是恶意文件。我还发现攻击者在/dev/shm下藏了一份挖矿程序。为什么选这个目录因为/dev/shm是共享内存目录重启就清空不容易被普通用户注意到而且很多杀毒软件默认会跳过 /dev 下的扫描这是挖矿木马的常见操作。除了常规进程还要检查 crontabcrontab -l以及系统级计划任务ls -la /etc/cron.d/ cat /etc/crontab我在这台机器上就发现了一个可疑的 cron 任务每隔 30 分钟从远程地址拉取一个脚本执行。这就是木马“复活”的机制之一。如果只杀进程不删这个任务后患无穷。3.3 翻检日志攻击是怎么进来的日志是还原攻击路径的最好材料。先看 SSH 日志grep Failed password /var/log/auth.log | tail -20然后统计一下次数最多的爆破来源 IPgrep Failed password /var/log/auth.log | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -20再查一下成功的登录记录grep Accepted /var/log/auth.log通过这段日志我找到了攻击者的入口某一天的凌晨一个 IP 通过 SSH 成功登录了系统而且是用的 root 用户。原因很简单我那时候给 root 用户设的密码是一个比较短的字符串虽然不至于像123456那么离谱但也没强到能扛住自动化爆破。除了 SSH 日志还应该看 Web 面板的日志、Nginx 的访问日志确认有没有通过 Web 漏洞进来的痕迹。比如grep -i admin /var/log/nginx/access.log之类的能看出有没有人尝试访问后台登录接口。3.4 攻击路径还原从爆破到提权到驻留结合所有线索我大概还原了这次攻击的完整时间线凌晨 2 点 17 分来自一个境外 IP 的扫描器发现了我这台 NAS 的 22 端口是开放的。凌晨 2 点 31 分开始该 IP 对这个端口进行了高频密码爆破前后大概试了几百次。凌晨 2 点 47 分爆破成功攻击者以 root 身份通过 SSH 登录系统。登录后立刻执行了一串命令包括创建临时目录、下载挖矿程序、修改 crontab、启动服务。之后攻击者又尝试了横向移动扫描了内网 192.168.1.0/24 网段的 22 端口和其他常见服务端口。第三天也就是我发现那天挖矿程序已经稳定运行CPU 被占满NAS 性能骤降我才意识到有问题。整个攻击过程可以说是教科书式的自动化入侵没有利用任何系统漏洞唯一的缺口就是那个不设防的 SSH 端口和强度不够的 root 密码。4. 一键修复清理、隔离与系统加固4.1 清理恶意进程和驻留文件溯源完成之后才开始清理。先是把挖矿进程杀掉pkill -f xmrig但这个时候还有可能残留其他的子进程所以再用ps aux | grep -iE xmrig|kinsing|kdevtmpfsi|ddgs做一次全面排查。把这些进程全部结束掉之后删掉对应的恶意文件。我当时找到并删除的恶意文件包括/tmp/.X11-unix/...一个伪装成 X11 目录的挖矿文件/dev/shm/...另一份挖矿程序副本/usr/lib/systemd/system/...一个可疑的 systemd 服务名称伪装成正常服务/etc/cron.d/...一个定时拉取脚本的任务然后检查并清理了 root 用户的~/.ssh/authorized_keys发现里面被塞了一把陌生的公钥。攻击者这个操作很阴他把自己的公钥写入authorized_keys就等于给机器留了一个永久的 SSH 后门哪怕你改了密码他依然能用私钥直接登录。这也是很多人“清理完又复发”的原因之一。cat ~/.ssh/authorized_keys看到不认识的内容或公钥注释直接编辑删除。顺便检查一下其他用户的.ssh目录确认没有类似的残留。4.2 改口令、关端口、上防火墙清理完之后我立刻修改了所有账号的密码包括 root 和飞牛面板的管理员账号。密码不强求“玩出花”但至少是 16 位以上包含大小写字母、数字和符号最好使用密码管理器生成。然后我把 SSH 端口从默认的 22 改到了一个高位端口。虽然不能彻底防住扫描但能过滤掉一批无差别爆破。同时关闭了 SSH 的密码登录方式改成密钥登录。具体在/etc/ssh/sshd_config中这样设置Port 22022 PasswordAuthentication no PubkeyAuthentication yes PermitRootLogin prohibit-password改完执行systemctl restart sshd生效。然后是防火墙。飞牛系统自带ufw可以直接操作sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow from 192.168.1.0/24 sudo ufw allow 22022/tcp comment ssh sudo ufw enable如果必须从外网访问某些服务原则是“能不开就不开能白名单就白名单”。用allow from 你家的固定IP这种规则把访问范围缩到最小。实在没有固定 IP就用组网工具把家里设备和手机电脑组进同一个虚拟内网再通过内网地址访问 NAS而不是把端口裸奔到公网。4.3 针对飞牛NAS的加固配置为了以防万一我又给系统加了几个防护层。第一是fail2ban专门盯 SSH 和 Web 面板的登录失败次数达到阈值自动封禁 IPsudo apt install fail2ban sudo systemctl enable fail2ban sudo systemctl start fail2ban第二是 Docker 端口安全。之前我在部署容器时习惯性地把端口映射成0.0.0.0:8080-8080这等于把容器端口暴露到所有网络接口。正确做法是只绑定内网 IPdocker run -d -p 192.168.1.100:8080:8080 --name easynvr ...或者直接绑定回环地址127.0.0.1再通过反向代理从飞牛面板统一入口访问。这样 Docker 容器端口就不会对公网开放了。修复后我逐个检查了正在运行的容器把那些不需要外部访问的容器全部改成了仅内网或仅本机访问。第三是保持系统更新。飞牛系统本身和 Debian 的软件源都有更新通道定期执行更新能堵住已知漏洞sudo apt update sudo apt upgrade -y4.4 观察期修复后一周内必须复查的指标很多人在清理完后就觉得万事大吉其实还差一步观察期。我修复之后坚持复查了一周每天看几个关键指标。用ss -antp看有没有新的异常外连。用auth.log看还有没有人尝试爆破。用crontab -l检查有没有新任务被添加。用top看 CPU 是否长期稳定在正常范围。随时留意机器运行是否又出现“莫名卡顿”的情况。当时第三天晚上auth.log里又出现了一波爆破尝试但都被 fail2ban 挡住了。这个现象让我确认之前的攻击者确实还在扫描这种暴露端口如果当时没做任何防护大概率会第二次中招。5. 一键检测脚本设计思路与完整源码5.1 检测项设计原则这次事件之后我写了一个一键检测脚本专门用来快速判断飞牛 NAS 是否有异常。脚本设计遵循几个原则检测项覆盖常见入侵路径和驻留手段进程、网络、计划任务、登录日志、Docker 暴露面。对系统零侵入只做读取和检测不做任何修改适合定期运行。输出结果要一眼能看懂能区分“正常”和“可疑”。兼容性尽量好基于 Debian 系的飞牛系统可以直接跑。脚本会检查这些内容系统基本信息和 CPU 占用最高的进程。高 CPU 进程和可疑进程名匹配。当前所有活跃的外部网络连接。SSH 登录失败次数统计也就是爆破检测。最近成功的 SSH 登录记录。所有用户的 crontab 任务。正在运行的 Docker 容器和端口映射。最近被修改过的系统敏感文件。常见后门文件路径检查。5.2 脚本源码与逐段说明下面是完整的脚本以 root 用户运行。可以直接保存为fnos_check.sh然后bash fnos_check.sh执行。#!/bin/bash # ------------------------------------------------------------------ # 飞牛NAS(fnOS) 一键安全检测脚本 v1.0 # 用法: sudo bash fnos_check.sh # 说明: 只做检测与输出提醒不修改任何系统配置 # ------------------------------------------------------------------ RED\033[0;31m YELLOW\033[1;33m GREEN\033[0;32m BLUE\033[0;34m NC\033[0m echo -e ${BLUE} 飞牛NAS 安全检测开始: $(date) ${NC} # ---------- 1. 系统信息 ---------- echo -e \n${YELLOW}[1] 系统基本信息${NC} uname -a echo uptime # ---------- 2. CPU占用TOP10 ---------- echo -e \n${YELLOW}[2] CPU占用TOP10进程${NC} ps aux --sort-%cpu | head -11 # ---------- 3. 可疑进程名检测 ---------- echo -e \n${YELLOW}[3] 可疑进程特征检测${NC} SUSPICIOUS_PROCxmrig|kinsing|kdevtmpfsi|ddgs|watchdogs|sysupdate|networkservice|phpguard|kworkerds|cr.sh|sustes|xmss result$(ps aux | grep -iE $SUSPICIOUS_PROC | grep -v grep) if [ -n $result ]; then echo -e ${RED}[发现可疑进程]${NC} echo $result else echo -e ${GREEN}未发现常见挖矿/木马进程。${NC} fi # ---------- 4. 外部活跃连接检测 ---------- echo -e \n${YELLOW}[4] 非内网活跃连接(可能有木马回连)${NC} ss -antp | grep ESTAB | grep -vE 127.0.0.1|192.168.|10\. || echo -e ${GREEN}未发现明显外连。${NC} # ---------- 5. SSH爆破检测 ---------- echo -e \n${YELLOW}[5] SSH爆破检测(失败次数TOP10)${NC} if [ -f /var/log/auth.log ]; then bad_count$(grep Failed password /var/log/auth.log | wc -l) echo 失败总次数: $bad_count grep Failed password /var/log/auth.log | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -10 else echo 未找到 /var/log/auth.log fi # ---------- 6. 最近成功登录记录 ---------- echo -e \n${YELLOW}[6] 最近成功登录记录${NC} grep Accepted /var/log/auth.log | tail -10 || echo 没有成功登录记录 # ---------- 7. 所有用户crontab检测 ---------- echo -e \n${YELLOW}[7] 所有用户crontab任务${NC} for user in $(cut -f1 -d: /etc/passwd); do content$(crontab -l -u $user 2/dev/null) if [ -n $content ]; then echo --- $user 的 crontab --- echo $content fi done # ---------- 8. Docker运行状态 ---------- echo -e \n${YELLOW}[8] Docker容器与端口映射${NC} if command -v docker /dev/null 21; then docker ps --format table {{.Names}}\t{{.Ports}}\t{{.Status}} else echo 未安装Docker或当前用户无权访问 fi # ---------- 9. 最近7天被修改的敏感文件 ---------- echo -e \n${YELLOW}[9] 最近7天被修改的敏感文件${NC} find /etc /usr/local/bin /root -type f -mtime -7 2/dev/null | grep -vE \.log|\.lock|\.pid | head -30 # ---------- 10. 常见后门路径检测 ---------- echo -e \n${YELLOW}[10] 常见后门路径检测${NC} for path in /tmp/.X11-unix /dev/shm/.tmp /var/tmp/.update /tmp/systemd-private; do if [ -e $path ]; then echo -e ${RED}[警告] 发现可疑目录: $path${NC} ls -la $path else echo -e ${GREEN}未发现可疑路径: $path${NC} fi done # ---------- 11. 检查SSH授权密钥 ---------- echo -e \n${YELLOW}[11] 检查root用户的authorized_keys${NC} if [ -f /root/.ssh/authorized_keys ]; then cat /root/.ssh/authorized_keys else echo 没有authorized_keys文件 fi echo -e \n${BLUE} 检测完成: $(date) ${NC}5.3 脚本使用方法和输出解读将脚本保存为fnos_check.sh执行前加执行权限sudo bash fnos_check.sh也可以设置成每周自动执行一次把结果输出到文件方便对比sudo bash fnos_check.sh /tmp/fnos_security_$(date %Y%m%d).log重点看这几个输出项如果“可疑进程特征检测”出现了红色告警说明有已知恶意进程需要赶紧处理。如果“非内网活跃连接”有陌生 IP 且进程名不在你熟悉的应用里要重点核查。如果“SSH爆破检测”显示失败次数很多说明这段时间一直被扫描建议立即改用密钥登录、启用 fail2ban。如果“crontab任务”里有你从来没见过的脚本路径务必检查脚本内容这很可能是木马的持久化机制。如果authorized_keys里有你不认识的公钥说明 SSH 后门可能已经被植入立即删掉它。脚本本身只是一个“体检报告”检测出问题之后再结合前面文章里的清理和加固步骤处理整个流程就闭环了。6. 常见问题与排查技巧实录6.1 实战中的高频问题和解决办法在排查和之后回复网友问题时我遇到了不少类似的情况整理成一张速查表问题场景可能原因解决办法没有高CPU进程但网络连接异常进程被隐藏或者通过内核模块驻留用busybox ps或静态编译的 ps 检查排查lsmod中的可疑内核模块杀完挖矿进程过一会儿又出现计划任务或 systemd 服务在自动拉起检查 crontab、/etc/systemd/system删掉对应任务和服务SSH 密码改了第二天还是被登录authorized_keys 中被写入公钥检查并清空所有用户的 authorized_keys机器已经被下了定时任务攻击者建立持久化后门清空 crontab、删除可疑服务并重启验证内网其他设备也出现异常攻击者在横向移动隔离 NAS逐台检查内网设备修改所有设备的管理密码日志文件被清空了攻击者清理了痕迹检查是否有其他日志备份通过文件时间戳、bash_history 寻找蛛丝马迹清理完文件但 /tmp 又自动生成某个服务仍在运行重新排查所有进程和启动项必要时用系统镜像重装6.2 保命技巧再遇到同样问题怎么办经过这次事件我总结出几条经验和大家分享。第一提前准备一个静态编译的busybox放在 U 盘里备用。当系统已经中了木马攻击者可能会替换掉系统自带的ps、ss、netstat等命令让你看到的信息都是假的。用静态编译的busybox就能绕过这层伪装直接查看真实的进程和网络状态。第二日志不要只放在本地。可以每天自动把/var/log里的关键日志同步到另一台机器或者对象存储。一旦系统被入侵且攻击者清理了日志你依然能从备份里找到攻击线索。第三不要把所有鸡蛋放在一个篮子里。我这次被攻击后把重要数据的定期快照做到了另一块独立硬盘上和系统盘物理隔离。这样即使系统被彻底搞坏也能快速恢复数据。第四端口映射这件事能少开就少开。很多攻击不是靠什么高深漏洞就是靠你懒得关的那些端口。如果只是自己用最好的方案就是完全关闭公网映射回到局域网再用。为了偶尔外网访问方便结果把整台 NAS 暴露在公网这笔账真的不划算。如果真的需要也是优先白名单设备访问其他一律拒绝。写在最后这次被黑事件对我来说是一次深刻的教训也让我养成了三个新习惯第一NAS 系统装完第一件事就是改 SSH 端口、关密码登录、开防火墙第二每周跑一次检测脚本看一遍输出日志第三重要日志定期备份到独立存储上别等出事才发现没记录可查。最后再分享一个小技巧检测脚本不要放在 NAS 里可以放到你的电脑上通过 SSH 远程执行。这样即使 NAS 被攻陷检测脚本本身也不会被攻击者篡改输出结果相对可信。希望这篇复盘能帮你避免踩同样的坑让你的飞牛 NAS 安安稳稳地服役很多年。