Telnet fue uno de los primeros servicios de lo que ahora se conoce como Internet, permitiéndote hacer login interactivo en una máquina remota, lanzar comandos y ver sus resultados. Todavía sigue siendo la herramienta primaria por defecto para administración remota en la mayoría de los entornos, y cuenta con soporte casi universal (incluso el NT tiene un demonio y un cliente de telnet). También es uno de los protocolos más inseguros, susceptible al sniffing, hijacking, etc. Si se tienen clientes utilizando telnet para llegar hasta el servidor, se debería hacer un chroot de sus cuentas si esto es posible, de igual forma que restringir el telnet a los hosts que se utilicen mediante TCP_WRAPPERS. La mejor solución para asegurar el telnet es deshabilitarlo y utilizar telnet con SSL o el ssh.
Los problemas con telnet incluyen:
- Autentificación en texto claro, nombre de usuario y contraseña.
- Texto en claro de todos los comandos.
- Ataques de adivinación de contraseñas (como mínimo acabarán en los ficheros de log)
La mejor solución es desactivar el telnet y utilizar ssh. Sin embargo esto no es práctico en todas las situaciones. Si es necesario utilizar telnet, sugeriría encarecidamente filtrarlo mediante un cortafuegos, tener reglas para permitir a los hosts/redes acceso a puerto 23, y después tener una regla general denegando acceso al puerto 23, al igual que utilizar TCP_WRAPPERS (lo cual es más eficiente, puesto que el sistema sólo comprueba cada conexión de telnet y no cada paquete contra las reglas del cortafuegos) sin embargo utilizar TCP_WRAPPERS le permitirá a la gente dar por hecho que se está ejecutando telnet, les permite conectar, se evalúa la conexión, y después se cierra si no se está listado como permitido el acceso. Un ejemplo de reglas del cortafuegos:
ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 23
ipfwadm –I –a accept –P tcp –S un.host.fiable –d 0.0.0.0/0 23
ipchains –A input –p all –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 23
Un ejemplo de lo mismo utilizando TCP_WRAPPERS:
En /etc/hosts.allow
in.telnetd: 10.0.0.0/255.0.0.0, un.host.fiable
Y en /etc/hosts.deny
in.telnetd: ALL
Existen varias alternativas cifradas al telnet, como ya se mencionó más arriba, ssh, SSLeay Telnet y otras utilidades de terceros, a mi personalmente me parece que la "mejor" alternativa si te vas a tomar la molestia de cambiar el telnet por algo mejor es utilizar ssh.
Para asegurar las cuentas de los usuarios con respecto a telnet, se pueden hacer varias cosas. La primera sería no permitir al root hacer login vía telnet, lo cual se controla mediante el /etc/securetty y por defecto en la mayoría de las distribuciones el root tiene restringido el acceso a la consola (una buena cosa). Para que un usuario haga login con éxito, su shell tiene que ser válido (lo cual viene determinado por la lista de shells de /etc/shells), de modo que configurar cuentas de usuario a las que se les permita hacer login es simplemente cuestión de configurar su shell a alguno de los listados en /etc/shells. Es hora de algunos ejemplos prácticos de lo que se puede conseguir configurando el shell del usuario para otro tipo de cosas además de para hacer shell.
Para un PSI que quiere permitir a sus clientes cambiar sus contraseñas con facilidad, pero no permitirles acceso al sistema (mi PSI utiliza Ultrasparcs y por alguna razón se niega a distribuir cuentas de usuario, me pregunto porqué).
en /etc/shells se lista:
/usr/bin/passwd
Y se cambia el shell de los usuarios por /usr/bin/passwd, de modo que se tiene algo así:
nombreusuario:x:1000:1000::/home/nombreusuario:/usr/bin/passwd
et voilá. El usuario hace un telnet al servidor, se le pregunta su nombre de usuario y contraseña, y después se le pide cambiar la contraseña. Si se hace correctamente, passwd termina y se les desconecta. Si no tienen éxito, passwd sale y se les desconecta. Lo que sigue es una transcripción de tal configuración cuando un usuario hace telnet:
Trying 1.2.3.4...
Connected to localhost
Escape character is ‘^]’.
Red Hat Linux release 5.2 (Apollo)
Kernel 2.2.5 on an i586
login: tester
Password:
Changing password for tester
(current) UNIX password:
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully
Connection closed by foreign host.
Telnet también muestra un banner por defecto cuando se conecta alguien. El banner suele contener información del sistema, como el nombre, el SO, la versión y a veces otro tipo de información detallada, como la versión del kernel. Antaño esto era útil cuando se trabajaba en múltiples SO’s, sin embargo en la Internet hostil de hoy suele ser más perjudicial que útil. Telnet muestra los contenidos del fichero /etc/issue.net (generalmente es idéntico a /etc/issue el cual se muestra en los terminales, etc.), este fichero se suele volver a crear al arrancar, en la mayoría de las distribuciones de Linux, desde el fichero de arranque rc.local. Simplemente edita el fichero rc.local, ya sea modificando lo que pone en /etc/issue y /etc/issue.net, o comentando las líneas que crean esos ficheros, y después editando los ficheros con información estática.
Los contenidos de un fichero rc.local típico pertenecientes a /etc/issue y /etc/issue.net:
# This will overwrite /etc/issue at every boot. So make any changes
# you want to make to /etc/issue here or you will lose them when you
# reboot.
echo "" > /etc/issue
echo "$R" >> /etc/issue
echo "Kernel $(uname –r) on $a $(uname –m)" >> /etc/issue
cp –f /etc/issue /etc/issue.net
echo >> /etc/issue
simplemente comenta las líneas o elimina los comandos uname. Si es absolutamente necesario habilitar el telnet para hacer logins de usuarios, asegúrate de mostrar una advertencia:
Este sistema es exclusivamente para usos autorizados.
Los infractores serán perseguidos.
o algo similar. Legalmente se está en una posición más fuerte si alguien revienta el sistema o abusa de cualquier otra forma de tu demonio telnet.
