Knowledgebase

Cron jobs often run with elevated privileges and access sensitive credentials, making them an underappreciated attack surface. This guide covers securing scheduled tasks against common risks.

Why Cron Security Matters

A cron job running as root, with a script that has weak file permissions or hardcoded credentials, presents a real risk — if an attacker can modify that script, they gain whatever privileges the cron job runs with.

Risk 1 — Scripts with Weak File Permissions

ls -la /usr/local/bin/backup.sh

If a script run by root's crontab is writable by a non-root user, that user can effectively achieve root privilege escalation by modifying the script.

Fix:

sudo chown root:root /usr/local/bin/backup.sh
sudo chmod 700 /usr/local/bin/backup.sh

Risk 2 — Hardcoded Credentials in Scripts

Avoid embedding passwords directly in cron scripts:

# Avoid this
mysqldump -u root -pMyPassword123 mydb

Use a restricted-permission credentials file instead:

mysqldump --defaults-extra-file=/root/.my.cnf mydb

sudo chmod 600 /root/.my.cnf

See How to Manage Environment Variables and Secrets on a VPS for the broader pattern.

Risk 3 — Running Cron Jobs as Root Unnecessarily

Only run a cron job as root if it genuinely requires root privileges — use a dedicated, less-privileged user's crontab otherwise:

crontab -e -u deploy

Risk 4 — World-Writable Cron Directories

ls -la /etc/cron.d/ /etc/cron.daily/

These should never be writable by non-root users — verify permissions haven't been accidentally loosened.

Risk 5 — Cron Scripts Downloading and Executing Remote Content

Avoid patterns like:

curl https://example.com/script.sh | bash

Executing remote content directly without review is risky — if that remote source is ever compromised (or the connection intercepted without TLS verification), the script executes whatever an attacker placed there. Download, review, then execute separately.

Auditing Existing Cron Jobs

sudo crontab -l
crontab -l -u deploy
cat /etc/crontab
ls /etc/cron.d/

Review every scheduled task, confirming it's still needed, running as the appropriate user, and referencing scripts with correct permissions.

Logging Cron Execution for Auditability

0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Beyond just debugging (see How to Schedule Tasks with Cron on a Linux VPS), logging provides an audit trail of what ran and when.

Monitoring for Unauthorized Cron Changes

Include cron directories in your file integrity monitoring:

/etc/cron.d    NORMAL
/etc/crontab   NORMAL
/var/spool/cron NORMAL

See How to Set Up File Integrity Monitoring with AIDE — an unauthorized new cron job is a common technique attackers use to maintain persistence after an initial compromise.

Common Errors

Cron job silently failing due to permission changes — verify the script's execute permission wasn't accidentally removed while tightening security.

Best Practices

• Run cron jobs as the least-privileged user that can accomplish the task
• Restrict script and credentials file permissions strictly
• Never pipe remote content directly into a shell without review
• Include cron configuration in file integrity monitoring

Continue Reading

• How to Schedule Tasks with Cron on a Linux VPS
• How to Manage Environment Variables and Secrets on a VPS
• How to Implement the Principle of Least Privilege on a Linux VPS

Browse more articles in Advanced Security & Compliance.