Désactiver le service telnet
Garantit que le service telnet.service en clair est désactivé et arrêté afin qu'aucun service telnet non sécurisé ne soit exposé.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
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 protocole telnet transporte tout le trafic, y compris les identifiants et mots de passe, en clair. Toute personne capable d'observer le réseau (un port miroir de commutateur, un rebond compromis, un renifleur Wi-Fi) peut capturer les identifiants de connexion et la session complète, et telnet n'offre aucune protection contre l'altération de type man-in-the-middle. Avec des alternatives chiffrées et fortement authentifiées (SSH) universellement disponibles, un service telnet actif constitue une exposition de sévérité élevée qui livre aux attaquants des identifiants et un accès distant.
Ce que vérifie Pavois
Pavois lit l'état effectif de l'unité via service('telnet.service') (systemctl is-enabled / is-active), il détecte donc telnet qu'il soit démarré directement ou par activation de socket, et tient compte des surcharges drop-in. Vérifier l'unité en cours d'exécution est supérieur à la recherche dans les fichiers de configuration : un service telnet peut être activé par socket ou par une surcharge qu'un balayage de /etc/xinetd.d/ ou similaire ne signalerait pas.
describe service('telnet.socket') do
it { should_not be_enabled }
it { should_not be_running }
endComment vérifier qu’elle est appliquée
Exécutez systemctl is-enabled telnet.service (attendu disabled, masked, ou Unit ... could not be found) et systemctl is-active telnet.service (attendu inactive). Confirmez que rien n'écoute sur TCP/23 avec ss -lntp | grep ':23' (attendu : aucune sortie).
Inspecter et investiguer
L'activité telnet et les transitions d'unité apparaissent dans journalctl -u telnet.service et dans le journal d'authentification (/var/log/secure sur RHEL/Alma). Les sockets en écoute se confirment avec ss -lntp | grep ':23'. Après désactivation, aucune nouvelle session telnet ne doit apparaître dans le journal d'authentification.
Remédiation
Le plan de durcissement de Pavois agit sur la ressource service nommée telnet : il exécute disable (pour qu'il ne démarre pas au boot) et stop (pour qu'il ne tourne pas maintenant). Il s'applique avec pavois harden apply. Pour une élimination complète, supprimez aussi le paquet telnet-server et tout telnet.socket pour qu'il ne puisse pas être réactivé par socket.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| action | disable, stop |
|---|---|
| name | telnet.socket |
| resource | service |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Désactiver telnet supprime une méthode d'accès distant. Le seul risque réel concerne les systèmes anciens où telnet est le seul moyen d'administration. Précautions : avant de désactiver, confirmez que SSH est installé, actif et joignable (systemctl is-active sshd et un test de connexion réussi) afin de ne pas perdre l'accès distant ; prévoyez un accès console/hors-bande en repli ; et migrez vers un transport chiffré tout script ou équipement qui dépendrait encore de telnet.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| NIST | 3.1.13 | support | 800-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.