Linux 定时任务安全排查实战：持久化后门检测与加固

作者

适用场景

Linux 定时任务安全排查实战的第一适用场景，是服务器已被入侵或疑似被入侵后的应急排查：攻击者获得 root 或应用账户权限后，最常用的持久化手段就是写入一条定时任务，让恶意脚本每隔几分钟自动执行、自动复活。第二个场景是日常安全基线巡检，通过定期审查计划任务清单，发现开发人员遗留的高危脚本、弱权限可篡改任务以及来源不明的可疑条目。第三个场景是自动化运维交接，接管一台陌生服务器时，先摸清全部定时任务才能判断哪些是业务必需、哪些是安全隐患。

前置条件

  • 一台 CentOS 7+/RHEL/Ubuntu/Debian 服务器，排查命令需以 root 身份或具备 sudo 权限执行
  • 已安装 cronie（RHEL 系）或 cron（Debian 系），systemd 服务器建议同时检查 systemd timers
  • 可选：安装 auditd 用于长期监控定时任务文件变更

原理说明

Linux 定时任务由 crond 守护进程驱动，配置分散在多个位置：用户级任务存放于 /var/spool/cron/<用户名>（Debian 系为 /var/spool/cron/crontabs/），系统级任务在 /etc/crontab 与 /etc/cron.d/ 目录，周期性脚本目录为 /etc/cron.hourly、cron.daily 等。crond 每分钟读取这些文件并按计划执行。攻击者偏好定时任务做持久化，原因有三：一是修改文件即可生效，无需重启服务；二是任务以指定用户身份运行，权限继承稳定；三是相比启动项更隐蔽，管理员日常较少巡检。典型后门特征包括：任务内容是一段远程下载命令（curl/wget 拉取脚本后执行）、任务脚本本身是一个反弹 Shell、或者一条”删除自身再重写自身”的自守护任务，用于在管理员删除挖矿进程后自动恢复。

操作步骤

第一步：汇总列出全部定时任务

依次执行以下命令，把散落在各处的任务一次性收齐：

# 所有用户级任务
for user in $(cut -f1 -d: /etc/passwd); do
  echo "== $user =="; crontab -l -u $user 2>/dev/null;
done

# 系统级任务
cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/

# systemd 定时器（常被忽略的第二个持久化点）
systemctl list-timers --all

第二步：识别可疑任务特征

重点筛查以下高危特征，命中即进入人工研判：

  • 包含 curl、wget、base64、python -c 组合的下载执行链
  • 任务指向 /tmp、/dev/shm、/var/tmp 等可写目录中的脚本
  • 任务脚本文件属主或权限异常（如 777、属主为 web 应用账户）
  • 时间频率异常密集（如 */1 每分钟执行）且业务上说不通
# 查找上述目录中近 7 天新建或修改的脚本
find /etc/cron* /var/spool/cron -type f -mtime -7 -ls

# 检查可写目录中的可疑脚本
ls -la /tmp /dev/shm /var/tmp | grep -v drwx------

第三步：加固定时任务写入权限

使用白名单机制限制谁能创建定时任务，并锁定关键文件防止被覆盖：

# 仅允许 root 与运维账户使用 crontab
echo root > /etc/cron.allow
echo opsuser >> /etc/cron.allow
rm -f /etc/cron.deny
chmod 600 /etc/cron.allow

# 关键系统任务文件设为不可变更属性
chattr +i /etc/crontab

# 用 auditd 监控定时任务配置变更
cat >> /etc/audit/rules.d/cron.rules <<'EOF'
-w /etc/cron.d/ -p wa -k cron_change
-w /var/spool/cron/ -p wa -k cron_change
-w /etc/crontab -p wa -k cron_change
EOF
augenrules --load

配置验证

先确认白名单生效：用未在 cron.allow 中的账户执行 crontab -e，应提示 you (xxx) are not allowed to use this program。再验证 auditd 监控：随便修改一次 /etc/cron.d/ 下的文件，执行 ausearch -k cron_change -i，应能看到包含时间、账户、进程的完整审计记录。最后复查 crond 运行状态：systemctl status crond 保持 active (running)。

常见问题

FAQ 1：删除了可疑任务，几分钟后又出现了怎么办？这说明存在自守护机制，通常有三处来源需要同步处理：一是任务本身负责重写任务文件，删除任务后先 kill 其派生进程；二是存在独立的守护脚本在别的任务或启动项里，用 grep -r "crontab" /etc/cron* /var/spool/cron 反查谁在写 crontab；三是恶意程序常驻内存自动重装，需先按进程定位二进制文件（ls -l /proc/<PID>/exe）再彻底清除，否则删多少次都会复活。

FAQ 2：chattr +i 后 crontab 编辑报错 Operation not permitted？这是预期行为，不可变更属性会同时挡住合法修改。需要调整系统任务时先执行 chattr -i /etc/crontab 解锁，改完再加回。注意该属性仅 root 可操作，且 xfs/ext4 文件系统才支持；若在容器环境中 chattr 不生效，属正常现象，可改用只读挂载或文件权限收敛替代。

总结

定时任务持久化是入侵后最常见、也最容易被忽视的驻留手段。排查的核心动作是”收齐、识别、加固”三步：用统一命令列出用户级、系统级、systemd timers 三类任务，按下载执行链、可疑路径、异常频率三个特征过滤，再通过 cron.allow 白名单、chattr 锁定与 auditd 审计把写入通道管起来。建议将本文的巡检命令纳入每周安全基线，持续验证，才能保证定时任务体系长期可控。