记录：第一次服务器被植入木马挖坑
切记！重装系统一定要第一时间更改默认密码！
一切的一切从前两天我dd重装狐蒂云服务器的系统开始说起
那会想着 dd 重装系统是因为 halo 博客出问题了，不小心点了恢复，但是结果却没有恢复，啥也没有了，就想趁着这次推到重来，那就开始 dd 吧，很快就 dd 好系统了，本来想着改密码的，结果因为别人叫了我一下，我和他聊天了，然后就忘记了..... 竟然就忘记改密码了🤣
结果这两天，每天看探针的时候，CPU 都是跑满了，这服务器可以 16H16G 的啊，之前看 CPU 占用一直都是 1%-5% 这个区间，但是这两天 TG 监控都给我推送 CPU 占用都是 100%，我就觉得肯定是哪里出问题了，（这会还没到是被植入挖坑程序）。
然后就一直在问 ai，包括 Gemini（前几天薅的一年）和 Claude，给占用图和 top 他们看，都在处理无关紧要的东西，一直没处理好，刚好刚刚突然想到是不是被植入挖坑程序了，然后就发了这句话给 Claude
结果发完给他，他给我回复后就提示 Claude 免费额度用完了，要等到晚上 8 点才能继续免费用，哈哈哈...
然后我就把第一步的 1、2 两条命令发给 Gemini 了，它就教我一步一步操作：
我问：
我的狐蒂云服务器在运行这两个命令后的情况root@ser971939400951:~# ps aux | grep -E "xmrig|minerd|cpuminer|cryptonight|kdevtmpfsi|kinsing|systemd-login|sysupdate" | grep -v grep
root 543 0.0 0.0 16916 7864 ? Ss 14:26 0:00 /lib/systemd/systemd-logind
root@ser971939400951:~# ps aux --sort=-%cpu | head -30 | grep -v -E "java|mysql|postgres|docker|containerd|node"
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 199690 100 0.0 11264 4876 pts/1 R+ 15:59 0:00 ps aux --sort=-%cpu
root 117961 3.6 0.0 1235092 15592 ? Ssl 15:29 1:03 /opt/komari/agent -e https://kk.oknm.de -t WQGyF72dO3GlgIm2tBHv57 --disable-web-ssh --month-rotate 1
root 114797 0.4 0.2 1444636 43036 ? Ssl 15:28 0:08 /opt/komari/komari server -l 0.0.0.0:25774
root 147351 0.3 0.0 11708 5468 pts/3 Ss+ 15:40 0:04 /usr/bin/top
root 42911 0.3 0.0 1228708 6404 ? S<sl 15:04 0:09 /tmp/sshd
999 1182 0.2 0.1 60156 26184 ? Ssl 14:26 0:15 redis-server *:6379
root 199409 0.2 0.0 155340 3956 ? S<sl 15:59 0:00 ./.bash_logout
root 15 0.1 0.0 0 0 ? I 14:26 0:07 [rcu_preempt]
root 343 0.1 0.1 49572 30148 ? Ss 14:26 0:07 /lib/systemd/systemd-journald
root 1 0.0 0.0 168108 12536 ? Ss 14:26 0:03 /sbin/init
root 673 0.0 0.3 1028784 59056 ? Ssl 14:26 0:02 PM2 v6.0.14: God Daemon (/root/.pm2)
root 192479 0.0 0.0 17732 11260 ? Ss 15:56 0:00 sshd: root@pts/1
root 181109 0.0 0.0 0 0 ? I 15:52 0:00 [kworker/u32:2-events_unbound]
sshd 1362 0.0 0.1 171952 21376 ? Sl 14:26 0:01 nginx: worker process
sshd 1364 0.0 0.1 172024 21484 ? Sl 14:26 0:01 nginx: worker process
root 10378 0.0 0.0 0 0 ? I 14:37 0:01 [kworker/u32:0-events_unbound]
root@ser971939400951:~# Gemini 回答：
从你提供的命令输出截图来看，情况**不容乐观**。虽然你的第一个命令（针对特定挖矿病毒名的过滤）没有直接抓到典型进程，但在第二个命令（CPU占用排序）中，暴露了**两个非常可疑的恶意进程**。
以下是详细分析和处理建议：
### 1\. 🔍 异常进程分析（高度危险）
你在 `ps aux` 输出中发现了以下两个极可能是木马或挖矿病毒伪装的进程：
* **`root 42911 ... /tmp/sshd`**
* **判定：恶意。**
* **原因：** 正常的 SSH 服务进程路径通常是 `/usr/sbin/sshd`。任何在 `/tmp`（临时目录）下运行的可执行文件，尤其是取名为 `sshd` 试图混淆视听的，几乎100%是黑客留下的后门或挖矿程序。
* **`root 199409 ... ./.bash_logout`**
* **判定：恶意。**
* **原因：** `.bash_logout` 本应是一个在用户退出 shell 时执行的脚本文件，而不是一个持续运行的二进制进程（STAT状态为 `S<sl`，显示它是一个多线程的守护进程）。这是病毒常用的伪装手段（常见于挖矿病毒如 `kdevtmpfsi` 的变种）。
### 2\. ✅ 看起来正常的进程
* `/lib/systemd/systemd-logind`：这是系统正常的登录管理服务，被你的第一个 grep 命令抓出来是因为它名字里包含 `login`，属于误报，无需担心。
* `/opt/komari/agent ...`：连接到 `kk.oknm.de`。鉴于 `oknm.de` 是你自己的域名（根据之前的对话记忆），这应该是你部署的**探针/监控服务**（可能是哪吒监控的改版？），这是正常的。
-----
### 3\. 🛡️ 紧急处理步骤
请立即按顺序执行以下操作来清除这些威胁：
#### 第一步：确认病毒文件位置
运行以下命令查看这两个进程对应的实际文件路径（虽然名字看起来像系统文件，但实际路径通常在隐藏目录）：
```bash
ls -l /proc/42911/exe
ls -l /proc/199409/exe
```
*记下显示的真实路径（例如可能是 `/tmp/sshd` 或 `/etc/.bash_logout` 等）。*
#### 第二步：杀掉恶意进程
强制结束这两个进程：
```bash
kill -9 42911 199409
```
*(注意：如果杀掉后进程ID变了又马上复活，说明有守护进程或定时任务在通过 crontab 恢复它。)*
#### 第三步：删除恶意文件
根据第一步找到的路径，删除文件。通常主要集中在 `/tmp` 目录下：
```bash
rm -rf /tmp/sshd
rm -rf /tmp/.bash_logout
# 检查是否有其他可疑文件
ls -al /tmp/
```
#### 第四步：检查定时任务（病毒复活的根源）
很多病毒会写入定时任务来确保持久化。请检查并编辑：
```bash
crontab -e
```
**如果看到任何奇怪的、不是你添加的任务（特别是包含乱码、base64编码、或指向 /tmp 目录的脚本），请直接删除那一行。**
同时检查系统级任务：
```bash
cat /etc/crontab
ls /etc/cron.d/
```
### 4\. 建议
鉴于发现了 `/tmp/sshd`，这意味着你的服务器可能已经被拿到了 Root 权限。
1. **修改密码：** 清理完后，立即修改服务器 Root 密码。
2. **检查防火墙：** 确认只开放了必要的端口。
3. **最彻底的方案：** 如果服务器上没有特别重要且无法迁移的数据，**重装系统**是最安全的办法，因为你无法确定黑客是否留下了其他隐藏更深的后门。
**需要我教你如何查看这台机器目前的网络连接（看它们在往哪里传输数据）吗？**我问：
root@ser971939400951:~# ls -l /proc/42911/exe
ls -l /proc/199409/exe
lrwxrwxrwx 1 root root 0 Nov 30 16:00 /proc/42911/exe -> '/tmp/sshd (deleted)'
ls: cannot access '/proc/199409/exe': No such file or directory
root@ser971939400951:~# Gemini 回答：
这两个输出揭示了非常典型的黑客\*\*“隐藏痕迹”\*\*手段：
1. **`/proc/42911/exe -> '/tmp/sshd (deleted)'`**
* **这意味着什么：** 这是一个**确凿的实锤**。黑客把病毒文件上传到 `/tmp/sshd`，运行它，然后**立即删除了文件**。
* **为什么这么做：** 这样你用 `ls` 去找文件是找不到的，杀毒软件的文件扫描也扫不到它，但因为它已经被加载到内存（RAM）里了，所以进程依然能正常运行。这叫做“无文件落地”或文件删除后的驻留。
2. **`ls: cannot access ... No such file or directory`**
* 那个伪装成 `.bash_logout` 的进程（PID 199409）已经停止了，或者是变幻了 PID（进程号）试图躲避追踪。
-----
### 🚨 立即执行以下清理步骤
你现在的首要任务是**斩草除根**，防止它复活。
#### 第一步：查看病毒连到了哪里（保留证据）
在杀掉它之前，先看看它连到了哪个 IP（这通常是黑客的矿池或控制端）。
运行：
```bash
netstat -antp | grep 42911
```
*如果看到陌生的国外 IP，那就是它的控制端。*
#### 第二步：杀掉进程
既然文件已经被删了，直接杀掉内存里的进程：
```bash
kill -9 42911
```
#### 第三步：检查 SSH 密钥（**最重要的一步**）
绝大多数此类病毒会在你的系统里留一把“钥匙”，这样就算你改了密码，黑客也能直接进来。
运行：
```bash
cat /root/.ssh/authorized_keys
```
**仔细看输出的内容：**
* 如果你自己没配置过 SSH 密钥登录，**这里应该是一片空白**。
* 如果有内容，且是以 `ssh-rsa ...` 开头的一长串乱码，而你又不知道这是谁的，**那100%是黑客留下的后门**。
**清除方法：**
```bash
# 清空密钥文件（慎用，除非你确定你不依赖密钥登录）
> /root/.ssh/authorized_keys
# 或者编辑它删除陌生行
vi /root/.ssh/authorized_keys
```
#### 第四步：检查定时任务（复活点）
再次强调，检查定时任务，因为刚才那个 `.bash_logout` 消失了，很可能是通过定时任务脚本在控制。
```bash
cat /var/spool/cron/crontabs/root
# 或者
crontab -l
```
如果看到类似 `curl`, `wget`, 或者指向 `/tmp`, `/etc/` 下不明脚本的命令，**立即删除**。
#### 第五步：阻断恶意文件再次下载
为了防止黑客再次通过 `wget` 或 `curl` 下载病毒，可以暂时锁定 `/tmp` 目录的执行权限（可选，但这可能会影响部分正常服务，操作完后如果服务异常需改回）：
```bash
chmod 000 /tmp
chattr +i /tmp
```
*(注意：这只是临时阻断，修复完后建议恢复)*
-----
**最后建议：**
既然已经发现 `/tmp/sshd (deleted)`，说明你的服务器已经被攻破过。如果这台服务器只是跑一些不重要的数据，**重装系统**是最省心且唯一能保证 100% 安全的办法。
如果你打算继续用，**一定要立刻修改 Root 密码！**我问:
root@ser971939400951:~# ls -l /proc/42911/exe
ls -l /proc/199409/exe
lrwxrwxrwx 1 root root 0 Nov 30 16:00 /proc/42911/exe -> '/tmp/sshd (deleted)'
ls: cannot access '/proc/199409/exe': No such file or directory
root@ser971939400951:~# kill -9 42911 199409
-bash: kill: (199409) - No such process
root@ser971939400951:~# netstat -antp | grep 42911
root@ser971939400951:~# kill -9 42911
-bash: kill: (42911) - No such process
root@ser971939400951:~# cat /root/.ssh/authorized_keys
cat: /root/.ssh/authorized_keys: No such file or directory
root@ser971939400951:~# Gemini 回答：
目前的情况比刚才要好很多，但**警报尚未解除**。
我们先解读一下刚才的输出结果：
1. **进程已死**：`kill -9 42911` 提示 `No such process`，说明那个恶意的 `/tmp/sshd` 进程**已经被成功杀掉了**（或者是它自己崩溃了）。
2. **没有 SSH 后门**：`cat /root/.ssh/authorized_keys` 提示文件不存在。这是一个**好消息**，说明黑客没有（或者来不及）在你的系统里写入免密登录的 SSH 公钥。
3. **网络连接断开**：`netstat` 没有结果，说明随着进程被杀，它与黑客服务器的连接也断开了。
-----
### ⚠️ 核心问题：它为什么会“重生”？
这种病毒通常都有\*\*“复活机制”\*\*。如果不把它的“根”挖出来，过不了几分钟（或者你重启服务器后），它又会重新下载并运行。
请立即执行以下三步排查“复活点”：
#### 第一步：严查定时任务（Crontab）—— 90% 的病毒藏在这里
大多数挖矿病毒会每隔几分钟运行一次脚本来检查自己是不是被杀掉了。
运行以下命令，把所有用户的定时任务都打出来：
```bash
cat /var/spool/cron/crontabs/root
ls -la /etc/cron.d/
cat /etc/crontab
```
**如何判断：**
* 如果你看到任何包含 `curl`, `wget`, `pastebin`, 或者指向 IP 地址的命令。
* 如果你看到指向 `/tmp/` 目录下奇怪文件的命令。
* **如果不确定，请把输出结果截图或复制发给我。**
#### 第二步：检查启动项（rc.local）
有些病毒会写在开机启动脚本里。
运行：
```bash
cat /etc/rc.local
```
* 正常情况下这个文件可能是空的，或者只有 `exit 0`。
* 如果里面有奇怪的脚本路径，告诉我。
#### 第三步：检查 Systemd 服务
有些高级一点的病毒会伪装成系统服务。
运行以下命令，查找最近变动过的服务文件：
```bash
find /etc/systemd/system/ -mtime -2
```
* 这个命令会列出**最近2天内**被修改过的服务文件。如果有看起来名字很奇怪的服务（比如乱码，或者名字模仿系统服务如 `mysqldd.service` 多了个d），需要警惕。
#### 第四步：确认 CPU 是否安静了
再次运行 `top` 命令：
```bash
top
```
观察前几行，确保没有新的占用 90%-100% CPU 的奇怪进程冒出来。
-----
**等待你的下一步反馈。如果定时任务（第一步）里是空的，我们再查别的。**我问：
Gemini 回答：
**抓到了！这就是病毒的“老巢”！**
看你截图中的 `cat /var/spool/cron/crontabs/root` 输出部分（紫色背景第一段），那两行密密麻麻的命令就是罪魁祸首。
### 🔍 你的截图暴露了什么？
1. **`@reboot ...`**：这句话的意思是：**每次服务器重启**，都要运行后面那串病毒脚本。
2. **`* * * * * ...`**：这句话的意思是：**每一分钟**，都要运行一次病毒脚本。
* 这就是为什么我们刚刚杀掉进程，它可能一会又会冒出来的原因。
3. **病毒文件伪装**：
* 它藏在 `/var/tmp/apt.log`（伪装成日志文件）。
* 它藏在 `/root/.bash_logout`（就是我们之前看到的那个进程）。
4. **自我保护机制**：脚本里有 `chattr -i`，说明病毒给这些文件加了“无敌锁”（Immutable属性），普通删除命令 `rm` 是删不掉它们的，必须先解锁。
-----
### ⚔️ 最终清除行动
请严格按照以下步骤操作，手速要快，因为那个定时任务每分钟都会尝试修复病毒。
#### 第一步：清除定时任务（切断供血）
运行编辑命令：
```bash
crontab -e
```
* 如果是 `vi/vim` 编辑器：移动光标到那两行乱码上，连续按两次 `d` 键（`dd`）删除行，直到删干净，然后输入 `:wq` 回车保存。
* 如果是 `nano` 编辑器：按 `Ctrl+K` 剪切（删除）行，然后按 `Ctrl+X`，再按 `Y`，最后回车保存。
* **或者（如果你确定没有其他重要的定时任务）：** 直接运行 `crontab -r` 清空所有定时任务。
#### 第二步：解锁并粉碎病毒文件
病毒给文件加了锁，直接删会提示“Operation not permitted”。必须先解锁：
```bash
# 1. 解锁并删除 /var/tmp/apt.log
chattr -i /var/tmp/apt.log
rm -rf /var/tmp/apt.log
# 2. 解锁并删除 /root/.bash_logout
chattr -i /root/.bash_logout
rm -rf /root/.bash_logout
# 3. 再次检查 /tmp 下有没有残留
ls -al /tmp/
# 如果有奇怪的文件（比如 sshd），也解锁删除
chattr -i /tmp/sshd
rm -rf /tmp/sshd
```
#### 第三步：最后一次杀进程
因为刚才定时任务可能又运行了一次，我们最后补一刀：
```bash
# 查找所有包含 apt.log 或 bash_logout 的进程并杀掉
pkill -f apt.log
pkill -f bash_logout
```
#### 第四步：修改 Root 密码（必须做！）
黑客既然能写入定时任务，说明已经完全拿到了 Root 权限。现在清理干净后，**必须**立刻改密码，否则他拿原来的密码直接 SSH 连进来，你刚才做的全白费。
```bash
passwd
```
*输入两遍新密码（输入时看不到字符是正常的）。*
-----
### 🎉 验证是否成功
做完以上步骤后，运行：
```bash
top
```
观察 1 分钟。如果没有出现 CPU 占用率 99% 或 100% 的奇怪进程，恭喜你，你的服务器终于干净了！我问：
Gemini 回答：
这是一个非常重要的发现！
**`bash: crontab: command not found`** 是一个**巨大的红色警报**。
正常情况下，Linux 系统一定会有 `crontab` 命令。这说明**黑客为了防止你删除他的定时任务，直接把系统里的 `crontab` 管理工具给删掉了！** 这是一种非常恶心但典型的“守塔”行为。
不用担心，虽然工具没了，但配置文件还在（你上一张截图已经看到了）。我们直接通过修改文件来清除它。
请严格按照以下步骤操作：
### 第一步：手动清除定时任务文件
既然不能用 `crontab -e`，我们就直接修改源文件。
1. **编辑文件**：
尝试用 `nano` 编辑器打开它（如果 `nano` 也没了，就试 `vi`）：
```bash
nano /var/spool/cron/crontabs/root
```
*(如果是 `vi`，命令是 `vi /var/spool/cron/crontabs/root`，按 `d` `d` 删除行，直到清空，输入 `:wq` 保存)*
2. **如果提示无法保存/权限不足**：
说明黑客加了文件锁。先解锁，再清空，再加锁（防止他写回来）：
```bash
# 1. 解锁
chattr -i /var/spool/cron/crontabs/root
# 2. 清空文件（直接用重定向符号清空，比编辑器快）
> /var/spool/cron/crontabs/root
# 3. 再次确认是否清空
cat /var/spool/cron/crontabs/root
# (应该没有任何输出，或者是空的)
# 4. 锁定文件（这一步很重要，暂时锁定防止病毒写回）
chattr +i /var/spool/cron/crontabs/root
```
### 第二步：清理 Systemd 服务（根据你的截图）
你运行的 `find` 命令列出了很多最近修改的服务。其中大部分（如 `networking`, `ssh`, `docker`）看起来是因为你可能刚重装过系统或进行了大更新，它们的时间戳比较新是正常的。
但是，我们需要重点检查和你自己安装的软件相关的，特别是 **PM2**。
截图里显示了 `pm2-root.service`。很多时候，黑客发现这台机器有 Node.js 环境（你这台显然有），会把挖矿脚本藏在 PM2 的进程列表里。
请运行：
```bash
pm2 list
```
**观察输出：**
* 看有没有名字很奇怪的进程（比如 `xmr`, `miner`, `crypto`，或者乱码）。
* 如果有，运行 `pm2 delete [id]` 删除它，并 `pm2 save` 保存。
### 第三步：修复被删除的系统工具
因为黑客删了 `crontab`，你需要把它装回来，否则系统定时任务会跑不起来。
根据你的系统（Debian/Ubuntu）：
```bash
apt-get update
apt-get install cron
```
*(如果是 CentOS/RedHat，用 `yum install cronie`)*
装好后，再次运行 `crontab -l` 看看能不能正常显示（应该是空的）。
### 第四步：重启并最终验证
做完上述所有步骤（清空定时任务文件、删除病毒源文件、杀进程）后：
1. **重启服务器**：
```bash
reboot
```
2. **重启后立即检查**：
等 1-2 分钟，连上 SSH，立刻运行：
```bash
top
```
如果 CPU 占用率很低（\<5%），且没有奇怪进程，**恭喜你，战斗结束！**
-----
**总结你的操作顺序：**
1. 用 `chattr -i` 解锁并用 `> ...` 清空 `/var/spool/cron/crontabs/root`。
2. 安装回 `cron` 工具。
3. 检查 `pm2 list`。
4. 重启验证。
等你重启后的好消息！最后搞掂了，一切恢复正常，CPU 占用恢复到正常水平了，基本上就是 0%-1% 这样子了。
