PROYECTO FIN DE CARRERA

Transcripción

1 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO SUPERIOR INFORMÁTICO PROYECTO FIN DE CARRERA Herramienta de Utilidades de Seguridad SSH para dispositivos móviles: GUEFIRA PROJECT AUTOR: Antonio Pascual Moreno MADRID, Junio de 2008

2 A mis Padres cuyas experiencias y consejos han sido el mejor regalo que me han podido legar. A María Eugenia que sin su apoyo y comprensión en los momentos difíciles hubiera sido imposible sacar adelante este proyecto. Antonio Pascual Moreno, Madrid 2008 ii

3 RESUMEN El auge de la telefonía móvil, y los avances en el desarrollo de aplicaciones software de comunicaciones, ha desembocado en la actual tendencia de integrar en un mismo dispositivo móvil comunicación de voz y de datos; acceso a Internet y telefonía. Cada vez más personas dentro de la sociedad de las tecnologías de la información están de acuerdo en que será el teléfono o terminal móvil, el centro de todo, con continuas evoluciones. El computador irá dentro de él para permitir que los datos regados por la red estén disponibles desde cualquier lugar y en cualquier momento. No en vano, dentro de poco tiempo habrá más de 3000 millones de terminales en todo el mundo. Al igual que otras muchas tecnologías, los dispositivos móviles han evolucionado a pasos agigantados en los últimos años. Los principales analistas coinciden en que el mercado de estos aparatos está desembocando en la creación de lo que actualmente conocemos con el nombre anglosajón de Smart Phone. Pero, qué es un Smart Phone? No hay acuerdo en la industria sobre lo que es un Smart Phone y las definiciones cambian a lo largo del tiempo, pero quizá una buena aproximación sería la de un dispositivo con todas las funcionalidades de un teléfono móvil convencional a lo que se añadiría un centro móvil de datos. Una computadora en miniatura. La principal diferencia con respecto a los teléfonos móviles convencionales reside en cómo están construidos y qué es lo que pueden hacer, aprovechando las ventajas que los sistemas operativos ofrecen y las constantes mejoras que se llevan a cabo año tras año. Y cierto es que las Agendas Personales Digitales (PDA) han sido sustituidas por las ventajas que los Smart Phone ofrecen. Pero también hay que admitir que estos dispositivos móviles no cuentan con la misma cantidad de recursos que una estación de trabajo de sobremesa. Están sujetos a la autonomía de baterías y la potencia de cálculo es reducida. De ahí surge la necesidad de desarrollar aplicaciones con poco peso y que realicen un uso óptimo de los recursos limitados de los dispositivos. Otro aspecto importante a destacar es la heterogeneidad del software embebido en los dispositivos. La aplicación que en un dispositivo puede correr de forma excelente, es iii

4 posible que en otra se ejecute con ciertas carencias. Y aún hoy debido a la competencia en el sector, los fabricantes no tienden a la unificación. La potencia de los dispositivos móviles reside precisamente en la posibilidad de acceder a datos e información desde cualquier lugar y en cualquier momento, pero esta permisividad en el acceso no está exenta de riesgos. Al igual que en los computadores de sobremesa, están expuestos a vulnerabilidades y a técnicas de ataques a través de la red. De ahí surge la necesidad de establecer políticas de seguridad en el acceso a Internet y de desarrollar aplicaciones que faciliten la seguridad en el trasiego de la información. Este documento corresponde a la memoria de el Proyecto Fin de Carrera Herramienta de Utilidades de Seguridad SSH para dispositivos móviles: GUEFIRA PROJECT. Este Proyecto de Fin de Carrera tiene por objetivo mediante el uso de una arquitectura cliente-servidor y bajo las reglas del protocolo Secure Shell (SSH), la creación de una herramienta software dirigida a dispositivos móviles, que permita brindar al usuario la posibilidad de establecer canales seguros para la conexión hacia la red. Gracias a la encriptación de los canales lógicos se proveerá confidencialidad e integridad de los datos al ser transportados por redes inseguras tales como Internet. Y debido a las ventajas que ofrecen los dispositivos móviles actuales, esta aplicación permitirá el establecimiento de conexiones seguras entre máquinas remotas en cualquier lugar y en cualquier momento. Basándonos en el principio de que el modelo de comunicaciones SSH está soportado por la arquitectura cliente-servidor, ha sido necesario estudiar la importancia que juegan los sistemas distribuidos y establecer las características entre un sistema cliente y un sistema servidor. En una primera aproximación al modelo de comunicaciones SSH, se ha realizado un estudio de la arquitectura del protocolo, los modos de uso, los recursos necesarios y los mecanismos de seguridad que proporciona. iv

5 Dado que la implementación de la herramienta que propone este proyecto está enfocada hacia dispositivos móviles, se ha hecho necesaria la investigación y elección de herramientas de desarrollo adecuadas para los mismos. En el presente documento se describen de forma detallada las tecnologías utilizadas para la consecución de la aplicación y el por qué de la elección de estas. En el proceso de desarrollo de la aplicación, se ha tenido muy en cuenta las limitaciones de los dispositivos y se ha puesto un especial empeño en maximizar los recursos que éstos brindan. v

6 ABSTRACT The apogee of the mobile devices, and the advances in the development of communications software applications, has ended in the actual trend of integrate in a single device voice communication and data; Internet access and telephony. More often, people inside the Information Technology Society agree about the role of the mobile phone or cellular in the market. They believe that it will be the centre of everything with continuous evolutions. Computer systems will be incorporated into the mobile device, allowing access of data spread all over the network, at any time in any place. Thus shortly in time, there will be more than 3000 millions terminals spread around the whole world. Like other technologies, mobile devices have evolved very quickly in the last years. The main analysts agree that the market for these devices is leading in the development of new phones known as Smart Phones. But What s exactly a Smart Phone? The industry don t have a common definition about what is a Smart Phone and this definitions change over time, but perhaps a good approach would be that a Smart Phone is a device with every functionality of a conventional cellular and also a mobile data centre. It s a small computer. The main difference regarding the usual mobile devices, is in how they are built and what they can do, taking the advantages of the Operative System, and the continuous improvements that are made year after year. And it s true that the Personal Digital Agendas (PDA s) has been replaced by the improvements and advantages brought by the Smart Phones. But it is also necessary to admit that these mobile devices do not include the same quantity of resources that a normal working station. They are subject to the autonomy of batteries and the power of calculation is limited. Because of that arises the need to develop light applications that make an ideal use of the limited resources of the devices Another important aspect to stand out is the heterogeneity of the software included in the devices. The application that in a device can run of excellent form, it s possible that in other one it is executed with certain lacks. And still today due to the competition in the sector, the manufacturers do not tend to the unification of software. vi

7 The power of the mobile devices resides precisely in the possibility of acceding to data and information from any place and in any moment, but this permissiveness in the access is not exempt of risks. As in the personal computers, they are exposed to vulnerabilities and attack techniques across the net. Because of that arises the need to establish security policies in the access to Internet and to establish applications that provide safety in the information exchange. This document belongs to the paper of the project Tool of SSH Security Utilities for mobile devices: GUEFIRA PROJECT This Project has as an aim through the use of Client-Server architecture and under the rules of the protocol Secure Shell (SSH), the creation of a software tool focused on mobile devices, that allows the user the possibility of establishing secure channels for the connection towards the net. Thanks to the encryption of the logical channels confidentiality and integrity of the information will be provided while being transported by insecure nets as the Internet. And because of the advantages that the actual mobile devices offer, this application will permit the establishment of secure connections between remote machines in any place and at any moment. Based on the principle that the SSH communications model is supported by a Client- Server architecture, it has been necessary to study the importance of distributed systems and the characteristics established between a client system and a server system. In a first approximation to the SSH communications model, a study of the architecture of the protocol have been done, the methods of use, the necessary resources and the securities mechanisms that it provides. vii

8 Provided that the implementation of the tool that proposes this project is focused towards mobile devices, it is necessary the investigation and election of development tools adapted for these devices. In the present document there are a detailed description of the technologies used for the attainment of the application and why of the election of these. In the development process of the application, we have take into account the limitations of the devices and we also have put a special pledge to maximize the resources that these devices offer. viii

9 ÍNDICE CAPÍTULO 1 - INTRODUCCIÓN OBJETIVOS DEL PROYECTO METODOLOGÍA DE TRABAJO ESTADO DEL ARTE Aplicaciones existentes Conclusiones CAPÍTULO 2 PROTOCOLO Secure Shell CONCEPTOS PRELIMINARES QUÉ ES SSH? LO QUE NO ES SSH HISTORIA ARQUITECTURA Capa de transporte RFC Capa de autenticación de usuario RFC Capa de conexión RFC MÉTODOS DE AUTENTICACIÓN Sesión SSH mediante autentificación por contraseña Sesión SSH mediante autenticación por intercambio de Clave publica Agente de autenticación SSH CARACTERÍSTICAS DEL PROTOCOLO Redirección de puertos (Port forwarding) Funcionamiento del Port forwarding Tipos de Port forwarding SSH X forwarding Transferencia de ficheros mediante SCP CONSIDERACIONES DE SEGURIDAD Known hosts Ataque Man in the middle TECNOLOGÍAS RELACIONADAS RSH (RCommands) ix

10 2.9.2 Kerberos Ipsec Secure Socket Layer (SSL) CAPÍTULO 3 DESARROLLO DE GUEFIRA PROJECT PRÓLOGO ENTORNO DE DESARROLLO Introducción al entorno JAVA J2ME Java Micro Edition Librerías JSch del equipo JCRAFT Librería Bouncy Castle Crypto El concepto de ofuscación y Proguard WebSphere Everyplace Micro Environment Librerías gráficas SWT de Eclipse Entornos de desarrollo alternativos ANÁLISIS DEL PROBLEMA Diagrama Conceptual de Clases Glosario de Conceptos Modelo de Casos de Uso Descripción Casos de Uso Otros requerimientos Diagrama de paquetes IMPLEMENTACIÓN Clases recogidas en el paquete sshapp Clases pertenecientes al paquete com.jcraft.jsch CONSIDERACIONES DE SEGURIDAD EN GUEFIRA Sniffer de Red Ejemplos de estudio Acceso remoto Telnet Acceso remoto (SSHExec) GUEFIRA CAPÍTULO 4 PLANIFICACIÓN Y VALORACIÓN ECONÓMICA RESULTADOS OBTENIDOS Establecimiento de perfiles de trabajo Estructura de división de trabajo Planificación x

11 4.2.4 Costes CAPÍTULO 5 CONCLUSIONES DEL PROYECTO CONCLUSIONES TRABAJOS FUTUROS BIBLIOGRAFÍA Y REFERENCIAS REFERENCIAS BIBLIOGRÁFICAS REFERENCIAS ON LINE ANEXOS xi

12 1 Capítulo 1 INTRODUCCIÓN

13 CAPÍTULO 1 - INTRODUCCIÓN 1.1 OBJETIVOS DEL PROYECTO El proyecto fin de carrera Herramienta de Utilidades de Seguridad SSH para dispositivos móviles: GUEFIRA PROJECT pretende conseguir los siguientes objetivos: 1. Creación de la aplicación GUEFIRA PROJECT, herramienta software para dispositivos móviles, que consta de cuatro utilidades. Ejecución remota de un terminal (Shell), para permitir acceso seguro a máquinas regidas por sistemas operativos Linux. Ejecución de comandos SSH desde la aplicación GUEFIRA cliente, hacia una máquina servidor bajo plataforma Linux. Soporte de redireccionamiento de puertos (Port forwarding) para permitir la creación de túneles seguros de acceso a la red. Envío y recepción de ficheros de forma segura entre la máquina cliente y la máquina servidora mediante canales de encriptación que provee la arquitectura SSH. Interfaz gráfica de usuario intuitiva y vistosa 2. Estudio en detalle del modelo cliente-servidor. Como ya se dijo con anterioridad, el protocolo SSH se sustenta en el modelo cliente servidor. Es necesario por tanto un estudio detallado de los sistemas distribuidos, las funciones del cliente y del servidor y los tipos diferentes existentes en el mercado. El modo de funcionamiento de los sistemas servidores y los parámetros de configuración. Se hace un evidente hincapié en servidores SSH y servidores Web necesarios para la ejecución de la aplicación cliente GUEFIRA. Se abarcará la definición y la utilidad del concepto servidor Proxy (representante), que juega un papel determinante en la creación de túneles seguros que permitan acceso a la red. 2

14 3. Estudio de la arquitectura y el protocolo SSH. Para la consecución del primer objetivo, se hace necesario un estudio detallado del funcionamiento del protocolo SSH, arquitectura, usos, criptografía de clave pública, comparación entre clientes SSH, alternativas a este protocolo y como necesidad práctica su implementación mediante las reglas que ofrece la herramienta OpenSSH bajo licencia de software libre. 4. Estudio de las tecnologías existentes para la implementación de la aplicación cliente GUEFIRA en dispositivos móviles. Existen numerosos lenguajes de programación aptos para la implementación de aplicaciones en dispositivos móviles. Sin embargo, la elección de estos en el caso de este Proyecto de Fin de Carrera vino condicionada por las librerías a usar. La aplicación requiere de las librerías Jsch del equipo JCraft para J2ME, la distribución de java para aplicaciones embebidas. Estas librerías establecen la implementación del protocolo SSH en java puro. 3

15 1.2 METODOLOGÍA DE TRABAJO La metodología que se ha empleado para el desarrollo del Proyecto de Fin de Carrera Herramienta de Utilidades de Seguridad SSH para dispositivos móviles: GUEFIRA PROJECT se puede describir en las siguientes fases: Estudio del entorno de desarrollo. En primer lugar, ser realiza una toma de contacto con el desarrollo de aplicaciones enfocadas hacia dispositivos móviles. Ciclo de vida de aplicaciones en Java J2ME y especificaciones del API. Estudio detallado del protocolo y la arquitectura SSH, establecimiento de sesión SSH, apertura de canales, método de intercambio de claves públicas y encriptación. Configuración del servidor SSH, creación de cuentas y perfiles etc. Fase de Análisis (ver Capítulo 3) La identificación de necesidades, la adquisición de conocimiento, son de las fases más importantes en el desarrollo de software [5]. Saber qué es lo que quiere el usuario o cliente, y adquirir el conocimiento necesario del dominio en el que se contempla el problema. En esta fase se abordan e identifican las entidades que pasarán a formar parte de la aplicación final, desde una perspectiva conceptual. Fase de Diseño (ver Capítulo 3) Diseño interno de la lógica de cada una de las utilidades que engloba la aplicación GUEFIRA. Una a una se afronta las distintas dificultades que conlleva cada herramienta y se buscan formas de solucionarlas. En esta fase se lleva a cabo la migración entre los conceptos propuestos en la fase anterior y las clases Java que se crearán para la aplicación final. 4

16 Fase de desarrollo e implementación (ver Capítulo 3) Quizá sea esta la fase en la que más tiempo se emplea. Es la codificación en el lenguaje de programación de la planificación desarrollada en la fase inmediatamente anterior. La ofuscación de código y ejecución se llevan a cabo en esta fase. Pruebas Consiste en la realización de las pruebas necesarias de cada utilidad para observar el comportamiento de las mismas. Muchas veces se recurre al método de prueba, error y modificación de código. La fase de desarrollo e implementación y la de pruebas se llevan a cabo de forma iterativa por cada una de las utilidades que conforman la aplicación GUEFIRA y tantas veces como sean necesarias hasta dar con un resultado óptimo en cada una de ellas. Documentación La documentación es la única fase de la metodología empleada que está presente en todo el desarrollo. En esta fase se recoge toda la información realizada tanto en el estudio del entorno como la información obtenida en el desarrollo e implementación de la aplicación. Es en esta fase donde se generan los documentos JavaDoc como resultado creación de la herramienta. Esta metodología ha tenido como referencia la explicada en el libro Metodología estructurada de aplicaciones de Jesús Barranco de Areba [5], con las modificaciones pertinentes para adaptarse al problema que se quería abordar. 5

17 1.3 ESTADO DEL ARTE Aplicaciones existentes La gran aceptación por los usuarios de la red que el protocolo SSH ha tenido desde su lanzamiento ha permitido el lanzamiento al mercado de un gran número de aplicaciones cliente SSH. La aparición de dispositivos móviles, Pda s, smartphones etc. ha implicado como consecuencia directa la aparición de clientes SSH dirigidos hacia estos dispositivos aunque en menor medida que los disponibles para sistemas fijos o estaciones de trabajo. La aplicación GUEFIRA PROJECT es un cliente SSH dirigido precisamente hacia esta clase de dispositivos, por lo que es una buena medida aclarar similitudes y diferencias entre las aplicaciones actuales y el proyecto que se pretende desarrollar. 1. Cliente SSH PSSH para Palm OS5 Este cliente está dirigido hacia dispositivos Palm con sistema operativo Palm 5 o superior. Sus características son las siguientes: Hace uso del protocolo SSH-2 usando como algoritmos de cifrado 3DES y AES- 128 bits. Autenticación y encriptación usando código ARM nativo. Soporte para autenticación con clave pública y autenticación por nombre de host. Código fuente completamente distribuido bajo licencia libre BSD. 6

18 Pantalla de conexión PSSH Shell remota en PSSH Esta aplicación permite la conexión a un servidor SSH abriendo una Shell remota par la posible introducción de comandos ssh. El interfaz es intuitivo y fácil de manejar. Sin embargo esta aplicación es muy escasa en cuanto a las funcionalidades que permite. No permite el envío de archivos entre máquina local y máquina remota bajo el protocolo seguro. No permite la ejecución individual de comandos ssh sin el engorro que supone abrir una sesión cada vez que se quiera ejecutar uno de estos comandos. Únicamente esta dirigida hacia dispositivos que lleven incorporado el sistema operativo Palm. Hasta la fecha de este documento existen numerosos errores sin resolver, el más importante es la imposibilidad de conexión cuando el servidor avisa de que su clave pública ha cambiado emitiendo un mensaje de precaución (warning message) que el cliente no recoge. 2. Cliente SSH TopGun SSH para Palm OS Este cliente SSH está dirigido para dispositivos con sistema operativo Palm desde su versión 4 en adelante. Hace uso de una serie de librerías criptográficas llamadas SSLeay. 7

19 Pantalla de conexión TopGun SSH Utiliza el protocolo SSH-1 mediante el uso de las librerías SSLeay para el cifrado de los canales. En esta ocasión tiene una amplia gama de algoritmos de cifrado como Diffie-Hellman, MD2, MD5, BlowFish, RSA etc. Soporte para autenticación mediante nombre de host. El interfaz de esta aplicación es más escaso que la anteriormente descrita PSSH. Aunque las funcionalidades son prácticamente las mismas. La gran pega es el uso del protocolo en su primera versión SSH-1, que como se verá en capítulos posteriores presenta serias deficiencias de seguridad. 3. Aplicación Mobile SSH Mobile SSH, es una de las aplicaciones SSH para dispositivos móviles que permite ejecutarse en una amplia gama de dispositivos. Esto es debido a que hace uso de aplicaciones que permiten la emulación de terminales, tales como IBM 5250, o VT100. Mobile SSH posee las siguientes características: Pantalla del terminal remoto en Mobile SSH 8

20 Al hacer uso de aplicaciones de emulación de terminales, está dirigida a una amplia gama de dispositivos. Esto le da opción a revisar informes que le provee el servidor para la solución de problemas en la ejecución. Permita la conexión a servidores SSH usando tanto el protocolo SSH-1 o SSH-2. Autenticación por nombre de host. Se distribuye bajo licencia de ámbito privado. 4. Aplicación zatelnet Professional zatelnet Professional es una de la aplicaciones cliente SSH más completa. A parte de soportar las dos versiones del protocolo SSH, también permite ejecutar directivas Telnet, mediante canales no cifrados. Esta aplicación hace un uso parcial de la emulación de terminales que es ofrecida por VT100. Sus características se exponen a continuación: Ejecución de terminales remotas bajo los protocolos SSH-1 y SSH-2. Ejecución de comandos Telnet. Autenticación mediante nombres de host. Aplicación dirigida a dispositivos regidos bajo plataformas Microsoft Windows Mobile CF1.0 y CF2.0 Interfaz configurable e intuitivo. Permite transferencias de ficheros mediante el protocolo SSH (SCP). Entre sus limitaciones cabe destacar las siguientes: Únicamente se puede ejecutar en plataformas Microsoft Windows Mobile. Requiere el Framework.NET de Microsoft para poder ejecutarse en cada dispositivo. Es muy dependiente del software en el que se ejecuta. 9

21 Se distribuye bajo licencia privada. Al distribuirse bajo licencia privada, sólo permite un número máximo de conexiones contra el servidor a menos que estemos registrados Conclusiones Todas las aplicaciones descritas anteriormente carecen de algo, y GUEFIRA PROJECT seguramente también, sin embargo existen dos elementos importantes que hacen única a la aplicación que este documento trata de presentar. La inclusión del redireccionamiento de puertos Port forwarding en dispositivos móviles. Ejecución en cualquier dispositivo que permita la ejecución de código JAVA, que en la actualidad son la mayoría. En capítulos posteriores se dará a conocer de forma exhaustiva la potencia y el uso que tiene GUEFIRA PROJECT. Así que juzguen ustedes mismos. 10

22 2 Capítulo 2 PROTOCOLO SECURE SHELL

23 CAPÍTULO 2 PROTOCOLO Secure Shell 2.1 CONCEPTOS PRELIMINARES Vamos a tratar de cubrir una serie de conceptos de redes de computadoras [14] que irán a pareciendo a lo largo de todo el capítulo, que serán necesarios su entendimiento para comprender el funcionamiento y uso del protocolo SSH y que quizá sea necesario aclarar desde un primer momento. TERMINOLOGÍA DE REDES DE COMPUTADORAS Computadora local: También denominada máquina local o host local. Se refiera a una máquina en la que accedes típicamente ejecutando un cliente SSH. Computadora remota: O máquina remota, host remoto. Una segunda computadora que es contactada desde el ordenador local. Típicamente, la máquina remota esta ejecutando un servidor SSH, y es accedida mediante un cliente SSH. Como caso extremo, la máquina local y remota puede ser la misma. Usuario local: Usuario que accede a la computadora local. Usuario remoto: Usuario que accede al ordenador remoto. Servidor: Un programa SSH servidor. Máquina servidora: Una máquina ejecutando un programa servidor SSH. A lo largo del capítulo se explicitará algunas veces simplemente como servidor, cuando se hace irrelevante establecer una distinción entre el programa servidor SSH y la máquina servidora. Cliente: Un programa cliente SSH. Máquina cliente: Una máquina ejecutando un programa cliente SSH. En algunas ocasiones se explicitará únicamente cliente queriendo englobar tanto a la máquina cliente como al programa cliente SSH. 12

24 2.2 QUÉ ES SSH? El protocolo Secure Shell (SSH) es un protocolo que establece la conexión, la autenticación remota y otros servicios de red de forma segura sobre una red insegura como puede ser Internet. Cada vez que se envían datos desde una máquina hacia la red, SSH los encripta. Cuando estos datos llegan al destinatario, servidor SSH, éste los decripta de forma automática. Esto se produce de forma transparente de cara al usuario. Este protocolo como ya se ha dicho, se sustenta en una arquitectura cliente/servidor. Un servidor SSH típicamente instalado y ejecutándose con permisos de administrador, acepta o rechaza conexiones entrantes. Los usuarios ejecutan aplicaciones SSH clientes desde otras máquinas, realizando peticiones al servidor tales como Por favor, autentícame, Por favor, envíame un fichero o Por favor, ejecuta este comando. (Ver Figura 1. Modelo cliente servidor en SSH) Esta es una visión simplificada del protocolo, pero puede servir de una primera aproximación para entender el funcionamiento del mismo. El protocolo SSH, cubre los siguientes aspectos: 1. Autenticación: determina la identidad de alguien. Si estás intentando acceder en la cuenta de una computadora remota, SSH pregunta por la prueba de tu identidad digital. Si pasas la prueba, puedes acceder, en caso contrario tu petición es rechazada. Suele realizarse mediante contraseña o frase de paso. Se verá en posteriores epígrafes de este documento. 1. Encriptación: desordena y cifra los datos para que sean ininteligibles por terceras personas ajenas a la comunicación. De esta forma los datos son enviados a través de la red. 2. Integridad: garantiza que el trasiego de datos sobre la red llega a su destino inalterado. Tal como se envía igual se recibe. Si terceras personas capturan y modifican los datos, el protocolo lo detecta. Sus principales objetivos son: 13

25 Permitir el intercambio de datos usando un canal seguro entre dos máquinas remotas. Aportando confidencialidad, integridad y autenticación a la información que viaja sobre redes inseguras. Reemplazar a otros protocolos de conexión remota no seguros bajo el modelo cliente servidor tales como Telnet, Rlogin o RSSH. Permitir redireccionamiento de puertos (Port forwarding) en conexiones TCP/IP sobre canales cifrados. Permitir el envío y recepción de ficheros haciendo uso de la herramienta Scp sobre canales cifrados. Permitir sesiones gráficas remotas bajo el servicio X11. La especificación del protocolo SSH-2, está recogida en el documento RFC 4251 del grupo de trabajo del IETF de enero del año La especificación del protocolo OpenSSH, es la más utilizada en la actualidad desde su aparición en el año 1999, soporta tanto la primera versión SSH-1 como la última SSH-2 y está recogida por el grupo de trabajo OpenSSH Project. 14

26 Figura 1. Modelo cliente servidor en SSH (O Reilly SSH the definitive Guide 2001) 2.3 LO QUE NO ES SSH Aunque el nombre SSH proviene de Secure Shell, SSH no provee exactamente un terminal Unix tal como si estuviéramos trabajando en la maquina remota propiamente dicha. SSH crea un túnel cifrado que permite la ejecución remota de esa terminal en la máquina servidora destino. SSH no es una solución completa a la inseguridad de la red, pero hoy en día ningún protocolo o aplicación ofrece una seguridad 100% al trasiego de información. No protegerá a las máquinas de conocidos ataques como denegaciones de servicio, virus o caballos de Troya. Sin embargo provee de un cifrado amigable y robusto, permitiendo autenticación, integridad y confidencialidad de los datos enviados. 15

27 2.4 HISTORIA En 1995, el investigador de la Universidad Tecnológica de Helsinki en Finlandia, Tatu Yönen, diseñó la primera versión del protocolo actualmente denominado SSH-1, a partir de un ataque a la red local de esta universidad que permitió el robo de contraseñas. El objetivo de este embrión del protocolo SSH fue el de remplazar las ya desfasadas aplicaciones de conexión remota entre máquinas tales como rlogin, Telnet u otros protocolos Rsh (Remote SHell, consolas o terminales remotos) que no contaban con unas fuertes medidas de autenticación o garantía de confidencialidad de la información que se transportaba. En julio del año 1995 Yönen distribuyó la implementación de SSH-1 y la herramienta pronto se hizo popular. Hacia el final de 1995, el uso de SSH creció hasta alcanzar los usuarios en cincuenta países. En Diciembre de 1995, Yönen fundó la compañía SSH Communications Security para comercializar y desarrollar el protocolo. La versión original del software SSH usaba varias partes bajo la licencia libre GNU, tales como la librería de funciones matemáticas libgmp, pero las versiones que la compañía de Yönen lanzó con posterioridad fueron enteramente software propietario. SSH-1 está compuesto por dos versiones; el protocolo 1.3 y el 1.5. Ambas usan el algoritmo de criptografía asimétrica RSA para la negociación de claves y para la encriptación de datos usan Blowfish y 3DES. El protocolo SSH-1 usa un simple Control de Redundancia Cíclica (CRC) para la integridad de los datos que contiene un error de diseño. Existe la posibilidad de un ataque de inserción de información basura en el envío. En 1996, una revisión del protocolo desembocó en la creación de SSH-2, diseñado de manera que la versión anterior fuera incompatible con la recién creada. La mejora del protocolo SSH-2 sobre SSH-1 viene en la implementación de la seguridad y otras características como la posibilidad de ejecutar cualquier número de sesiones remotas (Shell Sessions) sobre una misma conexión SSH. En cuanto a la mejora en la seguridad es debido a la integración en esta versión del intercambio de claves públicas Diffie-Hellman (DH) y la solución definitiva al problema de integridad de datos del Control de Redundancia Cíclica que se daba en el protocolo anterior. 16

28 En 1999, los desarrolladores pedían una versión libre de la herramienta SSH así que, a partir del trabajo realizado por el sueco Björn Grönvall s con su aplicación OSSH basada en la antigua versión del protocolo SSH aún bajo licencia libre, los desarrolladores del proyecto OpenBSD crearon lo que aún hoy en día se conoce como OpenSSH. OpenSSH es la implementación ssh más popular, distribuida como aplicación básica en un gran número de sistemas operativos. Sin embargo OSSH se ha quedado obsoleta. Como ya se ha comentado con anterioridad, el protocolo SSH-2 de Tatu Yönen ha sido integrado como un estándar de Internet, mantenido y documentado por el Internet Engineering Task Force (IETF). 17

29 2.5 ARQUITECTURA El protocolo SSH-2 tiene una arquitectura definida en el documento RFC 4251 [7], con una clara separación de capas. Estas capas son: Capa de transporte RFC 4253 Esta capa [20] gestiona el intercambio de claves inicial en la autenticación del servidor, y configura el cifrado, la compresión la integridad y la verificación. Transmite a la capa inmediatamente superior un interfaz para el envío y recepción de paquetes en texto plano de unos bytes cada uno (aunque mediante la implementación del protocolo esta cifra puede aumentar). La capa de transporte también llega a acuerdos para el intercambio de claves. Las fases que se implementan en esta capa son: Autenticación de servidor Gestión de intercambio de clave inicial Negociación de algoritmos o Intercambio de clave Diffie-Hellman o Autenticación del servidor (RSA, DSA) o Encriptación simétrica o Compresión de datos (Opcional) Capa de autenticación de usuario RFC 4252 Esta capa [21] gestiona la autenticación del cliente SSH, y provee varios métodos de autenticación. La autenticación del cliente es muchas veces incomprendida por los usuarios. Cuando la petición de una contraseña se muestra, puede ser el cliente SSH el que realiza la petición y no el servidor. El servidor únicamente responde a las peticiones de autenticación del cliente. Los métodos de autenticación de cliente más utilizados son (ver epígrafe 2.6 de este Capítulo): Autenticación por Contraseña: Método mediante el cual el cliente accede a la máquina servidora mediante una contraseña. Incluye facilidades para el cambio 18

30 de la contraseña y su consecuente mantenimiento de la seguridad. Este método no está implementado por todos los programas cliente SSH. Clave pública: Método que normalmente soporta al menos pares de claves mediante los algoritmos de cifrado DSA o RSA con otras implementaciones que permiten el soporte de certificados digitales. Teclado interactivo: Un método muy versátil en donde el servidor envío uno o más mensajes para la adquisición de información, es el cliente el que los muestra y envía la respuesta de vuelta al servidor. Usado para proporcionar autenticación mediante contraseña en un único paso. Está implementado en algunas configuraciones de servidores OpenSSH Capa de conexión RFC 4254 Esta capa [22] define el concepto de canales. Una única conexión SSH puede alojar múltiples canales SSH de forma simultánea cada uno transfiriendo datos en ambas direcciones. Las peticiones de canales son usadas para implementar datos específicos como el cambio de un terminal remoto, el código de finalización de la sesión SSH etc. Puede darse el caso de la petición de cliente para redireccionar un puerto en el servidor remoto, debido a esto, los canales incluyen: Ejecución de SHell para a ejecución de terminales remotos, que permitan la ejecución de comandos SSH (Exec) o el envío de ficheros (SCP). Redirección de conexiones TCP/IP para redirigir información de aplicaciones entre el cliente y el servidor. Esta arquitectura proporciona una considerable flexibilidad, permitiendo a los usuarios SSH usar una gran variedad de utilidades sobre el propio protocolo. La funcionalidad de la capa de transporte es similar a la del TLS (Transport Layer Security). La capa de autenticación de usuario es muy extensa, soportando numerosos métodos de autenticación, con diferentes configuraciones. Por último, la capa de conexión proporciona la habilidad de multiplexar diferentes sesiones en una única conexión SSH. 19

31 2.6 MÉTODOS DE AUTENTICACIÓN Sesión SSH mediante autentificación por contraseña SSH permite autentificar a un usuario utilizando su contraseña Unix. La única diferencia con respecto a Telnet, ftp o rlogin como ya se ha comentado es que esta contraseña no viaja nunca en claro por la red. De esta manera evitaremos el peligro de que la contraseña sea capturada al utilizar cualquier aplicación que recoja y analice las comunicaciones entre dos máquinas en una red (sniffer de red). Al conectarnos al servidor SSH, éste siempre requiere que nosotros introduzcamos la contraseña. Cada servidor tiene asociado un par de claves pública y privada, equivalentes al par de claves de un usuario. Estas claves se utilizan para identificar al servidor frente al usuario. De esta forma se evita que otra máquina pueda suplantarlo. La primera vez que nos conectamos a la máquina remota, la aplicación cliente SSH solicita al servidor su clave pública. El cliente debe aceptar la clave que le provee el servidor, y esta queda registrada en el cliente para que en futuras conexiones, el cliente compare la clave que es suministrada por el servidor con la que tiene almacenada. Si las claves no coinciden el cliente no establecerá la conexión. Figura 2. Establecimiento de un canal SSH 20

32 Una vez creado el canal, el servidor SSH abre una Shell, un terminal de comandos Unix de la máquina servidora puesta a disposición de la aplicación cliente. Trabajar desde la aplicación cliente con la máquina remota (servidor SSH). $ ssh -l luperuma host.ejemplo Consola cliente ssh para acceso a la cuenta del usuario luperuma De las muchas opciones que presenta el protocolo esta con la opción l representa al loggin de acceso al host denominado Host.ejemplo por el usuario luperuma (ver anexo manual OpenSSH). $ ssh luperuma@host.ejemplo Consola cliente ssh para acceso a la cuenta del usuario luperuma También puede crearse una sesión SSH mediante la sintaxis usuario@nombrehost, prescindiendo en este caso del parámetro l que indica el nombre del usuario, tal y como está descrito en el ejemplo inmediatamente anterior. Un ejemplo real de establecimiento de conexión SSH a la cuenta del usuario luperuma en el servidor con IP se muestra en la siguiente imagen. 21

33 2.6.2 Sesión SSH mediante autenticación por intercambio de Clave publica Este segundo escenario utiliza un esquema de autenticación de clave pública/privada también conocido como clave asimétrica. En el escenario anterior, el usuario luperuma es autenticado por el servidor SSH mediante el acceso por contraseña. Sin embargo las contraseñas presentan serios contratiempos. Para que la contraseña sea segura debe ser de una gran longitud y debe ser aleatoria. Debido a esto son difíciles de memorizar. Una contraseña que se envía por la red, incluso protegida por el canal del protocolo SSH, puede ser capturada cuando se recibe en la máquina remota si esta se ha visto comprometida por terceras personas. La mayoría de los sistemas operativos soportan únicamente una contraseña por cada cuenta de usuario. Para cuentas compartidas como por ejemplo las de superusuario en sistemas UNIX (root), presentan ciertas dificultades. 22

34 No es conveniente el cambio de contraseñas puesto que este cambio no se replica para el resto de personas que intentan acceder a esa misma cuenta. El seguimiento del uso de la cuenta se vuelve difícil debido a que los sistemas operativos no distinguen entre diferentes usuarios de la cuenta Para superar estos problemas, SSH provee la autenticación por clave pública en vez de delegar el esquema de contraseñas en el sistema operativo. SSH puede hacer uso de claves criptográficas las cuales son más seguras que las contraseñas en general. A estas alturas de la explicación de la autenticación mediante el intercambio de claves públicas, se hace necesario saber que es realmente una clave. Y es que una clave es una identidad digital. Es una única cadena de datos binarios que significan Soy yo, realmente. Y con un poco de magia criptográfica el cliente SSH puede probar al servidor de que esa clave es auténtica y que el cliente dice ser quien realmente es. Una identidad SSH usa un par de claves, una privada y una pública. La clave privada la almacena el cliente de forma recelosa. La clave pública es lo que su nombre indica, pública y es la que envía el cliente a todos los servidores a los que desea conectarse. Es necesario lo siguiente: Una clave pública, que se copia a todos los servidores a los que queremos conectarnos. Una clave privada, que solamente posee la aplicación cliente. Para mayor seguridad esta clave está cifrada con una frase de paso. Instalar la clave pública en la máquina servidora SSH. Estas dos claves poseen una característica importante: un texto cifrado con la clave pública sólo puede ser descifrado usando la clave privada, mientras que un texto cifrado con la clave privada sólo puede descifrarse mediante la clave pública. La secuencia de establecimiento del canal seguro sería la siguiente. Nótese que la secuencia de números se corresponde con los dibujados en la figura 3: 1. El cliente dice Me gustaría conectarme a través de SSH en una cuenta en su sistema con usuario luperuma. Y el servidor responde Bueno, quizá pero 23

35 primero te reto a que pruebes tu identidad. El servidor envía un mensaje al cliente, que debe devolver cifrado con su clave privada. El cliente responde Acepto el reto. Aquí está la prueba de mi identidad. 2. El servidor replica Gracias por la autenticación. Examinaré la cuenta del usuario luperuma para comprobar si puedes entrar. El servidor descifra el mensaje de respuesta con la clave pública del cliente. 3. El servidor compara el mensaje resultante con el texto original; si coinciden, el servidor considera a la aplicación cliente debidamente autentificada. De acuerdo pasa. 4. Se crea el canal SSH y se establece la sesión. Figura 3. Establecimiento de canal SSH mediante clave asimétrica Todo este proceso es transparente para la aplicación cliente. Únicamente es necesario que el usuario teclee la frase de paso cuando la aplicación cliente lo solicite. Aún así, es necesario por prevención que la clave privada esté protegida con una frase de paso adecuada. De esta forma, nadie podrá utilizarla en el caso de que consiguiera hacerse con ella. 24

36 Cifrado + = Clave privada del cliente Descifrado + = Clave pública del cliente La configuración previa para este proceso es: Leyenda Generación de las claves Propagación de la clave pública Selección del par de claves Mensaje cifrado con clave privada del cliente Mensaje sin cifrar Figura 4. ejemplo de autenticación clave pública (O Reilly SSH the definitive Guide 2001) 25

37 Con las claves públicas no es necesario que el remitente y el destinatario se pongan de acuerdo en la clave a emplear, todo lo contrario que en sistemas simétricos. Lo único que se requiere como anteriormente se ha explicado es que antes de iniciar la comunicación encriptada, el remitente, en este caso el servidor SSH, consiga una copia de la clave pública del destinatario, en nuestro caso la aplicación cliente SSH Agente de autenticación SSH Cada vez que se ejecuta SSH mediante el método de autenticación por clave pública, se debe de reescribir la frase de paso (si existe, que por seguridad debería existir). Las primeras veces puede que no importe, pero escribirla de forma continuada puede llegar a ser engorroso. No sería mejor identificarse una única vez y permitir que SSH recuerde la identidad del usuario sin tener que escribir la frase de paso? De hecho esto lo ofrece el protocolo mediante el agente de autenticación. Un agente es un programa que guarda las claves privadas en la memoria y provee servicios de autenticación a los clientes SSH. Si al agente se le provee con la clave privada antes del comienzo del proceso de autenticación, el cliente SSH no necesitará presentar la petición de introducción de la frase de paso. El programa agente para OpenSSH se denomina ssh-agent. Generalmente se ejecuta el agente en la sesión local del cliente antes del acceso a la máquina remota. Se puede ejecutar el agente a mano, pero normalmente la gente edita sus ficheros de log (en sistemas UNIX /~login o /.session) para que el agente se ejecute automáticamente. La ejecución del agente es un proceso gestionado por el Sistema Operativo, por lo que todos los usuarios en la máquina local tienen acceso a este agente. $ ssh agent luperuma@host.ejemplo Sintaxis comando del agente de autenticación SSH El comando de la figura superior es el empleado para el arranque del agente de autenticación SSH. 26

38 2.7 CARACTERÍSTICAS DEL PROTOCOLO Redirección de puertos (Port forwarding) Redireccionamiento de puertos, Port forwarding o tunneling, es una forma de guiar tráfico TCP inseguro sobre el protocolo seguro SSH. Al generar una sesión SSH, puede hacerse que ciertas aplicaciones pasen por el túnel encriptado que se generó. Para las aplicaciones superiores el establecimiento de la sesión es transparente y levantar este túnel es mucho menos engorroso que crear una Red Privada Virtual (VPN). Sin embargo, el establecimiento de un canal seguro SSH, sólo permite ejecutar conexiones TCP, que son las que están orientadas a conexión. Al contrario que UDP, que no maneja sesiones, por lo que este sistema no funciona para servicios como DHCP, NFS, NetBIOS etc. Es decir, sólo las aplicaciones con conexiones TCP/IP están permitidas para el establecimiento de redireccionamiento de puertos Port forwarding con el protocolo SSH. Este redireccionamiento se consigue mediante el emparejamiento o mapeo del puerto TCP de la aplicación cliente (aplicación que se quiere redireccionar) con el puerto de la aplicación servidora. Es decir, toda la información generada por la aplicación cliente en la máquina local (máquina cliente) se dirigirá por el puerto TCP de la aplicación (ver Tabla 1. Aplicaciones y sus puertos TCP reservados) hacia el puerto en la máquina remota (máquina servidora). Algunas de las aplicaciones que permiten el redireccionamiento de puertos seguro mediante el protocolo SSH: 27

39 Aplicación Descripción Puerto TCP HTTP Protocolo de transferencia de hipertexto (Web) 80/8080 SMTP Protocolo simple de transferencia de correo 25 HTTPS Protocolo de transferencia de hipertexto seguro 443 POP Post Office Protocol ( ) 110 IMAP Internet Message Access Protocol ( ) 143 FTP Protocolo de Transferencia de Archivos 21 SSH Secure SHell 22 Tabla 1. Aplicaciones y números de puertos estandarizados Los puertos por debajo del 1024 son puertos privilegiados y sólo se pueden redirigir con privilegios de administrador o súper usuario (root en máquinas Unix). 28

40 Funcionamiento del Port forwarding Para entender el funcionamiento del Port forwarding, es necesario conocer y entender algunos detalles sobre el protocolo TCP (Transmission Control Protocol) ya que es una pieza fundamental en la construcción de la redirección de puertos. CONEXIONES TCP Construido sobre el protocolo de red IP, es un mecanismo de transporte para muchas aplicaciones del nivel IP, tales como FTP, Telnet, http, SMTP, POP, IMAP, y el propio SSH. TCP posee grandes garantías. Una conexión TCP es un canal virtual fullduplex entre emisor y receptor. Cada parte puede escribir cualquier número de bytes a cualquier tiempo en el canal, y los bytes se garantizan que llegarán inalterados y preservando la secuencia de envío (en el mismo orden de envío) en la otra parte del canal. Los mecanismos que implementan estas garantías, aunque están diseñados para resolver problemas de transmisión en la red, tales como fallos en enlaces de enrutamiento, o retransmisión de datos que han sido corrompidos por el ruido o la pérdida de los mismos debido a la congestión en la red, no son efectivos contra intentos de robos de la conexión o alteración de los datos en tránsito. SSH provee esta protección de la que TCP carece. Si una aplicación no necesita estas garantías sobre la integridad de los datos y el mantenimiento de la secuencia de los mismos, existe otro protocolo denominado User Datagram Protocol (UDP) que a menudo es suficiente. Es un protocolo orientado a paquetes que no garantiza la recepción de los paquetes en el orden en que se enviaron. Algunos protocolos que se corren sobre UDP son NFS, DNS, CHCP, NetBIOS, TFTP, Kerberos etc. Cuando un programa establece una conexión TCP hacia un servicio determinado, éste necesita dos piezas de información. La dirección IP de la máquina destino y una forma de identificar el servicio deseado. 29

41 TCP (y UDP) utiliza un entero positivo, denominado número de puerto para identificar un servicio (ver tabla 1 Aplicaciones y números de puertos estandarizados). Los números de puerto permiten múltiples servicios sobre una misma dirección IP. La combinación de una dirección IP y un número de puerto se denomina socket. Por ejemplo si se ejecuta Telnet para conectarse en el puerto 23 en la máquina con dirección IP , el socket se representa como ( ,23). La fuente, el programa cliente, también tiene asociado un socket en el final de su conexión, y la conexión en su conjunto es completamente definida por un par de sockets fuentes y destinos. Para que una conexión mediante sockets tenga éxito, algo debe estar escuchando en esos sockets. Este algo es un programa que se ejecuta en la máquina destino de la comunicación, y que debe preguntar al protocolo TCP para aceptar peticiones de conexión en un determinado puerto y pasar esas conexiones a programa. Si alguna vez se ha intentado una conexión TCP y se ha recibido una respuesta del tipo Conexión rechazada, significa que la máquina remota está activa y ejecutándose, pero nada esta escuchando en el socket destino. Cómo conoce un programa cliente el número de puerto en el que el servidor está escuchando? Los números de puertos para muchos protocolos están estandarizados, asignado por IANA [15] (Internet Assigned Numbres Authority, ver tabla 1, aplicaciones y números de puertos estandarizados). Los números de puertos no son siempre implementados, codificados, en los programas. Muchos Sistemas Operativos dejan que las aplicaciones se refieran a los protocolos por nombre en vez de por número, definiendo una tabla de nombres y números de puertos TCP. De esta forma, los programas pueden obtener los números de puerto por el nombre del protocolo que se utiliza. En los sistemas Unix, la tabla esta a menudo almacenado en el fichero /etc/services, y las llamadas que se codifican requieren de librerías con funciones tipo getservbyname() getservbyport().. 30

42 Otros entornos permiten a los servidores registrar sus puertos de escucha dinámicamente mediante un servicio de nombre tales como DNS o AppleTalk. Visto el funcionamiento de los números de puertos bajo la perspectiva de la máquina servidora, observemos ahora más de cerca la máquina cliente. El cliente también utiliza un número de puerto, denominado número de puerto de origen, de forma que el servidor pueda transmitir al cliente. Si se combinan las direcciones IP del cliente y sus números de puerto origen obtenemos el socket del cliente. A diferencia de los números de puerto destinos, los puertos origen del cliente no están estandarizados. En la mayoría de los casos el cliente deja al protocolo TCP el que elija el número de puerto origen. Si se examinan conexiones TCP en una máquina con el comando netstat a se observaran conexiones con puertos bien conocidos (well-known), para servicios comunes como Telnet 23, SSH 22 etc. El mecanismos de puertos origen y destino y la combinación de direcciones IP de cada máquina, permite que múltiples clientes establezcan conexiones TCP a un mismo socket destino. Una vez realizado un breve viaje sobre el protocolo TCP, se expone a continuación un ejemplo para la comprensión del funcionamiento de la redirección de puertos en SSH, y una de sus posibles utilidades. Supongamos que queremos conectarnos a un servidor de correo (POP, IMAP) o que simplemente queremos navegar (HTTP), pero la parte que se sitúa más cerca, a la que nos vamos a conectar en primer lugar es insegura. Por ejemplo, nos estamos conectando mediante IEEE b (Wireless LAN) y no terminamos de fiarnos del cifrado WEP (Wired Equivalent Privacy) que nos ofrece el punto de acceso al que intentamos conectarnos. O realizamos una conexión al punto de acceso de la Universidad, pero entre los servicios que ofrece ésta, no está supongamos, incluido el de correo electrónico u otros 31

43 servicios de suma importancia para nuestro trabajo, o que debido a un firewall no podemos acceder a esos servicios. Supongamos también que tenemos acceso mediante SSH a una máquina servidora de confianza en una parte segura de la red como por ejemplo en nuestro domicilio, o por lo menos más segura que la parte que nos preocupa, en el ejemplo la red de la universidad. Es posible entonces, que esta máquina servidora remota a la que nos queremos conectar para leer el correo, o navegar, haga de pasarela (Gateway) entre la red inalámbrica de la Universidad y la red alámbrica de nuestro domicilio (ver Figura 6). Podremos entonces tender un puente, o un túnel mediante el establecimiento de una sesión SSH entre nuestra máquina local en la red insegura (red Universitaria inalámbrica) y la máquina remota en la parte segura (en el domicilio), salvando los peligros de la parte insegura gracias a la seguridad que provee el protocolo SSH. Lo que haremos en cierta manera es acercarnos a la máquina segura. De esta manera podremos redireccionar las conexiones TCP a través del túnel SSH para usar aplicaciones que en principio nos estaban vetadas (en la red de la Universidad) como el correo electrónico. Figura 5. Esquema teórico de Port forwarding (O Reilly SSH the definitive Guide 2001) 32

44 Figura 6. Ejemplo de Port Forwarding bajo sesión SSH Conjugando la redirección de puertos y la sesión SSH obtenemos todos los servicios disponibles en la máquina remota (domicilio) y una conexión con toda la seguridad que provee el canal SSH Tipos de Port forwarding Existen dos tipos de Port forwarding: Port forwarding Local Port forwarding Remoto Port forwarding -D Su funcionamiento es simétrico uno con respecto al otro. Por tanto comenzaremos explicando el Local sabiendo que el Remoto es igual pero a la inversa. 33

45 $ ssh -L puerto_local:maquina_destino:puerto_destino Sintaxis comando ssh port forwarding local El puerto_local especifica un puerto TCP de la máquina local y evidentemente la máquina_destino y el puerto_destino especifican pues eso, la máquina remota. Si nos conectamos a localhost:puertolocal (máquina local y un puerto local), entonces esa conexión TCP será redirigida a través del túnel SSH a la máquina remota (máquina segura) y de ahí se establecerá una conexión a la máquina_destino:puerto:destino. Hay que tener en cuenta que la máquina_destino se resolverá en la máquina segura, luego si ponemos localhost convertiremos las máquina_destino en la máquina segura. Todo es más fácil si observamos el siguiente ejemplo: $ ssh -L 8080:localhost:3128 luperuma.maquina.segura Sintaxis comando ssh port forwarding local Este comando lo que dicta es, por favor SSH, establece una conexión segura desde el puerto TCP 8080 en la máquina destino en este caso localhost, nuestra máquina local, al puerto TCP 3128 en la máquina remota luperuma.maquina.segura. Qué conseguimos con esto? Sencillamente que todas las conexiones que en nuestra máquina local vayan por el puerto 8080 (Web), se resuelvan por el puerto 3128 de la máquina remota segura. Claro está, es necesario dos pasos importantes para que esto funcione: Configurar un Proxy de servicios Web en este caso, que esté escuchando peticiones en el puerto Configurar nuestro navegador (aplicación que conecta por el puerto 8080) para que se conecte al Proxy en la máquina remota segura por el puerto

46 Otro ejemplo podría ser este: $ ssh -L 110:mipop:110 luperuma.maquina.segura Sintaxis comando ssh port forwarding local Suponiendo en este caso que tenemos una cuenta POP de correo en la máquina mipop y que no tenemos acceso a la cuenta de correo de la máquina mipop desde el punto de acceso al que está conectada la máquina local, estableciendo un túnel ssh hacia el servidor luperuma.maquina.segura, todas las conexiones al puerto local 110 serán redirigidas al puerto 110 de la máquina mipop a través de la máquina segura luperuma.maquina.segura. Como dijimos anteriormente, port forwarding local y remoto son simétricos, es decir lo mismo pero al revés. La única diferencia reside en la sintaxis del comando; el local se establece mediante -L mientras que el remoto se establece con el parámetro -R. $ ssh -R 6110:localhost:110 luperuma.maquina.segura Sintaxis comando ssh port forwarding remoto La redirección en este caso se realiza en sentido contrario. Todas las conexiones a luperuma.maquina.segura por el puerto 6110 con redirigidas de forma transparente a través del túnel SSH al puerto local 110. Así que si en la máquina local tenemos un servidor POP funcionando, las máquinas de la parte remota pueden usarlo accediendo en el puerto 6110 de luperuma.maquina.segura. El último tipo de Port forwarding es quizá el más flexible, pero a cambio de esa flexibilidad adicional requiere de aplicaciones TCP que lo soporten. 35

47 $ ssh -D 8080:localhost:3128 luperuma.maquina.segura Sintaxis comando ssh port forwarding -D Para el empleo de esta modalidad se requiere la sintaxis arriba explicitada. Este tipo de redirección de puertos, simplemente toma un puerto local, en este caso le hemos indicado el puerto 8080, como argumento, y ahí establece un servidor SOCKS. SOCKS es un protocolo de Internet que permite a las aplicaciones enmarcadas en la arquitectura cliente/servidor, usar de manera transparente los servicios de un firewall de red. SOCKS es una abreviación de SOCKetS SSH X forwarding X es un popular sistema de ventanas para estaciones de trabajo Unix y una de sus mejores características es su transparencia. Mediante el sistema X, se pueden ejecutar aplicaciones remotas que permiten la apertura de ventanas en la máquina local (y a la inversa, ejecutando aplicaciones locales abrir ventanas remotas). Desafortunadamente las comunicaciones entre máquinas es insegura. Pero mediante la comunicación SSH se permite que las comunicaciones y el despliegue de ventanas en máquinas remotas esté protegido por el túnel SSH Transferencia de ficheros mediante SCP El programa SCP es un programa regido bajo las reglas del protocolo Secure Shell que permite la trasferencia de archivos por el canal seguro establecido en una sesión SSH previa al envío. Es una buena alternativa a programas como la copia de archivos en máquinas UNIX (cp), o el inseguro rcp. Sin embargo su sintaxis en muy similar en ambos casos. $ scp nombre_fichero_origen nombre_fichero_destino Sintaxis comando ssh port forwarding remoto 36

48 Al copiar el archivo, debe existir en la máquina local un nombre idéntico al nombre_fichero_origen, y en cuanto al nombre_fichero_destino no tiene por que ser igual que el origen. Si el nombre destino es no está cualificado, es decir únicamente contiene el nombre del fichero, scp por defecto copia este fichero en el directorio local de la máquina remota. En general en máquinas UNIX /home/username. Aún así, se puede dirigir la copia en el directorio requerido indicándolo en el nombre de fichero destino. 37

49 2.8 CONSIDERACIONES DE SEGURIDAD Known hosts La primera vez que un cliente SSH accede a la máquina remota, servidor SSH, ésta imprime un mensaje como el siguiente: Asumiendo que el usuario normalmente responde Si a la pregunta planteada, el cliente continúa: Este mensaje aparece sólo la primera vez que se conecta con un host remoto. El mensaje proviene de una característica de seguridad inherente al concepto de SSH denominado Known hosts, máquinas conocidas. Si suponemos por ejemplo que un enemigo quiere obtener tu contraseña y sabe que estás utilizando SSH, el no puede observar la conexión que se está produciendo entre cliente y servidor, puesto que va cifrada, pero sin embargo puede alterar el servicio de nombres que está utilizando el cliente SSH y traducirlo a una dirección IP de otra máquina servidora ejecutándose bajo su administración. Este usuario malicioso instala un servidor SSH en esa máquina y espera peticiones, suplantando de esta forma al servidor SSH original al que se quería conectar. 38

50 Una vez realizado esto, cuando el usuario del cliente se conecta al servidor SSH alterado, el enemigo puede almacenar la contraseña del cliente para su uso posterior. El servidor malicioso puede desconectarse mediante un mensaje de error fingido tal como Sistema caído por mantenimiento y usar la contraseña robada para incluso acceder a la cuenta del cliente en el servidor real original SSH. A menos que el cliente cada vez que quiera conectarse al servidor decida realizar un seguimiento de la dirección IP del servidor, nunca se dará cuenta de que su contraseña se ha puesto en entredicho. El mecanismo de known host previene ataques como este. Cuando un cliente SSH y un servidor realizan una conexión, cada uno de ello provee la identidad al otro. No sólo el servidor autentica al cliente, como hemos visto antes, sino que el cliente también autentica al servidor mediante el mecanismo de criptografía de clave pública. En definitiva, cada servidor SSH posee una única ID denominada host key para identificarse a cada cliente. La primera vez que se conecta a la máquina remota, el cliente copia la clave pública del servidor en un archivo local (asumiendo que se respondo sí a la pregunta antes presentada). Cada vez que el cliente se reconecta al servidor comprueba la identidad de éste mediante su clave pública. Por supuesto es mejor copiar la clave pública del servidor antes de conectarte a el, puesto que técnicamente se está expuesto a ataques man in the middle. Si la autenticación del servidor falla, pueden ocurrir varias cosas dependiendo de la razón del error. Normalmente suelen aparecer mensajes en el cliente como el siguiente: Si la respuesta es Si SSH permite la conexión pero deshabilita varias características como la actualización del fichero local de máquinas conocidas (Known hosts) con la nueva clave. Esto debiera hacerse manualmente por el usuario cliente. 39

51 2.8.2 Ataque Man in the middle Un ataque man-in-the-middle es un tipo particular de ataque (ver figura 7), en donde un enemigo situado entre el cliente SSH y el servidor, intercepta todo el trafico alterando o borrando los mensajes de información a su gusto. Suponiendo que intentamos conectarnos a un servidor SSH, pero alguien intercepta la conexión. Este alguien el enemigo a partir de ahora, se comporta como si fuera un servidor SSH aunque el cliente no lo advierte, y el enemigo pretende compartir una clave de sesión con el usuario de la aplicación cliente. De forma simultánea, el enemigo inicia su propia conexión con el servidor SSH con el que el cliente pretendía acceder desde un principio, obteniendo una clave de sesión diferente con este servidor. El enemigo puede acceder al servidor como si fuera el cliente puesto que ha utilizado la contraseña de autenticación que convenientemente ha captado en la conexión con el cliente. Ambos, tanto el cliente como el servidor real SSH piensan que mantienen una conexión uno con el otro, cuando de hecho ambos mantienen una conexión con el enemigo. Éste entonces, permanece en el medio, enviando y recibiendo datos descifrando en un lado con una clave y cifrando por el otro lado con otra para la retransmisión. Por supuesto, el enemigo puede leer toda la información y modificarla incluso sin que esto sea detectable. El protocolo SSH contrarresta este efecto de dos maneras: La primera, la autenticación de servidor. A menos que el enemigo haya penetrado en la máquina servidora, no puede acceder a la clave privada del servidor, luego no puede identificarse como servidor SSH. Para que esta protección tenga efecto, es crucial que el cliente haya comprobado en sus ficheros de máquinas conocidas (known hosts) la validez de la clave pública enviada por el servidor SSH real. De otra forma no hay garantías de conocer si el servidor SSH es real y confiable. Si el cliente se conecta por primera vez a un nuevo servidor SSH y acepta su clave pública, éste se está exponiendo al ataque man-in-the-middle. 40

52 Figura 7. Esquema del ataque Man in the Middle (O Reilly SSH the definitive Guide 2001) La segunda protección que propone el protocolo es la autenticación basada en el intercambio de clave pública ya explicada. El enemigo no puede descubrir la clave de sesión mediante la simple observación del intercambio de clave. 41

53 2.9 TECNOLOGÍAS RELACIONADAS SSH es muy popular de hecho se lo ha ganado, pero también es cierto que no es la única solución para la seguridad de las redes. La autenticación, cifrado y seguridad de redes se originó antes que SSH. En este epígrafe se intenta realizar una somera visión sobre otras tecnologías representativas en el área de la seguridad de la red RSH (RCommands) Los programas UNIX rsh, rlogin y rcp conocidos como los RCommands son los directos antecesores de SSH-1. Los interfaces de usuarios y la sintaxis son casi idénticos a ssh exceptuando la seguridad. Estos programas al contrario que SSH no cifran sus conexiones y tienen un frágil modelo de autenticación. Los servidores RCommands se sustentan en dos mecanismos para la seguridad: el servicio de nombres de la red y lo puertos privilegiados TCP (del 1 al 1023). Cuando se observa una conexión entrante de un cliente, el servidor obtiene la dirección de red del origen de la comunicación, y la traduce a un nombre de host (hostname) mediante los servicios de DNS por ejemplo. Este nombre de host debe estar presente en un archivo de configuración (en UNIX /etc/hosts) para que el servidor le permita el acceso. Si la conexión pasa el test, el servidor cree que está hablando con un programa válido y de confianza, mientras que el cliente puede acceder en cualquier cuenta en el servidor. Estos dos mecanismos de seguridad son fácilmente ignorados. La traducción de direcciones IP a nombres de host está hecho por servicios como DNS, en los que la mayoría de implementaciones tiene serios agujeros de seguridad, presentando oportunidades para engañar al servidor y hacerle ver máquinas fiables donde realmente no las hay. De esta forma un usuario remoto puede acceder en la cuenta de otro usuario en un servidor simplemente por tener el mismo nombre. Desarrollado en anteriores epígrafes la superioridad de SSH en todos los aspectos, puesto que ofrece la misma funcionalidad que los RCommands y además sobre un soporte fiable en cuanto a seguridad se refiere, no se entiende y no se recomienda actualmente el uso de estas herramientas. 42

54 2.9.2 Kerberos Kerberos es un sistema de autenticación seguro para entornos donde las redes pueden ser observadas (monitoreadas), y los ordenadores no se encuentran bajo un control centralizado. Este sistema fue desarrollado por una parte del proyecto Athena, un amplio proyecto de investigación y desarrollo en la Universidad de Massachusetts en el Instituto de Tecnología (MIT). Kerberos autentica usuarios mediante los que se denomina tickets, pequeñas secuencias de bytes con un tiempo limitado de vida, mientras que las contraseñas están almacenadas de forma segura en una máquina central. Kerberos y SSH resuelven problemas similares pero son bastante diferentes en cuanto al ámbito de aplicación. Mientras que SSH es un protocolo poco pesado y de fácil despliegue en los sistemas, para permitir el acceso seguro de una máquina a otro, mediante la simple instalación de un cliente y un servidor. Kerberos al contrario, requiere una gran infraestructura para establecerse antes de poder usarse. Gestiones administrativas de contraseñas de usuario, una máquina central fuertemente asegurada, y software para redes amplias mediante sincronización de reloj. SSH envía contraseñas mediante la red sobre conexiones cifradas en cada acceso a la máquina remota, en la que se almacenan las claves. Kerberos también sirve para otros propósitos fuera del alcance de SSH, incluyendo una base centralizada de usuarios, listas de acceso y un modelo jerárquico de validación. Otra diferencia sustancial entre SSH y Kerberos es el acercamiento a la seguridad de las aplicaciones cliente. SSH puede ser fácilmente integrado con otros programas no seguros que abren conexiones directas hacia la red. Kerberos por el contrario contiene una serie de librerías de programas para añadirles la autenticación y encriptación a otras aplicaciones. Los desarrolladores pueden integrar aplicaciones con Kerberos mediante la modificación del código fuente para permitir llamadas a las librerías del sistema Kerberos [16]. 43

55 2.9.3 Ipsec Internet Protocol Security (IPSEC) [17], es un estándar de Internet en constante evolución, desarrollado por el grupo de trabajo IETF. IPSEC implementa la autenticación y la encriptación en el nivel IP. Este es un nivel más bajo del modelo de red con respecto al modelo que ofrece SSH. Es completamente transparente para los usuarios finales, los cuales no necesitan utilizar un programa particular como SSH para conseguir seguridad, ya que su tráfico de red inseguro es protegido automáticamente por el sistema que los soporta. IPSEC puede realizar conexiones seguras desde una única máquina a una red remota a través de una red insegura como puede ser Internet, puede por el contrario conectar redes enteras mediante la idea de Redes Privadas Virtuales (VPN). Mientras que la facilidad de SSH ya vista en su despliegue y utilización, IPSEC es una solución que requiere operaciones adicionales en los sistemas de ambos lados de la red. SSH implementa autenticación, mientras que IPSEC trabaja únicamente con máquinas individuales. IPSEC permite las características de autenticación y cifrado de SSH mediante el uso de otro protocolo denominado ESP, Encapsulated Security Payload Secure Socket Layer (SSL) Secure Socket Layer [18] es un protocolo de autenticación y técnicas de encriptación que provee seguridad a los servicios TCP de cliente. Fue inicialmente desarrollado por Netscape Communications para asegurar el protocolo http entre clientes y servidores Web y es el más popular en cuanto a su uso. Está documentado por el estándar del IETF den el RFC En SSH, los participantes de la comunicación prueban su identidad mediante certificados digitales. Un certificado indica que una autoridad certificadora prueba la identidad de la entidad a la que se quiere comunicar un cliente mediante la entrega de una clave cifrada. Los navegadores Web automáticamente prueban la validez del certificado cuando se quieren conectar al servidor Web mediante una conexión SSL, asegurando que ese servidor dice ser quien realmente es. 44

56 3 Capítulo 3 DESARROLLO DE GUEFIRA PROJECT

57 CAPÍTULO 3 DESARROLLO DE GUEFIRA PROJECT 3.1 PRÓLOGO Dos menos cinco de la tarde, cinco minutos faltan para el cierre de una sucursal bancaria donde un usuario realiza una gestión sobre su cuenta. Pero parece existir un problema cuando este usuario observa que no está en posesión de los datos necesarios para realizar la gestión. No le queda otro remedio que esperar al día siguiente. Dos menos cinco de la tarde, cinco minutos faltan para el cierre de otra sucursal bancaria, donde otro usuario realiza una gestión sobre su cuenta. Tampoco está en posesión de los datos necesarios para realizarla, y requiere de esta información antes de que cierre la sucursal. Es entonces cuando decide conectarse desde su teléfono móvil al ordenador de su casa donde reside la información necesaria para llevar a cavo la gestión. Sin embargo no está del todo conforme con que los datos, de extrema confidencialidad viajen de forma no segura por la red. Opta por no correr riesgos y establecer una conexión SSH a su ordenador mediante las herramientas ofrecidas por la aplicación GUEFIRA, garantizando integridad y confidencialidad a la información que desea recibir. Dos en punto de la tarde, este usuario realizó con éxito su tarea. GUEFIRA PROJECT, aplicación cliente SSH dirigida para su ejecución en dispositivos móviles engloba una serie de herramientas que pretenden satisfacer las necesidades de conexión de los usuarios en cualquier lugar y en cualquier momento. GUEFIRA PROJECT hace uso del protocolo SSH (Capítulo 2) para permitir autenticación, integridad y confidencialidad a la información que el usuario de la aplicación desea enviar o recibir. 46

58 3.2 ENTORNO DE DESARROLLO La implementación de GUEFIRA, se ha realizado íntegramente mediante las utilidades que ofrece el lenguaje de programación JAVA. Sin embargo al estar dirigida a dispositivos móviles ha sido necesario la utilización de este lenguaje en su versión denominada MICRO EDITION o J2ME, cuyas librerías de clases han sido adaptadas a la arquitectura y recursos presentados en esta clase de aparatos. En cuanto a la implementación del protocolo SSH en JAVA, se ha requerido la utilización de las librerías JSch del equipo JCRAFT bajo licencia libre de distribución Open BSD. Estas librerías son una implementación del protocolo SSH-2 en java puro. Los requerimientos necesarios para que las librerías JSCH funcionen son en primer lugar la dependencia que posee sobre JAVA TM Cryptography Extension (JCE), librerías de java con clases relativas al intercambio de claves y a la creación de las mismas mediante técnicas de cifrado. En último lugar resaltar la utilización de la plataforma eclipse IDE para la implementación de la aplicación y la gestión de librerías y plugins. A continuación pasamos a describir en detalle cada una de las tecnologías mencionadas Introducción al entorno JAVA J2ME Java Micro Edition J2ME es una familia de especificaciones que define varias versiones por debajo de la versión estándar de Java, (J2SE). Estas versiones pueden ser usadas para programar aplicaciones en una gran variedad de dispositivos electrónicos desde teléfonos móviles hasta Agendas Digitales Personales (PDA s), y smartphones. Estos dispositivos, diversos tanto en aspecto como en forma tienen un aspecto en común, no poseen memoria y/o capacidad de procesamiento para soportar las librerías que provee la versión estándar de java usada tanto en estaciones de trabajo como en sistemas servidores. J2ME define dos configuraciones, especificaciones que definen el entorno software para una gran variedad de dispositivos, definidos por una serie de características tales como: 47

59 La capacidad y el tipo de memoria disponible. El tipo y la velocidad de los procesadores. El tipo de conexión de red al que los dispositivos están disponibles a acceder. Los fabricantes de estos dispositivos deben implementar estas especificaciones para que los desarrolladores de software creen aplicaciones consistentes que se puedan ejecutar en los mismos y que sean lo más independientes del dispositivo a los que van dirigidos. Figura 8. Tecnologías JAVA disponibles. En naranja J2ME CDC. (Sun Microsystems 2008) Actualmente J2ME define dos configuraciones: 1. Connected limited Device Configuration (CLDC JSR 139) CLDC está dirigida a dispositivos de bajo rendimiento y poca capacidad de procesamiento. Típicamente teléfonos móviles o PDA s con una capacidad disponible de memoria de alrededor de los 512 KB. Por esta razón, CLDC está estrechamente relacionado con pequeñas aplicaciones Java denominadas MIDlets, específicas para teléfonos móviles. Una gran cantidad de fabricantes han firmado acuerdos con Sun 48

60 Microsystems que permitirán empezar a usar esta tecnología por lo que esta capacidad de programar en Java ya se está viendo incrementada rápidamente en los últimos años. 2. Connected Device Configuration (CDC JSR 218) CDC está identificada con las necesidades que presentan los dispositivos intermedios entre la configuración anterior (CLDC), y los ordenadores personales que ejecutan aplicaciones J2SE. Estos dispositivos, PDA s y smartphones, poseen una capacidad de memoria de alrededor de los 2 MB o más y unos procesadores que presentan una mayor capacidad de procesamiento. Debido a esto, estos dispositivos soportan un entorno Java más completo como es el CDC. Dentro de esta especificación surgen tres más que se desarrollaron para cubrir carencias o aplicar mejoras a la Connected Device Configuration. The Foundation Profile (JSR 219). Personal Basis Profile (JSR 217). Personal Profile (JSR 216). The Foundation Profile es una especificación de Java CDC. Esta especificación esta dirigida para ser usada por dispositivos que requieren una completa implementación de la máquina virtual de Java, incluyendo la plataforma estándar. Vincula la plataforma J2SE a los dispositivos móviles. Personal Basis Profile hereda de la especificación Foundation Profile pero incluye además soporte para interfaces gráficos de usuario (GUI) mediante la librería AWT de Java. Personal Profile es una extensión de Personal Basis Profile, que incluye mejoras para interfaces gráficos, mediante las librerías AWT de la plataforma estándar de Java. Además agrega soporte para applets. La aplicación GUEFIRA, está desarrollada con tecnología J2ME haciendo uso de esta segunda configuración, Connected Device Configuration. 49

61 3.2.2 Librerías JSch del equipo JCRAFT JSch [8] es el acrónimo que corresponde a una librería que implementa el protocolo SSH-2 en Java puro. Existen varias versiones de esta librería dependiendo de a qué plataforma está dirigida la programación. JSch para J2SE, la versión estándar de Java. JSch para J2ME es su configuración CLDC (MIDlets). JSch para J2ME en su configuración CDC. (GUEFIRA) La librería JSch permite soporte para: Soporte para protocolo SSH-2. Intercambio de claves Diffie-Hellman. Cifrado Blowfish, CBC, 3DES-CBC. Cifrado de claves del host ssh-dss, ssh-rsa. Autenticación mediante contraseña. Autenticación mediante intercambio de clave pública (DSA,RSA). Ejecución Remota de terminales SSH Transferencia de ficheros. Stream forwarding. Sin embargo JSch presenta una restricción. Tal como se explicó en el capítulo 2 SSH provee seguridad mediante el establecimiento de una sesión SSH mediante la apertura de un canal cifrado. Para el cifrado, y los métodos de autenticación, tanto mediante contraseña o nombre de host como autenticación mediante intercambio de clave pública, es necesario el uso de algoritmos que permitan la autenticación, la integridad y la confidencialidad a la información enviada. Para ello, JSch hace uso de otra librería llamada Bouncy Castle Crypto. JSch ha sido desarrollado de forma íntegra por ymnk@jcraft.com, JCraft,Inc. 50

62 3.2.3 Librería Bouncy Castle Crypto La llamada Legion Bouncy Castle, es la creadora de esta API de Java, que no es ni más ni menos que una implementación más concisa y actualizada de los algoritmos criptográficos necesarios para la implementación del protocolo SSH. Surge a partir de la necesidad de mejora del Java Cryptography Extension (JCE). Al empezar a organizar el entorno de desarrollo para la aplicación GUEFIRA, surgieron numerosos problemas para integrar todas las librerías en la herramienta de desarrollo eclipse IDE, pero existió un problema directamente relacionado con el uso de las librerías Bouncy Castle Crypto. Y es que esta librería crea clases Java en algunos paquetes tales como java/math/biginteger o java/security/securerandom/ que hacen que salte una excepción de seguridad que proviene de la máquina virtual de java (JVM). A la hora de compilar, eclipse no se quejaba de nada, sin embargo en tiempo de ejecución se lanzaba una excepción que provenía de la clase java.security.securerandom, que era instanciada a su vez desde el proceso de la aplicación GUEFIRA en el establecimiento de la sesión SSH por medio de la librería JSch. Pasó algún tiempo hasta que se pudo resolver el problema. La solución venía de la mano de lo PROGUARD 4.1, una herramienta bajo licencia libre de distribución, que permitía lo que se denomina ofuscación de código El concepto de ofuscación y Proguard 4.1 Según la Wikipedia [11], la ofuscación se refiere al hecho de encubrir el significado de una comunicación haciéndola más complicada de interpretar. En la computación, la ofuscación se refiere al acto deliberado de realizar un cambio, ya sea en 51

63 el código fuente de un programa o en el código máquina cuando el programa está en forma compilada o binaria, con el fin de que no sea fácil de entender o leer. La ofuscación lleva consigo en la gran mayoría de ocasiones, hacer que los programas sean más pequeños, aunque en algunos casos puede suceder que sean más grandes que el original. Proguard 4.1 es la herramienta pues, que permite la ofuscación de código, que en el caso que nos ocupa permite encubrir a la máquina virtual de java (JVM) la utilización que se está llevando a cabo de ciertas clases, que de ser instanciadas llevarían consigo la aparición de las excepciones comentadas en el epígrafe anterior. La herramienta Eclipse, provee el uso de Proguard 4.1 mediante la instalación de plugins. De esta forma el ciclo que sigue la aplicación en Eclipse sería el siguiente: 1. Implementación 2. Compilación 3. Ofuscación 4. Creación de las clases 5. Empaquetado Al final de esta serie de pasos, en el caso de la aplicación GUEFIRA se obtendría un fichero con extensión JAR WebSphere Everyplace Micro Environment El fabricante IBM ha desarrollado una máquina virtual de java para PDA s y Smartphones, puesto que no todos los sistemas operativos embebidos en estos dispositivos tienen la capacidad de ejecutar programas Java. 52

64 Es necesario por tanto la utilización de una máquina virtual para la ejecución de la aplicación GUEFIRA en dispositivos móviles. WebSphere Everyplace Micro Environment o anteriormente denominada IBM J9, es el único requisito necesario para la ejecución de la aplicación cliente SSH. En anteriores capítulos se había comentado el perjuicio que supone el que algunas aplicaciones sean tan dependientes de entornos muy concretos, impidiendo su ejecución en gran cantidad de dispositivos disponibles en el mercado. Sin embargo, la popularidad de Java es una gran ventaja para GUEFIRA, puesto que no existe prácticamente ningún sistema operativo móvil que no permita la instalación de esta herramienta de IBM. WebSphere puede ejecutarse en los siguientes sistemas operativos: Mobilinux con procesador ARM. Montavista Linux professional Edition con procesador PPC HF. Windows CE 5.0 con procesador ARM. Windows Mobile 5.0 con procesador ARM Librerías gráficas SWT de Eclipse SWT son una sería de librerías Java de distribución libre englobadas en el entorno de desarrollo de la herramienta eclipse, que permiten la implementación de widgets para la creación de interfaces de usuario. Es similar a las librerías Swing que ofrece Sun Microsistems en el paquete SDK de Java, con la diferencia de que éstas están a un nivel más cercano del sistema operativo en el que se ejecutan. Distribuyen los eventos de la misma forma que el sistema operativo en el que residen, mediante la gestión de colas de eventos e hilos de ejecución. Para ello, sólo disponen de un único thread o hilo de ejecución denominado UI thread o hilo de la interfaz de usuario desde el cuál se manejan las excepciones y eventos realizados por el usuario. 53

65 Como es lógico, la implementación de cualquier lógica de la aplicación que esté exenta del interfaz gráfico, se puede implementar en clases diferentes a la del UI thread para una mejor modularización y optimización del código de la aplicación. Para ello, la API de estas librerías proporciona métodos para la ejecución de código diferente del interfaz gráfico. Métodos síncrono con el hijo de ejecución del interfaz gráfico para la espera de respuestas de usuario, o métodos asíncronos para códigos que no guardan relación con la entrada salida de eventos en el interfaz gráfico. La gestión del hilo UI, debe ser precisa para no cometer errores, pero aunque es más compleja que la implementación de las librerías Swing de Java, las librerías SWT permiten la implementación de interfaces más vistos y amables de cara a la utilización de aplicaciones por parte de los usuario Entornos de desarrollo alternativos Existen numerosos lenguajes de programación disponibles para la implementación de aplicaciones dirigidas a PDA s y Smartphones. Smalltalk por ejemplo, que además posee la ventaja añadida de no requerir instalación alguna en el dispositivo para correr aplicaciones, aunque no permite el manejo de puertos. SuperWaba, presenta las mismas ventajas de J2ME. Python que aunque no posee la característica de gestión de la memoria ( recolector de basura de Java) es otro lenguaje muy adecuado para esta clase de dispositivos. Recientemente ha surgido un nuevo SDK para java de la manos de la compañía Google llamado Android. Sin embargo aún no está preparado para la implementación en los dispositivos, únicamente su emulación en PC s. Sin embargo, la elección de J2ME viene impuesta única y exclusivamente por la utilización de las clases JSch. Como ya se ha explicado con anterioridad, JSch es una implementación del protocolo SSH en Java puro, por lo que la aplicación cliente SSH debía de estar desarrollada en Java. 54

66 3.3 ANÁLISIS DEL PROBLEMA El problema fundamental con el que se enfrenta un analista de sistemas es interpretar las necesidades del usuario y las aspiraciones del producto a desarrollar, y transformar la descripción informal disponible en un conjunto de hechos, es decir, lo que se conoce como la Especificación de Requisitos de la Aplicación[13]. Para ello, se utiliza el Lenguaje de Modelado como UML [12]. En este epígrafe del documento se intentará llegar a un entendimiento completo de las necesidades y requerimientos del proyecto Diagrama Conceptual de Clases Se utilizará una perspectiva conceptual, reflejando los conceptos del dominio del problema a abordar, sin pensar en la solución final del mismo. De esta forma: Una clase representa un concepto relevante existente en el dominio del problema. Un atributo representa una propiedad relevante propia de ese concepto Las asociaciones representan relaciones conceptuales entre los conceptos. 55

67 3.3.2 Glosario de Conceptos Nombre Usuario Cliente SSH Exec SSH Shel SSH Copia SCP Port forwarding Conexión Descripción Usuario de la aplicación GUEFIRA Interfaz gráfico de la aplicación GUEFIRA. Entidad que engloba a otras entidades de menor tamaño y funcionalidad. Utilidad de ejecución de comandos SSH que es llamada y requerida por el Cliente SSH. Utilidad de ejecución de Terminal remota SSH, que está a disposición de las llamadas procedentes del Cliente SSH. Utilidad de envío y recepción de fichero a través del canal seguro SSH. Utilidad que está a disposición de las llamadas procedentes del Cliente SSH. Utilidad de redireccionamiento de puertos, que es llamada mediante el Cliente SSH cuando se requiere. Lleva a cabo toda la lógica de establecimiento de sesiones SSH y levantamientos de canales cifrados. Toda utilidad que requiera realizar una conexión SSH necesitará heredar esta funcionalidad 56

68 Resultados Presenta de forma homogénea los resultados como consecuencia de la ejecución de un comando, la apertura de un terminal o la copia de un fichero. En definitiva resultados procedentes de cualquier conexión SSH Modelo de Casos de Uso Identificando a los actores que pueden encontrarse en el sistema, se llega a la identificación de los casos de uso que se pueden dar en este escenario. En este epígrafe procederemos a la descripción detallada del caso de uso que se presenta. Escenario: Está representado por la aplicación cliente SSH. Es el propio sistema que responderá a los estímulos provocados por el actor. Actor: Un único actor que corresponde al Usuario de la aplicación cliente SSH GUEFIRA. Figura 9. Diagrama Casos de Uso 57

69 Descripción Casos de Uso En el diagrama anterior se representa la relación que tiene el único actor con respecto al sistema que se propone. A continuación describiremos cada uno de los casos de uso que se pueden dar para el actor Usuario. Ejecución de Shell SSH: El actor principal abre un terminal de comandos remoto desde la aplicación cliente hacia la máquina servidora remota. Ejecución de comandos SSH: El Usuario GUEFIRA ejecuta comandos UNIX sobre una sesión SSH previamente establecida. Port forwarding: El Usuario GUEFIRA establece una redirección de puertos para dirigir el tráfico TCP que crea oportuno. Copia de archivos SCP: El actor principal hace uso de la utilidad SCP de la aplicación para la copia de ficheros a través del canal SSH. Mostramos a continuación una descripción detallada de los Casos de Uso que se han explicado. Nótese, que en la descripción detallada que se realizará de cada Caso de Uso, no se han reflejado todos los posibles escenarios que se pueden dar, debido a que puede llegar a ser repetitivo. Todos los Casos de Uso que se exponen a continuación describen el Escenario Principal [12] excepto el Caso de Uso Ejecución de comandos SSH, en el que se ha representado un Escenario Secundario [12] para que el lector de este documento pueda comprender la diferencia entre los escenarios Principal y Secundario. 58

70 1. Ejecución de Shell SSH Caso de Uso Ejecución de Shell SSH Actor Usuario GUEFIRA Propósito Abrir un terminal SSH remoto desde la aplicación cliente El Usuario GUEFIRA ejecuta la aplicación Java, introduce parámetros de conexión, la lógica de la aplicación cambia devolviendo una Shell remota al usuario principal. Tipo Escenario primario y Caso de Uso esencial Curso Típico de Eventos Acción del Actor 1. El usuario inicia la aplicación 3. El usuario inicia la utilidad SSH SHell 5. El usuario introduce nombre de usuario, nombre de host remoto y contraseña. 8. El usuario sale de la aplicación. Respuesta del Sistema 2. La aplicación muestra el logo de GUEFIRA y título de bienvenida 4. El sistema muestra información para la introducción de nombre de usuario y host, y la contraseña 6. El sistema comprueba que el usuario introducido existe y la contraseña corresponde a ese usuario en el nombre de host remoto. 7. El sistema muestra un terminal procedente del host remoto introducido. 9. El sistema se cierra. 59

71 2. Ejecución de comandos SSH Caso de Uso Actor Propósito Ejecución de comandos SSH Usuario GUEFIRA Ejecución de comandos SSH sueltos en bajo una sesión SSH El Usuario GUEFIRA ejecuta la aplicación Java, introduce parámetros de conexión y comandos a ejecutar, la lógica de la aplicación cambia devolviendo el resultado la ejecución de cada comando. Tipo Escenario primario y Caso de Uso esencial Curso Típico de Eventos Acción del Actor 1. El usuario inicia la aplicación 3. El usuario inicia la utilidad Exec SSH 5. El usuario introduce nombre de usuario, nombre de host remoto, contraseña y comando a ejecutar. Respuesta del Sistema 2. La aplicación muestra el logo de GUEFIRA y título de bienvenida 4. El sistema muestra información para la introducción de nombre de usuario y host, y la contraseña y comando a ejecutar 6. El sistema comprueba que el usuario introducido no existe. 7. El sistema muestra un mensaje de error de conexión debido a los parámetros introducidos. 8. El sistema vuelve al estado anterior, preparado para una nueva conexión. Paso 3 60

72 3. Port forwarding Caso de Uso Port forwarding Actor Usuario GUEFIRA Propósito Establecimiento de redireccionamiento de puertos El Usuario GUEFIRA ejecuta la aplicación Java, introduce parámetros de conexión y comandos a ejecutar, la lógica de la aplicación cambia estableciendo redirección de puertos según los parámetros introducidos. Tipo Escenario primario y Caso de Uso esencial Curso Típico de Eventos Acción del Actor 1. El usuario inicia la aplicación 3. El usuario inicia la utilidad Port forwarding 5. El usuario introduce nombre de usuario, nombre de host remoto, contraseña. Además introduce puerto local y remoto..9. El usuario finaliza el redireccionamiento de puertos. Respuesta del Sistema 2. La aplicación muestra el logo de GUEFIRA y título de bienvenida 4. El sistema muestra información para la introducción de nombre de usuario y host, y la contraseña. Muestra campo para la introducción de puerto local y de puerto remoto. 6. El sistema comprueba que el usuario introducido existe y la contraseña corresponde a ese usuario en el nombre de host remoto. 7. El sistema realiza con éxito la redirección de puertos y muestra un mensaje de establecimiento de Port forwarding. El sistema queda bloqueado en este estado. 10. El sistema vuelve al estado inicial. Paso 4 61

73 4. Copia de archivos SCP Caso de Uso Copia de archivos SCP Actor Usuario GUEFIRA Propósito Copia de ficheros haciendo uso del canal cifrado seguro SSH El Usuario GUEFIRA ejecuta la aplicación Java, introduce parámetros de conexión y elige enviar o recibir archivos. La lógica de la aplicación cambia copiando o recibiendo archivos según la elección del Usuario. Tipo Escenario primario y Caso de Uso esencial Curso Típico de Eventos Acción del Actor 1. El usuario inicia la aplicación 3. El usuario inicia la utilidad de copia de ficheros mediante SCP 5. El usuario introduce nombre de usuario, nombre de host remoto, contraseña. Además elige la opción de recibir fichero e introduce el nombre del fichero que desea recibir.9. El usuario finaliza la utilidad. Respuesta del Sistema 2. La aplicación muestra el logo de GUEFIRA y título de bienvenida 4. El sistema muestra información para la introducción de nombre de usuario y host, y la contraseña. Muestra la posibilidad e enviar o recibir ficheros. 6. El sistema comprueba que el usuario introducido existe y la contraseña corresponde a ese usuario en el nombre de host remoto. 7. El sistema copia con éxito el archivo. 10. El sistema se cierra. 62

74 3.3.4 Otros requerimientos El sistema debe cumplir las siguientes restricciones: Será una aplicación programada en Java, basada en el modelo servidor. Deberá compilarse sin errores y ejecutarse con la versión (JSR 216) de la especificación personal profile de Java MICRO EDITION J2ME CDC. Se utilizarán las librerías JSch para J2ME que implementen el protocolo SSH-2 en java puro. El servidor SSH será OpenSSH Daemon versión 8, escuchando en el puerto TCP número 22. El representante o Proxy para permitir la redirección de puertos para aplicaciones Web (http), será Squid en su versión 2.6 STABLE14, escuchando peticiones en el puerto TCP número La arquitectura física de la aplicación será: o Modelo cliente servidor. Los usuarios se conectarán al sevidor SSH mediante su puerto TCP número 22. o Utilización del protocolo SSH-2. o Como consecuencia de los puntos anteriores, conexión vía protocolo TCP/IP. La aplicación debe ser realizada por una única persona, su autor Antonio Pascual Moreno, y supervisada por el director de proyecto Mario Castro Ponce. La fecha tope de entrega del proyecto será en Junio de A partir de las necesidades adquiridas y descritas en el epígrafe anterior, se hace necesario representar la arquitectura de paquetes y clases que tendrá la aplicación. A partir de la adquisición de conocimiento del problema a abordar se llega a la especificación de las clases, las dependencias y relaciones entre las mismas. 63

75 3.3.5 Diagrama de paquetes Figura 10. Diagrama de paquetes del proyecto GUEFIRA El proyecto consta de estos tres paquetes Java. Dos de ellos han sido desarrollados por terceras personas como se ha comentado. com.jcraft.jsch hace referencia a todas las clases Java para la implementación del protocolo SSH. Estas clases hacen uso de las clases criptográficas que se proveen en el paquete org.bouncycastle. A su vez estos paquetes son requeridos por la aplicación cliente SSH, cuyas clases están contenidas en el paquete sshapp. 64

76 3.4 IMPLEMENTACIÓN A continuación se describe la implementación de las funcionalidades que se han descrito en el análisis (modelo de casos) mediante las clases que contiene el paquete correspondiente a la aplicación. Se han omitido los paquetes no desarrollados por el autor puesto que no es necesario su descripción para el entendimiento de la lógica del cliente SSH. Una vez estudiado los requisitos funcionales del sistema, mediante el análisis realizado en el epígrafe anterior, estamos en disposición de comenzar a desarrollar las diferentes clases que compondrán el modelo de análisis, para tener así en mente las necesidades y funcionalidades del software. El diagrama de clases expuesto en la fase de análisis era como ya se dijo una visión conceptual del problema que se aborda, por lo que no tiene por que guardar exacta relación con las clases que se implementan. Las modificaciones de las clases se hacen visibles en la Fase de Implementación del proyecto, donde tendremos que tomar decisiones que afecten al diseño de las clases que se ha propuesto. El objetivo de todo buen analista es determinar las clases a implementar en el estudio de las especificaciones del cliente y que estas no necesiten ser modificadas en ninguna otra parte del proyecto, aunque esta tarea resulta bastante difícil y requiere de una amplia experiencia. Nótese que el ciclo que sigue la implementación de código en la herramienta de desarrollo Eclipse IDE, es la siguiente: 1. Implementación 2. Compilación 3. Ofuscación 4. Creación de las clases 5. Empaquetado La implementación es la propia codificación de cada una de las entidades que forma la aplicación. La compilación en Java permite la obtención a partir de las clases codificadas (ficheros.java) las clases en bytecode (ficheros.class). 65

77 La ofuscación de código mediante el uso de la herramienta Proguard 4.1, supone la modificación de las clases a partir de los ficheros.class. (ver capítulo 3 epígrafe 3.2.4, el concepto de ofuscación), para optimizar el rendimiento del programa en tiempo de ejecución entre otras cosas. Obtenemos las clases ofuscadas, y se proceden al empaquetamiento. El empaquetamiento de la aplicación GUEFIRA PROJECT es un fichero JAR, que será el que pueda introducirse en cualquier dispositivo móvil que presente un intérprete de Java. En este epígrafe iremos comentando las partes de código que representan la lógica de la aplicación. Cómo se establecen las conexiones y cómo se envían y reciben los datos con los que se trabaja etc Clases recogidas en el paquete sshapp. GuefiraMain.class Esta clase es la que permite la ejecución de todos los hilos de conexión. Desde esta clase se lanzan todas las posibles configuraciones y utilidades para conectarse contra el servidor SSH. Desde la pantalla principal se ofrece al usuario los principales datos de conexión. Estos datos son presentados al usuario mediante tres pestañas: Pestaña de conexión Desde la cual se ofrece la posibilidad de incluir la información relativa al usuario de la cuenta remota, el nombre de host del servidor contra el que se quiere realizar la conexión, el puerto SSH por el que va a estar escuchando peticiones el servidor y la contraseña asociada a la cuenta del usuario en la máquina remota. Adicionalmente, se presenta la posibilidad de introducción por parte del usuario de datos de conexión requeridos para la ejecución de la utilidad de redireccionamiento de puertos, tales como el puerto por el que el Proxy va a estar escuchando peticiones y el puerto local por el que se va a enviar cualquier conexión TCP que se realice desde la PDA o dispositivo móvil hacia el servidor SSH. 66

78 Pestaña SCP Ofrece al usuario datos de conexión para el envío y recepción de archivos sobre el túnel cifrado SSH. Los botones de archivo local y remoto hacen referencia a los archivos que residen en la máquina local y remota respectivamente. La visualización de los archivos de la máquina local no tiene ningún misterio, pero la visualización para su posterior elección de aquellos ficheros que se quieren copiar desde la máquina servidora hasta la máquina en donde reside la aplicación GUEFIRA PROJECT es algo más compleja. Para ello se requiere de una conexión cifrada SSH a la máquina remota y para de esa forma obtener los archivos que se alojan en el servidor. La aplicación muestra siempre una estructura de ficheros y directorios en árbol, partiendo siempre del directorio /home/ de la cuenta de usuario en la máquina servidora. Dependiendo de si se quiere recibir o enviar archivos desde o hacia la máquina servidora se emplean las opciones de Download o Upload respectivamente. Pestaña Exec Desde esta pestaña se elige la utilidad que se quiere utilizar para la conexión. La ejecución de cada una de estas utilidades conlleva la creación de nuevas clases para el manejo de la lógica de conexión en cada caso. Figura 11. Pestaña Conexión Figura 12. Pestaña SCP 67

79 ShellSSH.class Esta clase permite la apertura de un terminal remoto SSH, permitiendo manejar la cuenta remota del usuario alojada en la máquina servidora desde el dispositivo móvil mediante la ejecución de la aplicación cliente GUEFIRA. Todas las conexiones SSH, requieren del establecimiento de una sesión SSH. La secuencia de apertura de un canal SSH mediante el uso de métodos proporcionados por la librería JSch es: 1. Creación de la clase contenedora JSch. 2. Creación de la sesión y conexión a nivel de sesión. 3. Apertura del canal, configuración y conexión. ShellSSH SSHShell = new ShellSSH(user, host, port, passwd, sshell.getdisplay()) Constructor de la clase ShellSSH //Creación de la clase contenedora JSch JSch jsch = new JSch(); int port = 22; //Establecimiento de la sesión mediante usuario nombre de host y número de puerto session = jsch.getsession(user, host, port); //Instancia de la clase abstracta MyUserInfo UserInfo ui = new MyUserInfo(); session.setuserinfo(ui); //Conexión de la sesión session.connect(); //Creación del canal en modo ejecución de comandos channel = session.openchannel("shell"); ((ChannelExec)channel).setCommand(commandField.getText()); InputStream in = channel.getinputstream(); OutputStream out = channel.getoutputstream(); ((ChannelExec)channel).setErrStream(System.err); //Conexión del canal channel.connect(); 68

80 Establecimiento de una sesión SSH Analizando el código y fijándonos en la creación de la clase session de la librería JSch, observamos que para crear la sesión debemos proveer al método jsch.getsession() un nombre de usuario un host y un número de puerto. El nombre de usuario user en el ejemplo, haría referencia al nombre de usuario cuya cuenta existe en la máquina remota host. La sesión se establecería hacia un puerto de la máquina remota port, en el que necesariamente debería haber alguna aplicación escuchando. En este caso, al ser una conexión SSH, debería de existir un servidor escuchando en la dirección IP que hace referencia la variable host en el puerto determinado por la variable port. En el código de arriba, el número de puerto es el 22, el estándar según el IETF (ver Capítulo 2) para las conexiones SSH. Para seguir las convenciones de la arquitectura del protocolo Secure Shell con respecto a la capa de autenticación de usuario (User Authetication Protocol Layer ver Capítulo 2), la librería JSch implementa una clase donde se configura la información del usuario para la autenticación de este con el servidor. Más adelante comentaremos dicha clase Java. Siguiendo con el código, la sesión se establece mediante el método connect(). Para otras aplicaciones que no requieran el envío de comandos UNIX y la recepción de sus resultados, no es necesario el establecimiento de un canal, puesto que la sesión en sí permite el cifrado del resto de información que viaje entre el socket del cliente y el socket (ver Conexiones TCP Capítulo 2) del servidor. Sin embargo dado que la clase SSHExec provee un interfaz de ejecución de comandos SSH es necesario la apertura de ese canal. Esta librería en concreto permite la ejecución de comandos SSH o la apertura de una terminal remoto (Shell) en la máquina destino. Esta clase se encarga de la ejecución de comandos. Para eso el método a utilizar es session.openchannel("exec"); Mediante el método setcommand() que provee la clase Channel enviamos el comando UNIX a la máquina servidora remota. Recepción de datos La recepción de los datos se realiza mediante la clase InputStream que provee el paquete java.io del JDK. Abriendo un InputStream hacia el canal de entrada SSH, conseguimos que todos los datos cifrados enviados del servidor SSH a la aplicación sean recogidos y almacenados en un buffer. 69

81 byte tmp[] = new byte[1024]; do { int c = in.read(); if(c == -1) break; resultbox.append((new Character((char)c)).toString()); } while(true); El resultado almacenado mediante la clase InputStream, se imprime a un ResultBox tal y como vemos en el código de la parte superior. Es la propia clase JSch la que se encarga de cifrar los datos cuando son enviados hacia el servidor, y de descifrarlos al ser recibidos en la aplicación cliente. Desde esta clase se hace uso de métodos proporcionados por la librería SWT del entorno eclipse que permite la implementación de pantallas gráficas para la recogida y v de eventos de entrada salida por parte del usuario y visualización de otra serie de widgets. Figura 13. Pestaña Exec 70

82 Para mantener informado al usuario del avance y estado de la conexión que está realizando, y teniendo en cuenta que la distancia física de la máquina donde reside el servidor SSH influye en los tiempos de conexión, se ha implementado una barra de progreso que indica el porcentaje de avance de la conexión. Para la utilización de las librerías SWT se ha tenido que tener en cuenta las restricciones en cuanto al hilo del interfaz gráfico que implementa (Ver epígrafe Entorno de desarrollo librerías gráficas SWT de eclipse ). display.asyncexec(new Runnable() { public void run() { if (bar.isdisposed ()) return; bar.setselection(i[0]); } }); Para ello se ha hecho uso del método display.asyncexec() que permite la ejecución de la lógica de conexión ya explicada con anterioridad en un hilo independiente del hilo que permite la implementación del código gráfico relativo a la barra de progreso. Desde la clase principal GuefiraMain, se recogen los datos obtenidos por la ejecución del código de conexión implementado por la clase ShellSSH. Y éstos son presentados al usuario mediante la clase principal. La gestión de la contraseña para la autenticación al servidor SSH mediante nombre de host y contraseña, es enviada mediante la clase interna MyUserInfo. 71

83 Figura 14. Terminal SSH Figura 15. Terminal SSH Clase ExecSSH.class Esta clase muy parecida a ShellSSH.class. La única diferencia estriba en que en vez de de la apertura de un terminal remoto, esta clase implementa la ejecución directa comandos SSH sobre el túnel cifrado. JSch jsch = new JSch(); int port = 22; session = jsch.getsession(user, host, port); UserInfo ui = new MyUserInfo(); session.setuserinfo(ui); session.connect(30000); Channel channel=session.openchannel("exec"); El método openchannel que proporciona la clase session, en este caso abre un ejecución exec como se ve en el código superior, en vez de Shell para la apertura de un terminal remoto que se describía en la clase ShellSSH. 72

84 Clase Scp.class Scp es una herramienta que proporciona el protocolo SSH para la copia de ficheros (ver Capítulo 2), que se ha querido incorporar a las utilidades del proyecto GUEFIRA. Permite el envío y recepción de archivos mediante la seguridad que provee el protocolo. Para la implementación de esta clase, el establecimiento de la conexión (Sesión y apertura de Canal cifrado) es el mismo que se ha comentado hasta ahora. String command = "scp -f " + sourcefilename; Channel channel = session.openchannel("exec"); ((ChannelExec) channel).setcommand(command); String version = session.getclientversion(); Recepción de archivos El comando que permite la recepción de archivos es scp -f, que como se describe en el código superior se introduce en el canal seguro junto con el archivo que se quiere recibir. La variable sourcefilename hace referencia al nombre local que se le quiere dar al archivo recibido. Como no puede ser de otra manera para la recepción del archivo se hace necesario instanciar la clase InputStream que provee el paquete java.io del JDK de java. Figura 16. Estructura de directorio Remoto 73

85 String prefix=null; if(new File(destFilename).isDirectory()) { prefix=destfilename+file.separator; } InputStream in = channel.getinputstream(); channel.connect(); byte[] buf=new byte[1024]; buf[0]=0; out.write(buf, 0, 1); out.flush(); while(true) { int c=checkack(in); if(c!='c') { break; } // read '0644 ' in.read(buf, 0, 5); long filesize=0l; while(true) { if(in.read(buf, 0, 1)<0) { // error break; } } if(buf[0]==' ')break; filesize=filesize*10l+(long)(buf[0]-'0'); String file=null; for(int i=0;;i++) { in.read(buf, i, 1); if(buf[i]==(byte)0x0a) { file=new String(buf, 0, i); break; } } // enviar '\0' buf[0]=0; out.write(buf, 0, 1); out.flush(); System.out.println("ok antes de output"); 74

86 // leer el contenido de lfile fos=new FileOutputStream(prefix==null? destfilename : prefix+file); int foo; while(true) { if(buf.length<filesize) { foo=buf.length; } else { foo=(int)filesize; } foo=in.read(buf, 0, foo); } if(foo<0){ // error break; } fos.write(buf, 0, foo); filesize-=foo; if(filesize==0l) break; fos.close(); fos=null; if(checkack(in)!=0) { return false; } // send '\0' buf[0]=0; out.write(buf, 0, 1); out.flush(); } Para conocer si existen más datos en el canal para recibir o no, utilizamos un método llamado checkack. Si el método read de la clase InputStream nos devuelve un -1 entonces no hay más datos que recibir. Por el contrario si obtenemos un 0 hay información. Debemos saber la estructura de directorios para colocar el archivo recibido. Esto se realiza mediante el método isdirectory(), que nos indica el directorio en el que queremos almacenar el fichero. 75

87 Para la elección del archivo remoto que se quiere copiar en la máquina cliente, se ha implementado un interfaz que permite la visualización de la estructura de directorios de la cuenta de usuario remota. /home/username/ como nodo raíz. (Ver figura 16) Envío de archivos La otra posibilidad es la de enviar archivos desde el dispositivo móvil hacia el servidor, haciendo uso de la utilidad SCP de GUEFIRA. En este caso seleccionaríamos la opción de Upload en la pestaña SCP del interfaz de la aplicación. Seleccionaríamos el archivo que se quisiera enviar mediante la pulsación sobre el botón A.Local y automáticamente la aplicación lo enviaría al directorio /home/username/ del servidor destino mediante el canal cifrado SSH. La diferencia en la implementación del código en el envío de archivos reside únicamente en el cambio del comando SSH que se debe ejecutar. command = "scp -p -t " + destfile; Channel channel = session.openchannel("exec"); Clase PortForwarding.class Esta clase permite la redirección de puertos (ver Capítulo 2). La conexión se establece tal como se ha explicado, sin embargo, este es un ejemplo que no requiere la apertura del canal cifrado, puesto que no es necesario el acceso a una cuenta de usuario en la máquina remota. Esto es debido a que mediante el establecimiento de la sesión y la configuración de los puertos locales y remotos las aplicaciones TCP sobre estos puertos son las que enviarán o recibirán la información. Como no es necesaria la ejecución de comandos en la Shell remota, tampoco es necesaria la apertura del canal. 76

88 int puertolocal = Integer.parseInt(puertoLField.getText()); int puertoremoto = Integer.parseInt(puertoRField.getText()); session.setportforwardingl(puertolocal, host, puertoremoto); String portfl[] = session.getportforwardingl(); Sobre la clase Session se establece la redirección. Para ello es necesario el puerto TCP local del dispositivo móvil el cual se conectará al puerto TCP remoto del servidor. Y por supuesto el nombre de host en el que se realizará la redirección. En el código superior se muestra el establecimiento de un Port forwarding local, mediante el método session.setportforwardingl. Como ya se ha visto la sintaxis SSH para el redireccionamiento de puertos es la siguiente: $ ssh -L puerto_local:maquina_destino:puerto_destino Sintaxis comando ssh port forwarding local Si nos fijamos el método session.setportforwardingl(puertol,host,puertor) y la sintaxis SSH tienen muchas cosas en común. El método permitirá entonces que todas las aplicaciones que envíen información por el puerto TCP puertolocal se dirijan al puerto TCP puertoremoto de la máquina destino con dirección IP host. Como se trata de Port forwarding Local, la máquina destino debe ser el propio dispositivo móvil, la máquina local localhost, que se conectará al puerto destino de la máquina destino host. Si el número de puerto local es por ejemplo 8080 puertolocal, y el puerto destino puertoremoto es el 3128, todas las aplicaciones que envíen desde el dispositivo móvil información por el puerto 8080, serán recibidas en el puerto 3128 de la máquina destino host. 77

89 En las figuras superiores observamos como se realiza una redirección de puertos desde GUEFIRA. Pero como ya se ha explicado, para disfrutar de aplicaciones TCP seguras se necesitan dos pasos. 1. Configuración de la aplicación local TCP en el dispositivo móvil para que se conecte por el puerto local en este ejemplo Aplicación remota configurada para que esté escuchando la información enviada al puerto remoto TCP, en este ejemplo el número de puerto En el Anexo II se explica la configuración del navegador para PDA s sobre Windows Mobile Mínimo, desarrollado por el equipo de Mozilla Firefox. Y en el anexo IV se especifica la configuración de un servidor Proxy, representante, Squid en su versión 2.6 STABLE14, para la resolución de peticiones bajo el protocolo Http, en la máquina remota. Cuando el usuario de GUEFIRA decide terminar la redirección de puertos, lo único que debe de hacer es pulsar el botón de finalizar en el cuadro de diálogo representado en la figura x. Figura 17. Establecimiento de Port Forwarding 78

90 3.4.2 Clases pertenecientes al paquete com.jcraft.jsch Como resulta evidente, en este documento no se pretende explicar toda la API del paquete Java del equipo JCRAFT, pero si se hace necesaria la explicación en detalle de una serie de clases que están íntimamente relacionadas con las clases desarrolladas para el proyecto GUEFIRA en el paquete sshapp. Interfaz UserInfo UserInfo, es un interfaz de las librerías JSch para la implementación del protocolo SSH, que permite encapsular los datos del usuario de la aplicación cliente SSH. Este interfaz permite hacer cobertura de la arquitectura del protocolo respecto a la capa de autenticación de usuario (User Authentication Protocol Layer). En la aplicación desarrollada se hereda de este interfaz mediante la creación de una clase interna (Inner Class) denominada MyUserInfo.class. public class MyUserInfo implements UserInfo, ActionListener { Button yesuser; Button nouser; public MyUserInfo() { yesuser = new Button("Si"); nouser = new Button("No"); } public String getpassword() { return passwd; } 79

91 public boolean promptyesno(string str) { dialog = new Shell (display,swt.resize); MessageBox messagebox = new MessageBox(dialog, SWT.YES SWT.NO SWT.ICON_WARNING); messagebox.setmessage(str); int res = messagebox.open(); if(res == SWT.YES) { //dialog.dispose(); return true; } else { //dialog.dispose(); return false; } } public boolean promptpassword(string message) { return passwd!= null; } public String getpassphrase() { return null; } public boolean promptpassphrase(string message) { return true; } 80

92 Los métodos getpassword(), getpassphrase() definen la gestión de la contraseña por el servidor. Mediante la clase session, se utilizan estos métodos para obtener la contraseña del cliente SSH y enviarla al servidor SSH. Si la contraseña del cliente no está protegida en el servidor por una frase de paso (ver Capítulo 2) entonces únicamente se hace uso del método getpassword(), en caso contrario se hace uso del segundo método. En cuanto a los métodos promptpassword(string message) y promptpassphrase(string message) son utilizados para mostrar en la interfaz de usuario los mensajes que provienen del servidor según si la autenticación del cliente posee una contraseña con frase de paso o no. El método promptyesno(string str), es un método que muestra el mensaje enviado por el servidor SSH, cuando la aplicación cliente GUEFIRA no reconoce al servidor como una entidad de confianza. Es decir, cuando en el proceso de intercambio de claves, el cliente no tiene ninguna que corresponda al servidor al que se va a conectar. Este mensaje siempre se mostrará si el cliente SSH es la primera vez que se quiere conectar a ese determinado servidor. Figura 18. Mensaje Warning 81

93 Pulsando en Sí se acepta la nueva clave que corresponde con ese servidor SSH. Si por el contrario no se acepta, la aplicación muestra un error de conexión. 82

94 3.5 CONSIDERACIONES DE SEGURIDAD EN GUEFIRA Sin embargo, cómo sabemos que realmente la información va cifrada? Si es cierto, que la aplicación implementa todas las funcionalidades requeridas, puesto que mediante el interfaz de usuario podemos comprobar los resultados. Por ejemplo, al ejecutar el comando ls -l la aplicación devuelve un listado con de todos los ficheros de un determinado directorio, con información de hora de creación y usuario que lo creó (ver figura x). Pero esa información, va cifrada por la red? La manera de comprobarlo es mediante una herramienta denominada Sniffer de Red Sniffer de Red Esta herramienta es un programa de captura de paquetes de red. Permite la captura de tramas enviadas mediante varios protocolos, (TCP,IP,ARP,DNS etc ). Generalmente se utiliza para gestionar la red con una finalidad administrativa, aunque también puede ser utilizada con fines maliciosos. Típicamente, por topología de red y necesidad de material, el medio de transmisión es compartido por varias computadoras y dispositivos de red, lo que hace posible que un ordenador capture tramas de información no destinadas a él. Para conseguir esto, el sniffer pone la tarjeta de red o NIC en un estado conocido como modo promiscuo en el cual en la capa de enlace de datos no son descartadas las tramas no destinadas a la dirección física, MAC de la tarjeta. De esta manera se puede obtener (sniffar) todo tipo de información de cualquier aparato conectado a la red, como contraseñas, , conversaciones de chat o cualquier otro tipo de información personal. Los usos de esta herramienta se pueden listar de la siguiente manera: Analizar problemas de red Detección de tentativas de intrusión Obtención de información sobre intrusiones en la red Creación de informes de estadísticas de la red Depuración de comunicaciones cliente servidor Depuración de implementaciones de protocolos 83

95 Para nuestro propósito, utilizaremos esta herramienta según sus dos últimos usos aquí especificados; Depuración de comunicaciones cliente servidor y depuración de implementaciones de protocolos. Observaremos la comunicación que se establece entre la aplicación cliente GUEFIRA y el servidor remoto, y estudiaremos si realmente la implementación del protocolo Secure Shell es correcta viendo si la información esta cifrada o por el contrario viaja en claro por la red Ejemplos de estudio Acceso remoto Telnet En este epígrafe, vamos utilizar una de las herramientas incluidas en los denominados RCommands, Telnet. Vamos a poner de manifiesto la inseguridad que presentan mediante el acceso remoto a un servidor Telnet escuchando en el puerto 23. Para este ejemplo nos conectaremos desde una estación de trabajo mediante la herramienta Putty, a una máquina remota que está ejecutando un servidor Telnet. Configuración de la máquina remota de trabajo donde se aloja el servidor Telnet Figura x. Comando ifconfig 84

96 Como se observa en la figura x, el servidor SSH está alojado en una máquina cuya tarjeta de red inalámbrica wlan0, tiene por dirección IP la Está es la dirección del servidor Telnet que se requerirá para la conexión. El puerto TCP al que se conectará nuestro cliente es el estándar definido por el protocolo Telnet, el número 23 Observamos ahora la configuración de la estación de trabajo donde se aloja la aplicación cliente. Configuración de la máquina cliente Figura 19 Configuración máquina cliente Como dirección IP origen la Ambas máquinas forma una red local, las direcciones IP son direcciones de clase C ámbito privado, cuya puerta de enlace en este ejemplo un router, tiene por dirección IP la

97 La herramienta que se utilizará para el acceso remoto al servidor Telnet es Putty, una herramienta que permite la utilización de protocolos como Telnet, Rlogin o SSH. En ese ejemplo utilizaremos Telnet. Figura 20. Configuración de conexión al servidor Telnet del la herramienta Putty Observamos que la petición de conexión se va a realizar a la dirección IP de la máquina remota, Nos conectamos y se requiere la contraseña de usuario de la cuenta que está alojada en el servidor Telnet. La contraseña para el usuario luperuma con el cual nos vamos a logear, es thrawn. En este punto es importante tener en cuenta cual es la contraseña. Usuario: luperuma Contraseña: Thrawn 86

98 Como se puede ver en la figura x, el propio servidor Telnet nos oculta en el momento de la autenticación la contraseña que hemos introducido. El servidor NO muestra la contraseña Figura 21. Terminal de acceso remoto de la herramienta Putty Durante todo el proceso de autenticación y acceso a la cuenta de usuario del servidor Telnet, se ha utilizada el sniffer de red para la captura de tramas y poder observar qué información se ha transmitido entre la aplicación Putty y el servidor Telnet. Notese para no perderse en la explicación la siguiente información. Máquina servidora Telnet con dirección IP Máquina cliente con dirección IP En la figura 22, podemos observar las diferentes tramas capturadas ordenadas en secuencia. Si observamos el protocolo del que hacen uso vemos que es TELNET, y que la fuente y destino de la información son las direcciones IP mencionadas. 87

99 Número de paquete Figura 22. Captura de paquetes TELNET mediante la herramienta Wireshark 88

100 Si observamos con detenimiento la parte inferior de la herramienta Wireshark podemos obtener algo de la información que se ha estado enviando por la red. o En la Paquete número 44 observamos lo siguiente: Letra T Petición de Contraseña Paquete número 44 Nos muestra la salida del servidor en el momento de la autenticación del usuario. La petición de la contraseña (Password) de la cuenta en el servidor a la que queremos acceder. Justo antes de la petición de la contraseña, la herramienta Wireshark ha capturado una letra, la T. o Paquete número 46 Letra h En la trama 46 vemos la letra h. 89

101 o Paquete número 48 Letra r En este paquete 48 vemos la letra r. o Paquete número 50 Letra a En la 50 la letra a. o Paquete número 52 Letra w En la 52 la letra w. 90

102 o Paquete número 54 Letra n En la 54 la letra n. Hemos encontrado la contraseña para acceder a una cuenta de usuario a la que en un principio no teníamos acceso. Únicamente mediante la escucha del canal de comunicaciones y la captura de paquetes. Cualquier persona con intenciones poco éticas podría utilizar esta contraseña a su favor. Pero no sólo nos conformamos con el robo de la contraseña, sino que Telnet también nos muestra la configuración del servidor que se ejecuta en la máquina remota. Figura 23. Captura del paquete con información relativa al servidor Telnet 91

103 Nos indica que es una máquina linux, que corre Ubuntu con versión del kernel Nos muestra además el último acceso al servidor y desde qué máquina cliente. Hemos dejado en evidencia la inseguridad del protocolo Telnet. Esto como ya se explicó en el Capítulo 2 es debido a que este protocolo no ofrece encriptación de los datos, y estos viajan en claro por la red. Concluimos por consiguiente, que Telnet no es una buena opción para el acceso remoto a cuentas de usuario. 92

104 Acceso remoto (SSHExec) GUEFIRA Vamos a realizar la misma operación que en el ejemplo anterior, pero utilizando la aplicación cliente GUEFIRA con soporte para el protocolo SSH. Aclaramos de forma somera las configuraciones de la máquina donde se aloja el servidor SSH y del dispositivo donde reside la aplicación cliente en estudio. Configuración del dispositivo donde se aloja el cliente SSH Como se observa en la figura 24, la PDA en la que está corriendo el cliente GUEFIRA tiene una tarjeta de red inalámbrica con dirección IP Será ésta la dirección mediante la que se conectará al servidor SSH. A la propia aplicación cliente, el sistema operativo le asignará un puerto TCP no reservado para permitir la conexión. Figura 24. Configuración de red de la PDA Ambas máquinas forma una red local, las direcciones IP son direcciones de clase C ámbito privado, cuya puerta de enlace en este ejemplo un router, tiene por dirección IP la

105 Antes de abrir una Shell desde el cliente, ejecutamos la herramienta sniffer, en este caso la que viene en el repositorio de paquetes del sistema operativo UBUNTU Wireshark, como super usuario UNIX (root) con permisos de administrador. Seguidamente ejecutamos el comando de apertura de Shell en el cliente y observamos la captura de paquetes obtenida por el sniffer. En la figura 25 podemos ver cómo la conversación entre cliente y servidor hace uso del protocolo SSH2. Describimos los paquetes capturados más importantes. o El paquete número 6 nos indica la versión del servidor SSH que se está ejecutando. o El paquete número 12 inicia el intercambio de claves. En este caso la clave del servidor, si nos fijamos en la IP de origen del paquete es la que corresponde al servidor y la de destino la del cliente o El paquete número 14 la autenticación mediante intercambio de clave del cliente en esta ocasión, siendo el origen del paquete el cliente y el destino el servidor. o El paquete número 16 indica el método de intercambio de clave, en este caso Diffie-Hellman. o Si observamos el paquete número 18 y 24 podremos saber que el servidor o ha cambiado su clave de intercambio o que el cliente es la primera vez que se conecta a este servidor. El paquete 24 nos indica que el cliente ha tenido que aceptar la nueva clave del servidor. o El paquete número 26 es un paquete de datos, y como se observa, el sniffer de red indica que ha capturado un mensaje cifrado. o Si observamos el paquete 17, por ejemplo, vemos en la parte inferior de la herramienta el puerto de origen de envío de la paquete y el puerto destino. Como ya dijimos, el destino en este caso es el de servidor con número 22 según el estándar del protocolo, y el número de puerto origen es el 4043 el del cliente SSH impuesto por el sistema operativo. Fijándonos en la parte inferior del sniffer WireShark, observamos la información que transportan cada paquete de datos. Podemos observar en la figura 25, que la información es ilegible. Presenta símbolos y letras sin ningún tipo de sentido, es la 94

106 representación en ASCII de la encriptación de los datos realizada por el canal seguro. Podemos concluir por tanto, que nuestra información enviada desde la aplicación GUEFIRA no viaja en claro por la red. Cada paquete está cifrado mediante el protocolo SSH, establecido por la autenticación de claves entre cliente y servidor, tal y como muestra la captura de paquetes del sniffer de red. 95

107 Número de paquete Figura 25. Captura de tramas SSH mediante la herramienta Wireshark 96

108 4 Capítulo 4 PLANIFICACIÓN Y VALORACIÓN ECONÓMICA Guefira Project 97

109 CAPÍTULO 4 PLANIFICACIÓN Y VALORACIÓN ECONÓMICA 4.1 RESULTADOS OBTENIDOS GUEFIRA es una aplicación que ha cumplido con los objetivos propuestos? Vamos a hacer una comparación del los objetivos que se propusieron al principio del desarrollo del proyecto, con respecto a la características y utilidades que proporciona la aplicación final GUEFIRA PROJECT, para observar si los objetivos fijados se cumplen. 1. Ejecución remota de un terminal (Shell), para permitir acceso seguro a máquinas regidas por sistemas operativos Linux. Objetivo cumplido. Además el acceso al servidor remoto puede ser tanto establecimiento de sesión por contraseña, como mediante intercambio de clave pública. 2. Ejecución de comandos SSH desde la aplicación GUEFIRA cliente, hacia una máquina servidor bajo plataforma Linux. ejecutados contra el servidor. Objetivo cumplido. El cliente recoge la ejecución de todos los comandos 3. Envío y recepción de ficheros de forma segura entre la máquina cliente y la máquina servidora mediante canales de encriptación que provee la arquitectura SSH. Objetivo cumplido. La aplicación GUEFIRA permite el envío y recepción de archivos por en canal cifrado. 4. Soporte de redireccionamiento de puertos (Port forwarding) para permitir la creación de túneles seguros de acceso a la red. puertos. Objetivo cumplido. La aplicación GUEFIRA soporta la redirección de 98

110 5. Interfaz de usuario amigable e intuitivo Objetivo cumplido. La conexión hacia el servidor es fácil de realizar, y la introducción de comandos es casi como si se realizara en la máquina remota. Sin embargo, no hay que engañarse, puesto que las características de pantalla que ofrecen estos dispositivos no es igual de manejable que cualquier estación de trabajo de sobremesa. 6. La fecha tope de entrega del proyecto será en Junio de Objetivo cumplido. La entrega del proyecto se realizará en los plazos establecidos. La planificación en el desarrollo del mismo se ha cumplido, aunque las fases de desarrollo se hayan reajustado a lo largo del periodo de ejecución del proyecto y no concuerden con la planificación establecida en un principio, se ha logrado que el conjunto de fechas cuadre para la entrega del proyecto a finales de Junio de

111 4.2 PLANIFICACIÓN Y VALORACIÓN ECONÓMICA En este epígrafe se hará una estimación de costes para el desarrollo del proyecto [19]. Para valorar el coste del proyecto debemos a su vez establecer en primer lugar los perfiles de recursos humanos que deberían haber intervenido en el desarrollo del mismo. Aunque este proyecto ha sido realizado por una única persona, y supervisado por el director de proyecto, vamos a suponer varios perfiles de trabajo que en realidad se necesitan para cumplir el desarrollo del proyecto. Una vez establecidos los perfiles de trabajo, se debe estimar el esfuerzo que han invertido cada uno para la consecución del proyecto. En esta estimación se tomarán medidas de tiempo en función de la planificación que se precisó para la ejecución del proyecto. Por último lugar, y no menos importante, se establecerán otros costes adicionales, tales como el software utilizado (licencias), hardware o costes de otra índole Establecimiento de perfiles de trabajo Definimos los siguientes perfiles de trabajo para el proyecto GUEFIRA: Jefe de proyecto: Es el máximo responsable de la gestión y avance del proyecto. Debe velar por que se cumplan los plazos establecidos y se cumplan los objetivos propuestos. Sólo hay 1 jefe de proyecto. Analistas: Son los encargados de llevar a cabo las fases de análisis y diseño de la aplicación. Establecen los conceptos que posteriormente se implementarán en la fase de desarrollo o implementación Son los encargados de la gestión de la documentación que se va produciendo a lo largo del desarrollo. Se proponen 2 analistas para este proyecto. Programadores: Se encargan de implementar y codificar el diseño realizado por los analistas bajo su supervisión. Son los responsables de las pruebas unitarias realizadas a cada módulo que conforma la aplicación final. Se proponen 3 programadores. 100

112 4.2.2 Estructura de división de trabajo La planificación del proyecto se expone mediante la técnica de diagrama EDT [19] o Estructura de División del Trabajo figura x. Aplicación GUEFIRA GUE01 Gestión proyecto GES01 Fase de Diseño DIS01 Documentación DOC01 Fase de Análisis ANA01 Fase de Implementación IMP01 Modelo Dominio ANA01.1 Codificación IMP01.1 Modelo Casos de Uso ANA01.2 Otros Requerimientos ANA01.3 Modelo Conceptual DIS01.1 Pruebas IMP01.2 Estudio de Tecnologías ANA01.4 Diagrama de Paquetes DIS01.2 Diagrama de Clases DIS01.3 tabla 2. Estructura de División del Trabajo 101

113 4.2.3 Planificación OCT NOV DIC ENE FEB MAR ABR MAY JUN GES01 ANA01.1 ANA01 ANA01.2 ANA01.3 ANA01.4 DIS01.1 DIS01 DIS01.2 DIS01.3 IMP01 IMP01.1 IMP01.2 DOC01 Tabla 3. Diagrama de planificación de proyecto 102

114 4.2.4 Costes Debemos asignar el coste por horas de cada perfil interviniente en el desarrollo del proyecto. PERFIL Jefe de proyecto Analista Programador COSTE / HORA 25 /hora 20 /hora 15 /hora Tabla 4. Costes/hora por cada perfil A continuación mostraremos qué perfiles ejecutan qué perfiles de trabajo, y su correspondiente estimación de esfuerzo mediante la asignación de horas de trabajo Tabla x. Fase Asignación de perfil Horas Coste GES01 Jefe de Proyecto (100%) ANA ANA01.1 ANA01.2 ANA01.3 ANA01.4 Analistas (80%), Jefe de Proyecto (20%) Analistas (80%), Jefe de Proyecto (20%) Analistas (80%), Jefe de Proyecto (20%) Analistas (80%), Jefe de Proyecto (20%) DIS DIS01.1 DIS01.2 DIS01.2 Analistas (90%), Jefe de Proyecto (10%) Analistas (90%), Jefe de Proyecto (10%) Analistas (90%), Jefe de Proyecto (10%) ,5 922,5 IMP ,25 IMP01.1 IMP01.2 Analistas (15%), Programadores (85%) Analistas (15%), Programadores (85%) ,75 787,5 DOC01 Analistas (15%), Jefe de Proyecto (85%) GUE ,25 SUBTOTAL perfiles ,25 Tabla 5. Desglose de costes 103

115 Cabe destacar que el abultado número de horas correspondientes a la gestión del proyecto, actividad GES01, es debido a que en esta actividad a parte de las actividades propias de gestión, se ha incluido el estudio detallado del protocolo SSH, sus implementaciones, usos, funcionalidades etc. Como aclaración en la actividad ANA01.4 aparte del estudio de las tecnologías necesarias para la implementación de la aplicación, también se incluye en esta actividad el estudio en detalle del protocolo Secure Shell. A continuación pasamos a describir otros gastos que han influido en el coste total del proyecto. Coste hardware Este gasto hace referencia a los costes originados por la utilización de equipos físicos necesarios para el desarrollo del proyecto. Se han utilizado: 1. PDA Dell Axim X51 con tarjeta de red inalámbrica incluida, dispositivo móvil que aloja la aplicación cliente SSH. Valorado en la fecha de compra en Router inalámbrico Zyxel de cuatro puertos valorado en Estación de trabajo de sobremesa con valor de amortización durante el período de uso de 100 Total del coste hardware: 400 Coste software Todas las aplicaciones utilizadas para el desarrollo (ver Capítulo 3) han sido bajo licencia de software libre Open BSD. Por lo que el recargo de coste por uso de software es

116 Por tanto el coste global de la aplicación es: Tipo Coste Recursos humanos 12273,25 Hardware 400 TOTAL Tabla 6. Total costes 105

117 5 Capítulo 7 CONCLUSIONES DEL PROYECTO Guefira Project

118 CAPÍTULO 5 CONCLUSIONES DEL PROYECTO 5.1 CONCLUSIONES A lo largo del estudio realizado en el acceso a máquinas remotas mediante el modelo Cliente/Servidor en el marco del proyecto Herramienta de Utilidades de Seguridad SSH para dispositivos móviles: GUEFIRA PROJECT se ha puesto de manifiesto que existe una grave carencia en la seguridad de las mismas. Toda la información enviada entre cliente y servidor viaja en claro por la red, y esto como se ha visto, acarrea consecuencias graves que implican la vulnerabilidad de las máquinas intervinientes en la comunicación. El intercambio de contraseñas puede ser capturado por un sniffer de red (ver Capítulo 6) y permitir a usuarios ajenos a la comunicación la obtención de estas contraseñas para el acceso a recursos a los que en un principio estaban vetados. Se ha pretendido demostrar, que una solución a este problema es la utilización en las aplicaciones, del protocolo SSH para el establecimiento de canales cifrados seguros que permitan que la información transmitida viaje encriptada por la red dificultando la obtención de datos sensibles y por ende la utilización para propósitos poco fiables de terceras personas que quieran hacer uso de estos datos. En este documento se han tratado las posibles fórmulas para el establecimiento de estos canales cifrados, mediante las diferentes posibilidades de autenticación que ofrece el protocolo, tanto para los servidores como para los clientes. Se ha llegado a la conclusión de que SSH es una tecnología importante, útil y efectiva en comparación con técnicas como pueden ser Telnet, RSH, Rlogin etc. para permitir el acceso a máquinas remotas. Pero no es la única, y dependiendo de los requerimientos del problema que se aborde quizá tampoco sea la más adecuada. Como consecuencia práctica se ha propuesto la creación de una aplicación que permita el acceso a cuentas de usuario en una máquina remota desde una máquina cliente. No sólo se ha ofrecido la posibilidad de acceder a la máquina remota, sino también la ínter 107

119 actuación entre cliente y servidor mediante la ejecución de comandos UNIX establecidos en el sistema de la máquina remota servidora. O el envío de ficheros entre cliente y servidor, y todo ello mediante la seguridad que ofrece el protocolo SSH. Como utilidad de gran importancia cabe destacar la redirección de puertos que ofrece la aplicación desarrollada. Aunque esta utilidad es común en estaciones de trabajo de sobremesa, no es habitual su implementación en dispositivos móviles, y la utilidad de redireccionar cualquier aplicación del dispositivo que viaje a través de comunicaciones TCP/IP, permite poder establecer un control sobre las conexiones del aparato móvil proveyendo confidencialidad e integridad a las mismas. Cada vez más, las empresas de tecnologías de la información toman conciencia de la importancia de la seguridad sobre sus datos. Sin embargo aunque los datos almacenados proveen fuertes mecanismos de seguridad, tanto en la protección en sí por posibles pérdidas mediante la creación de copias de seguridad como en el acceso a los mismos, las políticas de seguridad no son claras y en muchos casos no se cumplen. A lo largo del desarrollo del proyecto, se ha tomado mayor conciencia si cabe de la importancia de la protección de las comunicaciones entre computadoras. Por eso se cree que es importante que en las escuelas de ingeniería se haga especial hincapié en el manejo de información sensible, en la explicación de recomendaciones para el buen uso de aplicaciones en las comunicaciones entre redes de computadoras y en el seguimiento de correctas políticas de seguridad. 108

120 5.2 TRABAJOS FUTUROS Como líneas de investigación futuras a partir de este proyecto desarrollado, se propone la creación de una utilidad que se pueda añadir al proyecto GUEFIRA PROYECT, relacionada con el sistema de ventanas X de UNIX. La seguridad que proporciona el protocolo SSH y el uso del redireccionamiento del sistema de ventanas X podría permitir la creación de una aplicación que desplegara el interfaz gráfico de la máquina remota en la aplicación cliente alojada en el dispositivo móvil. Como consecuencia directa de esta propuesta, también se podría implementar una técnica alternativa denominada Virtual Network Computing (VNC) sobre SSH que provee el despliegue del interfaz Gráfico del sistema operativo alojado en la máquina remota ya sea bajo sistema Windows o UNIX, en el dispositivo móvil. Múltiples empresas han descubierto un filón de beneficios en el desarrollo de aplicaciones destinadas a aparatos móviles. Debido a esto, han aparecido numerosos entornos de desarrollo (SDK) para la creación de aplicaciones dirigidas a esta clase de aparatos. Java tiene ciertas carencias en lo que a la creación de Interfaz de Usuario se Refiere. El uso de sus clases no proporciona un interfaz adecuado al look & feel de los sistemas operativos móviles. Otra línea de investigación podría se la utilización de la recién estrenada plataforma Android de Google para la creación de aplicaciones dirigidas a dispositivos móviles. Aunque si bien aún existen numerosos escollos de configuración, tales como la ejecución en los aparatos, puesto que aún sólo es posible la ejecución en emuladores de dispositivos desde estaciones de trabajo de sobremesa. 109

121 BIBLIOGRAFÍA Y REFERENCIAS 110

122 BIBLIOGRAFÍA Y REFERENCIAS REFERENCIAS ON LINE [1]. Información y noticias de TIC [2]. Breaking Business and tecnology news [3]. OpenSSH, Web oficial del proyecto OpenSSH [8] - Web oficial del equipo Jcraft, librerías JSch. [10] Web oficial Bouncy Castle Crypto API [11] Web oficial de la Wikipedia en español [15] - IANA, aplicaciones y números de puertos estandarizados [16] - Web official del MIT. Kerberos [17] - Web oficial del IETF, IPSEC [18] Web official del proyecto OpenSSL 111

123 REFERENCIAS BIBLIOGRÁFICAS [5] Metodología del análisis estructurado de sistemas, de Jesús Barranco de Areba, publicaciones Universidad Pontificia de Comillas [6] J2ME in a Nutshell, Java books O Reilly, primera edición marzo 2002 [7] RFC 4251 del IETF, descripción del protocolo SSH. [9] SSH secure SHell the definitive guide, O Reilly books, marzo de 2001 [12] UML distilled tercera edición, Martin Fowler, Addison Wesley [13] Escritos y documentación de Ingeniería del Software, Juan Carlos Esquivel Díaz, Universidad Pontificia de Comillas [14] Redes de computadoras, Andrew S. Tanembaum cuarta edición. [19] Escritos y documentación de Gestión de Proyectos Informáticos, Manuel Muñoz García, Universidad Pontificia de Comillas [20] RFC 4253 del IETF, descripción de la capa de transporte [21] RFC 4252 del IETF, descripción del la capa de autenticación de usuario [22] RFC 4254 del IETF, descripción del la capa de conexión 112

124 ANEXOS

125 ANEXOS Anexo I Manual de Instalación En este anexo se explica el funcionamiento de la aplicación y su instalación en el dispositivo móvil. En este caso se explicará la instalación en una PDA Dell Axim x INSTALACIÓN MÁQUINA VIRTUAL DE JAVA (IBM J9) Listamos los requerimientos mínimos para la instalación de la máquina virtual de IBM WebSphere EveryPlace MicroEnvironment. 1.Estación de trabajo de sobremesa basado en una arquitectura x86, ejecutando Windows XP service pack 2. 2.Programa de conexión PC Dispositivo móvil, ActiveSync 4.0 o superior. 3.Dispositivo PDA ejecutando Windows Mobile 5.0 Contenido del paquete de instalación IBM J9 Ficheros ejecutables: \bin: Incluye los programas de la máquina virtual J9 y librerías compartidas. Clases y recursos: \lib: Incluye el archivo charconv.zip \lib\jclfoundation11: Incluye classes.zip y locale.zip. \lib\jclfoundation11\ext: Incluye j9jce.jar y j9jsse.jar \lib\jclfoundation11\opt-ext: Incluye j9jceprov.jar \lib\jclfoundation11\ppro11: Incluye ppro-ui.jar y ppro-extras.jar \lib\security: Incluye cacerts, java.policy y java.security 114

126 \examples: Incluye GolfScoreTrackerApp.jar y GolfScoreTrackerApp.lnk. Estos ficheros se requieren para ejecutar la aplicación de ejemplo GolfScoreTrackerApp Ficheros fuente Java: \lib: Incluye charconv-src.zip \lib\jclfoundation11\source: Incluye source.zip y local-src.zip \lib\jclfoundation11\ppro11\source: Incluye ppro11-src.zip y ppro-ui-src.zip \licenses: Incluye licencias, avisos y ficheros relacionados. Desplegando la máquina virtual J9 en Windows Mobile 5.0 Seguir estos pasos para la instalación de la máquina virtual. 1.Descarga del producto de instalación desde PC, del siguiente portal Web: Product installer for Windows Mobile 5.0 CDC 1.1/FOUNDATION 1.1/PPRO 1.1: ibm-wemewm50-arm-ppro YYYYMMDD-######-###.exe 2.Usar el asistente de extracción para extraer los ficheros al directorio local del PC. 3. Seleccionar al icono de exploración en ActiveSync para abrir el explorador de archivos del Windows Mobile. 115

127 4.Usar el explorador de archivos para ir a la carpeta raíz del dispositivo móvil, y crear una nueva carpeta llamada J9. 5.Situarnos en el directorio J9 y crear otra subcarpeta llamándola PPRO11. 6.Copiar los directorios previamente extraídos, bin, lib y examples a la carpeta PPRO EJECUTANDO LA APLICACIÓN GUEFIRA PROJECT Para ejecutar la aplicación, se necesitan dos ficheros con extensiones LNK y JAR. La ejecución de la aplicación puede ser mediante dos modos: Utilizando la consola de la máquina virtual J9 Utilizando la máquina virtual exenta de consola J9w Dependiendo de donde estén ubicados los archivos de la aplicación en el sistema de archivos de la PDA el archivo.lnk tendrá una descripción u otra. Para editar el archivo Guefira0.13.lnk basta con la apertura de un editor de texto. El fichero Guefira0.13.lnk tiene esta descripción: 116

128 255#"\J9\PPRO11\bin\j9w.exe""-jcl:ppro11" "-cp" "\My Documents\perfilesSSH\Guefira0.13.jar" "sshapp.titulobienvenida" En primer lugar se hace referencia a la ubicación de la máquina virtual de Java. Esta puede ser ejecutada mediante los dos modos descritos anteriormente, con modalidad de consola para la visualización de informes, o sin consola. Luego se incluye las librerías de las que se van a hacer uso, y posteriormente indicamos el directorio del dispositivo en donde reside el archivo jar que contiene la aplicación GUEFIRA0.13, y por último especificamos cual es la clase de la aplicación que contiene el método estático main(). En este caso TituloBienvenida. Lo único que hay que cambiar en el archivo Guefira0.13.lnk es el directorio donde reside al archivo jar de la aplicación dependiendo de su ubicación a la hora de copiarlo en la PDA. Pulsando con el lápiz del dispositivo sobre el acceso directo Guefira0.13.lnk se ejecutará la aplicación GUEFIRA PROJECT. Para copiar los ficheros JAR y LNK de GUEFIRA, se requiere de nuevo de la herramienta ActiveSync. 117

129 Anexo II Manual de Usuario Desde la pantalla de bienvenida, se pueden acceder a todas la utilidades que ofrece la aplicación mediante el menú de herramientas. Utilidades de GUEFIRA PROJECT 1. SSH SHell (Terminal remota) 2. Copia de Archivos (SCP) 3. Exec SSH (Ejecución comandos remotos) 4. Port Forwarding (Redirección de puertos) El manejo de la aplicación consiste en dos pasos: 1.- Especificación de los datos de conexión 2.- Ejecución de la utilidad deseada Estos pasos se realizan mediante un interfaz de pestañas. Pestaña de Conexión, pestaña SCP y pestaña Exec, para la introducción de datos de conexión, copia de ficheros y la ejecución de la utilidad deseada respectivamente. 118

130 Utilidad SSH SHell Como ya se ha explicado con anterioridad, esta utilidad permite la apertura de un terminal de la cuenta de usuario alojada en la máquina remota en la propia máquina cliente donde se ejecuta GUEFIRA PROJECT. Para ello únicamente es necesario los siguientes datos de conexión: - Nombre Usuario - Nombre de Host o servidor remoto - Número de puerto de servidor SSH o Host remoto - Contraseña de la cuenta de Usuario remota La introducción de todos estos datos se realiza desde la pestaña de Conexión. La aplicación permite guardar y cargar perfiles de conexión, para evitar el engorro de introducir los datos a mano cada vez que se requiera realizar la conexión. Una vez realizada la configuración de los datos de conexión se procede a ejecutar la utilidad SSH SHell. Para ello nos situamos en la pestaña Exec. Desde allí elegimos la apertura de un terminal remoto y pulsamos ejecutar. 119

131 Nos aparecerá un mensaje de warning relativo a la identificación del servidor SSH, indicándonos de que el servidor no se fiable porque no se tiene constancia de que es realmente un servidor SSH. Sin embargo nosotros sabemos que sí lo es y pulsamos Sí para confiar en la máquina servidora. A continuación la aplicación nos muestra un terminal SSH UNIX en la PDA correspondiente al usuario introducido. 120

132 Puede surgir algún error de conexión. Para ello debemos seguir los siguientes pasos: - Comprobar que la contraseña introducida para la cuenta de usuario es válida - Comprobar nombre de Usuario y de Host. - Aceptar (Pulsar Sí) en el mensaje de identificación del servidor SSH, pues de lo contrario no se aceptaría su identidad y la aplicación GUEFIRA no accedería a la cuenta remota. Utilidad Exec SSH Esta utilidad permite la ejecución de comandos Unix. La ejecución de estos comandos viene determinada por los permisos del perfil que accede a la cuenta remota. Si el perfil de usuario es de administrador, podrá realizar la ejecución de comandos de administración de forma remota des de la aplicación cliente GUEFIRA. Esta utilidad sólo establece la sesión una única vez, pero permite la posibilidad que con la sesión ya establecida se realicen múltiples comandos contra el mismo servidor que se especificó en la conexión. La conexión viene determinada por un nombre de usuario y un nombre de servidor remoto de la forma usuario@hostname. Seguramente el servidor SSH al que nos conectamos nos pedirá la contraseña, luego también es necesario su introducción en el sistema de la aplicación. Por último introducimos el comando que vamos a ejecutar. A continuación se explicita una lista de comandos disponibles para su ejecución. Nótese que los comandos más utilizados son almacenados en la propia memoria de la aplicación. Pulsando en el menú de ayuda se obtendrán la posibilidad de introducir estos comandos más importantes. 121

133 Comandos de navegación pwd muestra el path completo del directorio en el que se encuentra cd cambia de directorio, por ejemplo cd directorio/subdirectorio cd ~ lleva a su directorio home cd - lleva al último directorio en el que estuvo cd.. sube a un directorio superior Listado de archivos ls lista archivos y directorios de un directorio ls -al lista archivos y directorios e información sobre los mismos ls -ar lista archivos e información incluyendo todos los subdirectorios ls -ar more lista archivos e información incluyendo todos los subdirectorios por pantallas ls -alr > resultado.txt lista archivos e información de subdirectorios y lo guarda en un archivo cat resultado.txt mostraría en pantalla el contenido del archivo ls *.html lista todos los archivos acabados en.html ls -al directorio/subdirectorio/ lista archivos e información de ese subdirectorio Crear, editar o eliminar archivos y directorios pico /home/usuario/public_html/index.html edita el archivo index.html con el editor pico touch /home/usuario/public_html/404.html crea el archivo vacio 404.html en ese directorio rm archivo.txt elimina archivo.txt rm -rf directorio/ CUIDADO! elimina el directorio indicado, los subdirectorios y todos sus archivos mkdir pepe Crea un directorio llamado pepe rmdir pepe Elimina el directorio llamado pepe 122

134 Compresión y descompresión de archivos zip archivo.zip /home/usuario/public_html/directorio Comprimir directorio unzip archivo.zip Descomprimir archivo.zip unzip -v archivo.zip Ver contenido de archivo.zip Otros comandos SSH cp-a/home/usuario/public_html/origen/* /home/usuario/public_html/destino/ Copia todos los archivos de un directorio a otro manteniendo sus respectivos permisos du -sh muestra es espacio total ocupado por el directorio en el que se encuentra du -sh * muestra el espacio ocupado de cada archivo y directorio lynx google.es usar el navegador Lynx para acceder a whoami muestra su nombre de usuario GUEFIRA permite el almacenamiento de perfiles de conexión. Para que cada vez que se quiera realizar una conexión no se tenga que introducir el nombre de usuario, el nombre de la máquina remota, la contraseña y el comando, se puede guardar el perfil, mediante el MENÚ Archivo Guardar perfil. Cuando se quiera volver a conectar y exista un perfil guardado con los datos de conexión que queremos reutilizar, dentro de la pestaña conexión pulsamos en el Archivo y seleccionamos Abrir, o simplemente pulsando el botón de Abrir en la propia interfaz de la pantalla. Nos aparecerá una pantalla con los directorios locales del dispositivo. Elegimos el directorio y el archivo de nuestro perfil que queramos cargar. 123

135 Carga de perfiles de conexión Utilidad Copia de Archivos Esta utilidad de GUEFIRA, nos brinda la posibilidad de enviar o recibir archivos desde la máquina remota al dispositivo o viceversa. En este caso nos centraremos en la pestaña SCP. Previamente se deben haber configurado los datos de conexión en la pestaña de Conexión. Seleccionando la opción Upload, enviaremos un archivo desde el dispositivo móvil a la máquina remota. Para la elección del archivos que queremos enviar, pulsamos el botón A. local, para que la aplicación despliegue el explorador de directorios del dispositivo móvil. Automáticamente la aplicación seleccionará como directorio destino /home/nombreusuario de la máquina remota. Si se quiere cambiar, se modifica mediante el campo de texto A. Remoto. 124

136 Seleccionando la opción Download, se realiza la recepción de ficheros desde la máquina remota al dispositivo. En este caso mediante el botón A. Remoto obtendremos el sistema de directorios pertenecientes a la cuenta del usuario (/home/username/ como Nodo Raíz), permitiendo la elección del archivo remoto que se quiere copiar al dispositivo móvil local. 125

137 Utilidad Port Forwarding Esta utilidad permite redireccionar todas las aplicaciones TCP del dispositivo a la máquina servidora destino. Para ello se requieren unos datos de conexión adicionales que pueden ser especificados desde la pestaña de Conexión: - Puerto local - Puerto Proxy El puerto local hace referencia al puerto del dispositivo móvil desde el que se mapearán todas las conexiónes TCP de las aplicaciones. El puerto Remoto o puerto Proxy hace referencia al puerto por el que va a estar escuchando el servidor Proxy de la aplicación local en el dispositivo móvil que se quiere redireccionar. Debemos tener en cuenta dos pasos importantes si queremos que la redirección de puertos funcione. 1. Tener un servidor escuchando en el mismo número de puerto remoto que se introduce en la aplicación cliente GUEFIRA. Si desde el dispositivo queremos redireccionar una aplicación de correo, entonces la aplicación que debe estar escuchando en el número de puerto remoto, debe ser un servidor de correo. Si por le contrario, queremos redireccionar peticiones Web, entonces la aplicación que debe estar escuchando en el número de puerto remoto debe ser un servidor Web. 2. Debemos configurar la aplicación que se redirecciona en el dispositivo, para que se conecte al número de puerto local. Si suponemos que la aplicación que queremos redireccionar es un navegador Web, entonces en las preferencias de configuración del navegador usaremos como medio de conexión un Proxy Web, 126

138 con el número de puerto local que se ha introducido en el cliente GUEFIRA. De esta manera, todas la peticiones del navegador por el puerto local se redirigirán al servidor que esté escuchando en el número de puerto remoto. Suponemos que vamos a llevar a cabo la redirección de la aplicación MINIMO, un navegador Web para dispositivos móviles que utiliza la tecnología de Mozilla Firefox. Llega el momento de la elección de número de puertos. El puerto local que se elija, debe ser un puerto TCP por el que normalmente se transmiten peticiones Web. Según el estándar están estipulados los puertos 80 y Como el número de puerto 80 ya está utilizado por la aplicación Internet Explorer Mobile, elegimos por tanto el número de puerto 8080 para asignarlo como puerto local en la redirección de puertos. Lo introducimos en la aplicación GUEFIRA. El puerto remoto que se elija deberá estar respaldado por un servidor Web en la máquina destino. En este caso en la máquina destino está corriendo un Proxy Web, llamado Squid. El Proxy o representante resolverá las peticiones Web realizadas desde nuestro dispositivo móvil mediante la aplicación MÍNIMO. A continuación vemos como se debe de configurar el navegador Web MÍNIMO. Vamos a Programas del menú inicio de Windows Mobile 5.0 y ejecutamos la aplicación MÍNIMO. Pulsamos el botón con un icono de tres puntos suspensivos y seleccionamos preferencias. Dentro del menú de preferencias pulsamos sobre el icono de red en el que aparece dibujado un enchufe. Y en configuraciones de conexión mediante Proxy http, ponemos como URL la dirección IP de nuestro dispositivo móvil. En este caso podría se la dirección IP localhost: y como puerto por el que se va a conectar el mismo que introducimos en la aplicación GUEFIRA, en nuestro caso el número de puerto TCP

139 Preferencias MINIMO ya está configurado para la redirección de puertos. A continuación ejecutamos en el cliente SSH GUEFIRA el Port Forwarding y esperamos a que se establezca la conexión segura. 128