← Toutes les règles
SOCLE-CLD-GEN-045// Hardening (misc)élevéeétat du système de fichiers

Supprimer les fichiers de confiance Rsh

Garantit qu'aucun fichier de confiance .rhosts n'existe sous /root ou /home, supprimant tout accès R-services non authentifié basé sur l'hôte.

Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 2 normes

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

Un fichier ~/.rhosts déclare des couples hôte/utilisateur distants autorisés à se connecter ou exécuter des commandes en tant qu'utilisateur local sans mot de passe, via les R-services hérités (rlogin, rsh, rcp). Si le support de .rhosts/pam_rhosts est activé, ces fichiers accordent un accès non authentifié basé sur l'hôte, trivialement usurpable sur le réseau, un vecteur classique de compromission distante. Même quand les R-services semblent désactivés, des fichiers de confiance résiduels constituent une porte dérobée latente, d'où la sévérité haute. Aucun fichier .rhosts ne doit exister sous /root ni /home.

Ce que vérifie Pavois

Pavois lance un find en direct sur /root et /home (un seul système de fichiers via -xdev) pour tout fichier .rhosts. Énumérer les fichiers réellement présents sur le disque détecte les fichiers de confiance dans chaque répertoire personnel, y compris ceux, dormants, qu'un attaquant aurait pu déposer, au lieu de se fier à une liste de comptes statique.

describe command('find /root /home -xdev -name .rhosts 2>/dev/null') do
  its('stdout.strip') { should eq '' }
end

Comment vérifier qu’elle est appliquée

Recherchez tout fichier de confiance rhosts :

  • find /root /home -xdev -name .rhosts 2>/dev/null, la sortie attendue est vide (aucun chemin affiché).

Inspecter et investiguer

L'accès aux R-services, si PAM rhosts est activé, apparaît dans le journal d'authentification :

  • grep -E 'rhosts|rlogin|rsh' /var/log/auth.log (Debian/Ubuntu) / /var/log/secure (RHEL), affiche les décisions pam_rhosts.
  • La création de fichiers peut être suivie via une surveillance auditd des répertoires personnels (/var/log/audit/audit.log).

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 .rhosts), considérez sa présence comme suspecte, puis supprimez-le avec rm <chemin>. Vérifiez aussi que les paquets R-services (rsh-server, rsh-redone) sont supprimés et que pam_rhosts n'est pas activé.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

commandfind /home /root -maxdepth 2 -name .rhosts 2>/dev/null; ls -l /etc/hosts.equiv 2>/dev/null # rm -f each after review
reasonremoving .rhosts/hosts.equiv kills rsh trust, review (rsh should not be used)
resourcemanual
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Risque si non appliqué : tout fichier .rhosts peut accorder des connexions réseau non authentifiées et usurpables en tant que son propriétaire, une voie directe de compromission distante.

Précautions avant application : les systèmes modernes légitimes n'utilisent pas .rhosts ; en trouver un justifie une investigation comme possible artefact d'intrusion avant suppression. Retirer le fichier est sans impact (les R-services sont obsolètes), mais vérifiez qu'aucune tâche batch ancienne ne dépende de la confiance rsh/rcp, et migrez-la vers l'authentification SSH par clé.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS7.2.10, 7.2.9directper OS, see the benchmark tablehaute
NISTCM-7(a), CM-7(b), CM-6(a)support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne

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.

Sources & références