“Telnet has a critical vulnerability introduced in 2015, recently patched.
Remote root authentication possible. PoC available.”
Voilà typiquement le genre d’info qui fait lever un sourcil… puis les deux.
Pas tant à cause de la vulnérabilité elle-même — le monde de la cybersécurité en voit passer tous les jours — mais à cause de ce qu’elle révèle :
👉 Telnet est encore utilisé. En production. En clair.
Et ça, en 2025, c’est un vrai problème.
🧨 Une vulnérabilité révélatrice d’un protocole à bout de souffle
La vulnérabilité évoquée est grave :
- authentification distante en root,
- sans interaction utilisateur,
- PoC public disponible,
- introduite il y a près de 10 ans,
- patchée… récemment.
Mais soyons honnêtes :
👉 si Telnet est encore exposé, cette vulnérabilité n’est qu’un bonus pour l’attaquant.
Telnet, par design :
- ne chiffre rien,
- transmet identifiants et commandes en clair,
- ne protège ni l’intégrité ni la confidentialité,
- n’offre aucun mécanisme de sécurité moderne.
Autrement dit : même sans CVE, Telnet est déjà une faille.
🏚️ Pourquoi Telnet est encore utilisé (et comment)
Malheureusement, les raisons sont connues — et souvent compréhensibles… mais pas excusables.
Les cas typiques :
- équipements legacy (réseau, industriel, médical),
- environnements OT / SCADA,
- appliances embarquées,
- scripts historiques jamais révisés,
- contraintes éditeur ou métier,
- “on a toujours fait comme ça”.
Résultat :
- port 23/TCP ouvert,
- comptes admin ou root,
- mots de passe partagés,
- parfois exposé hors du LAN.
🎯 Un cadeau pour tout attaquant interne, prestataire, ou pentester un peu curieux.
🚫 Pourquoi Telnet n’a plus rien à faire en production
Soyons clairs :
Telnet en prod = non-conformité sécurité.
Les risques concrets :
- interception réseau (ARP spoofing, MITM),
- vol d’identifiants,
- élévation de privilèges,
- absence de traçabilité fiable,
- exploitation automatisée.
D’un point de vue conformité (ISO 27001, NIS2, RGPD, HDS, etc.), c’est :
- ❌ absence de chiffrement,
- ❌ mauvaise gestion des accès,
- ❌ non-respect du principe de moindre privilège.
👉 Aucun RSSI sérieux ne peut défendre Telnet en clair aujourd’hui.
🩹 “Telnet sécurisé” : SSL / TLS, mieux… mais pas idéal
Certains environnements n’ont pas le choix immédiat.
Dans ces cas-là, Telnet encapsulé en SSL/TLS est un minimum.
Ce que ça corrige :
- chiffrement du flux,
- protection contre l’écoute passive,
- réduction du risque réseau.
Ce que ça ne corrige pas :
- protocole obsolète,
- surface d’attaque peu auditée,
- implémentations parfois douteuses,
- gestion des certificats souvent mal faite.
👉 Telnet-SSL, c’est du damage control, pas une bonne pratique cible.
🖥️ Cas particulier : IBM i / AS400 (le monde réel)
Soyons honnêtes :
pour les environnements IBM i (AS/400), le choix est souvent limité.
Sur ces plateformes, Telnet reste utilisé pour :
- l’accès 5250,
- certaines intégrations applicatives,
- des outils historiques.
Dans ce contexte, la seule option acceptable est :
- Telnet sécurisé via SSL/TLS,
- certificats correctement gérés,
- restriction réseau stricte.
👉 La documentation officielle de IBM détaille précisément la configuration TLS pour Telnet sur IBM i :
https://www.ibm.com/docs/fr/i/7.5.0?topic=tls-configuration-details-securing-telnet
⚠️ Important :
- certificat valide (pas auto-signé oublié),
- protocoles faibles désactivés,
- accès limité par IP,
- supervision active.
Ce n’est pas parfait, mais c’est le minimum vital.
✅ Les bonnes pratiques aujourd’hui
🔐 Si Telnet est encore utilisé :
- obligatoirement chiffré (SSL/TLS),
- certificats à jour,
- comptes non privilégiés,
- restriction IP stricte,
- journalisation renforcée,
- supervision et alertes.
🧪 Telnet côté client uniquement :
Telnet reste acceptable comme outil de test :
telnet serveur 25 telnet serveur 389
Pour :
- tester un port ouvert,
- lire une bannière,
- déboguer un service TCP.
👉 Jamais comme service exposé.
🔑 Pourquoi SSH est la norme (et depuis longtemps)
SSH a gagné pour de bonnes raisons :
- chiffrement fort,
- authentification par clé,
- MFA possible,
- traçabilité,
- durcissement fin.
Avec OpenSSH, on dispose en plus :
- d’un projet maintenu,
- audité,
- éprouvé,
- largement déployé.
👉 Tout ce qui est faisable en Telnet doit être migré vers SSH.
🧾 Conclusion : Telnet, le survivant qu’il faut enfin éteindre
Cette vulnérabilité “récemment patchée” n’est pas une surprise.
C’est un symptôme.
- Telnet est obsolète.
- Telnet en clair est dangereux.
- Telnet en prod est une dette technique et sécurité.
- Telnet-SSL est un pis-aller.
- SSH est le standard.
👉 En 2025, la vraie question n’est pas “est-ce patché ?”,
👉 mais “pourquoi c’est encore là ?”
Et si la réponse est “on n’a pas eu le temps”, alors il est temps de le planifier.
🔎 Encadré – Détection de Telnet dans un SI
Parce qu’avant de corriger, encore faut-il savoir où ça traîne…
🛰️ 1️⃣ Détection réseau avec Nmap (la base saine)
Le moyen le plus simple et le plus efficace pour identifier Telnet exposé reste un scan réseau ciblé.
Scan du port Telnet classique
nmap -p 23 --open 192.168.0.0/16
👉 Objectif :
- identifier les hôtes exposant 23/TCP,
- établir une première cartographie rapide.
Scan avec détection de service
nmap -p 23 -sV 192.168.0.0/16
Cela permet de :
- confirmer qu’il s’agit bien d’un service Telnet,
- identifier l’implémentation (vendor, version).
Recherche élargie (ports non standards)
nmap -p- --open -sT --min-rate 1000 192.168.0.0/16 | grep telnet
⚠️ Important :
Telnet est parfois déplacé sur des ports non standards pour “faire discret”.
👉 Spoiler : ça ne sécurise rien.
🧪 2️⃣ Détection via scanner de vulnérabilités (Nessus / Qualys / OpenVAS)
Les scanners identifient très bien :
- Telnet actif,
- Telnet en clair,
- Telnet sans chiffrement fort,
- versions vulnérables connues.
Avec Tenable Nessus, on retrouve généralement :
- “Cleartext Telnet Service”
- “Telnet Service Detection”
- “Weak Encryption or No Encryption”
👉 À classer immédiatement en High / Critical dans un rapport SSI.
Bonus :
- identification automatique des équipements réseau,
- corrélation avec d’autres faiblesses (comptes faibles, firmware obsolète).
📜 3️⃣ Audit de configuration système (le travail ingrat mais indispensable)
Sur les systèmes Linux / Unix :
Vérification des services actifs
systemctl list-unit-files | grep telnet
systemctl status telnet.socket
Vérification des ports à l’écoute
ss -tulpen | grep :23
ou
netstat -tulpen | grep :23
👉 Toute réponse positive = anomalie à traiter.
🧱 4️⃣ Audit firewall & équipements réseau
À ne surtout pas oublier :
- règles firewall internes,
- ACL sur switches / routeurs,
- équipements industriels ou métiers.
Points d’attention :
- Telnet autorisé “temporairement” et jamais fermé,
- règles anciennes non documentées,
- accès ouverts depuis des VLAN utilisateurs.
👉 Le Telnet interne est tout aussi dangereux que le Telnet exposé Internet.
🖥️ 5️⃣ Cas particuliers : IBM i / AS400 & équipements legacy
Sur les environnements IBM i / AS400 :
- Telnet peut être fonctionnellement nécessaire,
- mais doit impérativement être chiffré (SSL/TLS).
Actions à vérifier :
- Telnet clair désactivé,
- Telnet sécurisé seul autorisé,
- certificats valides et maintenus,
- restrictions IP,
- journalisation active.
👉 Telnet autorisé ≠ Telnet en clair.
🚨 6️⃣ Indicateurs d’alerte à remonter au RSSI
Tout audit Telnet doit générer une alerte si :
- Telnet est actif en clair,
- Telnet permet un accès admin/root,
- Telnet est exposé hors d’un VLAN dédié,
- Telnet n’est pas documenté,
- Telnet est présent “par héritage”.
🎯 C’est une dette technique ET une dette sécurité.
✅ Verdict SecuSlice
- Telnet détecté → analyse immédiate
- Telnet en clair → suppression ou confinement
- Telnet nécessaire → SSL/TLS + restrictions
- Alternative disponible → migration SSH
👉 Ce n’est pas un débat technique, c’est une décision de sécurité.
