Cron jobs, especially those running as root, are a commonly overlooked security consideration — a misconfigured scheduled task can become a privilege escalation path or a persistence mechanism for an attacker.
Why Cron Jobs Are a Security Consideration
Cron jobs often run with elevated privileges (root's crontab) on a schedule, executing scripts or commands automatically — if the script/command they execute can be tampered with by a lower-privileged user, this becomes a direct path to privilege escalation.
Reviewing Existing Cron Jobs
sudo crontab -l -u root
ls -la /etc/cron.d/
ls -la /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/ /etc/cron.monthly/Review everything scheduled, especially anything running as root, for legitimacy and correctness.
Checking Permissions on Scripts Executed by Cron
ls -la /path/to/script-executed-by-cron.shA script executed by a root cron job should not be writable by any non-root user — if it is, any user who can write to it effectively gains the ability to execute arbitrary code as root at the next scheduled run.
Fixing Insecure Script Permissions
sudo chown root:root /path/to/script.sh
sudo chmod 700 /path/to/script.shChecking the Full Path Used in Cron Commands
* * * * * /usr/local/bin/backup.shAlways use full, absolute paths in cron entries rather than relying on PATH resolution — cron's environment differs from an interactive shell's, and relying on PATH resolution could inadvertently execute a malicious script placed earlier in a manipulated PATH.
Restricting Who Can Create Cron Jobs
sudo nano /etc/cron.allowIf this file exists, only listed users can create their own crontabs — use this to restrict cron access to specifically authorized users rather than allowing any user with an account to schedule their own tasks.
Auditing for Unauthorized Cron Jobs (Sign of Compromise)
See How to Detect and Respond to a Compromised VPS — unfamiliar cron entries are a common persistence mechanism attackers use to maintain access even after other cleanup, since a scheduled task quietly re-establishes access on a recurring basis.
Logging Cron Execution
sudo journalctl -u cronReview cron execution logs periodically, particularly checking for unexpected new entries or unusual execution patterns.
Securing Script Content, Not Just Permissions
Beyond file permissions, review the actual content of scripts run by privileged cron jobs — avoid dynamically constructing commands from untrusted input, and follow general secure scripting practices given these run with elevated privileges.
Using systemd Timers as an Alternative (With Better Logging)
See How to Set Up systemd Timers as a Cron Alternative — systemd timers offer somewhat better logging/auditability integration than traditional cron, worth considering for security-sensitive scheduled tasks.
Common Errors
Discovering a cron job you don't recognize — treat this as a potential indicator of compromise; investigate immediately per How to Detect and Respond to a Compromised VPS rather than simply deleting it without understanding its origin.
Continue Reading
- Understanding and Preventing Privilege Escalation Attacks
- How to Detect and Respond to a Compromised VPS
- How to Set Up systemd Timers as a Cron Alternative
Browse more articles in Server Security & Hardening.
