CONAD CONNECTIONS ADMINISTRATOR : Aplicación web para la gestión de conexiones SSH a servidores

Abstract

Este proyecto surgió de la idea de darle visibilidad a las posibilidades del comando last de Linux, que guarda un registro de la actividad de los usuarios en un equipo. Dado que las conexiones ssh no dejan de ser en el fondo conexiones al servidor del mismo modo que podrían realizarse en el propio equipo pero de forma remota se tratan para el servidor de la misma manera que se trataría un acceso a terminal en local, puesto que ahora lo normal es tener los servidores en ‘la nube’ y cada vez es menos frecuente la imagen del servidor en la oficina o el data center de una empresa, pero a la vez sigue siendo necesario un control de los accesos de los usuarios a los servidores, para cubrir esta necesidad se planteó la posibilidad de obtener las conexiones ssh que se realizan a un servidor y mostrarlas de una forma sencilla e intuitiva a un administrador que necesite monitorizar dicha actividad. De esta idea nació el proyecto CONAD, que a través del comando last obtiene las conexiones ssh de los usuarios a un servidor, pero solo con esta idea no es suficiente para desarrollar un proyecto software completo y viable, para ello se llevó a cabo un estudio mucho más detallado de la idea para poder establecer unas bases en las que se cimentaría el proyecto a desarrollar. Lo primero que se hizo necesario en ese momento fue comprobar que la idea realmente tenía aplicaciones prácticas para su uso, dado que sino no tenía sentido el comenzar un desarrollo que luego nadie fuese a usar, de ahí surgió la idea de poder monitorizar el uso de los equipos de las salas informáticas, ver cuales tenían un uso mayor, por ejemplo, o poder sacar estadísticas de tiempo de uso de los usuarios de los diferentes equipos. Teniendo ya la idea y al mismo tiempo en que íbamos a emplearla llegó el momento de establecer los requisitos mínimos que iba a tener que cumplir para poder considerarse un éxito. Este razonamiento es el que llevó a un cambio de estrategia con respecto a la idea original que consistía en centrarse en los usuarios en lugar de estar centrados en servidores y número de conexiones, ya no tenía sentido almacenar usuarios que se conectasen independientemente del equipo y ver en qué equipos se conectaban como podría haber sido una primera idea, de hecho la idea original era el seguimiento de un solo equipo y poder ver los usuarios que se conectaban, a qué hora lo hacían y la duración de sus conexiones, hasta que realmente estudiando el potencial de la idea nos dimos cuenta que era mucho más útil lo expuesto hasta ahora, la utilización del comando last para obtener conexiones a diferentes servidores, lo de hacerlo multiservidor surgió del hecho de que dado que hay que almacenar toda la información necesaria para poder conectar con un servidor y obtener sus conexiones, hacer lo mismo varias veces para varios servidores era trivial y aportaba mucha información que el usuario final luego iba a saber valorar. Una vez establecida la base del proyecto, surgió la primera decisión de diseño, la selección de la herramienta en la que se iba crear y desarrollar la aplicación web, dado que ahora mismo hay muchos lenguajes y frameworks para la realización de aplicaciones web se antojaba complicado seleccionar uno frente a otro, como se puede extraer de las comparativas que hay más adelante en este mismo documento la elección del lenguaje no fue trivial, de los principales lenguajes y frameworks de desarrollo web los que mejores características tenían eran Ruby y Phyton. Como se expone con posterioridad una de las grandes complicaciones que tiene el framework Ruby on Rails y de Ruby es el conocerlo, es un lenguaje con una gran curva de aprendizaje pero que una vez que se sabe manejar da una versatilidad que no dan otros lenguajes, teniendo todo esto en cuenta y contando con un conocimiento en el desarrollo con dicha herramienta finalmente se decide hacer el desarrollo del proyecto utilizando el framework de Ruby on Rails. Tras tener decididas las líneas generales de lo que va a ser el proyecto y la plataforma en la que se va a realizar el desarrollo se procede a establecer los objetivos que va a tener que cumplir el proyecto para poder considerar que se ha completado con éxito y a su vez para poder marcar unos mínimos que tienen que cumplirse en cualquier caso pero que a su vez pueden ser mejorados durante el proceso de desarrollo de la aplicación. El primer objetivo y principal es la obtención de los datos de conexiones de los distintos servidores que se quieren monitorizar con ella, como ya se ha comentado con anterioridad se utiliza el comando last de los sistemas con base UNIX, por lo tanto por ahora el sistema CONAD sólo podrá usarse con servidores UNIX que son los únicos que tienen implementado el comando last y por tanto son los únicos de los que se va poder extraer datos con esta versión de la aplicación, una posible mejora para el futuro es obtener una solución similar para otros sistemas operativos que no tengan la base UNIX de modo que la herramienta web tenga una repercusión mayor y pueda ser utilizada por un número mayor de usuarios. Para la obtención de los datos es necesario disponer de un usuario y una contraseña ssh para cada uno de los servidores de los que se quiera hacer seguimiento, con esta información ssh la aplicación se conecta al servidor y ejecuta el comando last, después la aplicación se encargará de procesar la respuesta obtenida en el servidor y convertirla en las conexiones con las que luego se va a trabajar y cumplir así con el resto de objetivos. El procesado de los logs obtenidos del comando last para cada servidor se realiza en una tarea en background que de cada línea recogida extrae la información que necesita para poder mostrarse con posterioridad, en este caso, se extrae el usuario que ha realizado la conexión y la hora a la que se produjo la misma. Para la ejecución de las tareas que recogen la información de los logs se usa una gema (librería) de Rails llamada sidekiq que se encarga de lanzar de forma asíncrona en segundo plano tareas que requieran una gran carga de procesado por parte del servidor, un ejemplo típico de este tipo de tareas sería el envío de correos electrónicos por parte de la aplicación. Teniendo la obtención de datos en tareas asíncronas y paralelas se consigue que el procesado se realice en un tiempo menor dado que no tiene que esperar a que se haya procesado el servidor anterior para comenzar a procesar el siguiente, también se consigue que si por lo que sea falla la obtención de datos en un servidor el resto de servidores no se vea afectado y sí que se pueda obtener información de ellos, además se prevé también que pueda producirse que el tiempo de respuesta del servidor tras la petición de actualización de las conexiones sea superior al máximo establecido y que se detuviese la ejecución, puesto que los servidores web tienen establecido un tiempo máximo de respuesta después del cual la petición se desecha. El siguiente de los objetivos a cumplir es el de gestionar los diferentes servidores que van a estar almacenados y de los que se va a guardar registros de conexiones en la aplicación. Puesto que para conseguir dicha información hace falta almacenar información sobre ellos, esta información tiene que ser accesible para el usuario final de la aplicación dado que puede necesitarla, para la creación de un servidor nuevo dentro de la aplicación serán necesarias, ...