Introducción a los servicios de terminal remoto TELNET y SSH

Xabiel García Pañeda David Melendi Palacio Manuel Vilas Paz Roberto García Fernández

Sistemas de terminal remoto
• Acceder desde un serie de máquinas cliente a los recursos de una máquina servidor remota de forma interactiva
– De la misma forma que lo haría un cliente conectado a un terminal local del equipo servidor

El protocolo TELNET
• El cliente establece con el servidor una conexión TCP/IP
– Normalmente en el puerto TCP:23

El cliente lee de la terminal TELNET El cliente envía al servidor El servidor recibe TELNET

Sistema Operativo

Sistema Operativo

TCP/IP
El servidor envía una pseudo terminal

TELNET define cómo deben mandarse las secuencias de datos y comandos Se define el Terminal Virtual de Red (Network Virtual Terminal) (NVT) Dispositivo del usuario Formato Sistema Cliente Internet Cliente Formato NVT Servidor Formato Sistema Servidor Sistema Servidor .Adaptarse a la heterogeneidad • El TELNET debe inter-operar con tantos sistemas como sea posible – Algunos sistemas necesitan el carácter CR (retorno de carro) para marcar el final de línea – Otros necesitan el LF (alimentación de línea) – Otros la combinación de ambos CR-LF • • Para adaptarse.

Terminal Virtual de Red • Una NVT es un dispositivo imaginario que posee una estructura básica común a una amplia gama de terminales reales • Cada host mapea las características de su propia terminal sobre las de su correspondiente NVT. y asume todos los demás hosts harán lo mismo Adapta a un formato entendible por el sitio remoto Usuario Terminal físico NVT RED .

a menos que sean modificadas por opciones establecidas de común acuerdo.Terminal Virtual de Red • La NVT cuenta con un monitor o "display" y un teclado: – El teclado produce datos de salida. son: – Los datos se representan en código ASCII de 7 bits. que se envían por la conexión TELNET – El monitor recibe los datos de entrada que llegan • Las características básicas de una NVT. transmitido en bytes de 8 bits – La NVT es un dispositivo semi-duplex que opera en modo de buffer en línea – La NVT proporciona una función de eco local .

. Se conecta a la máquina. Cuando un usuario local de la máquina se conecte. podría analizar el tráfico y hacerse con esta información • El cliente no verifica la identidad del servidor – ¿Cómo sabemos a donde nos estamos conectando? 1. o un usuario de la máquina de destino con permisos suficientes.Problemas de TELNET • La autenticación de usuarios (login y password) viaja en claro por la red – Un atacante situado en algún punto intermedio. el usuario malintencionado dispone del nombre y la contraseña en esa máquina y posiblemente en otras. lanza un analizador de protocolos y espera … 2.

Solución: SSH • SSH (Secure Shell) • Autentifica los dos extremos de la conexión – El servidor se autentica ante el cliente con un certificado – El cliente se autentica ante el servidor • Usuario y password • Certificados • Encripta los datos intercambiados – No se transmiten usuarios ni passwords en claro – La información transmitida viaja también encriptada .

SYN-ACK. los datos viajan encriptados .Mensajes del protocolo Establecimiento TCP [ACK. ACK] Versión a utilizar Modos de autenticación y encriptación soportados Cliente y servidor acuerdan una clave dinámica para codificar los datos de esa sesión Intercambio de clave de Diffie-Hellman Datos en claro Datos encriptados A partir de este momento.

luego envía a A (gb mod p) – 515 mod 23 = 19 A calcula (gb mod p)a mod p – 196 mod 23 = 2 B calcula (ga mod p)b mod p – 815 mod 23 = 2 • A y B llegan a un secreto compartido sin que este sea transmitido sobre la red en ningún momento – Un atacante puede conocer p. g. ga mod p y gb mod p y no podría obtener la clave • Las operaciones de aritmética modular con números primos grandes (1024bits) escogidos cuidadosamente son no reversibles . luego envía a B (ga mod p) – 56 mod 23 = 8 B elige un número secreto b=15. A elige un número secreto a=6.Establecimiento de un transporte seguro • Cliente y servidor llegarán a un acuerdo sobre una clave única para cada sesión sin transmitir esta clave en ningún momento sobre la red – Se basa en el intercambio de clave de Diffie-Hellman (DH) • • • • • A y B acuerdan usar el número primo p=23 y la base g=5.

solo para identificar a las partes • El proceso de autentificación se basa en la presencia de un transporte seguro establecido previamente .Autentificación • Cada servidor dispone de una clave que le permite autenticarse ante el cliente – El cliente puede comprobar esta clave contra una base de datos local relacionando IPs y claves – El cliente puede recurrir a una tercera entidad (autoridad certificadora) para comprobar la validez del certificado • Esta clave no se usa para proteger la sesión.

que.Criptografía de clave pública y privada Se basan en operaciones de aritmética modular que son de cálculo sencillo pero de muy difícil inversión Clave pública Conocida por todo el mundo Clave privada Conocida solo por su propietario Mensaje Mensaje Encriptado Mensaje Algoritmo Algoritmo Solo el poseedor de la clave privada puede desencriptar los mensajes El resto tendrían que implementar un ataque por fuerza bruta. con las capacidades de computo actuales y la selección correcta de las claves es inviable Permite la firma de mensajes garantizando su autenticidad .

Configuración de un servidor SSH OpenSSH Server Xabiel García Pañeda David Melendi Palacio Manuel Vilas Paz Roberto García Fernández .

se incluye el script de arranque del servicio y se crean los certificados del servidor Ficheros de configuración en: – /etc/ssh/sshd_config – /etc/ssh/ssh_host_dsa_key à Clave privada para firmar los mensajes • Si este fichero tiene permisos de lectura universales el OpenSSH no lo utilizará – /etc/ssh/ssh_host_dsa_key.log Arrancar y parar el servicio: – /etc/init.pub à Clave pública • • Fichero de log por defecto: – /var/log/auth.d/sshd [start/restart/stop] .Instalación del servidor OpenSSH • Disponible en los repositorios en red de muchas distribuciones Linux – apt-get update – apt-cache search openssh-server – apt-get install openssh-server • • Durante la instalación se crea los ficheros de configuración por defecto.

Para las anteriores.Funcionamiento OpenSSH /etc/init. lee el fichero de configuración por defecto /etc/ssh/sshd_config /usr/sbin/sshd sshd_config Opción 1 Opción 2 … Opción N Los contenidos del fichero marcan como se comporta sshd para las sesiones establecidas a partir de este momento. Ej: Si se niega la entrada a un usuario.d/ssh restart/start En el arranque o tras solicitud del usuario. se inicia el servicio Llama a /usr/sbin/sshd Salvo que se le indique lo contrario. siguen aplicándose los parámetros definidos cuando se iniciaron P. este no es expulsado .

Control de acceso En la máquina hay cuentas de usuario1. usuario3 y root. usuario2. Usuario1 solo tiene permiso para acceder en local usuario1 Usuario2 y Usuario3 pueden acceder en remoto autenticándose mediante un certificado de cliente (no usa password) Usuario3 dejó sus credenciales accesibles de forma pública usuario2 usuario3 ¿root? .

Opciones de configuración de OpenSSH • • • Puerto en el que escucha peticiones (el puerto reservado por la AINA es el TCP:22) Port 22 Hay dos versiones del protocolo (se recomienda por motivos de seguridad la 2).1 Control de acceso al servidor ssh – – – – DenyUsers usuario1 usuario2 usuario3 AllowUsers usuario1 usuario2 usuario3 PermitRootLogin [yes/no] (Por defecto es yes) PermitEmptyPasswords no • • Mostrar cuando entra el usuario la fecha de su último acceso ssh – PrintLastLog [yes/no] Mostrar un Banner previo a la autenticación – Banner /PATH/fichero.txt . Para seleccionar entre ellas Protocol 2.

detener el proceso antes de memoria. .…) autenticarse (introducir el usuario) Tenemos que controlar este fenómeno. puertos. limitando el número de conexiones abiertas sin autenticar.Control de sesiones Conexión 1 Conexión 2 … Conexión N Un usuario podría abrir Los recursos de la máquina sesiones de forma remota y remota son limitados (CPUs. el tiempo máximo que puede estar abierta una conexión sin autenticar y el número máximo de intentos antes de una autenticación correcta.

• • Tiempo máximo durante el cual el cliente puede intentar logarse – LoginGraceTime NUM (Por defecto 120 segundos) Enviar mensajes solicitando respuesta del cliente cada NUM segundos. Con este valor a “yes” se monitoriza la disponibilidad de la conexión – TCPKeepAlive [yes/no] . Evita la caducidad de las sesiones en equipos NAT/PAT y Firewalls – ClientAliveInterval NUM (Por defecto = 0) • Control de sesiones caídas para evitar consumos innecesarios en el servidor. El 100% si se llega a full.Opciones de configuración de OpenSSH • • Número máximo de intentos de autentificación – MaxAuthTries NUM (Por defecto son 6) Número máximo de conexiones abiertas sin autenticar – MaxStartups NUM (Por defecto son 10) – MaxStartups start:rate:full • Descarta el rate/100% si hay más de start.

profile • Podemos aprovechar para definir la codificación adecuada para poder escribir acentos y similares export LANGUAGE=es_ES export LANG="es_ES.Gestión de sesiones autentificadas correctamente • OpenSSH no finalizará nunca sesiones SSH autentificadas correctamente – Los recursos son finitos – Los usuarios se despistan • Para controlar estas sesiones – Utilizar la variable TMOUT de Bash (evita despistes pero no usuarios malintencionados) • Para todos los usuarios: – /etc/profile • Para usuarios individuales: – ~/.ISO-8859-1” – Implementar un script que elimine sesiones inactivas durante un período .ISO-8859-1" export LC_ALL="es_ES.

org.html .greenend.Conexión desde un cliente Windows • • Existen clientes ssh de libre distribución como por ejemplo Putty http://www.chiark.uk/~sgtatham/putty/download.

Ejercicio 1 • Desplegar un servicio SSH que: – Solo admita la versión 2 (más segura) del protocolo – Permita el acceso al usuario1 pero no al usuario2 • Autentificandose con su usuario y contraseña local del equipo – No permita directamente el acceso al usuario root – Limite a dos el número de intentos de autentificación antes de uno correcto – Limite a 60 segundos el tiempo que un usuario puede consumir una línea sin autenticarse – Limite a 15 minutos la duración de las sesiones evitando los despistes de los usuarios – Mostrar un banner de entrada con un aviso sobre la funcionalidad del servicio y el almacenamiento en un fichero de log de las actividades del usuario .

ssh/authorized_keys – AuthorizedKeysFile /PATH/nombre – Se pueden utilizar %h para identificar el HOME de un usuario y %u para identificar el nombre de usuario que está accediendo • Permitir solo el login basado en certificados a aquellos usuarios que definan los permisos correctos y no tengan sus claves públicamente accesibles – StrictModes yes .Autentificación basada en certificados • • • Permitir autentificación basada en certificados – PubkeyAuthentication yes Impedir autentificación por usuario y password – PasswordAuthentication no Definir donde se almacenan los certificados de cada usuario. El valor por defecto es dentro de la carpeta HOME de cada usuario el fichero .

Proceso de importación Generar claves Servidor ssh Acceso ssh Grabar PuttyGen Importar desde PuttyGen Exportar a ppk Importar desde Putty Volcar en el equipo cliente Putty .

Your public key has been saved in /home/usuario/. Enter file in which to save the key (/home/usuario/. Copiar id_dsa. Comprobar los permisos del fichero!!!!! 5.Creación de certificados para un usuario 1.ssh/authorized_keys 4. Teclear: ssh-keygen -t dsa Generating public/private dsa key pair.ssh/id_dsa. Copiar el fichero de clave privada a un soporte seguro y llevarlo al cliente . Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/usuario/.ssh/id_dsa): Created directory '/home/usuario/.pub a authorized_keys cp .ssh/id_dsa./. The key fingerprint is:f1:9c:03:5a:b5:ad:03:41:0c:fa:e2:a3:58:be:37:02 usuario@servidor 3.pub.ssh/id_dsa.ssh'.pub ./. Entrar en la máquina como un cierto usuario 2.

ppk .Importar los certificados a un cliente Windows • Dada la falta de estandarización en el formato concreto de los certificados. tenemos que convertirlos de formato OpenSSH a formato Putty – La herramienta PuttyGen nos permite hacer eso • Importar la clave – Conversions -> Import Key – Seleccionar id_dsa • Proporcionar la password asignada durante la creación – File -> Save -> Guardar como privada.

ppk creado anteriormente – Connection -> Auto-login username à Nombre usuario para el que se creó el certificado • Si tecleamos un usuario diferente. rechaza el certificado y solicita password • Proporcionar los datos sobre IP y puerto • Pulsar Open • Conseguimos el acceso sin necesidad de teclear la password!!!!!!! . en la columna izquierda seleccionar – Connection -> SSH -> Auth – Seleccionar el certificado .Definición de sesión ssh basada en certificados • Dentro de la interfaz de Putty.

Ejercicio 2 • Sobre el servicio SSH desplegado anteriormente: – Habilitar la autentificación mediante certificados – Habilitar el acceso mediante certificados para el usuario1 – Comprobar el funcionamiento desde un cliente Windows con la aplicación Putty .

como el sftp (Secure FTP) • Para activar este soporte en OpenSSH – Subsystem sftp /usr/lib/openssh/sftp-server . incluye soporte a subsistemas externos.Transferencia de ficheros mediante SSH • SSH no permite solo el acceso interactivo a la interfaz de comandos – Permite la redirección de cualquier tipo de tráfico a través del transporte seguro que se establece • Tunelizado de tráfico • Además.

existen clientes gráficos para el protocolo SFTP – WinSCP – FileZilla .Conexión desde un cliente • En equipo Linux se dispone de aplicaciones por línea de comandos – sftp • La sintaxis es prácticamente idéntica a los clientes FTP – scp –P port user@]host1:file1 user@host2:file2 • Al igual que para el protocolo FTP.

Puttygen Soporte a autentificación por certificados Contenidos Equipo local Ventana inicial de parámetros de sesión Contenidos Equipo remoto .WinSCP • • • • • • Confirmación de operaciones sobre ficheros Almacenamiento de parámetros de sesión Ejecución de comandos no relacionados con la transferencia de ficheros Servicio automático de actualizaciones Integración con Putty.

rar del Servidor SFTP que se indique • Subir los contenidos al servidor de cada grupo de usuarios .Ejercicio 3 • Descargar mediante FTP el fichero ejemplos.

Ejemplo de script de control de duración de la sesión #!/bin/bash #Vemos quien tiene sesiones abiertas en la máquina y lo volcamos a un fichero who -u > /tmp/iddle #Obtenemos los PIDs PID=$(more /tmp/iddle | awk '{print $6}') #Recorremos los usuarios logados buscando en la columna inactividad algo con la forma ??:[1-9]? for i in $PID. do iddle=$(more /tmp/iddle | grep $i | awk '{print $5}' | grep ":[1-9]") #Si esas líneas no están vacías. then kill $i fi done. Si lo introducimos en el cron para que se ejecute cada minuto.sh . controlamos la inactividad de las sesiones abiertas: crontab -e */5 * * * * /root/monitoriza_sesiones. matamos el proceso que controla la sesión if [ -n "$iddle" ].

Gestión de cantidad de sesiones por IP • Nuevamente. descartamos iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP Si queremos eliminar las líneas aplicadas anteriormente: iptables -F . marcado de tráfico. NAT/PAT. redirección. routing. esta es una funcionalidad no contemplada en OpenSSH • Recurriremos a filtros de tráfico basados en iptables – Firewall.… • Para limitar la cantidad de logins que una IP puede hacer en un período determinado de tiempo #Añadimos las IPs de las conexiones nuevas (solo las nuevas “NEW) a un lista “recent” iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set #Si hay más de 4 ocurrencias de una cierta IP en la lista “recent” en los últimos 60 segundos.

Gestión de tráfico máximo de descarga • Para limitar el tráfico de salida que puede consumir el SSH podemos recurrir al conformado de tráfico #!/bin/bash #Definimos un control de tráfico basado en Token Bucket tc qdisc add dev eth0 root handle 1: htb default 30 #Definimos un consumo máximo de 10Mbps con una ráfaga de 15Kbytes tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit burst 15k #Definimos límites de tráfico para las diferentes clases tc class add dev eth0 parent 1:1 classid 1:10 htb rate 2mbit burst 15k tc class add dev eth0 parent 1:1 classid 1:20 htb rate 7mbit ceil 10mbit burst 15k tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1mbit ceil 10mbit burst 15k #Definimos la gestión de cola en cada clase tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 #Clasificamos los distintos tipos de tráfico tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 22 0xffff flowid 1:10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 80 0xffff flowid 1:20 Si queremos eliminar las líneas aplicadas anteriormente: tc qdisc del dev eth0 root .