凌晨两点五十，手机在枕头边上震了两下。云厂商的监控短信：您的主机 47.98.x.x CPU 使用率连续 5 分钟超过 95%，请及时关注。第一反应是「夜里跑了个什么批处理吧」，第二反应是打开 SSH 敲了个 top，然后第三反应就变了满屏的进程里，有一个叫 kdevtmpfsi 的东西，占着 380% 的 CPU，而它的路径是 /tmp/.x/，一个连目录名都带点的藏身目录。那一刻就知道，这台机器不是「忙」，是被入侵了。
如果你也在排查疑似入侵的机器，或者想给自己的服务器提前做一次加固，下面这几家的机器配置和安全组可以先拿来做参考：狗云DOGYUN（高性价比云服务器，安全组规则可自定义）、RackNerd（全球VPS，带防护方案）。
一、第一步不是查杀，是确认
很多人一看到 CPU 爆了，第一反应是 kill 掉那个进程，然后重启一下机器，觉得「重启就干净了」。这一步操作其实很危险：挖矿木马在被 kill 的瞬间，往往会通过各种手段把自己重新拉起来（cron、systemd service、rc.local、ld.so.preload 劫持、内核模块、或者一个你还没发现的 WebShell），重启只是把战场清空了，工具还在硬盘上，下次开机照旧。
正确的顺序是：先看、再断、后杀、最后改。具体说，先用 top -c 或 htop 看清进程树，记住可疑进程的名字和父进程；然后从云控制台的安全组里，把 22、3389、面板端口的入站临时收紧到只允许你自己的 IP；接着再动手清理。这样即使 malware 有外联通道，在你动手的这几分钟里它也传不出去新的配置文件。
判断是不是挖矿，其实有几个非常好认的特征：进程名是一堆随机小写字母或者模仿系统进程的名字（kdevtmpfsi、kinsing 这类）；CPU 占用高得离谱但流量很小，说明是本地算力而不是跑业务；进程的真实路径藏在 /tmp、/dev/shm、/var/tmp 这种正常程序不会待的地方；文件权限是 777 但属主是 root；最直接的证据是去矿池地址或者钱包地址做特征匹配。
二、入口在哪：顺着日志往回找
清理掉进程只是止住了流血，真正的问题是这个洞是怎么开的。我一般按这个顺序倒查：
第一层，SSH 弱口令。看 /var/log/secure 里有没有大量 Failed password，来源 IP 集中在几个境外段落的，基本可以确定是被批量爆破扫到了。判断依据很朴素你的密码如果只有数字加字母，八位以下，暴露在公网上被扫到是迟早的事，而不是「运气不好」。
第二层，网站面板和 Web 应用。宝塔、WordPress、ThinkPHP、Struts2、Log4j 这类组件是重灾区。挖矿木马最常见的落地方式是通过一个上传漏洞拿到 WebShell，再通过 WebShell 下载执行挖矿程序。所以 Web 目录里出现一个不属于你的 .php 文件，基本就锁定了。
第三层，第三方组件和依赖。老版本的 Redis（未设密码暴露 6379）、MongoDB、Elasticsearch、Docker API 挂出来的端口，都是可以直接被利用拉起容器的入口。这类问题的隐蔽之处在于：服务本身看起来「只是没设密码」，但等你在面板上看到一个陌生容器时，数据已经被翻过一遍了。
如果日志也被删干净了（攻击者很爱删），也别慌：翻一下 bash_history、命令历史时间戳有没有断层，再看看 /tmp 和 /var/tmp 里最近修改的文件，通常能拼出路径来。
三、应急处置的五个动作
把上面这些串起来，实际动手的时候我是这么排的：
1. 隔离。安全组里把高危端口只留自己的 IP。这一步做完，心跳稳住了，你才敢慢慢查。
2. 留证。把可疑进程的信息、文件、连接列表先保存一份（ss -antp、ps auxef、find 结果），后面可能要用来做溯源和报备，也方便判断清理是否彻底。
3. 清理残留。杀进程只是第一步，还要清：所有用户的 crontab（crontab -u 用户 -l 逐个看）、/etc/cron.d 与 /etc/cron.* 目录、systemd 的自定义 service（systemctl list-unit-files | grep enabled）、rc.local、profile 与 bashrc 里的注入行、每个用户的 ~/.ssh/authorized_keys 里多出来的公钥攻击者留着 authorized_keys 就等于留了一把后门钥匙，随时可以换回马甲登进来。
4. 换钥匙。被爆破过的机器，原来的 SSH 密码必须视为已泄露。同时把 authorized_keys 全清掉重发，只留自己的那把。这一步经常被跳过，也是同一台机器「清了又中」的主因。
5. 补丁与关端口。修补入侵路径对应的漏洞，卸载用不到的组件，关掉用不到的端口暴露。如果确认有数据被拖走，还要考虑数据库凭据、API Key、支付密钥全部作废重发，而不是改个密码就完事。
四、别等 CPU 烧到 100% 才发现问题
这次能及早发现，多亏了监控告警。所以真正值得花时间的是事后加固，让下一次连门都摸不到：
SSH 加固：改掉 22 端口（这不防扫描器，但能过滤掉八成傻瓜脚本）、禁用 root 直接登录、禁用密码登录只用密钥、装 fail2ban 或类似的封禁工具。
安全组最小化：默认只放行 80/443，管理端口对公网零暴露，数据库、Redis、面板端口一律内网或白名单访问。
面板和组件：宝塔这类面板的 8888 端口一定要改入口、绑定域名、开双因素；WordPress 插件及时更新，不用的插件直接删。
监控阈值：CPU 连续 3 分钟超 70% 就告警，磁盘使用率超 80% 告警，出站流量突增告警，等 CPU 真的到 95%，往往已经跑了好几个小时，账单和流量都白烧了。
异地备份：备份不只是防硬盘坏，更是防勒索。备份要有独立副本，最好还能验证能不能真的还原出来很多站备份文件也躺在同一台机器上，等被删的时候才发现一起没了。
五、写在最后
这次前后折腾了两个多小时，最耗时间的不是查杀进程，而是重建一套干净的环境：清理、重装组件、换密钥、逐条核对对外暴露的端口。真正让我后怕的是，在我发现之前那台机器可能已经被跑了整整一周凌晨三点那次报警只是因为任务刚好重启了一次，才让进程被重新拉起、负载曲线变得扎眼。
所以如果你现在正遇到 CPU 莫名其妙跑满，先别急着重启，也别急着去网上抄一键清理脚本。回想一下你是哪天开始觉得「这台机器好像有点慢」的，那个时间点往往才是入侵的起点。把它记下来，然后按上面四步走一遍，比什么都强。
喜欢 
顶
难过
囧
围观
无聊
