💾 Archived View for nlguerra.xyz › gemset › gemlog_telnet-fun.gmi captured on 2023-12-28 at 15:06:17. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
etiquetas: telnet,cli,protocolos
Como estudiante de informática siempre se me ha dejado claro que telnet es inseguro, viejo, y que nunca nunca NUNCA hay que usarlo. Desde hace ya sus años al puerto 23 se le tiene cierto abandono, y con razón. Con alternativas como SSH para recibir shells remotas ¿quién en su sano juicio usaría comunicaciones en texto claro?
Después de años sin oír de telnet quise montarme mi propio servidor de correo electrónico, una tecnología útil a la vez de resiliente, y gracias a emailwiz.sh de Luke Smith, facilísimo de montar.
Pero, ¿qué tiene que ver telnet con todo esto? El protocolo en sí, nada en absoluto, pero después de par de problemas a la hora de poner el servidor en producción, en una página de ayuda de Microsoft vi que se pueden depurar errores de SMTP usando el cliente de telnet en el puerto 25 y mandando una serie de comandos al servidor, comandos SMTP.
Esto por aquel entonces me pareció raro, porque para mí telnet siempre había sido el protocolo que no debes usar por ser inseguro, y punto; no había visto el cliente de telnet como algo útil con otros protocolos. Poder mandar un correo electrónico por medio de la terminal usando telnet me pareció flipante, pero no lo entendía realmente.
Este método de hablar con un servidor me dejó marca, y gracias a herramientas como Wireshark pude atar cabos: el programa telnet solo maneja una conexión TCP y con cada vez que haces Enter envía el texto que has introducido como PUSH/ACK, y el texto que recibe lo saca en la consola sin aportar más a la conexión. El protocolo telnet gestiona shells remotas y autenticación, pero el cliente telnet en sí ¡es tan simple que se puede usar para contactar cualquier servidor TCP basado en texto! Me pareció todo un descubrimiento, aunque a los de la vieja escuela quizá les parece una tontería más que obvia.
Después de aprender eso, como es predecible, decidí ponerlo a prueba con otros casos de estudio ¿Qué otro protocolo está basado en texto? HTTP, por ejemplo. Con `telnet 10.0.2.2 80` pude conectarme a un proxy de mi red, y escribiendo `GET / HTTP/1.1` para después dar dos veces al Enter (parece que el servidor HTTP espera a dos saltos de línea para responder), recibo una respuesta: `HTTP/1.1 400 Bad Request`.
Todo funcionaba como me esperaba, y me estaba encantando por tonto que parezca: estaba hablando en "bajo nivel" con un servidor y me estaba respondiendo. Nos estábamos entendiendo.
Un par de semanas después terminaba una práctica de proftpd en clase, una PDF de entrega de 35 páginas llenas de capturas de pantalla y explicaciones, así que quise desconectar un poco. Para ello fue suficiente un ejecutar `telnet localhost 21`. A ver adónde puedo llegar.
Primero, la autenticación: un comando USER y un comando PASS, para demostrar que tenemos permiso. El servidor nos deja pasar, pero una vez ahí poco podemos hacer sin saber la estructura de directorios, así que intento hacer un LIST, el equivalente a dir o ls para el protocolo FTP... No pasa nada, es más, me dice que la conexión fue rechazada. De vuelta a wireshark.
La tarea que había entregado hacía mención de un tal "modo pasivo", aunque nunca me explicaron en qué consistía. Según lo que entiendo ahora, el puerto 21 es el puerto por el que se mandan y reciben comandos como cd o los inicios de sesión, mientras que los comandos más complejos nos enviarán contenido por medio de otro puerto con una conexión que tenemos que iniciar nosotros.
Por lo que vi en wireshark un LIST ejecuta dos cosas, primero un EPSV, que nos devuelve el puerto del servidor que se abre para enviarnos el contenido, y después un LIST, que nos enviará dicho contenido por la nueva conexión y que la cerrará justo después.
Yo estaba flipando, porque esto no lo había visto nunca. Sin embargo, todavía no sabía cómo enfrentarme a esto. Mi misión era conseguir hacer un dir a base de telnet, y todo era más complejo de lo que esperaba. Por suerte, el servidor nos manda el puerto nuevo en texto claro así que recurriremos a nuestro amigo de nuevo: otra instancia de telnet, esta vez apuntando a ese otro puerto.
Una vez se inicia la conexión podemos ejecutar LIST en el telnet original, y la lista de archivos y directorios la recibirá la otra conexión, que se cerrará justo después. Algo que francamente no entiendo por qué es así, me parece algo innecesariamente complejo, pero que por otro lado me alegro de haber podido manejar con esta herramienta tan simple como es el cliente de telnet.
Y poco más, a día de hoy todavía no he intentado pasar archivos ni nada por el estilo, pero por ahora creo que puedo descansar mientras doy forma a esta nueva cápsula. Espero que este post haya despertado la curiosidad igual que la despertó en mí esa página de ayuda de Microsoft.
Gracias por leerme.
~ Néstor Llop Guerra
_________
CC0