核心要点（TL;DR）
- 后门排查优先看三处：cron定时任务、systemd启动项、异常进程的父进程与可执行文件路径。
- 用crontab -l只能看当前用户，必须同时检查/etc/cron*、/var/spool/cron与systemd timer。
- 隐藏进程可用ps与/proc比对、unhide等工具交叉验证，重点看名字伪装成kworker、sshd的进程。
- 清理后门要同时删除文件、任务、启动项与进程，并排查SSH公钥与新增账号，否则极易复发。
服务器突然变卡、带宽跑满、SSH 登录出现陌生 IP——很多运维的第一反应是重启，但重启往往只是让后门重新加载一次。攻击者拿到权限后，真正难缠的不是那一次入侵，而是他留下的持久化入口。本文聚焦 Linux 云服务器后门检测中最容易被忽略、也最常被利用的三类位置：定时任务、启动项与隐藏进程，给出可直接复制执行的排查命令和判断标准，帮你在应急响应中快速锁定并清除后门。
为什么后门总藏在这三个地方
攻击者要在重启后仍能控制服务器，必须让恶意程序被系统自动拉起。Linux 上实现自动执行的手段有限，最常用的就是三类：
- 定时任务：cron 与 systemd timer，按分钟级周期拉起，隐蔽且易写。
- 启动项：systemd service、rc.local、init.d、profile 与 bashrc 登录脚本。
- 常驻进程：伪装成系统进程名，或用 rootkit 隐藏，配合前两者保活。
这三者构成一条完整的保活链：启动项负责开机拉起，定时任务负责掉线重拉，隐藏进程负责降低被发现概率。排查时按链条顺序推进，比零散地看日志高效得多。
第一步：定时任务排查
只执行 crontab -l 是远远不够的，它只显示当前用户的计划任务。用一条命令覆盖所有 cron 位置：
grep -r '' /etc/cron* /var/spool/cron /etc/crontab 2>/dev/null
同时检查 systemd timer，它与 cron 效果等价但更隐蔽：
systemctl list-timers --all ls -l /etc/systemd/system/*.timer
判断可疑任务，重点看命令内容而非时间：
- 出现
curl、wget、base64 -d、bash -i、/dev/tcp等下载或反弹特征。 - 脚本路径落在
/tmp、/var/tmp、/dev/shm或用户家目录隐藏目录。 - 任务名伪装成
sysupdate、dbus-update、apt-check等系统风格命名。
注意：/etc/cron.d 下的文件格式与 crontab 不同，多一列执行用户，检查时不要漏掉。
第二步：启动项与登录脚本排查
启动项是后门复活的根源，建议按下面清单逐项过一遍：
| 位置 | 检查命令 | 可疑特征 |
|---|---|---|
| systemd 服务 | systemctl list-unit-files --state=enabled | 陌生服务、ExecStart 指向 /tmp |
| rc.local | cat /etc/rc.local | 末尾追加的下载执行命令 |
| init.d | ls -lt /etc/init.d/ | 近期新增的脚本 |
| 登录脚本 | grep -r '' /etc/profile /etc/profile.d/ ~/.bashrc ~/.bash_profile | base64 解码、后台拉起进程 |
| 动态库劫持 | cat /etc/ld.so.preload | 文件存在即高度可疑 |
其中 /etc/ld.so.preload 尤其值得警惕：正常系统通常没有这个文件，一旦被写入恶意 so 路径，可劫持几乎所有命令，是 rootkit 的典型手法。发现后先记录内容再处理，不要直接删除，避免丢失线索。
第三步：隐藏进程与网络连接排查
先用常规手段列出进程，再用 /proc 交叉验证是否存在隐藏：
ps aux --sort=-%cpu | head -20 ls /proc | grep -E '^[0-9]+$' | wc -l netstat -antp 或 ss -antp
如果 /proc 下的数字目录数量明显多于 ps 显示的进程数，说明存在被隐藏的进程。对可疑 PID 进一步取证：
ls -l /proc/PID/exe cat /proc/PID/cmdline | tr '' ' ' ls -l /proc/PID/cwd cat /proc/PID/status | grep PPid
重点看三件事：可执行文件的真实路径是否在系统目录之外；父进程是否为 1 或已消失（说明是守护型后门）；是否存在到陌生 IP 的外联连接。名字伪装成 kworker、sshd、dbus-daemon 但路径异常的，基本可以判定为恶意进程。
清理与加固清单
确认后门后，按顺序处理，避免打草惊蛇：
- 取证：复制恶意文件、记录进程信息与网络连接。
- 断链：删除对应 cron 文件、systemd unit、rc.local 追加行与 ld.so.preload 条目。
- 杀进程：
kill -9 PID，并确认未被重新拉起。 - 堵入口：检查
~/.ssh/authorized_keys、/etc/passwd新增账号、/etc/sudoers变更，修改所有账号密码与密钥。 - 验证：重启后复查三类位置，确认无复发。
日常防护上，建议把关键目录的文件变更、异常外联和进程启动链纳入持续监控，而不是等出事再手工排查。AegisX 的主机安全能力可对定时任务、启动项变更与异常进程行为做实时告警，配合本文的排查流程，能把应急响应从「事后救火」前移到「事中阻断」。
行动建议
不要等到服务器变慢才检查。建议本周内完成一次全量排查：把上面的 cron、启动项、进程三类命令各跑一遍并留存基线输出，之后每月对比一次差异，任何新增项都要能说清来源。对暴露在公网的云服务器，同时收紧 SSH 登录方式、关闭不必要的端口，把攻击面压到最小，后门才没有落脚的地方。
常见问题（FAQ）
服务器CPU突然跑满，怀疑被挖矿，第一步该查什么？
先定位进程再顺藤摸瓜。用top -c或ps aux --sort=-%cpu找出高占用进程，记录其PID与可执行文件路径，然后执行ls -l /proc/PID/exe查看真实二进制位置，再用cat /proc/PID/cmdline确认启动参数。多数挖矿木马会伪装成kworker、dbus等系统进程名，但可执行文件往往落在/tmp、/var/tmp或用户家目录，路径异常即可判定可疑。
crontab -l没发现异常，是不是就说明定时任务没问题？
不够。crontab -l只显示当前用户的计划任务，攻击者常写入/etc/cron.d、/etc/cron.hourly、/var/spool/cron/root等位置，或使用systemd timer实现同等效果。排查时应执行grep -r '' /etc/cron* /var/spool/cron 2>/dev/null统一检索，并检查systemctl list-timers --all的输出，重点关注指向curl、wget、base64或/tmp路径的命令。
如何判断一个进程是不是被rootkit隐藏了？
用多源比对。分别执行ps aux、ls /proc按数字目录统计、以及netstat或ss查看监听端口，三者数量与PID应基本一致；若/proc下存在进程目录但ps看不到，基本可判定被隐藏。可安装unhide执行unhide proc交叉检测，同时用rpm -Va或debsums校验核心命令是否被替换，例如ps、ls、netstat的校验值异常说明系统命令已被篡改。
发现后门进程直接kill掉可以吗？
不建议只kill。多数后门由cron或systemd守护，kill后几秒内会被重新拉起，反而暴露你已发现。正确顺序是先取证：记录进程PID、可执行文件、网络连接与父进程，复制样本；再定位并删除对应的定时任务、启动项与文件；最后才kill进程并重启验证。清理后必须检查~/.ssh/authorized_keys、/etc/passwd新增账号与sudoers变更，堵住攻击者的其他入口。
云服务器上有没有必要部署主机入侵检测？
有必要，人工排查适合应急，日常防护靠持续监控。主机层应至少做到：关键目录（/etc/cron*、/etc/systemd/system、~/.ssh）文件变更告警、异常外联与矿池域名拦截、以及进程启动链审计。AegisX提供主机安全基线核查与异常进程、定时任务变更的实时告警能力，可与本文的手工排查流程配合，把偶发检查变成常态化发现。