cron 目录为什么必须收紧
计划任务的执行者是 cron 守护进程，而它执行任务时通常以 root 或任务指定的用户身份运行。如果任务配置文件或目录对普通用户可写，任何本地账号都能植入一条定时运行的后门——不需要提权漏洞，也不需要被猜中口令。所以 cron 是少数几处「权限错误直接等同于完整控制权」的位置，值得单独建一条基线。
基本信息
| 加固项 | cron 配置与 spool 目录权限收敛 |
|---|---|
| 适用平台 | Linux（RHEL/CentOS/Debian/Ubuntu） |
| 风险等级 | 高 |
| 基线 | 任务文件与目录属主 root，权限按发行版加固要求收紧 |
| 覆盖范围 | 系统任务文件、cron 目录、用户任务 spool 目录 |
典型使用场景
- 基线核查：确认任务文件与目录无人可写
- 部署事故排查：以宽松权限部署脚本后，目录权限被意外放开
- 入侵排查：植入定时任务是常见的持久化手法，权限是第一条线索
- 多用户主机治理：共享服务器上任务目录的写权限尤其要确认
- 合规整改：计划任务权限是访问控制与入侵防范条款的检查项
核查命令
核查命令
stat -c '%a %U:%G %n' /etc/crontab
stat -c '%a %U:%G %n' /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly
stat -c '%a %U:%G %n' /var/spool/cron /var/spool/cron/crontabs 2>/dev/null
find /etc/cron* -type f -not -user root -print 2>/dev/null # 非 root 属主的任务文件
cat /etc/cron.allow /etc/cron.deny 2>/dev/null # 谁被允许使用任务加固
加固
chown root:root /etc/crontab /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly
chmod 600 /etc/crontab
chmod 700 /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly
chown -R root:root /var/spool/cron 2>/dev/null && chmod 700 /var/spool/cron 2>/dev/null
stat -c '%a %U:%G %n' /etc/crontab /etc/cron.d # 复核基线对照
| 路径 | 建议权限 | 说明 |
|---|---|---|
| /etc/crontab | 600 root:root | 系统级任务定义，只有 root 需要读 |
| /etc/cron.d | 700 root:root | 用户任务投递目录，可写即等于可提权 |
| cron.hourly 等目录 | 700 root:root | 目录内脚本会被定时以 root 执行 |
| /var/spool/cron | 700 root:root | 用户任务的实际存放位置，最易被遗忘 |
| /etc/cron.allow 与 cron.deny | 按发行版加固要求收紧 | 控制哪些账号可以使用计划任务 |
权限收紧前确认没有非 root 工具直接向这些目录写任务：个别发行版的 cron 实现或第三方部署脚本会以其他身份投递文件。收紧后要验证定时任务仍能正常触发，避免把「权限合规」做成「业务中断」。
不要只改权限不看内容：权限正确的目录里同样可能存在已被植入的恶意任务，两者要一起核查。另外不同发行版的默认权限并不一致，报告的基线列应写明采用的加固要求来源，而不是把发行版默认值当成基线结论。
与现代机制的边界
cron 不是唯一的时间触发机制：systemd timer、anacron、以及应用自带的调度组件都能实现定时执行。这条基线的覆盖范围仅限 cron 相关的文件与目录，做主机加固时要把其他机制一并列出，避免出现「cron 权限完美但 timer 目录随意可写」的不对称局面。