计划任务为什么是重点
root 的计划任务如果引用了普通用户可写的脚本，等价于把这些用户提升为 root 执行者：改一下脚本内容，下次执行就是 root 权限。审计要抓两件事：cron 目录与文件的权限和属主，以及任务引用脚本的可写性——包括脚本内部再调用的子脚本。后者最容易被忽略，也是实际出问题最多的地方。
基本信息
| 审计对象 | /etc/crontab、/etc/cron.d、/etc/cron.{hourly,daily,weekly,monthly}、各用户 crontab |
|---|---|
| 相关机制 | systemd timer 在多数发行版上承担部分定时任务 |
| 审计重点 | 文件权限与属主、被引用脚本路径与实际可写性 |
| 常见问题 | 脚本放在可写目录、目录存在 other 写权限、调用 /tmp 下的子脚本 |
| 加固方向 | 属主 root、去掉 other 写权限、统一由 /etc/cron.d 管理、变更纳入发布流程 |
| 适用平台 | Linux 各发行版，路径基本一致 |
检查项与期望
| 检查项 | 检查要点 | 期望状态 |
|---|---|---|
| cron 目录权限 | ls -la /etc/cron.d 等 | 属主 root，无 other 写权限 |
| 用户 crontab | crontab -l -u root | 内容可解释，无遗留调试项 |
| 全局可写文件 | find 查找 other 写权限文件 | 无输出结果 |
| 被引用脚本 | 逐一核对属主与权限 | root 属主，且非组内可写 |
| 子脚本调用 | 阅读脚本内容 | 不调用可写目录中的脚本 |
| 临时任务 | 核对创建时间与责任人 | 排障任务用完即删 |
审计命令
审计命令
ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly 2>/dev/null
crontab -l -u root 2>/dev/null
find /etc/cron* /var/spool/cron -type f -perm -o+w 2>/dev/null
# 找出引用可写目录（如 /tmp）的任务，逐一阅读
find /etc/cron* -type f -exec grep -l '/tmp/' {} \; 2>/dev/null
# systemd 系统同时检查定时器
systemctl list-timers --all | head -20收敛要点
收敛要点
1. 脚本目录与文件属主 root，组内可写受控，移除 other 写权限
2. 通过 /etc/cron.d 统一管理，而不是散落在各用户 crontab
3. 任务输出日志集中收集，失败与异常退出可告警
4. 变更计划任务纳入发布流程，避免口头临时添加
5. 定期复核：临时排障任务用完即删，避免长期驻留典型使用场景
- 主机基线巡检中的权限审计
- 应急排查：寻找可能的持久化位置
- 接管老系统时的计划任务摸底
- 渗透测试报告里权限配置问题的整改
- 发布流程规范化时把定时任务纳入
- 审计举证：给出任务清单与责任人
常见的疏漏是脚本本身权限正确，但它调用了一个位于 /tmp 或共享目录中的子脚本，权限链路上出现了可写点。
计划任务是常见的持久化位置。发现不认识的定时任务时先确认来源再处理，直接删除可能误伤业务任务造成故障。