Sistemas de autenticaci´ on de usuarios

Otro de los puntos que es necesario debatir es el dise˜no e implantaci´on de un sistema de autenticaci´on de usuarios, necesario para que los alumnos puedan iniciar su sesi´on en las estaciones del Laboratorio. En este sentido, ser´a necesario analizar las tecnolog´ıas actuales que brindan un sistema de usuarios en red que proporcione la infraestructura necesaria para que una persona, en posesi´on de su nombre de usuario y contrase˜na pueda iniciar una sesi´on, independientemente del ordenador en el que se encuentre en ese momento (de ah´ı que sea un sistema de usuarios en red). En este sentido, vamos a estudiar tres sistemas de autenticaci´on principales. El primero de ellos, es el m´as rudimentario, bas´andose en el sistema tradicional de ficheros /etc/passwd y /etc/shadow con replicaci´on ante cambios.

13

http://sites.google.com/a/ibeentoubuntu.com/debian-preeseds/

1.3. ESTADO DEL ARTE

En segundo lugar, estudiaremos los sistemas m´as avanzados para implementar un sistema de usuarios en red, y m´as usados hoy en d´ıa, sobre todo la segunda alternativa que planteamos, LDAP, un protocolo basado en directorio bastante ligero y que es una de las alternativas m´as usadas hoy en d´ıa ante este tipo de problemas.

Mapa de usuarios local con replicaci´on

La primera soluci´on que nos planteamos es la implantaci´on de un mecanismo de autenticaci´on basado en un mapa de usuarios locales que se replique a lo largo de todas las m´aquinas que componen el laboratorio. El funcionamiento de este mecanismo por tanto, ser´ıa el funcionamiento cl´asico basado en los ficheros /etc/shadow y /etc/passwd superponiendo por encima un mecanismo que permita replicar estos ficheros en todas las estaciones que componen nuestro entorno.

Este mecanismo de replicaci´on se puede llevar a cabo de muy diferentes maneras. Por ejemplo, implementando un monitor que sondee los cambios en ambos ficheros en una m´aquina concreta (en la que se producen los cambios, por ejemplo) y vaya propagando estos cambios entre aquellas m´aquinas interesadas. Esta replicaci´on se puede llevar a cabo mediante una transmisi´on simple de ficheros usando SSH (usando el comando SCP, por ejemplo).

Otra decisi´on a tomar ser´ıa si los cambios lo solicitan los clientes, o es una ´unica m´aquina la que propaga los cambios cuando estos se produzcan. En cualquier caso, estas decisiones pertenecen al mecanismo de propagaci´on de cambios que este mecanismo incorporar´ıa. Lo fundamental de este mecanismo es comprender que los mecanismos para a˜nadir y borrar usuarios, as´ı como cambiar una contrase˜na, por ejemplo, son los mismos que en un sistema Linux/Unix tradicional (al basarse en los ficheros tradicionales de usuarios de cualquier sistema Unix).

Sin embargo, este sistema adolece de muchos problemas para ser llevado a la pr´actica. Como desventaja principal, la escalabilidad del sistema, que se puede convertir en insostenible. Si el n´umero de m´aquinas es relativamente alto, la propagaci´on de cambios puede convertirse en un verdadero problema, cuando a˜nadamos muchas cuentas en muy poco tiempo, o simplemente realicemos un cambio en los datos de los usuarios, a parte de convertirse en un cuello de botella. Adem´as, si elegimos un dise˜no en el que solo se pudieran modificar datos en una sola m´aquina, nos deber´ıamos preguntar qu´e pasar´ıa si un usuario decide cambiar su contrase˜na (una acci´on bastante frecuente). ¿Deber´ıa iniciar una sesi´on en esa m´aquina y entonces cambiar la contrase˜na? ¿Deber´ıa poder cambiar la contrase˜na en la m´aquina en la que se encuentra, y que esta informara a la m´aquina maestra de que se ha producido un cambio? Como vemos, la acci´on m´as simple que puede darse en un esquema de cuentas en red, como cambiar una contrase˜na, puede convertirse en algo bastante complicado usando este esquema. Sin embargo, a˜nadir y borrar cuentas, as´ı como cambiar una contrase˜na en la m´aquina maestra es extremadamente simple, usando directamente comandos del sistema para realizarlo (eso s´ı, siempre que sea el administrador el que realice estos cambios). Debido a que el n´umero de pros es mayor a las ventajas que puede ofrecernos esta tecnolog´ıa, en principio decidimos estudiar otras alternativas para nuestro dise˜no de cuentas en red. Sin embargo y como rese˜na, cabe destacar las ventajas y desventajas de la citada tecnolog´ıa: Como ventaja, podemos decir que un sistema de usuarios locales con replicaci´on o propagaci´on de cambios es bastante simple para a˜nadir y borrar usuarios, as´ı como para cambiar contrase˜nas, ya que siempre se usan los comandos est´andar del sistema para esta labor (siempre y cuando los realice un administrador o un usuario con privilegios).

Como desventaja podr´ıamos destacar que se producen un gran problema de escalabilidad en este dise˜no, adem´as de tener que dise˜nar un sistema completo de propagaci´on de cambios que sea lo suficientemente bueno como para asumir el volumen de datos de cuentas que nos

CAP´ITULO 1. INTRODUCCI ´ON

proponemos. Adem´as, este dise˜no tiene serios problemas de concurrencia, que pueden darse cuando dos administradores realicen modificaciones en la cuenta de un usuario.

NIS

Las p´aginas amarillas NIS14

, tambi´en llamadas Sun Yellow Pages es una tecnolog´ıa de cuentas de usuario en red (aunque tambi´en puede ser usado para otros menesteres), desarrollada principalmente por Sun Microsystems en los a˜nos de los 90.

Esta tecnolog´ıa es la que inicialmente se usaba en los Laboratorios de Linux de la Universidad antes de evaluar soluciones m´as avanzadas de cara al aumento tanto de estaciones instaladas en los Laboratorios como de usuarios en posesi´on de una cuenta.

La tecnolog´ıa NIS se basa en llamadas RPC entre cliente y servidor para el intercambio de informaci´on sobre usuarios en sistemas distribuidos, tales como el que nos ocupa. El software que implementa tal funcionalidad se compone de un servidor, una biblioteca para el lado del cliente y varias herramientas de administraci´on. En concreto NIS funciona de tal forma que la informaci´on contenida en los ficheros /etc/passwd, /etc/shadow y /etc/group se puede distribuir a lo largo de una LAN de tal forma que el efecto es como si los citados ficheros fueran locales a la m´aquina en la que nos encontramos. En cierto modo, el funcionamiento es muy similar a tener un fichero /etc/passwd, /etc/shadow locales, ya que las herramientas para a˜nadir y borrar usuarios as´ı como cambiar una contrase˜na son las est´andares de Unix, con la ´unica excepci´on que ha de realizarse en el servidor que proporciona la informaci´on NIS. En el resto de hosts es necesario realizar llamadas RPC para realizar consultas sobre los datos de los usuarios.

En particular este esquema es bastante simple, y muy funcional: estuvo funcionando perfectamente durante aproximadamente 5 a˜nos en los Laboratorios sin muchos problemas. En cuanto a requerimientos t´ecnicos, solamente se necesita un servidor que almacene la informaci´on de los usuarios, y conocimientos b´asicos de administraci´on de usuarios en sistemas Unix. Con esto, es suficiente para poder construir un sistema de cuentas en red basado en NIS.

Sin embargo, hay dos problemas fundamentales para este esquema, que desarrollamos a continuaci´on:

La escalabilidad ´unicamente hay un servidor NIS de cuentas de usuario con todo lo que ello conlleva: protecci´on ante fallos, cuellos de botella, etc´etera. Sin embargo, cabe destacar que en los a˜nos que esta soluci´on estuvo implantada en los Laboratorios, no se produjeron en ning´un momento cuellos de botella significativos, ante un laboratorio de aproximadamente 90 estaciones de trabajo, lo que deducimos que se debe a lo ligero del protocolo, entre otras cosas. Por tanto, lo m´as preocupante es la protecci´on ante fallos y ca´ıdas repentinas del servidor que puedan producirse en cualquier momento.

La seguridad de los datos en la red. Usando esta soluci´on, los datos de los usuarios viajan en claro por la red, con todo lo que ello conlleva. La informaci´on relativa al nombre de usuario, directorio personal de los mismos viaja totalmente en claro, y las contrase˜nas de las cuentas viajan cifradas con un mecanismo de cifrado sim´etrico, con lo que el romper este cifrado es bastante sencillo. Hoy en d´ıa no podemos asumir que esto ocurra. Cualquier usuario malicioso que pueda ponerse entre medias de un cliente y del servidor NIS podr´a captar datos de cualquier usuario del sistema. Se hace necesario por tanto a˜nadir un mecanismo que cifre los datos de los usuarios cuando estos viajan entre cliente y servidor, mecanismo que a d´ıa de hoy no posee la tecnolog´ıa NIS de Sun.

14

NIS son las iniciales de Network Information Service

1.3. ESTADO DEL ARTE

Por tanto, debido a estas principales desventajas y a ser un producto tecnol´ogicamente desfasado, nos vemos obligados a estudiar otras tecnolog´ıas para llevar a cabo el sistema de usuarios en red.

LDAP

Por ´ultimo, nos planteamos el estudio de una soluci´on basada en directorio, usando para ello el est´andar LDAP15

. LDAP es una tecnolog´ıa de reciente aparici´on que gestiona un directorio en una base de datos que puede servir en principio para dar servicio a muy dispares aplicaciones, aunque sin duda, una de las m´as usadas hoy en d´ıa es la autenticaci´on de usuarios ya sea en sistemas operativos tipo Unix (como el que nos ocupa) o m´aquinas Windows (a trav´es de la creaci´on de cuentas Samba).

En nuestro caso, solamente usaremos el directorio LDAP para la autenticaci´on de usuarios en m´aquinas Unix. Aunque una vez puesto en marcha el servicio, se puede utilizar para muy diversos fines (aparte del descrito) como por ejemplo, la informaci´on de hosts en la red, o como servicio de libreta de direcciones. Como tal, LDAP es un est´andar detallado como tal en la RFC16

correspondiente17

.

Habitualmente, un servidor LDAP almacena informaci´on de un usuario de la red, tal como su nombre de usuario y su contrase˜na, aunque puede incluir informaci´on adicional como nombre de la persona, ubicaci´on f´ısica, foto personal, etc´etera. En definitiva, podemos afirmar que LDAP es un protocolo de acceso unificado a un conjunto de informaci´on sobre una red.

En nuestro caso vamos a utilizar este servicio para almacenar la informaci´on de las cuentas de usuario del sistema, particularmente y como informaci´on fundamental, su nombre de usuario y contrase˜na. Aunque por supuesto, tambi´en ser´a necesario almacenar otro tipo de informaci´on, como el nombre y apellidos del usuario en cuesti´on, correo electr´onico, etc´etera. La tecnolog´ıa LDAP como tal y dado a que ´unicamente describe un protocolo, es implementada por numerosas aplicaciones con muy diferentes licencias. Los gigantes inform´aticos han querido hacer suya esta tecnolog´ıa y han liberado aplicaciones que implementa de forma muy diferente (y con unos nombres muy diferentes) un servicio de directorio basado en LDAP. En concreto, Microsoft distribuye la aplicaci´on Active Directory, bajo la cual se almacena informaci´on de usuarios, recursos de la red, pol´ıticas de seguridad, configuraci´on, y asignaci´on de permisos, entre otras cosas, en entornos de redes Windows. Ni que decir tiene que se trata de una soluci´on comercial y por tanto, de pago, por lo que para nosotros queda descartada autom´aticamente, debido a la naturaleza del entorno en el que nos encontramos.

Otro producto muy similar es el liberado por Novell, Novell Directory Services. Esta aplicaci´on es la implementaci´on de Novell utilizada para manejar el acceso a recursos en diferentes servidores y computadoras de una red en la que se representan como objetos los servicios m´as usuales en una red, como una impresora, una estaci´on, un servidor, un servicio, una persona, etc´etera. Una vez definidos los objetos en la base de datos, se asignan los permisos para el control de acceso. Dado que esta soluci´on tambi´en es una soluci´on comercial, no nos planteamos abordarla en nuestros objetivos.

Por ´ultimo, la aplicaci´on OpenLDAP es una implementaci´on del protocolo LDAP basada en el concepto de software libre desarrollada por el proyecto OpenLDAP, que comienza aproximadamente en el a˜no 1998. Esta implementaci´on del est´andar LDAP, esta incluida en la mayor´ıa de distribuciones Linux m´as usadas hoy en d´ıa (por supuesto se encuentra en las basadas en Debian GNU/Linux, como Ubuntu). La implementaci´on incluye un servidor (llamado slapd ),

15

LDAP son las siglas de Lightweight Directory Access Protocol o Protocolo ligero de acceso a directorio

16

RFC son las siglas de Request for comments y es un documento t´ecnico que describe el comportamiento de un protocolo de red.

17

CAP´ITULO 1. INTRODUCCI ´ON

un demonio de replicaci´on de datos (llamado slurpd ) y una serie de bibliotecas que implementan el est´andar LDAP. Adem´as, esta implementaci´on soporta m´ultiples esquemas de datos, entre los que se encuentran los necesarios para representar una cuenta en un sistema Unix y un grupo, por lo que nos sirve para representar la informaci´on de cuentas de los usuarios del sistema.

Adem´as de todo lo descrito hasta ahora, OpenLDAP dispone de multitud de aspectos avanzados que lo convierten en una soluci´on bastante factible a la hora de decantarse por un sistema de cuentas en red, particularmente,

La posibilidad de a˜nadir replicaci´on de datos entre servidores OpenLDAP : Como veremos posteriormente en el cap´ıtulo Implantaci´on, es posible dise˜nar un esquema de servidores maestros-esclavos de tal forma que exista tolerancia ante fallos de red o de suministro el´ectrico, adem´as del consiguiente reparto de carga.

Reparto de carga entre diferentes servidores LDAP: Del lado del cliente, es posible repartir las peticiones de informaci´on sobre diferentes servidores LDAP. Esto es especialmente interesante en un entorno en el que nos encontramos, en el que existe un gran n´umero de usuarios y de estaciones que van a realizar peticiones sobre el servidor LDAP. Veremos m´as adelante como podemos llevar este dise˜no a cabo y cuales son las ventajas que nos proporciona.

Cifrado de datos entre cliente y servidor: OpenLDAP nos brinda la posibilidad de asegurar las conexiones entre el servidor y los diferentes clientes que vayan a realizar peticiones de autenticaci´on o solicitud de informaci´on sobre el mismo. Para ello, se utilizar´an las bibliotecas SSL de cifrado de informaci´on entre ambos extremos, que asegurar´an confidencialidad y privacidad de los datos de los usuarios que viajen en la red. Este aspecto es fundamental y es un requisito cr´ıtico en el entorno en el que nos encontramos. Debido a estas razones, LDAP se convierte hoy en d´ıa en un est´andar de facto a la hora de implementar un sistema de autenticaci´on de usuarios en red y ser´a la opci´on elegida para la construcci´on de nuestro servicio de autenticaci´on de usuarios en red.