Vérifier qu'aucun fichier .forward n'existe
Garantit qu'aucun fichier .forward n'existe sous /root ou /home, bloquant la redirection de courrier non autorisée et l'exécution de commande à la livraison.
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
Le fichier ~/.forward d'un utilisateur indique au MTA local (sendmail/Postfix) de rediriger le courrier de cet utilisateur ailleurs, vers une adresse externe, ou vers un pipe qui exécute une commande arbitraire. Le risque est double : exfiltration silencieuse de courrier sensible hors de l'organisation, et la forme pipe permet à un utilisateur (ou à un attaquant ayant déposé le fichier) d'exécuter des commandes lors de la livraison du courrier. Sur un système durci, aucun fichier .forward ne doit exister sous /root ni /home.
Ce que vérifie Pavois
Pavois lance un find en direct sur /root et /home (en restant sur un seul système de fichiers via -xdev) pour tout fichier nommé .forward. Énumérer les fichiers réellement présents sur le disque, plutôt que de deviner à partir d'une liste fixe d'utilisateurs, permet de détecter les fichiers forward dans n'importe quel répertoire personnel, y compris les comptes récemment créés.
describe command('find /root /home -xdev -name .forward 2>/dev/null') do
its('stdout.strip') { should eq '' }
endComment vérifier qu’elle est appliquée
Recherchez tout fichier forward :
find /root /home -xdev -name .forward 2>/dev/null, la sortie attendue est vide (aucun chemin affiché).
Inspecter et investiguer
L'activité de redirection de courrier apparaît dans les journaux du MTA :
grep -E 'forward|to=<' /var/log/mail.log(Debian/Ubuntu) //var/log/maillog(RHEL), affiche les livraisons redirigées par un.forward, y compris les livraisons par pipe (|commande).journalctl -u postfixcorrèle la redirection avec son déclencheur.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être appliquée manuellement : examinez chaque fichier trouvé (find /root /home -xdev -name .forward), confirmez son intention avec le propriétaire du compte, puis supprimez-le avec rm <chemin>. Investiguez tout .forward redirigeant vers une commande, car il peut être malveillant.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | find /home /root -maxdepth 2 -name .forward 2>/dev/null # rm -f <path> per file after confirming the forwarding is not required |
|---|---|
| reason | deleting user .forward files can drop mail forwarding, review each before removing |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque si non appliqué : le courrier peut être exfiltré silencieusement et, via les forwards par pipe, des commandes arbitraires peuvent s'exécuter à la livraison.
Précautions avant application : certains utilisateurs légitimes redirigent volontairement leur courrier (par ex. vers un alias d'équipe). Confirmez avec le propriétaire avant de supprimer, et préférez un alias géré centralement dans /etc/aliases plutôt qu'un .forward par utilisateur. Supprimer un fichier en usage arrête seulement la redirection ultérieure ; cela ne casse pas la connexion ni le shell de l'utilisateur.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 7.2.10, 7.2.9 | direct | per OS, see the benchmark table | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.