计划任务是持久化的重灾区
要在 Linux 上长期驻留，最简单的方法不是维持进程，而是写一条计划任务：机器重启也照样执行，且大多数运维人员不会每天查看。攻击者常用的一行流是下载脚本并直接交给解释器执行，或定时回连指挥端。因此计划任务核查的目标很明确——每一条任务都能说清来源与用途，说不清的就是待查对象。
基本信息
| 加固项 | 计划任务与自启项核查 |
|---|---|
| 适用平台 | Linux（systemd、cron、anacron） |
| 风险等级 | 高 |
| 判读 | 每条任务有来源说明；出现下载并执行的一行流按事件处理 |
| 覆盖范围 | 用户 crontab、系统 cron 目录、systemd timer、anacron、启动脚本 |
典型使用场景
- 入侵排查：计划任务是痕迹最集中的位置之一，必查
- 基线核查：确认设备上只有经审批的定时任务
- 运维交接：任务来源不明的环境，先从计划任务开始梳理
- 故障排查：任务执行失败或重复执行导致资源异常时定位来源
- 清理废弃项：历史遗留的备份或监控脚本长期无人维护
核查命令
核查命令
crontab -l 2>/dev/null # 当前用户的任务
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
cat /etc/cron.d/* 2>/dev/null | grep -v '^#' | head -20
ls -la /etc/cron.hourly/ /etc/cron.daily/ 2>/dev/null
systemctl list-timers --all --no-pager | head -20 # systemd 定时器
cat /etc/rc.local 2>/dev/null | head # 传统启动脚本五个持久化面
| 位置 | 特征 | 核查要点 |
|---|---|---|
| 用户 crontab | 存放在 spool 目录，按用户分开 | 只查 root 会漏，需遍历全部账号 |
| /etc/cron.d 与 cron.* | 系统级任务目录 | 关注非 root 属主与最近修改时间 |
| systemd timer | 以单元形式存在，易被忽略 | 定时触发的是服务单元，要连服务一起看 |
| anacron | 面向不定期开机的机器 | 任务集中在配置文件中，易被遗忘 |
| rc.local 与启动脚本 | 传统自启入口 | 确认文件是否存在以及内容是否被改动 |
发现「下载并执行」形式的一行流（把网络内容取回后直接交给 shell 执行）按入侵事件流程走：先封存证据，记录文件内容与修改时间，再决定处置方式。直接删除会破坏时间线，也不排除还有其他驻留点。
有三个面容易漏：各用户 crontab 分散在 spool 目录下，只查 root 会漏掉其他账号；systemd timer 与 cron 是完全独立的两套机制；anacron 在容器与虚拟机环境中也常被使用。核查时把这三个面与系统 cron 目录一起覆盖，才算完整。
按时间线关联分析
计划任务的价值不只在内容，还在时间。把任务的创建与修改时间与账号文件、授权文件、审计日志的变更时间放在同一条时间线上，常能还原出一串连续动作：某时刻有账号被创建，随后授权文件被改写，紧接着出现新的定时任务。这种关联比孤立地看一条任务更容易判断是否为攻击痕迹。