Servidor Streaming

Unidad de Trabajo 5

Servicios de acceso remoto
Greetings, Professor Falken.
Juegos de guerra (1983)

Resumen: En esta Unidad de Trabajo se describen diferentes métodos de acceso remoto a máquinas. En la unidad anterior vimos brevemente Telnet. Se revisan los problemas de seguridad de Telnet, y se
describe SSH, X Window y VNC.
Material: Laboratorio virtual montado en la unidad de trabajo1. Se asume que Debian Servidor tiene instalado y lanzado el demonio de telnet, y Ubuntu tiene Wireshark. En una práctica, el profesor
proporcionará

XKeyLogger.

Práctica 5.1: Inseguridad en Telnet y FTP
Tanto Telnet como FTP son el legado de un mundo que ya no existe,
en el que la que nalmente se bautizaría como Internet era aún una red entre amigos que estaban demasiado sorprendidosviendo que todo funcionaba
como para preocuparse por la seguridad. Debido a ello, son inseguros : no
se preocupan de encriptar la información ni de validar al servidor. Vamos a
comprobarlo.
En Ubuntu, lanza Wireshark como root (quizá tengas que hacerlo en
una consola) e inicia una captura de tráco.
Desde Debian Cliente, conectate usando telnet a Debian Servidor.
Analiza la capturarealizada en Ubuntu. Comprueba que puedes ver la
contraseña. Nota la diferencia de la captura entre el nombre del usuario
y la contraseña. ¾Por qué piensas que ocurre?
59

60

Unidad de Trabajo 5. Servicios de acceso remoto

Con esta práctica hemos visto que Telnet no encripta la comunicación.
Repitela abriendo una sesión de FTP para comprobar que tampoco lo hace.
Cuando nos conectamos portelnet, el servidor se asegura de que somos
nosotros pidiéndonos una contraseña. Pero el cliente no puede estar seguro
de que el servidor es quién dice ser (el destino de la IP):
En Debian Servidor, ejecuta la siguiente orden (sin saltos de linea):

# iptables -t nat -A PREROUTING -i eth1 -p tcp
--sport 1024:65535 --dport telnet
-j REDIRECT --to-port telnet
Esto signica cualquier datagramaque entre por

eth1,

lleve dentro

TCP con un puerto origen no privilegiado, y que vaya al puerto de
telnet, cambiale la IP destino, ponle la mía, y envíalo también al puerto
de telnet.
Desde Debian Cliente, conectate a un telnet externo. En casa puedes
utilizar el telnet del router ADSL. En clase, el del ordenador del profesor.
¾Dónde te estás conectando realmente?
Deshaz laredirección del experimento escribiendo en Debian Servidor:

# iptables -t nat -F PREROUTING

Práctica 5.2: Instalación del servidor de SSH
En Debian Servidor, instala el servidor de SSH:

# apt-get install ssh
El instalador nos informa de que se genera una pareja de claves RSA y
otra DSA. Posteriormente, el servidor de SSH se lanzará automáticamente.
Las parejas de clave pública/privada seguardan en

ssh_host_rsa_key*

guardan la clave RSA.

ssh_host_dsa_key*

guardan la clave RSA.

/etc/ssh.

61

Las claves son aleatorias; la parte pública y privada están relacionadas
entre sí. Compara los permisos de los cheros de la parte pública (extensión

.pub)

y parte privada (sin extensión). ¾Tiene sentido?

Práctica 5.3: Primera conexión: comprobando el ngerprintVamos a conectarnos desde Debian Cliente a Debian Servidor. El cliente
de SSH se instala por defecto en Debian, y no hay que instalar nada.
Antes, y sólo por motivos pedagógicos explicados más adelante vamos a
modicar un aspecto de la conguración del cliente :
En Debian Cliente, abre el chero

/etc/ssh/ssh_config.

En la parte nal, busca la directiva

HashKnownHosts

y ponla en

No.Desde Debian Cliente, conectate por primera vez a Debian Servidor:

$ ssh 10.x.n.1
The authenticity of host '10.x.n.1 (10.x.n.1)' can't be establi
shed.
RSA key fingerprint is ac:d7:e5:c0:f0:c7:c0:bd:d7:4d:ed:11:7c:c
b:cf:ae.
Are you sure you want to continue connecting (yes/no)?
El servidor nos envía su clave pública completa (RSA en este caso), que
el cliente no conoce. Nos pide...