Guía de puertos Telnet: acceso remoto heredado en el puerto 23

Telnet abre una conexión TCP y presenta una sesión de terminal basada en texto. Después de que el servidor acepta la conexión, el cliente y el servidor pueden negociar las opciones del terminal, luego el usuario envía comandos y recibe resultados como texto sin formato.

Esa simplicidad es la razón por la cual Telnet sobrevivió en la administración de dispositivos, laboratorios, equipos de fabricación y electrodomésticos antiguos. También es por eso que es riesgoso: sin un túnel cifrado separado, cualquiera que pueda capturar el tráfico entre el cliente y el servidor puede leer credenciales y comandos.

SSH reemplazó a Telnet para la mayoría de la administración remota porque SSH cifra la sesión, verifica la clave del host del servidor y admite una autenticación más segura. SSH normalmente usa el puerto TCP 22, mientras que Telnet normalmente usa el puerto TCP 23.

Si el dispositivo admite SSH, utilice SSH en lugar de Telnet. Mantenga Telnet solo para sistemas que no se pueden actualizar, para acceso a laboratorios aislados o para flujos de trabajo de emergencia cortos donde ya existen controles de compensación.

Telnet todavía aparece en enrutadores y conmutadores, sistemas PBX, servidores de consola fuera de banda, controles de edificios, controladores industriales, matrices de almacenamiento, impresoras y dispositivos de proveedores más antiguos que se diseñaron antes de que SSH se convirtiera en estándar.

También se utiliza como un cliente de diagnóstico simple para servicios TCP sin procesar, aunque las herramientas modernas como nc, ncat, curl, openssl s_client y clientes de protocolos especialmente diseñados generalmente brindan una mejor visibilidad y menos sorpresas.

El puerto 23 casi nunca debe estar abierto a la Internet pública. Telnet público atrae escaneos automatizados, ataques de contraseñas predeterminadas, actividad de botnets y toma de control oportunista de dispositivos. Si se puede acceder a un servicio Telnet desde fuera de una red confiable, trátelo como una exposición urgente a revisión.

Si Telnet es inevitable, restrinjalo a una VLAN de administración, VPN, host bastión, jump box, red de consola serie o lista permitida de IP de origen. El objetivo es hacer que Telnet sea accesible sólo para las personas y la automatización que realmente lo necesitan.

Antes de permitir TCP 23, confirme por qué aún se requiere Telnet y si SSH, administración HTTPS, una API de proveedor o una consola en serie pueden reemplazarlo. Luego identifique quién debe conectarse, desde qué red, durante cuánto tiempo y qué registros están disponibles.

Un verificador de puertos puede indicarle si se puede acceder a TCP 23 desde el exterior, pero no puede indicarle si las credenciales son seguras o si el dispositivo admite controles de acceso modernos. Pruebe la ruta de inicio de sesión real sólo desde una red confiable y evite enviar contraseñas reales a través de enlaces que no sean confiables.

En Windows, el Cliente Telnet se puede habilitar para realizar pruebas, pero el Servidor Telnet no debe usarse para la administración normal. Si un sistema Windows necesita acceso a comandos remotos, utilice PowerShell Remoting, SSH, RDP a través de una puerta de enlace u otra ruta de administración cifrada.

En Linux, los paquetes del servidor Telnet suelen ser innecesarios y deben permanecer deshabilitados. Si se debe ejecutar un demonio heredado, vincúlelo a una interfaz privada y restrinja el acceso con firewalld, ufw, nftables, iptables o una lista de permitidos basada en host.

En dispositivos y dispositivos de red, deshabilite Telnet cuando la administración SSH o HTTPS esté disponible. Si las limitaciones del proveedor obligan a Telnet, coloque el dispositivo en una red de administración restringida y documente la excepción para que pueda eliminarse durante el siguiente ciclo de actualización.

Comience con una verificación del puerto externo con el nombre de host o la dirección IP y el puerto 23. Si el resultado está abierto, un cliente remoto puede establecer una conexión TCP con el oyente Telnet. Eso no significa que sea seguro iniciar sesión desde la Internet pública.

Desde una red confiable, puede probar el banner con telnet host 23, nc -vz host 23 o ncat. En el servidor o dispositivo, inspeccione el estado del servicio y las reglas del firewall. Para los dispositivos, verifique la configuración de administración porque Telnet puede habilitarse por separado de SSH o la administración web.

Si el puerto 23 está cerrado, Telnet puede estar deshabilitado, el dispositivo puede admitir solo SSH, el servicio puede estar vinculado a una interfaz de administración o un firewall puede estar bloqueando la ruta. Si se agota el tiempo de espera, es posible que un enrutador, una ACL, una política de VPN, un firewall en la nube o una restricción de IP de origen estén interrumpiendo el tráfico.

Si el puerto está abierto pero el inicio de sesión falla, inspeccione el formato del nombre de usuario, el estado de la contraseña, las reglas de clase de acceso al dispositivo, la autenticación local frente a la de directorio, la configuración de línea y la configuración de bloqueo. En los equipos de red, la política de línea VTY o las ACL del plano de administración a menudo explican la falla.

Deshabilite Telnet siempre que sea posible. Reemplácelo con SSH, administración HTTPS, acceso solo VPN, consola serie o herramientas del proveedor. Elimine las cuentas predeterminadas, rote las contraseñas compartidas y mantenga actualizado el firmware del dispositivo hasta que desaparezca la dependencia de Telnet.

Si Telnet debe permanecer, aíslelo de las redes de usuarios e Internet, registre los intentos de acceso, supervise las direcciones de origen inesperadas y documente la propiedad. Trate cada excepción de Telnet como deuda operativa temporal, no como un patrón de gestión normal.