Telnet

APLICACIONES TELEMTICAS 5 INGENIERA DE TELECOMUNICACIN
EL PROTOCOLO TELNET:
DISEO DE UNA APLICACIN CLIENTE SERVIDOR
Alexandra Lorente Cablanque
Telnet: diseo de una aplicacin cliente/servidor
Pgina 1 de 29
ndice de contenidos
1.- Introduccin.- .............................................................................................................. 2 2.- Caractersticas a implementar.- .................................................................................. 3 3.- Diseo de la aplicacin Telnet: cliente.- ..................................................................... 4 Proceso EMPEZAR (arranque programa) ......................................................... 7 Proceso CONEXIN TCP/IP (establecimiento) ............................................... 7 Proceso NEGOCIACIN DE OPCIONES ....................................................... 9 Proceso AUTENTICACIN EN EL SERVIDOR .......................................... 10 Proceso SESIN: REALIZAR OPERACIONES............................................ 12 Proceso LIBERAR CONEXIN TCP/IP ........................................................ 13 Proceso FINALIZAR PROGRAMA ............................................................... 13 4.- Diseo de la aplicacin Telnet: servidor.- ................................................................ 14 Proceso EMPEZAR (arranque programa) ....................................................... 16 Proceso BLOQUEADO EN COLA DE ESPERA........................................... 16 Proceso CONEXIN TCP/IP (establecimiento) ............................................. 17 Proceso NEGOCIACIN DE OPCIONES ..................................................... 18 Proceso OBTENER TERMINAL DEL NVT .................................................. 19 Proceso VERIFICAR AUTENTICACIN ..................................................... 20 Proceso SESIN: REALIZAR OPERACIONES............................................ 22 Proceso LIBERAR CONEXIN TCP/IP ........................................................ 23 5.- Consideraciones prcticas de implementacin.- ....................................................... 24 6.- Conclusiones y posibles mejoras.- ............................................................................ 27 7.- Bibliografa.- ............................................................................................................. 28
Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque
Pgina 2 de 29
1.- Introduccin.-
El protocolo Telnet se desarroll pensando en un funcionamiento similar al de los protocolos cliente-servidor, pero siguiendo una arquitectura diferente a este tipo de protocolos (ya que en parte lo que se busca es la simetra en el protocolo, lo cual impide que internamente la arquitectura sea cliente-servidor). De hecho, se dise de forma que se pudiera establecer una sesin en cualquier tipo de servidor, entrando a travs de la conexin establecida a partir de un terminal cualquiera (que no acta como cliente). Este protocolo nos permite, por ejemplo, ejecutar programas en el servidor. El protocolo trabaja sobre una conexin TCP/IP, estableciendo un canal bidireccional de octetos (semi-duplex a pesar de ser TCP full duplex, por motivos que se vern a continuacin) y estableciendo la comunicacin de terminal a terminal y de proceso a proceso. El conjunto de caracteres definido es ASCII de 7 bits. Para poder soportar cualquier tipo de terminal, se introdujo el concepto de Terminal Virtual de Red o Network Virtual Terminal (NVT), dispositivo intermedio con el que deben trabajar tanto la aplicacin servidor como la aplicacin cliente. En realidad el NVT es un dispositivo irreal, imaginario (de ah que se le denomine virtual) que ambos extremos de la conexin utilizan para registrar (mapear en memoria) su terminal fsico y real. Es decir, la aplicacin cliente debe registrar en el NVT el tipo de terminal fsico que el usuario cliente est empleando en la mquina que inicia la conexin contra el servidor; y una vez registrado, el servidor debe mapear ese NVT en un terminal que soporte. Es importante destacar que, si bien el protocolo Telnet en s no est construido como una arquitectura cliente-servidor, en la prctica se trabaja con aplicaciones que funcionan como clientes Telnet en la mquina que inicia la conexin contra el cliente. De hecho, aunque inicialmente el mtodo de trabajo era emplear un terminal en el cliente compuesto solamente por una impresora y un teclado, y en pocas posteriores sustituyendo la impresora por una pantalla de ordenador y un mtodo de trabajo en modo consola, a da de hoy existen numerosos clientes Telnet que presentan una interfaz grfica que facilita enormemente el manejo de las aplicaciones. Algunos de esos clientes son PuttY, NetRunner, Zoc, y algunos otros. Tambin hay sistemas operativos que traen sus propios clientes Telnet instalados por defecto. El objetivo bsico de este trabajo es generar el diseo de una aplicacin que permita la implementacin del protocolo Telnet y su correcto funcionamiento. Para ello, ser necesario realizar un diseo de la aplicacin que habr que instalar en la mquina que trabaje como servidor, as como una aplicacin que har las veces de cliente en la mquina que inicie la conexin contra el cliente. Dada la extensin de las diferentes opciones que puede manejar este protocolo, as como los comandos y los modos de operacin posibles, en primer lugar se har un estudio de las caractersticas deseadas en
Pgina 3 de 29
las aplicaciones a desarrollar, y despus se generar el flujograma correspondiente de cada una de stas.
2.- Caractersticas a implementar.-
A la hora de realizar el diseo de una aplicacin que soporte el protocolo Telnet, primero debemos analizar qu opciones, de entre todas las posibles a implementar en el protocolo, consideramos deseables para la aplicacin. En primer lugar, analizaremos el establecimiento de la conexin. sta, segn el protocolo, es una conexin TCP/IP normal, por lo que el establecimiento puede realizarse de la manera que consideremos ms conveniente (por ejemplo, mediante sockets). En todo caso asumiremos que el cliente ser siempre el encargado de iniciar la conexin contra el servidor, nunca al contrario. En segundo lugar analizaremos la negociacin de opciones al iniciar la conexin Telnet. En principio el protocolo est pensado para que dicha negociacin sea simtrica (es decir, cualquiera de los extremos de la conexin podra iniciar la negociacin de cualquier opcin), pero desde el punto de vista de la seguridad puede suponer un problema importante; por lo tanto, limitaremos algunas opciones de forma que nicamente puedan ser iniciadas por slo uno de los extremos de la comunicacin. Las cuatro posibles peticiones para cada opcin son las siguientes: WILL (el que enva la peticin quiere habilitar la opcin l mismo), DO (el que enva la peticin quiere que sea el otro extremo el que se encargue de habilitar la opcin), WONT (el que enva la peticin quiere encargarse de deshabilitar la opcin l mismo) y DONT (el que enva la peticin quiere que el otro extremo deshabilite la opcin). En tercer lugar analizaremos el modo de operacin deseado para el cliente y servidor Telnet que queremos disear. En principio, existen cuatro modos de funcionamiento: semi-duplex (modo por defecto que se usa muy infrecuentemente, si bien fue el primer modo de funcionamiento que se dise), modo carcter (tpico de Rlogin, que consiste en enviar cada carcter que se escribe en el terminal de forma independiente al servidor), modo lnea kludge (consiste en enviar los comandos en lneas completas y ciertas rdenes en modo carcter) y modo lnea puro (que es una mejora del modo kludge, que corrige los fallos que ste presentaba). En nuestro caso implementaremos unas aplicaciones que trabajarn por defecto en modo carcter, ya que, si bien este modo presenta ciertos problemas por el volumen de trfico que genera y por los altos retardos que presenta en lneas lentas, es tambin el modo que se est imponiendo a da de hoy en la mayora de aplicaciones e implementaciones del protocolo actuales.
Pgina 4 de 29
En cuarto lugar, implementaremos autenticacin para emplear seguridad en el protocolo y evitar un uso malintencionado de la aplicacin para daar al servidor. Para ello, por defecto el cliente deber introducir un nombre de usuario y una contrasea cuando el servidor as lo solicite; el nombre de usuario se enviar por la lnea en texto en claro, pero la contrasea se cifrar (por ejemplo mediante DES). Por ltimo, analizaremos las posibles opciones a implementar en la negociacin de opciones entre el cliente y el servidor. Hay que tener en cuenta que las reglas de Telnet especifican que cualquiera de los dos extremos de la conexin puede aceptar o rechazar la peticin de habilitacin de una opcin, pero una peticin de deshabilitacin ha de ser siempre aceptada; por tanto slo se contemplarn los siguientes supuestos:
PETICIN
WILL WILL DO DO WONT
RESPUESTA
DO DONT WILL WONT DONT
DESCRIPCIN
El que enva la peticin quiere habilitar opcin l mismo; el otro extremo accede El que enva la peticin quiere habilitar opcin; el otro extremo no accede El que enva la peticin quiere que el otro habilite opcin; el otro extremo accede El que enva la peticin quiere que el otro habilite opcin; el otro extremo no accede El que enva la peticin quiere deshabilitar opcin l mismo; el otro extremo est obligado a acceder El que enva la peticin quiere que el otro extremo deshabilite opcin; el otro extremo est obligado a acceder
DONT
WONT
Una vez establecidos los parmetros generales a tener en cuenta para el diseo de las aplicaciones cliente y servidor, empezaremos con el diseo funcional de cada una de stas.
3.- Diseo de la aplicacin Telnet: cliente.-
Queremos implementar una aplicacin que funcione como un cliente Telnet en una consola de comandos de un sistema operativo (UNIX, por ejemplo), cumpliendo con las consideraciones realizadas en el apartado anterior, a saber: 1. El cliente ser siempre el encargado de iniciar la conexin hacia el servidor, y nunca a la inversa.
Pgina 5 de 29
2. Se limitarn las opciones que pueda intentar negociar el cliente, ya que algunas estarn restringidas de manera que slo el servidor podr iniciar la negociacin de las mismas. 3. Por defecto el conjunto de aplicacin trabajar en modo carcter, pero se permitir al cliente iniciar la negociacin de otros modos de trabajo (por ejemplo, modo lnea). Slo el cliente iniciar la negociacin de este tipo de opciones; el servidor no cambiar nunca el modo de trabajo a menos que acceda a la peticin del cliente. 4. La contrasea de sesin deber enviarse cifrada por motivos de seguridad, mediante DES. Por tanto, la aplicacin cliente deber encargarse del cifrado de la misma antes de enviarla hacia el servidor. Una vez establecidos los parmetros y las restricciones de nuestra aplicacin cliente, procedemos al diseo de la misma, mediante un flujograma sencillo que nos permita entender el funcionamiento de esta aplicacin. Tambin se adjuntar, si procede, pseudocdigo para aclarar cmo podra ser la implementacin de la aplicacin a partir de un lenguaje de programacin de alto nivel, como por ejemplo C. El mencionado pseudocdigo se referir en todo caso a la implementacin de algunas de las particularidades del protocolo Telnet, ya que no tiene sentido tratar aqu la implementacin prctica de, por ejemplo, el mecanismo de implementacin de una conexin TCP/IP mediante sockets de una aplicacin cliente-servidor iterativa y conectiva. En primer lugar se proceder a dar una visin funcional del diseo de la aplicacin cliente a implementar. Para ello nos serviremos de un flujograma explicativo que se muestra a continuacin:

EMPEZAR (arranque programa)
Pgina 6 de 29
CONEXIN TCP/IP (establecimiento)
NEGOCIACIN DE OPCIONES (y mapeo en el NVT en caso de negociar el tipo de Terminal) NO FIN DE NEGOCIACIN?
S AUTENTICACIN EN EL SERVIDOR
SESIN: REALIZAR OPERACIONES NO MENSAJE DEL SERVIDOR (FIN S OPERACIONES)? S CONEXIN TCP/IP (liberacin)
FINALIZAR PROGRAMA
El flujograma anterior est simplificado, ya que en l no se especifican la mayora de funciones y acciones que debemos realizar; esto se debe a que en caso de haber incluido stas en el anterior flujograma, ste habra quedado excesivamente sobrecargado y sera poco claro. Por ello, a continuacin se muestran los flujogramas completos de cada uno de los procesos anteriores.
Pgina 7 de 29
PROCESO EMPEZAR (arranque programa): consiste simplemente en arrancar la aplicacin en la mquina del cliente. Tcnicamente este proceso no sera parte del diseo interno de la aplicacin en la mquina del cliente, pero se ha indicado aqu por motivos de claridad.
Iniciar la aplicacin en la mquina del cliente
FIN DEL PROCESO EMPEZAR PROGRAMA
PROCESO CONEXIN TCP/IP (establecimiento): consiste en el establecimiento de la conexin TCP/IP a partir de la apertura de un socket que deber posteriormente asociarse y conectarse al socket del servidor, que estar bloqueado esperando la conexin del cliente (es decir, generaremos una aplicacin en modo orientado a conexin). Tambin se arrancar un temporizador en la mquina del cliente para establecer un plazo mximo de retardo en la conexin; en caso de expirar, se reintentar una vez ms (el control del nmero de conexiones intentadas se llevar a cabo mediante una variable de programa llamada NUM_CONEXION) y en caso de volver a fallar, se asumir que existe un problema con la conexin o con el servidor, y se finalizar la ejecucin del programa sacando un mensaje de error por el terminal del cliente. En caso de no haber problemas, eso significar que el establecimiento de la conexin TCP/IP ha sido satisfactorio, y por tanto habremos finalizado con xito este proceso. Lo habitual es realizar la conexin a travs del puerto 23 del servidor, para ello ser necesario establecer el par Direccin IP-Puerto de la manera adecuada.
Pgina 8 de 29
NUM_CONEXION inicialmente a 1
Creacin del socket, para asociacin y conexin con el servidor
Incrementar NUM_CONEXION
Arrancar temporizador, esperar conexin
Liberar conexin (socket) fallida
EXPIRACIN DEL TEMPORIZADOR? S
NO
xito en la conexin
NO
NUM_CONEXION = 2? S Fallo en la conexin
Mensaje de error en el terminal del cliente
Liberar conexin (socket) fallida
FINALIZAR PROGRAMA
FIN DEL PROCESO CONEXIN TCP/IP
Pgina 9 de 29
PROCESO NEGOCIACIN DE OPCIONES: en este proceso, el cliente y el servidor llevarn a cabo la negociacin de opciones previa a la sesin Telnet. Esta negociacin engloba opciones tales como la velocidad de terminal, el tipo de terminal que tiene el cliente (para su posterior mapeo en el NVT, una vez finalizada la negociacin), el modo de funcionamiento, el manejo del eco, etctera. Es importante destacar que, en este proceso, tanto el cliente como el servidor pueden iniciar la negociacin de la mayora de opciones de forma simtrica, aun a pesar de limitar ciertas opciones a uno solo de los dos terminales (por ejemplo, el servidor trabaja por defecto en modo carcter, y no pedir nunca el cambio a otro modo de funcionamiento; ser el cliente el nico que pueda iniciar la negociacin de esta opcin).
NEGOCIACIN DE OPCIONES El cliente quiere enviar su tipo de terminal: WILL TERMINAL TYPE El cliente enva el resto de opciones que desea negociar con el servidor
El cliente responde a las peticiones de opciones que le llegan desde el servidor
El cliente recibe las respuestas a las peticiones que solicit al servidor
NEGOCIAR MS (SUB)OPCIONES? NO Mapear tipo de terminal en el NVT para el servidor, y esperar confirmacin de recepcin de ste
FIN DEL PROCESO NEGOCIACIN DE OPCIONES
Pgina 10 de 29
Conviene destacar en el proceso anterior que lo primero que hace el cliente necesariamente, en esta implementacin, es indicarle al servidor que desea especificar el tipo de terminal que posee. El servidor, en nuestro caso, necesariamente tendr que estar de acuerdo, como veremos cuando hablemos de la implementacin del mismo. Una vez indicado el terminal, se negociarn el resto de opciones (control de flujo, eco, velocidad del terminal, modo de trabajo ste nicamente se iniciar en el cliente, el servidor estar o no de acuerdo pero no iniciar un cambio del modo de trabajo, etc.; las respuestas se harn teniendo en cuenta la tabla indicada en el apartado 2 de este documento, y codificando cada una de las posibles opciones del protocolo con diferentes valores decimales). Una vez terminada la negociacin de opciones (y subopciones, si procediera), el cliente mapear su tipo de terminal en el NVT para que el servidor pueda a su vez interpretarlo, y esperar a que el cliente confirme la recepcin del tipo. Con esto finalizara este proceso de negociacin, del cual no podemos ser ms explcitos ya que variara considerablemente en cada sesin.
PROCESO AUTENTICACIN EN EL SERVIDOR: este proceso se encarga de esperar a que, una vez finalizada la negociacin de opciones por parte de ambos extremos, el servidor le enve el prompt para iniciar la sesin Telnet. Como por defecto, para que la sesin se admita en el servidor, el cliente ha de identificarse con un nombre de usuario y una clave (ambas recogidas en un fichero o una base de datos en el servidor), el servidor enviar una peticin de nombre de usuario y contrasea despus de que el cliente intente iniciar la sesin. Dado que adems, en Telnet, toda la informacin se enva en claro, para que el envo de la contrasea de identificacin no suponga un problema de seguridad para el cliente ni para el servidor, se llevar a cabo un proceso de cifrado de la contrasea mediante DES, de forma transparente al usuario. En caso de introducir un par usuario-contrasea vlido (es decir, reconocido por el servidor), se dar paso a la sesin Telnet; no obstante, se permitirn tres intentos (controlados por la variable de programa INTENTOS) por si el usuario cometiera errores a la hora de introducir sus datos. Si tras esos tres intentos no se hubiera introducido un par usuario-contrasea vlido (lo cual se comprueba recibiendo un mensaje de error por parte del cliente), el cliente enviar al servidor un mensaje solicitando el cierre de la conexin en el otro extremo, se cerrar la conexin en el lado del cliente y finalizar la ejecucin de la aplicacin del cliente.
Pgina 11 de 29
AUTENTICACIN EN EL SERVIDOR Variable INTENTOS = 1 El cliente espera a que aparezca el prompt de sesin; ste pedir un nombre de usuario vlido (>Login: ) El cliente introduce el nombre de usuario en su terminal; ste se visualizar en claro en el terminal La variable INTENTOS se incrementa una unidad El cliente espera a que aparezca el prompt de sesin; ste pedir la contrasea asociada (>Passwd: ) El cliente introduce su contrasea, que no se ve en su terminal, y se enva cifrada al servidor (DES) El cliente recibe mensaje de error PAR LOGIN PASSW VLIDO? NO NO INTENTOS = 3? S El cliente recibe mensaje de error, contesta y se libera la conexin (socket) S
El cliente recibe mensaje de bienvenida y prompt de sesin
FINALIZAR PROGRAMA
FIN DEL PROCESO AUTENTICACIN EN EL SERVIDOR
Pgina 12 de 29
PROCESO SESIN: REALIZAR OPERACIONES: en este proceso se llevar a cabo la sesin Telnet propiamente dicha. Esta sesin depende de la aplicacin y del tipo de servidor que tengamos; podra tratarse, por ejemplo, de un router que se quisiera configurar de forma remota a partir de la conexin a ste desde un cliente Telnet, o bien un servidor de comparticin de archivos que permitiera subir y/o descargar documentos en/desde el servidor. Para que el cliente sepa por dnde empezar a la hora de buscar las opciones necesarias, se le enviar un mensaje desde el servidor indicndole que teclee help para conocer todos los comandos de sistema que puede ejecutar.
SESIN: REALIZAR OPERACIONES
El cliente recibe aviso del servidor indicndole que el comando help es de ayuda
El cliente recibe el prompt de sistema para teclear comandos El cliente recibe un mensaje de error desde el servidor y lo muestra por el terminal del cliente
El cliente teclea un comando Se muestra el resultado de la operacin devuelto por el servidor en el terminal del cliente
NO
COMANDO VLIDO? S COMANDO FINALIZAR? S FIN DEL PROCESO SESIN
NO
Es importante destacar que no es el lado del cliente quien finaliza la sesin, sino el propio servidor al recibir la peticin del cliente.
Pgina 13 de 29
PROCESO LIBERAR CONEXIN TCP/IP: este proceso se encarga de, una vez que el cliente cierra la sesin Telnet, cerrar tambin la conexin TCP/IP liberndola. Para ello debe liberar el socket (primitiva close(id_socket), donde id_socket es el descriptor del socket de la conexin TCP/IP). Este proceso es, por tanto, muy sencillo.
LIBERAR CONEXIN TCP/IP
Cerrar el socket en el cliente (close) para liberar la conexin
FIN DEL PROCESO LIBERAR CONEXIN TCP/IP
PROCESO FINALIZAR PROGRAMA: este proceso es simplemente una manera de indicar en el flujograma que finaliza la ejecucin de la aplicacin cliente, mediante una primitiva exit(cdigo) que, en funcin del cdigo de retorno que devuelva, nos indicar si todo ha ido bien o si ha habido algn incidente durante la ejecucin. Los valores de retorno que puede devolver el proceso son: o 0: el proceso termin normalmente, tras la liberacin de la conexin TCP/IP posterior al fin de la sesin Telnet. o -1: se produjo algn fallo durante el establecimiento de la conexin TCP/IP durante el proceso de conexin. o -2: el cliente agot los 3 intentos de autenticacin de usuario y contrasea antes de iniciar la sesin Telnet.
En los procesos anteriormente descritos podran opcionalmente introducirse mecanismos de control de errores de conexin, por ejemplo mediante temporizadores, para evitar la prdida de datos. Hay que tener en cuenta que, a menos que el servidor acepte lo contrario, el mtodo de trabajo por defecto es el modo carcter, por lo que se sobrecarga la red de trfico y por tanto pueden existir frecuentes retrasos y colisiones.
Pgina 14 de 29
4.- Diseo de la aplicacin Telnet: servidor.-
De forma anloga a lo que explicbamos en el apartado anterior de este documento, queremos implementar una aplicacin que funcione como un servidor Telnet en una consola de comandos de un sistema operativo (UNIX, por ejemplo), que sea compatible con el cliente Telnet del apartado anterior (y cumpliendo con el protocolo, que sea tambin, a ser posible, compatible con otros clientes distintos), cumpliendo con las consideraciones realizadas en el apartado 2, a saber: 1. El servidor nunca iniciar la conexin, ser el cliente el encargado de realizarla. Por ello, el servidor estar siempre arrancado, esperando a que un cliente se conecte a l. Dado que se trata de una aplicacin orientada a conexin, que en principio debera estar preparada para trabajar con varias conexiones a la vez, se crear una cola de peticiones que sern atendidas mediante procesos hijos (hilos) de una en una hasta llenar la cola de peticiones. Para ello, nos serviremos de la primitiva fork( ). 2. Se limitarn las opciones que pueda intentar negociar el servidor, ya que algunas estarn restringidas de manera que slo el cliente podr iniciar la negociacin de las mismas. De la misma manera, la opcin del cliente WILL TERMINAL TYPE ser siempre aceptada por el servidor. 3. Por defecto el conjunto de aplicacin trabajar en modo carcter, pero se permitir al cliente iniciar la negociacin de otros modos de trabajo (por ejemplo, modo lnea). Slo el cliente iniciar la negociacin de este tipo de opciones; el servidor no cambiar nunca el modo de trabajo a menos que acceda a la peticin del cliente. 4. La contrasea de sesin deber enviarse cifrada por motivos de seguridad, mediante DES. Por tanto, la aplicacin del servidor deber encargarse de descifrar la misma antes de comparar el par usuariocontrasea con los datos que tenga almacenados (ya sea un fichero de contraseas o una base de datos). En caso de que el cliente falle tres veces consecutivas el intento de autenticacin, el servidor cerrar su lado de la conexin sin enviarle mensaje al cliente, ya que ste se encargar tambin a su vez de cerrar la conexin y de avisar al usuario final de la aplicacin. Una vez establecidos los parmetros y las restricciones de nuestra aplicacin cliente, procedemos al diseo de la misma mediante un flujograma sencillo que nos permita entender el funcionamiento de esta aplicacin. En el flujograma, para ver el funcionamiento completo del servidor, supondremos que por algn motivo se ha reiniciado el servidor recientemente, y por ello aparecer en el diagrama el arranque del programa. No obstante, hay que tener en cuenta que en principio el servidor es una mquina que est Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque
Pgina 15 de 29
continuamente prestando servicio, por lo que lo habitual es que se encuentre arrancado y esperando conexiones por parte de los clientes.
EMPEZAR (arranque programa) BLOQUEADO EN COLA DE ESPERA
NO
PETICIN DEL CLIENTE? S CONEXIN TCP/IP (establecimiento: hilos)
NEGOCIACIN DE OPCIONES
NO
FIN DE NEGOCIACIN?
S OBTENCIN DEL TERMINAL (NVT)
VERIFICAR AUTENTICACIN
NO
MENSAJE DEL CLIENTE (FIN OPERACIONES)? S CONEXIN TCP/IP (liberacin)
Pgina 16 de 29
El flujograma anterior est simplificado, ya que en l no se especifican la mayora de funciones y acciones que debemos realizar; esto se debe a que en caso de haber incluido stas en el anterior flujograma, ste habra quedado excesivamente sobrecargado y sera poco claro. Por ello, a continuacin se muestran los flujogramas completos de cada uno de los procesos anteriores.
PROCESO EMPEZAR (arranque programa): consiste simplemente en arrancar la aplicacin en la mquina servidora. Tcnicamente este proceso no sera parte del diseo interno de la aplicacin en la mquina del servidor, ni tampoco es parte del funcionamiento habitual del servidor (ya que ste se presupone siempre arrancado, no hace falta reiniciar la mquina para cada conexin con un cliente), pero se ha indicado aqu por motivos de claridad.
Iniciar la aplicacin en la mquina del servidor
FIN DEL PROCESO EMPEZAR PROGRAMA
PROCESO BLOQUEADO EN COLA DE ESPERA: aunque este proceso podra incluirse dentro de la conexin TCP/IP, su importancia a la hora de atender varias peticiones es notable. Tambin sera el punto de partida de la aplicacin en s misma, si no hubisemos tenido en cuenta el rearranque del servidor mencionado anteriormente. En este proceso se crea la cola de atencin de peticiones, que actuar como cola de espera en caso de recibir varias peticiones simultneas (el nmero mximo de peticiones que se pueden atender puede controlarse por software). El cdigo del servidor estar dormido aqu, esperando a que algn cliente intente conectarse con l.
Pgina 17 de 29
BLOQUEADO EN COLA DE ESPERA
Se crea un socket de conexin y se asocia con la direccin IP y el puerto de escucha
Se crea una cola de escucha de peticiones (primitiva listen)
FIN DEL PROCESO BLOQUEADO EN COLA DE ESPERA
PROCESO CONEXIN TCP/IP (establecimiento): consiste en el establecimiento de la conexin TCP/IP una vez que se recibe una peticin de conexin por parte de un cliente, en el puerto asociado a la aplicacin Telnet y en la mquina del cliente. Lo primero ser crear un proceso hijo del proceso de escucha (primitiva fork) de forma que el proceso padre pueda volver a atender la cola de escucha, mientras que el proceso hijo ser el encargado de atender la peticin actual del cliente. El control de conexin (retardos) lo realizar el cliente, por lo que no nos preocuparemos en el servidor de estos menesteres. Por defecto la aplicacin emplear el puerto 23 para establecer la conexin, ya que se trata del puerto tpico y habitual en este protocolo.
Pgina 18 de 29
El proceso recibi una peticin de conexin por parte de un cliente
Fork: crear proceso hijo El proceso padre ha cedido el control al hijo, y vuelve a la cola de espera a atender ms peticiones El proceso hijo acepta la conexin y se encarga de ella (primitiva accept)
VUELTA AL PROCESO BLOQUEADO
FINALIZAR PROCESO CONEXIN
PROCESO NEGOCIACIN DE OPCIONES: en este proceso, el cliente y el servidor llevarn a cabo la negociacin de opciones previa a la sesin Telnet. Esta negociacin engloba opciones tales como la velocidad de terminal, el tipo de terminal que tiene el cliente (para su posterior mapeo en el NVT, una vez finalizada la negociacin, y que el servidor pueda obtener la informacin necesaria), el modo de funcionamiento, el manejo del eco, etctera. Es importante destacar que, en este proceso, tanto el cliente como el servidor pueden iniciar la negociacin de la mayora de opciones de forma simtrica, aun a pesar de limitar ciertas opciones a uno solo de los dos terminales (por ejemplo, el servidor trabaja por defecto en modo carcter, y no pedir nunca el cambio a otro modo de funcionamiento; ser el cliente el nico que pueda iniciar la negociacin de esta opcin). El proceso es muy similar al que se describi para el cliente, y se pone aqu un flujograma general, ya que dependiendo de cada sesin, tipo de terminal, etc., la negociacin se llevar a cabo de diferente manera. Eso s, dado que en el cliente especificamos que lo primero que se hara en la negociacin sera el envo por parte del cliente del tipo de terminal, y que el servidor aceptara obligatoriamente, esa ser la primera tarea a realizar.
Pgina 19 de 29
NEGOCIACIN DE OPCIONES El servidor accede a que el cliente enve su tipo de terminal El servidor enva las opciones que desea negociar con el cliente
El servidor responde a las peticiones de opciones que le llegan desde el cliente
El servidor recibe las respuestas a las peticiones que solicit al cliente
NEGOCIAR MS (SUB)OPCIONES? NO
FIN DEL PROCESO NEGOCIACIN DE OPCIONES
PROCESO OBTENER TERMINAL DEL NVT: en este proceso, el servidor simplemente obtiene el tipo de terminal del cliente del NVT, ya que el cliente ha debido mapearlo all previamente.
OBTENER TERMINAL (NVT)
El servidor obtiene el tipo y lo mapea
FIN DEL PROCESO OBTENER TERMINAL
Pgina 20 de 29
PROCESO VERIFICAR AUTENTICACIN: este proceso se encarga de esperar a que, una vez finalizada la negociacin de opciones por parte de ambos extremos, el cliente enve mensajes con el nombre de usuario y la contrasea, supuesto esto despus de que el servidor le enve el prompt para iniciar la sesin Telnet solicitando los datos. Dado que en Telnet, toda la informacin se enva en claro, para que el envo de la contrasea de identificacin no suponga un problema de seguridad para el cliente ni para el servidor, se llevar a cabo un proceso de cifrado de la contrasea mediante DES en el cliente, de forma transparente al usuario; esto implica que el servidor deber llevar a cabo un descifrado de la contrasea una vez obtenido el par usuariocontrasea. El servidor deber entonces verificar que el par es vlido (es decir, est presente en su registro de usuarios de forma unvoca, esto es, ambos datos deben estar asociados y presentes en el registro); en caso de ser datos vlidos, se proceder a iniciar la sesin, y en caso de no ser vlidos, se enviar un mensaje de error al cliente. Dado que el cliente se encarga de verificar cul es el nmero de intentos permitidos antes de cancelar la sesin, el servidor slo cerrar la conexin cuando reciba un mensaje del cliente solicitndolo as. El motivo por el que se ha elegido DES como algoritmo de cifrado, tanto en el cliente como en el servidor, se debe a que es un algoritmo de implementacin sencilla y suficientemente potente como para servirnos en una aplicacin que requiere un nivel de seguridad no especialmente crtico. Para que el algoritmo sea vlido, tanto el cliente como el servidor han de conocer la clave de cifrado que se va a utilizar en la sesin. No obstante, incluiremos la gestin de claves de cifrado y la distribucin de stas dentro del bloque de autenticacin y cifrado, despreocupndonos de la codificacin (ya que no tiene sentido en este caso pararnos a estudiar la seguridad; no es el objetivo de este documento).
Pgina 21 de 29
VERIFICAR AUTENTICACIN
Enviar prompt de sesin al cliente
Enviar solicitud de nombre de usuario al cliente (>Login: ) El servidor recibe un mensaje por parte del cliente con el nombre de usuario; se enva solicitud de la contrasea asociada al cliente (>Passwd: ) El servidor recibe la contrasea cifrada mediante DES; la descifra
El servidor consulta su registro de usuarios buscando coincidencia en el par usuario-contrasea
PAR LOGIN PASSW VLIDO? NO Se enva al cliente mensaje de error NO
Se enva al cliente mensaje de bienvenida y prompt de sesin
FINAL? S El cliente envi mensaje de error, por tanto se libera la conexin (socket)
FIN DEL PROCESO AUTENTICACIN EN EL SERVIDOR
Pgina 22 de 29
PROCESO SESIN: REALIZAR OPERACIONES: en este proceso se llevar a cabo la sesin Telnet propiamente dicha. Esta sesin depende de la aplicacin y del tipo de servidor que tengamos; podra tratarse, por ejemplo, de un router que se quisiera configurar de forma remota a partir de la conexin a ste desde un cliente Telnet, o bien un servidor de comparticin de archivos que permitiera subir y/o descargar documentos en/desde el servidor. Para que el cliente sepa por dnde empezar a la hora de buscar las opciones necesarias, se le enviar un mensaje desde el servidor indicndole que teclee help para conocer todos los comandos de sistema que puede ejecutar.
El servidor enva aviso al cliente indicndole que el comando help es de ayuda
Se enva al cliente el prompt de sistema para teclear comandos Se enva al cliente un mensaje de error desde el servidor
Se recibe un comando desde el cliente Se ejecuta el comando y se enva un mensaje al cliente con el resultado
NO
COMANDO VLIDO? S COMANDO FINALIZAR? S FIN DEL PROCESO SESIN NO
Pgina 23 de 29
PROCESO LIBERAR CONEXIN TCP/IP: este proceso se encarga de, una vez que el cliente cierra la sesin Telnet, cerrar tambin la conexin TCP/IP en el servidor, liberndola. Para ello debe liberar el socket (primitiva close(id_socket), donde id_socket es el descriptor del socket de la conexin TCP/IP). Este proceso es, por tanto, muy sencillo. Una vez cerrada, hay que eliminar al proceso hijo, devolvindole el PID al proceso padre.
LIBERAR CONEXIN TCP/IP
Cerrar el socket en el servidor (close) para liberar la conexin
Finalizar el proceso hijo y devolverle el PID al proceso padre
FIN DEL PROCESO LIBERAR CONEXIN TCP/IP
De momento, tanto en el apartado dedicado al cliente como en el dedicado al servidor nos hemos preocupado nicamente de dar una visin funcional del problema y su resolucin; hemos dibujado los flujogramas explicativos del diseo de cada una de las aplicaciones y de los procesos que las componen, pero no nos hemos preocupado de la implementacin prctica de los mdulos. En el siguiente apartado se darn algunas claves bsicas para entender cmo sera la codificacin, en un lenguaje de alto nivel, de ciertos aspectos relacionados con el protocolo Telnet.
Pgina 24 de 29
5.- Consideraciones prcticas de implementacin.-
En este apartado nos encargaremos de explicar someramente algunas ideas acerca de la implementacin prctica del protocolo en la aplicacin final (tanto cliente como servidor), especialmente en lo que atae a una codificacin en un lenguaje de programacin de alto nivel. Las consideraciones prcticas que aqu se van a explicar son generales y vlidas tanto para la aplicacin cliente como servidor, por lo que no se van a hacer distinciones notables entre el pseudocdigo generado para una y para otra. En primer lugar hay que recordar dos aspectos que ya se han mencionado anteriormente, acerca de las particularidades de este protocolo. El primero es que las aplicaciones que implementan protocolos tales como Telnet, FTP, SMTP, Finger y Whois, usan codificacin NVT ASCII. Esto significa que cada carcter est codificado con 7 bits, y habitualmente suelen transmitirse como un byte completo con el bit ms significativo puesto a 0. El segundo aspecto a recordar es que, salvo que el servidor acepte una modificacin al respecto, el modo de operacin por defecto de trabajo ser el modo carcter, por lo que cada orden se enviar carcter a carcter. Esto nos obliga a trabajar de una forma un tanto especial. La sealizacin de los comandos Telnet se har, por defecto, en modo carcter. El protocolo est preparado para ello, y se utiliza el byte 0xFF como bit indicador de que lo que le sucede en la lnea es un comando. A este bit se le llama IAC (Interpret As Command). A continuacin se enva el byte correspondiente al comando en s mismo; cada comando est codificado con un byte. Este mecanismo tiene el problema de que empleando codificacin con 7 bits no podemos enviar IAC, ni tampoco la mayora de bytes de comando. Para ello sera necesario realizar una implementacin en modo binario, en lugar de hexadecimal, que nos resolviera el problema; dicha implementacin est especificada en la RFC 856. El problema de enviar el byte 0xFF como dato en lugar de como IAC se resuelve envindolo por duplicado; de esta forma el protocolo interpreta que se encuentra con un dato de valor 0xFF. Por tanto, no se puede codificar ningn comando Telnet mediante el cdigo decimal 255. En el caso de llevar a cabo una negociacin de opciones, el mecanismo cambia sensiblemente. En este caso, se enviara primero el byte IAC, seguido de la peticin deseada (WILL, WONT, DO, DONT), y despus enviar el byte que codifica segn el protocolo la opcin a habilitar o deshabilitar. Dado que el protocolo Telnet, salvo en determinados detalles particulares, est pensado para ser simtrico (esto es, cada extremo puede empezar libremente una negociacin de opciones o enviar determinados comandos permitidos), la implementacin siguiente es vlida tanto para el cliente como para el servidor. Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque
Pgina 25 de 29
El envo de comandos Telnet podra codificarse en pseudocdigo como se muestra a continuacin:

Buffer [N] = {lista_de_comandos_a_enviar}; While(datos_en_el_buffer) { send (IAC); //interpretar como comando send (Buffer[i]); //comando a enviar i++; }
En el caso de tratarse de una negociacin de opciones, el pseudocdigo sera levemente distinto en este caso. Habra que mantener una lista de comandos a enviar, asociados con la peticin asociada a cada uno (tanto peticin como respuesta a una peticin del otro extremo). El pseudocdigo sera por tanto:
Buffer1 [N] = {lista_de_peticiones_asociadas}; Buffer2 [N] = {lista_de_comandos_a_enviar}; While(datos_en_Buffer1 && datos_en_Buffer2) { send (IAC); //interpretar como comando send (Buffer1 [i] ); //peticin asociada al siguiente comando send (Buffer2 [i] ); //comando a enviar i++; }
A la hora de recibir datos, tendremos que ser capaces de distinguir si se trata de un comando simple, una negociacin de opcin, o un dato cualquiera. Para ello, tendremos que mantener una lista de los cdigos especiales que identifican los comandos y las opciones de negociacin. Esto es sencillo, basta con tener las constantes predefinidas e identificadas; en el caso de C, se hara con #define:
//Esto es un ejemplo, se pondrn aqu algunas constantes a ttulo de curiosidad //En primer lugar, comandos #define IAC 255 //Interpret As Command #define EOF 236 //End of file #define SUSP 237 //Suspend //ms comandos hasta llegar a 250 #define WILL 251 #define WONT 252 #define DO 253 #define DONT 254 //Algunas opciones de negociacin #define ECHO 1 //control del eco #define SGA 3 //suppress go ahead //ms opciones de negociacin, actualmente las RFCs definen ms de 40
Pgina 26 de 29
A la hora de recibir los datos, habr que estudiar qu se est recibiendo para actuar en consecuencia. Sabemos que si se recibe un byte IAC no duplicado se trata de un comando; y en caso de comando, hay que distinguir si se trata de un comando simple o de una negociacin de opcin. El pseudocdigo para llevar a cabo la distincin y realizar correctamente el tratamiento de los datos recibidos podra ser el siguiente:
Byte_recibido = Extraer_Byte_Del_Buffer_De_Recepcin ( ); If (Byte_recibido == IAC) { //Puede ser dato, comando, opcin //Necesitamos extraer un segundo byte Byte_recibido = Extraer_Byte_Del_Buffer_De_Recepcin ( ); Switch (Byte_recibido) { Case IAC: Es_El_Dato (Byte_recibido); //es un dato Break; Case WILL, WONT, DO, DONT: //El siguiente byte es opcin de negociacin Opcion = Extraer_Byte_Del_Buffer_De_Recepcin ( ); Respuesta = Negociar (Byte_recibido, Opcion); Break; Default: //Es un byte de comando Comando_Recibido (Byte_recibido); Break; } } else { //Hemos recibido un dato Es_El_Dato (Byte_recibido); //es un dato }
En el pseudocdigo anterior, las diversas funciones se encargaran de realizar el tratamiento de la informacin extrada del buffer de recepcin de datos, dependiendo de si se trata de un simple dato, de un comando, o de una negociacin de opcin. En los dos primeros casos el tratamiento es simple, ya que bastara con evaluar el valor que se pasa como argumento a las funciones y llevar a cabo las acciones necesarias. En el caso de la negociacin, habra que implementar las reglas que se describieron en la tabla de posibilidades del apartado 2 de este documento, pero tambin sera una funcin muy sencilla.
//En C, el pseudocdigo de la funcin sera el siguiente: Int * Negociar ( accion, opcion ) { Int respuesta[2] ; //devolver accin y cdigo de respuesta respuesta[1] = opcion; Switch (accion) { Case WONT: Respuesta[0] = DONT; break; Case DONT: Respuesta[0] = WONT; break; Default: //en estos casos la respuesta s puede variar Respuesta[0] = Obtener_Respuesta (accion); Break; } Return respuesta; }
Pgina 27 de 29
Hay que tener en cuenta que, en todos los casos anteriores, se ha hecho una simplificacin del problema: en principio, con NVT ASCII no podramos emplear un solo byte para enviar los comandos o las negociaciones de opciones. En cualquier caso, se ha procedido as para simplificar el pseudocdigo.
6.- Conclusiones y posibles mejoras.-
En conclusin a este trabajo, se puede afirmar que el protocolo Telnet es un protocolo que cumple holgadamente su funcin: permitir la comunicacin entre mquinas de distinto tipo. Es un protocolo flexible y que admite mltiples posibilidades, y esto es lo nico que podra dificultar en parte su implementacin prctica: puede incluir seguridad y autenticacin, cifrado, control de flujo, varios modos de funcionamiento, etc. Tambin es posible afirmar que, aunque la arquitectura interna de este protocolo no es clienteservidor (debido fundamentalmente a la simetra del protocolo), en la prctica es posible desarrollar una aplicacin que funcione como cliente-servidor: de ah el ttulo, a primera vista contradictorio con el protocolo, de este trabajo. La aplicacin cliente-servidor para protocolo Telnet que aqu se ha desarrollado probablemente no funcionara correctamente con clientes y/o servidores distintos a los desarrollados. Esto se debe no a que hayamos violado de alguna manera las directrices del protocolo, sino a que se han aadido ciertas funcionalidades que no tendran por qu estar presentes en cualquier otro cliente o servidor Telnet (por ejemplo, el cifrado de la clave mediante DES). Por tanto, una posible mejora podra consistir en eliminar dicho cifrado, pero eso redundara en la seguridad de la autenticacin, lo cual podra ser contraproducente en determinadas aplicaciones. Otra posibilidad es fijar por defecto el modo de trabajo en modo lnea. Esto evitara la gran cantidad de trfico que se genera en la lnea debido a que cada carcter se enva en un mensaje distinto, provocando diversas colisiones y multitud de paquetes circulando por la red. Las colisiones adems agravan el problema. Tambin podramos tratar de implementar una aplicacin que empleara caracteres ASCII en lugar de NVT ASCII a la hora de trabajar con los datos. Esto evitara el problema de no poder enviar los comandos con un solo byte, pero hara que las aplicaciones fueran potencialmente invlidas con clientes y servidores ajenos a los desarrollados, que no tendran por qu implementar ASCII en lugar de NVT ASCII. En definitiva, este protocolo admitira mltiples implementaciones estndar y no estndar, queda en manos del desarrollador decidir si prefiere crear un diseo vlido para cualquier cliente y/o servidor, o desarrollar el par Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque
Pgina 28 de 29
propio. En funcin del destino de la aplicacin, puede ser interesante cualquiera de las dos alternativas.
7.- Bibliografa.-
W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley Professional Computing Series. J. M. Arco Rodrguez, B. Alarcos Alczar, A. Domingo Ajenjo, Programacin de aplicaciones en redes de comunicaciones bajo entorno UNIX. Servicio de publicaciones de la UAH. Apuntes de clase.

Telnet

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Telnet

Încărcat de

Drepturi de autor:

Formate disponibile

APLICACIONES TELEMTICAS 5 INGENIERA DE TELECOMUNICACIN

Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

2.- Caractersticas a implementar.-

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

3.- Diseo de la aplicacin Telnet: cliente.-

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

CONEXIN TCP/IP (establecimiento)

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

EMPEZAR (arranque programa)

Iniciar la aplicacin en la mquina del cliente

FIN DEL PROCESO EMPEZAR PROGRAMA

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

CONEXIN TCP/IP (establecimiento)

Creacin del socket, para asociacin y conexin con el servidor

Arrancar temporizador, esperar conexin

Liberar conexin (socket) fallida

EXPIRACIN DEL TEMPORIZADOR? S

NUM_CONEXION = 2? S Fallo en la conexin

Mensaje de error en el terminal del cliente

Liberar conexin (socket) fallida

FIN DEL PROCESO CONEXIN TCP/IP

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

El cliente responde a las peticiones de opciones que le llegan desde el servidor

El cliente recibe las respuestas a las peticiones que solicit al servidor

FIN DEL PROCESO NEGOCIACIN DE OPCIONES

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

El cliente recibe mensaje de bienvenida y prompt de sesin

FIN DEL PROCESO AUTENTICACIN EN EL SERVIDOR

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

SESIN: REALIZAR OPERACIONES

COMANDO VLIDO? S COMANDO FINALIZAR? S FIN DEL PROCESO SESIN

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

LIBERAR CONEXIN TCP/IP

Cerrar el socket en el cliente (close) para liberar la conexin

FIN DEL PROCESO LIBERAR CONEXIN TCP/IP

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

4.- Diseo de la aplicacin Telnet: servidor.-

Telnet: diseo de una aplicacin cliente/servidor

PETICIN DEL CLIENTE? S CONEXIN TCP/IP (establecimiento: hilos)

S OBTENCIN DEL TERMINAL (NVT)

SESIN: REALIZAR OPERACIONES

MENSAJE DEL CLIENTE (FIN OPERACIONES)? S CONEXIN TCP/IP (liberacin)

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin Autora: Alexandra Lorente Cablanque

Telnet: diseo de una aplicacin cliente/servidor

Iniciar la aplicacin en la mquina del servidor

FIN DEL PROCESO EMPEZAR PROGRAMA