Auditd 是唯一能从系统调用层抓到 cron 任务真实执行痕迹的工具，需监控 execve 系统调用、cron 配置文件变更，并补全日志上下文及覆盖 systemd timer 等非 cron 触发方式。
要真正看清 cron 任务到底有没有执行、谁执行的、执行了什么、成功还是失败，不能只看 crontab -l 或翻 /var/log/cron。Auditd 是唯一能从系统调用层抓到真实执行痕迹的工具，关键在于监控 execve 和保护配置路径。
捕获脚本实际执行行为
cron 本身只是调度器，真正干活的是内核的 execve() 系统调用。所有定时脚本（无论 bash、python 还是 perl）都绕不开它。
- 为关键脚本添加精准规则：
-a always,exit -F arch=b64 -S execve -F path=/opt/scripts/backup.sh -k cron_backup - 若脚本解释器不固定，可按解释器监控：
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/python3 -k cron_python_job - 加载后执行：
sudo augenrules --load，确保重启不失效 - 查执行记录：
sudo ausearch -k cron_backup --start today | aureport -i -f，输出含 UID、AUID、完整命令行、工作目录和退出码
盯紧 cron 配置文件变动
攻击者不会直接改脚本，而是悄悄往 /etc/crontab 或 /etc/cron.d/ 塞新任务。这些修改必须被实时捕获。
- 监控主配置：
-w /etc/crontab -p wa -k cron_master - 覆盖常用入口：
-w /etc/cron.d/ -p wa -k cron_d_dir，-w /etc/cron.daily/ -p wa -k cron_daily - 加过滤减少噪音：
-F auid>=1000 -F auid!=4294967295，只留真实登录用户操作 - 测试是否生效：用
sudo echo "* * * * * /bin/true" >> /etc/cron.d/test，再运行sudo ausearch -k cron_d_dir -i查日志
补全脚本内部执行上下文
Auditd 记录“谁调用了”，但不记录“脚本里干了什么”。需在脚本开头结尾手动打点，与 audit 日志交叉验证。
- 脚本第一行加：
echo "[$(date '+%Y-%m-%d %H:%M:%S')] UID=$(id -u) AUID=$(cat /proc/$$/loginuid 2>/dev/null || echo 'N/A') CMD=$0 $* STARTED" >> /var/log/cron_audit.log - 最后一行加：
echo "[$(date '+%Y-%m-%d %H:%M:%S')] EXIT_CODE=$? FINISHED" >> /var/log/cron_audit.log - 确保日志路径可写：
sudo touch /var/log/cron_audit.log && sudo chown root:adm /var/log/cron_audit.log
覆盖非 cron 的定时触发方式
很多“定时任务”其实走的是 systemd timer，不是 cron。漏掉它们等于留后门。
- 列出所有活跃 timer：
systemctl list-timers --all - 查某 timer 的执行命令：
systemctl cat myjob.timer→ 找ExecStart=行 - 为对应 service 文件中的
ExecStart路径加 audit 规则，例如：-a always,exit -F arch=b64 -S execve -F path=/usr/local/bin/myjob.sh -k systemd_myjob - 别忘了检查
/etc/cron.hourly/这类目录里的脚本，它们常被 cron 调用，但本身不在 crontab 里显式出现
