Guide des ports Telnet : accès à distance existant sur le port 23

Telnet ouvre une connexion TCP et présente une session de terminal textuelle. Une fois que le serveur a accepté la connexion, le client et le serveur peuvent négocier les options du terminal, puis l'utilisateur envoie des commandes et reçoit le résultat sous forme de texte brut.

Cette simplicité est la raison pour laquelle Telnet a survécu dans la gestion des appareils, les laboratoires, les équipements de fabrication et les anciens appareils. C’est aussi pourquoi c’est risqué : sans tunnel crypté séparé, toute personne capable de capturer le trafic entre le client et le serveur peut lire les informations d’identification et les commandes.

SSH a remplacé Telnet pour la plupart des administrations à distance, car SSH crypte la session, vérifie la clé de l'hôte du serveur et prend en charge une authentification plus forte. SSH utilise normalement le port TCP 22, tandis que Telnet utilise normalement le port TCP 23.

Si l'appareil prend en charge SSH, utilisez SSH au lieu de Telnet. Conservez Telnet uniquement pour les systèmes qui ne peuvent pas être mis à niveau, pour un accès à un laboratoire isolé ou pour de courts flux de travail d'urgence pour lesquels des contrôles compensatoires sont déjà en place.

Telnet apparaît toujours sur les anciens routeurs et commutateurs, les systèmes PBX, les serveurs de console hors bande, les contrôles de bâtiments, les contrôleurs industriels, les baies de stockage, les imprimantes et les appareils de fournisseurs conçus avant que SSH ne devienne la norme.

Il est également utilisé comme simple client de diagnostic pour les services TCP bruts, bien que les outils modernes tels que nc, ncat, curl, openssl s_client et les clients de protocole spécialement conçus offrent généralement une meilleure visibilité et moins de surprises.

Le port 23 ne devrait presque jamais être ouvert à l'Internet public. Public Telnet attire des analyses automatisées, des attaques par mot de passe par défaut, des activités de botnet et des prises de contrôle opportunistes d'appareils. Si un service Telnet est accessible depuis l’extérieur d’un réseau approuvé, traitez-le comme une exposition urgente à examiner.

Si Telnet est inévitable, limitez-le à un VLAN de gestion, un VPN, un hôte bastion, un jump box, un réseau de console série ou une liste blanche d'IP source. L’objectif est de rendre Telnet accessible uniquement aux personnes et aux automatismes qui en ont réellement besoin.

Avant d'autoriser TCP 23, confirmez pourquoi Telnet est toujours requis et si SSH, la gestion HTTPS, une API de fournisseur ou une console série peuvent le remplacer. Identifiez ensuite qui doit se connecter, à partir de quel réseau, pendant combien de temps et quelle journalisation est disponible.

Un vérificateur de port peut vous dire si TCP 23 est accessible de l'extérieur, mais il ne peut pas vous dire si les informations d'identification sont sécurisées ou si l'appareil prend en charge les contrôles d'accès modernes. Testez le chemin de connexion réel uniquement à partir d'un réseau de confiance et évitez d'envoyer de vrais mots de passe sur des liens non fiables.

Sous Windows, le client Telnet peut être activé à des fins de test, mais le serveur Telnet ne doit pas être utilisé pour une administration normale. Si un système Windows a besoin d'un accès aux commandes à distance, utilisez PowerShell Remoting, SSH, RDP via une passerelle ou un autre chemin de gestion chiffré.

Sous Linux, les packages de serveur Telnet sont généralement inutiles et doivent rester désactivés. Si un démon hérité doit s'exécuter, liez-le à une interface privée et restreignez l'accès avec firewalld, ufw, nftables, iptables ou une liste blanche basée sur l'hôte.

Sur les appareils et appareils réseau, désactivez Telnet lorsque la gestion SSH ou HTTPS est disponible. Si les limitations du fournisseur imposent Telnet, placez le périphérique sur un réseau de gestion restreint et documentez l'exception afin qu'elle puisse être supprimée lors du prochain cycle d'actualisation.

Commencez par une vérification du port externe par rapport au nom d'hôte ou à l'adresse IP et au port 23. Si le résultat est ouvert, un client distant peut établir une connexion TCP avec l'écouteur Telnet. Cela ne signifie pas qu’il est possible de se connecter en toute sécurité à partir de l’Internet public.

Depuis un réseau de confiance, vous pouvez tester la bannière avec l'hôte telnet 23, l'hôte nc -vz 23 ou ncat. Sur le serveur ou l'appareil, inspectez l'état du service et les règles de pare-feu. Pour les appliances, vérifiez les paramètres de gestion car Telnet peut être activé séparément de SSH ou de l'administration Web.

Si le port 23 est fermé, Telnet peut être désactivé, l'appareil peut prendre en charge uniquement SSH, le service peut être lié à une interface de gestion ou un pare-feu peut bloquer le chemin. En cas d'expiration, un routeur, une liste de contrôle d'accès, une politique VPN, un pare-feu cloud ou une restriction d'adresse IP source peuvent supprimer le trafic.

Si le port est ouvert mais que la connexion échoue, inspectez le format du nom d'utilisateur, l'état du mot de passe, les règles de classe d'accès au périphérique, l'authentification locale ou par répertoire, la configuration de la ligne et les paramètres de verrouillage. Sur les équipements réseau, la politique de ligne VTY ou les ACL du plan de gestion expliquent souvent l'échec.

Désactivez Telnet autant que possible. Remplacez-le par SSH, la gestion HTTPS, l'accès VPN uniquement, la console série ou les outils du fournisseur. Supprimez les comptes par défaut, alternez les mots de passe partagés et maintenez le micrologiciel de l'appareil à jour jusqu'à ce que la dépendance Telnet disparaisse.

Si Telnet doit rester, isolez-le des réseaux d'utilisateurs et d'Internet, enregistrez les tentatives d'accès, surveillez les adresses sources inattendues et la propriété des documents. Traitez chaque exception Telnet comme une dette opérationnelle temporaire et non comme un modèle de gestion normal.