Telnet: ¿Qué es, cómo funciona y por qué es inseguro?

Telnet es uno de esos protocolos que explican muy bien cómo evolucionaron las redes: nació para abrir una sesión de texto con otro equipo a distancia y todavía aparece en laboratorios, equipos antiguos y tareas de diagnóstico. El punto crítico es simple: transmite la interacción en claro, así que entenderlo sirve tanto para administrar sistemas como para evaluar riesgos en WiFi y en redes internas. En este artículo verás qué hace, cómo funciona, cuándo todavía puede tener sentido y por qué hoy casi siempre conviene sustituirlo.

Qué es Telnet y qué problema resolvía

Yo lo resumiría así: Telnet es un protocolo pensado para manejar un equipo como si estuvieras delante de una terminal de texto, pero a distancia. La máquina cliente abre una conexión con el servidor y ambos intercambian caracteres, órdenes y respuestas de forma muy simple.

El estándar base, RFC 854, lo define como un medio de comunicación bidireccional orientado a terminales y procesos. Su idea original era resolver un problema muy concreto de los primeros tiempos de Internet: acceder a sistemas remotos sin depender de la compatibilidad exacta entre terminales. Para eso se apoyaba en el concepto de NVT (Network Virtual Terminal), una terminal virtual común que estandariza la conversación entre extremos distintos.

En la práctica, esto lo convirtió en una herramienta útil para administradores y entornos académicos, pero también en un protocolo con límites muy claros cuando las redes dejaron de ser cerradas y pasaron a ser mucho más expuestas.

Con esa base clara, merece la pena ver qué ocurre en una conexión real y por qué esa sencillez tuvo un coste.

Cómo funciona una conexión Telnet por dentro

Telnet trabaja sobre TCP, así que primero establece una conexión fiable entre cliente y servidor. Por convención, el servicio se asocia al 23/TCP, que es el puerto que registra IANA para Telnet.

Una vez abierta la sesión, el cliente actúa como una terminal. Lo que tecleas viaja al servidor y la respuesta vuelve en texto, sin capa gráfica ni cifrado adicional. Si el equipo remoto pide autenticación, las credenciales también forman parte de ese intercambio.

El protocolo incluye negociación de opciones para ajustar detalles como el eco local, el modo de línea o la interpretación de caracteres. Esa flexibilidad fue útil en su momento, pero hoy ya no compensa frente a métodos que resuelven lo mismo con más seguridad y menos exposición.

En redes internas pequeñas esto parece inocuo hasta que recuerdas que cualquier capturador de tráfico, un switch mal segmentado o un punto de acceso comprometido puede leer la sesión.

Por qué hoy se considera inseguro

La razón principal es directa: Telnet no protege el contenido de la sesión. Lo que escribes puede quedar expuesto para cualquiera que tenga visibilidad sobre el tráfico de red, y eso incluye contraseñas, comandos de administración y cualquier dato sensible que aparezca en pantalla.

Yo aquí suelo hacer una distinción útil. El problema no es solo que alguien se conecte; el problema es que la sesión puede ser capturada, leída o incluso alterada en un ataque de man in the middle, cuando un tercero se coloca entre cliente y servidor. En WiFi, especialmente en redes abiertas o mal segmentadas, ese riesgo sube bastante.

Es verdad que el ecosistema de Telnet llegó a contemplar opciones de autenticación y cifrado, pero en despliegues reales lo habitual sigue siendo una sesión en texto plano. Por eso, desde una perspectiva de ciberseguridad, no se recomienda para acceso administrativo normal.

La cuestión práctica ya no es si el protocolo puede funcionar, sino en qué escenarios todavía resulta aceptable sin elevar demasiado el riesgo.

Dónde sigue teniendo sentido en redes y WiFi

No todo uso de Telnet es absurdo, pero el margen es estrecho. En mi experiencia, solo tiene cierto sentido en tres escenarios: equipos heredados que no soportan SSH, laboratorios aislados donde no circula información sensible y pruebas rápidas de conectividad para comprobar si un puerto TCP responde.

• Equipamiento antiguo: routers, switches o sistemas industriales que no se han actualizado y no ofrecen otra cosa.
• Entornos de prueba: redes de laboratorio sin datos reales, donde interesa verificar el comportamiento básico del servicio.
• Diagnóstico: comprobar manualmente si un host escucha en un puerto concreto antes de pasar a herramientas más completas.

Incluso en esos casos yo pondría límites: segmentación estricta, sin credenciales reales, sin exponerlo a Internet y, en WiFi, solo dentro de redes controladas donde puedas asumir que el tráfico no va a salir de tu perímetro de confianza.

Si el caso de uso es más amplio que eso, la comparación con SSH deja muy poco espacio para defender Telnet.

Telnet frente a SSH y otras alternativas

Si me obligas a elegir una alternativa para administración remota, SSH gana casi siempre porque resuelve lo mismo con autenticación y cifrado. También existen consolas web sobre HTTPS y soluciones de gestión fuera de banda, pero Telnet queda muy atrás en seguridad.

La diferencia no es solo técnica, también operativa: con SSH puedes automatizar mejor, auditar mejor y reducir muchísimo la superficie de exposición. Por eso, cuando veo Telnet en una red actual, mi primera pregunta no es si funciona, sino por qué no se ha sustituido ya.

Y si todavía te toca probarlo de forma puntual, conviene hacerlo con una metodología que minimice daños.

Cómo probarlo sin poner en riesgo una red real

Si necesitas tocar Telnet por motivos de soporte o inventario, yo seguiría un orden muy conservador. No se trata de activarlo y ya está, sino de limitar alcance, tiempo y exposición.

1. Haz la prueba en una red aislada, no en la WiFi principal ni en una red con usuarios reales.
2. Usa credenciales de laboratorio y cambia cualquier contraseña que hayas expuesto por error.
3. Confirma el puerto antes de abrir sesión; en Telnet lo habitual es 23/TCP, pero el equipo puede estar configurado distinto.
4. Registra la actividad si estás en un entorno de administración, para saber quién accedió y cuándo.
5. Cierra el servicio cuando termines; dejarlo activo “por si acaso” es una mala costumbre que acaba generando incidentes.

Si lo que quieres es comprobar conectividad, a menudo basta con una herramienta más segura o con una sesión SSH al mismo equipo. Yo solo mantendría Telnet abierto cuando el dispositivo no da otra opción y la operación está acotada por diseño.

Ese criterio es el que me lleva a la última parte: qué revisaría antes de dejarlo vivo en producción.

Qué revisaría antes de dejarlo activo en un equipo real

Antes de aceptar Telnet en un entorno real, yo miraría tres cosas: aislamiento de red, necesidad operativa y plan de sustitución. Si una de las tres falla, el protocolo deja de ser una herramienta temporal y pasa a ser una deuda de seguridad.

• Aislamiento: VLAN de gestión, filtrado por IP y sin exposición hacia Internet.
• Necesidad real: que el equipo no soporte SSH, HTTPS de administración o consola fuera de banda.
• Sustitución: fecha clara para migrar a un mecanismo cifrado o retirar el equipo.
• Pruebas: verificar que nadie está enviando credenciales reales por ese canal.

Mi criterio final es sencillo: Telnet sirve para entender la historia de las redes y, en casos muy limitados, para mantener equipos viejos vivos un poco más; no sirve como base de una administración moderna. Si hoy dependes de él para entrar a un dispositivo, el siguiente movimiento serio es planificar su reemplazo, no seguir estirando la excepción.