Telnet PDF

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

Aplicaciones Telemticas, 5 de Ingeniera de Telecomunicacin
Autora: Alexandra Lorente Cablanque
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

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

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.


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 RESPUESTA DESCRIPCIN
WILL DO El que enva la peticin quiere habilitar
opcin l mismo; el otro extremo accede
WILL DONT El que enva la peticin quiere habilitar
opcin; el otro extremo no accede
DO WILL El que enva la peticin quiere que el otro
habilite opcin; el otro extremo accede
DO WONT El que enva la peticin quiere que el otro
habilite opcin; el otro extremo no accede
WONT DONT El que enva la peticin quiere deshabilitar
opcin l mismo; el otro extremo est
obligado a acceder
DONT WONT El que enva la peticin quiere que el otro
extremo deshabilite opcin; el otro
extremo est obligado a acceder

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.


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:



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.

NO
S
S
NO
EMPEZAR
(arranque programa)
CONEXIN TCP/IP
(establecimiento)
NEGOCIACIN DE
OPCIONES (y mapeo en
el NVT en caso de
negociar el tipo de
Terminal)
AUTENTICACIN EN
EL SERVIDOR
FIN DE
NEGOCIACIN?
SESIN: REALIZAR
OPERACIONES
MENSAJE DEL
SERVIDOR (FIN
OPERACIONES)?
FINALIZAR
PROGRAMA
CONEXIN TCP/IP
(liberacin)
S


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.

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.

Iniciar la aplicacin en la
mquina del cliente
FIN DEL PROCESO
EMPEZAR
PROGRAMA
EMPEZAR
(arranque programa)


NO
NO
S
S
CONEXIN TCP/IP
(establecimiento)
Creacin del socket,
para asociacin y
conexin con el servidor
Arrancar temporizador,
esperar conexin
EXPIRACIN DEL
TEMPORIZADOR?
NUM_CONEXION
inicialmente a 1
Incrementar
NUM_CONEXION
Liberar conexin
(socket) fallida
NUM_CONEXION
= 2?
xito en la conexin
Fallo en la conexin
Mensaje de error en el
terminal del cliente
Liberar conexin
(socket) fallida
FINALIZAR
PROGRAMA
FIN DEL PROCESO
CONEXIN TCP/IP

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).

NO
S
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?
Mapear tipo de terminal en
el NVT para el servidor, y
esperar confirmacin de
recepcin de ste
FIN DEL PROCESO
NEGOCIACIN DE
OPCIONES

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.



NO
S
S
NO
El cliente espera a que aparezca el
prompt de sesin; ste pedir un nombre
de usuario vlido (>Login: )
AUTENTICACIN EN EL
SERVIDOR
El cliente introduce el nombre de
usuario en su terminal; ste se
visualizar en claro en el terminal
El cliente espera a que aparezca el
prompt de sesin; ste pedir la
contrasea asociada (>Passwd: )
Variable INTENTOS = 1
INTENTOS = 3?
El cliente introduce su contrasea, que
no se ve en su terminal, y se enva
cifrada al servidor (DES)
PAR LOGIN
PASSW VLIDO?
El cliente recibe
mensaje de bienvenida
y prompt de sesin
El cliente recibe
mensaje de error
La variable
INTENTOS se
incrementa una unidad
El cliente recibe mensaje de error,
contesta y se libera la conexin (socket)
FINALIZAR PROGRAMA
FIN DEL PROCESO
AUTENTICACIN EN EL
SERVIDOR

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.

Es importante destacar que no es el lado del cliente quien finaliza la
sesin, sino el propio servidor al recibir la peticin del cliente.

S
NO
S
NO
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 teclea un
comando
COMANDO
VLIDO?
COMANDO
FINALIZAR?
El cliente recibe un
mensaje de error desde el
servidor y lo muestra por
el terminal del cliente
FIN DEL PROCESO
SESIN
Se muestra el resultado
de la operacin devuelto
por el servidor en el
terminal del cliente

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.

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.
LIBERAR
CONEXIN TCP/IP
Cerrar el socket en el
cliente (close) para
liberar la conexin
FIN DEL PROCESO
LIBERAR CONEXIN
TCP/IP

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 usuario-
contrasea 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

continuamente prestando servicio, por lo que lo habitual es que se encuentre
arrancado y esperando conexiones por parte de los clientes.

S
S
NO
S
NO
NO
EMPEZAR
(arranque programa)
BLOQUEADO EN
COLA DE ESPERA
NEGOCIACIN DE
OPCIONES
VERIFICAR
AUTENTICACIN
FIN DE
NEGOCIACIN?
SESIN: REALIZAR
OPERACIONES
MENSAJE DEL
CLIENTE (FIN
OPERACIONES)?
CONEXIN TCP/IP
(liberacin)
OBTENCIN DEL
TERMINAL (NVT)
CONEXIN TCP/IP
(establecimiento: hilos)
PETICIN
DEL CLIENTE?


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.

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.

Iniciar la aplicacin en la
mquina del servidor
FIN DEL PROCESO
EMPEZAR
PROGRAMA
EMPEZAR
(arranque programa)


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.

Se crea un socket de
conexin y se asocia con
la direccin IP y el
puerto de escucha
FIN DEL PROCESO
BLOQUEADO EN
COLA DE ESPERA
BLOQUEADO EN
COLA DE ESPERA
Se crea una cola de
escucha de peticiones
(primitiva listen)


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.

CONEXIN TCP/IP
(establecimiento)
Fork: crear proceso hijo
El proceso hijo acepta la
conexin y se encarga de
ella (primitiva accept)
El proceso recibi una
peticin de conexin por
parte de un cliente
El proceso padre ha
cedido el control al hijo,
y vuelve a la cola de
espera a atender ms
peticiones
FINALIZAR
PROCESO
CONEXIN
VUELTA AL
PROCESO
BLOQUEADO


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.

El servidor obtiene el
tipo y lo mapea
FIN DEL PROCESO
OBTENER
TERMINAL
OBTENER
TERMINAL (NVT)
NO
S
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?
FIN DEL PROCESO
NEGOCIACIN DE
OPCIONES


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 usuario-
contrasea. 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).



NO
S
S
NO
Enviar solicitud de nombre de usuario al
cliente (>Login: )
VERIFICAR AUTENTICACIN
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
Enviar prompt de sesin al cliente
FINAL?
El servidor consulta su registro de
usuarios buscando coincidencia en el par
usuario-contrasea
PAR LOGIN
PASSW VLIDO?
Se enva al cliente
mensaje de bienvenida
y prompt de sesin
El cliente envi mensaje de error, por
tanto se libera la conexin (socket)
FIN DEL PROCESO
AUTENTICACIN EN EL
SERVIDOR
Se enva al cliente
mensaje de error

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.

S
NO
S
NO
SESIN: REALIZAR
OPERACIONES
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 recibe un comando
desde el cliente
COMANDO
VLIDO?
COMANDO
FINALIZAR?
Se enva al cliente un
mensaje de error desde el
servidor
FIN DEL PROCESO
SESIN
Se ejecuta el comando y
se enva un mensaje al
cliente con el resultado


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.

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.
LIBERAR
CONEXIN TCP/IP
Cerrar el socket en el
servidor (close) para
liberar la conexin
FIN DEL PROCESO
LIBERAR CONEXIN
TCP/IP
Finalizar el proceso
hijo y devolverle el
PID al proceso padre

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.


El envo de comandos Telnet podra codificarse en pseudocdigo como
se muestra a continuacin:

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:

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:

Buffer [N] = {lista_de_comandos_a_enviar};

While(datos_en_el_buffer) {

send (IAC); //interpretar como comando
send (Buffer[i]); //comando a enviar
i++;

}
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++;

}
//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


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:

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.

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 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;
}

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 cliente-
servidor (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

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 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Telnet PDF

Cargado por

Copyright:

Formatos disponibles

APLICACIONES TELEMTICAS

También podría gustarte