Restreindre cron et at : maîtriser qui planifie des tâches

Par défaut, sur beaucoup de systèmes, n'importe quel utilisateur peut planifier des tâches avec crontab ou at. C'est un moyen discret pour un attaquant d'assurer sa persistance (relancer une porte dérobée toutes les minutes) ou d'exécuter du code à retardement. Ce guide montre comment restreindre cron et at aux seuls comptes autorisés avec cron.allow et at.allow, puis durcir les permissions des fichiers de planification. Pour administrateurs Linux, sur Debian/Ubuntu et RHEL/AlmaLinux. Aligné CIS Benchmarks. Toutes les sorties proviennent d'un test réel.

Ce que vous allez apprendre

Comprendre la logique allow / deny de cron et at
Restreindre la planification aux comptes autorisés
Durcir les permissions de /etc/crontab, /etc/cron.d et des répertoires cron.*
Vérifier qu'un utilisateur non autorisé est bien refusé

Prérequis

Un accès root (ou sudo), et les paquets cron et at installés si vous les utilisez. Ces réglages s'appliquent immédiatement, sans redémarrage.

Comment cron et at décident qui a le droit

L'accès se contrôle avec deux paires de fichiers : /etc/cron.allow / /etc/cron.deny pour cron, /etc/at.allow / /etc/at.deny pour at. La logique est la suivante :

Si cron.allow existe, seuls les utilisateurs qui y figurent peuvent utiliser crontab ; cron.deny est alors ignoré.
Sinon, si cron.deny existe, tout le monde peut sauf les utilisateurs listés.
La même logique s'applique à at.allow / at.deny.

La liste blanche (allow) est toujours préférable à la liste noire (deny) : un fichier deny oublié laisse passer tout le monde, alors qu'un allow ne laisse passer que les comptes explicitement autorisés. La bonne pratique consiste donc à créer cron.allow et at.allow (avec root et les rares comptes légitimes) et à supprimer les fichiers deny.

Restreindre cron

Créer la liste blanche avec les seuls comptes autorisés (ici root) et la protéger :

echo root | sudo tee /etc/cron.allow
# Debian/Ubuntu : le fichier doit rester lisible par le groupe "crontab"
sudo chown root:crontab /etc/cron.allow && sudo chmod 640 /etc/cron.allow
# RHEL/AlmaLinux : groupe root
# sudo chown root:root /etc/cron.allow && sudo chmod 640 /etc/cron.allow

Supprimer la liste noire pour ne garder que la logique allow :
Fenêtre de terminal
```
sudo rm -f /etc/cron.deny
```

Le lab confirme l'effet : un utilisateur non listé (alice) qui tente d'éditer sa crontab est refusé, cron vérifiant cron.allow :

$ su alice -c "crontab -e"
You (alice) are not allowed to use this program (crontab)

Restreindre at

On applique exactement la même approche à at :

echo root | sudo tee /etc/at.allow
sudo chown root:root /etc/at.allow && sudo chmod 640 /etc/at.allow
sudo rm -f /etc/at.deny

Sur RHEL/AlmaLinux, le contrôle CIS attribue at.allow au groupe daemon (chown root:daemon) ; sur Debian/Ubuntu, root:root en 640 convient.

Vérification avec un compte non autorisé :

$ su alice -c "at now + 1 minute"
You do not have permission to use at.

Durcir les permissions des fichiers cron

Les fichiers et répertoires de cron exécutent des commandes en tant que root. S'ils sont lisibles ou modifiables par d'autres, un utilisateur peut découvrir des tâches sensibles (mots de passe en clair dans une ligne de commande) ou, pire, y injecter du code. Par défaut, ils sont trop ouverts. Le lab relève sur Debian :

-rw-r--r-- 1 root root /etc/crontab          # 644, lisible par tous
drwxr-xr-x 2 root root /etc/cron.d           # 755
drwxr-xr-x 2 root root /etc/cron.daily       # 755

On restreint l'accès à root seul :

sudo chown root:root /etc/crontab
sudo chmod 600 /etc/crontab
sudo chmod 700 /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly /etc/cron.d
sudo chown root:root /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly /etc/cron.d

Vérifier

# Les listes blanches existent (640), sans liste noire
ls -l /etc/cron.allow /etc/at.allow
ls /etc/cron.deny /etc/at.deny 2>/dev/null   # ne doivent plus exister

# Permissions verrouillées sur les fichiers cron
stat -c '%n %a %U %G' /etc/crontab /etc/cron.d /etc/cron.daily

# Un compte non autorisé est bien refusé
su - <utilisateur_test> -c "crontab -l"   # doit afficher "not allowed"

Sécurité et points de vigilance

Ne pas oublier root dans cron.allow : sans lui, même root pourrait être gêné pour gérer ses crontabs personnelles (les tâches système de /etc/crontab continuent de tourner, mais l'édition via crontab est filtrée).
Lister uniquement les comptes qui en ont réellement besoin. Les services modernes utilisent plutôt des timers systemd, qui ne dépendent pas de cron.
Ne jamais mettre de secret en clair dans une ligne cron : tout utilisateur pouvant lire le fichier le verrait.

Dépannage

Symptôme	Cause probable	Solution
Un utilisateur légitime est refusé	absent de `cron.allow`	l'ajouter dans `/etc/cron.allow`
Tout le monde peut encore planifier	`cron.allow` absent et `cron.deny` vide	créer `cron.allow`, supprimer `cron.deny`
`at` refuse tout le monde sauf root	comportement normal avec `at.allow` = root	ajouter les comptes légitimes
Tâche cron qui ne s'exécute plus	permissions trop restrictives sur un script	le script doit rester exécutable par root

À retenir

Préférer la liste blanche : créer cron.allow et at.allow, supprimer les fichiers deny.
Si cron.allow existe, lui seul fait foi (cron.deny ignoré).
Toujours inclure root dans les listes blanches.
Durcir les permissions : /etc/crontab en 600, les répertoires cron.* en 700 root:root.
Jamais de secret en clair dans une ligne cron (lisible selon les droits).
Sur Debian/Ubuntu, cron.allow doit être lisible par le groupe crontab : 640 root:crontab, jamais 600.
CIS : RHEL 9 v2.0.0 sections 2.4.1.x / 2.4.2.1 ; Ubuntu 22.04 et 24.04 sections 5.1.x. ANSSI-BP-028 n'a pas de règle dédiée (application du moindre privilège).

Prochaines étapes

Planifier des tâches avec cron Maîtriser la syntaxe et les bonnes pratiques de cron.

Permissions et propriété des fichiers Corriger les droits dangereux sur l'ensemble du système.

Le hub durcissement Linux La démarche complète et les autres mesures.