Copy Link
Add to Bookmark
Report
SET 021 0x0f
-[ 0x0F ]--------------------------------------------------------------------
-[ Terminales Graficas ]-----------------------------------------------------
-[ by FCA00000 ]------------------------------------------------------SET-21-
Terminales Graficas
-------------------
En este articulo voy a explicar el funcionamiento de las terminales de
acceso a un ordenador, sobre todo las de tipo grafico. Ejemplo de esto
es el sistema X-window.
-Que?
Un terminal es un aparato de hardware, generalmente con varios perifericos
conectados, fundamentalmente teclado, raton, monitor y conexion.
-Para que?
Su aplicacion se encuentra en el uso de recursos compartidos por varios
usuarios, sin necesidad de tener potencia alli donde no se necesita, sino
centralizandola en un ordenador principal.
-Como?
Las terminales simplemente son dispositivos de entrada/salida de datos,
mandando/recibiendolos a la maquina principal (host) mediante una conexion.
-Quien?
Se usa mayoritariamente en centros de calculo, donde existen ordenadores muy
potentes, y varios usuarios que necesitan esa potencia, pero estan dispuestos
a compartirla con otros, pues sus calculos son urgentes, pero hacen pocos.
-Donde?
Las terminales se instalan en lugares de acceso restringido: laboratorios,
centros de proceso, entornos de seguridad, ...
-Cuando?
Tan pronto cuanto es posible. Se rentabilizan rapidamente.
TERMINALES DE TEXTO
En un principio (en los 60), la informatica era centralizada. Las empresas
adquirian una computadora destinada al calculo, y los trabajadores o
investigadores introducian sus datos mediante sus terminales. Esos datos
se procesaban al momento o en batch, y el resultado era devuelto al
teletipo.
Esto permitia un optimo aprovechamiento de los recursos, pues cuando el 10%
de los trabajadores estaban haciendo trabajar a la maquina, el restante 90%
simplemente introducia datos, con lo que no se notaba retardo alguno.
Los mismo pasaba con las tarjetas perforadas: la lectura, proceso y
escritura ocupaba un tiempo minimo comparado con la creacion de las tarjetas
por parte del usuario.
Despues llegaron los terminales de texto. Eran sistemas con un teclado, una
pantalla, y una linea de conexion RS-232. El monitor entendia secuencias ANSI
del tipo "mueve el cursor a la posicion 80,25 e imprime la letra X".
El teclado mandaba las combinaciones de teclas mediante la misma linea.
El ordenador central necesitaba un monton de puertos serie (y, por supuesto,
un sistema operativo multiusuario y multiproceso), o bien tarjetas
multiplexoras.
El sistema es barato, facil de instalar, y se usa mas de lo que creeis:
centralitas de incendios, de telefonia, sistemas de semaforos, BBS,
cajeros automaticos, cajeros de supermercados, pool de modems, lavadoras
con interface serie, ...
Creo que no me equivoco si digo que todos los ordenadores tienen un software
que les hace actuar como terminal, y que un 90% de los aparatos "inteligentes"
tienen un software que les hace actuar como servidor de terminal.
El funcionamiento es muy sencillo:
-un hardware minimo (puertos serie)
-conexion con cable de 3 hilos (GR, TR, TS)
-un protocolo de control (ej. 8N1, 2400)
-protocolo de datos: ANSI
-emulacion de terminal (ej. VT100)
Desde el punto de vista de la seguridad, el sistema esta totalmente abierto:
-el cable se puede husmear (sniffing)
-un ordenador con 2 puertos series, puede modificar los datos (hijacking)
-no hay autentificacion del host (spoofing)
-no hay verificacion del cliente
Hay que contar con otros problemas de seguridad
-parametrizacion erronea
-cortes en la linea
-cortes en el terminal
-debil chequeo de errores de transmision
-el mas grave: los usuarios creen que apagando el monitor, se corta la conexion
En conclusion, el uso fraudulento de una terminal es cosa de crios.
Esto se supone que se mejora con el uso de autentificacion: usuario/password.
Sin embargo, debo mencionar que hay muchos servidores de terminales que solo
utilizan la password, y algunos ni siquiera esto.
Y, por supuesto, el sniffing es una tecnica tan vieja como efectiva.
Es cierto que las terminales de texto eran rapidas: incluso para redibujar
toda la pantalla (80x25) con colores (2 bytes) hacia falta mandar 4000 bytes;
a 9600 baudios, se tardaban 4 segundos en mandar los datos; pero redibujando
solo las zonas que cambian, el retraso es inapreciable. Y, por supuesto, a
mayor velocidad, menor retraso.
Mas informacion de la que puedas procesar:
Text-Terminal-HOWTO de Linux
Serial-HOWTO de Linux
Pero siempre se quiere algo mas.
TERMINALES GRAFICOS
El siguiente paso fueron las terminales graficas.
La creacion del raton dio paso a una nueva generacion de interface: el GUI
o Graphical User Interface. Ventanas, raton, botones, checkbox, ... todo
un mundo de objetos. Y eso sin contar los dibujos, animaciones, sonido.
Cuando los de Xerox desarrollaron la idea tuvieron que pensar mucho.
Una de las cosas buenas que se les ocurrio era separar el software del
hardware. Dicho de otro modo: nada de accesos a memoria, ni lectura
continuada del raton, ni ocuparse de superposicion de ventanas. Eso lo tiene
que hacer el hardware. Si una aplicacion quiere dibujar, que lo diga, y sera
la terminal la que haga el trabajo estrictamente grafico.
Asi inventaron las terminales graficas con estructura cliente-servidor, que
llamaron sistema 'W'
Como pasa con estos temas, unos cuantos fabricantes de terminales decidieron
usar este sistema, estandarizarlo, formar comites, y cambiarle el nombre.
Nace X-window, avalado por el X-Consortium.
La primera implementacion para el publico era X9, a la que siguio X10, X11r1,
X11R2, ... X11R6, X11R6.3 y las que vengan.
La filosofia de X-Window (y no X-WindowS, como la gente se obceca) es tan
sencilla como el modelo cliente-servidor: Una aplicacion quiere
dibujar (o leer el raton o teclado), y le lanza una peticion al servidor.
Notar que el cliente es la aplicacion, y el servidor es el terminal.
Podria parecer que es al contrario, pero estamos hablando de servidor de
graficos, no de servidor de procesamiento.
Luego se subieron otros al carro del tele-control:
PcAnywhere (Symantec)
CarbonCopy
RemoteControl
VNC (dominio publico, de Olivetti & Oracle)
WinFrame (Citrix)
TerminalServer (Microsoft)
Como el primero, el mas potente, el mas facil y el que mas me gusta es el
sistema X-Window, lo explico el primero.
PRIMER PASO: REQUISITOS
La conexion entre un terminal y sus clientes se realiza fisicamente a traves
de una red. Lo mas comun es Ethernet con TCP/IP, pero se admiten muchos tipos
de variacions: PPP, FastEthernet, DECNET, ... con todo lo que esto
implica: modems, firewalls, multicast, sniffing, ...
Las terminales pueden tener disco duro, o no. En todo caso, siempre deben tener
una conexion, que suele ser a traves de red local.
Recordar que las terminales de texto ya incorporan un interface serie,
una (o varias) emulacion de terminal, y soportan las secuencias de control ANSI.
Pero las terminales graficas no suelen tener esto incluido en su memoria, sobre
todo porque se incorporan mejoras (tarjetas graficas o de red, aceleracion de
graficos, parches al Xserver) y seria engorroso tener que abrir el XTerminal
cada vez que hay una modificacion de software.
Si tienen disco duro (Xfree Linux, X-Reflection Win, X-Lite DOS, Xserver SUN)
es necesario saber el tipo de tarjeta grafica para configurar el servidor,
asi como conocer el puerto del raton, tener instalada la tarjeta de red,
y configurar la resolucion/frecuencias del monitor. De esto se ha escrito
mucho, y actualmente no deberia ser problema para cualquier aficionado al UN*X
el tener un servidor X en marcha.
Otro tema es configurar un diskless-station. Todo se hace con TFTP.
Trivial File Transfer Protocol es un protocolo TCP/IP que sirve para hacer
transferencia de ficheros, de modo simple. No hay usuario/clave, no hay
directorios, no se pueden hacer listados, no se pueden meter archivos, y
suele estar mal configurado.
El funcionamiento es este: al encender el XTerminal, la tarjeta de red lanza
una peticion a un ordenador servidor de TFTP (tambien se puede hacer un
broadcast) muy simple; solo contiene el comando "get X"
Gracias al protocolo TCP, se sabe cual es la direccion TCP origen (iaddr)
Gracias al protocolo IP, se sabe cual es la direccion MAC origen (haddr)
El servidor TFTP consulta el archivo /etc/tftpboot
manda el archivo /tftpboot/MAC a la direccion que lo pidio.
Por cierto, que lo manda con protocolo de datagramas udp (puerto 69).
Hay una implementacion mas completa del TFTP que salio mas tarde: secure TFTP
Esta es la que se suele encontrar en la mayoria de servidores TFTP, e incluye
la posibilidad de configuraciones complejas, autentificacion segun TCP+MAC
y permite copiar archivos (upload). Sin embargo, no permite copiar ficheros
a un directorio distinto de /tftpboot (o el que haya configurado el
administrador).
En situaciones donde las Xterminales no tienen disco duro, todo el Sistema
Operativo lo obtienen del servidor TFTP, por lo que este suele exportar parte
del sistema de ficheros, habitualmente por NFS. Aqui tambien se pueden
obtener algunos resultados agradables para el hacking.
Sin embargo, es comun que se pueda bajar un fichero (download), modificarlo,
y luego meterlo de nuevo, con lo que se tiene un servidorX crackeado.
Asi es posible capturar pulsaciones de teclas, por ejemplo, o simularlas.
Como digo, suele estar mal configurado, y, aunque poca gente usa terminalesX
hoy en dia, se pueden hacer cosas muy, muy malas.
Mas informacion: man tftp, man tftpboot , extension TFTP RFC1048, y el
manual X Window System Administrator's Guide, de SunOS/Solaris.
Tambien vale la pena The X window System. Volume 0. X Protocol, de O'Reilly
SIGUIENTE PASO: CONEXIONES
Aunque no lo parezca, tenemos ahora una aplicacion (el Xserver) que esta
esperando peticiones de conexion por el puerto 6000. Efectivamente, un
netstat indica que este puerto esta listening.
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:6000 *:* LISTEN
tcp 0 0 localhost:1024 localhost:6000 ESTABLISHED
tcp 0 0 localhost:6000 localhost:1024 ESTABLISHED
Active UNIX domain sockets (including servers)
Proto RefCnt Flags Type State I-Node Path
unix 1 [ ACC ] STREAM LISTENING 25906 /tmp/.X11-unix/X0
unix 2 [ ] STREAM CONNECTED 25910
unix 2 [ ] STREAM 25932 /tmp/.X11-unix/X0
unix 2 [ ] STREAM CONNECTED 25934
unix 2 [ ] STREAM 25935 /tmp/.X11-unix/X0
Se ve claramente que por cada cliente, se establece una conexion con el
servidor, a traves del puerto 6000.
Notar tambien que, en local, la conexio nse lleva a cabo por un fichero.
Asi que, si estas en un entorno multiusuario, ten cuidado con los permisos
que se le dan a este fichero, no vaya a ser que otros usuarios puedan leer
o escribir en el.
Al igual que el resto de los protocolos TCP/IP (o DECNET), los comandos del
sistema X-Window se componen de tramas de datos con origen, destino, tipo,
modificadores, y datos.
Esto es lo que hace grande y versatil este sistema: es independiente de las
otras capas OSI. Cuando hay conexion, ya se puede trabajar.
Ademas, la estructura los datos son de dominio publico y estan perfectamente
documentadas por el X-Consortium (todo es trabajo del MIT), y asi cualquiera
puede implementar un servidor X, o una aplicacion que hable protocolo X. Claro
que para eso ya estan los chicos del XFree, sus servidores, y sus librerias
para los clientes.
Pero como el objetivo es aprender, comento la estructura de los paquetes:
PETICION (request)
Cada peticion contiene un codigo (opcode) de 8 bits , otro codigo secundario
de 8 bits, seguido por 16 bits que indican la longitud de los
datos (cada dato son 32 bits), y a continuacion los datos.
Por ejemplo:
comando Bell (pitar)
opcode=104 (0x68)
sec-opcode= tono
longitud=1 (1+1+2= 4 bytes = 32 bits = 1 dato)
Otro ejemplo:
comando ChangePointerControl
opcode=105 (0x69)
sec-opcode=0 (no usado)
longitud=3 (1+1+2 + 2+2+2 + 1+1 = 12 bytes = 36 bits = 3 datos)
aceleracion-numerador = dividendo (2 bytes)
aceleracion-denominadir = divisor (2 bytes)
variacion-minima = numero_pixels (2 bytes)
haz-aceleracion = 0/1 (1 byte)
haz-variacion = 0/1 (1 byte)
Otro mas:
comando AllocColor (usa color)
opcode=84
sec-opcode=0
longitud=4
mapa-colores
nivel_rojo
nivel_vede
nivel_azul
relleno
RESPUESTA (reply)
La longitud se marca como '0'
El primer byte es siempre '1'.
El siguiente es un codigo secundario.
El siguiente (mide 2 bytes) es un numero secuencial, para no perder eventos
Ej. respuesta a AllocColor
opcode=1
sec-opcode=0
secuencia=xx
longitud=0
nivel_rojo=rr
nivel_verde=gg
nivel_azul=bb
relleno
pixel
relleno
EVENTO (event)
Los eventos son transmitidos desde el servidor hacia el cliente.
No se especifica la longitud de la trama.
comando KeyPress (tecla pulsada)
opcode=2
sec-opcode=tecla
numero_secuencia (2)
hora (4)
ventana_raiz (4)
ventana_evento (4)
ventana_hija (4)
ventana_raiz_x (2)
ventana_raiz_y (2)
evento_x (2)
evento_y (2)
mascara_teclado (2)
misma_pantalla (1)
relleno (1)
Toda la lista de codigos se puede encontrar en 'X Window System Protocol',
y tambien en el volumen 0 de los libros de O'Reilly.
Por supuesto, la quia oficial esta en X11R6/include/X11/XProto.h
SIGUIENTE PASO: CLIENTES
Ahora, lo que tenemos es un fondo de puntos blancos y negros, y una X grande
que se mueve con el raton, mandando eventos como una loca, pero sin nadie
que le haga caso.
Entonces necesitamos clientes que quieran escribir en ese terminal.
Hay cientos de aplicaciones que funcionan en X-Window, y la mas simple es
una que se llama xbell.
La manera de llamarla es xbell -display ordenador:0.0
que simplemente manda el comando Bell, y consigue que pite la terminal.
Simple, y efectivo.
Otra aplicacion bastante util es el manejador de ventanas (window manager),
que usa casi todas los comandos del sistema X-window: trata fondos, teclas,
aceleradores, marcos, crea/destruye ventanas, graphic context, fuentes, ...
Sin el wm, es imposible mover ventanas.
Pero ojo, no es una parte intrinseca del sistema, como puede serlo el
manejador de ventanas de Win3.1, 95, NT, OS/2 o Amiga. Es, simplemente, un
programa que manda eventos a las ventanas, para que ellas mismas se redibujen,
se reposicionen, y cosas asi. Se obtiene lo mismo mandando los comandos
directamente, abriendo una conexion
telnet localhost 6000
y mandando (en binario)
104 100 0 1 (comando 'pitar')
o cualquier cosa mas compleja que se os ocurra.
Si lo habeis probado en vuestro ordenador, seguramente haya funcionado, pero
no siempre es asi.
PUESTOS EN RED
Como se ha dicho, los datos viajan por la conexion, y, siendo esta de tipo
TCP/IP, es posible que varias Xterminales usen varios hosts.
Es decir, cada Xterminal puede tener clientes un uno o varios ordenadores.
Para que no se forme mucho follon, y la seguridad funcione como tiene que ser,
se incorpora un protocolo de autentificacion, tanto por parte del cliente-host
como del servidor-terminal.
XHOST
Para que un Xterminal permita que un server lo use, es necesario que este en la
lista de los permitidos. Esta lista se mantiene con el programa xhost, cuyo
funcionamiento se basa simplemente en admitir o negar un server. No hay mas.
Esto es: si el usuario PEPE quiere ejecutar aplicaciones X en el ordenador HOST,
para que se visualicen en su terminal PEPEX, debe establecer una conexion
con el servidor (ej. con telnet), arrancar el servidor X, y permitirlo:
xhost +HOST
(para permitir que todos los hosts del mundo pueda escribir en su terminal)
Esto permite un ataque de tipo spoofing, si no fuera por que la mayoria de
los Xterminales se encuentran en una red local, con lo que es mas complicado
forzar el spoof.
Por supuesto, cuando se escribe
xhost +
(para permitir que todos los hosts del mundo pueda escribir en su terminal)
la seguridad se debilita totalmente.
Estonces es facil hacer un scaning de todos los Xterminales (ej, con strobe)
al puerto 6000, y arrancar cualquier aplicacion.
Por supuesto, existe ya una aplicacion que captura las pulsaciones de teclas
y el movimiento del raton, y se llama xspy. Una version mas depurada se
llama xsniff, que muestra una salida de datos bastante mas mona.
Al fin y al cabo, el comando 36 (GrabServer) esta para eso.
Lamentablemente (para los hackers), no hay tantos Xterminales por el mundo.
Y, por defecto, solo esta activado xhost +localhost
por lo que es necesario spoofing con direccion 127.0.0.1; A ver como lo haceis.
Una vez se tiene una aplicacion visualizandose en un Xterminal, es facil
mandarle pulsaciones de teclas (comando SendEvent), y hala, a hackear.
Tambien se puede mandar un dibujo, capturar lo que el usuario ve, o incluso
redirigir sus entradas y salidas a otro Xterminal.
Como te habras podido dar cuenta, no existe ninguna otra restriccion: no
usuario, ni password, nada de nada.
Por eso, en entornos multiusuario (compartiendo el mismo host) un usuario
puede usar el servidor, aunque lo haya arrancado otro usuario.
Eso permite facilmente ver lo que hace el usuario que esta sentado en la
consolaX principal.
Incluso mas: si varios usuarios de terminales X se validan contra el mismo
servidor (de autentificacion), lo normal sea que lo tengan como (xhost +) ,
por lo que cualquier usuario puede usar el Xserver de otro impunemente.
Esto se soluciona con un protocolo que implemente cifrado, tal como ssh.
Y, tal como estan las cosas, crackear a ssh es practicamente imposible.
Y tambien se puede aplicar xauth para aumentar la seguridad.
Mas datos en:
la mini-FAQ de Remote-X-Apps de Linux
http://ciac.llnl.gov/ciac/documents/ciac2316.html
comp.windows.x
www.x.org
RFC1013
OTROS SISTEMAS
VNC
Este es otro sistema de control remoto. En este modo no se opera con ventanas
distintas, sino que se toma el control total del ordenador host.
La nomenclatura cambia, y se llama servidor al ordenador que ejecuta las
aplicaciones, y cliente al que lleva el control del raton, teclado y pantalla.
Se arranca el/los servidor/es, se arranca el cliente, se conecta con el
servidor deseado, y se maneja en remoto.
En este caso el usuario que esta delante del servidor ve como se mueve el
cursor, aunque puede tomar el control en cualquier momento.
Hay unicamente servidor para Win9x/NT, pero clientes para Win3.1, Win9x/NT,
Linux y otros UNIX.
Los fuentes son publicos, y ademas muy instructivos.
La gracia esta en mandar los eventos por parte del cliente, y refrescar la
pantalla cada vez que cambia.
Solo funciona con TCP/IP, pero se puede hacer a traves de Internet.
El sistema de autentificacion es con puerto/clave, y la clave usa 16 bytes,
asi que es bastante dificil de conseguir.
Esto se comprueba mirando el codigo; la clave se le hace un hash, y esto es
lo que se chequea.
La verdad es que usa DES de simple longitud, tanto para archivar las claves
como para el desafio/respuesta.
Es uni-usuario; es decir, solo un terminal puede tomar control del servidor.
De hecho, el servidor deja de ser operativo mientras esta siendo manejado
en remoto.
El puerto usado para escuchar es el 5900, y se comienza el protocolo con
el comando RFB 003.003 , Asi que usa un protocolo llamado RFB, que
esta muy bien explicado en el archivo rfbproto.h , y se parece mucho al
que usa X-Window.
Asi que ya sabes: telnet xxx.yyy.zzz.ttt 5900 , y a ver quien te responde.
O se pueden usar otras herramientas; recomiendo strobe/iss para hacer un
port-scaning masivo. Luego, probar todas las claves.
O lo mas facil: parchear el fuente, y que lo haga por ti automaticamente:
modulo vncclient.cpp
funcion vncClientThread::InitAuthenticate
donde dice // Compare them to the response
Ojo que tiene un mecanismo de seguridad extra: cuando el cliente ha fallado
demasiadas veces la clave, no le deja intentarlo hasta pasado un rato.
Mas informacion (y fuentes) en www.orl.co.uk/vnc
CARBON COPY
Exactamente igual que el VNC, pero tambien permite que el cliente y el servidor
sean de MS-DOS, con lo que el trafico es menor. Es posible arrancar Windows
en el servidor, y que lo maneje el cliente. Lento, pero efectivo.
El sistema de autentificacion es basado en clave, y es bastante seguro.
Uni-usuario tambien.
REMOTE CONTROL
Lo mismo. Quizas un poco mas lento, supongo que porque decide mandar la
pantalla en momentos innecesarios. Es barato, pero solo se puede hacer a
traves de linea telefonica. La clave se puede establecer tanto en el cliente
como en el servidor. Asi se evita el spoofing en ambas direcciones.
Uni-usuario.
PC ANYWHERE
Nunca lo he usado.
WINFRAME
Merced a su protocolo ICA (Independent Computing Architecture), se afirma
que es el sistema que mas rapido transmite los datos. Y creo que es verdad.
Pero, como todos, se basa en enviar datos de uno a otro.
El sistema es multiusuario.
Usa un servidor de tipo NT con un "plug-in", por lo que la seguridad es
exactamente la misma que Nt Server 3.51 o 4.0
Funciona por TCP/IP, IPX, NetBios, o uno propietario.
En cualquier caso, se establece un protocolo superior llamado ICA que sirve
para enviar los movimientos del raton y teclado, y para recibir las
respuestas, que son siempre redibujar zonas de pantalla.
Con TCP/IP, el puerto usado es el 1512, y hay 2 tipos de paquetes:
-busqueda de servidor (broadcast) mide 512 y es UDP
-paquete de datos: protocolo TCP, hasta 1460 bytes.
y se reconoce que te atiende un servidor porque cada 2 segundos, manda
el comando
ICA
para ver si le respondes.
Hay clientes (redordar que la nomenclatura esta cambiada) para DOS,
Windows 3.x, Win9x/NT, Mac, Linux, Sun, Otros UNIX, e incluso navegadores.
La autentificacion se lleva a cabo mediante el sistema tipico de MicroSoft
de desafio/respuesta, al igual que LanManager, es decir:
-claves de 8-40 caracteres
-el server envia un hash de desafio
-el cliente envia un hash del desafio y la clave
-el servidor chequea este hash contra el de la base de datos SAM
Veamos mas detalle:
En principio, se usan claves (keys) de 1024 que se dividen en:
-dos claves RC5 de 128 bits para conectar
-dos claves RC5 de 40, 56 o 128 bits tras el logon.
Se usa el algoritmo RSA con bloques de 64 bits y 12 vueltas.
-Se generan 2 numeros A y B usados de parametros del metodo Diffie-Hellman.
-El servidor genera su clave privada K1
-El sevidor genera una llave publica P1=A*K1 mod B
-El servidor envia A, B y P1 al cliente.
-El cliente recibe estos valores
-El cliente genera la clave privada K2
-El cliente genera una clave secreta S=(P1**K2) mod B
-El cliente genera su clave publica P2=(A**K2) mod B
-El cliente envia P2 al servidor
-El servidor recibe P2
-El servidor averigua S=(P2**K1) mod B
El hecho de poder obtener S es debido a que
((A**K1 mod B)**K2) mod B = (A**(K1*K2)) mod B
((A**K2 mod B)**K1) mod B = (A**(K2*K1)) mod B
Aunque un intruso obtenga P2, P1, A y B (todos ellos viajan por a red),
no se puede obtener S (eso es lo que opinan los de RSA laboratories)
A partir de aqui, los datos entre el cliente y el servidor van cifrados
con ese hash S.
Una cosa buena que tiene es que si apagas el cliente, la conexion se guarda,
por lo que si desde el mismo cliente, el mismo usuario vuelve a conectar, se
queda donde estaba la ultima vez.
El protocolo ICA no esta descrito libremente en ninguna parte (que yo sepa)
TERMINAL SERVER
Microsoft le compro a Citrix la tecnologia MultiWin para convertir sus
servidores NT en multi usuario.
Como, porque, cuando y quien se explican en
www.gcisystems.com/thinclient/wts-faq.html
El protocolo usado es RDP (Remote Desktop Protocol) compatible con las
especificaciones T.120 para comunicaciones multipunto en tiempo real.
Mas concretamente, en el modo T.128; mas info en:
www.itu.org
gw.databeam.com/ccts/t120primer.html
Para consideraciones morales, consultar RFC949 y RFC505
*EOF*
