核心要点（TL;DR）

• 后门排查顺序建议：先看crontab与systemd自启动项，再查进程与网络连接，最后做rootkit深度检测。
• crontab后门常藏在/etc/cron.d、/var/spool/cron与用户级crontab -l，需三处同时核对。
• ps看不到的进程可用/proc目录比对与unhide工具交叉验证，警惕内核级隐藏。
• 清理后门后必须轮换所有凭据并复核自启动项，否则重启即复发。

服务器突然变慢、带宽跑满、SSH 登录出现陌生 IP——多数运维的第一反应是改密码，但真正的问题往往藏在持久化入口里：攻击者早已通过 crontab、systemd 自启动项或隐藏进程埋好后门，改密码只是把门锁换了，人还在屋里。本文给出一套可直接照做的 Linux 后门检测流程，围绕 crontab 定时任务、自启动项与隐藏进程三条主线，每条都配具体命令与判定标准，目标是让你在 30 分钟内完成一次完整巡检。

一、为什么先查持久化：后门的三个落脚点

入侵者拿到 shell 后第一件事是确保「下次还能进来」。Linux 上成本最低、最常用的持久化位置只有三类：

• 定时任务：crontab、/etc/cron.d、anacron，几分钟一次自动拉起木马或反弹 shell。
• 自启动项：systemd 服务单元、rc.local、profile/bashrc 登录脚本、ld.so.preload 预加载库。
• 进程层隐藏：改名进程、/proc 隐藏、内核模块 rootkit，让 ps 与 top 看不到。

排查顺序建议由浅入深：定时任务 → 自启动项 → 进程与网络 → rootkit 深度检测。前两步成本低、命中率高，能解决大多数中小型入侵事件。

二、crontab 后门排查：三处位置一个都不能漏

很多人只执行 crontab -l 就下结论，这是最常见的漏检。攻击者通常直接写系统级目录，不碰用户表。完整排查要覆盖以下位置：

# 1. 当前用户与 root 的用户级任务
crontab -l; sudo crontab -l -u root

# 2. 系统级目录全量列出，重点看近期改动
ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/
cat /etc/crontab

# 3. 各用户 spool 目录（Debian/Ubuntu 路径）
ls -la /var/spool/cron/crontabs/ 2>/dev/null
ls -la /var/spool/cron/ 2>/dev/null

# 4. 按时间排序找异常文件
find /etc/cron* /var/spool/cron* -type f -mtime -30 -ls 2>/dev/null

判定可疑的依据：任务内容出现 curl、wget、base64 -d、/dev/shm、/tmp 路径；执行周期极短（每分钟）；文件属主不是 root；文件修改时间与系统升级记录不符。发现可疑条目先备份内容再删除，不要直接清空整张表，避免破坏业务定时任务。

提示：cron 的日志在 /var/log/cron 或 journalctl -u cron，可反查任务首次执行时间，帮助确认入侵时间窗口。

三、自启动项排查：systemd 与登录脚本

systemd 已成为主流发行版的自启动入口，攻击者常伪造一个名字像系统组件的服务单元。执行以下命令列出全部单元并按时间排序：

systemctl list-unit-files --type=service --state=enabled
systemctl list-units --type=service --all | grep -v "systemd"

# 找近期新增或修改的单元文件
find /etc/systemd/system /lib/systemd/system -name "*.service" -mtime -60 -ls

打开可疑单元，重点看 ExecStart= 指向的路径是否在 /tmp、/dev/shm、/var/tmp，以及是否带 Restart=always（被杀后自动复活）。除 systemd 外，还要检查传统入口：

• /etc/rc.local、/etc/init.d/ 下的非官方脚本；
• /etc/profile、/etc/bash.bashrc、各用户 ~/.bashrc 是否被追加反弹 shell 命令；
• /etc/ld.so.preload 是否被写入陌生 .so 文件（这是用户态 rootkit 的典型手法，正常系统该文件通常不存在）；
• ~/.ssh/authorized_keys 是否多出陌生公钥。

四、隐藏进程排查：ps 看不到怎么办

当 ps aux 与 ss -lntp 的结果对不上时，就要怀疑进程隐藏。核心思路是拿 /proc 目录与 ps 输出做交叉比对：

# 列出所有PID目录
ls /proc | grep -E "^[0-9]+$" | sort -n > /tmp/proc_pids.txt
# 列出ps可见PID
ps -eo pid --no-headers | tr -d " " | sort -n > /tmp/ps_pids.txt
# 差集即为隐藏嫌疑
diff /tmp/proc_pids.txt /tmp/ps_pids.txt

对可疑 PID 继续取证：ls -l /proc/PID/exe 看真实二进制路径（显示 deleted 说明文件已被删除但进程仍在跑），cat /proc/PID/cmdline 看启动参数，ls -l /proc/PID/cwd 看工作目录。若怀疑内核级隐藏，用 unhide proc 或 rkhunter --check 交叉验证；确认存在内核模块后门时，建议立即下线取证，避免在原机反复操作触发自毁逻辑。

五、处置与加固清单

确认后门后按以下顺序处置，顺序错了容易复发：

1. 隔离：安全组或 iptables 限制出站，切断反弹通道，但保留 SSH 管理入口。
2. 取证：备份可疑文件、crontab 内容、进程命令行与网络连接记录。
3. 清除：删除恶意定时任务与 systemd 单元，systemctl daemon-reload 后 disable，再 kill 进程并删除落地文件。
4. 轮换：更换全部 SSH 密钥、数据库口令、API Token，清理 authorized_keys 与 sudoers 中的陌生条目。
5. 复核：重启后重新执行本文全部检查项，确认无复活。

长期防护上，建议把上述命令固化成每周一次的基线比对脚本，对 /etc 与网站目录开启文件完整性监控；在主机层可借助 AegisX 的定时任务与进程异常监测能力，把「事后排查」变成「持续告警」，减少人工巡检遗漏。

行动建议：现在就登录一台生产服务器，按第二节与第三节的命令跑一遍，把输出存档作为基线。后门检测的价值不在于工具多高级，而在于你是否真的动手查了那三处最容易被忽略的位置。

常见问题（FAQ）

服务器CPU突然飙高，怎么快速判断是不是被植入了挖矿后门？

先定位高占用进程再顺藤摸瓜。用top -c或ps aux --sort=-%cpu取PID，执行ls -l /proc/PID/exe看真实可执行文件路径，若指向/tmp、/dev/shm或已删除文件（显示deleted）基本可判定可疑。随后查该进程的crontab与systemd单元来源，确认持久化入口后再kill并清理，切勿只杀进程不删入口。

crontab -l看不到异常，是不是就说明定时任务没被动手脚？

不一定。crontab -l只显示当前用户的表，攻击者常写入/etc/cron.d/、/etc/cron.hourly/、/var/spool/cron/crontabs/等位置，甚至篡改/etc/crontab。排查时应全量grep这些目录，并检查文件修改时间与属主，非root属主或近期被改动的任务文件都要重点复核。

ps命令查不到进程，但端口确实在监听，这种隐藏进程怎么找？

优先用/proc与ss交叉验证。执行ss -lntp看监听PID，再ls /proc比对PID目录是否与ps输出一致，缺失的PID目录即为隐藏线索。也可用unhide proc或rkhunter做比对。若确认存在内核级隐藏，建议直接下线取证，不要在原机反复操作，避免触发后门自毁逻辑。

发现后门清理干净后，还需要做哪些收尾动作？

清理只是第一步。必须轮换服务器上所有SSH密钥、数据库口令与API Token，检查authorized_keys与sudoers是否被加白，复核全部自启动项与定时任务，并比对关键二进制文件哈希。最后从可信基线重装或加固系统，开启文件完整性与登录审计，避免二次入侵。

普通站长没有安全团队，日常怎么低成本预防后门？

做好三件事即可显著降低风险：关闭密码登录改用密钥并限制来源IP、定期导出crontab与systemd单元清单做基线比对、对/etc与网站目录开启文件改动监控。若缺乏人力，可借助AegisX这类主机安全能力做定时任务与进程异常监测，把排查从被动应急变成持续告警。