Memoria Pfc Superior

Ingenier´ıa Inform´ atica Escuela T´ecnica Superior de Ingenier´ıa Inform´atica Curso acad´emico 2007-2008

Proyecto Fin de Carrera

´ ´ Y ADMINISTRACION ´ INSTALACION, CONFIGURACION ´ DE AULAS INFORMATICAS MEDIANTE SOFTWARE LIBRE

Autor: Tutor:

Antonio Guti´errez Mayoral Jose Centeno Gonz´alez

Septiembre 2008

ii

A mis padres y mi hermano

iv

Gracias

La finalizaci´on de un proyecto fin de carrera normalmente lleva asociado el fin de una etapa y el comienzo de otra. En particular, este proyecto resume pr´acticamente los u ´ltimos dos a˜ nos trabajando en el GSyC en la administraci´on de sus laboratorios docentes. Un par de a˜ nos en los que he trabajado en un entorno de trabajo que creo que puede considerarse privilegiado y que cualquier persona podr´ıa envidiar. A trav´es de este peque˜ no texto quiero agradecer al Grupo de Sistemas y Comunicaciones el facilitarme un entorno de trabajo envidiable, y del que me acordar´e siempre, sobre todo si alg´ un d´ıa ya no estoy aqu´ı. A Jose Centeno y Pedro de las Heras por confiar en m´ı y creer en m´ı como aqu´el que podr´ıa realizar el trabajo que intento hacer todos los d´ıas con la m´ axima ilusi´ on posible. Gracias tambi´en a Sergio Ar´evalo y Jes´ us Gonz´alez Barahona como directores del Departamento y estar ah´ı siempre que lo he necesitado, ayud´ andome siempre que han podido. Gracias tambi´en a todo el Grupo por el capital humano aportado y por hacerme sentir en uno de los mejores entornos de trabajo que he estado. Gracias a mis compa˜ neros de Universidad sin los cuales el d´ıa a d´ıa ser´ıa mucho m´ as amargo y aburrido. Gracias a Lorena, Juan Carlos, Carlos, Tamara, Fran, Javi, Marina, Bel´en y todos los dem´as. Gracias a mi familia, a mis padres y mi hermano, ya que sin su apoyo y confianza nada de esto hubiera sido posible. A todos, gracias.

v

vi

Resumen Hoy en d´ıa la administraci´on de sistemas se ha convertido en un aspecto fundamental en cualquier entorno inform´atico. En la empresa esta responsabilidad es clara, donde la alta disponibilidad de los sistemas es b´asica para su operabilidad. De la misma manera, en cualquier entorno docente es fundamental la puesta en marcha de todas aquellas tecnolog´ıas necesarias para permitir a los alumnos realizar sus pr´acticas y a los profesores impartir sus asignaturas. A veces esta tarea no es tan f´acil como parece a simple vista: requiere de conocimientos avanzados de redes, sistemas operativos y administraci´on de sistemas. Por otro lado, el avance del Software Libre como modelo de desarrollo de software adem´ as de como alternativa para la docencia hace muy atractivo su uso de cara a las diferentes materias que pueden ser impartidos en una carrera de Ingenier´ıa Inform´atica, ya que su flexibilidad y los conceptos sobre los que se sustenta el Software Libre hacen que se pueda adaptar muy f´acilmente a ellas. En particular, la puesta en marcha de una serie de tecnolog´ıas relacionadas con la administraci´on del sistema Linux resultan b´asicas para que se pueda usar este Sistema Operativo en un entorno docente. En este proyecto se ha llevado a cabo un an´ alisis de las diferentes tecnolog´ıas que son necesarias para el funcionamiento de un entorno de estas caracter´ısticas. Por un lado, es necesario establecer un plan o mecanismo que facilite la labor de los administradores de cara a la instalaci´ on de un n´ umero elevado de estaciones de usuario. Para ello, se implementar´ a un mecanismo de instalaciones autom´aticas completamente desatendidas que facilite esta labor. Por otro lado, tambi´en se hace necesaria la implantaci´ on de un servicio que facilite que los usuarios puedan iniciar una sesi´ on en el entorno a partir de unas credenciales determinadas (normalmente un par formado por el nombre de usuario y contrase˜ na), as´ı como proporcionar un servicio de disco en red que facilite a los usuarios el poder almacenar sus ficheros personales a lo largo de toda la red local. Estos dos objetivos principales son b´asicos para el funcionamiento del entorno, pero no son los u ´nicos. La adici´on de servicios adicionales al Laboratorio, como un servicio de correo electr´onico (entrega y recogida) as´ı como un sitio web bien documentado y funcional de cara a los alumnos van a hacer que ´este sea m´ as agradable al uso diario. Servicios adicionales de cara a la gesti´ on, como construir y documentar pol´ıticas de seguridad eficientes e instaurar un sistema de monitorizaci´ on del estado de la red (que garantizar´ an la r´apida detecci´ on de incidencias y por tanto su resoluci´ on), culmina el proyecto. La realizaci´on de este proyecto supone la implantaci´ on de un entorno totalmente funcional apto para la docencia de todas las pr´acticas de las asignaturas pertenecientes al Departamento de Sistemas Telem´ aticos y Computaci´on, al mismo tiempo que consolidan amplios conocimientos en Sistemas Operativos de la familia GNU/Linux, as´ı como en un amplio abanico de aplicaciones de servidor, ampliamente usadas en entornos empresariales. La construcci´ on adicional de aplicaciones web de gesti´ on de todos los servicios que hemos implementado en este proyecto, as´ı como t´ecnicas avanzadas como la virtualizaci´on de servidores dejan la puerta abierta a trabajos futuros en la misma l´ınea de investigaci´on que el presente proyecto.

vii

viii

´Indice general

1. Introducci´ on 1.1. Motivaci´ on del proyecto . . . . . . . . . . . . 1.2. Estructura de este documento . . . . . . . . . 1.3. Estado del arte . . . . . . . . . . . . . . . . . 1.3.1. Distribuciones de Linux . . . . . . . . 1.3.2. Sistemas de instalaci´ on desatendidos . 1.3.3. Sistemas de autenticaci´ on de usuarios 1.3.4. Sistemas de ficheros en red . . . . . . 1.3.5. Servidores de correo electr´onico . . . . 1.3.6. Sistemas de monitorizaci´ on . . . . . .

. . . . . . . . .

2. Objetivos 2.1. Sistema de instalaciones masivas y desatentidas 2.2. Sistema de cuentas de usuario y disco en red . 2.3. Servicios adicionales . . . . . . . . . . . . . . . 2.4. Monitorizaci´ on del sistema . . . . . . . . . . . . 2.5. Pol´ıticas de seguridad . . . . . . . . . . . . . . 2.6. Documentaci´ on . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

3. Especificaci´ on y Dise˜ no 3.1. Metodolog´ıa empleada . . . . . . . . . . . . . . . . . 3.2. An´ alisis de requisitos . . . . . . . . . . . . . . . . . . 3.2.1. Proceso de instalaci´ on desatendido . . . . . . 3.2.2. Cuentas de usuario en red y disco en red . . . 3.2.3. Servicios de valor a˜ nadido . . . . . . . . . . . 3.3. Dedicaci´on de las m´ aquinas f´ısicas . . . . . . . . . . 3.3.1. Peloto . . . . . . . . . . . . . . . . . . . . . . 3.3.2. Zipi . . . . . . . . . . . . . . . . . . . . . . . 3.3.3. Zape . . . . . . . . . . . . . . . . . . . . . . . 3.3.4. Lechuzo . . . . . . . . . . . . . . . . . . . . . 3.3.5. Sapientin . . . . . . . . . . . . . . . . . . . . 3.3.6. Pantuflo . . . . . . . . . . . . . . . . . . . . . 3.3.7. Espatula . . . . . . . . . . . . . . . . . . . . . 3.4. Servidores disponibles en el Campus de Fuenlabrada 3.4.1. Bilo . . . . . . . . . . . . . . . . . . . . . . . 3.4.2. Nano . . . . . . . . . . . . . . . . . . . . . . ix

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

3 4 4 4 5 10 13 17 19 22

. . . . . .

27 28 28 29 30 31 32

. . . . . . . . . . . . . . . .

33 34 34 34 35 35 36 37 37 37 37 37 38 38 38 39 39

´INDICE GENERAL

´INDICE GENERAL

4. Implantaci´ on 4.1. Herramienta de Instalaci´ on Autom´atica . . . . . . . . . . . . 4.1.1. Servidor DHCP para configuraci´ on autom´atica de Red 4.1.2. Arranque por PXE . . . . . . . . . . . . . . . . . . . . 4.1.3. Arranque por red de Linux . . . . . . . . . . . . . . . 4.1.4. Ficheros de preconfiguraci´on . . . . . . . . . . . . . . 4.2. Protocolos situados en la capa de aplicaci´on . . . . . . . . . . 4.2.1. Servidor LDAP de cuentas de usuario . . . . . . . . . 4.2.2. Servidor NFS de ficheros en red . . . . . . . . . . . . . 4.2.3. Servidor Web de los Laboratorios . . . . . . . . . . . . 4.2.4. Servidor de correo electr´onico . . . . . . . . . . . . . . 4.3. Otros servicios disponibles . . . . . . . . . . . . . . . . . . . . 4.3.1. Listas de correo . . . . . . . . . . . . . . . . . . . . . . 4.3.2. Mirror de Debian y Ubuntu . . . . . . . . . . . . . . . 4.4. Monitorizaci´ on del Sistema . . . . . . . . . . . . . . . . . . . 4.4.1. Monitorizaci´ on de servidores . . . . . . . . . . . . . . 4.4.2. Monitorizaci´ on de estaciones . . . . . . . . . . . . . . 4.5. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1. Limitar los accesos remotos . . . . . . . . . . . . . . . 4.5.2. Auditor´ıa de usuarios . . . . . . . . . . . . . . . . . . 4.5.3. Detecci´on de intrusos . . . . . . . . . . . . . . . . . . 4.5.4. Ataques de fuerza bruta v´ıa SSH . . . . . . . . . . . . 4.5.5. Seguridad en las contrase˜ nas de los usuarios . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

41 42 43 44 46 46 52 52 69 74 81 86 86 89 90 91 94 95 95 97 99 100 102

5. Conclusiones 105 5.1. Logros alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.2. Conocimientos adquiridos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 A. Scripts de Instalaci´ on Autom´ atica I A.1. Fichero de preconfiguraci´on gen´erico . . . . . . . . . . . . . . . . . . . . . . . . . . ii A.2. Configuraci´on Isolinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v A.3. Fichero de configuraci´ on del servidor dhcp . . . . . . . . . . . . . . . . . . . . . . vi B. Scripts adicionales B.1. Scripts de copias de seguridad . . . . . . . B.1.1. De lechuzo a sapientin . . . . . . . B.1.2. De bilo a nano . . . . . . . . . . . B.1.3. De sapientin al disco USB . . . . . B.1.4. De nano al disco USB . . . . . . . B.2. Script de copia de seguridad del directorio B.3. Auditor´ıa de usuarios . . . . . . . . . . . B.3.1. Creaci´on de la base de datos . . . B.3.2. Inserci´ on de los datos de auditor´ıa B.4. Scripts ssh-a-todos y scp-a-todos . . . . . B.4.1. Scripts ssh-a-todos . . . . . . . . . B.4.2. Scripts scp-a-todos . . . . . . . . . B.5. Script de debilidad de contrase˜ nas . . . . x

IX

. . . . . . . . . . . . . . . . . . . . LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

x x x xi xi xii xii xii xii xiii xiii xiv xv

C. Ficheros de configuraci´ on C.1. M´ aquinas zipi y zape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.1.1. Servidor LDAP. Fichero slapd.conf . . . . . . . . . . . . . . . . C.1.2. Servidor DNS. Fichero named.conf y db.pantuflo.es para zipi C.1.3. Servidor DNS. Fichero named.conf para zape . . . . . . . . . . C.2. M´ aquina pantuflo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.2.1. Fichero de configuraci´ on de Apache . . . . . . . . . . . . . . . . C.2.2. Fichero de configuraci´ on de Postfix . . . . . . . . . . . . . . . . C.2.3. Fichero de configuraci´ on de Dovecot . . . . . . . . . . . . . . . C.3. M´ aquina lechuzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.4. M´ aquina peloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.5. M´ aquina sapientin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.6. M´ aquina minervo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.7. M´ aquina espatula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.8. M´ aquina bilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.8.1. Servicio NFS en bilo . . . . . . . . . . . . . . . . . . . . . . . . . C.9. M´ aquina nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xi

XXI

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

xxii xxii xxiv xxxi xxxii xxxii xxxv xxxviii li lii lv lv lv lv lvi lvi

´INDICE GENERAL

´INDICE GENERAL

xii

´Indice de figuras

1.1. Interfaz web de Zabbix. Fuente: Wikipedia . . . . . . . . . . . . . . . . . . . . . . . 23 1.2. Representaci´ on del uso de memoria en una m´ aquina a trav´es de Munin. Fuente: Wikipedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1. El proceso de instalaci´ on en Debian/Ubuntu y la preconfiguraci´ on de paquetes. . 4.2. La raiz del a ´rbol LDAP contiene dos unidades organizativas principales: alumnos y profesores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. La unidad organizativa de alumnos se subdivide a su vez en otras dos: alumnos de M´ ostoles y alumnos de Fuenlabrada. . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. La unidad organizativa de profesores contiene dos unidades organizativas que almacenan los objetos posixAccount y posixGroup. . . . . . . . . . . . . . . . 4.5. La aplicaci´ on wireshark muestra como se mandan los datos de autenticaci´ on en claro entre cliente y servidor, con nuestro esquema actual. . . . . . . . . . . . . . 4.6. Una vez establecida la conexi´ on segura entre cliente y servidor LDAP resulta m´ as dif´ıcil capturar datos de autenticaci´ on de usuarios. . . . . . . . . . . . . . . . . . 4.7. Reparto de carga entre varios servidores LDAP. . . . . . . . . . . . . . . . . . . . 4.8. La aplicaci´ on PHPLdapAdmin sobre nuestro esquema de servidores. . . . . . . . 4.9. P´ agina principal del Laboratorio de M´ ostoles . . . . . . . . . . . . . . . . . . . . 4.10. Autenticaci´ on en la p´ agina del Laboratorio mediante el directorio LDAP. . . . . . 4.11. Webmail de pantuflo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12. Webmail de bilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13. Gesti´ on de listas de correo en pantuflo con Mailman. . . . . . . . . . . . . . . . 4.14. La p´ agina de resumen de estado de Nagios para el Laboratorio de M´ ostoles. . . . 4.15. La p´ agina de problemas de Nagios muestra los problemas en algunas m´ aquinas. . 4.16. El parte de guerra de M´ ostoles muestra el estado de las estaciones. . . . . . . . .

xiii

. 50 . 55 . 55 . 56 . 60 . . . . . . . . . . .

62 63 68 78 80 86 87 87 93 93 94

´INDICE DE FIGURAS

´INDICE DE FIGURAS

xiv

Indice de Listados

4.1. Generaci´ on de un CD personalizado de Ubuntu para instalaci´ on autom´atica . . 4.2. Instalaci´ on del paquete dhcp a trav´es de apt-get . . . . . . . . . . . . . . . . 4.3. Fichero de configuraci´ on dpchd.conf. Configuraci´on de subred. . . . . . . . . . 4.4. Fichero de configuraci´ on dpchd.conf. Configuraci´on de host. . . . . . . . . . . 4.5. Instalaci´ on del servicio tfptd-hpa a trav´es de apt-get . . . . . . . . . . . . . . 4.6. Fichero de configuraci´ on /etc/default/tfptd-hpa. . . . . . . . . . . . . . . . 4.7. Reinicio del demonio tftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8. Descarga del kernel de arranque por red de Ubuntu Hardy . . . . . . . . . . . . 4.9. Fichero de configuraci´ on de Isolinux . . . . . . . . . . . . . . . . . . . . . . . . 4.10. Fichero de configuraci´ on de Isolinux . . . . . . . . . . . . . . . . . . . . . . . . 4.11. El fichero de preconfiguraci´on preseed.cfg. . . . . . . . . . . . . . . . . . . . . 4.12. El fichero de preconfiguraci´on preseed.cfg. . . . . . . . . . . . . . . . . . . . . 4.13. El fichero de preconfiguraci´on preseed.cfg. . . . . . . . . . . . . . . . . . . . . 4.14. El fichero de preconfiguraci´on preseed.cfg. . . . . . . . . . . . . . . . . . . . . 4.15. El fichero de preconfiguraci´on preseed.cfg. . . . . . . . . . . . . . . . . . . . . 4.16. El fichero de preconfiguraci´on preseed.cfg. . . . . . . . . . . . . . . . . . . . . 4.17. El fichero de preconfiguraci´on preseed.cfg. . . . . . . . . . . . . . . . . . . . . 4.18. El fichero de preconfiguraci´on preseed.cfg. . . . . . . . . . . . . . . . . . . . . 4.19. Instalaci´ on del paquete slapd a trav´es de apt-get . . . . . . . . . . . . . . . . 4.20. El fichero de plantilla de debconf para el paquete slapd. . . . . . . . . . . . . . 4.21. Preconfigurando el paquete slapd. . . . . . . . . . . . . . . . . . . . . . . . . . 4.22. Instalaci´ on del paquete slapd a trav´es de apt-get . . . . . . . . . . . . . . . . 4.23. Instalaci´ on de las bibliotecas necesarias para la autenticaci´ on PAM v´ıa LDAP . 4.24. Contenido del fichero nsswitch.conf para autenticaci´ on v´ıa LDAP . . . . . . . 4.25. Contenido del fichero pam ldap.conf para autenticaci´ on v´ıa LDAP . . . . . . 4.26. Contenido del fichero libnss-ldap.conf para autenticaci´ on v´ıa LDAP . . . . . 4.27. Instalaci´ on del conjunto de herramientas migrationtools a trav´es de apt-get 4.28. Modificando registros en el ´ arbol LDAP usando ldapadd . . . . . . . . . . . . 4.29. Instalaci´ on del paquete openssl a trav´es de apt-get . . . . . . . . . . . . . . . 4.30. Creaci´on de un certificado para nuestro servidor LDAP . . . . . . . . . . . . . 4.31. L´ıneas necesarias para proporcionar soporte SSL al servidor LDAP . . . . . . . 4.32. L´ıneas necesarias para proporcionar soporte SSL al servidor LDAP . . . . . . . 4.33. Reinicio del demonio slapd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.34. L´ıneas necesarias para proporcionar soporte SSL al servidor LDAP . . . . . . . 4.35. L´ıneas necesarias para proporcionar soporte SSL al servidor LDAP . . . . . . . 4.36. Instalaci´ on del demonio slurpd con apt-get . . . . . . . . . . . . . . . . . . . 4.37. A˜ nadiendo replicaci´ on a nuestro servidor LDAP . . . . . . . . . . . . . . . . . . xv

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43 43 44 44 45 45 45 46 46 47 47 47 48 48 49 49 49 50 51 51 51 52 56 57 57 57 58 58 60 60 61 61 61 63 64 65 65

INDICE DE LISTADOS

INDICE DE LISTADOS

4.38. A˜ nadiendo replicaci´ on a nuestro servidor LDAP . . . . . . . . . . . . . . . . . . . . 4.39. Copia de Seguridad de los datos del servidor LDAP . . . . . . . . . . . . . . . . . . 4.40. L´ınea de cron para automatizar las copias de seguridad de LDAP . . . . . . . . . . 4.41. Modificando la contrase˜ na de un usuario usando ldappasswd . . . . . . . . . . . . 4.42. Instalaci´ on del servidor NFS a trav´es de apt-get . . . . . . . . . . . . . . . . . . . 4.43. Instalaci´ on del gestor de raid mdadm usando apt-get . . . . . . . . . . . . . . . . 4.44. Automatizaci´ on en la creaci´ on del raid . . . . . . . . . . . . . . . . . . . . . . . . . 4.45. Automatizaci´ on en la creaci´ on del RAID . . . . . . . . . . . . . . . . . . . . . . . . 4.46. Instalaci´ on de Apache y del m´ odulo PHP5 para el servidor . . . . . . . . . . . . 4.47. Instalaci´ on del servidor Apache2 y del m´ odulo WebDav/Subversion para el servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.48. Creaci´on de un host virtual en Apache para el host pantuflo.escet.urjc.es . . . . 4.49. Descarga e Instalaci´ on de la herramienta MediaWiki . . . . . . . . . . . . . . . . 4.50. Configuraci´on de MediaWiki para autenticar usuarios usando LDAP . . . . . . . 4.51. Configuraci´on de Apache para dar soporte a p´aginas personales de usuarios . . . . 4.52. Instalaci´ on de la herramienta postfix usando apt-get . . . . . . . . . . . . . . . . 4.53. Instalaci´ on de los demonios necesarios para dar soporte POP3 e IMAP a pantuflo 4.54. Reiniciando el demonio dovecot tras su reconfiguraci´on . . . . . . . . . . . . . . . 4.55. Instalaci´ on de mailman usando apt-get . . . . . . . . . . . . . . . . . . . . . . . 4.56. Creaci´on de una nueva lista de mailman usando el comando newlist . . . . . . . 4.57. Instalaci´ on de la herramienta debmirror usando apt-get . . . . . . . . . . . . . . 4.58. Descargando la r´eplica de Ubuntu usando el comando debmirror . . . . . . . . . 4.59. Descargando la r´eplica de Debian usando el comando debmirror . . . . . . . . . . 4.60. Contenido del fichero /etc/apt/sources.list usando la r´eplica del Laboratorio . . 4.61. Instalaci´ on de la herramienta Nagios con apt-get . . . . . . . . . . . . . . . . . . . 4.62. Instalaci´ on de la herramienta Munin (servidor) con apt-get . . . . . . . . . . . . . 4.63. Instalaci´ on de la herramienta Munin (cliente) con apt-get . . . . . . . . . . . . . . 4.64. Instalaci´ on de la herramienta Munin (cliente) con apt-get . . . . . . . . . . . . . . 4.65. Creaci´on de una tabla en MySQL para almacenar la informaci´ on relativa a auditor´ıa de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.66. Script b´asico para registrar informaci´ on de auditor´ıa de usuarios . . . . . . . . . . 4.67. L´ınea de cron para la automatizaci´on de la auditor´ıa de usuarios en el sistema . . . 4.68. Monitor de alerta de conexiones nocturnas en el laboratorio . . . . . . . . . . . . . 4.69. Intentos de ataque de SSH mediante fuerza bruta o diccionario . . . . . . . . . . . 4.70. Instalaci´ on de la herramienta Denyhosts . . . . . . . . . . . . . . . . . . . . . . . A.1. El fichero de preconfiguraci´ on necesario para la instalaci´ on desatendida. . . . . . . A.2. Fichero de configuraci´ on de Isolinux para el arranque por red. . . . . . . . . . . . . A.3. Fichero de configuraci´ on de Isolinux para el arranque por red. . . . . . . . . . . . . B.1. Script backup-sapientin.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2. Script backup-nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.3. Script backup-usb.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.4. Script backup-usb.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.5. Script backup-ldap.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.6. Creaci´ on de la base de datos de Auditor´ıa . . . . . . . . . . . . . . . . . . . . . . . B.7. Script who-mostoles.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.8. Script sshatodos-alphas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.9. Script sshatodos-betas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.10.Script sshatodos-gammas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.11.Script sshatodos-deltas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

66 67 67 69 70 71 72 72 75 75 76 77 79 81 82 83 84 88 88 89 90 90 90 91 93 94 94 98 98 99 99 100 101 ii v vi x x xi xi xii xii xii xiii xiii xiii xiv

B.12.Script sshatodos.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.13.Script scpatodos-alphas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.14.Script scpatodos-betas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.15.Script scpatodos-gammas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.16.Script scpatodos-deltas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.17.Script scpatodos.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.18.Script john-laboratorio-mostoles . . . . . . . . . . . . . . . . . . . . . . . . . B.19.Script john-laboratorio-fuenla . . . . . . . . . . . . . . . . . . . . . . . . . . . C.1. Fichero de configuraci´ on /etc/ldap/slapd.conf . . . . . . . . . . . . . . . . . . C.2. Fichero de configuraci´ on /etc/bind9/named.conf . . . . . . . . . . . . . . . . C.3. Fichero de configuraci´ on /etc/bind9/db.pantuflo.es . . . . . . . . . . . . . . . C.4. Fichero de configuraci´ on /etc/bind9/named.conf . . . . . . . . . . . . . . . . C.5. Fichero de configuraci´ on /etc/apache2/sites-enabled/pantuflo.es . . . . . . C.6. Fichero de configuraci´ on /etc/apache2/sites-enabled/pantuflo.escet.urjc.es C.7. Fichero de configuraci´ on /etc/apache2/sites-enabled/webmail.pantuflo.es . C.8. Fichero de configuraci´ on /etc/apache2/sites-enabled/mysql.pantuflo.es . . C.9. Fichero de configuraci´ on /etc/postfix/main.cf . . . . . . . . . . . . . . . . . . C.10.Fichero de configuraci´ on /etc/postfix/master.cf . . . . . . . . . . . . . . . . . C.11.Fichero de configuraci´ on /etc/dovecot/dovecot.conf . . . . . . . . . . . . . . C.12.Fichero de configuraci´ on /etc/exports . . . . . . . . . . . . . . . . . . . . . . . C.13.Fichero de configuraci´ on /etc/postfix/master.cf . . . . . . . . . . . . . . . . . C.14.Fichero de configuraci´ on /etc/exports . . . . . . . . . . . . . . . . . . . . . . .

xvii

. . . . . . . . . . . . . . . . . . . . . .

xiv xiv xiv xiv xiv xv xv xviii xxii xxiv xxvi xxxi xxxii xxxii xxxiv xxxiv xxxv xxxvi xxxviii li lii lvi

INDICE DE LISTADOS

INDICE DE LISTADOS

xviii

Licencia de este documento

El presente documento se distribuye bajo la licencia Creative Commons Reconocimiento no comercial - compartir bajo la misma licencia 2.5, cuyos t´erminos pueden encontrarse en el Web1 . La presente licencia, le otorga permiso para: Copiar, distribuir y publicar libremente la obra Hacer obras derivadas Bajo las condiciones siguientes: Reconocimiento: Debe reconocer los cr´editos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra). No comercial. No puede utilizar esta obra para fines comerciales. Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra derivada, s´ olo puede distribuir la obra generada bajo una licencia id´entica a ´esta.

1

http://creativecommons.org/licenses/by-nc-sa/2.5/es/

1

INDICE DE LISTADOS

Proyecto Fin de Carrera

2

Universidad Rey Juan Carlos

Cap´ıtulo

1

Introducci´on El primer cap´ıtulo de este documento resume la motivaci´ on inicial de la realizaci´on de este proyecto (el porqu´e se lleva a cabo), as´ı como la estructura principal del presente documento. Posteriormente, se procede a enumerar cada una de las tecnolog´ıas que se utilizan en el proyecto, incluyendo todas las alternativas que exist´ıan para cada una de ellas (en el apartado Estado del arte). Este cap´ıtulo es meramente introductorio al proyecto desarrollado, dejando los detalles de los objetivos a desarrollar y la implementaci´ on de los mismos para cap´ıtulos posteriores.

3

´ DEL PROYECTO 1.1. MOTIVACION

1.1.

Motivaci´ on del proyecto

El presente documento resume casi toda la actividad realizada en un plazo de un a˜ no aproximadamente como administrador de sistemas de los Laboratorios de Linux de la ETSII1 y la ETSIT2 , en los Campus de M´ ostoles y Fuenlabrada, de la Universidad Rey Juan Carlos. Durante el desarrollo de este trabajo, se han completado una serie de hitos que si bien pertenecen al trabajo diario y normal de cualquier administrador de sistemas, puede adaptarse bastante bien a la realizaci´on de un Proyecto Fin de Carrera de una Ingenier´ıa Inform´atica, debido a que el desarrollo diario del trabajo ha sido dividido en fases, al igual que un proyecto: elaborar una lista y analizar las diferentes alternativas para cada uno de los objetivos, construir una lista de objetivos a desarrollar en un plazo determinado de tiempo, establecer un dise˜ no conveniente y escalable, y por u ´ltimo, implementar o implantar poco a poco cada uno de los objetivos propuestos. Por supuesto, un a˜ no da para mucho, para bastante m´ as que para los hitos que se documentan en la presente memoria. Sin embargo, debido a limitaciones de espacio, nos vemos obligados a documentar lo estrictamente necesario y lo m´ as fundamental.

1.2.

Estructura de este documento

En esta secci´ on se indica la divisi´ on en cap´ıtulos del presente documento, en los cuales se realizar´a un an´ alisis de cada una de las fases por las cuales ha avanzado el proyecto. Este documento se encuentra dividido en cinco cap´ıtulos, a saber: El cap´ıtulo de Introducci´ on, en el cual se presentan cu´ al es la motivaci´ on del proyecto y el estado del arte de cada una de las tecnolog´ıas que se han usado en el proyecto. El cap´ıtulo de Objetivos, en el cual se presentar´ an los objetivos principales que se han de desarrollar en el proyecto. El cap´ıtulo de Dise˜ no, El cap´ıtulo de Implantaci´ on, en el cual se implementan cada uno de los requisitos de los que consta el proyecto. El cap´ıtulo de Conclusiones, en el que se realiza un an´ alisis de todos los hitos alcanzados, los conocimientos adquiridos y todo el trabajo futuro que podr´ıa realizarse para mejorar o terminar de perfilar el trabajo realizado. Por u ´ltimo, en los Ap´ endices del presente documento, se incluye el c´ odigo fuente (enti´endase por c´odigo fuente en este proyecto todos aquellos ficheros de configuraci´ on y scripts de shell que se han desarrollado) desarrollado en el proyecto. Junto con el presente documento se adjunta un soporte electr´onico en CD en el que puede encontrarse la presente memoria as´ı como todo el c´odigo fuente desarrollado en el proyecto.

1.3.

Estado del arte

En este apartado vamos a analizar todas aquellas tecnolog´ıas que vamos a tocar en este proyecto. En este proyecto de hecho, van a ser muchas las tecnolog´ıas, aplicaciones, servidores y servicios que se van a facilitar a los usuarios de nuestro sistema. Como ser´ıa pr´acticamente 1 2

Escuela Superior de Ingenier´ıa Inform´ atica Escuela T´ecnica Superior de Ingenier´ıa de Telecomunicaciones

Proyecto Fin de Carrera

4

Universidad Rey Juan Carlos

´ CAP´ITULO 1. INTRODUCCION imposible realizar un an´ alisis del estado del arte de cada una de ellas, nos vamos a centrar solamente en realizar un breve an´ alisis de los sistemas de instalaciones desatendidos, por un lado, ya que uno de nuestros objetivos primordiales (el que nos llevar´ a m´ as tiempo) ser´a la implementaci´ on de un sistema de instalaciones completamente desatendido que nos haga olvidarnos del tedioso proceso de tener que instalar aproximadamente 200 estaciones de usuario. Evidentemente para ello, partimos de la base que estas instalaciones se realizan de sistemas Linux, y no hemos ca´ıdo en la cuenta que hoy en d´ıa existen multitud de distribuciones que ofrecen este grandioso sistema operativo listo para su instalaci´ on. Aunque son pocas las distribuciones que tienen m´ as fama hoy en d´ıa, ser´a necesario enumerar las bondades y defectos de las m´ as conocidas (principalmente, Debian GNU/Linux, Ubuntu, Red Hat Linux y SuSE). Por u ´ltimo, y dado que nuestro sistema albergar´ a un gran n´ umero de cuentas de usuario, ser´a tarea obligada decidir acerca de qu´e sistema de cuentas de usuario en red es m´ as adecuado para nuestras necesidades, y por supuesto, dotar a este sistema de cuentas de un mecanismo de almacenamiento de ficheros adecuado (obviamente, si tenemos un sistema de cuentas en red, el medio de almacenamiento de informaci´ on deber´a estar en red tambi´en). Por u ´ltimo, y para no extendernos demasiado, realizaremos un breve an´ alisis de las aplicaciones que dotan de funcionalidad de correo electr´onico a nuestro sistema (tanto de recogida como de entrega). De esta manera dotaremos a nuestro entorno con la funcionalidad de que los usuarios sean capaces de recibir correo electr´onico en sus cuentas, y ´estos tambi´en sean capaces de poder descargar este correo en sus ordenadores personales. Una vez que todos estos sistemas se encuentran perfectamente configurados y funcionando, nuestra labor se centrar´ a en la monitorizaci´ on de todos estos servicios. Para ello, instalaremos una herramienta de monitorizaci´ on que de cuenta cuando se produce cualquier tipo de problema o ca´ıda de un servicio concreto, alertando a las personas oportunas. Estos herramientas ser´an discutidas en el apartado Herramientas de monitorizaci´ on.

1.3.1.

Distribuciones de Linux

En primer lugar, vamos a realizar un breve repaso por las distribuciones de Linux m´ as usadas hoy en d´ıa. Cuando hablamos de Linux, en el sentido m´ as general de la palabra, nos referimos al kernel o n´ ucleo del Sistema Operativo. El kernel de Linux es el mismo para todas las distribuciones (normalmente, m´ınimamente modificado por la distribuci´on) y puede ser descargado de forma independiente desde Internet3 e instalado en cualquier distribuci´on sin muchas dificultades. Cuando hablamos de distribuci´ on de Linux nos referimos al conjunto formado por el kernel, las aplicaciones (que incluya de forma opcional el equipo desarrollador de la distribuci´on en concreto) junto con un proceso de instalaci´ on. En este sentido, hoy en d´ıa hay miles de distribuciones de Linux4 que son usadas por millones de usuarios alrededor del mundo. Sin embargo, hay algunas que merecen especial atenci´on, y que est´an clasificadas como las m´ as usadas o m´ as populares hoy en d´ıa. En esta clasificaci´on, se encuentran Red Hat Linux, SuSE o Debian GNU/Linux. Seg´ un podemos comprobar en el cuadro 1.1, la distribuci´on m´ as usada hoy en d´ıa es Debian (18.84 %), seguida por Ubuntu (16.43 %), SuSE (9.32 %), Slackware (8.35 %) y gentoo (8.07 %), entre otras. Se omite en este resultado el indicado por otras distribuciones mostrado en la tabla.

Es necesario indicar que las estad´ısticas de uso por distribuciones mostradas en la tabla 1.1 se realizan a partir de los usuarios registrados en el sitio del cual se ha obtenido la estad´ıstica. La tabla 1.2 muestra su estad´ıstica particular sobre las diez distribuciones m´ as usadas (en el 3 4

http://www.kernel.org http://distrowatch.com/index.php?language=ES

A. Guti´errez Mayoral

5

ETSI Inform´atica

1.3. ESTADO DEL ARTE Distribuci´ on CentOS Kubuntu Mandriva Mandrake Red Hat Fedora Core Gentoo Slackware SuSE Ubuntu Debian GNU/Linux Others

Uso 0.98 % 1.50 % 2.01 % 4.27 % 6.70 % 6.93 % 8.07 % 8.35 % 9.32 % 16.43 % 18.84 % 18.80 %

Cuadro 1.1: Distribuciones m´ as usadas en la actualidad. Fuente: LinuxCounter Distribuci´ on Ubuntu openSUSE Mint PCLinuxOS Fedora Debian Sabayon Mandriva CentOS Gentoo

N´ umero de visitas u ´ ltimo mes 1944 1557 1351 1053 1036 923 853 776 629 611

Cuadro 1.2: Distribuciones m´ as usadas en la actualidad. Fuente: DistroWatch u ´ltimo mes), colocando tambi´en a Ubuntu y Debian entre los primeros puestos. En este caso se han obtenido los datos del portal DistroWatch 5 . Como vemos, las distribuciones mayoritarias son Debian GNU/Linux y Ubuntu, seguidas muy de cerca por SuSE, Gentoo y Fedora, entre otras. La decadencia de Red Hat en los u ´ltimos a˜ nos queda presente en la estad´ıstica. La distribuci´on que hace a˜ nos ocupaba los primeros puestos de uso entre los usuarios ha visto comido su terreno a favor de Ubuntu y SuSE. Quiz´a los cambios en la organizaci´on interna de Red Hat (que veremos a continuaci´ on) y la aparici´on de Ubuntu tuvo como precio la p´erdida de un gran n´ umero de usuarios. En definitiva, existen multitud de distribuciones hoy en d´ıa, de las cuales s´ olo unas cuantas alcanzan los primeros puestos en n´ umero de usuarios y en popularidad. En concreto, en los Laboratorios de Linux de la Universidad se ha usado Debian GNU/Linux desde que comenz´ o su andadura, hasta hace poco tiempo, que se tom´ o la decisi´ on de pasar a Ubuntu. A continuaci´ on vamos a realizar un breve repaso por las distribuciones m´ as usadas o m´ as populares. En concreto, Debian GNU/Linux, como distribuci´on que usaremos en aquellas m´ aquinas que presten su funci´on de servidor. A continuaci´ on, Ubuntu, distribuci´on que usaremos en las estaciones de trabajo de los laboratorios. Por u ´ltimo, detallaremos las razones que nos llevan a descartar otras distribuciones como soluci´on adoptada tanto en los servidores de los laboratorios como en las estaciones, haciendo hincapi´e principalmente en las desventajas, ya que 5

http://www.distrowatch.com

Proyecto Fin de Carrera

6

Universidad Rey Juan Carlos

´ CAP´ITULO 1. INTRODUCCION son propuestas que en un principio se decide descartar. Debian GNU/Linux El proyecto Debian surge aproximadamente en el a˜ no 1993, de la mano de Ian Murdock como l´ıder del proyecto, y con un objetivo principal: crear una distribuci´on de Linux que separara claramente el software libre del no libre. Adem´ as, el modelo de desarrollo de la distribuci´on es completamente ajeno a objetivos empresariales o comerciales, dejando de la mano de los usuarios de la misma la liberaci´on de las versiones de la distribuci´ on. En principio, la adaptaci´ on de Debian m´ as conocida y m´ as desarrollada hasta la fecha es la que se basa en el n´ ucleo Linux, com´ unmente llamada Debian GNU/Linux, aunque existen otras ramas de desarrollo basadas en otros n´ ucleos, como Hurd, NetBSD o FreeBSD. El proyecto Debian se rige por unas directrices muy estrictas en cuanto a la organizaci´on del mismo: un contrato social establece cual es la base del proyecto y como sus usuarios deben tratar la mayor´ıa de los asuntos, unas directrices de software establecen qu´e software es adecuado o no para la distribuci´on, as´ı como la Constituci´ on de Debian establece cual es la jerarqu´ıa interna de la organizaci´on y como se llevan a cabo y se toman las decisiones principales. Estas normas establecen cuales son los poderes principales del l´ıder del proyecto (el que est´e vigente en ese momento) y las responsabilidades de los desarrolladores en general. Existe una figura visible dentro de la organizaci´on, el l´ıder de la misma. Esta figura es elegida por los propios integrantes de la comunidad Debian (principalmente, desarrolladores) y aunque tiene unas atribuciones principales m´ as all´ a de las de cualquier desarrollador, est´a lejos de ser una decisi´ on absoluta que tengan que acatar el resto de desarrolladores. El l´ıder de la comunidad se elige una vez al a˜ no, siendo el primero Ian Murdock (a˜ no 1993-1996) y el u ´ltimo (l´ıder actual) Steve McIntyre (abril 2008-hoy). Respecto a los detalles t´ecnicos, cabe rese˜ nar que Debian ha conseguido su fama en los u ´ltimos a˜ nos, cuando el n´ umero de arquitecturas soportadas se ha elevado considerablemente en los u ´ltimos a˜ nos, as´ı como el n´ umero de paquetes incluido por defecto dentro de la distribuci´on. Actualmente, son soportadas 11 arquitecturas diferentes de hardware en Debian GNU/Linux, y el n´ umero de paquetes se eleva por encima de 18.000. Actualmente, la distribuci´on se encuentra en la versi´ on 4.0 de manera estable (´ ultima versi´ on estable liberada), cuyo nombre en clave se denomina Etch. Como curiosidad, los nombres de liberaci´on de las versiones de Debian hacen alusi´ on a personajes de la trilog´ıa de Disney/Pixar Toy Story, asign´andose un nuevo nombre cuando se crea una nueva versi´ on de pruebas. La organizaci´on de desarrollo de Debian se divide en tres ramas de desarrollo principales: la rama estable, la cual es fruto de la congelaci´ on de una rama en pruebas (llega un momento que la estabilidad alcanzada en la rama en pruebas supone que no se a˜ nadan ni nuevos paquetes ni nueva funcionalidad a la correspondiente rama, creando una nueva versi´ on de la distribuci´on); la rama de pruebas o testing, la cual se compone de todos los paquetes que han ido reduciendo su n´ umero de fallos provenientes de la rama inestable. Por u ´ltimo, la rama inestable, comprende el desarrrollo activo y principal de la distribuci´on. En ella se encuentran los paquetes reci´en a˜ nadidos a la distribuci´on donde se comprueba su estabilidad, el n´ umero de fallos y la integraci´on con el resto de paquetes de la distribuci´on. En particular y respecto a las diferentes ramas de desarrollo de la distribuci´on, siempre se recomienda el uso de la rama estable para uso en producci´ on (debido a la estabilidad y al nivel de depuraci´on que ha alcanzado esta versi´ on) y al uso de la rama inestable si se quiere estar m´ as al d´ıa en cuanto a versiones de un paquete en concreto, incluido dentro de la distribuci´on. Sin embargo, usar la rama inestable puede convertirse en un juego peligroso, ya que de un d´ıa para otro nuestro ordenador puede dejar de funcionar o puede producirse un problema grave que puede acabar en una reinstalaci´on si no se tienen los conocimientos necesarios para solucionar el problema y volver a la situaci´on original. Los usuarios avanzados de Debian A. Guti´errez Mayoral

7

ETSI Inform´atica

1.3. ESTADO DEL ARTE conocen esta situaci´on y normalmente, siempre que su distribuci´on se encuentra situada en la rama inestable, suelen tener mucho cuidado con las actualizaciones o instalaciones de paquetes nuevos. Existe dos ventajas principales de la distribuci´on Debian GNU/Linux sobre la mayor´ıa de distribuciones m´ as usadas hoy en d´ıa. La principal, es la estabilidad de la rama estable de la distribuci´on. La independencia de Debian frente a intereses comerciales hacen que los tiempos de liberaci´on de la distribuci´on sean lo suficientemente grandes como para que de tiempo a que la distribuci´on sea revisada todo lo necesario como para que tenga un nivel de calidad m´ as que aceptable. Estos tiempos, de un a˜ no normalmente (como m´ınimo) son excesivos para usuarios que desean tener su software al d´ıa: u ´ltima versi´ on de escritorio, u ´ltima versi´ on del servidor web Apache, etc´etera. Sin embargo, estos usuarios deben saber que la rama de desarrollo de Debian que est´an usando no es la m´ as adecuada para ellos, ya que los tiempos de liberaci´on tan grandes facilitan que la distribuci´on sea una de las m´ as estables y seguras frente a otras m´ as conocidas, en detrimento de usar las versiones m´ as actuales y novedosas en lo que a software se refiere. Es por ello que la rama estable de Debian GNU/Linux ha sido relegada al plano del servidor principalmente, dejando otras ramas para el escritorio y el uso menos profesional del equipo en cuesti´ on. La otra ventaja que nos ocupa es la herramienta de instalaci´ on de software, la herramienta apt6 . Esta herramienta, muy conocida entre los usuarios de la distribuci´on y todas aquellas que se apoyan en ´esta (Knoppix, Ubuntu y dem´as) facilita enormemente la instalaci´ on, configuraci´ on y eliminaci´on de software en Debian (y en todas aquellas distribuciones Linux que lo hayan acogido como herramienta de instalaci´ on de software). En principio, esta herramienta funciona en l´ınea de comandos, aunque ha medida que ha pasado el tiempo se han dise˜ nado 7 interfaces u ´nicos o front-ends que facilitan el uso de la herramienta para usuarios noveles . La herramienta apt es capaz de funcionar con repositorios de software a lo largo de Internet, facilitando as´ı la labor de localizaci´on de software adicional. De forma oficial, existen repositorios oficiales para Debian que contienen los paquetes incluidos en la distribuci´on en cada una de las ramas. Para que este sistema sea escalable, estos repositorios se encuentran replicados a lo largo del mundo en mirrors o espejos locales distribuidos en cada regi´ on del planeta. Es com´ un que cada Universidad cuente con el suyo propio (como es el caso de la nuestra). Adem´ as, es posible que los usuarios construyan o creen sus propios repositorios con aquellos paquetes que hayan construido particularmente con las aplicaciones que ellos hayan considerado oportuno. El resto de usuarios del planeta puede instalar esas aplicaciones sin m´ as que indicar a la herramienta apt cual es la localizaci´on del recurso del correspondiente repositorio (normalmente, a trav´es de una URL com´ un). El uso de apt es casi una herramienta fundamental en el uso diario del sistema, facilitando la tarea de instalaci´ on de software enormemente, tanto al administrador como al usuario de a pi´e. Tanto, que hoy en d´ıa, la instalaci´ on de software en sistemas Linux a trav´es de los fuentes (usando el c´odigo fuente, compil´ andolo de forma manual) a quedado relegada a un plano muy lejano y casi ya no es usada por los usuarios, tanto por la incomodidad de este m´etodo como por el n´ umero de errores que normalmente se suelen producir. Es por ello que realizamos la elecci´ on de Debian GNU/Linux como sistema base para nuestros servidores: la estabilidad de la distribuci´on en su rama estable para sistemas en producci´ on hace que nos decantemos por esta opci´ on, dejando para el escritorio distribuciones que se apoyen en Debian (principalmente, por la estabilidad y las herramientas de instalaci´ on de software) pero que incluyan software m´ as actual de cara al usuario. Con el paso del tiempo han sido muchas las distribuciones que han surgido tomando Debian GNU/Linux como distribuci´on base. La estabilidad y la organizaci´on de la distribuci´on hace que muchas distribuciones adopten o partan de ella para crear nuevas distribuciones. Las m´ as 6 7

APT son las siglas de Advanced Packaging Tool o Herramienta de empaquetamiento avanzado. Los m´ as conocidos son Synaptics (para el escritorio Gnome) o Adept (para KDE)

Proyecto Fin de Carrera

8

Universidad Rey Juan Carlos

´ CAP´ITULO 1. INTRODUCCION conocidas, Knoppix o Ubuntu, que comentaremos a continuaci´ on.

Ubuntu Ubuntu8 es una de las distribuciones cuyo cociente entre tiempo y popularidad ha sido m´ as pronunciado. Basada en Debian GNU/Linux como distribuci´on base, ha ido desplazando a los usuarios m´ as confesos y ac´errimos a la distribuci´on base hasta Ubuntu como sistema principal de escritorio basado en Linux. Los pilares ideol´ogicos principales en los que se basa Ubuntu son la facilidad y usabilidad a la hora de usar el sistema operativo, as´ı como la regularidad en la liberaci´on de nuevas versiones (normalmente, cada seis meses, en Abril y en Octubre). Est´a desarrollada por Canonical, apoyada por el empresario sudafricano Mark Shuttleworth. El proyecto surgi´o en el a˜ no 2004 aproximadamente, con una financiaci´ on de unos diez millones de d´olares. En la distribuci´on participan muchos desarrolladores de Debian y de Gnome, estos primeros decepcionados con el modo de funcionamiento interno de la distribuci´on Debian, por aquel entonces una de las m´ as usadas, tanto en el escritorio como en el servidor. Estos desarrolladores buscaron apoyo en el empresario Mark Shuttleworth, que apreci´o la idea del proyecto y lo apoy´o econ´ omicamente. Tras varios meses de trabajo y un breve per´ıodo de pruebas, la primera versi´ on de Ubuntu (Warty Warthog) fue lanzada el 20 de octubre de 2004. Como detalles t´ecnicos relevantes, podemos destacar que Ubuntu conserva la mayor´ıa de las ventajas de Debian GNU/Linux, manteniendo como principal la herramienta de instalaci´ on de software apt. Adem´ as, los periodos de liberaci´on de Ubuntu son bastante m´ as cortos, lo que hace que las versiones que se incluyen en la distribuci´on sean bastante actuales. Normalmente, Ubuntu suele incluir la u ´ltima versi´ on de los escritorios Gnome y KDE (sino la u ´ltima, una de las m´ as actuales) as´ı como las u ´ltimas versiones de los paquetes de software m´ as importantes. Ubuntu no soporta tanto arquitecturas como Debian: se incluyen de manera oficial soporte para dos arquitecturas: Intel x86 y AMD64, sin embargo ha sido portada a m´ as plataformas de forma extraoficial, la descontinuada PowerPC, Sparc, o incluso la plataforma de videojuegos PlayStation 3 creada por Sony. Ubuntu es una de las distribuciones que incluye un CD Live!, que facilita que el usuario pueda probar la distribuci´on sin necesidad de realizar una instalaci´ on en el disco. Esta funcionalidad es bastante interesante para poder introducir nuevos usuarios en Linux sin necesidad de realizar nuevas instalaciones en sus sistemas. Una de las principales ventajas que hacen que nos decantemos por Ubuntu como sistema usado en las estaciones del Laboratorio es que, aparte de ser una distribuci´on basada en Debian (incluyendo todas sus ventajas, como apt), se incluyen las versiones m´ as actuales de software en cada liberaci´on, de forma que de cara a los usuarios disponemos de un sistema totalmente actual, no como pasaba anteriormente cuando las estaciones del Laboratorio se basaban en Debian GNU/Linux: los periodos de liberaci´on tan largos hac´ıan que una vez liberada la versi´ on estable, las versiones de escritorio, aplicaciones y dem´as estuvieran totalmente desactualizadas. Ubuntu al igual que Debian, ha servido como base para otras distribuciones: xUbuntu, kUbuntu o Edubuntu son distribuciones muy usadas en la actualidad y que est´an basadas en Ubuntu como distribuci´on base (al igual que Ubuntu se apoya en Debian). Estas distribuciones normalmente contienen pocas variaciones con respecto a la original, centr´andose normalmente en las aplicaciones incluidas o en el escritorio por defecto que se usa en cada una de ellas. 8

http://www.ubuntulinux.org

A. Guti´errez Mayoral

9

ETSI Inform´atica

1.3. ESTADO DEL ARTE SuSE La distribuci´on SuSE9 es una de las distribuciones Linux m´ as conocidas y m´ as usadas en la actualidad. Est´a basada en la distribuci´on Slackware y entre las principales ventajas o virtudes de esta distribuci´on est´a la facilidad de instalaci´ on de la misma (contaba con un instalador gr´ afico hace bastante tiempo, cuando ninguna de las distribuciones Linux lo sol´ıan incluir) y un administrador gr´ afico del equipo llamado Yast, el cual facilita la labor de instalaci´ on de nuevo software y la configuraci´ on del equipo. En la actualidad, SuSE es propiedad de Novell, desde que la absorbi´o en 2004. En el a˜ no 2005, en la LinuxWorld, Novell, siguiendo los pasos de RedHat Inc., anunci´o la liberaci´on de la distribuci´on SuSE Linux para que la comunidad fuera la encargada del desarrollo de esta distribuci´on, que ahora se denomina openSUSE. Como detalles t´ecnicos, SuSE usa el escritorio KDE por omisi´on, aunque incluye tambi´en el escritorio Gnome. Como sistema de paquetes nativo, SuSE usa el sistema de paquetes RPM (Red Hat Package Manager), que es el sistema de paquetes que se incluye en la distribuci´on Red Hat/Fedora. Sin embargo, los cambios que ha sufrido esta distribuci´on a lo largo del tiempo as´ı como el sistema de gesti´ on de paquetes que usa (RPM) hace que descartemos esta distribuci´on para ser usada en nuestro entorno. Red Hat/Fedora Core Por u ´ltimo, realizaremos un breve an´ alisis de otra de las distribuciones m´ as conocidas en la actualidad. La distribuci´on Red Hat10 , posteriormente Fedora, ha sido una de las distribuciones que m´ as reconocimiento ha tenido en los u ´ltimos tiempos. En principio, existen dos versiones principales de esta distribuci´on: Red Hat Enterprise Linux, dirigida principalmente al mercado profesional, y Fedora Core, que surgi´o en el a˜ no 2003 cuando Red Hat Linux fue descontinuado. Digamos que esta divisi´ on es similar a la sufrida por SuSE, que mantiene una versi´ on comercial de su distribuci´on (Novell SuSE Enterprise) y su versi´ on gratuita, openSuSE. De forma similar, Red Hat ofrece su versi´ on comercial (Red Hat Enterprise Linux) y su versi´ on gratuita o libre (Fedora). Red Hat Software Inc. fue fundada en el a˜ no 1994, y es conocida por aportar numerosas contribuciones y luchar en pro del software libre. En esos a˜ nos la distribuci´on contaba con gran n´ umero de usuarios y gran popularidad. Sin embargo, el paso de los a˜ nos y la aparici´on de nuevas distribuciones con mayor estabilidad, mayor n´ umero de usuarios y de desarrolladores la ha relegado a un segundo plano, aunque sigue contando con un gran n´ umero de usuarios en la actualidad. En cuanto al plano t´ecnico no hay muchos detalles que comentar. Red Hat Linux al igual que SuSE usa el sistema de paquetes RPM, un sistema de paquetes un tanto antiguo en comparaci´on con el sistema de paquetes apt. El sistema de paquetes es algo tan fundamental dentro de una distribuci´on que es motivo de descartar esta distribuci´on para su uso en el laboratorio al igual que SuSE.

1.3.2.

Sistemas de instalaci´ on desatendidos

Dado que uno de nuestros objetivos principales es dise˜ nar un proceso de instalaci´ on desatendida y completamente automatizado, vamos a analizar los sistemas de instalaci´ on desatendidos m´ as usados hoy en d´ıa por administradores de un n´ umero muy elevado de m´ aquinas. En concreto y para el caso que nos ocupa, partimos de la base que necesitamos un m´etodo que nos permita instalar en 300 estaciones de usuario aproximadamente (160 en el Campus de M´ ostoles 9 10

http://es.opensuse.org/Bienvenidos a openSUSE.org http://www.redhat.com/

Proyecto Fin de Carrera

10

Universidad Rey Juan Carlos

´ CAP´ITULO 1. INTRODUCCION y 140 en el de Fuenlabrada) de la forma m´ as r´apida y c´omoda posible, de cara al administrador de las estaciones y de las instalaciones masivas. Clonaci´ on de disco duro La clonaci´ on de una partici´on del disco o del disco duro completo es hoy en d´ıa uno de los sistemas m´ as usados a la hora de realizar instalaciones masivas, bien se trate de entornos docentes o de entornos empresariales, en los que se debe instalar una m´ aquina r´eplica de una m´ aquina inicial. Este sistema copia bit a bit todos los datos de una partici´on en un fichero para el posterior volcado a la inversa en otra partici´on o disco duro. Dependiendo de la aplicaci´ on con la que estemos realizando la clonaci´ on, este proceso ser´a m´as o menos r´apido, y nos permitir´a una mayor flexibilidad a la hora de realizar la clonaci´ on. Hoy en d´ıa, las aplicaciones m´ as modernas que permiten realizar clonaciones de disco duro, permiten: Lectura de sistemas de ficheros ext2/ext3 (aspecto fundamental en nuestro caso) Compresi´on de los datos para que ocupen menos espacio. Los sistemas de clonaci´ on m´ as antiguos requer´ıan un espacio en disco igual o mayor al del disco duro que se iba a clonar. Almacenamiento en red de los datos. La imagen del disco duro clonado pod´ıa almacenarse en un servidor FTP, o en un directorio compartido de Windows. Posteriormente, cuando se realizaba el proceso inverso, los datos pod´ıan ser descargados de estos servicios en red. Clonaci´on de todo el disco duro o de una partici´on en concreto. Los sistemas m´ as modernos permiten elegir entre clonar el disco duro al completo, o solamente una partici´on del disco. Rapidez de la clonaci´ on del disco duro o partici´on. Los sistemas m´ as antiguos empleaban una gran cantidad de tiempo para realizar una clonaci´ on de un disco, con el consiguiente perjuicio para el administrador. Hoy en d´ıa, existe un gran abanico de aplicaciones con diferentes licencias pensadas para realizar clonaciones de discos duros o particiones para realizar copias de seguridad de datos, realizar instalaciones masivas, etc´etera. Las aplicaciones comerciales m´ as conocidas hoy en d´ıa pueden ser Acronis True Image11 o Norton Ghost12 . Ambas aplicaciones est´an disponibles a trav´es de los servicios inform´aticos de Campus, con una licencia totalmente funcional para nuestras necesidades. Sin embargo, el balance total entre las ventajas y desventajas entre este m´etodo y el posteriormente elegido como m´etodo principal de instalaci´ on, hace que nos decantemos finalmente por el m´etodo basado en ficheros de preconfiguraci´on. Existen otras aplicaciones con licencias libres que permiten realizar una clonaci´ on de disco duro. En el caso m´ as b´asico, el comando dd permite leer una partici´on y guardarla en un fichero. Sin embargo, este m´etodo tan rudimentario adolece de ser muy lento, a parte de necesitar como m´ınimo el tama˜ no en disco de la partici´on para almacenar el fichero correspondiente. Entre los dos aplicaciones comerciales presentadas anteriormente, cabe destacar como ventajas principales la rapidez y el poco espacio que ocupa la imagen de un disco duro de cualquiera de los equipos que deseemos clonar. Adem´ as, la aplicaci´on Acronis True Image nos permite guardar las im´agenes de los discos duros que deseemos en un servidor FTP, con las ventajas que ello supone: cuando deseemos instalar un equipo a partir de una imagen, solamente debemos arrancarlo con el CD de la aplicaci´on, y seleccionar el servidor FTP donde se encuentran alojadas las im´agenes del 11 12

http://www.acronis.com/homecomputing/products/trueimage/ http://www.symantec.com/es/mx/norton/ghost

A. Guti´errez Mayoral

11

ETSI Inform´atica

1.3. ESTADO DEL ARTE equipo en cuesti´ on. Este mecanismo puede resultar muy c´omodo cuando el n´ umero de equipos que se desea instalar es muy bajo: pongamos, quince o veinte equipos, siendo generosos en la paciencia de la persona que vaya a ocuparse de las instalaciones. A mayor n´ umero de equipos, el proceso de instalaci´ on, puede resultar tedioso. En nuestro caso, disponiendo de 160 estaciones en el Campus de M´ ostoles y 140 en el Campus de Fuenlabrada, resulta pr´acticamente no asumible. Adem´ as de esta desventaja principal, hemos de a˜ nadir que las diferencias entre las estaciones principales del laboratorio supone que se deba almacenar una imagen por cada modelo de estaci´on, ya que la clonaci´ on asume que ´esta se realiza entre equipos id´enticos. En nuestro caso, disponemos en M´ ostoles de 3 tipos principales de hardware en las estaciones de usuario y de tres tipos en el Campus de Fuenlabrada. Es por ello que decidimos plantearnos otros mecanismos de instalaci´ on desatendida para realizar nuestro proceso de instalaci´ on autom´atica. Sin embargo, el m´etodo de la clonaci´ on de disco nos vendr´ a muy bien cuando tengamos que arreglar un disco que ha sido reemplazado (por ejemplo, por un problema de hardware) o cuando tengamos que instalar pocas m´ aquinas (una o dos) y el resto ya est´en instaladas completamente. La raz´on de esta elecci´ on es que el m´etodo de la clonaci´ on es muy r´apido, y no supone la puesta en marcha de infraestructura adicional (como es el caso de los ficheros de preconfiguraci´on, que estudiaremos posteriormente). En resumen, podr´ıamos decir que las ventajas y desventajas que aporta este m´etodo son: Como ventajas, el m´etodo de la clonaci´ on es r´ apido, sencillo y no requiere maquinaria adicional para ponerlo en marcha. Como desventajas, podemos afirmar que este m´etodo puede ser complejo en caso de que el n´ umero de estaciones sea elevado, exige hardware id´entico (al menos para una sola clonaci´ on) y que realiza una instalaci´ on no limpia del sistema. Ficheros de preconfiguraci´ on Por u ´ltimo, vamos a realizar un an´ alisis del uso de ficheros de preconfiguraci´on para realizar instalaciones masivas y completamente desatendidas. El m´etodo de los ficheros de preconfiguraci´on (el t´ermino anglosaj´on es preseeds o ficheros semilla). Este m´etodo, que se encuentra disponible en Debian (y sus derivados) a partir de la versi´ on de Sarge, consiste en incluir en un fichero de texto todas las indicaciones necesarias para la instalaci´ on de o bien un sistema Debian completo (fichero de preconfiguraci´on para el proceso de instalaci´ on) o bien un paquete en concreto. A trav´es de este m´etodo, conseguimos que todas las indicaciones o preguntas que el proceso de instalaci´ on realiza al usuario, sean introducidas autom´aticamente sin necesidad de la interacci´ on del usuario en ning´ un momento en el proceso de instalaci´ on (siempre que todas las respuestas sean introducidas en el fichero correspondiente). El fichero de semilla o fichero preconfiguraci´on es un fichero de texto legible por humanos, en el que se incluyen la preconfiguraci´on de cada pregunta en un formato concreto. Este formato, si bien no es a priori puede resultar un tanto complejo, es bastante autom´atico en cuanto a la forma de construir indicaciones para un proceso de instalaci´ on. Cada indicaci´on se incluye en una l´ınea del fichero de texto, y contiene una especificaci´ on en la forma clave/valor para cada paquete a instalar, incluido el proceso de instalaci´ on (el proceso debian installer ). Una de las ventajas principales de este m´etodo radica en que se puede automatizar todo el proceso de instalaci´ on al completo, sin m´ as que responder o incluir todas las indicaciones en el fichero de preconfiguraci´on correspondiente. Adem´ as, estaremos realizando una instalaci´ on limpia de un sistema (a diferencia del procedimiento de la clonaci´ on de una partici´on o del disco duro). Esta instalaci´ on sin duda es m´ as conveniente para el sistema que replicar una instalaci´ on ya hecha. Por otra parte, los ficheros de preconfiguraci´on son muy flexibles en el sentido que pueden Proyecto Fin de Carrera

12

Universidad Rey Juan Carlos

´ CAP´ITULO 1. INTRODUCCION estar almacenados en un CD ya prefabricado (un CD de Debian en el que se ha modificado el arranque) o bien se pueden incluir en una memoria USB o incluso en la red, localizadas por una URL. Este m´etodo es especialmente potente y flexible, ya que facilita que el sistema pueda ser instalado completamente por la red, sin necesitar tan siquiera un CD de Debian para realizar la instalaci´ on. Solamente necesitaremos la imagen correspondiente del arranque por red de la versi´ on correspondiente que queramos instalar (disponible en cualquiera de los mirrors de Debian) y unas peque˜ nas modificaciones en el arranque para que ´este use un fichero de preconfiguraci´on. Una vez hecho esto, tendremos un proceso de instalaci´ on que no necesita soporte de instalaci´ on (un CD, como tradicionalmente se ha instalado el Sistema Operativo) ni ninguna interacci´ on con el usuario: tan s´ olo ser´a necesario reiniciar el equipo y seleccionar arranque por red en la placa base para que el proceso comience, se instale correctamente y cuando haya finalizado el proceso, el equipo se reinicie y muestre el nuevo sistema al usuario. Como vemos, la idea es bastante atractiva: tan s´ olo requiere reiniciar el equipo para realizar una instalaci´ on. En el cap´ıtulo Implantaci´ on veremos los detalles t´ecnicos de este proceso, que si bien no requiere tan s´ olo de fichero de preconfiguraci´on en cuesti´ on (es necesario otras tecnolog´ıas paralelas, como arranque por red de Linux, puesta en marcha de un servidor que despache direcciones IP, etc´etera) no es complicado en exceso. Podemos resumir que el proceso de instalaci´ on tiene las siguientes ventajas y desventajas principales: Como ventaja, principalmente es la escasa interacci´ on con el usuario que necesita (por no decir nula). La u ´nica acci´on que se requiere por parte del usuario es reiniciar el equipo para que comience la instalaci´ on (y esta acci´on no pertenece propiamente al proceso de instalaci´ on). La instalaci´ on del sistema es totalmente limpia (se formatea el disco duro, se crea la tabla de particiones, se instala el sistema completo partiendo de cero, se configuran todos los paquetes una vez ´este se ha instalado, etc´etera), lo cual es una ventaja con respecto al m´etodo de la clonaci´ on. Por u ´ltimo el poder realizar instalaciones por red es una ventaja bastante importante, en los tiempos en los que nos encontramos, en el que el uso de soportes de almacenamiento f´ısicos cada vez est´a menos extendido. Como desventaja, podemos indicar que si bien este proceso es muy usado hoy en d´ıa por parte de administradores de sistemas, la documentaci´ on del m´etodo de preconfiguraci´on es bastante escasa, por no decir nula. Si bien ya empiezan a existir proyectos de Debian dedicados u ´nicamente a esta labor13 , hace un a˜ no aproximadamente resultaba bastante complicado encontrar recetas de instalaciones desatendidas usando ficheros de preconfiguraci´on. Tambi´en cabe rese˜ nar que el m´etodo de ficheros de preconfiguraci´on suele requerir la puesta en marcha y configuraci´ on de tecnolog´ıas paralelas que no tienen que ver mucho con el proceso de instalaci´ on, como veremos en el cap´ıtulo Implantaci´ on.

1.3.3.

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/

A. Guti´errez Mayoral

13

ETSI Inform´atica

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 u ´nica 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 Proyecto Fin de Carrera

14

Universidad Rey Juan Carlos

´ CAP´ITULO 1. INTRODUCCION 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 u ´nica 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 u ´nicamente 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

A. Guti´errez Mayoral

15

ETSI Inform´atica

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 u ´ltimo, 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 u ´nicamente 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 u ´ltimo, 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 RFC son las siglas de Request for comments y es un documento t´ecnico que describe el comportamiento de un protocolo de red. 17 http://www.faqs.org/rfcs/rfc2251.html es la RFC de LDAP en su versi´ on 3. 16

Proyecto Fin de Carrera

16

Universidad Rey Juan Carlos

´ CAP´ITULO 1. INTRODUCCION 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.

1.3.4.

Sistemas de ficheros en red

Dado que estamos trabajando con un entorno de red basado en estaciones de trabajo en las que los usuarios pueden iniciar su sesi´ on y trabajar con un conjunto de ficheros (a los que llamaremos directorio personal de usuario o ficheros de usuario) es necesario implantar un sistema de ficheros en red que sea capaz de dotar al entorno de un servicio de ficheros en red que permita a los usuarios poder usar sus ficheros independientemente de la estaci´on en la que se encuentren trabajando. En este sentido, no existen muchas alternativas para poder implementar esta funcionalidad dentro de un sistema operativo Linux o Unix. Una de las m´ as conocidas y la m´ as usada por excelencia, es el sistema de ficheros en red NFS18 . En los u ´ltimos a˜ nos se ha extendido una alternativa a esta opci´ on, el sistema de ficheros usado en comparticiones con sistemas operativos Windows. Esta soluci´on suele ser adoptada en entornos h´ıbridos en los que se trabaja tanto con sistemas Unix/Linux como con sistemas Windows. En principio no es nuestro caso y por tanto optaremos por no implantar tal sistema, aunque su an´ alisis resulta interesante por si en alg´ un momento es necesario plantear la posibilidad de instalar sistemas Windows en el Laboratorio ante el requerimiento de software docente de alguna asignatura. Cabe rese˜ nar que aunque son sistemas de ficheros en principio muy diferentes, las dos opciones pueden funcionar perfectamente en conjunci´ on: si un host arranca un sistema operativo Windows, 18

NFS son las siglas de Network File System o Sistema de Ficheros en Red.

A. Guti´errez Mayoral

17

ETSI Inform´atica

1.3. ESTADO DEL ARTE usar´ a el sistema de ficheros en red que facilite el servidor Samba, y si arranca el sistema operativo Linux o cualquier otro basado en Unix, usar´ a el an´ alogo basado en NFS. Por tanto, los directorios ser´an lo mismo, simplemente la manera de servirlos ser´a diferente: en un caso se usar´ a el sistema de ficheros para comparticiones Windows (Samba) y en otro, para sistemas Linux (NFS). NFS El sistema de ficheros NFS (Sistema de ficheros en red) es un protocolo a nivel de aplicaci´ on seg´ un el modelo OSI). Este sistema de ficheros en red es muy usado en entornos de red en el que se trabaja con un modelo distribuido de estaciones de trabajo que necesitan acceder a un mismo directorio que se encuentra alojado en un servidor (como el caso que nos ocupa). Esto posibilita que las estaciones de trabajo puedan acceder a este directorio como si de un directorio local se tratara. Originalmente fue desarrollado en 1984 por Sun Microsystems, con el objetivo de que fuera independiente del Sistema Operativo, y el protocolo de transporte. Esto fue posible ya que fue implementando bajo los protocolos XDR y ONC-RPC. El conjunto de aplicaciones que hace posible el uso del protocolo NFS suele estar incluido por defecto en la mayor´ıa de las distribuciones Linux actuales. El sistema NFS suele estar compuesto de un servidor, y uno o m´ as clientes. Los clientes acceden de forma remota a los directorios ofrecidos o exportados por el servidor, donde se encuentran almacenados los datos. De esta forma, los usuarios de nuestro sistema no necesitar´ an disponer de un directorio HOME (el directorio personal de usuario en un sistema Linux) en cada una de las estaciones Linux en las que inicien su sesi´ on, sino que todos los directorios HOME se encontrar´ an en el servidor de ficheros NFS y los usuarios importar´ an o montar´ an (t´ermino muy usado en sistemas Linux que hace suele hacer alusi´ on a empezar a usar un sistema de ficheros) este directorio en la estaci´on de trabajo en la que se encuentren. No es objetivo de esta secci´ on enumerar los aspectos t´ecnicos del protocolo, ya que estos se encuentran descritos en la RFCs correspondientes19 . Las pruebas que se han llevado a cabo en el entorno demuestran que este protocolo resuelve bastante bien la tarea de servir un directorio HOME a todas las estaciones del Laboratorio (unas 160 aproximadamente) sin que se produzcan retardos excesivos en las comunicaciones o cuellos de botella. De hecho, solamente es una sola m´ aquina es la que lleva a cabo esta tarea, sin que sea necesario la divisi´ on del servicio para su escalabilidad. Dado que el sistema NFS es un sistema nativo y propio de sistemas operativos Unix/Linux, y debido a que no disponemos de equipos Windows en el conjunto de estaciones de trabajo que conforman nuestra red de ´ area local (y por tanto no es necesario servir a trav´es de un sistema de ficheros de Windows los directorios personales de los usuarios) ser´a la soluci´on que adoptemos en el entorno que nos ocupa. Samba Samba es una implementaci´ on de software libre del protocolo de archivos compartidos de Windows para sistemas operativos tipo Unix/Linux. Antiguamente recib´ıa el nombre SMB, pero fue renombrado recientemente a CIFS. Gracias a esta implementaci´ on es posible que ordenadores con Linux, MacOS o cualquier Unix en general sean capaces de servir o ser clientes de ficheros en redes Windows. Samba tambi´en permite validar usuarios haciendo las labores de Controlador Principal de Dominio (PDC), como miembro de dominio o incluso como un dominio de Directorio Activo (Active Directory) para redes basadas en Windows, aparte de ser capaz de servir colas de impresi´on, directorios compartidos y autenticar con su propio archivo de usuarios. 19

http://tools.ietf.org/html/rfc3530 es la RFC del protocolo NFS en su u ´ltima versi´ on.

Proyecto Fin de Carrera

18

Universidad Rey Juan Carlos

´ CAP´ITULO 1. INTRODUCCION Entre los sistemas tipo Unix en los que se puede ejecutar Samba, est´an las distribuciones GNU/Linux, Solaris y las diferentes variantes BSD entre las que podemos encontrar el Mac OS X Server de Apple. Dado que en nuestra red no se van a alojar hosts con sistemas operativos Windows, descartamos esta opci´ on, aunque es interesante analizarla por si en un futuro no muy lejano es necesario instalar Windows para la docencia de alguna asignatura del Departamento.

1.3.5.

Servidores de correo electr´ onico

Dotar al entorno de un sistema de gesti´ on del correo electr´ onico nos brinda una cantidad enorme de nuevas funcionalidades. Sin entrar a´ un en cuales pueden ser estas nuevas funcionalidades, es necesario indicar que bajo el punto de vista de organizaci´on independiente dentro de la Universidad, no se disponen a priori datos de los alumnos, entre ellos, los datos necesarios para poder contactar con ellos en caso de que sea necesario. A menos que usemos el correo electr´ onico que se usa por defecto sobre cualquier m´ aquina Unix. Es por esta raz´on que debemos instaurar un mecanismo que nos permita entrar en contacto con los alumnos, para poder indicarles en un momento determinado cualquier incidencia con su cuenta de usuario. Adem´ as, este mecanismo tambi´en puede ser usado para otros menesteres, entre ellos, enviar al alumno las notas de sus ex´ amenes parciales, noticias acerca del funcionamiento interno del Laboratorio, etc´etera. Para ello, se decide la implantaci´ on de un sistema de transporte de correo (MTA) que asuma las funciones de recogida de correo electr´onico bajo los dominios de cada uno de los campus en los que disponemos de un Laboratorio de Linux (M´ ostoles y Fuenlabrada) y que facilite de un buz´ on de correo electr´ onico a los usuarios. Adem´ as, como posteriormente veremos en el cap´ıtulo de Implantaci´ on, instalaremos un servidor de recogida de correo (para que los usuarios sean capaces de recoger su correo electr´ onico usando un gestor como Outlook, Evolution, Eudora, etc´etera) y un webmail, que facilitar´ a que todos aquellos usuarios que no quieran o no puedan recoger su correo electr´ onico usando un gestor, lo puedan consultar en el web. En el cap´ıtulo Implantaci´ on se detallar´a m´ as ampliamente este mecanismo. A continuaci´ on vamos a enumerar las alternativas m´ as frecuentes y m´ as conocidas en lo que a servidores o agentes de correo se refiere. Por un lado, es necesaria la instalaci´ on de un agente de correo o Mail Transport Agente, que se encargue de la recogida de todo el correo que llega a cada uno de los servidores: de este lado, analizaremos los servidores m´ as com´ unmente usados en este sentido: Postfix y Sendmail. Una vez completada esta tarea, ser´a necesaria la instalaci´ on del citado servidor de recogida de correo. Estos servidores, suelen operar bajo los protocolos POP y/o IMAP (siempre bajo conexiones seguras, usando SSL o TLS). En este sentido, hemos citado dos de los servidores m´ as conocidos y usados en la actualidad: Courier y Dovecot (aunque por supuesto, existen muchos m´ as). Cabe rese˜ nar que las pretensiones de estos servidores no van m´ as all´ a que la simple entrega y recogida de correo, sin necesidad de alcanzar unas cotas de rendimiento m´ınimas o condiciones especiales. Es por ello que a la hora de decantarnos por una opci´ on u otra, nos centraremos b´asicamente en la facilidad de instalaci´ on de cada herramienta. Sendmail Sendmail a d´ıa de hoy es uno de los proyectos m´ as conocidos dentro del Software Libre. Sendmail es un Agente de Transporte de correo, o MTA (Mail Transport Agent). Esta aplicaci´ on se encarga de encaminar los mensajes de correo electr´onico en Internet para que lleguen a su destino. Se afirma que Sendmail es uno de los principales encaminadores de todo el tr´afico de correo electr´ onico en la Internet mundial, de ah´ı la importancia de este agente de correo electr´onico. Comenzaba su andadura cuando la Internet moderna comenzaba sus pasos, de ah´ı que una de las principales dolencias de Sendmail sea uno de los aspectos que en principio no era un A. Guti´errez Mayoral

19

ETSI Inform´atica

1.3. ESTADO DEL ARTE problema cuando Internet comenzaba sus pasos: la seguridad. Seg´ un los principales detractores de esta herramienta adolece de numerosas fallas de seguridad (muchas descubiertas y documentadas, y quien sabe las que tiene por descubrir), aunque normalmente est´an son arregladas a las pocas horas de ser notificadas. Otro de los principales problemas de los que adolece Sendmail es de su configuraci´ on. Mientras la mayor´ıa de los servidores de recogida de correo tienen ficheros de configuraci´ on legibles por humanos (human-readables) los propios desarrolladores de Sendmail afirman que los ficheros de configuraci´ on de la herramienta no cumplen esta condici´ on, y recomiendan al administrador de sistemas encargado de configurar esta tediosa herramienta el aprender un lenguaje basado en macros para la configuraci´ on de la misma (M420 ). Adem´ as de soportar evidentemente el protocolo SMTP de correo electr´onico, Sendmail da soporte a una gran variedad de protocolos de correo electr´onico, como ESMTP, DECnet’s mail11, HylaFax, QuickPage o UUCP. Como vemos, Sendmail es una aplicaci´on con una funcionalidad bastante extensa para nuestros prop´ ositos, que dificulta su configuraci´ on enormemente, por lo que en un principio ser´a descartada en favor de una aplicaci´on que aunque con menor funcionalidad, sea m´ as sencilla y r´ apida de configurar. Postfix Al igual que Sendmail, Postfix21 es un agente de transporte de correo (MTA) que encamina los mensajes de correo electr´ onico desde el origen hasta el destinatario. Actualmente, Postfix se encuentra en su versi´ on estable 2.5, liberada aproximadamente en Enero de 2008. Postfix surgi´o como principal alternativa a Sendmail: se buscaba un gestor de correo electr´onico seguro, f´ acil de administrar y cuya instalaci´ on no supusiera un quebradero de cabeza para muchos administradores de sistemas a lo largo de toda Internet. Con este objetivo, Thomas J. Watson desarroll´ o las primeras versiones de Postfix, antiguamente conocido como VMailer y IBM Secure Mailer. Postfix es el sistema gestor de correo predefinido en muchas distribuciones de Linux (por ejemplo Ubuntu), y en las u ´ltimas versiones del sistema operativo de Apple (Mac OS Tiger y Leopard). Respecto a los detalles t´ecnicos, el c´odigo fuente de Postfix suele ser citado como ejemplo de buena pr´ actica de programaci´ on. Aparte de este detalle, Postfix posee muchas funcionalidades que hoy en d´ıa son casi primordiales a la hora de configurar cualquier servidor de correo: soporte para comunicaciones seguras (usando la capa de seguridad TLS), capacidad de filtrar el correo mediante listas grises, uso de diferentes bases de datos para obtener fuentes de usuarios, dominios etc´etera (entre ellas, MySQL, PostgreSQL, LDAP, bases de datos Berkeley, etc´etera), soporte de formato mbox y Maildir para almacenar los mensajes de correo, etc´etera. Como se puede observar, la funcionalidad de este gestor de correo es bastante extensa, lo que puede incitar a pensar que su configuraci´ on puede ser incluso m´ as complicada que la de su principal rival, Sendmail. Nada m´ as lejos de la realidad. La instalaci´ on y configuraci´ on de Postfix se realiza en apenas tres pasos, sin m´ as que indicar si se desea instalar un gestor de correo que reciba correo de Internet, el dominio para el que se desea recoger correo y poco m´ as. Por supuesto, si la configuraci´ on es m´ as extensa, se deber´an personalizar los ficheros de configuraci´ on al gusto, para conseguir la configuraci´ on deseada seg´ un las necesidades de cada administrador. No obstante, los ficheros de configuraci´ on de Postfix son bastante sencillos de asimilar (principalmente la configuraci´ on se realiza editando un u ´nico fichero, el fichero /etc/postfix/main.cf ) y la configuraci´ on avanzada no resulta muy complicada, existiendo gran documentaci´ on en Internet y configuraciones est´andar ya escritas para la mayor´ıa de los supuestos casos que nos podemos encontrar. 20 21

M4 es un procesador de macros de prop´ osito general, desarrollado por Brian Kernighan y Dennis Ritchie. http://www.postfix.org/

Proyecto Fin de Carrera

20

Universidad Rey Juan Carlos

´ CAP´ITULO 1. INTRODUCCION Debido a la rapidez de la instalaci´ on de esta herramienta y su posterior configuraci´ on (para nuestros requerimientos, la configuraci´ on est´andar es m´ as que necesaria) ser´a el gestor de correo que elijamos como agente de transporte de correo para el Laboratorio, frente a su principal competidor (Sendmail). En el cap´ıtulo Implantaci´ on estudiaremos m´ as en detalle la configuraci´ on que se lleva a cabo para que el gestor funcione correctamente. Courier Una vez elegido un agente de transporte de correo (MTA) debemos pensar en que los usuarios deben poder leer su correo de una forma eficiente. En este sentido, ser´a necesario instalar y configurar un servicio de recogida de correo. Estos servicios facilitan a los usuarios la descarga del correo electr´ onico usando un gestor de correo electr´onico para el escritorio, como por ejemplo Outlook (para Windows), Eudora, Mozilla Thunderbird, Evolution, etc´etera. A trav´es de estos gestores los usuarios podr´an descargar el correo del Laboratorio sin necesidad de tener que conectarse al servidor para leerlo en el terminal, algo engorroso en algunos casos. Para ello, nos planteamos la instalaci´ on de alguna herramienta que facilite este servicio. Hoy en d´ıa, los m´ as usados en la distribuciones Linux que vamos a usar como principales (Debian y Ubuntu) son Courier y Dovecot, que repasaremos a continuaci´ on. Courier Mail Server, o com´ unmente llamado Courier, tambi´en es un agente de transporte de correo MTA que facilita la operaci´on de los protocolos POP e IMAP para la recogida de correo. Estos protocolos son los que facilitan que los gestores de correo e informaci´ on personales puedan conectarse al servidor y descargar el correo electr´onico a cada uno de los ordenadores de los usuarios. Adem´ as, Courier puede funcionar como gestor de correo electr´onico (como Postfix y Sendmail) aunque en nuestro caso, solamente plantearemos su uso como servicio POP e IMAP. La herramienta Courier se encuentra presente en Debian como paquete (en concreto, es necesario instalar los paquetes courier-pop-ssl, courier-imap-ssl para a˜ nadir soporte POP e IMAP usando una conexi´ on segura). La instalaci´ on de Courier se divide en aquellos elementos que se desea instalar, seg´ un el protocolo ofrecido al usuario (POP, IMAP, POP bajo SSL, etc´etera) existiendo un paquete para cada funcionalidad. La configuraci´ on de Courier es algo compleja para nuestras necesidades, por lo que en principio, nos decantaremos por una opci´ on m´ as sencilla de instalar y configurar, como es Dovecot, un servidor POP e IMAP muy sencillo de configurar. Dovecot La labor fundamental de Dovecot22 es la de facilitar el acceso a los buzones de correo mediante los protocolos POP3 e IMAP (pudiendo usar tambi´en una conexi´ on segura, es decir, POP3s e IMAPs). Esta aplicaci´on ha sido escrita principalmente por Timo Sirainen y fue liberada por primera vez en 2002, por lo que despu´es de seis a˜ nos podemos afirmar que la herramienta se encuentra lo suficientemente madura como para ser usada en producci´ on (la u ´ltima versi´ on es la 1.1.2 que fue liberada en Julio de 2008). La instalaci´ on y posterior configuraci´ on de Postfix es extremadamente sencilla, bas´ andose u ´nicamente en un fichero de configuraci´ on (el fichero /etc/dovecot/dovecot.conf ). En este fichero se indica los protocolos que se desea ofrecer (pop3, pop3, imap o imaps) y algunas otras indicaciones relativas a los certificados (en caso de que ofrezcamos conexiones seguras), los directorios de ejecuci´ on, el formato de los mensajes de correo almacenados, etc´etera. En realidad es muy probable que con tan solo indicar los protocolos ofrecidos la herramienta funcione a la primera, de ah´ı la sencillez de su configuraci´ on. Para nuestro caso es m´ as que suficiente (en un momento somos capaces de ofrecer un servicio POP/IMAP bajo conexiones seguras a los usuarios 22

http://www.dovecot.org/

A. Guti´errez Mayoral

21

ETSI Inform´atica

1.3. ESTADO DEL ARTE para que descarguen sus correos) por lo que nos decantamos por esta herramienta en favor de cualquier otra.

1.3.6.

Sistemas de monitorizaci´ on

Los sistemas de monitorizaci´ on nos permiten conocer en todo momento el estado de la red, formado por un conjunto de m´ aquinas que ofrecen una serie de servicios a disposici´on de los usuarios. En este sentido, las herramientas de monitorizaci´ on realizan un sondeo continuo de todas las m´ aquinas que conforman una red, comprobando que todos los servicios que dispone esa m´ aquina est´an funcionando adecuadamente. En caso de que alguno de ellos no est´e funcionando como debiera, el sistema enviar´ a una alerta, normalmente en forma de correo electr´onico al administrador de la aplicaci´on. Este correo electr´onico pondr´ a en aviso al responsable de la m´ aquina o m´ aquinas en cuesti´ on afectadas por el problema, que tomar´a las medidas oportunas. En nuestro caso, estas herramientas nos van a permitir conocer en todo momento el estado de las estaciones del Laboratorio y de los servidores, mostrando en todo momento aquellas m´ aquinas que se encuentren en problemas. Normalmente, la mayor´ıa de los sistemas de monitorizaci´on ofrecen un interfaz web amigable para el usuario donde se muestran los resultados de la monitorizaci´ on de la red. Es el caso de las tres herramientas estudiadas en esta secci´ on: Zabbix, Munin y Nagios. Zabbix Zabbix23 es una soluci´on de monitorizaci´ on de c´odigo abierto de las m´ as avanzadas hoy en d´ıa. Permite la monitorizaci´ on y registro del estado de varios servicios de red, servidores, estaciones, etc´etera. Almacena los datos que registra en un sistema gestor de base de datos del tipo MySQL, PostgreSQL, SQLite o Oracle. Adem´ as dispone de un frontend o interfaz u ´nico escrito en PHP, donde se muestran todos los datos recopilados por cada una de las herramientas que sondea el estado de la red. Aparte de monitorizar el estado de m´ aquinas y servicios (por ejemplo, una pasarela SMTP o un servidor HTTP) Zabbix permite la monitorizaci´ on avanzada de una m´ aquina instalando un componente llamado agente zabbix (Zabbix Agent) en el host en cuesti´ on. Este agente permite la obtenci´on de datos del host como por ejemplo el uso de memoria, procesos, espacio libre en disco, etc´etera. Los agentes env´ıan la informaci´ on al servidor para almacenar los datos y mostrarlos de una forma amigable para el usuario a trav´es de un interfaz web. En la imagen 1.1 podemos observar una de las capturas de pantalla del interfaz web de gesti´ on de Zabbix, en el que se muestra el estado particular de un host: uso de memoria, carga de procesador, espacio en disco, carga de red, etc´etera. Como se puede ver en la imagen, las estad´ısticas resultado de la monitorizaci´ on realizada por Zabbix resultan ser bastante detalladas, quiz´a m´ as de lo que en un principio necesitamos. Adem´ as, la instalaci´ on y posterior configuraci´ on de esta herramienta puede ser demasiado compleja, lo suficiente para que no compense realmente con respecto a nuestras necesidades. Digamos que los reportes ofrecidos resultan ser bastante m´ as detallados de lo que en un principio necesitamos: saber qu´e m´ aquinas est´an disponibles en cada momento y si se ha producido cualquier tipo de problema. Es por ello que en principio dejamos aparcada esta herramienta en busca de otra un poco m´ as simple para nuestros prop´ ositos. No obstante, vamos a destacar las principales ventajas y desventajas de esta herramienta de monitorizaci´ on. Como ventajas, podemos decir que los reportes obtenidos por esta herramienta son muy detallados, obteniendo gr´ aficas en diferentes formatos de toda la informaci´ on acerca del estado de la red y de los hosts que creamos oportuno. Esta informaci´ on nos puede ayudar 23

http://www.zabbix.com

Proyecto Fin de Carrera

22

Universidad Rey Juan Carlos

´ CAP´ITULO 1. INTRODUCCION

Figura 1.1: Interfaz web de Zabbix. Fuente: Wikipedia a construir informes de disponibilidad muy bien detallados y de una calidad m´ as que aceptable. Adem´ as de esto, Zabbix, soporta un gran n´ umero de plataformas (incluidos Solaris, Linux, Mac OS, FreeBSD, HP-UX, etc´etera). En la actualidad el n´ ucleo de Zabbix no soporta Windows, pero s´ı puede monitorizar plataformas Windows, algo muy interesante para todas aquellas personas que usen software de servidor basado en este sistema operativo. Como desventajas podemos decir que la curva de aprendizaje de esta herramienta es bastante elevada, y se ha de meditar si conviene usarla para lo que realmente se necesita. En nuestro caso, la respuesta era no, ya que es una herramienta bastante avanzada para nuestros objetivos. La configuraci´ on de la herramienta es bastante compleja y podemos afirmar que su manual de instrucciones tiene muchas p´ aginas, lo que puede echar para atr´ as a alguien que en principio quiera usar esta herramienta para monitorizar una red de no muy grandes dimensiones. Nagios Nagios24 es una aplicaci´on bastante parecida a Zabbix, en muchos sentidos: permite monitorizar el estado de un conjunto de m´ aquinas en una red, comprobando disponibilidad tanto de las m´ aquinas como de los servicios asociados a ella. Cuando se produce un problema, Nagios env´ıa una alerta a un contacto o grupo de contactos informando del problema producido y su nivel de peligro. La diferencia m´ as importante de Nagios respecto a Zabbix es que Nagios en principio no puede monitorizar el estado interno de una m´ aquina (carga de memoria, procesador, espacio en disco, etc´etera), aunque en principio estos datos no son de nuestro inter´es, ya que para 24

http://www.nagios.org

A. Guti´errez Mayoral

23

ETSI Inform´atica

1.3. ESTADO DEL ARTE nosotros es m´ as importante conocer el estado de la red en tanto a m´ aquinas y servicios. Adem´ as de la monitorizaci´ on constante que realiza Nagios, ´este ofrece un portal Web donde monitorizar todos los resultados. Si en un momento dado queremos ver de una pasada r´apida el estado de un host o de un grupo de hosts podemos realizarlo usando para ello su interfaz web. Respecto a la configuraci´ on de Nagios, podemos afirmar que no es demasiado complicada. Existen diversos ficheros de configuraci´ on donde se indican por un lado, las m´ aquinas de las que consta nuestra red, por otro lado y por otro los servicios que se desean comprobar sobre estas m´ aquinas. Digamos que la configuraci´ on es m´ as tediosa que complicada, debido a la verbosidad de los ficheros de configuraci´ on. A´ un as´ı, puede resolverse eficientemente si disponemos de un fichero de texto donde se indique la direcci´on IP de cada m´ aquina y su nombre correspondiente. Usando un script de shell muy sencillo podemos generar el fichero de configuraci´ on de nagios de forma trivial. Una vez que se han declarado todas las m´ aquinas en el fichero de configuraci´ on, se indican los servicios que se desean comprobar para cada m´ aquina. Como es muy frecuente agrupar las m´ aquinas en grupos (en nuestro caso, las agruparemos por laboratorios y por grupos de servidores) Nagios nos permite declarar grupos de hosts. De esta forma, ser´a m´ as sencillo indicar que se desea comprobar un cierto servicio sobre un determinado grupo de hosts. Una vez que se han declarado m´ aquinas, grupos de m´ aquinas y servicios, solamente deberemos indicarle a Nagios los contactos a los que se desea enviar informaci´ on en caso de problemas. De la misma forma que antes, Nagios permite declarar contactos y grupo de contactos. Es usual que los responsables de un conjunto de m´ aquinas sean m´ as de una persona, de ah´ı esta funcionalidad muy acertada en la herramienta. Una vez se han configurado estos par´ ametros, se lanza Nagios y se pueden consultar a trav´es de su p´agina web el estado de la red, y si se ha configurado para ello, nos llegar´a mediante correo electr´onico los avisos de las alertas correspondientes. Nagios est´a disponible como paquete Debian/Ubuntu en las versiones estables actuales de ambas distribuciones, por lo que su instalaci´ on es trivial. No obstante, tambi´en puede ser instalado mediante fuentes, si queremos tener disponible la u ´ltima versi´ on estable de la herramienta. Debido a la sencillez de la configuraci´ on (generada autom´aticamente con scripts) nos decantaremos por Nagios como herramienta de monitorizaci´ on de nuestro entorno. Finalmente y para recapitular, podemos decir que, Nagios presenta las siguientes ventajas y desventajas:

Como ventajas, su configuraci´ on es muy simple y se puede realizar en apenas minutos, partiendo de un fichero con las IPs de todos los equipos de la red y su nombre de host, lo cual siempre se suele tener a mano. Una vez realizada esta configuraci´ on, la herramienta empieza a obtener todos los reportes sin m´ as. Como desventajas, podemos decir que los reportes por Nagios son demasiado simples. Dependiendo del nivel de reporte que queramos obtener, esto puede ser una desventaja, pero tambi´en puede convertirse en una ventaja. En el entorno en el que nos encontramos, estos reportes son m´ as que suficientes. Otra de sus desventajas es que solamente existe una versi´ on para sistemas operativos de la familia Unix (y por tanto, Linux). No existe actualmente una versi´ on para Windows, aunque en principio esto no nos afecta ya que en nuestro entorno no disponemos hasta la fecha de estaciones Windows. Esto ocurr´ıa tambi´en con su principal competidor, Zabbix, con la diferencia de que Zabbix puede obtener las estad´ısticas completas de monitorizaci´ on de una m´ aquina Windows, debido a que dispone de una versi´ on de su agente para este sistema operativo. Proyecto Fin de Carrera

24

Universidad Rey Juan Carlos

´ CAP´ITULO 1. INTRODUCCION Munin Por u ´ltimo, analizamos la herramienta Munin25 . La aplicaci´on Munin es una herramienta de monitorizaci´ on de red y del sistema en general (m´ as bien, del sistema). La aplicaci´on se distribuye en dos componentes: El servidor Munin, que recoge y procesa los datos que son enviados por los clientes, los nodos de Munin. Estos nodos se encuentran instalados en todas aquellas m´ aquinas que se desea monitorizar o de las que se desea obtener estad´ısticas. Adem´ as, dispone de un gran n´ umero de plugins o a˜ nadidos para recoger y procesar todo tipo de datos interesantes para el administrador: carga de procesador (procesos), carga de memoria, espacio en disco, carga de la red, n´ umero de operaciones de entrada/salida, etc´etera. Adem´ as, dependiendo de si el servidor dispone de una serie de servicios o no, Munin ser´a capaz de obtener datos de estos servicios. Por ejemplo, para un servidor MySQL, Munin es capaz de obtener el n´ umero de consultas por unidad de tiempo realizadas, e incluso, discriminar por tipo de consulta realizada en la base de datos. Sin embargo si nuestro servidor tiene capacidades de servidor web, Munin es capaz de representar el n´ umero de p´aginas servidas por unidad de tiempo. En general, Munin dispone de un amplio abanico de plugins que hace que sea capaz de representar casi todas las estad´ısticas que puede haber en un servidor hoy en d´ıa.

Figura 1.2: Representaci´ on del uso de memoria en una m´ aquina a trav´es de Munin. Fuente: Wikipedia La aplicaci´on est´a pensada para visualizar u ´nicamente los datos que son recogidos a trav´es de los diferentes nodos. Una vez que estos datos son recogidos, se muestran a trav´es de un interfaz 25

http://munin.projects.linpro.no/

A. Guti´errez Mayoral

25

ETSI Inform´atica

1.3. ESTADO DEL ARTE web las diferentes gr´ aficas que se corresponden con cada uno de los servicios. En la imagen 1.2 podemos ver c´omo se representa el uso de memoria en una m´ aquina a trav´es de Munin. Munin utiliza la herramienta RRDTool26 para la representaci´ on de sus p´aginas. La configuraci´ on de Munin es extremadamente simple, ya que u ´nicamente hay que instalar la aplicaci´on cliente en cada uno de los nodos que se desea monitorizar y el servidor en aquella m´ aquina que se desea usar para representar la informaci´ on. En los clientes, se especifica en un fichero de configuraci´ on qu´e m´ aquina es el servidor (para permitirle recoger los datos que el cliente recopila) especificando la direcci´on IP del mismo. En el servidor, se indica a qu´e clientes se debe acudir para recopilar toda la informaci´ on que se desea monitorizar. Y nada m´ as. Una vez hecho esto, el servidor Munin se conectar´a a los clientes peri´ odicamente para representar la informaci´ on que le facilitan los clientes. Como el uso de esta aplicaci´on no implica no usar el resto, hemos decidido instalarla en una m´ aquina para obtener gr´ aficas relativas al uso de los diferentes servicios en cada uno de los servidores. Ya que la configuraci´ on es extremadamente simple, no nos llevar´ a mucho tiempo debido a que el n´ umero de servidores en nuestra red no es muy elevado. Finalmente, indicamos las ventajas y desventajas de esta herramienta: Como ventaja, podemos afirmar que la configuraci´ on de Munin es extremadamente sencilla, realiz´ andose en apenas minutos para el entorno en el que nos encontramos. Adem´ as, las estad´ısticas obtenidas por Munin son muy detalladas y nos brindan una informaci´ on muy concisa. Como desventaja, podemos decir que el sistema de notificaci´ on es algo pobre y algo extra˜ no de configurar. Aunque, como Munin en s´ı mismo no est´a pensado como sistema de notificaci´ on, simplemente podemos usarlo para visualizar las gr´ aficas de los diferentes servidores y estaciones y usar Nagios como sistema de notificaci´ on.

26

http://oss.oetiker.ch/rrdtool/

Proyecto Fin de Carrera

26

Universidad Rey Juan Carlos

Cap´ıtulo

2

Objetivos Una vez realizada una introducci´ on tanto a la motivaci´ on del proyecto como a los objetivos principales, vamos a detallar de forma concisa en qu´e consistir´a cada uno de ellos. Para ello, detallaremos cada uno de los objetivos y como lo afrontaremos. Nos proponemos dos objetivos principales, basados en el desarrollo de un sistema de instalaci´ on autom´atico y desatendido y la implantaci´ on de un sistema de cuentas de usuario en red. Una vez que ambos objetivos han sido llevados a cabo, se ampliar´a la funcionalidad del entorno dot´andolo de servicios de valor a˜ nadido y ampliando la seguridad del mismo todo lo que podamos. Con esto conseguiremos un entorno bastante fiable y reduciremos la probabilidad de que alguien pueda entrar en el sistema con una cuenta de usuario que no le pertenece, con todo lo que ello conlleva.

27

2.1. SISTEMA DE INSTALACIONES MASIVAS Y DESATENTIDAS Una vez presentado el marco general de desarrollo de este proyecto y las tecnolog´ıas utilizadas, en este cap´ıtulo abordaremos los objetivos que se han perseguido durante la elaboraci´on del proyecto. Los principales objetivos del proyecto son: Desarrollar un sistema de instalaciones masivas y completamente desatendidas Implantar un sistema de cuentas de usuario y disco en red Dotar al entorno de una serie de servicios de valor a˜ nadido (p´agina web, correo electr´onico, etc´etera) Instaurar un servicio de monitorizaci´ on de la red y de los servicios Aumentar al m´ aximo la seguridad del entorno.

2.1.

Sistema de instalaciones masivas y desatentidas

El primer objetivo que abordamos es la implementaci´ on de un mecanismo que permita automatizar la instalaci´ on de estaciones de usuario basadas en Ubuntu Linux, de una forma lo m´ as autom´atica y desatendida posible. Este mecanismo permitir´a la instalaci´ on masiva de laboratorios de una forma c´omoda para el administrador de las mismas, y en un corto espacio de tiempo. Hay que tener en cuenta que cada Laboratorio se compone de al menos cuarenta equipos, por lo que el que exista un m´etodo de instalaci´ on que no sea el tradicional (basado en un medio extra´ıble que se instala en un equipo, siguiendo una serie de pasos) resulta pr´acticamente indispensable. El mecanismo de instalaci´ on que perseguimos construir debe instalar todo el sistema, con todos los requisitos necesarios, sin que sea necesaria la intervenci´on del usuario administrador que lo realiza (´ unicamente, la iniciaci´ on del proceso). Nuestro objetivo ser´a siempre que la interacci´ on entre el administrador y el proceso de instalaci´ on sea m´ınimo, como veremos posteriormente. A veces, esto no ser´a posible, como veremos en el cap´ıtulo Implantaci´ on, donde se estudiar´ a detenidamente la construcci´ on de esta herramienta. Sin embargo, y en comparaci´on con los m´etodos estudiados y descartados, la interacci´ on del administrador con el proceso de instalaci´ on casi siempre ser´a m´ınima. En el m´etodo estudiado e implementado se ha dotado al sistema de un sistema de instalaci´ on desatendido que solamente requiere que el administrador inicie el proceso. El sistema se instalar´ a sin requerir ninguna acci´on por parte del usuario y cuando ´este haya sido completado, la estaci´on se reiniciar´a autom´aticamente, iniciando el nuevo sistema reci´en instalado. Para la construcci´ on de este sistema de instalaci´ on autom´atica nos basaremos en diversas tecnolog´ıas, siendo la primordial los ficheros de preconfiguraci´on de Debian GNU/Linux. Este mecanismo ser´a estudiado con detalle en el cap´ıtulo de Implantaci´ on del presente documento.

2.2.

Sistema de cuentas de usuario y disco en red

Debido a la naturaleza del sistema, es necesario proveer al mismo de un sistema de cuentas de usuario en red, que facilite que los usuarios puedan iniciar una sesi´ on en el sistema usando para ello una credencial basada en nombre de usuario y una palabra de paso o contrase˜ na. El sistema debe facilitar que un usuario pueda iniciar siempre una sesi´ on en cualquier estaci´on del Laboratorio, independientemente de cual sea ´esta. De la misma forma, debe facilitar la creaci´ on de nuevos usuarios, o el cambio de la palabra de paso de un usuario en concreto. Ser´ıa razonable el marcar como objetivo que un cambio de una contrase˜ na de un usuario, permita que el usuario Proyecto Fin de Carrera

28

Universidad Rey Juan Carlos

CAP´ITULO 2. OBJETIVOS inmediatamente vea reflejado que el cambio afecta a todas las estaciones del Laboratorio: no ser´ıa razonable que si el usuario ha efectuado un cambio en su contrase˜ na, la nueva palabra de paso no se viera reflejada inmediatamente al iniciar una sesi´ on en cualquier otra estaci´on del Laboratorio. Como objetivo primordial para esta fase tambi´en nos marcaremos el a˜ nadir privacidad a los datos que viajan por la red relativos a las credenciales del usuario que intenta iniciar una sesi´ on en una estaci´on del Laboratorio, o que efect´ ua un cambio en la palabra de paso o contrase˜ na de su cuenta. Esto es muy importante ya que al encontrarnos en un entorno basado en red de medio compartido, nos podr´ıamos encontrar con usuarios maliciosos que pueden monitorizar los datos que viajan por la red en un momento dado, capturando nombres de usuario y contrase˜ nas pertenecientes a un usuario en concreto. Si no a˜ nadimos un mecanismo que permita ocultar estos datos de forma conveniente, nos podemos encontrar con alguna que otra sorpresa desagradable. Veremos posteriormente en el cap´ıtulo Implantaci´ on como este aspecto se soluciona convenientemente aportando una soluci´on basada en bibliotecas de cifrado sobre el protocolo que se ocupa de las cuentas de usuario. En principio no aportamos m´ as detalles t´ecnicos sobre este objetivo, ya que se estudiar´ an en detalle en el cap´ıtulo oportuno. Adem´ as, junto con el sistema de cuentas de usuario en red, ser´ıa conveniente proporcionar un servicio de disco en red. No ser´ıa l´ ogico que cada vez que un usuario iniciara una sesi´ on en un equipo, tuviera unos ficheros diferentes a una sesi´ on iniciada previamente en otro equipo (es decir, cada m´ aquina con sus ficheros independientes). Como es l´ ogico, el inicio de una sesi´ on en una estaci´on debe llevar asociado un espacio en disco personal, independiente de la estaci´on en la que se inicia la sesi´ on y que est´e siempre disponible. Estudiaremos posteriormente como implementar este servicio.

2.3.

Servicios adicionales

Construir un sistema de instalaci´ on completamente autom´ atico y desatendido y dotar al entorno con un sistema de cuentas de usuario en red y lo suficientemente seguro y confiable ser´an nuestros objetivos principales. Una vez completados estos hitos, nos marcamos ampliar la funcionalidad del entorno con otros aspectos secundarios. En general, estos objetivos ser´an en su mayor´ıa servicios de valor a˜ nadido, que har´ an del sistema un entorno m´ as funcional y m´ as agradable de cara al usuario final: los alumnos. En esta secci´ on, nos planteamos la persecuci´on de los siguientes hitos: Dotar al entorno de una p´ agina web: dotar a los Laboratorios de un sitio web facilita el aprendizaje por parte de los usuarios al funcionamiento del mismo, as´ı como facilita una plataforma para la documentaci´ on de preguntas frecuentes de usuarios, anunciar noticias relacionadas con el Laboratorio y colgar los horarios de las salas para referencia de profesores y alumnos. Sistema de correo de entrada y recogida: dado que el sistema de cuentas de usuario no est´a relacionado con las cuentas de dominio u ´nico que se facilitan a los usuarios y profesores de la Universidad por ser miembros de ella, implementaremos un sistema de correo unido a las cuentas que entregar´an correo en la direcci´on compuesta por el nombre de usuario propietario de la cuenta seguido del dominio del servidor que recoja el correo en ese momento. Una vez que los usuarios disponen de esta cuenta de correo, podr´an leer los mensajes que en ella se almacenen o bien redirigirlos a una cuenta de correo que lean asiduamente. Esta caracter´ıstica es fundamental, puesto que no disponemos de otro mecanismo de comunicaci´ on con los usuarios del sistema que no sea el correo electr´onico. Sistema de resoluci´ on de nombres local: de cara a a˜ nadir funcionalidad y tolerancia de fallos, es interesante el a˜ nadir un sistema de resoluci´ on de nombres local interno a los A. Guti´errez Mayoral

29

ETSI Inform´atica

´ DEL SISTEMA 2.4. MONITORIZACION Laboratorios. Esto permitir´a la resoluci´ on de nombres de dominio m´ as r´apidamente que si se usara un servidor de resoluci´ on de nombres ajeno al mismo, adem´ as de aumentar la tolerancia a fallos de cara a ca´ıdas de red. En cualquier caso, siempre podr´ıamos usar los servidores DNS que facilita la Universidad de cara a los usuarios de la red de la Organizaci´ on. Listas de correo: la utilizaci´ on de listas de correo tiene dos objetivos principales. Por un lado, la comunicaci´ on entre los administradores del Laboratorio y los usuarios, por medio de una u ´nica lista de correo. A trav´es de esta lista de correo se mandan avisos, noticias, recomendaciones de uso sobre el Laboratorio y en general cualquier nota que sea de inter´es para los usuarios del sistema. Los avisos que se mandan a esta lista son recibidos autom´aticamente por los usuarios del mismo solamente por el mero hecho de disponer de una cuenta en los Laboratorios. Por otro lado, la creaci´ on de un sistema de listas de correo nos va a permitir el gestionar determinados avisos y alertas que lleguen a determinados grupos de personas encargadas de la gesti´ on de los Laboratorios (profesores, administradores, etc´etera). Por ejemplo, alertas sobre ca´ıdas en los servicios (fallos el´ectricos, de red, etc´etera) o incidencias que se producen en el entorno (enviadas por los propios usuarios). La creaci´ on de listas permite que los mensajes sean enviados a varias personas con facilidad adem´ as de ser almacenados para su posterior consulta. R´ eplicas locales de Debian y Ubuntu: Dado que la instalaci´ on de software (paquetes, como se denomina usualmente en las distribuciones Debian GNU/Linux y Ubuntu) es muy frecuente, y normalmente se repite en tantas estaciones haya en el Laboratorio, el disponer de una r´eplica local o espejo de un servidor de software de Debian GNU/Linux o de Ubuntu resulta realmente interesante. Si esto no fuera as´ı, cada paquete de software que se deseara instalar en una estaci´on o servidor deber´ıa ser descargado desde la r´eplica correspondiente. Esta r´eplica, a´ un no estando muy lejos (podemos disponer de una r´eplica de Debian GNU/Linux o de Ubuntu en los servidores de RedIris) ya supone el dar un salto fuera de la red institucional de la propia Universidad, con todo lo que ello conlleva. Por esta raz´on, la instalaci´ on de una r´eplica local siempre ser´a un punto muy a favor para disminuir el tr´afico externo y aumentar la velocidad a la hora de instalar software en los Laboratorios. Copias de seguridad de directorios de usuario: con el fin de que un problema de hardware no afecte a los datos personales de los usuarios del sistema, llevaremos a cabo un plan de copias de seguridad que garantice que al menos si se produce un fallo de hardware en alguno de los discos del sistema tengamos una copia de respaldo de la que disponer para restaurar los ficheros personales de los usuarios. Posteriormente en el cap´ıtulo Implantaci´ on estudiaremos como se han llevado a cabo cada uno de estos requisitos que acabamos de definir.

2.4.

Monitorizaci´ on del sistema

En este tipo de entornos, parece que el trabajo queda finalizado cuando todos los hitos que nos plante´ abamos se han completado y todos los sistemas se encuentran funcionando en fase de producci´ on. Nada m´ as lejos: una vez que el sistema est´a en marcha, la monitorizaci´ on del sistema se convierte en el aspecto fundamental para el correcto funcionamiento del mismo. En nuestro caso, y dado el elevado n´ umero de estaciones existentes y servidores que hacen que el entorno funcione correctamente, la evaluaci´on de un sistema de monitorizaci´ on de servicios ser´a algo fundamental y completamente necesario si no queremos encontrarnos una ma˜ nana con que un servicio ha dejado de funcionar y no nos hayamos enterado hasta pasadas unas horas. Proyecto Fin de Carrera

30

Universidad Rey Juan Carlos

CAP´ITULO 2. OBJETIVOS Para solucionar este aspecto, se pondr´ a en marcha un sistema de monitorizaci´ on de todos los servicios existentes en el Laboratorio: por un lado, se vigilar´ a que no haya ca´ıda masiva de estaciones (las cuales son producidas normalmente por interrupciones del fluido el´ectrico). En este sentido, es importante saber en todo momento cuando se ha producido una ca´ıda masiva de estaciones: es significado de que algo no va bien. Sin embargo, no ser´a necesario conocer cuando un ordenador ha dejado de estar disponible (se encuentra apagado), ya que puede ser por muy diversos motivos y en principio, que una estaci´on deje de funcionar (una o un n´ umero muy peque˜ no) no debe ser motivo de distracci´ on. Por otro lado, ser´a muy importante vigilar que todas aquellas m´ aquinas que proporcionen servicios b´asicos para el funcionamiento del Laboratorio (esto es, servidores) se encuentren disponibles siempre, en todo momento. Al contrario que en las estaciones, la ca´ıda de una sola de estas m´ aquinas debe requerir nuestra atenci´on inmediatamente y debe ser resuelta lo m´ as r´ apido posible. Normalmente, estos avisos son enviados por correo electr´onico, o son notificados mediante avisos sonoros. En cualquier caso, la notificaci´ on inmediata de problemas en el entorno debe ser fundamental. Estos mensajes son interesantes para los administradores del Laboratorio, si bien para los alumnos siempre resulta u ´til conocer cuantas estaciones est´an disponibles en un momento dado, para poder iniciar una sesi´ on en una de ellas. Si bien esta informaci´ on no es fundamental, es bastante interesante de cara a encontrar una estaci´on disponible en un momento dado para poder iniciar una sesi´ on remota. En este sentido, llamaremos partes de guerra a los informes de estaciones disponibles existentes en el Laboratorio, y podr´an ser consultados desde la p´agina web del Laboratorio. En resumen, ser´a condici´ on indispensable para este proyecto la implantaci´ on de un sistema que permita monitorizar en todo momento el estado de todos los servicios del Laboratorio: estaciones (si est´an funcionando, cuantas en cada momento, etc´etera) y servidores (que est´en todos levantados y que sus correspondientes servicios se encuentren funcionando correctamente).

2.5.

Pol´ıticas de seguridad

Una vez puesto en marcha todos los servicios anteriores, se marca como hito mantener siempre un entorno lo m´ as seguro posible. Cabe destacar que nos encontramos en un entorno con las siguientes caracter´ısticas: Aproximadamente 3000 cuentas de usuario 160 estaciones de trabajo en el Campus de M´ ostoles y 100 en el Campus de Fuenlabrada Todas las estaciones de trabajo y servidores disponen de IPs p´ ublicas. Un entorno de estas caracter´ısticas, en el que todas las estaciones disponen de un servicio SSH en el que realizar peticiones, y con tantas cuentas de usuario y adem´ as con IPs p´ ublicas (accesibles desde cualquier punto de Internet) puede ocasionarnos verdaderos quebraderos de cabeza si no tomamos una serie de medidas que garanticen que si alguien accede al sistema de forma fraudulenta (normalmente, usando una cuenta de usuario que no le pertenece), ´este sea interceptado inmediatamente. Es com´ unmente sabido que no hay mayor defensa que un buen ataque. Pues bien, en este sentido, para minimizar la posibilidad que alguien pueda entrar en el sistema de forma fraudulenta, plantearemos un ataque en los siguientes aspectos: Limitar el acceso a los servidores a redes internas de la Universidad. A. Guti´errez Mayoral

31

ETSI Inform´atica

´ 2.6. DOCUMENTACION Monitorizar y denegar conexiones a aquellas IPs que son detectadas como posibles or´ıgenes o causantes de intentos de fuerza bruta a trav´es de SSH. Desarrollar un sistema de auditor´ıa que nos permita almacenar un hist´ orico de aquellos usuarios que han iniciado una sesi´ on en alguna estaci´on del laboratorio. Utilizar herramientas que nos ayuden en la detecci´ on de intrusos (o desarrollarlas nosotros mismos). Vigilar constantemente la fortaleza de las contrase˜ nas de los usuarios del sistema. Siguiendo estrictamente y regularmente esta serie de medidas, seguramente no eliminemos la probabilidad de que alguien ajeno al sistema pueda penetrar en ´el utilizando o bien una cuenta de usuario o bien un agujero de seguridad en alguna aplicaci´ on; pero con toda seguridad, esta probabilidad ser´a bastante m´ as baja a no realizar estos chequeos.

2.6.

Documentaci´ on

Por u ´ltimo, un aspecto deseable de nuestro proyecto ser´ıa generar la m´ axima documentaci´ on posible de todos aquellos hitos realizados. Implementaciones, ficheros de configuraci´ on, decisiones tomadas, etc´etera. Todo aquello que podamos dejar por escrito siempre ser´a bienvenido para poder ser consultado en un futuro bien por nosotros mismos o por la persona que se tenga que encargar de la administraci´on de los Laboratorios en un momento dado. Dado que vamos a disponer de una p´agina web para los Laboratorios, no ser´a mala idea utilizar esa misma p´agina web para poder almacenar toda la documentaci´ on que se ha ido generando a medida que los hitos se han ido completando. Una buena idea para almacenar esta informaci´ on podr´ıa ser la utilizaci´ on de un sitio web tipo wiki 1 que se pudiera editar usando el propio navegador, incluso por otros usuarios. As´ı, diversos usuarios encargados de la gesti´ on del Laboratorio podr´ıan visualizar y editar los contenidos en caso que lo creyeran oportuno.

1 Un wiki, o una wiki, es un sitio web cuyas p´ aginas web pueden ser editadas por m´ ultiples voluntarios a trav´es del navegador web.

Proyecto Fin de Carrera

32

Universidad Rey Juan Carlos

Cap´ıtulo

3

Especificaci´on y Dise˜no Una vez puestas sobre la mesa todas las tecnolog´ıas, habiendo enumerado las posibles alternativas a cada una de ellas y establecido los objetivos que nos proponemos como base en el presente proyecto, en este cap´ıtulo vamos a enumerar todos los requisitos de una manera m´ as formal. Debido a que este proyecto no se centra en el desarrollo de ning´ un producto software en particular, no se seguir´ a ninguna metodolog´ıa de desarrollo en concreto, bas´ andonos u ´nicamente en la implementaci´ on y puesta en marcha de todos los servicios requeridos. En este cap´ıtulo enumeraremos los requisitos de cada una de las tres partes diferenciadas desarrolladas anteriormente.

33

3.1. METODOLOG´IA EMPLEADA

3.1.

Metodolog´ıa empleada

El desarrollo de cualquier producto software se realiza siguiendo una determinada metodolog´ıa o modelo de desarrollo, de manera que se realizan una serie de tareas entre la idea inicial y el resultado obtenido. El modelo de desarrollo escogido establece el orden en el que se han de afrontar las tareas en el desarrollo del proyecto, y nos provee de requisitos de entrada y salida para cada una de las actividades. Sin embargo, en este proyecto, al no desarrollarse ning´ un producto software en concreto (est´ a centrado b´asicamente en la administraci´on de sistemas) en este cap´ıtulo nos vamos a centrar en enumerar todos los requisitos funcionales y no funcionales de los que constaba nuestro desarrollo.

3.2.

An´ alisis de requisitos

El an´ alisis de los servicios necesarios que deben estar funcionando en cada uno de los servidores (necesarios para el correcto funcionamiento del Laboratorio) se llevar´ a a cabo mediante una lista de requisitos funcionales. Debido a que el proyecto se subdivide b´asicamente en tres partes claramente diferenciadas (construcci´ on del proceso de instalaci´ on desatendido, implementaci´ on de un sistema de cuentas de usuario en red y creaci´ on de servicios de valor a˜ nadido para los usuarios) vamos a ver la lista de requisitos funcionales para cada una de estas tres partes por separado. Los requisitos se obtienen normalmente de los casos de uso, que a su vez describen la interacci´ on del usuario y el sistema. En nuestro caso, vamos a establecer que el usuario es el usuario administrador (que puede considerarse como un nivel m´ as elevado de usuario) y que el sistema es en cada caso cada una de las partes que nos proponemos desarrollar. Debido a que la interacci´ on en cada caso es m´ınima, no vamos a describir los casos de uso (ni los diagramas ni la descripci´ on del flujo de eventos en cada caso) ci˜ n´endonos u ´nicamente a la captura de requisitos.

3.2.1.

Proceso de instalaci´ on desatendido

A continuaci´ on vamos a enumerar la lista de requisitos que debe cumplir el proceso de instalaci´ on desatendido. En cuanto a los requisitos funcionales, cabr´ıa destacar: 1. RF1: El proceso debe facilitar la instalaci´ on de un sistema completo Ubuntu Linux, preferiblemente, en la versi´ on Hardy (numerada como 8.04). 2. RF2: La interacci´ on con el usuario en este proceso debe ser nula. El proceso de instalaci´ on debe ser completamente desatendido. En cuanto a los requisitos no funcionales (basados principalmente en las propiedades del sistema) podemos observar las siguientes: 1. RNF1: El sistema de instalaci´ on autom´atica debe funcionar en plataformas Linux (tanto el sistema instalado, el cliente, como el sistema que provee la instalaci´ on, el servidor). 2. RNF2: Ser´ a necesario que el cliente posea la capacidad de realizar arranque por red en la placa base (com´ unmente llamado PXE). 3. RNF3: El sistema debe cumplir unas condiciones m´ınimas de velocidad. Dado que el n´ umero de estaciones a instalar ser´a elevado, es conveniente que se provea de alg´ un espejo local de instalaci´ on, para que las latencias sean lo m´ as peque˜ nas posibles y por tanto, el proceso de instalaci´ on no lleve mucho tiempo. Proyecto Fin de Carrera

34

Universidad Rey Juan Carlos

´ Y DISENO ˜ CAP´ITULO 3. ESPECIFICACION

3.2.2.

Cuentas de usuario en red y disco en red

Respecto al sistema de cuentas de usuario en red, podemos destacar los siguientes requisitos funcionales: 1. RF1: El sistema de cuentas de usuario en red debe facilitar la autenticaci´ on de usuarios del sistema, en todas aquellas m´ aquinas que conformen nuestro sistema, a trav´es de un nombre de usuario y una contrase˜ na, o palabra de paso. 2. RF2: El sistema debe autenticar a los usuarios independientemente de la m´ aquina en la que se encuentren y de forma independiente, es decir, un usuario puede iniciar su sesi´ on al mismo tiempo en tantas m´ aquinas como desee. 3. RF3: El sistema debe permitir la creaci´ on de nuevas cuentas de usuario (por parte de un administrador o una cuenta privilegiada). 4. RF4: El sistema debe permitir que un usuario pueda cambiar su palabra de paso (no ser´a posible cambiar su nombre de usuario). 5. RF5: El sistema debe proveer un directorio personal para el usuario donde poder almacenar sus ficheros personales, una vez que haya iniciado su sesi´ on. Este espacio permitir´a que los alumnos puedan almacenar sus pr´acticas en el servidor, y que puedan ver estos ficheros y directorios independientemente de la m´ aquina en la que hayan iniciado su sesi´ on. En cuanto a los requisitos no funcionales de este elemento del sistema, podemos destacar los siguientes: 1. RNF1: En cuanto al Sistema Operativo usado para implementar el sistema de autenticaci´ on, ´este debe ser un Sistema Operativo Debian GNU/Linux, a ser posible, en la u ´ltima versi´ on estable. 2. RNF2: En cuanto al sistema de cuentas de usuario en red, ´este debe estar basado en un directorio LDAP, que estar´a implementado por el software OpenLDAP, en su u ´ltima versi´ on estable tambi´en a ser posible. 3. RNF3: En cuanto a requisitos de seguridad, debemos procurar en la medida de lo posible que siempre que los datos de usuario viajen por la red, ´estos deben encontrarse cifrados utilizando t´ecnicas avanzadas de criptograf´ıa, que haga muy dif´ıcil que un usuario no autorizado pueda capturar estos datos y obtener una cuenta de usuario de forma ileg´ıtima. 4. RNF4: En cuanto a aspectos avanzados de tolerancia a fallos, replicaci´ on, divisi´ on de carga y dem´as, se debe procurar en la medida de lo posible que el sistema sea tolerante a fallos (deben duplicarse aquellos recursos que sean necesarios), el sistema sea escalable (se debe realizar un reparto de carga adecuado) y se pueda realizar una recuperaci´ on r´ apida ante cualquier tipo de desastre (se deben realizar copias de seguridad diarias de los datos de autenticaci´ on de los usuarios).

3.2.3.

Servicios de valor a˜ nadido

Por u ´ltimo vamos a poner en marcha una serie de servicios de valor a˜ nadido que van a ayudar a que el entorno sea m´ as agradable y funcional de cara a los usuarios. Dado que estos servicios son opcionales, de cara a que el uso del entorno por parte de los usuarios sea m´ as agradable y sencillo, plantearemos en su mayor´ıa requisitos funcionales, que ser´an normalmente requisitos recomendados y que no est´en del todo definidos, dejando al administrador la elecci´ on de la plataforma, sistema en concreto, etc´etera. A. Guti´errez Mayoral

35

ETSI Inform´atica

´ DE LAS MAQUINAS ´ 3.3. DEDICACION F´ISICAS 1. RF1: Se debe poner en marcha un sistema de correo que permita que los usuarios propietarios de una cuenta en el sistema puedan recibir correo (posean un buz´ on de correo en el servidor donde recibir mensajes). Este sistema permitir´a que podamos comunicarnos con los usuarios del sistema para indicarles cualquier asunto relacionado con su cuenta. 2. RF2: El entorno debe contar con una p´agina web, donde se indique el nombre de los Laboratorios, y a ser posible se documente la mayor informaci´ on posible acerca del funcionamiento interno de los mismos (horarios, normas internas de funcionamiento, recomendaciones, preguntas de uso frecuente sobre el uso del sistema, donde acudir si existe alg´ un problema, etc´etera). Tambi´en debe facilitar que los alumnos puedan colgar sus propias p´aginas web, mediante la inclusi´on de alg´ un directorio en su espacio de disco personal. Esto permitir´a que puedan generar documentaci´ on sobre las asignaturas y puedan compartirla en Internet. 3. RF3: Es recomendable que se implemente alg´ un mecanismo de listas de correo que permita la gesti´ on de anuncios a los usuarios del sistema, as´ı como la comunicaci´ on interna de los responsables del Laboratorio. Adem´ as, las listas de correo pueden ser usadas para enviar notificaciones relativas al funcionamiento interno del sistema (alertas sobre ca´ıdas en servicio, por ejemplo). 4. RF4: Debe implantarse un sistema de monitorizaci´ on y notificaci´ on de todos aquellos servicios que sean vitales para el correcto funcionamiento del Laboratorio. Este servicio debe alertar inmediatamente de cualquier ca´ıda en cualquiera de los servicios que impida que el Laboratorio pueda funcionar adecuadamente. Es recomendable que este servicio posea una interfaz web de cara al administrador y a los usuarios, que permita visualizar el estado de las estaciones y de los servidores. Como requisitos no funcionales, u ´nicamente vamos a rese˜ nar lo siguiente: 1. RNF1: se debe intentar en la medida de lo posible garantizar la seguridad en el entorno. Esto incluye la instalaci´ on de todas aquellas herramientas de detecci´ on de intrusos, seguridad y toma de decisiones relativas a la instauraci´on de pol´ıticas de seguridad que impidan al m´ aximo que un usuario pueda obtener una cuenta de usuario de forma ileg´ıtima o penetrar en alguno de los servidores cr´ıticos para el funcionamiento del Laboratorio.

3.3.

Dedicaci´ on de las m´ aquinas f´ısicas

Una vez establecidos los requisitos de manera semiformal, vamos a establecer la divisi´ on de cada uno de los subsistemas principales entre las m´ aquinas que tenemos disponibles. En principio en el Campus de M´ ostoles contamos con aproximadamente siete m´ aquinas que pueden actuar como servidores en los cuales se instalar´ an los servicios m´ as importantes que dar´ an servicio al Laboratorio. En el Campus de Fuenlabrada contamos solamente con dos servidores. La raz´on de esta diferencia en cuanto a n´ umero de servidores se debe a que inicialmente los Laboratorios de Linux comenzaron su andada en el Campus de M´ ostoles, mientras que el Campus de Fuenlabrada (que presta servicio principalmente a asignaturas que se imparten en la titulaci´on de Ingenier´ıa de Telecomunicaciones) ha comenzado hace poco, y continua ampli´andose actualmente. En el Campus de M´ ostoles contamos con las m´ aquinas peloto, zipi, zape, lechuzo, sapientin, pantuflo y espatula. Como se puede observar, los nombres de los servidores de este campus pertenecen a personajes del c´omic Zipi y Zape, de Escobar. Como vimos en el cap´ıtulo Introducci´ on, el Sistema Operativo elegido para los servidores ser´a el Sistema Operativo Debian GNU/Linux, en su versi´ on 4.0 (la u ´ltima versi´ on estable, c´odigo Etch). Proyecto Fin de Carrera

36

Universidad Rey Juan Carlos

´ Y DISENO ˜ CAP´ITULO 3. ESPECIFICACION

3.3.1.

Peloto

La m´ aquina peloto poseer´ a la direcci´on IP 212.128.4.7, y albergar´a el servidor LDAP de cuentas de usuario de forma primaria (esto es, el servidor LDAP alojado en esta m´ aquina ser´a el encargado de realizar escrituras en el directorio LDAP (en caso de que se produjeran). Adem´ as, albergar´ a un mirror o espejo de los repositorios de Debian y de Ubuntu, para que las instalaciones de software en el Laboratorio sean m´ as r´apidas.

3.3.2.

Zipi

La m´ aquina zipi poseer´ a la direcci´on IP 212.128.4.2 y albergar´ a el servidor LDAP en forma secundaria. Es uno de los servidores secundarios del directorio LDAP en el Laboratorio, adem´ as de otros servicios. En concreto la m´ aquina zipi albergar´ a el servidor DNS del laboratorio de forma primaria, aunque en este documento no ha quedado detallado este servicio.

3.3.3.

Zape

La m´ aquina zape posee la direcci´on IP 212.128.4.3 y es el segundo de los servidores secundarios de LDAP en el Campus de M´ ostoles. Junto con los otros dos servidores LDAP existentes en el Campus de M´ ostoles conforman el conjunto de los servidores de autenticaci´ on para este Campus. Como veremos posteriormente en el cap´ıtulo Implantaci´ on, la divisi´ on del servicio de autenticaci´ on en diferentes m´ aquinas nos va a garantizar la fiabilidad, escalabilidad y tolerancia a fallos del servicio. En concreto esta m´ aquina, tambi´en alberga otro servicio no detallado en este documento, que es el de resoluci´ on de nombres DNS (la m´ aquina zape alberga de forma secundaria el servicio DNS para el Laboratorio).

3.3.4.

Lechuzo

La m´ aquina lechuzo posee la direcci´on IP 212.128.4.8 y es una m´ aquina cr´ıtica para el correcto funcionamiento del Laboratorio, ya que alberga el servicio de almacenamiento de ficheros en red para los usuarios. A trav´es de este servicio los usuarios al iniciar la sesi´ on disponen de un espacio personal en el que almacenar sus ficheros personales (pr´acticas, documentos, etc´etera). Por supuesto, se trata de un servicio distribuido y en el que independientemente de la estaci´on en la que inicien la sesi´ on, dispondr´ an de los mismos ficheros. Como vimos en el cap´ıtulo Introducci´ on, la soluci´on adoptada para implementar este servicio se basa en el sistema de ficheros NFS de Linux. Aunque este servicio se encuentra duplicado (en la m´ aquina sapientin) el cese en el funcionamiento de esta m´ aquina provocar´ıa que los usuarios, a´ un pudiendo iniciar su sesi´ on en cualquier estaci´on del Laboratorio, no pudieran acceder a sus ficheros personales (la autenticaci´ on y el disco en red son servicios en principio independientes el uno del otro). Es por ello que el funcionamiento de esta m´ aquina es cr´ıtico para el funcionamiento del Laboratorio, y debe ser monitorizada constantemente para ser alertados en el preciso instante en el que se produzca cualquier problema.

3.3.5.

Sapientin

La m´ aquina sapientin posee la direcci´on IP 212.128.4.6 y en cuanto a servicios, podemos decir que es una r´eplica exacta a la m´ aquina lechuzo. Esta m´ aquina dispone de un servicio de disco en red (usando para ello el sistema de ficheros NFS de Linux) y posee una copia exacta de A. Guti´errez Mayoral

37

ETSI Inform´atica

3.4. SERVIDORES DISPONIBLES EN EL CAMPUS DE FUENLABRADA los ficheros personales de los usuarios que se encuentran alojados en la m´ aquina lechuzo. Para ello, todas las noches se sincronizan ambos directorios desde lechuzo hasta sapientin. Si se produce cualquier tipo de problema en la m´ aquina lechuzo que no sea recuperable en un periodo corto de tiempo (imaginemos que se rompe un disco en la m´ aquina lechuzo pero el Laboratorio debe seguir prestando servicio), esta m´ aquina comenzar´ a a prestar servicio de disco en red como lo estaba haciendo lechuzo. En principio, las probabilidades de que esta m´ aquina llegue a usarse son realmente bajas. Para que se deje de usar la m´ aquina lechuzo han de estropearse al menos dos discos en lechuzo, debido a que el espacio en disco se implementar´ a usando una soluci´on basada en RAID, como veremos posteriormente en el cap´ıtulo de Implantaci´ on. En cualquier caso, siempre es necesario disponer de una m´ aquina de recambio para que el servicio pueda seguir funcionando en cualquier caso ante cualquier tipo de desastre.

3.3.6.

Pantuflo

La m´ aquina pantuflo posee la direcci´on IP 212.128.4.4 y tradicionalmente ha sido la m´ aquina visible de los Laboratorios de Linux de la Escuela. Antiguamente (en los primeros a˜ nos de existencia de la Escuela, all´ a por el a˜ no 1999) era el u ´nico servidor que exist´ıa: prestaba servicio de autenticaci´ on, disco en red, p´agina web, correo, serv´ıa para que los usuarios (alumnos y profesores) se conectaran e hicieran las pr´acticas, etc´etera. Afortunadamente, los tiempos han cambiado y con la adquisici´on de nuevos servidores dedicados en exclusiva a servicios cr´ıticos para el Laboratorio (autenticaci´ on, disco en red, etc´etera) la m´ aquina pantuflo ha sido relegada a ser u ´nicamente la m´ aquina visible o buque insignia de los Laboratorios de Linux. Esta m´ aquina, solamente prestar´a servicio de p´agina web para los Laboratorios, web personales de los alumnos, y albergar´ a el sistema de correo para los usuarios. La raz´on de albergar el sistema de correo y p´agina web en esta m´ aquina, es que los alumnos ya asocian la m´ aquina pantuflo con los Laboratorios de Linux, de forma que para ellos es muy f´acil recordar (o averiguar) que la p´agina web se encuentra en la direcci´on http://pantuflo.escet.urjc.es o que las cuentas de correo del servidor terminan por @pantuflo.escet.urjc.es. Adem´ as, vamos a aprovechar esta m´ aquina para albergar las listas de correo del servidor, lo que nos va a permitir crear un canal directo de comunicaci´ on entre todos los usuarios de los Laboratorios (para enviar notificaciones, noticias y notas de r´egimen interno sobre el funcionamiento de los Laboratorios).

3.3.7.

Espatula

Por u ´ltimo, la m´ aquina espatula, con direcci´on IP 212.128.4.12 servir´a para albergar los diferentes ficheros de preconfiguraci´on de las instalaciones desatendidas que desarrollaremos posteriormente en el cap´ıtulo Implantaci´ on. Adem´ as, en esta m´ aquina instalaremos el servicio de monitorizaci´ on que nos servir´a para comprobar el estado de la red en todo momento, y que enviar´ a alertas en forma de correo electr´onico cuando se produzca alg´ un problema en cualquiera de los servidores o de los servicios cr´ıticos para el funcionamiento del Laboratorio. En principio en esta m´ aquina no alojaremos ning´ un servicio m´ as.

3.4.

Servidores disponibles en el Campus de Fuenlabrada

A diferencia del Campus de M´ ostoles, en el Campus de Fuenlabrada u ´nicamente se dispone de dos servidores principales, que asumen las labores de autenticaci´ on de usuarios y de disco en red. Bien es cierto que el n´ umero de estaciones en este campus es bastante menor que el de M´ ostoles (160 estaciones en el Campus de M´ ostoles frente a unas 100 aproximadamente en el Campus de Fuenlabrada), aunque debido a que este n´ umero est´a aumentando considerablemente, se prevee Proyecto Fin de Carrera

38

Universidad Rey Juan Carlos

´ Y DISENO ˜ CAP´ITULO 3. ESPECIFICACION que el n´ umero de servidores en el Campus de Fuenlabrada tambi´en aumente. De momento, los dos servidores de los que se dispone son bilo y nano. Estos nombres est´an inspirados en la tira de c´omic del mismo nombre, Bilo y Nano, personajes creados por Javier Malonda. Debido a que el n´ umero de servidores en este campus es menor, ser´a inevitable reunir servicios en una misma m´ aquina.

3.4.1.

Bilo

La m´ aquina bilo, posee la direcci´on IP 193.147.73.54. Es la m´ aquina an´ aloga a pantuflo para el Campus de Fuenlabrada, es decir, albergar´ a el servicio de p´agina web para ese laboratorio, as´ı como las p´aginas personales de los usuarios, el servicio de correo y la lista de correo de usuarios para este Campus. Adem´ as, albergar´ a el servicio de disco en red para los laboratorios de este Campus (debido a que solamente poseemos dos servidores, es inevitable que una sea la que sirva el disco en red y la otra la tengamos de repuesto ante posibles cat´astrofes).

3.4.2.

Nano

La m´ aquina nano posee la direcci´on IP 193.147.73.55 y tiene asociados dos servicios cr´ıticos. Por un lado, es un servidor secundario para el servicio de directorio LDAP (el servicio de cuentas de usuario en red) y por otro lado, sirve de m´ aquina de repuesto ante cualquier ca´ıda en el servicio de disco en red que provee la m´ aquina bilo (al igual que la m´ aquina sapientin en el Campus de M´ ostoles). Como se puede apreciar, disponemos de un u ´nico servicio de directorio LDAP que da servicio a ambos campus, el de M´ ostoles y el de Fuenlabrada. Por motivos de operaci´on, el servidor primario para este servicio se encuentra alojado en el Campus de M´ ostoles (debido a que nuestra localizaci´on f´ısica en la Universidad se encuentra en el Campus de M´ ostoles, resulta m´ as c´omodo tenerlo en este campus). Por el contrario, el servicio de disco en red se ofrece de forma independiente entre ambos campus, cada uno dispone de su disco particular y de sus ficheros. Evaluados en este cap´ıtulo los requisitos funcionales y no funcionales de cada una de las tres partes en las que se divide este proyecto, y dise˜ nados y divididos por servidores todos los servicios que nos proponemos construir e implementar, en el siguiente cap´ıtulo detallaremos todos los detalles t´ecnicos que son necesarios para la puesta en marcha de todos los servicios.

A. Guti´errez Mayoral

39

ETSI Inform´atica

3.4. SERVIDORES DISPONIBLES EN EL CAMPUS DE FUENLABRADA

Proyecto Fin de Carrera

40

Universidad Rey Juan Carlos

Cap´ıtulo

4

Implantaci´on Una vez llegados a este punto, nos ponemos manos a la obra para llevar a cabo uno por uno cada uno de los objetivos que nos propusimos en los cap´ıtulos Objetivos y y Dise˜ no. En primer lugar, arrancaremos formalizando e implementando un proceso completo de instalaci´ on desatendida. Este proceso, nos facilitar´ a la tarea de realizar instalaciones masivas en poco tiempo y con muy poco esfuerzo. Una vez completada esta tarea, pasaremos a implementar cada uno de los servicios de los que se compone el entorno. En primer lugar, y como servicios indispensables, un mecanismo de autenticaci´ on que permita a los usuarios poder usar tanto los terminales como los servidores oportunos. De forma paralela, un servicio de disco en red que permita tener disponible almacenar sus ficheros en el entorno distribuido. A continuaci´ on, iremos completando la implementaci´ on con m´ as servicios, que sin ser del todo indispensables, son necesarios para que el entorno funcione adecuadamente. Estos servicios (Web, correo electr´onico, resoluci´ on de nombres, listas de correo, etc´etera) quedar´ an totalmente implantados y funcionando correctamente a la finalizaci´on del presente cap´ıtulo.

41

´ AUTOMATICA ´ 4.1. HERRAMIENTA DE INSTALACION

4.1.

Herramienta de Instalaci´ on Autom´ atica

Cuando se dispone de un n´ umero muy elevado de estaciones o terminales se hace necesario el disponer de un m´etodo de instalaci´ on desatendida para que tanto la instalaci´ on del Sistema Operativo como de todo el software se haga de la forma m´ as autom´atica posible. Para llevar a cabo esta tarea, se va a utilizar el m´etodo de los ficheros de preconfiguraci´on de Debian, como se estudi´o en el cap´ıtulo Introducci´ on. Esta t´ecnica no es nueva, y viene introducida desde la versi´ on 3.0 de Debian GNU/Linux. Como vimos en la secci´ on Estado del arte, esta t´ecnica se basa en la inclusi´on de las respuestas a todas las preguntas del proceso de instalaci´ on de Debian GNU/Linux o de Ubuntu, en nuestro caso. Si dejamos alguna cuesti´ on sin especificar, el instalador nos preguntar´ a de forma interactiva sobre ella. Como es obvio, cuantas m´ as preguntas queden respondidas en este fichero, m´ as automatizado y por tanto desatendido ser´a el proceso. Las preguntas respondidas en este fichero, pueden o deben ser las siguientes, por ejemplo: Configuraci´on de la red (direcci´ on IP, puerta de enlace predeterminada, servidores de nombres DNS. Configuraci´on de la versi´ on de Ubuntu a ser instalada (por ejemplo, la actual 8.04, Ubuntu Hardy). Sitio r´eplica que debe usarse para instalar la distribuci´ on a trav´es de la red (nuestro mirror local). Disco duro donde ser´a instalado el Sistema Operativo. Particionado espec´ıfico (novato, experto, usual). Configuraci´on de la zona horaria. Configuraci´on de la herramienta de gesti´ on de software (apt-get). Contrase˜ na del superusuario (root) y creaci´ on de un usuario sin privilegios. Por u ´ltimo, ejecuci´ on de un script de postinstalaci´ on para personalizar la estaci´on a nuestro gusto. Como es frecuente en las instalaciones de las u ´ltimas versiones de Ubuntu, la mayor´ıa de las preguntas de la lista anterior son las correspondientes a las del proceso de instalaci´ on, y que dej´ andolas todas resueltas, el proceso de instalaci´ on se realizar´a completamente en silencio, sin realizar ninguna cuesti´ on al usuario y de forma totalmente desatendida. Este fichero de preconfiguraci´on debe ser incluido en el CDROM de Ubuntu con el que se pretenda instalar el sistema1 . Bastar´a con colocar el fichero de texto en el ra´ız del sistema de ficheros del CDROM y modificar algunas l´ıneas del fichero isolinux para poder en marcha nuestra soluci´on. Para ello, podemos descargar la versi´ on actual de Ubuntu, montar la imagen ISO como un sistema de ficheros de loopback, copiar y modificar los ficheros correspondientes y volver a generar la ISO. Una vez hecho esto, podemos grabar nuestro CD personalizado de Ubuntu y proceder a realizar el proceso de instalaci´ on de Ubuntu. 1 Recomendamos la consulta del ap´endice o los ficheros incluidos en el CDROM adjunto para leer un fichero de preconfiguraci´ on de ejemplo b´ asico.

Proyecto Fin de Carrera

42

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION Listado 4.1: Generaci´ on de un CD personalizado de Ubuntu para instalaci´ on autom´atica 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

# Descargamos una imagen m´ ı nima de Debian o Ubuntu $ wget http ://.../ debian -40 r0 - i386 - netinst . iso # Montamos el CD de Ubuntu $ mkdir / mnt / nueva_imagen # copiamos el preseed $ mount -o loop -t iso9660 $imagen_base / mnt / nueva_imagen # Creamos un directorio para la nueva imagen $ mkdir / copia_imagen # Copiamos todo el contenido $ cp - aRv / mnt / $nueva_iso / copia_imagen # Se modifica el fichero Isolinux , situado en # / copia imagen / nueva iso / isolinux / isolinux . cfg # Copiamos el fichero de preconfiguracion creado previamen te $ cp preseed . cfg / copia_imagen / $nueva_iso /. # Se regenera la ISO y se graba mediante Cdrecord , por ejemplo $ mkisofs -v -J -R -T -V nueva_imagen -b isolinux / isolinux . bin -c boot . cat -no - emul - boot - boot - load - size 4 - boot - info - table -o nueva_imagen . iso / copia_imagen / nueva_imagen

Pero, ¿tenemos que insertar nuestro CDROM 160 veces, y expulsarlo otras 160? ¿No existe alg´ un proceso m´ as corto? Efectivamente, lo hay. Si nuestro hardware es relativamente moderno, y nos permite realizar arranque por red, podemos realizar una instalaci´ on completa a trav´es de la red, sin tan siquiera tener que insertar nuestro CD en el equipo correspondiente. De esta forma, incluso podemos indicar que nuestro fichero de preconfiguraci´on, se encuentra en una URL concreta. Esto nos abre la puerta a un mundo de posibilidades: podemos tener un repositorio de preconfiguraciones en un servidor concreto, siempre disponible para poder servir instalaciones de equipos. Para llevar a cabo este proceso, es necesario la puesta a punto de unas cuantas herramientas. Suponemos por supuesto que nuestra placa base permite el arranque del sistema a trav´es de red (usualmente llamado PXE2 . Hablaremos de ello en adelante. De forma impl´ıcita, necesitamos un despachador de direcciones IP autom´aticas, esto es, un servidor DHCP3 .

4.1.1.

Servidor DHCP para configuraci´ on autom´ atica de Red

Como hemos visto anteriormente, si queremos que nuestras instalaciones autom´aticas se realicen a trav´es de la red, sin tan siquiera introducir un CDROM de instalaci´ on, necesitamos la puesta a punto de un servidor DHCP. Este servidor configurar´a autom´aticamente la red de la estaci´on que lo solicite, habilit´ andola para poder descargar tanto el Sistema Operativo como todas aquellas herramientas o ficheros de configuraci´ on que consideremos oportunos. Nuestro servidor DHCP se puede encontrar en cualquier servidor que tengamos en nuestra Intranet. No es necesario que se encuentre en el mismo servidor donde se encuentre el sitio r´eplica de la distribuci´on de Linux a instalar ni tampoco en el servidor donde se encuentre el fichero PXE que se descargar´a para comenzar la instalaci´ on del Sistema Operativo. Un servidor DHCP: dhcpd Si estamos usando Ubuntu o en su defecto Debian, una llamada al instalador de software apt-get ser´a suficiente para instalar r´ apidamente un servidor DHCP. Listado 4.2: Instalaci´ on del paquete dhcp a trav´es de apt-get $ apt - get install dhcp

2

PXE son las siglas de Preboot Execution Environment, o Entorno de preejecuci´ on. DHCP son las siglas de Dynamic Host Configuration Protocol, o Protocolo de Configuraci´ on din´ amica de hu´esped. 3

A. Guti´errez Mayoral

43

ETSI Inform´atica

´ AUTOMATICA ´ 4.1. HERRAMIENTA DE INSTALACION Es probable que la herramienta de configuraci´ on e instalaci´ on de paquetes dpkg solicite configuraci´ on para el citado paquete (por ejemplo el rango de direcciones IP que se va a despachar autom´aticamente). En nuestro caso, procedemos a configurar manualmente editando el fichero de configuraci´ on que encontramos en /etc/dhcpd.conf. Es necesario especificar algunos par´ ametros correspondientes a la configuraci´ on de la subred que estemos usando en ese momento. Listado 4.3: Fichero de configuraci´ on dpchd.conf. Configuraci´on de subred. subnet 212.128.4.0 netmask 255.255.255.0 { range 212.128.4.20 212.128.4.20; option broadcast - address 212.128.4.255; option routers 212.128.4.1;

1 2 3 4 5

}

Adem´ as, vamos a incluir una entrada para que el host beta01.pantuflo.es arranque autom´aticamente a trav´es de la red: Listado 4.4: Fichero de configuraci´ on dpchd.conf. Configuraci´on de host. 1 2 3 4 5 6

host beta01 { hardware ethernet 00:0 f :1 f : e4 : a9 :20; filename " pxelinux .0"; next - server 212.128.4.4; fixed - address 212.128.4.131; }

Vemos como a trav´es de la direcci´on MAC4 , asignamos autom´aticamente la direcci´on IP del equipo especificando adem´ as que busque el fichero de arranque PXE en el servidor 212.128.4.4. El fichero, se llama adem´ as pxelinux.0. Se recomienda que si el n´ umero de estaciones a instalar es muy elevado, se programe un peque˜ no script de shell (por ejemplo, en bash o sh) para automatizar la tarea de crear el fichero de configuraci´ on de DHCP. Bastar´ıa solamente a˜ nadir la salida de este peque˜ no script al fichero de configuraci´ on de DHCP y reiniciar su demonio correspondiente.

4.1.2.

Arranque por PXE

El protocolo PXE (Entorno de preejecuci´on) es un protocolo que permite el arranque de estaciones usando un interfaz de red, independientemente de los dispositivos de almacenamiento locales que se encuentren en el mismo. PXE fue introducido por Intel y est´a descrito en su especificaci´ on correspondiente5 publicado por la propia Intel y Systemsoft, el 20 de Septiembre de 1999. Este protocolo hace uso de otros tantos protocolos de red (como IP) transporte (como UDP) y aplicaci´on (como hemos visto, hace necesario el uso de DHCP para el arranque). A continuaci´ on veremos como es necesario que se use otro protocolo de la capa de aplicaci´on, TFTP para poder descargar la imagen linux correspondiente que ser´a arrancada para la instalaci´ on del Sistema Operativo. Como dijimos anteriormente, es necesario que nuestro hardware (tarjeta de red y placa base) incluya el uso de esta tecnolog´ıa para poder hacer uso de ella. Normalmente a trav´es de la herramienta de configuraci´ on de nuestra placa base podremos ver si se dispone de ella. 4

Es recomendable que si usa DHCP en su red, se asegure que solamente responde a aquellas estaciones que lo necesitan. El uso indiscriminado de DHCP puede producirle problemas a otros usuarios de su misma subred. 5 Actualmente en la versi´ on 2.1

Proyecto Fin de Carrera

44

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION Normalmente, para poder arrancar usando este protocolo, es necesario que durante el arranque de la estaci´on correspondiente, se pulse una combinaci´on de teclas (normalmente F12 o alguna otra tecla funci´on) que llame a la ejecuci´ on del protocolo. Una vez arrancado, la tarjeta solicitar´ a una petici´on DHCP a la subred para que ´esta se autoconfigure. Configuraci´ on del servicio TFTP Por u ´ltimo, y para poder comenzar con la instalaci´ on del Sistema Operativo en cuesti´ on, necesitamos una imagen del mismo y que de alguna forma, se pueda descargar de la red desde un servidor hacia la estaci´on que se est´e instalando en ese momento. Para ello, se hace uso de otro protocolo de la capa de aplicaci´on, TFTP6 . TFTP es un protocolo de transferencia de ficheros muy similar a su familiar m´ as cercano FTP7 . Este protocolo es muy usado cuando se quiere transferir archivos de peque˜ no tama˜ no entre estaciones de una misma subred. N´ otese que el que este protocolo use el protocolo de transporte UDP no es una simple elecci´ on trivial: se asume que no se va a usar TFTP para transferir ficheros muy pesados o para realizar una trasnferencia entre subredes muy alejadas. Algunos detalles de TFTP son los siguientes: Utiliza UDP (puerto 69) como protocolo de transporte (a diferencia de FTP que utiliza el puerto 21 TCP). No puede listar el contenido de los directorios. No existen mecanismos de autentificaci´ on o cifrado. Se utiliza para leer o escribir archivos de un servidor remoto. Soporta tres modos diferentes de transferencia, netascii, octet y mail, de los que los dos primeros corresponden a los modos ascii e imagen (binario) del protocolo FTP. Podemos instalar un servidor TFTP en Debian GNU/Linux o Ubuntu a trav´es del siguiente comando: Listado 4.5: Instalaci´ on del servicio tfptd-hpa a trav´es de apt-get $ apt - get install tftpd - hpa

Al igual que antes, el paquete solicitar´ a configuraci´ on. Lo vamos a configurar como demonio, ejecut´ andose de forma independiente de inetd. Para ello, el fichero de configuraci´ on situado en /etc/default/tftpd-hpa contendr´ a las siguientes l´ıneas: Listado 4.6: Fichero de configuraci´ on /etc/default/tfptd-hpa. 1 2

RUN_DAEMON =" yes " OPTIONS =" - l -s / var / lib / tftpboot "

Vemos como en el fichero de configuraci´ on se indica que se servir´an los ficheros situados por debajo del directorio /var/lib/tftboot. Esto nos servir´a para incluir en este directorio la imagen de la distribuci´on de Linux que vamos a instalar posteriormente. Para aplicar los nuevos cambios, basta con reiniciar el demonio correspondiente, tal y como muestra el listado de ´ ordenes 4.7. Listado 4.7: Reinicio del demonio tftp / etc / init . d / tftpd - hpa restart 6 7

TFTP son las siglas de Trivial File Transfer Protocol (Protocolo de transferencia de archivos trivial). FTP son las silgas de File Transfer Protocol (Protocolo de transferencia de ficheros).

A. Guti´errez Mayoral

45

ETSI Inform´atica

´ AUTOMATICA ´ 4.1. HERRAMIENTA DE INSTALACION

4.1.3.

Arranque por red de Linux

Una vez que todas las herramientas anteriores se encuentran perfectamente configuradas y se encuentran funcionando, necesitamos una imagen concreta de la distribuci´on de Linux que queremos instalar. En nuestro caso, necesitaremos una versi´ on de Ubuntu de arranque por red. Esta imagen contendr´ a una imagen m´ınima del kernel de Linux que permitir´a iniciar los dispositivos necesarios y comenzar´ a el proceso de instalaci´ on. Podemos descargar una imagen m´ınima de arranque por red desde la p´agina de Ubuntu Linux8 . En concreto, usaremos la versi´ on de arranque por red de Ubuntu Hardy (8.04) que es la versi´ on que instalaremos en el Laboratorio. Una vez que hemos descargado el fichero correspondiente, procedemos a descomprimirlo en el directorio ra´ız que sirve nuestro servidor TFTP, tal y como queda indicado en el listado 4.8. Listado 4.8: Descarga del kernel de arranque por red de Ubuntu Hardy $ wget http :// archive . ubuntu . com / ubuntu / dists / hardy / main / installer - i386 / current / images / netboot / netboot . tar . gz $ tar - xvzf pxeboot . tar . gz -C / var / lib / tftpboot /

Si todo va bien (nuestro servidor DHCP est´a funcionando correctamente y el servidor TFTP est´a sirviendo ficheros) al solicitar arranque por red en la pantalla de arranque de nuestra estaci´on, deber´ıa auto configurarse la tarjeta seg´ un su IP correspondiente, y justo a continuaci´ on, ver la pantalla principal de Ubuntu.

4.1.4.

Ficheros de preconfiguraci´ on

A continuaci´ on, vamos a ver de qu´e manera podemos automatizar todo el proceso de instalaci´ on. A partir de un fichero de preconfiguraci´on, que contiene todas las respuestas al proceso de instalaci´ on, podemos evitar que el programa de instalaci´ on de Ubuntu nos realice ninguna pregunta sobre la configuraci´ on del Sistema Operativo. Isolinux Isolinux9 es un cargador de de arranque para Linux (arquitectura i386). Necesitamos editar el fichero de configuraci´ on de Isolinux para poder indicar que queremos cargar un fichero de preconfiguraci´on. Esto lo podemos hacer de la siguiente forma: Listado 4.9: Fichero de configuraci´ on de Isolinux 1 3 5 7

LABEL i n s t a l a c i o n A u t o m a t i c a kernel ubuntu - installer / i386 / linux append vga = normal initrd = ubuntu - installer / i386 / initrd . gz netcfg / choose_interface = eth1 locale = es_ES console - setup / ask_detect = false console - setup / layoutc ode = es languagechooser / language - name = Spanish countrychooser / shortlist = ES console - keymaps - at / keymap = es netcfg / get_hostname = una ssigned - hostname preseed / url = http :// minervo . escet . urjc . es / preseed --

N´ otese el uso de la directiva preseed/url indicando que el fichero de preconfiguraci´on es un recurso HTTP situado en la direcci´on indicada por la URL. Si quisi´eramos haber incluido el fichero de preconfiguraci´on directamente en la imagen m´ınima del kernel que se arranca con el proceso de instalaci´ on, deber´ıamos hacer uso de la directiva preseed/file, indicando la ruta absoluta hacia el fichero de semilla. El fichero de configuraci´ on de isolinux puede contener numerosas opciones de arranque (cada una forma una etiqueta LABEL). Podemos tener por tanto numerosas opciones de arranque, 8 9

https://help.ubuntu.com/community/Installation/Netboot http://syslinux.zytor.com/iso.php

Proyecto Fin de Carrera

46

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION cada una dependiendo por ejemplo de un hardware espec´ıfico, o de unas opciones de instalaciones concretas. Si queremos que en cada momento se arranque siempre una instalaci´ on en concreto (una etiqueta LABEL) lo podemos hacer incluyendo las siguientes l´ıneas: Listado 4.10: Fichero de configuraci´ on de Isolinux 8 9 10

DEFAULT i n s t a l a c i o n A u t o m a t i c a PROMPT 0 TIMEOUT 0

Donde indicamos que se debe arrancar por defecto la etiqueta instalacionAutomatica, con un timeout de 0 segundos, y sin indicador de arranque. Fichero de preconfiguraci´ on Por u ´ltimo, u ´nicamente nos queda empezar a definir el fichero de preconfiguraci´on que utilizar´a el sistema de instalaci´ on autom´atica para realizar el proceso de instalaci´ on en un modo no interactivo. Este fichero es un fichero de texto, visible y modificable por cualquier editor de textos. Podemos usar nuestro editor de textos favorito para poder editar nuestro fichero de preconfiguraci´on personalizado. El fichero de preconfiguraci´on contiene todas las respuestas a cada una de las secciones del proceso de instalaci´ on. As´ı, en vez de solicitar al usuario la entrada por teclado, la leer´a de este fichero. Las opciones m´ as importantes son las relacionadas con la red, el particionado del disco duro, la configuraci´ on de la herramienta de gesti´ on de software, y la creaci´ on de usuarios. Mencionaremos las opciones m´ as importantes, dejando la posibilidad de leer el fichero de preconfiguraci´on completo en el ap´endice de este documento. En primer lugar, debemos indicar las opciones necesarias para preconfigurar la red. En nuestro caso, nos es particularmente interesante que la preconfiguraci´on se realice a trav´es del protocolo DHCP. Esto nos facilitar´ a que cada estaci´on asuma la direcci´on de red que le pertenece. Una vez finalizado el proceso, podemos cambiar esta configuraci´ on de din´ amica a est´atica, si as´ı nos sentimos m´ as seguros ante la ca´ıda del servidor DHCP y por ende el cese del funcionamiento de todas las estaciones. Esto lo podemos conseguir con las siguientes l´ıneas: Listado 4.11: El fichero de preconfiguraci´on preseed.cfg. 10 11 12

d-i d-i d-i

netcfg / choose_interface select eth1 netcfg / disable_dhcp boolean false netcfg / confirm_static boolean true

Una vez hemos configurado la red, procedemos a indicar el sitio r´eplica de donde se descargar´a la imagen del sistema base a ser instalada. Es preciso indicar tambi´en que sistema deseamos instalar (versi´ on concreta). Lo podemos indicar con el codename o nombre en clave de cada una de las versiones. En nuestro caso, vamos a instalar la vesi´ on Hardy (numerada 8.04) de la distribuci´on Ubuntu: Listado 4.12: El fichero de preconfiguraci´on preseed.cfg. 12 13 14 15 16

d-i d-i d-i d-i d-i

mirror / country mirror / http / hostname mirror / http / directory mirror / suite mirror / security - host

A. Guti´errez Mayoral

string enter information manually string peloto . escet . urjc . es string / ubuntu / string hardy peloto . escet . urjc . es

47

ETSI Inform´atica

´ AUTOMATICA ´ 4.1. HERRAMIENTA DE INSTALACION Tenga en cuenta que es interesante tener un mirror o espejo local en la Intranet para acelerar notablemente el proceso de instalaci´ on. Si por motivos de espacio no le es posible instalar un mirror completo de toda la distribuci´on, puede usar la herramienta apt-proxy para evitar descargar un mismo paquete repetidas veces (una por estaci´on). Notar´a una mejor´ıa notable en el proceso de instalaci´ on. Una parte importante del proceso de instalaci´ on reside en la configuraci´ on del particionado del disco donde se ha de instalar el Sistema Operativo. Esto requiere de numerosas l´ıneas de preconfiguraci´on que indican entre otras cosas, que disco ha de usarse en la instalaci´ on (usando la nomeclatura cl´ asica de sistemas Unix), que esquema de particionado se va a usar (para novatos, experto o con receta) y el esquema concreto que va a usarse. En nuestro caso, vamos a usar una receta 10 de partman (el programa que se encarga del particionado del disco para la instalaci´ on). Para ello, indicamos las siguientes l´ıneas: Listado 4.13: El fichero de preconfiguraci´on preseed.cfg. 16 17 18 19 20

d-i d-i d-i d-i d-i

21 22 23 24 25 26 27 28 29 30 31 32

d-i

33 34

d-i

mirror / security - host peloto . escet . urjc . es partman - auto partman - auto / select_disk string / dev / sda partman - auto / disk string / dev / sda partman - auto / method string regular partman - auto / expert_recipe string boot - root :: 300 5500 30000 ext3 $primary { } $bootable { } method { format } format { } use_filesystem { } filesystem { ext3 } mountpoint { / } . 64 512 300 % linux - swap method { swap } format { } . 100 10000 1000000000 ext3 method { format } format { } use_filesystem { } filesystem { ext3 } mountpoint { / data } . partman / choose_partition select Finish partitioning and write changes to disk partman / confirm boolean true

En la etiqueta se indica una receta de partman. Como vemos, en ella se indica que se crear´ an tres particiones, todas ellas deber´an ser formateadas, y el sistema de ficheros de todas ellas ser´a (el sistema de ficheros m´ as usado en particiones Linux). Se indican adem´ as los puntos de montaje de cada una de ellas, adem´ as como el tama˜ no (indicando el cilindro de comienzo y el de final). Se recomienda la lectura de las reglas de sintaxis para la formaci´on de recetas para el particionador partman. Es necesario configurar el lenguaje predefinido del Sistema. Adem´ as, tenemos que configurar apt-get, la herramienta de gesti´ on de paquetes de Ubuntu. Tambi´en nos interesar´ a que se use nuestro mirror local (situado en el servidor peloto.escet.urjc.es) y que adem´ as, se usen todas las secciones de las distribuciones11 . Esto lo conseguimos con las siguientes l´ıneas: Listado 4.14: El fichero de preconfiguraci´on preseed.cfg. 34 35

d-i d-i

languagechooser / language - name - fb select Spanish debian - installer / locale select es_ES . UTF -8

10

Receta viene del t´ermino anglosaj´ on recipe, muy usado en la comunidad Open source. Usualmente, en las distribuciones Debian y Ubuntu el software incluido ha estado dividido en secciones. En Ubuntu existen principalmente cuatro: main, universe, multiverse, restricted y backports. 11

Proyecto Fin de Carrera

48

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION

36 37 38 39 40 41 42 43 44 45 46 47

d-i d-i d-i d-i d-i d-i d-i d-i d-i d-i d-i d-i

apt - setup / uri_type select http apt - setup / country select enter information manually apt - setup / hostname string peloto . escet . urjc . es apt - setup / directory string / ubuntu / apt - setup / another boolean false apt - setup / security - updates boolean false apt - setup / security_host string peloto . escet . urjc . es apt - setup / main boolean true apt - setup / universe boolean true apt - setup / multiverse boolean true apt - setup / restricted boolean true apt - setup / backports boolean true

Tambi´en nos interesa configurar la zona horaria del Sistema y su localizaci´on. Lo conseguimos con las l´ıneas siguientes: Listado 4.15: El fichero de preconfiguraci´on preseed.cfg. 47 48 49

d-i d-i d-i

tzconfig / gmt boolean false tzconfig / choose_country_zone / Europe select Madrid tzconfig / c h o o s e _ c o u n t r y _ z o n e _ s i n g l e boolean true

Las cuales depender´an evidentemente de la localizaci´on de la estaci´on que se instale en ese momento. A continuaci´ on, vamos a configurar el usuario gen´erico del sistema, que dispondr´ a de privilegios especiales por medio de la herramienta sudo para convertirse en superusuario: Listado 4.16: El fichero de preconfiguraci´on preseed.cfg. 49 50 51 52

d-i passwd / user - fullname d-i passwd / username d-i passwd / user - password - crypted d-i passwd $1$ascCqW . t $ b f U O F H D Q L p B m p r 9 d O r P . a0

string agutierr string agutierr

La contrase˜ na, como se puede observar, se introduce en claro (cifrada con un peque˜ no hash. Recomendamos la inclusi´on de una contrase˜ na gen´erica y que una vez terminado el proceso, se sustituyan lo m´ as r´ apido posible los ficheros /etc/passwd y /etc/shadow. En las l´ıneas finales, indicaremos que, como u ´ltima tarea, deseamos ejecutar un script descargado de Internet. A trav´es de este script, realizaremos todas aquellas tareas que no no es posible configurar a trav´es de esta herramienta de preconfiguraci´on. En este script podremos instalar paquetes, retocar ficheros de configuraci´ on, tener en cuenta algunas particularidades espec´ıficas de hardware, etc´etera. Esta aplicaci´on es muy interesante, ya que nos permite dejar el sistema al gusto del administrador. Lo conseguimos con las l´ıneas: Listado 4.17: El fichero de preconfiguraci´on preseed.cfg. 52 53 54

d-i

preseed / late_command string wget http :// minervo . escet . urjc . es / instalacion / ajusta - linux - mostoles ; chmod + x ajusta - linux - mostoles ; sh ajusta - linux - mostoles

Por u ´ltimo, indicamos donde se instalar´ a el gestor de arranque. El gestor de arranque es necesario para poder iniciar el sistema una vez instalado. El gestor de arranque que se usa hoy en d´ıa es Grub, en detrimento de Lilo (LinuxLoader) que se usaba hasta hace muy poco en la mayor´ıa de las distribuciones. Lo conseguimos con las siguientes l´ıneas: A. Guti´errez Mayoral

49

ETSI Inform´atica

´ AUTOMATICA ´ 4.1. HERRAMIENTA DE INSTALACION Listado 4.18: El fichero de preconfiguraci´on preseed.cfg. 54 55 56

d-i d-i d-i

finish - install / reboot_in_progress note grub - installer / only_debian boolean true grub - installer / with_other_os boolean true

Preconfiguraci´ on gen´ erica de paquetes El fichero de configuraci´ on mostrado anteriormente es v´alido para todas aquellas instalaciones basadas en la versi´ on Hardy (8.04) de Ubuntu. Sin embargo, si se quiere usar este m´etodo en futuras versiones, es muy probable que la notaci´ on de la preconfiguraci´on haya cambiado. El objetivo de este apartado es la de entender como funciona internamente la preconfiguraci´on de un paquete, y poder usar este m´etodo para preconfigurar cualquier paquete en la instalaci´ on, sin necesidad de guiarnos por un m´etodo gen´erico (el fichero mostrado anteriormente). Es muy probable que si usamos este m´etodo en versiones posteriores a la usada en el presente documento, se introduzcan en la instalaci´ on nuevos paquetes (con su correspondiente configuraci´ on) que hagan que si ´este no se encuentra preconfigurado (enti´endase por preconfigurado el que se indique en el fichero de preconfiguraci´on todas las preguntas a su configuraci´ on) se muestre el di´ alogo del proceso de instalaci´ on instando a la persona que realiza el proceso de instalaci´ on a responder a las preguntas que sean necesarias. Coment´abamos en el cap´ıtulo Introducci´ on que sin duda una de las ventajas principales del m´etodo de instalaci´ on desatentida basada en ficheros de preconfiguraci´on es que el proceso se realiza autom´aticamente, sin necesidad de realizar ninguna acci´on entre el administrador que instala el sistema y el proceso de instalaci´ on. Si bien responder a una pregunta o dos en el proceso de instalaci´ on no representa mayor molestia, si el n´ umero de instalaciones es elevado, el proceso puede llegar a convertirse en tedioso.

Figura 4.1: El proceso de instalaci´ on en Debian/Ubuntu y la preconfiguraci´ on de paquetes. Si nos vemos en el papel de realizar una instalaci´ on desatendida basada en ficheros de preconfiguraci´on y tenemos la mala suerte de que el fichero incluido en el ap´endice de este documento no resulta completo frente a la preconfiguraci´on de todos los paquetes que se instalan en el proceso de instalaci´ on del sistema, no tenemos que asustarnos, puesto que el m´etodo es muy simple. En primer lugar, debemos fijarnos en qu´e paquete est´a solicitando configuraci´ on Proyecto Fin de Carrera

50

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION adicional. Para ello, podemos observar el t´ıtulo de la ventana de debconf, donde indica el paquete en cuesti´ on. Por ejemplo, en la imagen 4.1 se muestra como el paquete slapd est´a solicitando configuraci´ on adicional. Una vez que hemos identificado el paquete molesto, debemos obtener sus fuentes para inspeccionar la plantilla de configuraci´ on. Para realizar este paso, podemos optar por diversas soluciones. Si se tiene configurada una l´ınea de fuentes en el fichero /etc/apt/sources.list, simplemente una llamada a apt-src puede ser m´ as que suficiente. En el listado 4.19 se muestra la llamada a este comando. N´ otese que la llamada a apt-src no requiere privilegios especiales, y que la instalaci´ on resolver´a todos aquellos paquetes necesarios, de los que depende el que se quiere instalar. Nuestro objetivo solamente ser´a el paquete indicado en la llamada a apt-src, pudiendo obviar el resto. Listado 4.19: Instalaci´ on del paquete slapd a trav´es de apt-get $ apt - src install slapd

Una vez que las fuentes han sido descargadas, es necesario descomprimir el c´odigo fuente del paquete en busca del fichero templates. Este fichero en la mayor´ıa de las ocasiones suele encontrarse en el directorio debian/ de las fuentes del paquete. En el caso del paquete slapd, el fichero mencionado se encontrar´ıa en el directorio openldap2.32.4.7/debian/slapd.templates12 . Una vez que hemos localizado el fichero, podemos abrirlo con nuestro editor de texto favorito. Un p´arrafo del fichero puede ser el siguiente: Listado 4.20: El fichero de plantilla de debconf para el paquete slapd. 56 57 58 59 60 61

Template : slapd / no_configuration Type : boolean Default : false _Description : Omit OpenLDAP server configuration ? If you enable this option , no initial configuration or database will be created for you .

La lectura de este fichero es muy sencilla: en ´el se incluyen todas las preguntas que deben ser respondidas cuando se instala el paquete por primera vez, a trav´es de la herramienta debconf. En el caso del fragmento del fichero anterior, se indica que se realiza una pregunta que solamente puede tener dos respuestas (de ah´ı el tipo booleano), que de forma predeterminada se responder´a que No y que tiene la descripci´ on indicada en las l´ıneas siguientes. Si estuvi´eramos interesados en preconfigurar este paquete, deber´ıamos incluir una l´ınea por cada pregunta que fuera incluida en la configuraci´ on del mismo. Para el caso de la pregunta anterior, ser´ıa suficiente que incluy´eramos la siguiente l´ınea: Listado 4.21: Preconfigurando el paquete slapd. 61

slapd

slapd / no_configuration

boolean false

Con esto conseguir´ıamos que la pregunta anterior no se llevara a cabo, ya que se encuentra preconfigurada. Si realizamos este mecanismo para todas aquellas preguntas que interfieren en el proceso de instalaci´ on no dejando que sea un proceso desatendido al cien por cien, habremos conseguido que no sea necesario realizar ninguna acci´on para instalar el paquete en cuesti´ on. Como vemos, la preconfiguraci´on de paquetes es un m´etodo muy potente y flexible, que nos brinda la posibilidad de realizar procesos de instalaci´ on completamente desatendidos sin m´ as 12

Fuentes del paquete slapd en la distribuci´ on Ubuntu Hardy.

A. Guti´errez Mayoral

51

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION que inspeccionar los ficheros de plantilla que requieren los paquetes que estemos interesados en instalar.

4.2.

Protocolos situados en la capa de aplicaci´ on

En esta secci´ on se detallar´a c´omo se ha llevado a cabo la implementaci´ on todos los protocolos que son necesarios para el correcto funcionamiento del entorno. Sin duda, los dos m´ as importantes son el servicio de cuentas de usuario, y el servicio de disco en red. A trav´es de estos dos protocolos los usuarios podr´an iniciar su sesi´ on en cada una de las estaciones y poder acceder a sus ficheros, independientemente de la estaci´on en la que se encuentren.

4.2.1.

Servidor LDAP de cuentas de usuario

Un punto muy importante en cualquier sistema que se precie, es la gesti´ on de los usuarios en red. Teniendo en cuenta que se trata de un sistema que va a soportar un n´ umero muy elevado de usuarios en l´ınea, son muchos los factores a tener en cuenta. La implementaci´ on del servicio de cuentas de usuario se llevar´ a a cabo mediante la gesti´ on de un directorio de tipo LDAP, tal y como estudiamos en el cap´ıtulo Introducci´ on, donde realizamos una comparativa de las diferentes tecnolog´ıas para llevar a cabo una implementaci´ on de cuentas de usuario en red. Instalaci´ on del servicio LDAP Una vez comentadas las motivaciones principales que nos convencieron a proceder al cambio de los protocolos NIS a LDAP, vamos a proceder a meternos en harina detallando cuales son los pasos necesarios para poder implementar un entorno de autenticaci´ on segura basado en el protocolo LDAP. En primer lugar, necesitamos por supuesto uno o m´ as servidores LDAP. Cabe rese˜ nar en cuanto a la nomenclatura usada, que el t´ermino LDAP hace referencia al protocolo, descrito por la RFC13 correspondiente14 ; mientras que existen aplicaciones con diferentes licencias que implementan el citado protocolo. Una de las m´ as usadas hoy en d´ıa en la mayor´ıa de servidores Unix y Linux (adem´as de otros Sistemas Operativos de la familia Unix) es OpenLDAP, un software que proporciona un servidor basado en el protocolo LDAP. En nuestro caso, ser´a el que usemos. Como comentamos en el cap´ıtulo de dise˜ no, en los servidores del entorno se usar´ a la distribuci´on Debian GNU/Linux, en versi´ on estable (actualmente, la 4.0 con c´odigo Etch). La instalaci´ on de la aplicaci´on OpenLDAP en una distribuci´ on Debian es realmente sencilla, y se basa en una llamada muy simple a su herramienta de instalaci´ on de Software, como queda reflejado en el listado 4.22. Listado 4.22: Instalaci´ on del paquete slapd a trav´es de apt-get $ apt - get install slapd

En Debian, y en la mayor´ıa de distribuciones Linux, la aplicaci´on OpenLDAP se provee a trav´es del paquete slapd. La instalaci´ on del paquete resolver´a aquellas dependencias que se consideren oportunas para que el servidor pueda funcionar adecuadamente. En el proceso de instalaci´ on del paquete, es necesario responder a algunas preguntas relativas a la configuraci´ on del paquete en el entorno en el que va a ser instalado. Algunas de ellas son cu´ al 13

RFC son las siglas de Request for comments, documentos que describen detalladamente el comportamiento de un protocolo. 14 http://www.faqs.org/rfcs/rfc2251.html

Proyecto Fin de Carrera

52

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION ser´a la ra´ız del directorio LDAP, la contrase˜ na del administrador, la elecci´ on del sistema gestor de base de datos que almacenar´a los datos del directorio y poco m´ as. En nuestro caso, hemos decidido que: La ra´ız del arbol ´ LDAP se identifique mediante la cadena siguiente: dc=zipi,dc=escet,dc=urjc,dc=es. Este nombre se debe a la notaci´ on de los nombres de las m´ aquinas usado en la Universidad. El tipo de base de datos que almacenar´an los datos del directorio ser´a DBD. La contrase˜ na de administrador de LDAP es un dato que queda privado de cara al administrador del sistema. Una vez que hemos decidido estos par´ ametros, el servidor queda instalado, y se inicia en el puerto est´andar de LDAP: el puerto 389. Este puerto recibir´a las peticiones de los clientes sobre consultas al directorio LDAP: en texto claro. Cualquier usuario que tenga acceso a la red podr´a escuchar estas peticiones y averiguar datos sensibles (muy sensibles, como la contrase˜ na de su cuenta, por ejemplo) de los usuarios. Es por tanto, que nuestra primera tarea avanzada ser´a securizar el servidor de cara a crear conexiones seguras entre los clientes y el servidor LDAP. El protocolo LDAP: conceptos b´ asicos Hasta el momento hemos detallado como se lleva a cabo la instalaci´ on b´asica de un servidor LDAP. Sin embargo, no sabemos hasta el momento como funciona realmente este protocolo. Vamos a realizar una descripci´ on t´ecnica muy breve de c´omo se organizan los datos en un servidor LDAP y c´omo funciona ´este realmente (a grandes rasgos). Sin duda, estas explicaciones son fundamentales de cara a mejorar la funcionalidad del servidor, poder agrupar los datos en organizaciones o sub´arboles, y dotar al servidor de aspectos avanzados como son la replicaci´ on y el reparto de carga. Como hemos dicho, LDAP proporciona servicios de directorio: una base de datos centralizada de informaci´ on esencial sobre personas, usuarios, grupos de usuarios, etc´etera. Puesto que cada organizaci´on se estructura de una forma y su definici´on de informaci´ on esencial puede ser muy distinta, un servicio de directorio debe ser muy flexible y personalizable. El eje fundamental de un servicio de directorio es proporcionar un mapa de distribuci´on de una compa˜ n´ıa, en este caso, de una organizaci´on de los usuarios de una Universidad. Una de las caracter´ısticas m´ as visibles de una estructura de base de datos LDAP es la convenci´on en los nombres que se usa: es fundamental llevar a cabo una convenci´on de nombres que identifique la estructura organizativa de la empresa u organizaci´on que se quiere representar antes de configurar el servidor. Este sistema, puede resultar muy parecido y similar al Sistema de Resoluci´on de nombres DNS, en el que cada compa˜ n´ıa debe encajar en un u ´nico nombre de dominio de primer nivel, pudiendo crear por debajo multitud de nombres dependiendo de la estructura de servicios de la empresa. En este sentido la organizaci´on de los nombres en una base de datos LDAP es muy similar. En una base de datos LDAP, la organizaci´on se estructura en forma de ´arbol, en el que existe una ra´ız o elemento superior que se crea en el momento de la instalaci´ on (este par´ ametro se corresponde cuando la configuraci´ on del servidor nos preguntaba acerca de la ra´ız del ´arbol). Por debajo, se encuentran los elementos de informaci´ on llamados nodos, los cuales deben pertenecer a un tipo concreto. Este tipo, es llamado el elemento estructural del nodo, que en principio, no tiene porqu´e ser uno solamente, sino que pueden ser varios. Existen varios tipos predefinidos que pueden ser usados para representar elementos de informaci´ on com´ unmente usados hoy en d´ıa: para almacenar la informaci´ on de una persona, podemos usar el tipo person, para almacenar la A. Guti´errez Mayoral

53

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION informaci´ on de una cuenta de usuario en un sistema Unix, podemos usar el tipo posixAccount, mientras que para poder representar la informaci´ on de un grupo en un sistema Unix, se facilita el tipo posixGroup. Una vez que el tipo de un nodo queda establecido, podemos asignar valores a los atributos que nos facilita ese tipo estructural. Parece razonable que si un elemento posee el tipo posixAccount, se pueda saber el nombre de usuario, su UID, el grupo al que pertenece, su gecos, y seguramente algunos campos m´ as. Sin embargo, si un objeto posee la estructura posixGroup, seguramente nos baste con saber el nombre del grupo y su identificador num´erico. Podemos decir que cada objeto que exista en el directorio LDAP va a constar de una serie de tipos estructurales a los que pertenece, adem´ as de un nombre o identificador que va a posicionar al elemento en un punto concreto del directorio. Este nombre se denomina nombre distinguido o distinguished name. Dependiendo del punto en el que se encuentre el objeto dentro del ´arbol, este tendr´ a un dn diferente a otro. Normalmente, el dn se construye concatenando la sucesi´on de nodos por los que es necesario pasar para poder llegar al objeto, de forma muy similar al servicio de nombres DNS. Existen tipos predefinidos que se facilitan para poder agrupar elementos, y poder as´ı crear organizaciones dentro del ´ arbol. Normalmente, estos tipos reciben el nombre de unidad organizativa o organizational unit. A trav´es de estos elementos estructurales, podremos agrupar elementos finales (como cuentas de usuario, por ejemplo) en diferentes sub´arboles, como veremos a continuaci´ on. La jerarqu´ıa de nuestro directorio LDAP Una vez llegados a este punto, es necesario decidir c´omo estar´a estructurado el directorio LDAP donde se encontrar´ an las cuentas de los usuarios de nuestro sistema. Para empezar, debemos decidir cuales son las diferencias entre los tipos de usuario que vamos a almacenar en nuestro directorio, que se detallan a continuaci´ on: En primer lugar, necesitamos almacenar cuentas de usuario de dos tipos, fundamentalmente: estudiantes que cursan asignaturas (normalmente, pertenecientes a titulaciones de grado y postgrado) y profesores que imparten estas asignaturas. Los estudiantes pueden pertenecer al Campus de M´ ostoles (Escuelas de Ciencias Tecnol´ogicas e Inform´atica) o al Campus de Fuenlabrada (Escuelas de Telecomunicaci´ on y Facultad de Comunicaci´ on Audiovisual). Sin embargo, los profesores que imparten las asignaturas, suelen pertenecer al Campus de M´ ostoles (al menos, su localizaci´on geogr´ afica se encuentra en M´ ostoles) y pueden impartir asignaturas en un campus, o en ambos. Adem´ as, es preciso saber de cada alumno, el a˜ no en el que obtuvo la cuenta, sin importar en principio la asignatura para la que la usa (ya que en cada carrera, suele usarse en diferentes asignaturas). Con estas premisas, se ve claramente que los profesores, deben poder usar su cuenta en ambos campus (no se hace distinci´on entre los profesores de Fuenlabrada y los profesores de M´ ostoles) y que las cuentas de los alumnos de cada campus deben estar organizadas o separadas por el campus al que pertenecen. Adem´ as, es muy probable que un profesor pueda acceder a recursos o a m´ aquinas a las que no pueden acceder los alumnos estudiantes. Es por ello que una vez m´ as, deberemos separar muy bien esta organizaci´ on en el esquema del ´arbol LDAP. Podemos ver una primera versi´ on de esta jerarqu´ıa en la imagen 4.2. En ella vemos como la ra´ız del ´arbol LDAP Proyecto Fin de Carrera

54

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION contiene dos nodos principales, en los que se crean dos unidades organizativas: los alumnos por un lado, y los profesores por otro.

dc=admin,dc=zipi,dc=es cet,dc=urjc,dc=es

ou=alumnos,dc=zipi, dc=escet,dc=urjc,dc= es

ou=profesores,dc=zipi, dc=escet,dc=urjc,dc=e s

Figura 4.2: La raiz del a ´rbol LDAP contiene dos unidades organizativas principales: alumnos y profesores. Si nos centramos en la unidad organizativa de alumnos, debemos tener en cuenta que ´estos pueden pertenecer a dos campus: al campus de M´ ostoles, o al campus de Fuenlabrada. Es por ello, que decidimos de la misma forma representar esta divisi´ on en el ´arbol LDAP en forma de dos unidades organizativas, como se puede ver en la imagen 4.3.

Figura 4.3: La unidad organizativa de alumnos se subdivide a su vez en otras dos: alumnos de M´ ostoles y alumnos de Fuenlabrada. Por el contrario, en el grupo de profesores, no es necesario realizar ninguna distinci´on adicional: podemos decir que todos los profesores se deben encontrar en el mismo nivel del ´arbol LDAP. Es por ello, que directamente agrupamos sus usuarios y grupos (objetos de las clases PosixAccount y PosixGroup) en el nivel de la unidad organizativa profesores que ve´ıamos en la imagen 4.2. A. Guti´errez Mayoral

55

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Esta representaci´ on se puede observar en la imagen 4.4.

ou=profesores, dc=zipi,dc=escet, dc=urjc,dc=es

ou=usuarios (...)

ou=grupos (...)

Figura 4.4: La unidad organizativa de profesores contiene dos unidades organizativas que almacenan los objetos posixAccount y posixGroup.

Configuraci´ on de los clientes Una vez que se ha configurado los servidores, es necesario pasar a configurar los clientes para que ´estos puedan autenticar a sus usarios mediante un directorio LDAP. Usando Ubuntu, solamente es necesario instalar un par de paquetes para disponer de las herramientas adecuadas. Estos paquetes son libnss-ldap y libpam-ldap, los cuales proveen de las bibliotecas oportunas para poder autenticar a usuarios a trav´es de un directorio LDAP. La instalaci´ on de estos paquetes en Ubuntu es inmediata y bastante simple, realizando una llamada al instalador de paquetes apt, como queda reflejado en el listado 4.23. Listado 4.23: Instalaci´ on de las bibliotecas necesarias para la autenticaci´ on PAM v´ıa LDAP $ apt - get install -- assume - yes libnss - ldap libpam - ldap

Es posible que los paquetes instalados anteriormente requieran configuraci´ on adicional, como por ejemplo, la ra´ız del ´ arbol LDAP a partir del cual se buscar´an los usuarios a autenticar. En nuestro caso, vamos a responder a todas las preguntas por omisi´ on y a configurar estos datos de forma manual. En principio, para poder autenticar a los usuarios de un sistema Ubuntu mediante LDAP, es necesario configurar al menos los siguientes ficheros: El fichero /etc/nsswitch.conf en el que se indicar´a que los datos de los usuarios y los grupos proceden de una base de datos LDAP. El fichero /etc/ldap/ldap.conf en el que se deben introducir los datos de conexi´ on a los servidores LDAP (URIs de los servidores) y alg´ un otro par´ ametro, como por ejemplo si es necesario establecer una conexi´ on segura al servidor. Los ficheros /etc/pam ldap.conf y /etc/libnss-ldap.conf, en los que es necesario configurar entre otras cosas, los datos de conexi´ on a los servidores LDAP, la ra´ız del ´arbol LDAP a partir de la cual se deben buscar a los usuarios, y muchos otros par´ ametros que para nosotros ser´an transparentes. Proyecto Fin de Carrera

56

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION Los ficheros de los m´ odulos de autenticaci´ on PAM, situados bajo el directorio /etc/pam.d/. En este directorio se situan los ficheros de configuraci´ on de los m´ odulos de autenticaci´ on de usuario, en los que ser´a necesario indicar que la autenticaci´ on se llevar´ a a cabo mediante LDAP. Vamos a ver de forma m´ as detallada los ficheros de configuraci´ on m´ as importantes. Fichero /etc/nsswitch.conf En este fichero se indica de donde provienen las bases de datos de los servicios m´ as importantes del sistema, como los usuarios y los grupos. En nuestro caso, ser´a necesario anteponer la palabra LDAP para indicar que los datos de los usuarios y los grupos provienen de una base de datos LDAP, tal y como muestra el fichero 4.24. Listado 4.24: Contenido del fichero nsswitch.conf para autenticaci´ on v´ıa LDAP passwd : group : shadow :

files ldap files ldap files ldap

Fichero /etc/pam ldap.conf Este fichero contiene la configuraci´ on de PAM que accede a servicios de directorio LDAP. En este fichero, los datos de configuraci´ on m´ as importantes son las cadenas de conexi´ on al servidor LDAP y la raiz del ´ arbol a partir de la cual se empiezan a buscar usuarios. Podemos ver esta configuraci´ on en el siguiente fragmento del fichero de configuraci´ on mostrado en el listado del fichero 4.25. Listado 4.25: Contenido del fichero pam ldap.conf para autenticaci´ on v´ıa LDAP uri ldaps :// peloto . escet . urjc . es base dc = zipi , dc = escet , dc = urjc , dc = es ldap_version 3 bind_policy soft

fichero /etc/libnss-ldap.conf Este fichero es bastante parecido al anterior, y contiene la informaci´ on para poder acceder a un servidor LDAP en el caso en el que se usen bases de datos LDAP en la base de datos de los servicios del sistema (Fichero nsswitch.conf). Las l´ıneas m´ as significativas de este fichero son bastante parecidas al anterior, y se muestran en el listado del fichero 4.26. Listado 4.26: Contenido del fichero libnss-ldap.conf para autenticaci´ on v´ıa LDAP uri ldaps :// peloto . escet . urjc . es base dc = zipi , dc = escet , dc = urjc , dc = es ldap_version 3 bind_policy soft

M´ odulos de PAM bajo /etc/pam.d/ Por u ´ltimo, es necesario configurar todos los ficheros de autenticaci´ on de PAM para que usen la autenticaci´ on bajo un directorio LDAP. Este directorio, contiene los ficheros necesarios para la autenticaci´ on, adem´ as de un fichero por cada servicio que requiere autenticaci´ on en el sistema (ssh, screensaver, gdm, etc´etera). Debemos ser cuidadosos en el sentido de que si tenemos un servicio que requiere autenticaci´ on pero no a˜ nadimos su fichero correspondiente en este directorio, ese servicio no podr´a autenticar v´ıa LDAP con nuestro servicio de autenticaci´ on. Por ejemplo, si no se crea el servicio de autenticaci´ on screensaver, cuando un usuario lance el salvapantallas en una sesi´ on X y deje la pantalla bloqueada (es necesario introducir el nombre de usuario y la contrase˜ na A. Guti´errez Mayoral

57

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION para volver a retomar su sesi´ on) no podr´a desbloquearla, puesto que el servicio salvapantallas no podr´a autenticar contra el servicio de autenticaci´ on LDAP. Migraci´ on de cuentas NIS a LDAP Un aspecto importante de la decisi´ on de implantaci´ on de un servidor LDAP para la administraci´on de cuentas de usuario es la seguridad de poder migrar la base de datos actual de usuarios (ahora mismo en NIS) a la base de datos LDAP. En el momento en el que se realiza la migraci´ on, el n´ umero de usuarios en el sistema es aproximadamente de dos mil usuarios (solamente en el Campus de M´ ostoles, que es el primero en el que se propone la migraci´ on). Sin duda, no nos podemos plantear la migraci´ on a la tecnolog´ıa LDAP si no tenemos una herramienta que automatice todo el proceso de migraci´ on de cuentas (es impensable migrar dos mil cuentas de usuario a mano). Por eso, lo primero que debemos hacer es localizar una herramienta que pueda traducir el fichero actual de usuarios (recordamos que la una base de datos NIS es equivalente a los ficheros de usuarios /etc/passwd y /etc/shadow tradicionales) a una base de datos o fichero de importaci´ on de datos de LDAP, un fichero LDIF15 que contendr´ a todos los usuarios actuales y que u ´nicamente tendremos que volcar en la base de datos LDAP. Para esta tarea, se provee de unas herramientas muy u ´tiles que nos ayudar´an en la tarea de la migraci´ on de un formato a otro. Una vez m´ as, este paquete se encuentra en la mayor´ıa de las distribuciones usadas hoy en d´ıa, y como no, en Debian GNU/Linux: Listado 4.27: Instalaci´ on del conjunto de herramientas migrationtools a trav´es de apt-get $ apt - get install migrationtools

El uso de estas herramientas es realmente simple y muy potente. Las aplicaciones quedan instaladas bajo el directorio /usr/share/migrationtools/. En este directorio podemos localizar el script migrate passwd.pl, el cual se encarga de transformar los ficheros /etc/passwd y /etc/shadow de la m´ aquina donde ejecuta el script en el formato adecuado de una base de datos LDAP: la salida, mostrada por pantalla, es un fichero LDIF que contiene los usuarios de estos ficheros transformados al formato correspondiente. Con un poco de mano, podemos transformar este peque˜ no script escrito en Perl para que tome como argumentos ficheros pasados al invocar al programa, aumentando as´ı la versatibilidad del mismo. Adem´ as, como vimos en el apartado anterior (Jerarqu´ıa de nuestro servidor LDAP), podemos separar las cuentas entre los profesores y los alumnos, haciendo que para cada uno de ellos, se muestre un nombre distinguido diferente. Estas operaciones auxiliares, se pueden realizar haciendo uso de comandos est´andar de Unix, como sed, awk, grep y cut. Una vez que tenemos los datos de los usuarios almacenados en un fichero de intercambio de informaci´ on LDAP (simplemente, redirigiendo la salida de la herramienta de migraci´ on a un fichero) procedemos a la carga de este fichero en el servidor LDAP. Esta operaci´on, se realiza a trav´es de la herramienta ldapadd 16 , de la siguiente forma: Listado 4.28: Modificando registros en el ´arbol LDAP usando ldapadd

$ ldapadd -x -H ldap :// peloto . escet . urjc . es -D ’ cn = admin , dc = zipi , dc = escet , dc = urjc , dc = es ’ -W -f cuentas . ld

En el comando, que sirve para a˜ nadir informaci´ on a un servidor LDAP, se especifican los siguientes par´ ametros: 1. El modificador -x asume que la autenticaci´ on es simple, en vez de usar el protocolo SASL. 15 16

LDIF son las siglas de LDAP Interchange format o formato de intercambio de datos LDAP Para poder usar el comando ldapadd es necesario tener instalado el paquete ldap-utils.

Proyecto Fin de Carrera

58

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION 2. La localizaci´on del servidor LDAP, especificado mediante una URI (identificador de recurso universal). 3. Se pasa como par´ ametro (-D) el nombre distinguido del usuario administrador, que es en ese momento el que permite realizar escrituras en el ´arbol LDAP. En general el modificador -D sirve para atarse al servidor con un nombre de usuario concreto. 4. El modificador -W para que el comando pregunte de forma interactiva al usuario por su contrase˜ na o palabra de paso. 5. Y por u ´ltimo, se pasa con el modificador -f, el nombre de fichero con los datos en formato LDIF que se pretenden a˜ nadir al servidor. La llamada al comando provocar´a que se muestre por la salida est´andar un peque˜ no mensaje por cada nodo o entrada que se va a˜ nadiendo al ´arbol LDAP. En caso de error, ´este tambi´en se mostrar´a, y depender´a de c´omo se haya invocado al comando la interrupci´on inmediata o asumir la continua carga del fichero en el servidor para continuar o no la ejecuci´ on. Una vez concluido este paso, podemos decir que tenemos completamente migrada nuestra base de datos de usuarios anterior (en formato NIS) a un servidor de directorio LDAP, por lo que los clientes, ya ser´an capaces de autenticar con los usuarios actuales del sistema, a trav´es de un servidor de autenticaci´ on LDAP. A partir de este momento, vamos a centrar nuestra tarea en dotar al servidor de aspectos avanzados muy interesantes (y muchos de ellos indispensables) como implementar una conexi´ on segura entre el servidor y los clientes (recordamos que ahora mismo el intercambio de informaci´ on se realiza en texto claro), adem´ as de implementar la funcionalidad de reparto de carga y replicaci´ on para aumentar la fiabilidad y seguridad del servicio. Aspectos avanzados: Aumentando la seguridad Ahora mismo, tenemos un entorno de autenticaci´ on de usuarios bajo un directorio LDAP totalmente funcional. Los usuarios podr´ıan autenticarse sin problemas en las estaciones clientes, con la misma contrase˜ na que tuvieran antes (ya que hemos migrado la base de datos de usuarios y para el usuario final, la autenticaci´ on es completamente transparente). Sin embargo, sino realizamos ning´ un ajuste adicional, podr´ıamos tener problemas con usuarios maliciosos que tuvieran acceso a herramientas de escaneo de tr´afico en una interfaz de red determinada. Sin duda, esto en un entorno real empresarial, ser´ıa dif´ıcil que ocurriera. Sin embargo, en un entorno universitario, en el que muchas de las pr´acticas que se realizan tienen que ver con el an´ alisis del tr´afico de red de determinados protocolos, esto es completamente normal. En la figura 4.5 se muestran los paquetes capturados en el momento en el que un usuario inicia una sesi´ on en una m´ aquina. Vemos como bajo el protocolo LDAP, en el campo de datos del paquete TCP se muestran claramente el nombre de usuario y la contrase˜ na del usuario en cuesti´ on, lo que demuestra que el esquema que nos hemos planteado hasta el momento adolece de problemas de seguridad bastante evidentes. Por eso, no podemos poner en funcionamiento nuestro sistema todav´ıa sin antes establecer una conexi´ on segura entre los clientes y el servidor de autenticaci´ on. Para poder completar esta tarea, nos vemos obligados a la realizaci´on de los siguientes pasos: Del lado del servidor, ser´a necesario la creaci´ on de un certificado para poder establecer la comunicaci´ on usando los protocolos de seguridad SSL/TLS. Podemos crear el certificado de dos formas: la m´ as sencilla (en principio ser´a la que se usar´ a en nuestro entorno, por simplicidad) contempla la creaci´ on de un certificado auto firmado. La forma m´ as compleja contempla el caso de que nuestro certificado sea firmado por una entidad certificadora (una CA). Podemos usar este m´etodo tambi´en, siguiendo los siguientes pasos: A. Guti´errez Mayoral

59

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION

Figura 4.5: La aplicaci´ on wireshark muestra como se mandan los datos de autenticaci´ on en claro entre cliente y servidor, con nuestro esquema actual. 1. Creamos la entidad certificadora 2. Creamos el certificado 3. Firmamos el certificado mediante la entidad certificadora. Sin embargo, por simplicidad (en principio, no dependemos de ninguna entidad certificadora) usaremos un certificado auto firmado. De cara a los clientes, deberemos modificar los par´ ametros de conexi´ on para que ´esta se realice a trav´es de otro puerto (el protocolo LDAP sobre SSL usa el puerto 636). En principio estas modificaciones en los clientes ser´ıan m´ as que suficientes. Creaci´ on de un certificado auto firmado Para llevar a cabo la creaci´ on de un certificado auto firmado hemos de seguir los siguientes pasos. En primer lugar, hemos de tener instaladas en nuestro sistema las herramientas relacionadas con la creaci´ on de certificados SSL, provistas en su mayor´ıa por el paquete openssl. Lo instalamos de la forma habitual: Listado 4.29: Instalaci´ on del paquete openssl a trav´es de apt-get $ apt - get install openssl

Una vez instalado el paquete, bajo el directorio /usr/lib/ssl/misc/ tenemos los scripts necesarios para nuestra tarea. El comando que deberemos lanzar para crear el certificado, es el siguiente: Listado 4.30: Creaci´on de un certificado para nuestro servidor LDAP $ openssl req - newkey rsa :1024 - x509 - nodes - out server . pem - keyout server . pem - days 365

Entre los modificadores m´ as importantes de este comando, se encuentran donde se guardar´a el certificado de salida (fichero server.pem), la duraci´ on antes de que el certificado expire (365 d´ıas), Proyecto Fin de Carrera

60

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION y el tama˜ no de la clave (1024 bits). Una vez que invocamos el comando, ´este nos preguntar´ a acerca de la informaci´ on que contendr´ a el certificado. Es muy importante que cuando nos pregunte acerca del nombre com´ un o Common Name del certificado, escribamos exactamente el elemento raiz del ´arbol LDAP: en nuestro caso, recordamos que era dc=zipi,dc=escet,dc=urjc,dc=es. Si no escribimos literalmente esto, la conexi´ on desde los clientes fallar´ a. El resto de preguntas tienen que ver con la organizaci´on donde se usar´ a, el correo de la persona responsable, etc´etera. Configuraci´ on de OpenLDAP para el uso del certificado Una vez que hemos creado el certificado (´este se encuentra en el fichero server.pem) debemos modificar la configuraci´ on del servidor OpenLDAP para el uso del certificado, y que ´este atienda peticiones a trav´es de un canal de comunicaci´ on seguro (basado en SSL/TLS). Para ello, editamos el fichero /etc/ldap/slapd.conf, que es el fichero de configuraci´ on del servidor LDAP, y a˜ nadimos al final del fichero las siguientes l´ıneas: Listado 4.31: L´ıneas necesarias para proporcionar soporte SSL al servidor LDAP 1 2 3 4

TLSCipherSuite HIGH : MEDIUM : - SSLv2 T L S C A C e r t i f i c a t e F i l e / etc / ldap / ssl / server . pem TLSCertificateFile / etc / ldap / ssl / server . pem T L S C e r t i f i c a t e K e y F i l e / etc / ldap / ssl / server . pem

Hemos copiado el certificado del servidor a la localizaci´on /etc/ldap/ssl/. Por u ´ltimo, es necesario modificar las opciones de arranque del demonio LDAP para que cambie el puerto en el que atender´ a peticiones a partir de ahora. Este paso es muy simple, y se consigue editando el fichero /etc/default/slapd y a˜ nadiendo la l´ınea Listado 4.32: L´ıneas necesarias para proporcionar soporte SSL al servidor LDAP 1

SLAPD_SERVICES =" ldaps ://"

Donde la cadena ldaps:// indica que el protocolo de comunicaci´ on usado se basar´a a partir de ahora en SSL/TLS. Si quisi´eramos tener ambos m´etodos de conexi´ on disponibles (tanto seguro como no seguro) hubiera bastado con dejar ambas cadenas disponibles (ldaps:// y ldap://). En principio, como nos interesa que los clientes u ´nicamente puedan conectar al servidor usando un canal seguro, dejaremos la opci´ on indicada como predeterminada. Una vez efectuados todos estos cambios, bastar´ıa reiniciar el servidor LDAP para que fueran aplicados: Listado 4.33: Reinicio del demonio slapd / etc / init . d / slapd restart

Podemos comprobar con ayuda de la herramienta nmap que el servidor LDAP se ha iniciado correctamente en el puerto SSL: 636/ tcp open

ldapssl

Configuraci´ on de los clientes Los cambios que se deben efectuar en los clientes para que efect´ uen una conexi´ on al servidor LDAP son realmente simples, y se basar´an en la sustituci´ on de la cadena de conexi´ on que especifica la localizaci´on del servidor LDAP. As´ı, debemos editar los siguientes ficheros: En el fichero /etc/ldap/ldap.conf, sustituimos la cadena ldap:// por ldaps:// En los ficheros /etc/libpam ldap.conf y /etc/libnss-ldap.conf se realiza la misma modificaci´ on. A. Guti´errez Mayoral

61

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Adem´ as, en el fichero /etc/ldap/ldap.conf se a˜ nade la linea tls reqcert never para que no se compruebe el certificado del lado de los clientes. Si no a˜ nadimos esto, la conexi´ on probablemente fallar´ıa del lado del servidor, puesto que el cliente no le va a ofrecer ning´ un certificado.

Figura 4.6: Una vez establecida la conexi´ on segura entre cliente y servidor LDAP resulta m´ as dif´ıcil capturar datos de autenticaci´ on de usuarios. Una vez realizadas todas las modificaciones, procedemos a realizar la misma prueba que realizamos antes. Apoy´andonos en la herramienta wireshark, procedemos a autenticarnos en el sistema. Vemos como ahora el protocolo que se identifica es SSL/TLS, y que resulta pr´acticamente imposible identificar cualquier campo del mensaje puesto que ahora se encuentran cifrados. Se puede observar en la imagen 4.6 como ahora resulta imposible identificar datos de usuarios analizando el tr´afico que pasa por el interfaz de red. Aspectos avanzados: Reparto de carga Vimos como en el cap´ıtulo de dise˜ no ´ıbamos a dedicar tres m´ aquinas en el Campus de M´ ostoles para que dispusieran de servidor de directorio LDAP. Evidentemente, en esta configuraci´ on, una de las m´ aquinas servir´a la base de datos LDAP de forma primaria (lectura y escritura de datos) y el resto de las m´ aquinas lo servir´an de forma secundaria (solamente lectura). Esta configuraci´ on nos permitir´a separar la carga de todos los laboratorios por m´ aquinas (160 m´ aquinas en un campus y 140 en otro es mucha carga para un u ´nico servidor LDAP por campus), adem´ as de poder realizar replicaci´ on del servidor primario a los secundarios y disponer de la misma base de datos LDAP en diferentes localizaciones (de cara a que pudiera ocurrir una tragedia y necesit´aramos acceder a los datos de las cuentas). La m´ aquina principal en este esquema, tal y como vimos en el capitulo de Dise˜ no, ser´a la m´ aquina peloto (con direcci´on IP 212.128.4.7) la cual se va a encargar de servir el directorio LDAP de forma primaria. Esto significa que siempre que se necesite realizar una escritura en el directorio (creaci´ on de una cuenta o cambio de una contrase˜ na) se deber´a realizar en el servidor LDAP de peloto. Por el contrario, las lecturas de datos (autenticaci´ on de un usuario frente al directorio) se podr´an realizar en cualquiera de los servidores secundarios. Proyecto Fin de Carrera

62

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION Las operaciones m´ as frecuentes en un directorio LDAP suelen ser de lectura, frente a las operaciones de escritura. Las creaciones de cuenta se suelen llevar a cabo una u ´nica vez en todo el a˜ no (comienzo de curso) y los cambios de contrase˜ na, a´ un siendo m´ as usuales que las operaciones de creaci´ on de cuenta, representan un porcentaje totalmente despreciable frente al n´ umero de lecturas para autenticaci´ on que se realizan. peloto.escet.urjc.es 212.128.4.7 Servidor LDAP Primario

zipi.escet.urjc.es 212.128.4.2 Servidor LDAP Secundario (1)

zape.escet.urjc.es 212.128.4.3 Servidor LDAP Secunario (2)

nano.cct.urjc.es 193.147.73.55 Servidor LDAP Secunario (ETSIT Fuenlabrada)

Figura 4.7: Reparto de carga entre varios servidores LDAP. El resto de m´ aquinas que se disponen para servir el directorio LDAP de forma secundaria son zipi (con direcci´on IP 212.128.4.2) y zape (con direcci´on IP 212.128.4.3), situadas estas dos m´ aquinas en el campus de M´ ostoles. En el campus de Fuenlabrada, disponemos de una sola m´ aquina para la autenticaci´ on, la m´ aquina nano (con direcci´on IP 193.147.73.57). El n´ umero de estaciones en cada campus (160 en M´ ostoles frente a 140 en Fuenlabrada) nos hace en principio disponer de m´ as servidores de autenticaci´ on en M´ ostoles que en Fuenlabrada, aunque se prevee que se instalen m´ as en el futuro en el campus de Fuenlabrada dado que el n´ umero de estaciones en ese campus est´a aumentando considerablemente. La figura 4.7 muestra una imagen representativa de la divisi´ on en m´ aquinas de los servidores que dispondr´ an de servicio de autenticaci´ on LDAP. Cabe recordar en este punto, que las cuentas de usuario son las mismas para ambos campus (M´ ostoles y Fuenlabrada), por lo que si en principio el servidor de LDAP de Fuenlabrada deja de estar disponible por cualquier raz´on, las estaciones de este campus intentar´ an autenticar contra cualquiera de los servidores de autenticaci´ on instalados en el campus de M´ ostoles, sin ning´ un tipo de problema. Configuraci´ on de los clientes para el reparto de carga La configuraci´ on de los clientes para que puedan conectarse a diferentes servidores LDAP en caso de que encuentren un fallo en alguno es realmente simple, y basta con a˜ nadir en los ficheros /etc/ldap/ldap.conf, /etc/libpam ldap.conf, y /etc/libnss-ldap.conf tantas cadenas de conexi´ on como servidores tengamos disponibles. En nuestro caso, vamos a tener disponibles cuatro servidores que ofrezcan servicio de autenticaci´ on v´ıa LDAP, que se identifican por su nombre de host. Por tanto, las cadenas de conexi´ on ser´ıan las siguientes:

A. Guti´errez Mayoral

63

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Listado 4.34: L´ıneas necesarias para proporcionar soporte SSL al servidor LDAP 1 2 3 4

ldaps :// peloto . escet . urjc . es ldaps :// zipi . escet . urjc . es ldaps :// zape . escet . urjc . es ldaps :// nano . cct . urjc . es

Por tanto, bastar´ıa con a˜ nadir a estos ficheros la cadena Listado 4.35: L´ıneas necesarias para proporcionar soporte SSL al servidor LDAP 1 2

ldaps :// peloto . escet . urjc . es ldaps :// zipi . escet . urjc . es ldaps :// zape . escet . urjc . es ldaps :// nano . cct . urjc . es

Los clientes, cuando tuvieran que resolver una petici´on de autenticaci´ on, acudir´ıan al primer servidor en la lista de servidores disponibles, en este caso, a la m´ aquina peloto. Si esta no se encontrara disponible, acudir´ıan al segundo recurso disponible, en este caso, la m´ aquina zipi. As´ı consecutivamente, hasta que lograran encontrar un servidor que no produjera fallo. Evidentemente, esta configuraci´ on no produce ning´ un reparto de carga (tal y como se han escrito las direcciones de los servidores LDAP) puesto que todos los clientes, intentar´ıan siempre conectarse al servidor LDAP de peloto, posteriormente al de zipi, etc´etera. Para que el reparto de carga sea real, es necesario escribir los identificadores de las localizaciones de los servidores en cada cliente en un orden determinado: as´ı conseguiremos realmente que cada laboratorio, por ejemplo, intente autenticar siempre contra un servidor determinado, otro laboratorio contra otro, etc´etera. Para ello, podemos realizar la siguiente configuraci´ on. En M´ ostoles, decidimos que: Las estaciones del laboratorio 108 intenten autenticarse siempre contra la m´ aquina peloto, luego contra zipi, posteriormente contra zape y por u ´ltimo contra nano. Las estaciones del laboratorio 106 intentar´ an autenticarse en primer lugar contra zipi, luego contra zape, a continuaci´ on contra peloto y por u ´ltimo contra nano. Las estaciones del laboratorio 109 intentar´ an autenticarse en primer lugar contra zape, luego contra zipi, posteriormente contra peloto, y por u ´ltimo contra nano. Por u ´ltimo, las estaciones del laboratorio 111 intentar´ an autenticarse en primer lugar contra zipi, luego contra peloto, posteriormente contra zape y por u ´ltimo contra nano. Est´a claro que nos interesa que el u ´ltimo recurso a explorar en caso de que fallen los anteriores, es el servidor LDAP situado en el Campus de Fuenlabrada, debido a que geogr´ aficamente se encuentra m´ as lejos y provoca m´ as latencia en las conexiones y por tanto en el servicio de autenticaci´ on. La configuraci´ on para las estaciones del campus de Fuenlabrada podr´ıa ser muy similar, y en este sentido: Las estaciones del Laboratorio 004 intentar´ an autenticarse primero contra nano, luego contra peloto, a continuaci´ on contra zipi y por u ´ltimo contra zape. Las estaciones del Laboratorio 005 intentar´ an autenticarse primero contra nano, luego contra zipi, posteriormente contra zape y por u ´ltimo contra peloto. Las estaciones del Laboratorio del Seminario 5 intentar´ an autenticarse primero contra nano, luego contra zape, posteriormente contra zipi y por u ´ltimo contra peloto. Est´a claro que en este Campus primero se intente la conexi´ on contra el servidor m´ as cercano, en este caso, la m´ aquina nano. A continuaci´ on, se plantean diversos ´ordenes de conexi´ on a los servidores adicionales, en caso de que falle el principal, para poder repartir adecuadamente la carga entre todos los posibles servidores disponibles. Proyecto Fin de Carrera

64

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION Aspectos avanzados: Replicaci´ on No sirve de nada tener varios servidores disponibles para realizar reparto de carga en la autenticaci´ on si no existe coherencia entre ellos. La decisi´ on de dividir la carga en varios servidores, supone adem´ as, que debemos establecer un mecanismo que permita que cuando se realice un cambio en el servidor primario (el de la m´ aquina peloto) este cambio se vea reflejado autom´aticamente en todos los servidores secundarios. No tendr´ıa ning´ un sentido que existieran varios servidores para la autenticaci´ on pero que los datos no estuvieran exactamente replicados desde el servidor primario hasta los secundarios. Afortunadamente, la aplicaci´on OpenLDAP provee de un mecanismo para que esto sea posible. La utilidad slurpd establece un mecanismo para replicar todos los cambios que se efect´ uen en un servidor LDAP primario. Para ello, y en primer lugar, debemos instalar esta aplicaci´on en todos los servidores LDAP de los que disponemos actualmente. Para ello, hacemos uso de la herramienta de instalaci´ on de software en Debian: Listado 4.36: Instalaci´ on del demonio slurpd con apt-get $ apt - get install slurpd

Debemos instalar esta utilidad en las m´ aquinas peloto, zipi y zape. Una vez realizado este paso, debemos aplicar algunos cambios a la configuraci´ on inicial que tenemos en este momento, que contemple las siguientes acciones: Solamente se podr´an realizar cambios en la m´ aquina peloto, que es la que alberga el servidor LDAP primario. Cuando se intente realizar alg´ un cambio en el directorio LDAP de las m´ aquinas zipi, zape o nano, esta modificaci´ on se redireccionar´ a a la m´ aquina peloto, que es la que atender´a esa petici´on. Un cambio en el directorio LDAP de la m´ aquina peloto produce una reacci´ on en cadena de cambios sobre las m´ aquinas zipi, zape y nano, de forma que su directorio LDAP quede autom´aticamente sincronizado con el de la m´ aquina peloto. Esta configuraci´ on se lleva a cabo siguiendo los siguientes pasos. Cambios necesarios en el servidor LDAP primario En primer lugar, en la m´ aquina peloto es necesario indicar donde est´a el fichero de log de replicaci´ on, para a continuaci´ on indicar cada una de las r´eplicas en las que vamos a propagar los cambios que se efectuen en nuestro directorio LDAP. Para ello, es necesario incluir las siguientes l´ıneas: Listado 4.37: A˜ nadiendo replicaci´ on a nuestro servidor LDAP 1

replogfile

/ var / lib / ldap / replog

2 3 4 5

replica uri = ldaps :// zipi . escet . urjc . es binddn =" cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es " bindmethod = simple credentials = replicator

6 7 8 9

replica uri = ldaps :// zape . escet . urjc . es binddn =" cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es " bindmethod = simple credentials = replicator

10 11 12 13

replica uri = ldaps :// nano . cct . urjc . es binddn =" cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es " bindmethod = simple credentials = replicator

A. Guti´errez Mayoral

65

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Como vemos, por cada servidor LDAP secundario es necesario indicar una directiva replica con los par´ ametros de conexi´ on necesarios. Como se puede apreciar, se especifica la localizaci´on del servidor mediante la directiva uri y el usuario al que se debe atar para propagar el cambio, en este caso, el usuario replicator. Previamente, debemos haber creado este usuario en el servidor LDAP primario. Cambios necesarios en los servidores LDAP secundarios En cada una de las m´ aquinas que albergan un servidor LDAP secundario (esto es, las m´ aquinas zipi, zape y nano, debemos aplicar estos cambios. Estos cambios quedan descritos aplicando estas l´ıneas en cada uno de los ficheros de configuraci´ on del servidor LDAP de la m´ aquina (fichero /etc/ldap/slapd.conf : Listado 4.38: A˜ nadiendo replicaci´ on a nuestro servidor LDAP 13 14

access to * by dn = cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es write by * read

15 16 17

updatedn " cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es " updateref ldaps :// peloto . escet . urjc . es

Como vemos, se especifica que el usuario propietario del nombre distinguido dn=cn=replicator,dc=zipi,dc=escet,dc=urjc,dc=es tendr´ a acceso para escribir. El resto de usuarios, solamente tendr´ an acceso de lectura. Adem´ as, las dos u ´ltimas l´ıneas indican que solamente se pueden realizar actualizaciones de datos mediante el nombre distinguido anterior, y que cualquier otra modificaci´ on por cualquier otro usuario debe devolver un error (indicando que no se puede escribir en el directorio) remitiendo a la direcci´on del servidor LDAP primario que s´ı admite modificaciones de escritura en el directorio. Esta l´ınea es muy interesante, sobre todo con respecto a los clientes. Vimos en el apartado anterior, Reparto de carga, que se especificaban las cadenas de conexi´ on a los diferentes servidores en diferente orden para poder as´ı repartir la carga entre todos los servidores disponibles. Bien, ¿qu´e ocurrir´ıa si un cliente tiene como primer servidor disponible un servidor LDAP secundario, que no admite modificaciones y recibe una petici´on para un cambio de contrase˜ na? Podr´ıa pensarse que se remitir´ıa a un error, debido a que ese servidor LDAP no admite ninguna operaci´on de escritura en su directorio (a no ser que provengan de un servidor LDAP primario). Pues bien, realmente cuando ocurre esta situaci´on, el servidor LDAP secundario devueve la cadena de conexi´ on al servidor LDAP primario, y es ah´ı entonces donde se realiza la modificaci´ on. Evidentemente, si ´este no estuviera disponible, s´ı que se producir´ıa un error y la operaci´on de cambio de contrase˜ na no podr´ıa llevarse a cabo. Llegados a este punto, hemos conseguido completar una compleja configuraci´ on de servidores de autenticaci´ on bastante fiable, con reparto de carga (no saturaremos a un servidor con todas las peticiones de todas las estaciones) y en las que el fallo de una m´ aquina no supone la caida del servicio de autenticaci´ on. Copias de seguridad Un aspecto muy importante de cara a la recuperaci´on del servicio en caso de error, es la continua gesti´ on de copias de seguridad de los datos del directorio. En en el dise˜ no que nos ocupa, en el que manejamos cuatro servidores LDAP diferentes, resulta bastante interesante que realicemos copias de seguridad de nuestros datos en cada uno de ellos, y que esas copias se sincronicen finalmente en otro servidor diferente. Para ello, podemos hacer uso de la utilidad slapcat, la cual ejecutada en cada uno de los servidores LDAP provocar´a que se vuelque en formato texto el directorio LDAP por la salida est´andar. Simplemente redirigi´endolo a un fichero, tendr´ıamos suficiente. Podr´ıamos escribir un script de este estilo, para realizar esta tarea, tal y como se muestra en el script mostrado en el listado 4.39. Proyecto Fin de Carrera

66

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION Listado 4.39: Copia de Seguridad de los datos del servidor LDAP 1

#!/ bin / bash

2 3

DATE = ‘ date + %F ‘

4 5

/ usr / sbin / slapcat | gzip -9 > / var / backups / ldap / ldap - backup_$DATE . gz

Siempre es conveniente que cuando hagamos uso de la herramienta slapcat, se detenga el servicio LDAP para evitar inconsistencias en la base de datos cuando se realiza el volcado. El anterior script se encuentra escrito en bash, y u ´nicamente invoca al comando slapd para guardar su resultado en un fichero comprimido, con la fecha (a˜ no, mes y d´ıa) de la copia de seguridad. Este script, al que denominaremos backup ldap.py, se ejecutar´ a en todas aquellas m´ aquinas que dispongan de un servidor LDAP, de forma diaria. Para ello, podemos incluir la siguiente l´ınea de cron en las m´ aquinas peloto, zipi, zape y nano: Listado 4.40: L´ınea de cron para automatizar las copias de seguridad de LDAP 00 00 * * * / root / bin / backup - ldap . sh

A trav´es de la cual ejecutar´ a todos los d´ıas a las 00:00h la utilidad de copia de seguridad del directorio LDAP. Podemos combinar este script con otras t´ecnicas, como por ejemplo, cada 15 d´ıas guardar los datos en un soporte magn´etico, como cinta, o CD, etc´etera. Sin duda se recomienda cada cierto tiempo volcar todos los datos a un soporte de forma que se encuentren fuera de cada uno de los servidores, por lo que pudiera pasar. Herramientas de Gesti´ on del directorio LDAP Una vez puesto en marcha todo el sistema, es necesario disponer de herramientas adecuadas para poder administrar f´acilmente el directorio LDAP. En nuestro caso, como solamente va a ser usado para autenticaci´ on de usuarios, hemos de disponer de las herramientas necesarias que nos permitan a˜ nadir, eliminar y modificar usuarios existentes en la base de datos. Normalmente, cuando se instala un servidor de directorio LDAP, resulta casi fundamental instalar junto a ´el las herramientas ldap-utils, que proveen de utilidades para gestionar adecuadamente el directorio. En concreto, son herramientas que permiten a˜ nadir (ldapadd), modificar datos del directorio (ldapmodify) y poder borrar (ldapdelete). Sin embargo, usar estas herramientas en l´ınea de comandos directamente, sin usar por encima scripts que se apoyen en estas herramientas, puede resultar un poco tosco. Por eso, aparte de haber desarrollado una aplicaci´on propia para la gesti´ on de los usuarios del sistema, hemos instalado una aplicaci´on web para poder administrar el directorio f´acilmente. No obstante, usaremos utilidades en l´ınea de comandos si nuestro fin es poder realizar un peque˜ no cambio (por ejemplo, cambiar una contrase˜ na) en el sistema de forma r´apida y simple. Vamos a ver cada una de ellas de forma breve. PHPLdapAdmin La aplicaci´on PHPLdapAdmin17 es una aplicaci´on libre y gratuita que permite gestionar a trav´es de un interfaz web un conjunto de servidores LDAP. Adem´ as de eso, obviamente, permite a˜ nadir, borrar y modificar datos del directorio LDAP. Esta herramienta es muy c´omoda desde el punto de vista que permite ver de una pasada r´ apida cual es el estado de los servidores LDAP en un momento determinado, adem´ as de poder ver en forma de ´arbol la estructura del mismo. Adem´ as, permite a˜ nadir usuarios con estructura posixAccount (muy u ´til para cambiar contrase˜ nas) y permite localizar a un usuario r´apidamente. En la imagen 4.8 se puede ver esta 17

http://phpldapadmin.sourceforge.net/

A. Guti´errez Mayoral

67

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION

Figura 4.8: La aplicaci´ on PHPLdapAdmin sobre nuestro esquema de servidores. aplicaci´on funcionando en nuestro entorno de servidores LDAP18 . Esta aplicaci´on la usaremos para localizar r´ apidamente un objeto en el LDAP y poder realizar una modificaci´ on sobre ´el, no obstante, est´a pensada para ser usada solamente sobre los usuarios administradores del entorno, ya que desde el punto de vista de su gesti´ on puede resultar un poco t´ecnica. En principio, se recomienda que los profesores, que muy a menudo se ven obligados a cambiar contrase˜ nas y crear cuentas para sus alumnos, usen la herramienta propia de gesti´ on de usuarios del Laboratorio19 La instalaci´ on de configuraci´ on de PHPLdapAdmin es bastante simple, estando disponible como paquete en la mayor´ıa de las distribuciones m´ as usadas hoy en d´ıa. Posteriormente, despu´es de instalar la herramienta, se debe configurar con los par´ ametros de los servidores a los cuales se desea poder acceder desde la administraci´on web. En este documento no se describir´a la instalaci´ on y posterior configuraci´ on de la herramienta por existir multitud de documentos que se encargan de ello20 . Aplicaciones en l´ınea de comandos Aparte de las herramientas gr´ aficas de gesti´ on del directorio y de los servidores LDAP, siempre viene bien tener disponibles herramientas en l´ınea de comandos para la gesti´ on del directorio de forma eficiente y simple. Estas herramientas, est´an provistas por el paquete ldap-utils, como se ha comentado antes. Normalmente, las herramientas ldapadd y ldapdelete se suelen usar a trav´es de herramientas de nivel superior, ya que tanto los par´ ametros que requieren como los formatos de ficheros que usan para intercambiar datos con el servidor LDAP (formato LDIF) suele ser bastante complejo. En nuestro caso, solamente usaremos la herramienta ldappassword para poder cambiar la contrase˜ na de un usuario en l´ınea de comandos r´apidamente. La sintaxis de este comando es bien sencilla, mostr´andose un ejemplo a continuaci´ on. Supongamos que queremos cambiar la contrase˜ na a un usuario cuyo nombre de usuario es agutierr, sabiendo que su cuenta se encuentra 18

Se puede acceder a la gesti´ on del LDAP desde la URL https://minervo.escet.urjc.es/ldapadmin desde la Intranet de la Universidad. 19 Esta aplicaci´ on se encuentra en la URL https://pantuflo.escet.urjc.es/admin 20 En la p´ agina web del proyecto (http://phpldapadmin.wiki.sourceforge.net/Documentation) se puede encontrar abundante informaci´ on sobre la instalaci´ on y personalizaci´ on de la herramienta.

Proyecto Fin de Carrera

68

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION situada en el sub´arbol de profesores del directorio LDAP. Sencillamente, escribir´ıamos lo siguiente: Listado 4.41: Modificando la contrase˜ na de un usuario usando ldappasswd $ ldappasswd -x -H ldaps :// peloto . escet . urjc . es -D ’ cn = admin , dc = zipi , dc = escet , dc = urjc , dc = es ’ -W ’ uid = agutierr , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es ’

Como se puede apreciar en el anterior fragmento de c´odigo, la sintaxis de los comandos de LDAP no es simple, precisamente. Por eso siempre se recomienda el uso de scripts personalizados que recubran estas herramientas, para reducir al m´ınimo la complejidad de estos comandos.

4.2.2.

Servidor NFS de ficheros en red

En este punto, podemos decir que uno de los hitos fundamentales que quer´ıamos conseguir en nuestro sistema, ya lo hemos logrado: dar el salto a una tecnolog´ıa punta como es hoy en d´ıa LDAP, aumentar la seguridad de la autenticaci´ on de los usuarios en el sistema, como ha quedado demostrado, adem´ as de dotar al entorno de una fiabilidad y rendimiento ´optimos. A continuaci´ on, se nos presenta como reto dotar al sistema de un servicio de ficheros en red capaz de soportar toda la carga del entorno, adem´ as de disponga de espacio suficiente para poder almacenar de forma amplia un n´ umero aproximado de tres mil cuentas de usuario, con sus correspondientes carpetas personales. La opci´ on u ´nica clara que se presenta es el uso del sistema de ficheros NFS21 , un sistema de ficheros en entornos Unix que permite acceder a ficheros y diretorios remotos como si fueran ficheros locales. En Unix/Linux esto es posible gracias a una mezcla de funcionalidad en el mismo kernel de Linux en la m´ aquina cliente y un demonio en el servidor, mezclado todo con llamadas 22 RPC entre el cliente y el servidor (NIS tambi´en funciona con RPC). El servidor de NFS, exporta un conjunto de directorios (uno o m´ as) de forma remota a todos aquellos clientes que deseen montar ese directorio. Por otro lado, los clientes montan ese directorio v´ıa NFS en su sistema de ficheros local. La sintaxis para montar un directorio v´ıa NFS no es muy diferente a la que que se usa para montar directorios locales, m´ as que a˜ nadiendo la m´ aquina que alberga el servidor NFS y el directorio que se desea montar. Como vimos en el cap´ıtulo de dise˜ no, la m´ aquina que albergar´ a el servidor NFS para el Campus de M´ ostoles, ser´a la m´ aquina lechuzo (con direcci´on IP 212.128.4.8), y exportar´ a el directorio /disks/raid/homes.mostoles de cara a los clientes, las estaciones del Laboratorio. As´ı, para poder montar remotamente los directorios personales de los alumnos en una estaci´on cliente, tendr´ıamos que introducir: $ mount -t nfs lechuzo . escet . urjc . es :/ disks / raid / homes . mostoles / home

De forma que en el directorio /home de los clientes, quedar´ıa montado el directorio remoto /disks/raid/homes.mostoles/ del servidor. El uso de este directorio, ser´ıa totalmente transparente para los usuarios de las estaciones, que lo usar´ıan como si de un directorio local se tratara. Evidentemente, la tarea de montar el servidor de homes est´a automatizada en el arranque de las estaciones del laboratorio. Esto se consigue a˜ nadiendo una l´ınea al fichero /etc/fstab que contiene los montajes remotos que se desea iniciar en el inicio del sistema: lechuzo . escet . urjc . es :/ disks / raid / homes . mostoles / , rsize =8192 , wsize =8192 , udp

/ home

nfs

rw

Esta l´ınea contiene algo m´ as de informaci´ on que la anterior. Las opciones m´ as interesantes son las opciones rw, y la opci´ on udp, que monta el directorio del servidor usando el protocolo de 21 22

NFS son las siglas de Network File System o Sistema de Ficheros en Red. RPC son las siglas de Remote Procedure Call o Llamada a Procedimiento Remoto.

A. Guti´errez Mayoral

69

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION transporte udp. Resulta razonable en una red local como la que nos ocupa usar este protocolo, ya que suponemos que se producen pocas p´erdidas y los tiempos de respuesta son en su mayor´ıa bajos. Por otro lado, en el servidor, deber´ıamos tener disponible el demonio de NFS, provisto por el paquete nfs-kernel-server: Listado 4.42: Instalaci´ on del servidor NFS a trav´es de apt-get $ apt - get install nfs - kernel - server

Configuraci´ on del servidor La configuraci´ on del servidor de NFS u ´nicamente contempla el seleccionar el directorio que se desea exportar de cara a los clientes. Esta configuraci´ on se lleva a cabo en el fichero /etc/exports. Para cada directorio exportado, se debe seleccionar el rango de direcciones IP a los que se les permite usar o montar ese recurso. En este momento, NFS no dispone de ning´ un mecanismo de autenticaci´ on que no sea permitir o denegar el montaje del recurso ateniendo a la direcci´on IP del cliente. Vemos un fragmento del fichero de configuraci´ on a continuaci´ on: / disks / raid / homes . mostoles \ 212.128.4.0/24( rw , sync , no_root_squash , no_subtree_ch eck ) \ 193.147.56.0/24( rw , sync , no_root_squash , no_subtree_c heck )

En efecto, esto supone muchos problemas de seguridad de cara a los clientes a los que permitimos montar el recurso, y en los que confiamos. En principio, cualquier persona que usara una direcci´on IP del laboratorio (con su ordenador port´ atil, por ejemplo) ser´ıa capaz de montar el recurso NFS sin mayor dificultad. Las operaciones que pueda realizar en ese momento con ese directorio dependen u ´nicamente de las opciones que se hayan marcado en el directorio exportado en el servidor: Si el recurso se ha exportado con la opcion no root squash, las operaciones a nombre del usuario root en la m´ aquina local se traducir´an como operaciones con el usuario root en la m´ aquina servidor. Por el contrario, si se ha exportado el directorio con la opci´ on root squash, las operaciones a nombre del usuario root en la m´ aquina local se traducir´an como operaciones a nombre del usuario nobody en la m´ aquina remota, y por tanto, este usuario solamente tendr´ a privilegios sobre aquellos ficheros que tenga a su nombre. A´ un as´ı, estando el recurso exportado con la opci´ on root squash, un usuario root local no tendr´ıa privilegios sobre nada que no est´e a su nombre, pero nada impide que intercambiando su id de usuario acceda a todos los ficheros para los que no tenga privilegios. Vemos por tanto, que las opciones son bastante poco esperanzadoras, en cuanto a seguridad se refiere. Adem´ as de no poder autenticar a los clientes, excepto confiar en ellos a trav´es de su direcci´on IP, es posible acceder en modo lectura y escritura con privilegios desde cualquier cliente y modificar los ficheros de cualquier usuario al antojo del atacante, sin m´ as que escribir unos cuantos comandos de shell. Como se puede deducir, NFS hoy en d´ıa adolece de graves problemas de seguridad que de momento, y debido a la estructura del kernel de Linux, no est´ a a la vista ser corregidos, pero hoy en d´ıa representa la u ´nica opci´ on medianamente usable en cuanto a rendimiento y fiabilidad. RAID de disco En un sistema en el que se tienen aproximadamente tres mil cuentas de usuario, resulta imprescindible disponer de una tecnolog´ıa que permita aunar gran cantidad de espacio en disco Proyecto Fin de Carrera

70

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION como si se tratara de un solo dispositivo. Como vimos en el cap´ıtulo de dise˜ no, vamos a hacer uso de la m´ aquinas lechuzo y sapientin en el Campus de M´ ostoles para albergar por un lado los directorios personales de los usuarios (directorios HOMES) y por otro lado, una copia de seguridad exacta de estos directorios, para que en caso de fallo de alg´ un disco de la primera, se pueda sustituir ´esta r´ apidamente (sin m´ as que cambiar su direcci´on IP) y no dejar sin servicio a los laboratorios. Discos disponibles En principio, la configuraci´ on de hardware de las m´ aquinas lechuzo y sapientin no tienen porqu´e ser similares, siendo recomendable u ´nicamente que la segunda tenga al menos el mismo tama˜ no de espacio en disco que la primera. Incluso, la configuraci´ on del RAID puede variar, no teniendo porqu´e estar configuradas en el mismo nivel. En la m´ aquina lechuzo, disponemos de cinco discos duros disponibles, de diferentes tama˜ nos, tal y como muestra la tabla 4.1. El espacio total sumado entre todos los discos alcanza los 830 GB, aproximadamente. Disco duro /dev/hdb /dev/hde /dev/hdi /dev/hdm

Tama˜ no 400 GB 163 GB 163 GB 163 GB

Partici´on principal /dev/hdb1 /dev/hde1 /dev/hdi1 /dev/hdm1

Cuadro 4.1: Discos duros de la m´ aquina lechuzo

An´ alogamente, en la m´ aquina sapientin, destinada a albergar las copias de seguridad de los directorios personales de los usuarios, disponemos de seis discos duros (sin contar el dedicado a la partici´on del sistema) de 120 GB de tama˜ no cada uno. El tama˜ no total es aproximadamente de 500 GB, para copias de seguridad. Configuraci´ on del raid en Linux Dispuestos los discos duros que van a ser dedicados en cada m´aquina a albergar los directorios personales de los usuarios (m´ aquina principal y copias de seguridad) debemos configurar un raid por software bajo Linux, para poder acceder a todos los discos como si de u ´nico dispositivo se tratara. Las herramientas adecuadas que disponen de esta funcionalidad bajo Linux vienen provistas por el paquete mdadm, cuya instalaci´ on se puede completar usando el gestor de paquetes de Debian (recordamos que en el cap´ıtulo de Dise˜ no establecimos que la distribuci´on a usar en los servidores, iba a ser Debian GNU/Linux): Listado 4.43: Instalaci´ on del gestor de raid mdadm usando apt-get $ apt - get install mdadm

La herramienta mdadm es una utilidad para Linux que permite administrar (a˜ nadir, borrar y modificar) raids de disco que funcionen por software (en ausencia de una controladora hardware dedicada). El nombre de la aplicaci´on mdadm viene de multiple disks. La herramienta mdadm se distribuye bajo la licencia GNU/GPL. Lo primero que debemos hacer para configurar el RAID de disco, es formatear los discos usando el sistema de ficheros ext3. Si previamente, los discos no ten´ıan ninguna partici´on creada, debemos crearla haciendo uso de las herramientas fdisk o cfdisk. Una vez que hemos creado las particiones correspondientes, podemos formatearlas usando el sistema de ficheros ext3 invocando el programa mkfs.ext3: A. Guti´errez Mayoral

71

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Listado 4.44: Automatizaci´ on en la creaci´ on del raid $ for i in ‘ echo b e i m ‘; do mfks . ext3 / dev / hd$i1 ; done

De esta forma, formateamos las cuatro particiones en lechuzo de forma totalmente autom´atica. Lo mismo podemos hacer en la m´ aquina sapientin: Listado 4.45: Automatizaci´ on en la creaci´ on del RAID $ for i in ‘ echo e g i k m ‘; do mkfs . ext3 / dev / hd$i1 ; done

Concluida esta operaci´on, podemos crear el RAID de disco deseado. Niveles de RAID usados Un dispositivo RAID puede ser configurado en diferentes niveles, dependiendo de la configuraci´ on m´ as ´ optima para el entorno. Para ilustrar diferentes configuraciones de RAID, vamos a usar el nivel cero (tambi´en llamada configuraci´ on en tiras) en la m´ aquina lechuzo y la configuraci´ on de nivel cinco (disco en redundancia o disco spare) en la m´ aquina sapientin. Desde el punto de vista del espacio en disco, la configuraci´ on m´ as ´optima es la configuraci´ on en tiras, que aprovecha al m´ aximo el uso de cada disco: el tama˜ no total del RAID es la resultante de multiplicar el espacio disponible en cada uno de los discos por el n´ umero de discos. Sin embargo, si se produce un error en uno de los discos, el RAID quedar´ a totalmente inutilizable, y ser´a preciso hacer uso de la copia de seguridad. La configuraci´ on en nivel cinco, o con redundancia, hace uso de un disco para almacenar redundancias entre la informaci´ on, de forma que si se produce un error en alguno de los discos, nos podremos recuperar de la informaci´ on en caliente, sin m´ as que cambiar el disco defectuoso. Como en principio, disponemos de dos m´ aquinas, vamos a hacer uso de ambas configuraciones para poder disponer de cada las dos ventajas por el mismo precio. Para la creaci´ on del RAID hacemos uso de la herramienta mdadm de la siguiente forma: $ mdadm -- create / dev / md0 -- level - raid 0 -- raid - devices 4 / dev / hd [ beim ]1

En la m´ aquina lechuzo. El dispositivo final /dev/md0 en esta m´ aquina albergar´a el raid de disco que podr´a ser considerado como si de un solo disco se tratara. En el comando expuesto, se indica que se desea aplicar un nivel de raid cero, con cuatro discos, indicando por supuesto que discos se desea a˜ nadir al raid. De la misma forma, en la m´ aquina sapientin, $ mdadm -- create / dev / md0 -- level - raid 5 -- raid - devices 5 / dev / hd [ egikm ]1 -- spare - devices / dev / hdo1

En este caso, se desea aplicar una configuraci´ on de RAID con redundancia, y por tanto es necesario indicar mediante el par´ ametro –spare-devices que disco se desea usar para almacenar esta redundancia. Despu´es de aplicar estas operaciones, debemos tener en ambas m´ aquinas y bajo el directorio /dev/md0 los respectivos dispositivos raid. Usando la propia herramienta de diagn´ostico del paquete podemos comprobar el estado de cada uno de los raids: lechuzo :~# mdadm -D / dev / md0 / dev / md0 : Version : 00.90.03 Creation Time : Sun Jun 24 21:24:00 2007 Raid Level : raid0 Array Size : 870947392 (830.60 GiB 891.85 GB ) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent

Proyecto Fin de Carrera

72

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION Update Time State Active Devices Working Devices Failed Devices Spare Devices

: : : : : :

Sun Jun 24 21:24:00 2007 clean 4 4 0 0

Chunk Size : 64 K UUID : 4838047 a :31901 cef :88217 ab2 :99168 cf3 Events : 0.1 Number 0 1 2 3

Major 3 33 56 88

Minor 65 1 1 1

RaidDevice 0 1 2 3

State active active active active

sync sync sync sync

/ dev / hdb1 / dev / hde1 / dev / hdi1 / dev / hdm1

Que nos indica que el estado es correcto (clean), que existen cuatro dispositivos activos y funcionando, el tama˜ no total del dispositivo raid, adem´ as de las fechas de creaci´ on, actualizaci´on y de los dispositivos f´ısicos de los que se compone el raid. De la misma forma en la m´ aquina sapientin, podemos observar la misma informaci´ on: sapientin :~# mdadm -D / dev / md0 / dev / md0 : Version : 00.90.03 Creation Time : Mon May 22 10:14:23 2006 Raid Level : raid5 Array Size : 468872704 (447.15 GiB 480.13 GB ) Device Size : 117218176 (111.79 GiB 120.03 GB ) Raid Devices : 5 Total Devices : 6 Preferred Minor : 0 Persistence : Superblock is persistent Update Time State Active Devices Working Devices Failed Devices Spare Devices

: : : : : :

Mon Feb 25 07:52:35 2008 clean 5 6 0 1

Layout : left - symmetric Chunk Size : 64 K UUID : c8a8661f :758 a1942 :83 ba8395 : dd3064ca Events : 0.7129708 Number 0 1 2 3 4 5

Major 33 34 56 57 88 89

Minor 1 1 1 1 1 0

RaidDevice 0 1 2 3 4 -

State active active active active active spare

sync sync sync sync sync

/ dev / hde1 / dev / hdg1 / dev / hdi1 / dev / hdk1 / dev / hdm1

/ dev / hdo

Ahora podemos tratar todos estos discos como si de un u ´nico se tratara, por lo que (aunque no es obligatorio) se recomienda formatear esta nueva partici´on en el formato de ficheros elegido, en nuestro caso, el sistema de ficheros ext3: $ mkfs . ext3 / dev / md0

Ejecutado en ambas m´ aquinas, formatear´ a los dispositivos para que puedan ser montados a ´ partir de ese momento en el sistema. Unicamente nos queda montar los directorios bajo el punto A. Guti´errez Mayoral

73

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION de montaje elegido: /disks/raid/homes.mostoles/: $ mount / dev / md0 / disks / raid / homes . mostoles /

Y por u ´ltimo, reiniciar el demonio NFS en ambas m´ aquinas para que los recursos est´en disponibles a todas las estaciones del Laboratorio: $ / etc / init . d / nfs - kernel - server restart

Configuraci´ on del RAID en los servidores del Campus de Fuenlabrada La configuraci´ on del RAID para los servidores del Campus de Fuenlabrada (bilo y nano) es muy similar a la creaci´ on del RAID para los servidores de disco del Campus de M´ ostoles. En concreto, usaremos nivel de raid cero (configuraci´on en tiras) en ambas m´ aquinas. Como vimos en el cap´ıtulo de dise˜ no, la m´ aquina bilo albergar´ a el RAID que contendr´ a los ficheros personales de los usuarios de ese campus (como servidor principal) y la m´ aqina nano albergar´a las copias de seguridad de dichos ficheros.

4.2.3.

Servidor Web de los Laboratorios

Como vimos en el cap´ıtulo de Dise˜ no, en los Laboratorios (tanto de los Campus de M´ ostoles como de Fuenlabrada) instalaremos un servidor web en una de las m´ aquinas, que cubrir´a dos funcionalidades principalmente: Instalar una p´agina principal que sirva para informar a los alumnos de las instalaciones, los procedimientos principales (apertura de cuenta, cambio de contrase˜ na, etc´etera), una serie de tutoriales (conectar al laboratorio desde casa, configurar el correo electr´onico, etc´etera). Que los propios alumnos puedan configurar una peque˜ na p´agina personal, con la informaci´ on acad´emica que deseen (normalmente los alumnos usan este medio para proporcionar informaci´ on sobre su persona y sus intereses profesionales). Para poder implementar este servicio, instalaremos un servidor web en uno de los servidores visibles de cada uno de los Campus. En el campus de M´ ostoles, cuando los Laboratorios comenzaron a funcionar, siempre se us´ o la m´ aquina pantuflo para esta tarea. Como vimos en el cap´ıtulo de Especificaci´ on y Dise˜ no, la m´ aquina pantuflo implementa la tarea de ser la cabeza visible de los Laboratorios. Proporciona, adem´ as de servidor web, servidor de correo electr´onico para los usuarios, listas de correo, etc´etera. Por tanto, usaremos la direcci´on pantuflo.escet.urjc.es para instalar la p´agina web del Laboratorio. Para las p´aginas personales de los usuarios, usaremos la notaci´ on tradicional de p´aginas web en un entorno Unix/Linux, es decir, el nombre del host, seguido del car´acter y el nombre del usuario. As´ı, si mi nombre de usuario es agutierr, la URL que har´ıa referencia a mi espacio web en el servidor ser´ıa http://pantuflo.escet.urjc.es/˜ agutierr/. De la misma forma, en el Campus de Fuenlabrada tambi´en dispondremos de un servidor web que servir´a de p´agina principal del Laboratorio. La m´ aquina encargada de albergar este servidor (y por tanto la p´agina del Laboratorio en Fuenlabrada) ser´a la m´ aquina bilo, siendo la URL principal del Laboratorio la direcci´on http://bilo.cct.urjc.es/. A continuaci´ on vamos a ver c´omo configurar r´apidamente un gestor de contenidos para el Laboratorio, que permita editar, a˜ nadir y borrar contenido de forma f´acil e intuitiva (incluso, que permita a los docentes hacerlo) y c´omo configurar el servidor web para que permita a los usuarios gestionar sus p´aginas personales. Proyecto Fin de Carrera

74

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION P´ agina principal del Laboratorio Desde el punto de vista informativo y corporativo, siempre resulta interesante como organizaci´ on disponer de una p´agina web de informaci´ on, de cara al resto del mundo, que los alumnos o los visitantes puedan utilizar para saber cual es el r´egimen de funcionamiento interno del Laboratorio, as´ı como otra informaci´ on muy interesante de cara a los usuarios finales del entorno. Es por ello que una de nuestras tareas ser´a instalar un servidor web que nos permita configurar un gestor de contenidos para el Laboratorio. Un servidor web es un programa que implementa el protocolo HTTP23 . Este protocolo est´a dise˜ nado para transferir lo que llamamos p´aginas web o p´aginas en formato HTML24 . Sin embargo, es importante rese˜ nar que HTTP hace referencia al protocolo que permite el visionado de documentos escritos en HTML. Un servidor web, se encarga de mantenerse a la espera de peticiones HTTP que les llegan desde los clientes (normalmente, un navegador, como Firefox, Opera, Safari, etc´etera). El navegador, realiza una petici´on al servidor y ´este le responde con el contenido que ´este solicita. Existen multitud de programas que implementan un servidor web, siendo uno de los m´ as conocidos en entornos Unix/Linux el servidor web Apache. Versiones de Apache Hoy en d´ıa, existen dos versiones principales de Apache: la versi´ on 1.3 y la versi´ on 2. En el entorno en el que nos encontramos, instalaremos ambas. Ambas siguen en desarrollo, y las principales ventajas de la versi´ on 2 sobre la versi´ on 1 radica en una mejora en las implementaciones que mejoran sustancialmente el rendimiento (en plataformas no Unix sobre todo), centr´andose en la modularizaci´on del servidor. En nuestro entorno, usaremos las dos, principalmente por dos razones: Existen m´ odulos que s´ olo est´an disponibles para la versi´ on 1 (como es el caso del m´ odulo de PHP5) Existen m´ odulos que s´ olo est´an disponibles para la versi´ on 2 (como es el caso del m´ odulo de Webdav y Subversion) Instalaci´ on La instalaci´ on en Debian GNU/Linux de Apache (tanto en la versi´ on 1 como en la versi´ on 2) es realmente sencilla e intuitiva. En primer lugar instalaremos Apache 1 con los m´ odulos necesarios, en este caso, el m´ odulo de PHP5. Listado 4.46: Instalaci´ on de Apache y del m´ odulo PHP5 para el servidor $ apt - get install apache libapache - mod - php5

Despu´es de responder a unas preguntas relativas a la configuraci´ on del paquete, lo m´ as probable es que el software se haya instalado correctamente, y ya podamos acudir a la direcci´on principal para poder ver una p´agina de prueba. Por tanto, en la direcci´on http://pantuflo.escet.urjc.es/ (y respectivamente, a la del Campus de Fuenlabrada) podemos ver la p´agina de prueba que nos deja Apache nada m´ as ser instalado. A continuaci´ on, vamos a instalar el servidor web Apache en su versi´ on 2, junto con el m´ odulo de Webdav/Subversion. Este m´ odulo nos permitir´a acceder a repositorios Subversion dentro del servidor pantuflo, en ocasiones usado por alumnos para versionar el c´odigo fuente de sus pr´acticas. 23 24

HTTP son las siglas de Hypertext Transfer Protocol. HTML son las siglas de Hypertext Markup Language, o lenguaje de marcado de hipertexto.

A. Guti´errez Mayoral

75

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Listado 4.47: Instalaci´ on del servidor Apache2 y del m´ odulo WebDav/Subversion para el servidor $ apt - get install apache2 libapache2 - svn

El gestor de paquetes de Debian resolver´a las dependencias que considere oportunas, y terminar´ a de instalar el software. Es importante destacar que obviamente, no es posible tener los dos servidores escuchando peticiones en los dos puertos, por lo que la decisi´ on adoptada ser´a establecer el puerto 80 (el est´andar de HTTP) para el servidor Apache en la versi´ on 1 y el puerto 8080 para el servidor Apache en la versi´ on 2. Para llevar a cabo esta configuraci´ on, editamos el fichero /etc/apache2/ports.conf : Listen 8080

Es muy probable que si hemos instalado Apache 2 posteriormente a Apache 1 (como es el caso) ´este quede desactivado. Si esto fuera as´ı, no tenemos m´ as que editar el fichero /etc/default/apache2 y escribir: NO_START =0

De esta forma, el servidor web Apache 2 arrancar´ a normalmente en el arranque o bajo petici´on del demonio correspondiente. Configuraci´ on de los Hosts virtuales Los hosts virtuales son una caracter´ıstica del servidor web por la cual le permite resolver peticiones que van dirigidas hacia diferentes hosts. Esto permite que un mismo servidor web pueda resolver peticiones que en principio, pertenecen a diferentes URLs o localizaciones. En nuestro caso, disponemos de un nombre abreviado o alias que hace referencia al servidor pantuflo.escet.urjc.es. Este nombre es pantuflo.es, que nos sirve para no tener que escribir el nombre completo (a los alumnos les es m´ as f´acil recordar este nombre) y para disponer de un mapa propio de nombres que puede ser administrado por el Departamento y por los administradores del Laboratorio. Veremos m´ as adelante en la secci´ on de Configuraci´ on del servicio de resoluci´ on de nombres como configurar una zona concreta con un software de resoluci´ on de nombres. En este punto, lo u ´nico que nos debe preocupar es que nuestro servidor web sea capaz de atender las peticiones dirigidas tanto a la direcci´on pantuflo.escet.urjc.es como a la direcci´on pantuflo.es (y que por supuesto, devuelva el mismo contenido). La configuraci´ on de los hosts virtuales se lleva a cabo en el fichero de configuraci´ on de Apache, el fichero /etc/apache/httpd.conf. En la u ´ltima secci´ on del fichero, podemos encontrar el ´area de declaraci´ on de hosts virtuales. Como en nuestro caso solamente tenemos dos hosts, vamos a declarar uno (el host pantuflo.escet.urjc.es) y el otro lo vamos a configurar como alias. Esto nos permitir´a no tener que repetir la misma informaci´ on para el host pantuflo.es. La configuraci´ on, por tanto, quedar´ıa como sigue: Listado 4.48: Creaci´on de un host virtual en Apache para el host pantuflo.escet.urjc.es 2 4 6 8 10

< VirtualHost 212.128.4.4 > ServerName pantuflo . escet . urjc . es ServerAlias pantuflo . es ServerAdmin agutierr@gsyc . escet . urjc . es DocumentRoot / var / www / wikipantuflo / Alias / parte . html / var / www / parte . html Alias / imagenes_parte / var / www / imagenes_parte Alias / calendario / var / www / icalendar / Alias / tablas . css / var / www / tablas . css Alias / admin / var / www / admin / Alias / cuentas / var / www / cuentas

Proyecto Fin de Carrera

76

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION

12 14

Alias / pipermail / var / lib / mailman / archives / public Options + Indexes

Se puede observar en el fragmento del fichero de configuraci´ on anterior como se define el host pantuflo.escet.urjc.es, una direcci´on de correo para el administrador del mismo, y la etiqueta DocumentRoot que indica a partir de qu´e localizaci´on en el disco f´ısico se han de servir las p´aginas web referenciadas por las peticiones entrantes al servidor. Tambi´en podemos ver como con ayuda de la directiva ServerAlias, definimos que el host pantuflo.es es exactamente lo mismo que el host pantuflo.escet.urjc.es. En la siguiente secci´ on veremos c´omo retocar esta secci´ on del fichero de configuraci´ on de Apache para que sea capaz de servir las p´aginas personales de los usuarios bajo los hosts virtuales pantuflo.escet.urjc.es y pantuflo.es. Gestor de contenidos MediaWiki Una vez hemos instalado un servidor web en cada una de las m´ aquinas visibles de los Laboratorios (las m´ aquinas pantuflo y bilo vamos a proceder a la instalaci´ on de un gestor de contenidos que nos permita a˜ nadir contenido a las p´aginas de cada uno de los laboratorios, de forma que sea f´acil, r´ apido y que los alumnos y docentes puedan modificar los contenidos. La conjunci´ on de cada una de estas palabras responde a un u ´nico t´ermino: un wiki. Un wiki (o una wiki ) (del hawaiano wiki wiki, ((r´ apido))) es un sitio web colaborativo que puede ser editado por varios usuarios. Los usuarios de una wiki pueden as´ı crear, modificar, borrar el contenido de una p´agina web, de forma interactiva, f´acil y r´apida; dichas facilidades hacen de la wiki una herramienta efectiva para la escritura colaborativa. Existen multitud de programas que implementan esta funcionalidad. El escogido para ser usado en nuestro entorno ser´a la aplicaci´on MediaWiki25 . Actualmente, uno de los wikis m´ as grandes que existen, es el proyecto Wikipedia, en cada uno de los lenguajes que dispone. Este proyecto, utiliza como gestor de contenidos el software Mediawiki, unwiki con una apariencia muy personalizable (permite gestionar diferentes estilos), con una sintaxis muy amplia (el lenguaje de marcado que usa es bastante amplio) y que adem´ as, permite diferentes mecanismos de autenticaci´ on de usuarios, entre ellos, autenticaci´ on frente a un directorio LDAP. Es por esta raz´on que nos decantamos en favor de esta aplicaci´on, puesto que la integraci´on con el sistema de autenticaci´ on es cien por cien: cualquier usuario con cuenta en los laboratorios (ya sea docente o alumno) podr´a a˜ nadir o editar contenidos a la p´agina del Laboratorio. Por supuesto, existir´ an p´aginas para las que no se dispongan permisos de edici´on (o solamente un docente pueda hacerlo). En general, no nos preocupa mucho que un alumno pueda borrar el contenido de una p´agina: aparte de que su nombre quedar´ıa registrado, la propia estructura de un wiki hace que la recuperaci´on sea inmediata. Instalaci´ on de MediaWiki La instalaci´ on del software MediaWiki desde las fuentes es realmente sencilla. Para empezar, debemos descargar la u ´ltima versi´ on26 del software, disponible en la p´agina web del Proyecto. Una vez descargada y descomprimida, pasamos a leer el fichero INSTALL, en el que normalmente se incluyen las instrucciones de instalaci´ on. Listado 4.49: Descarga e Instalaci´ on de la herramienta MediaWiki $ $ $ $ $ $

wget http :// download . wikimedia . org / mediawiki /1.11/ mediawiki -1.11.1. tar . gz 1 > / dev / null cd / var / www / mkdir mediawiki cd mediawiki mv / root / mediawiki -1.11.1. tar . gz . tar xvfz mediawiki -1.11.1. tar . gz 25 26

http://www.mediawiki.org En el momento de escribir el presente documento, la u ´ltima versi´ on estable es la 1.1 .

A. Guti´errez Mayoral

77

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Una vez descomprimido el software, debemos acudir a la direcci´on /config para terminar la configuraci´ on del mismo. En esta direcci´on se muestra un formulario para completar los ajustes relativos a la base de datos donde se alojar´ an las p´aginas de la citada aplicaci´on, usuarios y dem´as. Es necesario en este punto disponer de un servidor de bases de datos funcionando (no tiene porqu´e ser en la misma m´ aquina donde se instala la aplicaci´on). Suponemos que de ser as´ı, simplemente introducir´ıamos los par´ ametros de conexi´ on oportunos (nombre de host donde se encuentra el servidor de base de datos, usuario y contrase˜ na para la conexi´ on, nombre de la base de datos que albergar´ a el wiki, etc´etera). Si todo ha ido bien, el script terminar´ a de ejecutar sus acciones instalando en el servidor de base de datos las tablas necesarias para que la aplicaci´ on pueda funcionar correctamente. Una vez que hemos completado esta acci´on, nuestro wiki queda correctamente instalado, y preparado para ser personalizado. Tras unas tareas de edici´on en el wiki, tenemos una p´agina totalmente funcional donde poder informar a los usuarios del Laboratorio de diferentes aspectos, tal y como muestra la imagen 4.9:

Figura 4.9: P´ agina principal del Laboratorio de M´ ostoles

En la secci´ on Noticias, se mostrar´an las noticias relacionadas con el servidor (informaci´on de incidencias, cambios de horario, avisos para los usuarios, etc´etera). Estos avisos normalmente tambi´en se mandar´an por correo electr´onico mediante la lista de usuarios del Laboratorio, cuya configuraci´ on veremos m´ as tarde. En la secci´ on Instalaciones se muestran las instalaciones (descripci´on del hardware y fotos) de las que disponemos en los Laboratorios. Tambi´en puede resultar de utilidad a futuros alumnos o a visitantes ajenos a la Universidad. En la secci´ on Tutoriales se muestran diversas gu´ıas de configuraci´ on de los servicios m´ as usados en los Laboratorios: c´omo configurar el correo de la cuenta, acceder a ´el mediante el webmail, conectarse a las terminales desde casa, abrir una sesi´ on gr´ afica desde casa, etc´etera. Esta secci´ on sin duda resulta de mucha ayuda a los alumnos que acuden a los Laboratorios a realizar sus pr´acticas, y sin duda es una de las m´ as visitadas. Proyecto Fin de Carrera

78

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION En la secci´ on FAQs se encuentra una selecci´ on de las preguntas m´ as frecuentes, relacionadas sobre todo con el Sistema Operativo Linux. Etc´etera. Autenticaci´ on en MediaWiki en un directorio LDAP Como se coment´o anteriormente, una de las principales ventajas de la aplicaci´on MediaWiki es la integraci´on de autenticaci´ on a trav´es de un directorio de usuarios LDAP. Esto nos va a permitir que los usuarios (tanto alumnos como profesores) se puedan autenticar de cara al wiki y puedan editar los contenidos (a˜ nadir, modificar o borrar). Para poder llevar a cabo esta integraci´on, debemos descargar una extensi´ on de la aplicaci´ on. Una extensi´ on es un aditivo que permite a˜ nadir funcionalidad a la aplicaci´on base. En este caso, esta extensi´ on nos va a permitir autenticar usuarios contra el directorio LDAP del Laboratorio. nade esta funcionalidad. El mecanismo de La extensi´ on LDAP Authentication27 a˜ instalaci´ on y configuraci´ on es realmente simple: en primer lugar, debemos descargar la extensi´ on en el directorio de extensiones de la aplicaci´on: $ cd / var / www / mediawiki / extensions / $ wget http :// svn . wikimedia . org / viewvc / mediawiki / trun k / extensions / LdapAuthentication / LdapAuthentication . php ? revision =20128 1 > / dev / null /

Una vez hemos descargado la extensi´ on, lo u ´nico que tendremos que hacer es configurarla. Para ello, editamos el fichero principal de configuraci´ on de la aplicaci´on, el fichero /var/www/mediawiki/LocalSettings.php. Tal y como detalla la documentaci´ on de la extensi´ on, escribimos la configuraci´ on de autenticaci´ on LDAP para el entorno en el que nos encontramos: Listado 4.50: Configuraci´on de MediaWiki para autenticar usuarios usando LDAP 2 4 6 8 10

require_once ( ’ extensions / LdapAuthentication . php ’ ) ; $wgAuth = new L d a p A u t h e n t i c a t i o n P l u g i n () ; $wgLDAPDomainNames = array ( " alumnos " , " profes " ); $wgLDAPServerNames = array ( " alumnos "= > " peloto . escet . urjc . es " , " profes " = > " peloto . escet . urjc . es " );

12

$wgLDAPUseLocal = true ; 14 16 18 20 22

$ w g L D A P E n c r y p t i o n T y p e = array ( " alumnos "= >" ssl " , " profes " = > " ssl " ); $ w g L D A P S e a r c h A t t r i b u t e s = array ( " alumnos "= >" uid " , " profes "= >" uid " );

24 26 28

$wgLDAPBaseDNs = array ( " alumnos "= >" ou = usuarios , ou = escet , ou = alumnos , dc = zipi , dc = escet , dc = urjc , dc = es " , " profes "= >" ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " );

27

Disponible en http://www.mediawiki.org/wiki/Extension:LDAP Authentication

A. Guti´errez Mayoral

79

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION

30 32

$wgLDAPGroupBaseDNs = array ( " alumnos "= >" ou = grupos , ou = escet , ou = alumnos , dc = zipi , dc = escet , dc = urjc , dc = es " , " profes "= >" ou = grupos , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " );

34 36 38 40 42

$wgLDAPUserBaseDNs = array ( " alumnos "= >" ou = usuarios , ou = escet , ou = alumnos , dc = zipi , dc = escet , dc = urjc , dc = es " , " profes "= >" ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " ); $wgLDAPAddLDAPUsers = array ( " alumnos "= > false , " profes "= > true );

Figura 4.10: Autenticaci´ on en la p´ agina del Laboratorio mediante el directorio LDAP. Vemos c´omo, se definen dos grupos diferentes de usuarios: alumnos y profes (en principio, cada uno dispondr´ a de un conjunto diferente de privilegios). A continuaci´ on, definimos el servidor de autenticaci´ on (con uno de ellos hubiera bastado, especificamos el servidor primario) y de forma especial, destacamos que el mecanimos de conexi´ on al servidor LDAP debe ser SSL. Si no especificamos esto, la aplicaci´on MediaWiki intentar´ a conectar al puerto est´andar de LDAP en el servidor especificado (389) y la conexi´ on fallar´ a. En la imagen 4.10 podemos ver el resultado de esta configuraci´ on. El sitio MediaWiki del Laboratorio permite la autenticaci´ on contra el directorio LDAP de usuarios. Web personales de usuarios Un aspecto interesante de la configuraci´ on de Apache es la que permite a los usuarios colocar una peque˜ na p´agina personal de usuario en el servidor. Muchos de los usuarios del sistema, utilizan esta posiblidad para colgar informaci´ on sobre su curr´ıculum, pr´acticas realizadas, etc´etera. Para poder llevar a cabo esta configuraci´ on, debemos editar la entrada del virtual host para que busque las p´aginas personales de los usuarios en el directorio public html del usuario que se especifica en la URL. Por ejemplo, la URL del usuario agutierr ser´a http://pantuflo.escet.urjc.es/ agutierr (para el campus de M´ ostoles) o http://bilo.cct.urjc.es/ agutierr (para el campus de Fuenlabrada). Los ficheros que se servir´an Proyecto Fin de Carrera

80

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION en esa URL se localizar´an dentro del directorio public html, en el directorio HOME del usuario. Es necesario que tanto este directorio como el superior, tenga permisos de lectura y ejecuci´ on. La configuraci´ on que materializa esta funcionalidad se muestra a continuaci´ on: Listado 4.51: Configuraci´on de Apache para dar soporte a p´aginas personales de usuarios 2 4 6 8 10 12 14

< IfModule mod_userdir .c > UserDir public_html < Directory / home /*/ public_html > AllowOverride All DirectoryIndex index . html index . php < Limit GET POST OPTIONS PROPFIND > Order allow , deny Allow from all < Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK > Order deny , allow Deny from all

Aplicando esta configuraci´ on en los servidores web de cada una de las m´ aquinas que lo alojan (pantuflo y bilo) los usuarios podr´an colgar su propia p´agina personal alojada en su directorio HOME.

4.2.4.

Servidor de correo electr´ onico

Junto con la cuenta de usuario de los laboratorios se facilita una direcci´on de correo bajo el dominio pantuflo.escet.urjc.es (para el campus de M´ ostoles) y bilo.cct.urjc.es para los usuarios con cuenta en el campus de Fuenlabrada. Esta cuenta de correo en principio es la u ´nica forma de contactar con los usuarios del sistema, puesto que no disponemos de datos adicionales como direcci´on de correo de la Universidad, tel´efono, etc´etera. Por tanto, el buen funcionamiento de este servicio ser´a fundamental para mantener el contacto con los usuarios. Relativo al servicio de correo electr´onico, se nos presentan varios objetivos para el correcto funcionamiento del servicio: 1. Instalar un servidor de correo entrante (SMTP) capaz de recoger todo el correo que llegue a los usuarios del servidor pantuflo.escet.urjc.es. Este servicio, obviamente residir´a en la m´ aquina pantuflo.escet.urjc.es y ser´a gestionado por la aplicaci´on Postfix, tal y como vimos en el cap´ıtulo Estado del arte. Alternativamente, en el campus de Fuenlabrada, el correo ser´a recogido por la m´ aquina bilo.cct.urjc.es. 2. Instalar un servidor de recogida de correo electr´onico, que permita a los usuarios recoger el correo electr´ onico de sus buzones para descargarlos con su gestor de correo favorito. En principio, ofreceremos servicio POP328 para la recogida de correo, aunque posteriormente tambi´en se ofrecer´a la posibilidad de consultar el correo electr´onico usando el protocolo IMAP29 . Preferiblemente, es recomendable que los datos que usen estos protocolos viajen de forma segura, es decir, haciendo uso de una capa de cifrado SSL. Es por ello que una vez que se ha configurado el servidor de recogida de correo para servir v´ıa POP e IMAP y se ha comprobado el correcto funcionamiento del mismo, pasaremos a habilitar el soporte POP3s e IMAPs (variantes de los mismos protocolos en su versi´ on SSL) y quedar´ a desactivado los protocolos POP3 e IMAP en versi´ on texto claro. Esto garantizar´ a a los usuarios una mayor seguridad y privacidad de los datos que intercambian con el servidor. 28 29

POP son las siglas de Post Office Protocol IMAP son las siglas de Internet Message Access Protocol

A. Guti´errez Mayoral

81

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION 3. Alternativamente, vamos a ofrecer a los usuarios la posibilidad de consultar su correo a trav´es de un webmail. De esta forma siempre podr´an consultar sus correos en cualquier momento, u ´nicamente teniendo acceso a un navegador web. Comentaremos a continuaci´ on como conseguimos realizar cada uno de los hitos planteados en esta secci´ on. Entrega de correo electr´ onico (SMTP) Para dotar al sistema de un servidor que recoja el correo electr´onico dirigido a la m´ aquina pantuflo.escet.urjc.es instalaremos la aplicaci´on Postfix. Postfix es un servidor de entrega de correo muy potente y muy sencillo de configurar al mismo tiempo. Como nuestro sistema en principio no tiene grandes pretensiones m´ as que la de simplemente recoger el correo y entreg´arselo a los usuarios, nos decantaremos por esta opci´ on. La instalaci´ on de Postfix es muy sencilla en m´ aquinas basadas en el sistema de paquetes de Debian. En concreto, para la instalaci´ on del mismo, ejecutaremos Listado 4.52: Instalaci´ on de la herramienta postfix usando apt-get $ apt - get install postfix

El paquete solicitar´ a configuraci´ on adicional. No obstante, la configuraci´ on es muy sencilla. Configuraremos el gestor como: Sitio de Internet, capaz de recoger correo dirigido al dominio que nos ocupa (pantuflo.escet.urjc.es para el campus de M´ ostoles y bilo.cct.urjc.es para el campus de Fuenlabrada). El dominio para el cual debe aceptar correo suele ser localhost para el correo local de la propia m´ aquina, localhost.localdomain como extensi´ on al anterior, y por u ´ltimo, el dominio visible desde Internet, que en nuestro caso ser´a pantuflo.escet.urjc.es para el campus de M´ ostoles y bilo.cct.urjc.es para el campus de Fuenlabrada. Por u ´ltimo, y esto es muy importante, las IPs desde las cuales el servidor debe poder hacer relay. Hacer relay en un servidor de correo significa desde que IPs o redes de IPs se debe reenviar correo a dominios externos al propio sin pedir una confirmaci´ on o una autenticaci´ on adicional. En general, se conf´ıa siempre en la propia m´ aquina (las subredes con IP 127.0.0.0/24) y las de la propia red local (en nuestro caso ser´a 212.128.4.0/24 para el campus de M´ ostoles y 193.147.73.0/24 para el campus de Fuenlabrada). Si no configuramos este par´ ametro con especial cautela, numerosos spammers de Internet pueden usar nuestro servidor de correo para enviar correo fraudulento, publicidad y derivados. Una vez hemos aplicado la configuraci´ on en concreto para cada una de las m´ aquinas que se encargar´an de la entrega del correo, podemos comprobar que nuestro servidor funciona adecuadamente (podemos enviarnos un correo de prueba y comprobar que nos llega correctamente). Si quisi´eramos modificar alg´ un aspecto de la configuraci´on, Postfix almacena sus opciones de configuraci´ on en los ficheros /etc/postfix/main.cf y /etc/postfix/master.cf. Los ficheros de configuraci´ on de esta herramienta son bastante sencillos y asequibles de modificar. Recogida de correo electr´ onico (POP3 e IMAP) La recogida de correo mediante protocolos como POP3 e IMAP es un aspecto casi fundamental de cara a que los usuarios de nuestro sistema se sientan lo suficientemente motivados como para Proyecto Fin de Carrera

82

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION usar el correo electr´ onico del servidor pantuflo. De no proporcionar un servicio de recogida de correo, los usuarios se ver´ıan obligados a leer el correo electr´onico en la propia m´ aquina que lo recibe, a trav´es del comando mail, o alguno m´ as avanzado, como Pine o Mutt. La disposici´on de permitir al usuario recoger el correo electr´onico mediante los citados protocolos permite al usuario utilizar aplicaciones de correo como Outlook, Evolution, o Thunderbird, y gestionar el correo de forma eficiente. Mediante estas aplicaciones ser´an capaces de poder leer el correo electr´ onico que les llegue a su cuenta de correo de pantuflo o de bilo sin necesidad de tener que conectarse al servidor para poder leerlo. En concreto, vamos a implantar un servidor de recogida de correo que permita que los usuarios puedan descargarse el correo mediante los protocolos POP3 e IMAP. Como ya vimos en el cap´ıtulo Estado del arte, la aplicaci´on elegida para realizar esta tarea ser´a la aplicaci´on Dovecot, por las ventajas enumeradas en este cap´ıtulo. Esta aplicaci´on nos permitir´a que tanto la m´ aquina pantuflo como la m´ aquina bilo atiendan el servicio POP3 e IMAP, a trav´es de sus correspondientes versiones cifradas (POP3s e IMAPs). Es necesario recordar que ambos protocolos se transmiten por la red en texto claro, incluyendo nombres de usuario y contrase˜ nas, por lo que ser´a obligado el proporcionar el citado servicio utilizando alg´ un m´etodo de encriptaci´on para datos sensibles, como son el correo electr´onico y la informaci´ on de autenticaci´ on. Dovecot La aplicaci´on Dovecot es un servidor de recogida de correo que funciona tanto con ficheros mbox (en los que los correos electr´ onicos se almacenan en un u ´nico fichero) como con el formato m´ as actual de almacenamiento de correo electr´onico, el formato Maildir. Seg´ un se detalla en la p´agina oficial de Dovecot30 , esta aplicaci´on fue pensada y escrita pensando principalmente en la seguridad, en la escalabilidad y en el alto rendimiento, funcionando igual de bien para sistemas austeros, con pocos usuarios, como para grandes sistemas. Adem´ as, soporta multitud de mecanismos de autenticaci´ on, como por ejemplo la autenticaci´ on mediante los m´ odulos de PAM (que ser´a la que usemos en nuestro caso) as´ı como basados en bases de datos. Por u ´ltimo, aunque no es nuestro caso, Dovecot funciona perfectamente en cl´ usters de ordenadores en red que usen por ejemplo NFS como sistema de archivos compartidos. Aunque no es nuestro caso, es un buen ejemplo de la escalabilidad que puede llegar a proveer esta aplicaci´on. Instalaci´ on de Dovecot La instalaci´ on de Dovecot resulta bien sencilla, puesto que se encuentra incluido como paquete Debian en la distribuci´on estable, y por tanto, una simple llamada al comando aptget bastar´ a para su instalaci´ on: Listado 4.53: Instalaci´ on de los demonios necesarios para dar soporte POP3 e IMAP a pantuflo $ apt - get install dovecot - common dovecot - pop3d dovecot - i mapd

Como vemos, es necesario indicar que se desea instalar el paquete con la funcionalidad b´asica de Dovecot (paquete dovecot-common) adem´ as de los paquetes que proveer´ an funcionalidad de los protocolos POP3 e IMAP: los paquetes dovecot-pop3d y dovecot-imapd. Una vez instalados ambos paquetes, ser´a necesario realizar unos ajustes que nos permitan configurar el sistema para que los usuarios puedan recoger el correo electr´onico mediante cualquiera de los dos protocolos. Para ello, deberemos editar el fichero de configuraci´ on /etc/dovecot/dovecot.conf. Nos centraremos en las siguientes l´ıneas: 1. Indicar los protocolos que deben ser servidos por el servidor de recogida de correo. En nuestro caso, vamos a servir los protocolos POP3 e IMAP, en su versi´ on segura (apoyados en las bibliotecas SSL). Lo indicamos de la siguiente forma: 30

http://www.dovecot.org/

A. Guti´errez Mayoral

83

ETSI Inform´atica

´ 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION

protocols = imaps pop3s

2. Indicar donde se encuentran los directorios de correo de los usuarios. Este aspecto es muy importante, ya que si no indicamos la ruta hacia el directorio de correo de forma correcta, los usuarios obtendr´ an un error cuando intenten descargar o consultar su correo con la aplicaci´on gestora correspondiente. En nuestro caso, los directorios de correo se encuentran en el directorio /var/mail/ seguido del nombre de usuario en cuesti´ on. Hay que recordar que debido a que se proporciona funcionalidad IMAP, es necesario que el correo electr´onico se almacene en el formato Maildir, est´andar casi de facto en la mayor´ıa de servidores de correo. Para indicar este par´ ametro en la configuraci´ on de Dovecot, debemos escribir en el fichero de configuraci´ on la siguiente l´ınea: default_mail_env = maildir :/ var / mail / %u /

3. Por u ´ltimo, y dado que la autenticaci´ on de los usuarios en el servidor de recogida de correo ser´a la est´andar del sistema, podemos usar PAM para esta tarea. En ese sentido PAM es muy flexible, ya que para a˜ nadir un nuevo servicio solamente debemos incluir en el directorio /etc/pam.d/ un fichero de nombre dovecot indicando como se realizar´a la autenticaci´ on (exactamente igual al resto de servicios del sistema). Su contenido podr´a ser el siguiente: # %PAM -1.0 @include common - auth @include common - account @include common - session

Una vez realizados estos ajustes en el fichero de configuraci´on de Dovecot, podemos reiniciar el servicio y comprobar que se encuentra escuchando peticiones de los protocolos indicados correctamente: Listado 4.54: Reiniciando el demonio dovecot tras su reconfiguraci´on pantuflo :~# / etc / init . d / dovecot restart Restarting mail server : dovecot . pantuflo :~#

Una llamada a nmap desvela que los servicios se encuentran escuchando en los puertos correspondientes: 993/ tcp 995/ tcp

open open

imaps pop3s

Examinando los ficheros de log del servidor de correo podemos ver c´omo los usuarios se autentican correctamente y recogen su correo usando Dovecot: pantuflo :~# tail -f / var / log / mail . log Jul 2 16:22:26 pantuflo dovecot : pop3 - login : Login : user = < fescriba > , method = PLAIN , rip =83.54.158.7 , lip =212.128.4.4 , TLS Jul 2 16:22:26 pantuflo dovecot : POP3 ( fescriba ) : Disconne cted : Logged out top =0/0 , retr =0/0 , del =0/0 , size =0 Jul 2 16:22:43 pantuflo dovecot : pop3 - login : Login : user = < fescriba > , method = PLAIN , rip =83.54.158.7 , lip =212.128.4.4 , TLS

Proyecto Fin de Carrera

84

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION Jul

2 16:22:43 pantuflo dovecot : POP3 ( fescriba ) : Disconne cted : Logged out top =0/0 , retr =0/0 , del =0/0 , size =0

Webmail para consulta de correo De cara a que los usuarios del Laboratorio dispongan de un m´etodo para la consulta del correo electr´ onico de sus cuentas @pantuflo y @bilo (para el Campus de M´ ostoles y de Fuenlabrada,respectivamente) decidimos instalar un webmail. Un webmail es una aplicaci´on web que permite consultar a trav´es de un navegador web el correo electr´onico de una cuenta de un usuario en un sistema, normalmente una cuenta Unix o Linux. Dado que la instalaci´ on de este tipo de aplicaciones no es muy compleja, decidimos implantar este servicio para ambos campus. De esta forma, aquellos usuarios que no quieran descargarse su correo mediante aplicaciones gestoras de correo (como Outlook, Evolution y derivados) podr´an consultarlo a trav´es del web. Una de las aplicaciones que implementa el servicio webmail m´ as conocidas hoy en d´ıa es la Suite Horde, que adem´ as de proporcionar acceso al buz´ on de correo de un usuario en un sistema Unix/Linux, proporciona servicios de agenda, calendario, etc´etera. De hecho, esta aplicaci´on es en la que se basa el servicio webmail de la Universidad31 . Esto ser´a una ventaja para nosotros, puesto que a los usuarios les resultar´ a familiar el interfaz y apenas existir´ a complejidad de adaptaci´ on a una nueva herramienta. Horde El Proyecto Horde se compone de unas bibliotecas (llamado Horde Framework ) que proporcionan funcionalidades b´asicas (autenticaci´ on, gesti´ on de preferencias, interfaz gr´ afica, etc´etera) y que funciona como nexo de uni´ on entre distintas aplicaciones de usuario, que son gestionadas como subproyectos independientes, dentro de la aplicaci´on Horde. Entre estas aplicaciones encontramos IMP, un sistema webmail que permite el acceso a buzones de correo mediante POP3 o IMAP. A trav´es de este acceso podremos acceder a los buzones de las cuentas de los usuarios, tanto en los servidores pantuflo como bilo. La instalaci´ on de esta aplicaci´on es extremadamente sencilla y por esta raz´on no ser´a detallada en exceso en el presente documento. Para llevar a cabo la instalaci´ on, es necesario descargar las u ´ltimas versiones estables de la aplicaci´on principal de esta suite, llamada Horde: esta aplicaci´ on es la u ´nica no opcional bajo la que se sustentan el resto de m´ odulos del sistema. Si u ´nicamente deseamos instalar la aplicaci´on IMP (webmail), deberemos descargar desde la p´agina del proyecto el m´ odulo imp, instal´ andolo a continuaci´ on de horde. Los u ´nicos aspectos relevantes de la instalaci´ on son: 1. Como se realiza el acceso al servidor POP3/IMAP donde se encuentran los buzones de los usuarios. En nuestro caso, es la configuraci´ on de correo electr´onico que se llev´ o a cabo en el apartado anterior. 2. Como se lleva a cabo la autenticaci´ on de usuarios para poder ingresar en el webmail. Dado que estas aplicaciones se instalar´ an en las m´ aquinas pantuflo y bilo (es l´ ogico que el webmail se encuentre en la misma m´ aquina que recibe el correo) podemos usar la autenticaci´ on local de la citada m´ aquina: si un usuario puede entrar con una cuenta en esa m´ aquina, podr´a entrar en el webmail (l´ ogicamente). Para llevar a cabo esta implementaci´ on, debemos indicarle a IMP que la autenticaci´ on se debe llevar a cabo usando los m´ odulos PAM de la m´ aquina donde se encuentra alojada la aplicaci´on. En el soporte electr´ onico de este documento se puede encontrar los ficheros de configuraci´ on de Horde e IMP para esta configuraci´ on. Una vez que se han llevado a cabo estos ajustes, realizamos 31

https://webmail.urjc.es

A. Guti´errez Mayoral

85

ETSI Inform´atica

4.3. OTROS SERVICIOS DISPONIBLES

Figura 4.11: Webmail de pantuflo unos retoques adicionales a las plantillas HTML de ambos webmails, donde se indica el nombre del laboratorio y unas instrucciones para poder acceder al mismo. El resultado lo podemos observar en las im´agenes 4.11 para el webmail de la m´ aquina pantuflo y 4.12 para el webmail de la m´ aquina bilo. Sobre esta configuraci´ on pueden realizarse mejoras adicionales, como dotar al sistema de un servicio de agenda, calendario, libreta de direcciones, e incluso acceso a las cuentas de usuario (ficheros personales de cada cuenta) a trav´es del navegador web. En nuestro caso, todos estos servicios se implementan junto al servicio webmail: agenda, libreta de direcciones y acceso a las cuentas a trav´es del navegador web.

4.3.

Otros servicios disponibles

En la siguiente secci´ on se comentar´ an una serie de servicios que, aunque no son imprescindibles para que el correcto funcionamiento del Laboratorio, resultan m´ as que interesantes para un funcionamiento m´ as eficiente. En concreto, vamos a comentar brevemente la instalaci´ on de listas de correo para la comunicaci´ on entre administradores y usuarios del sistema (algo fundamental, debido a que no tenemos m´ as datos de los usuarios que su direcci´on de correo en el sistema) as´ı como la instalaci´ on de una r´eplica de paquetes de software tanto para Debian como para Ubuntu, para aumentar la rapidez con la que se instalan los paquetes en el Laboratorio.

4.3.1.

Listas de correo

Un aspecto muy importante del sistema es tener un canal de comunicaci´ on entre los usuarios y los administradores o responsables t´ecnicos del mismo. En nuestro caso, debido a que la autenticaci´ on en nuestros laboratorios no se basa en el dominio u ´nico que provee la Universidad, no disponemos de m´ as datos de los usuarios que la direcci´on de correo que poseen en el momento en el que se abre la cuenta (la direcci´on de correo con dominio @pantuflo.escet.urjc.es. Por supuesto ser´a responsabilidad del usuario leer este correo o redireccionarlo a una direcci´on que lea con asiduidad para poder estar al tanto de los acontecimientos que se suceden en el servidor, as´ı como de cualquier otro asunto que sea relativo a su cuenta. Proyecto Fin de Carrera

86

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION

Figura 4.12: Webmail de bilo Para la gesti´ on de la comunicaci´ on entre los administradores del laboratorio y los usuarios, instalaremos la herramienta de listas de correo mailman. Para la comunicaci´ on entre los administradores del sistema y los usuarios del mismo, creamos dos listas, cuya funci´on ser´a la siguiente:

Figura 4.13: Gesti´ on de listas de correo en pantuflo con Mailman.

Una lista para la comunicaci´ on entre los administradores y los usuarios del sistema en el campus de M´ ostoles, a la que llamaremos lista pantuflo-todos. Una lista para la comunicaci´ on entre los administradores y los usuarios del sistema en el campus de Fuenlabrada, a la que llamaremos lista bilo-todos. A. Guti´errez Mayoral

87

ETSI Inform´atica

4.3. OTROS SERVICIOS DISPONIBLES La primera lista, obviamente ser´a gestionada en uno de los servidores del campus de M´ ostoles. Como vimos en el Cap´ıtulo de Especificaci´ on y Dise˜ no, este servidor ser´a la m´ aquina pantuflo.escet.urjc.es. Uno de los motivos que lleva a que sea esta m´ aquina la que albergue las listas de correo para el campus de M´ ostoles es el dominio de salida de los correos, la m´ aquina visible al resto de los usuarios @pantuflo.escet.urjc.es. De la misma forma, la segunda lista, destinada a la comunicaci´ on entre los administradores y los usuarios del sistema en el campus de Fuenlabrada, estar´a albergada en la m´ aquina bilo.cct.urjc.es, que es la m´ aquina destinada a albergar la gesti´ on de la p´agina web del Laboratorio y el correo electr´ onico, entre otros. Existen otras listas que pueden resultar de utilidad para la gesti´ on interna del laboratorio. Estas listas reciben mensajes de alertas variados, como por ejemplo, avisos de errores en discos duros, el reporte diario de uso de disco del sistema, las alertas por caidas en el servicio, etc´etera. Comentamos alguna a continuaci´ on. La lista pantuflo-local tiene como funci´on la comunicaci´ on interna entre profesores y administradores del laboratorio. La lista pantuflo-backups recibe las alertas de las copias de seguridad que se ejecutan peri´ odicamente en el sistema (en ambos campus). La lista pantuflo-nagios-estaciones recibe las alertas por caidas en las estaciones de usuario, enviadas autom´aticamente por la herramienta nagios. La lista pantuflo-nagios-servidores recibe las alertas por caidas en los servidores, enviadas autom´aticamente por la herramienta nagios. La lista pantuflo-raids recibe notificaciones autom´aticas del estado de los raids en todas las m´ aquinas que los usan. La lista pantuflo-hd-alerts recibe notificaciones de alertas que se puedan producir en los discos duros de las m´ aquinas cr´ıticas (servidores principalmente). Debido a que la gesti´ on del laboratorio (tanto del campus de Fuenlabrada como el de M´ ostoles) se suelen hacer f´ısicamente desde M´ ostoles, todas estas listas estar´an albergadas en la m´ aquina pantuflo.escet.urjc.es. Gesti´ on de listas La gesti´ on de listas a trav´es de la herramienta mailman es realmente sencilla. Como hemos visto, la gesti´ on de estas listas se llevar´ a a cabo en las m´aquinas pantuflo.escet.urjc.es y bilo.cct.urjc.es, en las que est´a instalado Debian GNU/Linux. Por tanto, la instalaci´ on se puede llevar a cabo usando el gestor de paquetes apt-get: Listado 4.55: Instalaci´ on de mailman usando apt-get $ apt - get install mailman

Durante la instalaci´ on, es probable que el gestor de paquetes realice alguna pregunta relativa a la post configuraci´ on del mismo. Una vez instalado, es necesario que se cree una primera lista para que mailman comience a funcionar correctamente. Esta lista es la lista con nombre mailman, y la podemos crear de la siguiente forma: Listado 4.56: Creaci´on de una nueva lista de mailman usando el comando newlist $ newlist mailman

Proyecto Fin de Carrera

88

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION Despu´es de responder a algunas preguntas relativas a la gesti´ on de la lista (persona que la gestiona, contrase˜ na inicial, etc´etera) ser´a necesario a˜ nadir la informaci´ on de salida del comando al fichero /etc/aliases. La informaci´ on que el fichero contendr´ a por tanto, es parecida a esta: mailman : mailman - admin : mailman - bounces : mailman - confirm : mailman - join : mailman - leave : mailman - owner : mailman - request : mailman - subscribe : mailman - unsubscribe :

"|/ var / lib / mailman / mail / mailman "|/ var / lib / mailman / mail / mailman "|/ var / lib / mailman / mail / mailman "|/ var / lib / mailman / mail / mailman "|/ var / lib / mailman / mail / mailman "|/ var / lib / mailman / mail / mailman "|/ var / lib / mailman / mail / mailman "|/ var / lib / mailman / mail / mailman "|/ var / lib / mailman / mail / mailman "|/ var / lib / mailman / mail / mailman

post mailman " admin m ailman " boun ces mailman " conf irm mailman " join mai lman " leave m ailman " owner m ailman " requ est mailman " su bscribe mailman " unsubscribe mailman "

Es importante rese˜ nar que despu´es de haber modificado el contenido de este fichero es necesario ejecutar el comando newaliases. Si no se hace, no se har´ a visible ninguna modificaci´ on que se haya hecho de cara al gestor de correo y a mailman. Una vez que las listas est´an correctamente instaladas, la gesti´ on de ellas se puede realizar u ´nicamente utilizando un navegador. Solamente es necesario crearlas con el comando newlist, ya que toda su gesti´ on puede realizarse mediante el interfaz web de mailman. En la figura 4.13 podemos observar la pantalla de administraci´on de la listas de correo de mailman (para la m´ aquina pantuflo).

4.3.2.

Mirror de Debian y Ubuntu

Debido a que, como se coment´o en anteriores cap´ıtulos, en las estaciones del Laboratorio tenemos instalada la ditribuci´on Ubuntu Linux, resulta realmente interesante tener disponible de forma interna a la red un mirror o espejo que nos sirva para poder instalar paquetes de una forma m´ as eficiente. Sin duda la capacidad de la red es bastante alta, y en ese sentido, la instalaci´ on de paquetes no resulta para nada lenta en ning´ un caso. Sin embargo, siempre resulta m´ as eficiente de cara al tr´afico de la red descargar los paquetes una u ´nica vez y luego replicarlo en todas aquellas m´ aquinas en las que sea necesario. Por ello, se decide llevar a cabo la instalaci´ on (o mejor dicho, la r´eplica) de un servidor de paquetes tanto para Ubuntu, como para Debian. En el caso de Debian la necesidad no es tan alta, puesto que esta distribuci´on u ´nicamente se usa en los servidores. Adem´ as, la red Rediris provee de un mirror o espejo de paquetes para esta distribuci´on, por tanto la penalizaci´on de tr´afico por descarga no ser´ıa tan alta en este caso. Para la instalaci´ on de un mirror local usamos la herramienta debmirror, la cual descargar´a todos los paquetes necesarios para consolidar la r´eplica local de una determinada versi´ on de Debian (o de Ubuntu), con sus correspondientes ramas y secciones. La herramienta debmirror se encuentra disponible tanto en Debian GNU/Linux como en Ubuntu como paquete, y con una u ´nica llamada al gestor de paquetes puede ser instalada. Listado 4.57: Instalaci´ on de la herramienta debmirror usando apt-get $ apt - get install debmirror

Una vez que ha sido instalada, debe ser configurada para ser ejecutada peri´odicamente (lo m´ as normal, es que se ejecute una vez al d´ıa). Lo m´ as f´acil para llevar a cabo esta tarea es usar una l´ınea de cron, para asegurar que este comando se ejecuta peri´odicamente. Como es sabido , las distribuciones que nos ocupan (Debian y Ubuntu) se dividen en versiones. A su vez estas versiones, est´an divididas en secciones. Por tanto, deberemos indicarle a la herramienta A. Guti´errez Mayoral

89

ETSI Inform´atica

´ DEL SISTEMA 4.4. MONITORIZACION debmirror que versiones queremos replicar as´ı como qu´e secciones y ramas de desarrollo. Lo vemos en las siguientes l´ıneas: En el caso de Ubuntu, podemos usar la orden de comando mostrada en el listado 4.58. Listado 4.58: Descargando la r´eplica de Ubuntu usando el comando debmirror debmirror -- nosource -m -- passive -- host = archive . ubuntu linux . org -- root = ubuntu / -- method = ftp -- progress -- dist = dapper , dapper - backports , dapper - security , dapper - updates , dapper - proposed , edgy , edgy - backports , edgy - security , edgy - updates , edgy - proposed , feisty , feisty - backports , feisty - proposed , feisty - security , feisty - updates , gutsy , gutsy - backports , gutsy - proposed , gutsy - security , gutsy - updates , hardy , hardy - backports , hardy - proposed , hardy - security , hardy - updates -- sectio n = main , multiverse , universe , restricted -- arch = i386 / disks / raid / ubuntu - mirror / -- ignore - release - gpg -- nocleanup

En la cual se indica que el mirror principal a trav´es del cual se replicar´ a la informaci´ on es archive.ubuntulinux.org, que se usar´ a el m´etodo ftp, y que se replicar´ an las versiones de Ubuntu dapper, edgy, feisty, gutsy, y hardy. Adem´ as, en cada versi´ on se replicar´ an las secciones main, universe, multiverse y restricted. Por u ´ltimo, le indicamos que la u ´nica arquitectura que se deber´a replicar es la aquitectura Intel x86 y que se deber´an ignorar las advertencias relativas a las firmas PGP. El caso de Debian es m´ as simple, puesto que tanto el n´ umero de versiones como las ramas y secciones es mucho menor, tal y como muestra la llamada a debmirror del listado 4.59. Listado 4.59: Descargando la r´eplica de Debian usando el comando debmirror debmirror / disks / raid / debian - mirror / -- host = ftp . redir is . es -- root =/ debian -- dist = testing , stable , unstable , experimental -- sectio n = main , contrib , non - free -- arch = i386 -- progress -- method = ftp -- nosource -- ignore - release - gpg

En la que se indica que u ´nicamente se deber´an replicar las versiones de Debian testing, stable, unstable y experimental, las secciones main, contrib y non-free en la arquitectura Intel x86. Una vez que hemos configurado el servidor de paquetes como r´eplica para Ubuntu y Debian, configurar los clientes para que usen este mirror es trivial. Para ello, editamos el fichero /etc/apt/sources.list. Como comentamos en el cap´ıtulo Dise˜ no, la m´ aquina peloto ser´a la encargada de albergar el mirror de Ubuntu y de Debian en el Laboratorio, por tanto, en el caso de Ubuntu, el contenido del fichero podr´ıa ser el mostrado en el listado 4.60. Listado 4.60: Contenido del fichero /etc/apt/sources.list usando la r´eplica del Laboratorio 2

4

deb http :// peloto . escet . urjc . es / ubuntu deb http :// peloto . escet . urjc . es / ubuntu deb http :// peloto . escet . urjc . es / ubuntu multiverse deb http :// peloto . escet . urjc . es / ubuntu

feisty main rest ricted universe multiverse feisty - securit y main restricted universe multiverse feisty - backpor ts main restricted universe feisty - updates main restricted universe multiverse

Suponiendo que queremos que nuestro sistema se encuentre en la versi´ on feisty de Ubuntu. Para el caso de Debian, el contenido del fichero es pr´acticamente el mismo, y por tanto no ser´a mostrado a continuaci´ on.

4.4.

Monitorizaci´ on del Sistema

Una vez que todo el sistema est´a implantado y se ha comprobado el correcto funcionamiento de todos los objetivos que nos plante´ abamos, la monitorizaci´ on del mismo es un aspecto fundamental. Es muy importante conocer en todo momento el estado tanto de los hosts que forman nuestra Proyecto Fin de Carrera

90

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION red como de los servicios que ofrecen. En particular, ser´a muy importante conocer el estado de aquellas m´ aquinas que ofrecen servicios que resultan cr´ıticos para el correcto funcionamiento de los laboratorios, es decir, los servidores. La monitorizaci´ on de las estaciones de trabajo es algo importante, pero en todo caso, el que una estaci´on de trabajo no funcione en un momento dado, no origina que el resto de estaciones del laboratorio dejen de funcionar, como es el caso de los servidores. En cualquier caso, ver que todas las estaciones de una sala no funcionan, desde luego puede levantar nuestras sospechas de que algo extra˜ no est´a ocurriendo y requiere nuestra atenci´on. Existen numerosas aplicaciones que prestan funcionalidad de monitorizaci´ on de servicios y m´ aquinas en una red local. Como vimos en el cap´ıtulo Estado del arte, hemos elegido la herramienta Nagios para la monitorizaci´ on b´asica de estaciones, servidores y servicios en cada una de ellas (alertar de posibles ca´ıdas en m´ aquinas y/o servicios y env´ıo de mensajes). Por otro lado, hemos elegido la herramienta Munin para recolectar informaci´ on m´ as elaborada acerca del funcionamiento de cada uno de los servidores. Esta informaci´ on ser´a representada a trav´es de gr´ aficas que podremos visualizar a trav´es de nuestro navegador web favorito. Por otro lado, utilizaremos un script muy sencillo que informar´ a del estado de las estaciones de cara a los usuarios del mismo (principalmente, los alumnos). Esta utilidad volcar´a en una p´agina web el estado de todas las estaciones, para las que se identificar´an tres estados posibles: la m´ aquina est´a apagada, la m´ aquina est´a encendida pero solo responde al ping y por u ´ltimo, la m´ aquina est´a encendida y responde al ping (est´ a disponible). A esta utilidad la llamaremos parte de guerra y estar´a disponible tanto en el campus de M´ ostoles y de Fuenlabrada. A continuaci´ on vamos a ver de forma m´ as detallada el proceso de monitorizaci´ on de los servidores y de las estaciones.

4.4.1.

Monitorizaci´ on de servidores

Como ya se ha comentado, para la monitorizaci´ on de los servidores usaremos dos aplicaciones principalmente. Utilizaremos Nagios para la monitorizaci´ on b´ asica de m´ aquinas y servicios (esto es, saber si las m´ aquinas y los servicios est´an o no disponibles) y de forma m´ as avanzada, utilizaremos Munin para una monitorizaci´ on m´ as avanzada de los servidores. Munin proporciona informaci´ on m´ as detallada y extensa de una m´ aquina en concreto, representada a trav´es de gr´ aficas, que se pueden ver a trav´es del navegador web. Munin est´a compuesto de dos aplicaciones principales: el cliente, que env´ıa informaci´ on de la m´ aquina al servidor Munin, y el servidor, que recolecta la informaci´ on que le env´ıan los clientes y la representa a trav´es de gr´ aficas clasificadas en diferentes ´ areas. Ser´ a muy interesante obtener a trav´es de Munin la informaci´ on del uso de CPU, memoria, procesos, uso de la red, uso del servidor NFS en una m´ aquina en concreto. La m´ aquina que usaremos como vig´ıa de toda esta informaci´ on (tanto Nagios como Munin) ser´a la m´ aquina espatula, como ya se estudi´o en el cap´ıtulo Especificaci´ on y Dise˜ no. Instalaci´ on de Nagios La instalaci´ on de Nagios usando apt-get es realmente sencilla, mostr´andose en el listado 4.61. Listado 4.61: Instalaci´ on de la herramienta Nagios con apt-get $ apt - get install nagios - text

Nagios est´a disponible en diferentes paquetes. En concreto usaremos ´este, que almacena la informaci´ on en ficheros de texto. Otros paquetes de Nagios almacenan la informaci´ on de las m´ aquinas monitorizadas en bases de datos MySQL. Por no a˜ nadir otro servicio a la instalaci´ on, A. Guti´errez Mayoral

91

ETSI Inform´atica

´ DEL SISTEMA 4.4. MONITORIZACION decidimos usar la versi´ on de nagios que no necesita de ning´ un sistema gestor para poder funcionar adecuadamente. Una vez que la herramienta ha sido instalada, ´esta debe ser configurada. En el directorio /etc/nagios existen numerosos ficheros de configuraci´ on que es necesario editar al gusto para que la herramienta funcione seg´ un nuestras necesidades. La configuraci´ on de nagios puede resultar un tanto tediosa si no se automatiza apoy´andonos en scripts de automatizaci´on. Es muy recomendable disponer de un fichero de texto en el que se encuentren reflejadas todas las IPs que se desean monitorizar, as´ı como el nombre de cada m´ aquina. A trav´es de este fichero y usando scripts b´asicos de shell, la configuraci´ on resulta muy sencilla. Vamos a comentar a continuaci´ on los ficheros principales de Nagios que es preciso editar para que funcione correctamente: /etc/nagios/hosts.cfg: almacena la informaci´ on de las m´ aquinas que se desean monitorizar (b´asicamente, la direcci´on IP y el nombre de la m´ aquina). /etc/nagios/hostgroups.cfg: agrupa las m´ aquinas a˜ nadidas en el fichero de configuraci´ on anterior en grupos de m´ aquinas. En nuestro caso, resulta aconsejable agrupar las m´ aquinas de cada aula en un grupo diferente, y crear otro para los servidores. /etc/nagios/contacts.cfg: contiene la informaci´ on de las personas de contacto para los avisos autom´aticos de la aplicaci´on. La informaci´ on reflejada en este fichero consta de nombre de la persona de contacto, correo electr´onico, tel´efono, etc´etera. /etc/nagios/contactgroups.cfg: agrupa las personas de contacto anterior en grupos. Esta funcionalidad tiene como objetivo separa los contactos en grupos, en caso de que la administraci´on de cada m´ aquina estuviera separada. En nuestro caso (debido a que el equipo t´ecnico es m´ as bien peque˜ no) no se usar´ a, y u ´nicamente existir´ a un grupo. /etc/nagios/services.cfg: este fichero almacen la informaci´ on de los servicios que se desean monitorizar de una m´ aquina o de un grupo de m´ aquinas en concreto. Por ejemplo, aquina tiene el monitorizar que la m´ aquina est´a disponible (servicio check ping), que la m´ servicio SSH ejecutando (servicio check ssh), etc´etera. Una vez que todos los ficheros han sido configurados, es necesario reiniciar el servico nagios, para que la configuraci´ on se actualice y todo empiece a funcionar adecuadamente. Existen diferentes otros ficheros de configuraci´ on que no son exactamente relativos a Nagios, como son la configuraci´ on de Apache, los usuarios que pueden acceder a la informaci´ on, etc´etera. Una vez que est´a todo funcionando, podemos acceder al sistema de monitorizaci´ on32 . En la imagen 4.14 se pude observar la p´agina principal del estado de los servicios en Nagios. Podemos ver las m´ aquinas del Laboratorio de M´ ostoles agrupadas por aula (106, 108, 109 y 111) y los servidores. Por cada grupo, se puede observar las m´ aquinas que est´an disponibles y el estado de los servicios que se monitorizan en esas m´ aquinas. Podemos ver que en todas las aulas todas las m´ aquinas est´an disponibles (estado OK) menos en el aula 108, que hay dos que no lo est´an, y que en principio la mayor´ıa de los servicios est´an disponibles (excepto de las m´ aquinas que est´an apagadas, por supuesto). Por cada m´ aquina se monitorizan como m´ınimo dos servicios: servicio ping y servicio ssh. Para los servidores, se monitorizan m´ as cosas. Por ejemplo, en pantuflo nos interesar´ a saber que los servidores web (HTTP) y correo (SMTP, POP3s e IMAPs) est´an disponibles. En la parte de la izquierda de la p´agina se muestra el men´ u de opciones de Nagios (que son bastantes). La parte m´ as interesante ser´a saber los problemas de los servicios que haya en algunas m´ aquinas. Podemos acudir a la opci´ on service problems para ver los problemas que hay en las 32

http://espatula.pantuflo.es/nagios/

Proyecto Fin de Carrera

92

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION

Figura 4.14: La p´ agina de resumen de estado de Nagios para el Laboratorio de M´ ostoles.

Figura 4.15: La p´ agina de problemas de Nagios muestra los problemas en algunas m´ aquinas. m´ aquinas que se monitorizan. En la imagen 4.15 podemos ver la informaci´ on contenida en esta secci´ on, las m´ aquinas que tienen problemas, la duraci´ on del mismo y cuando se comprob´ o por u ´ltima vez. Adem´ as de esta informaci´ on, por supuesto, los problemas que pueda tener una m´ aquina en concreto se pueden enviar por correo electr´onico. Para ello, es preciso configurar los ficheros que se comentaban anteriormente. Es necesario observar que las alertas de problemas en las estaciones pueden ocasionar mucho ruido: tenemos 160 estaciones en el campus de M´ ostoles, y 100 en el campus de Fuenlabrada. A cada reinicio de m´ aquina, tendremos dos mensajes de correo electr´onico (servicio DOWN y servicio UP). Esto puede ocasionar demasiados mensajes y producir un efecto rebote, que nos haga prescindir de esta informaci´ on. En nuestro caso, los mensajes de alerta de las estaciones se enviar´ an a una direcci´on de correo y los de los servidores (ya que requieren mucha m´ as atenci´on) se enviar´ an a otra. Instalaci´ on de Munin Vamos a utilizar Munin como sistema de recolecci´on de informaci´ on para los servidores u ´nicamente. Como hemos visto, Munin se compone de un servidor que representa la informaci´ on de los clientes, y los nodos que env´ıan la informaci´ on al servidor. La instalaci´ on de Munin es muy sencilla en un sistema Debian o basado en la herramienta apt-get: En el servidor:

A. Guti´errez Mayoral

93

ETSI Inform´atica

´ DEL SISTEMA 4.4. MONITORIZACION Listado 4.62: Instalaci´ on de la herramienta Munin (servidor) con apt-get $ apt - get install munin

En los clientes: Listado 4.63: Instalaci´ on de la herramienta Munin (cliente) con apt-get $ apt - get install munin - node

En los clientes, u ´nicamente ser´a necesario indicar qu´e servidor puede conectarse al puerto de escucha de Munin y obtener la informaci´ on de la m´ aquina. Esto se puede indicar editando el fichero /etc/munin/munin-node.conf : Listado 4.64: Instalaci´ on de la herramienta Munin (cliente) con apt-get host_name lechuzo allow ^212\.128\.4\.9 $

Los par´ ametros m´ as importantes son el nombre que se mostrar´a en la p´agina de Munin, y la IP que puede acceder al nodo para recopilar la informaci´ on. Este par´ ametro obviamente depender´a de la m´ aquina que recoja los datos de los clientes de Munin.

4.4.2.

Monitorizaci´ on de estaciones

La monitorizaci´ on de estaciones de cara a los usuarios del sistema se llevar´ a a cabo a trav´es de un script muy simple que informa de las estaciones que se encuentran disponibles. Normalmente, los usuarios del laboratorio, suelen conectarse a las estaciones del laboratorio para poder realizar sus pr´acticas.

Figura 4.16: El parte de guerra de M´ ostoles muestra el estado de las estaciones. En la imagen 4.16 puede observarse la visualizaci´ on del parte de guerra para el campus de M´ ostoles33 . Como se puede observar, para cada estaci´on se representa mediante el color verde 33

http://pantuflo.escet.urjc.es/parte.html

Proyecto Fin de Carrera

94

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION el que la m´ aquina tenga el servicio disponible (ping o ssh) y rojo en caso contrario. De esta forma, los alumnos saben en cada momento a qu´e estaci´on se pueden conectar para realizar sus tareas. Alternativamente, se aplica el mismo script para el campus de Fuenlabrada34 . La salida de esta p´agina es bastante similar a la mostrada en la imagen 4.16. El parte de guerra se actualiza aproximadamente cada tres minutos mediante una tarea de cron en las m´ aquinas pantuflo.escet.urjc.es y bilo.cct.urjc.es. En el ap´endice adjunto al documento pueden consultarse los scripts que producen la salida correspondiente para ambos partes de guerra.

4.5.

Seguridad

Para finalizar, el u ´ltimo de nuestros objetivos ser´a elevar el grado de seguridad de todos los servicios disponibles. En concreto, vamos a centrar nuestros esfuerzos en tener controlados los siguientes aspectos: Limitar los accesos remotos a las m´ aquinas clave para el correcto funcionamiento del laboratorio (servidores, principalmente). Detectar intrusiones en las estaciones mediante geolocalizaci´ on de las conexiones de hosts remotos. Detecci´on de ataques de fuerza bruta en los intentos de autenticaci´ on a las estaciones Evaluar la debilidad de las contrase˜ nas de los usuarios mediante la herramienta John the ripper.

4.5.1.

Limitar los accesos remotos

En primer lugar, vamos a impedir el acceso a aquellas m´ aquinas que son cr´ıticas para el correcto funcionamiento del Laboratorio. Principalmente, los servidores, tanto del campus de M´ ostoles como el de Fuenlabrada. Aunque tambi´en, ser´a necesario limitar las conexiones en los servidores LDAP para que solamente sea posible que se conecten a ellos estaciones de los Laboratorios. Limitar el acceso SSH mediante los ficheros hosts.allow y hosts.deny Para limitar el acceso SSH a los servidores, vamos a restringir la conectividad a redes pertenecientes o bien al Departamento de Sistemas Telem´aticos o al Laboratorio. Esto es, a m´ aquinas pertenecientes a la subredes 212.128.4.0/24, 193.147.71.0/24 para el Campus de M´ ostoles, y 193.147.73.0/24 junto con la subred 193.147.71.0/24 para el Campus de Fuenlabrada. De esta forma, aseguramos que nadie pueda iniciar una sesi´ on SSH en ning´ un servidor si no lo hace desde dentro de alguna de nuestras redes. Esta norma se aplicar´a a todos los servidores excepto al servidor pantuflo y al servidor bilo, en los que se puede iniciar una sesi´ on SSH en principio desde cualquier host. Para poder llevar a cabo esta restricci´on, haremos uso de los ficheros /etc/hosts.deny y /etc/hosts.allow. En concreto, en el fichero /etc/hosts.deny, debemos indicar que por defecto se deniegue cualquier conexi´ on SSH a no ser que alguna regla lo permita (descrita en el fichero /etc/hosts.allow. Por tanto, el fichero /etc/hosts.deny debe contener lo siguiente: sshd : ALL 34

http://bilo.cct.urjc.es

A. Guti´errez Mayoral

95

ETSI Inform´atica

4.5. SEGURIDAD De esta forma estamos indicando que el servicio SSH ser´a denegado a cualquier host, a no ser que el fichero /etc/hosts.allow diga lo contrario. Y es aqu´ı donde este fichero entra en juego: sshd : 212.128.4. , 193.147.71. , 193.147.73.

Como vemos, es posible indicar mediante los tres primeros d´ıgitos de la IP desde que subredes s´ı se admitir´ a usar el servicio SSH. De esta forma, no podremos abrir una conexi´ on SSH desde fuera de estas tres subredes, lo que a priori, reducir´ a considerablemente la probabilidad de que alguien ajeno a los laboratorios o al departamento intente nada contra estas m´ aquinas. Si intentamos conectarnos a cualquiera de los servidores que incluyan estas restricciones, obtendremos el siguiente error: s s h _ e x c h a n g e _ i d e n t i f i c a t i o n : Connection closed by remot e host

Limitar el acceso SSH mediante clave p´ ublica/privada Si queremos aumentar a´ un m´ as el grado de seguridad a la hora de inicar una sesi´ on SSH en cualquiera de los servidores, podemos desactivar el inicio de sesi´ on mediante desaf´ıo pregunta/respuesta (el tradicional acceso introduciendo una contrase˜ na), y activar la autenticaci´ on u ´nicamente usando mecanismos de criptograf´ıa de clave p´ ublica/privada. De esta forma, ser´a necesario generar un par de claves, copiar la clave p´ ublica del host desde el que queremos conectar al servidor en cuesti´ on y a˜ nadirlo en el fichero authorized keys del directorio /root/.ssh/. De esta forma, solamente podr´an inciar sesi´ on en el servidor aquellos usuarios que posean la clave privada y la palabra de paso que la desbloquea (en caso de que haya sido generada con contrase˜ na). Adem´ as, en caso de perder la clave privada, no tendr´ıamos por qu´e preocuparnos (demasiado) debido a que sin la palabra de paso, es una clave totalmente in´ util. Por tanto, para poder iniciar sesi´ on en cualquiera de los servidores, necesitaremos cumplir estrictamente estos dos requisitos: Poseer una IP perteneciente a la red del Laboratorio o del Departamento Poseer la clave privada incluida como autorizada en el servidor al que nos queremos conectar (y adem´ as saber la palabra de paso que desbloquea la clave) Como vemos, son dos requisitos suficientemente restrictivos que nos proporcionan bastante tranquilidad en la seguridad del servidor y disminuyen bastante la probabilidad de intrusi´ on en la m´ aquina. Impedir la conexi´ on a los servidores LDAP desde fuera de los Laboratorios Los servidores LDAP, si nada lo impide, permiten que cualquier m´ aquina pueda realizar peticiones de lectura sin emplear ning´ un mecanismo de autenticaci´ on previo. Debido a la arquitectura de LDAP como mecanismo de autenticaci´ on, es necesario que de forma an´ onima, un usuario pueda realizar peticiones de lectura de su nombre de usuario (adem´as de otra serie de datos), de forma totalmente an´ onima (de hecho, esto es lo que le permite autenticarse). Cabe rese˜ nar que entre estos datos no se encuentra la contrase˜ na, aunque existen otros que son tambi´en muy sensibles, y que se pueden consultar de forma an´ onima si nada lo impide. La otra posibilidad es introducir un usuario que permita leer los datos de todos los usuarios, inclu´ıda la contrase˜ na, y configurar los clientes para que se aten a este usuario para realizar operaciones de autenticaci´ on. En nuestro caso hemos optado por el primer mecanismo, ya que configuraremos los servidores para que no respondan a peticiones que vengan de m´ aquinas que no se encuentran en los Laboratorios. Proyecto Fin de Carrera

96

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION Para llevar a cabo esta restricci´on, vamos a emplear el mismo mecanismo que en el punto anterior, cuando limit´abamos el acceso a los servidores mediante SSH: haciendo uso de los ficheros hosts.allow y hosts.deny. De esta forma, en cada servidor LDAP debemos incluir las subredes de todos los laboratorios (recordamos que las peticiones de autenticaci´ on de un campus pueden resolverse en un servidor LDAP de otro campus, si todos los servidores de este campus se han caido). De la misma forma que en el punto anterior, debemos denegar todas las conexiones al servicio slapd (encargado de atender las peticiones LDAP) desde cualquier host. Esta regla debe ser incluida en el fichero /etc/hosts.deny: slapd : ALL

Y si queremos que se acepten conexiones al servicio slapd desde redes espec´ıficas, solamente lo debemos indicar en el fichero /etc/hosts.allow: slapd : 212.128.4. , 193.147.56. , 193.147.57. , 193.147.73 .

En este caso no se contempla que m´ aquinas pertenecientes a la red del Departamento se puedan conectar a un servidor LDAP, puesto que no es necesario.

4.5.2.

Auditor´ıa de usuarios

Otro de los aspectos que es muy importante de cara a la seguridad general del sistema es la implantanci´ on de alg´ un tipo de sistema de auditor´ıa, tanto de los usuarios que se encuentran en un momento dado en el sistema como de los comandos que ejecutan en cualquiera de las estaciones. En este sentido, no hemos encontrado ninguna aplicaci´on en sistemas operativos Linux que realize esta tarea de forma autom´atica. En concreto, para la auditor´ıa de comandos realizados por los usuarios, existe un parche para el kernel de Linux llamado process accounting a trav´es del cual, el kernel del sistema operativo vuelca en un fichero (situado en el directorio /proc) que puede ser leido en principio por aplicaciones que obtienen en un formato legible por humanos la informaci´ on concerniente a los diversos comandos que los usuarios ejecutan en el sistema. No obstante, esta informaci´ on es demasiado verbosa, ya que a˜ nade una entrada por cada proceso que el usuario ejecuta en un momento dado. Cuando realizamos algunas pruebas de este sistema de auditor´ıa nos encontramos con que en un s´ olo d´ıa podemos obtener miles y miles de l´ıneas de informaci´ on (debido al elevado n´ umero de estaciones y de usuarios) con el consecuente problema de almacenamiento que ello supon´ıa (adem´as del indexado posterior en un momento determinado). Sin embargo, la auditor´ıa de los usuarios conectados en el sistema en un momento dado no resulta ni tan verbosa ni tan costosa en t´erminos de almacenamiento. Es por ello que nos planteamos la creaci´ on de un sistema que registre en cualquier momento los usuarios que se encuentran logueados en el sistema, en cualquier m´ aquina del laboratorio. Como ya hemos comentado anteriormente, no encontramos ninguna aplicaci´on que nos resolviera esta funcionalidad de forma satisfactoria, por lo que optamos por programar nuestro propio sistema de auditor´ıa a medida. El sistema no debe tener grandes pretensiones: simplemente debe almacenar en un sistema de almacenamiento (por ejemplo, una base de datos) las entradas de los usuarios que en ese momento se encuentran en el sistema. Para ello, podemos apoyarnos en scripts b´asicos de shell que recojan la salida de comandos est´andar de Unix que devuelven la informaci´ on relativa a los usuarios conectados en el sistema en un momento dado (como por ejemplo los comandos w o who). En principio, la informaci´ on que nos gustar´ıa almacenar de cada usuario ser´ıa la siguiente: Host o estaci´on en la que el usuario se encuentra conectado o logueado. A. Guti´errez Mayoral

97

ETSI Inform´atica

4.5. SEGURIDAD Consola en la que ha iniciado sesi´ on (una consola virtual, de texto o la consola gr´ afica). Fecha y hora en la que ha iniciado sesi´ on Fecha y hora actual Host remoto desde el que ha iniciado la sesi´ on. El almacenamiento de esta informaci´ on en una base de datos MySQL supondr´ a la creaci´ on de una base de datos y una tabla a tal efecto. Para la informaci´ on que necesitamos almacenar, podemos usar las siguientes sentencias de SQL mostradas en el el listado 4.65. Listado 4.65: Creaci´on de una tabla en MySQL para almacenar la informaci´ on relativa a auditor´ıa de usuarios 2 4 6 8 10

CREATE TABLE ‘who ‘ ( ‘id ‘ int (20) NOT NULL auto_increment , ‘ hostname ‘ varchar (255) NOT NULL default ’’, ‘ logname ‘ varchar (12) NOT NULL default ’’, ‘pts ‘ varchar (255) NOT NULL default ’’, ‘ login ‘ datetime NOT NULL default ’0000 -00 -00 00:00:00 ’ , ‘now ‘ datetime NOT NULL default ’0000 -00 -00 00:00:00 ’ , ‘ from ‘ varchar (255) NOT NULL default ’’, PRIMARY KEY ( ‘ id ‘) , KEY ‘ hostname ‘ ( ‘ hostname ‘ , ‘ logname ‘) ) ENGINE = MyISAM ;

Por supuesto asumimos que en cualquier host disponemos de un sistema gestor MySQL con los permisos suficientes para realizar las anteriores tareas. Una vez que la base de datos ha sido creada, podemos usar el script mostrado en el listado 4.66 para poder registrar la informaci´ on relativa a la auditor´ıa de usuarios: Listado 4.66: Script b´asico para registrar informaci´ on de auditor´ıa de usuarios #!/ bin / bash 2 4

TMP_FILE1 = ‘ mktemp -p $HOME / bin / ‘ TMP_FILE2 = ‘ mktemp -p $HOME / bin / ‘

6

/ usr / bin / who | sed s / ’ ’/ ’_ ’/ g > $TMP_FILE1

8

for linea in ‘ cat $TMP_FILE1 ‘; do i = ‘ echo $linea | sed s / ’_ ’/ ’ ’/g ‘ HOSTNAME = ‘ hostname ‘ LOGNAME = ‘ echo $i | awk ’{ print $1 } ’ ‘ PTS = ‘ echo $i | awk ’{ print $2 } ’ ‘ DATE = ‘ echo $i | awk ’{ print $3 } ’ ‘" " ‘ echo $i | awk ’{ print $4 } ’ ‘ FROM = ‘ echo $i | awk ’{ print $5 } ’ | sed s / ’) ’/ ’ ’/ g | sed s / ’( ’/ ’ ’/ g ‘ NOW = ‘ date + %F " " %T ‘ echo " INSERT INTO who VALUES ( ’ ’ , ’" $HOSTNAME " ’ , ’" $LOGNAM E " ’ , ’" $PTS " ’ , ’" $DATE " ’ , ’" $NOW " ’ , ’" $FROM " ’) " echo " INSERT INTO who VALUES ( ’ ’ , ’" $HOSTNAME " ’ , ’" $LOGNAM E " ’ , ’" $PTS " ’ , ’" $DATE " ’ , ’" $NOW " ’ , ’" $FROM " ’) " > $TMP_FILE2 done

10 12 14 16

18 20

cat $TMP_FILE2 | / usr / bin / mysql -u who -h $MYSQL_HOST -- pas sword = $MYSQL_PASSWORD $MYSQL_DATABASE 1 > / dev / null 2 > / dev / null

22

rm $TMP_FILE1 rm $TMP_FILE2

A trav´es del script anterior, se registrar´ an los usuarios que est´an conectados en una m´ aquina en un momento dado. Combinando el script anterior con una sentencia de cron, podemos registrar Proyecto Fin de Carrera

98

Universidad Rey Juan Carlos

´ CAP´ITULO 4. IMPLANTACION autom´aticamente todos los usuarios que est´en conectados en una estaci´on, con una frecuencia muy baja (cada minuto). La siguiente l´ınea de cron puede ser suficiente para dejar definida la tarea: Listado 4.67: L´ınea de cron para la automatizaci´on de la auditor´ıa de usuarios en el sistema */1 * * * * sh / root / who - mostoles . sh

La posterior consulta de datos en un momento determinado, dado que ´estos son almacenados en una base de datos MySQL, se puede realizar a trav´es de sentencias b´asicas de SQL. Incluso, se puede realizar a trav´es de un portal PhpMyAdmin35 , para minimizar la dificultad en la consulta de estos datos.

4.5.3.

Detecci´ on de intrusos

Detecci´ on de IPs no espa˜ nolas Gracias al sistema que hemos dise˜ nado e implantado para registrar los accesos de los usuarios en cada una de las estaciones, podemos dise˜ nar diversos sistemas de alerta que nos avisen ante situaciones sospechosas. Una de estas situaciones podr´ıa ser la conexi´ on en una estaci´on desde un host remoto fuera de Espa˜ na. No es frecuente en el entorno que tenemos instalado que se conecten al laboratorio alumnos desde fuera del pa´ıs, excepto contadas excepciones, las cuales podr´ıan ser enumeradas en un fichero de nombres de usuario a no tener en cuenta por este monitor. Para poder detectar si un host remoto pertenece o no al pa´ıs, podemos usar la herramienta geoiplookup, tal y como se muestra en el ejemplo mostrado en el listado 4.5.3. La ejecuci´ on de este comando devuelve el c´odigo de pa´ıs correspondiente a la geolocalizaci´ on del host. agutierr@minervo ~ $ geoiplookup 212.128.4.4 GeoIP Country Edition : ES , Spain

Si a trav´es de la salida de este comando se detecta que la IP o host remoto no pertenece a Espa˜ na (es decir, haciendo b´ usquedas por c´odigos no pertenecientes a ES, Spain tendremos una lista de IPs (combinando con la estaci´on y nombre de usuario que se ha usado en la conexi´ on) cuanto menos, sospechosas de ser investigadas. El monitor o script que realiza esta tarea puede ser consultado en el ap´endice de este documento. Debido a que la estructura del mismo es bastante simple no se indica en l´ınea. Conexiones nocturnas en el Laboratorio Si bien es muy frecuente que los alumnos inicien sus sesiones por la noche para realizar sus pr´acticas, existen unos l´ımites horarios a partir de los cuales ya no es muy frecuente encontrar usuarios conectados en las estaciones (si bien siempre existen alumnos a los que les gusta realizar sus pr´acticas a altas horas de la madrugada). Debido a que encontrar usuarios trabajando a altas horas de la noche tambi´en puede ser sospechoso a priori, podemos programar otro monitor que nos alerte de los usuarios que han realizado conexiones nocturas, por ejemplo, entre las dos y las siete de la madrugada. Listado 4.68: Monitor de alerta de conexiones nocturnas en el laboratorio DATE = ‘ date + %Y- %m- %d ‘ 2

TMPFILE = ‘ mktemp ‘ 35 Aplicaci´ on que permite realizar operaciones de gesti´ on y consulta sobre un sistema gestor MySQL a trav´es de un navegador.

A. Guti´errez Mayoral

99

ETSI Inform´atica

4.5. SEGURIDAD

4

echo " SELECT hostname , logname , now , \ ‘ from \ ‘ FROM \ ‘ who \ ‘ WHERE now >= \" $DATE 02:00\" AND now sapientin ‘ date + %d- %m- %Y ‘" pantuflo - backups@pantuflo . escet . urjc . es

B.1.2.

De bilo a nano Listado B.2: Script backup-nano

#!/ bin / bash

5

DIR_ORIGEN =/ disks / raid / homes . fuenla DIR_DESTINO =/ disks / raid / homes . fuenla LOG =/ var / log / backups / log_backups_ ‘ date + %d- %m- %Y ‘ / etc / init . d / nscd stop sleep 5

10

## CUIDADO : PONEMOS -S ( sparse ) en rsync para manejar adecua damente ## los ficheros sparse . Si no lo ponemos , la copia ocupar´ ı a t anto que ## no cabr´ ı a en el servidor . 15

if [ ! " ‘ pidof backup - nano . sh ‘" ] ; then for i in ‘ ls $DIR_ORIGEN ‘ do echo Haciendo backup a nano >> $LOG

Proyecto Fin de Carrera

x

Universidad Rey Juan Carlos

´ APENDICE B. SCRIPTS ADICIONALES echo * origen $DIR_ORIGEN / $i >> $LOG echo * destino $DIR_DESTINO / $i >> $LOG rsync - arzvvS $DIR_ORIGEN / $i -- max - size =500 M -- exclude =" debian - mirror *" -- exclude ="*. mp3 " -- exclude ="*. avi " -- exclude ="*. mpg " -- exclude =".* " -- delete -- exclude ="*. disk " root@nano . cct . urjc . es : $DIR_DESTINO done echo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> $LOG echo BACKUP A NANO TERMINADO >> $LOG echo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> $LOG

20

25

fi mail -s " Backup bilo -> nano ‘ date + %d- %m- %Y ‘" pantuflo - bac kups@pantuflo . escet . urjc . es < $LOG 30

/ etc / init . d / nscd start

B.1.3.

De sapientin al disco USB Listado B.3: Script backup-usb.sh

#!/ bin / bash

5

DIR_ORIGEN =/ disks / raid / homes . mostoles / DIR_DESTINO =/ mnt / disks / raid / homes . mostoles / LOG =/ var / log / backups / log_backups - usb_ ‘ date + %d- %m- %Y ‘ ## CUIDADO : PONEMOS -S ( sparse ) en rsync para manejar adecua damente ## los ficheros sparse . Si no lo ponemos , la copia ocupar´ ı a t anto que ## no cabr´ ı a en el servidor .

10

15

20

if [ ! " ‘ pidof backup - usb . sh ‘" ] ; then for i in ‘ ls $DIR_ORIGEN ‘ do echo Haciendo backup a USB >> $LOG echo * origen $DIR_ORIGEN / $i >> $LOG echo * destino $DIR_DESTINO / $i >> $LOG rsync - arzvvS -- delete $DIR_ORIGEN / $i $DIR_DESTINO done echo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> $LOG echo BACKUP SAPIENTIN - USB TERMINADO >> $LOG echo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> $LOG fi mail -s " Backup sapientin - > disco usb en ‘ date ‘" pantuflo - b ackups@pantuflo . escet . urjc . es < $LOG

B.1.4.

De nano al disco USB Listado B.4: Script backup-usb.sh

#!/ bin / bash

5

DIR_ORIGEN =/ disks / raid / homes . fuenla / DIR_DESTINO =/ mnt / disks / raid / homes . fuenla / LOG =/ var / log / backups / log_backups - usb_ ‘ date + %d- %m- %Y ‘ ## CUIDADO : PONEMOS -S ( sparse ) en rsync para manejar adecua damente ## los ficheros sparse . Si no lo ponemos , la copia ocupar´ ı a t anto que ## no cabr´ ı an en el servidor .

10

if [ ! " ‘ pidof backup - usb . sh ‘" ] ; then for i in ‘ ls $DIR_ORIGEN ‘ do

A. Guti´errez Mayoral

xi

ETSI Inform´atica

B.2. SCRIPT DE COPIA DE SEGURIDAD DEL DIRECTORIO LDAP echo Haciendo backup a USB >> $LOG echo * origen $DIR_ORIGEN / $i >> $LOG echo * destino $DIR_DESTINO / $i >> $LOG rsync - arzvvS -- delete $DIR_ORIGEN / $i $DIR_DESTINO done echo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> $LOG echo BACKUP SAPIENTIN - USB TERMINADO >> $LOG echo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> $LOG

15

20

fi mail -s " Backup nano -> disco usb en ‘ date ‘" pantuflo - backup s@pantuflo . escet . urjc . es < $LOG

B.2.

Script de copia de seguridad del directorio LDAP Listado B.5: Script backup-ldap.sh

#!/ bin / bash DATE = ‘ date + %F ‘ 5

/ usr / sbin / slapcat | gzip -9 > / var / backups / ldap / ldap - bac kup_$DATE . gz

B.3.

Auditor´ıa de usuarios

La auditor´ıa de usuarios nos permite saber en todo momento los usuarios que iniciaron una sesi´ on en el Laboratorio en un momento determinado, con todo lujo de detalles: nombre de usuario, m´ aquina en la que iniciaron una sesi´ on, fecha y hora del inicio de la sesi´ on, etc´etera. Estos datos se almacenan en una base de datos MySQL, mediante scripts de Shell que se ejecutan cada minuto, en cada una de las estaciones del Laboratorio. A continuaci´ on mostramos el script de creaci´ on de la base de datos y el de inserci´ on de datos.

B.3.1.

Creaci´ on de la base de datos Listado B.6: Creaci´ on de la base de datos de Auditor´ıa

5

10

CREATE TABLE IF NOT EXISTS ‘who ‘ ( ‘id ‘ int (20) NOT NULL auto_increment , ‘ hostname ‘ varchar (255) NOT NULL default ’’, ‘ logname ‘ varchar (12) NOT NULL default ’’, ‘pts ‘ varchar (255) NOT NULL default ’’, ‘ login ‘ datetime NOT NULL default ’0000 -00 -00 00:00:00 ’ , ‘now ‘ datetime NOT NULL default ’0000 -00 -00 00:00:00 ’ , ‘ from ‘ varchar (255) NOT NULL default ’’, PRIMARY KEY ( ‘ id ‘) , KEY ‘ hostname ‘ ( ‘ hostname ‘ , ‘ logname ‘) ) ENGINE = MyISAM DEFAULT CHARSET = latin1 AUTO_INCREMENT =8 599042 ;

B.3.2.

Inserci´ on de los datos de auditor´ıa Listado B.7: Script who-mostoles.sh

#!/ bin / bash

Proyecto Fin de Carrera

xii

Universidad Rey Juan Carlos

´ APENDICE B. SCRIPTS ADICIONALES TMP_FILE1 = ‘ mktemp -p $HOME / bin / ‘ TMP_FILE2 = ‘ mktemp -p $HOME / bin / ‘ 5

/ usr / bin / who | sed s / ’ ’/ ’_ ’/ g > $TMP_FILE1

10

15

20

for linea in ‘ cat $TMP_FILE1 ‘; do i = ‘ echo $linea | sed s / ’_ ’/ ’ ’/g ‘ HOSTNAME = ‘ hostname ‘ LOGNAME = ‘ echo $i | awk ’{ print $1 } ’ ‘ PTS = ‘ echo $i | awk ’{ print $2 } ’ ‘ DATE = ‘ echo $i | awk ’{ print $3 } ’ ‘" " ‘ echo $i | awk ’{ print $4 } ’ ‘ FROM = ‘ echo $i | awk ’{ print $5 } ’ | sed s / ’) ’/ ’ ’/ g | sed s / ’( ’/ ’ ’/ g ‘ NOW = ‘ date + %F " " %T ‘ echo " INSERT INTO who VALUES ( ’ ’ , ’" $HOSTNAME " ’ , ’" $LOGNAM E " ’ , ’" $PTS " ’ , ’" $DATE " ’ , ’" $NOW " ’ , ’" $FROM " ’) " echo " INSERT INTO who VALUES ( ’ ’ , ’" $HOSTNAME " ’ , ’" $LOGNAM E " ’ , ’" $PTS " ’ , ’" $DATE " ’ , ’" $NOW " ’ , ’" $FROM " ’) " > $TMP_FILE2 done cat $TMP_FILE2 | / usr / bin / mysql -u who -h 212.128.4.12 -- pa ssword =??????? who - escet 1 > / dev / null 2 > / dev / null rm $TMP_FILE1 rm $TMP_FILE2

B.4.

Scripts ssh-a-todos y scp-a-todos

Los scripts llamados ssh-a-todos son algo imprescindible en el sistema. A trav´es de ellos, conseguimos iniciar una sesi´ on SSH desde un servidor o estaci´on a todos las estaciones del Laboratorio, como usuario root, sin necesidad de introducir ninguna contrase˜ na. Gracias a esto, podemos copiar ficheros, sincronizar directorios, instalar software, en definitiva, lanzar cualquier comando en cualquier estaci´on o en un grupo de estaciones de forma totalmente autom´atica. Para realizar esta tarea se utiliza un mecanismo de autenticaci´ on por clave p´ ublica-privada, conteniendo la clave p´ ublica del servidor desde el cual iniciamos una sesi´ on en el fichero /root/.ssh/authorized keys de todas las m´ aquinas del laboratorio.

B.4.1.

Scripts ssh-a-todos

Disponemos de un script que inicia una sesi´ on SSH a un laboratorio concreto (sala alpha, beta, gamma o delta) o un script que realiza un SSH a todos las estaciones (las cuatro aulas). Listado B.8: Script sshatodos-alphas.sh

5

#!/ bin / bash for i in ‘ seq -w 01 40 ‘; do echo alpha$i ssh alpha$i " $1 " done

Listado B.9: Script sshatodos-betas.sh

5

#!/ bin / bash for i in ‘ seq -w 01 40 ‘; do echo beta$i ssh beta$i " $1 " done

A. Guti´errez Mayoral

xiii

ETSI Inform´atica

B.4. SCRIPTS SSH-A-TODOS Y SCP-A-TODOS Listado B.10: Script sshatodos-gammas.sh

5

#!/ bin / bash for i in ‘ seq -w 01 40 ‘; do echo gammaa$i ssh gamma$i " $1 " done

5

#!/ bin / bash for i in ‘ seq -w 01 40 ‘; do echo deltaa$i ssh delta$i " $1 " done

Listado B.11: Script sshatodos-deltas.sh

Listado B.12: Script sshatodos.sh

5

#!/ bin / bash for i in ‘ echo alpha beta gamma delta ‘; do for j in ‘ seq -w 01 40 ‘; do echo ssh $i$j " $1 " ssh $i$j " $1 " done done

B.4.2.

Scripts scp-a-todos

Disponemos de un script que inicia una sesi´ on SCP a un laboratorio concreto (sala alpha, beta, gamma o delta) o un script que realiza un SCP a todos las estaciones (las cuatro aulas). Listado B.13: Script scpatodos-alphas.sh

5

#!/ bin / bash for j in ‘ seq -w 01 40 ‘; do echo scp $1 alpha$j : $2 scp $1 alpha$j : $2 done

5

#!/ bin / bash for j in ‘ seq -w 01 40 ‘; do echo scp $1 beta$j : $2 scp $1 beta$j : $2 done

Listado B.14: Script scpatodos-betas.sh

Listado B.15: Script scpatodos-gammas.sh

5

#!/ bin / bash for j in ‘ seq -w 01 40 ‘; do echo scp $1 gamma$j : $2 scp $1 gamma$j : $2 done

Listado B.16: Script scpatodos-deltas.sh #!/ bin / bash

Proyecto Fin de Carrera

xiv

Universidad Rey Juan Carlos

´ APENDICE B. SCRIPTS ADICIONALES

5

for j in ‘ seq -w 01 40 ‘; do echo scp $1 delta$j : $2 scp $1 delta$j : $2 done

Listado B.17: Script scpatodos.sh

5

#!/ bin / bash for i in ‘ echo alpha beta gamma delta ‘; do for j in ‘ seq -w 01 40 ‘; do echo scp $1 $i$j : $2 scp $1 $i$j : $2 done done

B.5.

Script de debilidad de contrase˜ nas

Como indicamos en el cap´ıtulo 4 (Implantaci´ on), diriamente se comprueba la debilidad de las contrase˜ nas de los usuarios, utilizando la herramienta John the Ripper. Para automatizar esta tarea, se ha desarrollado un script para cada Campus que comprueba la debilidad de las contrase˜ nas en cada una de las ramas del directorio LDAP: para los usuarios cuya cuenta se encuentra en el sub´arbol de M´ ostoles as´ı como para los que su cuenta se encuentra en el sub´arbol de Fuenlabrada. Dichos scripts tienen por nombre john-laboratorio-mostoles para el Campus de M´ ostoles y john-laboratorio-fuenla para el Laboratorio de Fuenlabrada. Listado B.18: Script john-laboratorio-mostoles #!/ bin / bash START_STOP_DAEMON =/ sbin / start - stop - daemon JOHN =/ var / local / john / john 5

FICHERO_ALERTAS =/ etc / john - alertas EMAIL_AVISO =/ etc / mail - aviso - mala - pass

10

LDAPPASSWD =/ usr / bin / ldappasswd LDIF2PASSWD =/ usr / bin / ldif2passwd . pl LDAPSEARCH =/ usr / bin / ldapsearch MAIL =/ usr / bin / mail

15

## 1) Si el argumento es ’ start ’ , ejecutamos john the ripper con el fichero ## de passwords del mismo dia ... ## 2) Si el argumento es ’ stop ’ , matamos el proceso john y reco gemos los usuarios ## de los que ha averiguado la password .

20

25

30

35

## ## ## ## ## ## ## ## ## ## ## ##

Para cada usuario devuelto , lo metemos en / etc / john - aler tas en el siguiente formato : usuario : num aviso con la siguiente regla : - Si el usuario no estaba en el fichero , introducimos - > log in :1 - Si el usuario YA estaba en el fichero , introducimos - > log in :( n +1) Procesamos el fichero / etc / john - alertas en busca de los u suarios que tengan el aviso a 3. En ese caso , se modifica aleatoriamente la password del usuario , y lo eliminamos del fichero . Para todos los usuarios restantes del fichero , se les envi a un correo adviertiendo de la situacion , con la posibilidad de que cambien su passwor d .

## ## Introduce al usuario en el fichero $FICHERO_ALERTAS

A. Guti´errez Mayoral

xv

ETSI Inform´atica

˜ B.5. SCRIPT DE DEBILIDAD DE CONTRASENAS

40

45

50

55

## Si el usuario ya estaba , aumenta su aviso en uno . ## Si el usuario no estaba , lo inicializa a cero patatero . function alerta_usuario () { if [ " ‘ cat $FICHERO_ALERTAS | grep ^ $1 ‘" != "" ]; then NUM_AVISO = ‘ cat $FICHERO_ALERTAS | grep ^ $1 | cut -d : -f2 ‘ NUM_AVISO = ‘ echo $NUM_AVISO +1 | bc ‘ TMPFILE = ‘ mktemp ‘ cat $FICHERO_ALERTAS | grep -v $1 > $TMPFILE echo $1 : $NUM_AVISO >> $TMPFILE mv $TMPFILE $FICHERO_ALERTAS else echo " $1 :1" >> $FICHERO_ALERTAS fi } ## cambia la password de un usuario a una password generada au tomaticamente . function desactiva_usuario () { PASSWORD_ALEATORIA = ‘ pwgen -N 1 -c 12 ‘ DN_USER =" uid =" $1 " , ou = usuarios , ou = escet , ou = alumnos , dc = zipi , dc = escet , dc = urjc , dc = es " $LDAPPASSWD -x -H ldaps :// peloto . escet . urjc . es -D ’ uid = agutierr , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es ’ -s $PASSWO RD_ALEATORIA -w e7ds , enua $DN_USER echo " Se desactiva la cuenta por password mala malisima ." | $ MAIL -s " Desactivacion de cuenta usuario ( mostoles ) $1 " agutierr@g syc . escet . urjc . es echo " Se desactiva la cuenta por password mala malisima ." | $ MAIL -s " Desactivacion de cuenta usuario ( mostoles ) $1 " pantuflo - cuentas anuladas@pantuflo . escet . urjc . es }

60

65

70

75

80

85

## busca en el fichero de alertas aquellos usuarios que tenga n ## el numero de avisos =3. A estos usuarios , se les cambia la pa ssword automaticamente ## no se les manda un correo , ya que no lo van a poder leer . ## Se manda correo a una lista en la que se indican las cuentas d esactivadas . function comprueba_alertas () { for line in ‘ cat $FICHERO_ALERTAS ‘; do USUARIO = ‘ echo $line | cut -d : -f1 ‘ NUM_INTENTOS = ‘ echo $line | cut -d : -f2 ‘ echo " num intentos :" $NUM_INTENTOS case $NUM_INTENTOS in "1") cat $EMAIL_AVISO | mail -s "[ laboratorios - linux - mostoles ] Primer aviso , detectada mala password " $USUARIO@pantuflo . escet . urjc . es cat $EMAIL_AVISO | mail -s "[ laboratorios - linux - mostoles ] Primer aviso , detectada mala password [ $USUARIO ]" pantuflo - cuentas - anuladas@pantuflo . escet . urjc . es cat $EMAIL_AVISO | mail -s "[ laboratorios - linux - mostoles ] Primer aviso , detectada mala password [ $USUARIO ]" agutierr@gmail . com ;; "2") cat $EMAIL_AVISO | mail -s "[ laboratorios - linux - mostoles ] Segundo aviso , detectada mala password " $USUARIO@pantuflo . escet . urjc . es cat $EMAIL_AVISO | mail -s "[ laboratorios - linux - mostoles ] Segundo aviso , detectada mala password [ $USUARIO ]" pantuflo - cuentas - anuladas@pantuflo . escet . urjc . es cat $EMAIL_AVISO | mail -s "[ laboratorios - linux - mostoles ] Segundo aviso , detectada mala password [ $USUARIO ]" agutierr@gmail . com ;; "3") ## se desactiva la cuenta del usuario desactiva_usuario $USUARIO TMPFILE = ‘ mktemp ‘ cat $FICHERO_ALERTAS | grep -v $USUARIO > $TMPFILE mv $TMPFILE $FICHERO_ALERTAS ;; esac

Proyecto Fin de Carrera

xvi

Universidad Rey Juan Carlos

´ APENDICE B. SCRIPTS ADICIONALES done 90

95

100

105

110

115

120

125

} ## Los usuarios que esten ya en el fichero de alertas y NO hayan salido en esta pasada de John , ## se les quita del fichero de Alertas . function alerta_inversa () { TMPFILE1 = ‘ mktemp ‘ for i in ‘ echo $1 ‘; do echo $i >> $TMPFILE1 done echo " Usuarios que han salido ahora :" " $1 " TMPFILE2 = ‘ mktemp ‘ for j in ‘ cat $FICHERO_ALERTAS ‘; do USER = ‘ echo $j | cut -d : -f1 ‘ echo $USER if [ " ‘ cat $TMPFILE1 | grep $USER ‘" != "" ]; then # el usuario de FICHERO_ALERTAS no ha salido en este john , lo borramos echo " Dejando al usuario en el fichero ..." echo $j >> $TMPFILE2 else echo " Quitando al usuario $j del fichero ..." fi done / bin / mv $TMPFILE2 $FICHERO_ALERTAS } ## vuelca el arbol ldap en un fichero de texto function vuelca_ldap () { TMPFILE = ‘ mktemp -p / var / tmp / john ‘ $LDAPSEARCH -x -H ldaps :// peloto . escet . urjc . es / -D ’ uid = agutierr , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es ’ -w ??????? -s children -b ’ ou = usuarios , ou = etsii , ou = alumnos , dc = zipi , dc = escet , dc = urjc , dc = es ’ ’( objectClass = posixAccount ) ’ > $TMPFILE echo $TMPFILE }

case $1 in start ) TMPFILE = ‘ mktemp -p / var / tmp / john / ‘ LDAP_FILE = ‘ vuelca_ldap ‘ cat $LDAP_FILE | $LDIF2PASSWD > $TMPFILE $START_STOP_DAEMON -- start -- make - pidfile -- pidfile / var / run / john laboratorio . pid -- background -- startas $JOHN $TMPFILE ;;

130

stop ) $START_STOP_DAEMON -- stop -- pidfile / var / run / john - labo ratorio . pid TMPFILE = ‘ mktemp -p / var / tmp / john / ‘ LDAP_FILE = ‘ vuelca_ldap ‘ cat $LDAP_FILE | $LDIF2PASSWD > $TMPFILE # zcat / var / backups / ldap / ldap - backup_ ‘ date + %Y- %m- %d ‘. gz | $LDIF2PASSWD > $TMPFILE USUARIOS_ALERTA = ‘ $JOHN - show $TMPFILE | grep ^[ a - z ] | cut - d : -f1 ‘ alerta_inversa " $USUARIOS_ALERTA " for i in ‘ echo $USUARIOS_ALERTA ‘; do alerta_usuario $i done # los usuarios del fichero $FICHERO_ALERTAS que no hayan sal ido ( se presupone que han cambiado su pass ) # son borrados del fichero ... # alerta_inversa $USUARIOS_ALERTA / bin / rm / var / local / john / john . pot / bin / rm / var / tmp / john /* ;;

135

140

145

alerta ) 150

comprueba_alertas

A. Guti´errez Mayoral

xvii

ETSI Inform´atica

˜ B.5. SCRIPT DE DEBILIDAD DE CONTRASENAS ;; esac

Listado B.19: Script john-laboratorio-fuenla #!/ bin / bash START_STOP_DAEMON =/ sbin / start - stop - daemon JOHN =/ var / local / john / john 5

FICHERO_ALERTAS =/ etc / john - alertas EMAIL_AVISO =/ etc / mail - aviso - mala - pass

10

LDAPPASSWD =/ usr / bin / ldappasswd LDIF2PASSWD =/ usr / bin / ldif2passwd . pl LDAPSEARCH =/ usr / bin / ldapsearch MAIL =/ usr / bin / mail

15

## 1) Si el argumento es ’ start ’ , ejecutamos john the ripper con el fichero ## de passwords del mismo dia ... ## 2) Si el argumento es ’ stop ’ , matamos el proceso john y reco gemos los usuarios ## de los que ha averiguado la password .

20

25

30

35

40

45

50

55

## ## ## ## ## ## ## ## ## ## ## ##

Para cada usuario devuelto , lo metemos en / etc / john - aler tas en el siguiente formato : usuario : num aviso con la siguiente regla : - Si el usuario no estaba en el fichero , introducimos - > log in :1 - Si el usuario YA estaba en el fichero , introducimos - > log in :( n +1) Procesamos el fichero / etc / john - alertas en busca de los u suarios que tengan el aviso a 3. En ese caso , se modifica aleatoriamente la password del usuario , y lo eliminamos del fichero . Para todos los usuarios restantes del fichero , se les envi a un correo adviertiendo de la situacion , con la posibilidad de que cambien su passwor d .

## ## Introduce al usuario en el fichero $FICHERO_ALERTAS ## Si el usuario ya estaba , aumenta su aviso en uno . ## Si el usuario no estaba , lo inicializa a cero patatero . function alerta_usuario () { if [ " ‘ cat $FICHERO_ALERTAS | grep ^ $1 ‘" != "" ]; then NUM_AVISO = ‘ cat $FICHERO_ALERTAS | grep ^ $1 | cut -d : -f2 ‘ NUM_AVISO = ‘ echo $NUM_AVISO +1 | bc ‘ TMPFILE = ‘ mktemp ‘ cat $FICHERO_ALERTAS | grep -v $1 > $TMPFILE echo $1 : $NUM_AVISO >> $TMPFILE mv $TMPFILE $FICHERO_ALERTAS else echo " $1 :1" >> $FICHERO_ALERTAS fi } ## cambia la password de un usuario a una password generada au tomaticamente . function desactiva_usuario () { PASSWORD_ALEATORIA = ‘ pwgen -N 1 -c 12 ‘ DN_USER =" uid =" $1 " , ou = usuarios , ou = cct , ou = alumnos , dc = zipi , dc = escet , dc = urjc , dc = es " $LDAPPASSWD -x -H ldaps :// peloto . escet . urjc . es -D ’ uid = agutierr , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es ’ -s $PASSWO RD_ALEATORIA -w e7ds , enua $DN_USER echo " Se desactiva la cuenta por password mala malisima ." | $ MAIL -s " Desactivacion de cuenta usuario ( fuenla ) $1 " agutierr@gsy c . escet . urjc . es echo " Se desactiva la cuenta por password mala malisima ." | $ MAIL -s " Desactivacion de cuenta usuario ( fuenla ) $1 " pantuflo - cuentas anuladas@pantuflo . escet . urjc . es

Proyecto Fin de Carrera

xviii

Universidad Rey Juan Carlos

´ APENDICE B. SCRIPTS ADICIONALES } 60

65

70

75

80

85

90

95

100

105

110

## busca en el fichero de alertas aquellos usuarios que tenga n ## el numero de avisos =3. A estos usuarios , se les cambia la pa ssword automaticamente ## no se les manda un correo , ya que no lo van a poder leer . ## Se manda correo a una lista en la que se indican las cuentas d esactivadas . function comprueba_alertas () { for line in ‘ cat $FICHERO_ALERTAS ‘; do USUARIO = ‘ echo $line | cut -d : -f1 ‘ NUM_INTENTOS = ‘ echo $line | cut -d : -f2 ‘ echo " num intentos :" $NUM_INTENTOS case $NUM_INTENTOS in "1") cat $EMAIL_AVISO | mail -s "[ laboratorios - linux - fuenla ] Primer aviso , detectada mala password " $USUARIO@bilo . cct . urjc . es cat $EMAIL_AVISO | mail -s "[ laboratorios - linux - fuenla ] Primer aviso , detectada mala password [ $USUARIO ]" pantuflo - cuentas - anuladas@pantuflo . escet . urjc . es cat $EMAIL_AVISO | mail -s "[ laboratorios - linux - fuenla ] Primer aviso , detectada mala password [ $USUARIO ]" agutierr@gmail . com ;; "2") cat $EMAIL_AVISO | mail -s "[ laboratorios - linux - fuenla ] Segundo aviso , detectada mala password " $USUARIO@bilo . cct . urjc . es cat $EMAIL_AVISO | mail -s "[ laboratorios - linux - fuenla ] Segundo aviso , detectada mala password [ $USUARIO ]" pantuflo - cuentas - anuladas@pantuflo . escet . urjc . es cat $EMAIL_AVISO | mail -s "[ laboratorios - linux - fuenla ] Segundo aviso , detectada mala password [ $USUARIO ]" agutierr@gmail . com ;; "3") ## se desactiva la cuenta del usuario desactiva_usuario $USUARIO TMPFILE = ‘ mktemp ‘ cat $FICHERO_ALERTAS | grep -v $USUARIO > $TMPFILE mv $TMPFILE $FICHERO_ALERTAS ;; esac done } ## Los usuarios que esten ya en el fichero de alertas y NO hayan salido en esta pasada de John , ## se les quita del fichero de Alertas . function alerta_inversa () { TMPFILE1 = ‘ mktemp ‘ for i in ‘ echo $1 ‘; do echo $i >> $TMPFILE1 done echo " Usuarios que han salido ahora :" " $1 " TMPFILE2 = ‘ mktemp ‘ for j in ‘ cat $FICHERO_ALERTAS ‘; do USER = ‘ echo $j | cut -d : -f1 ‘ echo $USER if [ " ‘ cat $TMPFILE1 | grep $USER ‘" != "" ]; then # el usuario de FICHERO_ALERTAS no ha salido en este john , lo borramos echo " Dejando al usuario en el fichero ..." echo $j >> $TMPFILE2 else echo " Quitando al usuario $j del fichero ..." fi done / bin / mv $TMPFILE2 $FICHERO_ALERTAS

A. Guti´errez Mayoral

xix

ETSI Inform´atica

˜ B.5. SCRIPT DE DEBILIDAD DE CONTRASENAS

115

120

125

} ## vuelca el arbol ldap en un fichero de texto function vuelca_ldap () { TMPFILE = ‘ mktemp -p / var / tmp / john ‘ $LDAPSEARCH -x -H ldaps :// peloto . escet . urjc . es / -D ’ uid = agutierr , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es ’ -w ??????? -s children -b ’ ou = usuarios , ou = cct , ou = alumnos , dc = zipi , dc = escet , dc = urjc , dc = es ’ ’( objectClass = posixAccount ) ’ > $TMPFILE echo $TMPFILE }

case $1 in start ) TMPFILE = ‘ mktemp -p / var / tmp / john / ‘ LDAP_FILE = ‘ vuelca_ldap ‘ cat $LDAP_FILE | $LDIF2PASSWD > $TMPFILE $START_STOP_DAEMON -- start -- make - pidfile -- pidfile / var / run / john laboratorio . pid -- background -- startas $JOHN $TMPFILE ;;

130

stop ) $START_STOP_DAEMON -- stop -- pidfile / var / run / john - labo ratorio . pid TMPFILE = ‘ mktemp -p / var / tmp / john / ‘ LDAP_FILE = ‘ vuelca_ldap ‘ cat $LDAP_FILE | $LDIF2PASSWD > $TMPFILE # zcat / var / backups / ldap / ldap - backup_ ‘ date + %Y- %m- %d ‘. gz | $LDIF2PASSWD > $TMPFILE USUARIOS_ALERTA = ‘ $JOHN - show $TMPFILE | grep ^[ a - z ] | cut - d : -f1 ‘ alerta_inversa " $USUARIOS_ALERTA " for i in ‘ echo $USUARIOS_ALERTA ‘; do alerta_usuario $i done # los usuarios del fichero $FICHERO_ALERTAS que no hayan sal ido ( se presupone que han cambiado su pass ) # son borrados del fichero ... # alerta_inversa $USUARIOS_ALERTA / bin / rm / var / local / john / john . pot / bin / rm / var / tmp / john /* ;;

135

140

145

alerta ) comprueba_alertas ;;

150

esac

Proyecto Fin de Carrera

xx

Universidad Rey Juan Carlos

´ Apendice

C

Ficheros de configuraci´on Por u ´ltimo, incluiremos en este ap´endice los ficheros de configuraci´ on de aquellos servicios que hemos considerado m´ as importantes. Para agrupar estos ficheros de configuraci´ on, realizaremos una clasificaci´on en primer lugar a nivel de m´ aquina donde se alojan y en segundo lugar, en cuanto al servicio que prestan.

xxi

´ C.1. MAQUINAS ZIPI Y ZAPE

C.1.

M´ aquinas zipi y zape

Las m´ aquinas zipi y zape son servidores secundarios LDAP y a la vez, sirven el mapa del dominio .pantuflo.es, como ya vimos en el cap´ıtulo Implantaci´ on. Como ya vimos, el servidor DNS primario se aloja en la m´ aquina zipi y el secundario en la m´ aquina zape.

C.1.1.

Servidor LDAP. Fichero slapd.conf Listado C.1: Fichero de configuraci´ on /etc/ldap/slapd.conf

# This is the main slapd configuration file . See slapd . conf (5) for more # info on the configuration options .

5

####################################################################### # Global Directives : # Features to permit # allow bind_v2

10

15

# Schema and objectClass definitions include / etc / ldap / schema / core . schema include / etc / ldap / schema / cosine . schema include / etc / ldap / schema / nis . schema include / etc / ldap / schema / inetorgperson . schema include / etc / ldap / schema / pantufloperson . schema # Where the pid file is put . The init . d script # will not stop the server if you change this . pidfile / var / run / slapd / slapd . pid

20

# List of arguments that were passed to the server argsfile / var / run / slapd / slapd . args

25

# Read slapd . conf (5) for possible values loglevel 0 # Where the dynamically loaded modules are stored modulepath / usr / lib / ldap moduleload back_bdb

30

# The maximum number of entries that is returned for a search o peration sizelimit 500

35

40

45

# The tool - threads parameter sets the actual amount of cpu ’ s that is used # for indexing . tool - threads 1 ####################################################################### # Specific Backend Directives for bdb : # Backend specific directives apply to this backend until an other # ’ backend ’ directive occurs backend bdb checkpoint 512 30 ####################################################################### # Specific Backend Directives for ’ other ’: # Backend specific directives apply to this backend until an other # ’ backend ’ directive occurs # backend < other >

50

55

####################################################################### # Specific Directives for database #1 , of type bdb : # Database specific directives apply to this databasse unti l another # ’ database ’ directive occurs database bdb # The base of your directory in database #1

Proyecto Fin de Carrera

xxii

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION suffix 60

65

" dc = zipi , dc = escet , dc = urjc , dc = es "

# rootdn directive for specifying a superuser on the databas e . This is needed # for syncrepl . # rootdn " cn = admin , dc = zipi , dc = escet , dc = urjc , dc = es " # Where the database file are physically stored for database #1 directory "/ var / lib / ldap " # For the Debian package we use 2 MB as default but be sure to upd ate this # value if you have plenty of RAM dbconfig set_cachesize 0 2097152 0

70

# Sven Hartge reported that he had to set this value incredibl y high # to get slapd running at all . See http :// bugs . debian . org /3 03057 # for more information . 75

80

# Number dbconfig # Number dbconfig # Number dbconfig

of objects that can be locked at the same time . set_lk_max_objects 1500 of locks ( both requested and granted ) set_lk_max_locks 1500 of lockers set_lk_max_lockers 1500

# Indexing options for database #1 index objectClass eq 85

# Save the time that the entry gets modified , for database #1 lastmod on # Where to store the replica logs for database #1 # replogfile / var / lib / ldap / replog

90

95

100

105

110

# # # # #

The userPassword by default can be changed by the entry owning it if they are authenticated . Others should not be able to see it , except the admin entry below These access lines apply to database #1 only

# Ensure read access to the base for things like # s u p p o r t e d S A S L M e c h a n i s m s . Without this you may # have problems with SASL not knowing what # mechanisms are available and the like . # Note that this is covered by the ’ access to * ’ # ACL below too but if you change that as people # are wont to do you ’ ll still need this if you # want SASL ( and possible other things ) to work # happily . # access to dn . base ="" by * read # The admin dn has full write access , everyone else # can read everything . # access to * # by dn =" cn = admin , dc = zipi , dc = escet , dc = urjc , dc = es " writ e # by * read access to dn . base ="" by * read

115

access to * by dn = cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es write by * read

120

125

# The admin dn has full write access , everyone else # can read everything . access to * by dn =" cn = admin , dc = zipi , dc = escet , dc = urjc , dc = es " write by * read access to attrs = userPassword , shadowLastChange by dn =" cn = admin , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = tgonzale , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write

A. Guti´errez Mayoral

xxiii

ETSI Inform´atica

´ C.1. MAQUINAS ZIPI Y ZAPE by dn =" uid = cespedes , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = llopez , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = kleal , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = ceaguero , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = asantos , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = agutierr , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jcenteno , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = mortuno , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = grex , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = vmo , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jmplaza , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jgb , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = fmartin , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = aleonar , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = nemo , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = barrera , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jmrecio , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jferrer , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = acs , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = anto , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = eva , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = pheras , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = esoriano , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = lrodero , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jfs , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by anonymous auth by self write by * none

130

135

140

145

150

155

160

# For Netscape Roaming support , each user gets a roaming # profile for which they have write access to # access to dn =".* , ou = Roaming , o = morsnet " # by dn =" cn = admin , dc = zipi , dc = escet , dc = urjc , dc = es " writ e # by dnattr = owner write

165

####################################################################### # Specific Directives for database #2 , of type ’ other ’ ( can be bdb too ) : # Database specific directives apply to this databasse unti l another # ’ database ’ directive occurs # database < other >

170

# The base of your directory for database #2 # suffix " dc = debian , dc = org " #

175

TLSCipherSuite HIGH : MEDIUM : - SSLv2 T L S C A C e r t i f i c a t e F i l e / etc / ldap / ssl / server . pem TLSCertificateFile / etc / ldap / ssl / server . pem T L S C e r t i f i c a t e K e y F i l e / etc / ldap / ssl / server . pem sizelimit -1

180

updatedn " cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es " updateref ldaps :// peloto . escet . urjc . es

C.1.2.

Servidor DNS. Fichero named.conf y db.pantuflo.es para zipi Listado C.2: Fichero de configuraci´ on /etc/bind9/named.conf

// This is the primary configuration file for the BIND DNS ser ver named . //

Proyecto Fin de Carrera

xxiv

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION

5

// // // // //

Please read / usr / share / doc / bind9 / README . Debian . gz for information on the structure of BIND configuration files in Debian , * BEFORE * you customize this configuration file . If you are just adding zones , please do that in / etc / bind / n amed . conf . local

include "/ etc / bind / named . conf . options "; 10

15

20

25

30

35

// prime the server with knowledge of the root servers zone "." { type hint ; file "/ etc / bind / db . root "; }; zone " gsyc . info " { type slave ; masters { 193.147.71.64; }; file "/ etc / bind9 / db . gsyc . info . slave "; }; zone " dat . escet . urjc . es " { type slave ; masters { 193.147.71.64; }; file "/ etc / bind9 / db . dat . escet . urjc . es . slave "; }; zone " gsyc . es " { type slave ; masters { 193.147.71.64; }; file "/ etc / bind9 / db . gsyc . es . slave "; }; zone " ditte . es " { type slave ; masters { 193.147.71.64; }; file "/ etc / bind9 / db . ditte . es . slave "; };

40

45

50

55

60

65

70

zone " ladyr . es " { type slave ; masters { 193.147.71.64; }; file "/ etc / bind9 / db . ladyr . es . slave "; };

// be authoritative for the localhost forward and reverse zones , and for // broadcast zones as per RFC 1912 zone " localhost " { type master ; file "/ etc / bind / db . local "; }; zone "127. in - addr . arpa " { type master ; file "/ etc / bind / db .127"; }; zone "0. in - addr . arpa " { type master ; file "/ etc / bind / db .0"; }; zone "255. in - addr . arpa " { type master ; file "/ etc / bind / db .255"; };

A. Guti´errez Mayoral

xxv

ETSI Inform´atica

´ C.1. MAQUINAS ZIPI Y ZAPE

75

zone " pantuflo . es " { type master ; file "/ etc / bind9 / db . pantuflo . es "; };

80

// logging { // category lame - servers { null ; }; //};

85

logging { channel " querylog " { file "/ var / log / bind9 - query . log "; print - time yes ; }; category queries { querylog ; }; }; // zone " com " { type delegation - only ; }; // zone " net " { type delegation - only ; };

90

95

100

// From the release notes : // Because many of our users are uncomfortable receiving und elegated answers // from root or top level domains , other than a few for whom that behaviour // has been trusted and expected for quite some length of time , we have now // introduced the " root - delegations - only " feature which a pplies delegation - only // logic to all top level domains , and to the root domain . An ex ception list // should be specified , including " MUSEUM " and " DE " , and any other top level // domains from whom undelegated responses are expected and trusted . // root - delegation - only exclude { " DE "; " MUSEUM "; }; include "/ etc / bind / named . conf . local ";

Listado C.3: Fichero de configuraci´ on /etc/bind9/db.pantuflo.es ; ; ; ;

/ var / named / db . gsyc . info datos de la zona pantuflo . es

( @ = gsyc . info . )

5

10

15

pantuflo . es . IN SOA ns0 . pantuflo . es . agutierr . pantuflo . es . ( 2007037912 ; Serial 28800 ; Refresh 8 horas 7200 ; Retry 2 horas 604800 ; Expire 1 semana 86400 ) ; Minimum ttl 1 dia

pantuflo . es . pantuflo . es .

IN NS IN NS

ns0 . pantuflo . es . ns1 . pantuflo . es .

ns0 ns1 @

IN A IN A IN A

212.128.4.2 212.128.4.3 212.128.4.4

; pantuflo . es .

IN MX

10 pantuflo . es .

; servidores zipi zape jaimita sapientin peloto lechuzo minervo pildorin espatula hydra leviatan

IN IN IN IN IN IN IN IN IN IN IN

212.128.4.2 212.128.4.3 212.128.4.5 212.128.4.6 212.128.4.7 212.128.4.8 212.128.4.9 212.128.4.10 212.128.4.12 193.147.73.53 212.128.4.120

20

25

30

35

A A A A A A A A A A A

auditoria . pantuflo . es .

Proyecto Fin de Carrera

IN A

212.128.4.12

xxvi

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION

40

45

50

55

60

65

70

75

80

85

90

95

100

105

; aliases www ftp webmail pop3 smtp mysql subversion trac

IN IN IN IN IN IN IN IN

CNAME CNAME CNAME CNAME CNAME CNAME CNAME CNAME

pantuflo . es . pantuflo . es . pantuflo . es . pantuflo . es . pantuflo . es . pantuflo . es . pantuflo . es . pantuflo . es .

; Mirrors de Debian y Ubuntu ubuntu IN CNAME debian IN CNAME

peloto . pantuflo . es . peloto . pantuflo . es .

wiki . pantuflo . es .

212.128.4.4

IN A

; Laboratorios docentes ; Estaciones alpha01 IN A alpha02 IN A alpha03 IN A alpha04 IN A alpha05 IN A alpha06 IN A alpha07 IN A alpha08 IN A alpha09 IN A alpha10 IN A alpha11 IN A alpha12 IN A alpha13 IN A alpha14 IN A alpha15 IN A alpha16 IN A alpha17 IN A alpha18 IN A alpha19 IN A alpha20 IN A alpha21 IN A alpha22 IN A alpha23 IN A alpha24 IN A alpha25 IN A alpha26 IN A alpha27 IN A alpha28 IN A alpha29 IN A alpha30 IN A alpha31 IN A alpha32 IN A alpha33 IN A alpha34 IN A alpha35 IN A alpha36 IN A alpha37 IN A alpha38 IN A alpha39 IN A alpha40 IN A beta01 IN A beta02 IN A beta03 IN A beta04 IN A beta05 IN A beta06 IN A beta07 IN A beta08 IN A beta09 IN A beta10 IN A beta11 IN A

212.128.4.251 212.128.4.172 212.128.4.173 212.128.4.174 212.128.4.175 212.128.4.176 212.128.4.177 212.128.4.178 212.128.4.179 212.128.4.180 212.128.4.181 212.128.4.182 212.128.4.183 212.128.4.184 212.128.4.185 212.128.4.186 212.128.4.187 212.128.4.188 212.128.4.189 212.128.4.190 212.128.4.191 212.128.4.192 212.128.4.193 212.128.4.194 212.128.4.195 212.128.4.196 212.128.4.197 212.128.4.198 212.128.4.199 212.128.4.200 212.128.4.201 212.128.4.202 212.128.4.203 212.128.4.204 212.128.4.115 212.128.4.116 212.128.4.117 212.128.4.118 212.128.4.119 212.128.4.210 212.128.4.131 212.128.4.132 212.128.4.133 212.128.4.134 212.128.4.135 212.128.4.136 212.128.4.137 212.128.4.138 212.128.4.139 212.128.4.140 212.128.4.141

A. Guti´errez Mayoral

xxvii

ETSI Inform´atica

´ C.1. MAQUINAS ZIPI Y ZAPE

110

115

120

125

130

135

140

145

150

155

160

165

170

175

beta12 beta13 beta14 beta15 beta16 beta17 beta18 beta19 beta20 beta21 beta22 beta23 beta24 beta25 beta26 beta27 beta28 beta29 beta30 beta31 beta32 beta33 beta34 beta35 beta36 beta37 beta38 beta39 beta40 gamma01 gamma02 gamma03 gamma04 gamma05 gamma06 gamma07 gamma08 gamma09 gamma10 gamma11 gamma12 gamma13 gamma14 gamma15 gamma16 gamma17 gamma18 gamma19 gamma20 gamma21 gamma22 gamma23 gamma24 gamma25 gamma26 gamma27 gamma28 gamma29 gamma30 gamma31 gamma32 gamma33 gamma34 gamma35 gamma36 gamma37 gamma38 gamma39 gamma40 delta01

IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN

A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A

212.128.4.142 212.128.4.143 212.128.4.144 212.128.4.145 212.128.4.146 212.128.4.147 212.128.4.148 212.128.4.149 212.128.4.150 212.128.4.151 212.128.4.152 212.128.4.153 212.128.4.154 212.128.4.155 212.128.4.156 212.128.4.157 212.128.4.158 212.128.4.159 212.128.4.160 212.128.4.161 212.128.4.162 212.128.4.163 212.128.4.164 212.128.4.165 212.128.4.166 212.128.4.167 212.128.4.168 212.128.4.169 212.128.4.170 212.128.4.211 212.128.4.212 212.128.4.213 212.128.4.214 212.128.4.215 212.128.4.216 212.128.4.217 212.128.4.218 212.128.4.219 212.128.4.220 212.128.4.221 212.128.4.222 212.128.4.223 212.128.4.224 212.128.4.225 212.128.4.226 212.128.4.227 212.128.4.228 212.128.4.229 212.128.4.230 212.128.4.231 212.128.4.232 212.128.4.233 212.128.4.234 212.128.4.235 212.128.4.236 212.128.4.237 212.128.4.238 212.128.4.239 212.128.4.240 212.128.4.241 212.128.4.242 212.128.4.243 212.128.4.244 212.128.4.245 212.128.4.246 212.128.4.247 212.128.4.248 212.128.4.249 212.128.4.250 212.128.4.61

Proyecto Fin de Carrera

xxviii

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION

180

185

190

195

200

205

210

215

220

225

230

235

240

245

delta02 IN delta03 IN delta04 IN delta05 IN delta06 IN delta07 IN delta08 IN delta09 IN delta10 IN delta11 IN delta12 IN delta13 IN delta14 IN delta15 IN delta16 IN delta17 IN delta18 IN delta19 IN delta20 IN delta21 IN delta22 IN delta23 IN delta24 IN delta25 IN delta26 IN delta27 IN delta28 IN delta29 IN delta30 IN delta31 IN delta32 IN delta33 IN delta34 IN delta35 IN delta36 IN delta37 IN delta38 IN delta39 IN delta40 IN epsilon01 epsilon02 epsilon03 epsilon04 epsilon05 epsilon06 epsilon07 epsilon08 epsilon09 epsilon10 epsilon11 epsilon12 epsilon13 epsilon14 epsilon15 epsilon16 epsilon17 epsilon18 epsilon19 epsilon20 epsilon21 epsilon22 epsilon23 epsilon24 epsilon25 epsilon26 epsilon27 epsilon28 epsilon29 epsilon30 epsilon31

A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A

212.128.4.62 212.128.4.63 212.128.4.64 212.128.4.65 212.128.4.66 212.128.4.67 212.128.4.68 212.128.4.69 212.128.4.70 212.128.4.71 212.128.4.72 212.128.4.73 212.128.4.74 212.128.4.75 212.128.4.76 212.128.4.77 212.128.4.78 212.128.4.79 212.128.4.80 212.128.4.81 212.128.4.82 212.128.4.83 212.128.4.84 212.128.4.85 212.128.4.86 212.128.4.87 212.128.4.88 212.128.4.89 212.128.4.90 212.128.4.49 212.128.4.50 212.128.4.51 212.128.4.52 212.128.4.53 212.128.4.54 212.128.4.55 212.128.4.56 212.128.4.57 212.128.4.58 IN A 193.147.73.56 IN A 193.147.73.57 IN A 193.147.73.58 IN A 193.147.73.59 IN A 193.147.73.60 IN A 193.147.73.61 IN A 193.147.73.62 IN A 193.147.73.63 IN A 193.147.73.64 IN A 193.147.73.65 IN A 193.147.73.66 IN A 193.147.73.67 IN A 193.147.73.68 IN A 193.147.73.69 IN A 193.147.73.70 IN A 193.147.73.71 IN A 193.147.73.72 IN A 193.147.73.73 IN A 193.147.73.74 IN A 193.147.73.75 IN A 193.147.73.76 IN A 193.147.73.77 IN A 193.147.73.78 IN A 193.147.73.79 IN A 193.147.73.80 IN A 193.147.73.81 IN A 193.147.73.82 IN A 193.147.73.83 IN A 193.147.73.84 IN A 193.147.73.85 IN A 193.147.73.86

A. Guti´errez Mayoral

xxix

ETSI Inform´atica

´ C.1. MAQUINAS ZIPI Y ZAPE

250

255

260

265

270

275

280

285

290

295

epsilon32 epsilon33 epsilon34 epsilon35 epsilon36 epsilon37 epsilon38 epsilon39 epsilon40 epsilon41 zeta01 IN zeta02 IN zeta03 IN zeta04 IN zeta05 IN zeta06 IN zeta07 IN zeta08 IN zeta09 IN zeta10 IN zeta11 IN zeta12 IN zeta13 IN zeta14 IN zeta15 IN zeta16 IN zeta17 IN zeta18 IN zeta19 IN zeta20 IN zeta21 IN zeta22 IN zeta23 IN zeta24 IN zeta25 IN zeta26 IN zeta27 IN zeta28 IN zeta29 IN zeta30 IN zeta31 IN zeta32 IN zeta33 IN zeta34 IN zeta35 IN zeta36 IN zeta37 IN zeta38 IN zeta39 IN zeta40 IN zeta41 IN

A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A

IN A 193.147.73.87 IN A 193.147.73.88 IN A 193.147.73.89 IN A 193.147.73.90 IN A 193.147.73.91 IN A 193.147.73.92 IN A 193.147.73.93 IN A 193.147.73.94 IN A 193.147.73.95 IN A 193.147.73.96 193.147.73.97 193.147.73.98 193.147.73.99 193.147.73.100 193.147.73.101 193.147.73.102 193.147.73.103 193.147.73.104 193.147.73.105 193.147.73.106 193.147.73.107 193.147.73.108 193.147.73.109 193.147.73.110 193.147.73.111 193.147.73.112 193.147.73.113 193.147.73.114 193.147.73.115 193.147.73.116 193.147.73.117 193.147.73.118 193.147.73.119 193.147.73.120 193.147.73.121 193.147.73.122 193.147.73.123 193.147.73.124 193.147.73.125 193.147.73.126 193.147.73.127 193.147.73.128 193.147.73.129 193.147.73.130 193.147.73.131 193.147.73.132 193.147.73.133 193.147.73.134 193.147.73.135 193.147.73.136 193.147.73.137

300

; seminario 5 de fuenla ( laboratorio SSOO )

305

310

315

theta01 theta02 theta03 theta04 theta05 theta06 theta07 theta08 theta09 theta10 theta11 theta12 theta13 theta14 theta15

IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN

A A A A A A A A A A A A A A A

193.147.57.71 193.147.57.72 193.147.57.73 193.147.57.74 193.147.57.75 193.147.57.76 193.147.57.77 193.147.57.78 193.147.57.79 193.147.57.80 193.147.57.81 193.147.57.82 193.147.57.83 193.147.57.84 193.147.57.85

Proyecto Fin de Carrera

xxx

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION

320

theta16 theta17 theta18 theta19 theta20

C.1.3.

IN IN IN IN IN

A A A A A

193.147.57.86 193.147.57.87 193.147.57.88 193.147.57.89 193.147.57.90

Servidor DNS. Fichero named.conf para zape Listado C.4: Fichero de configuraci´ on /etc/bind9/named.conf

5

// // // // // // //

This is the primary configuration file for the BIND DNS ser ver named . Please read / usr / share / doc / bind9 / README . Debian . gz for information on the structure of BIND configuration files in Debian , * BEFORE * you customize this configuration file . If you are just adding zones , please do that in / etc / bind / n amed . conf . local

include "/ etc / bind / named . conf . options "; 10

15

// prime the server with knowledge of the root servers zone "." { type hint ; file "/ etc / bind / db . root "; }; // be authoritative for the localhost forward and reverse zones , and for // broadcast zones as per RFC 1912

20

zone " localhost " { type master ; file "/ etc / bind / db . local "; };

25

zone "127. in - addr . arpa " { type master ; file "/ etc / bind / db .127"; };

30

zone "0. in - addr . arpa " { type master ; file "/ etc / bind / db .0"; };

35

zone "255. in - addr . arpa " { type master ; file "/ etc / bind / db .255"; };

40

zone " pantuflo . es " { type slave ; file "/ etc / bind9 / db . pantuflo . es "; masters { 212.128.4.2; }; };

45

logging { category lame - servers { null ; }; }; 50

// zone " com " { type delegation - only ; }; // zone " net " { type delegation - only ; };

55

// From the release notes : // Because many of our users are uncomfortable receiving und elegated answers // from root or top level domains , other than a few for whom that behaviour // has been trusted and expected for quite some length of time , we have now

A. Guti´errez Mayoral

xxxi

ETSI Inform´atica

´ C.2. MAQUINA PANTUFLO

60

// introduced the " root - delegations - only " feature which a pplies delegation - only // logic to all top level domains , and to the root domain . An ex ception list // should be specified , including " MUSEUM " and " DE " , and any other top level // domains from whom undelegated responses are expected and trusted . // root - delegation - only exclude { " DE "; " MUSEUM "; }; include "/ etc / bind / named . conf . local ";

M´ aquina pantuflo

C.2.

Los servicios m´ as importantes que se sirven en la m´ aquina pantuflo son la p´agina web del Laboratorio, las p´aginas web de los alumnos, el correo de las cuentas @pantuflo.escet.urjc.es y el servicio MySQL (que no ha sido estudiado en este documento).

C.2.1.

Fichero de configuraci´ on de Apache

Los ficheros de configuraci´ on de sitios para Apache en la versi´ on 2, se encuentran situados bajo el directorio /etc/apache2/sites-enabled. Listado C.5: Fichero de configuraci´ on /etc/apache2/sites-enabled/pantuflo.es

5

10

< VirtualHost 212.128.4.4:80 > ServerAdmin agutierr@gsyc . escet . urjc . es ServerName pantuflo . es ReWriteEngine On RewriteRule ^/(.*) http :// pantuflo . escet . urjc . es / $1 [L , R ] < VirtualHost 212.128.4.4:443 > ServerAdmin agutierr@gsyc . escet . urjc . es ServerName pantuflo . es RewriteRule ^/(.*) https :// pantuflo . escet . urjc . es / $1 [ L , R ]

Listado C.6: Fichero de configuraci´ on /etc/apache2/sites-enabled/pantuflo.escet.urjc.es

5

10

15

< VirtualHost 212.128.4.4:80 > ServerAdmin agutierr@gsyc . escet . urjc . es ServerName pantuflo . escet . urjc . es DocumentRoot / var / www / wikipantuflo / < Directory / > Options FollowSymLinks AllowOverride None < Directory / var / www / wikipantuflo / > Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow , deny allow from all # This directive allows us to have apache2 ’ s default start page # in / apache2 - default / , but still have / go to the right place

20

25

ScriptAlias / cgi - bin / / usr / lib / cgi - bin / < Directory "/ usr / lib / cgi - bin " > AllowOverride None Options ExecCGI - MultiViews + S y m L i n k s I f O w n e r M a t c h Order allow , deny Allow from all

Proyecto Fin de Carrera

xxxii

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION CustomLog / var / log / apache2 / pantuflo . escet . urjc . es / ac cess . log combined ErrorLog / var / log / apache2 / pantuflo . escet . urjc . es / err or . log 30

# Possible values include : debug , info , notice , warn , error , crit , # alert , emerg . LogLevel warn ServerSignature On

35

Alias / webmail / var / www / webmail / Alias / tablas . css / var / www / tablas . css Alias / imagenes_parte / var / www / parte / imagenes_parte / 40

45

50

55

60

Redirect http :// pantuflo . escet . urjc . es / admin https :// pantuflo . escet . urjc . es / admin / # Host con SSL < VirtualHost 212.128.4.4:443 > ServerAdmin agutierr@gsyc . escet . urjc . es ServerName pantuflo . escet . urjc . es SSLEngine On SSLCertificateFile / etc / apache2 / ssl / certificado - pant uflo . escet . urjc . es . pem DocumentRoot / var / www / wikipantuflo / < Directory / > Options FollowSymLinks AllowOverride None < Directory / var / www / wikipantuflo / > Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow , deny allow from all # This directive allows us to have apache2 ’ s default start page # in / apache2 - default / , but still have / go to the right place

65

70

ScriptAlias / cgi - bin / / usr / lib / cgi - bin / < Directory "/ usr / lib / cgi - bin " > AllowOverride None Options ExecCGI - MultiViews + S y m L i n k s I f O w n e r M a t c h Order allow , deny Allow from all ErrorLog / var / log / apache2 / error . log

75

# Possible values include : debug , info , notice , warn , error , crit , # alert , emerg . LogLevel warn CustomLog / var / log / apache2 / access . log combined ServerSignature On

80

85

90

95

Alias Alias Alias Alias Alias

/ webmail / var / www / webmail / / admin / var / www / admin / / nagios / cgi - bin / usr / lib / cgi - bin / nagios / / nagios / stylesheets / etc / nagios / stylesheets / nagios / usr / share / nagios / htdocs

< Directory / var / www / admin > AllowOverride None Options ExecCGI - MultiViews + S y m L i n k s I f O w n e r M a t c h Order allow , deny Allow from all < Directory / usr / lib / cgi - bin / nagios > Options ExecCGI

A. Guti´errez Mayoral

xxxiii

ETSI Inform´atica

´ C.2. MAQUINA PANTUFLO AllowOverride AuthConfig Order Allow , Deny Allow From All 100

105

AuthName " Servidor Nagios de Pantuflo " AuthType Basic AuthUserFile / etc / nagios / htpasswd . users require valid - user < Directory / usr / share / nagios / htdocs > Options FollowSymLinks

110

115

AllowOverride AuthConfig Order Allow , Deny Allow From All AuthName " Servidor Nagios de Pantuflo " AuthType Basic AuthUserFile / etc / nagios / htpasswd . users require valid - user

120



Listado C.7: Fichero de configuraci´ on /etc/apache2/sites-enabled/webmail.pantuflo.es

5

10

< VirtualHost 212.128.4.4:80 > ServerAdmin agutierr@gsyc . escet . urjc . es ServerName webmail . pantuflo . es ReWriteEngine On RewriteRule ^/(.*) https :// webmail . pantuflo . es / $1 [L , R ] < VirtualHost 212.128.4.4:443 > ServerAdmin agutierr@gsyc . escet . urjc . es ServerName webmail . pantuflo . es SSLEngine On SSLCertificateFile / etc / apache2 / ssl / certificado - webm ail . pantuflo . es . pem DocumentRoot / var / www / webmail /

Listado C.8: Fichero de configuraci´ on /etc/apache2/sites-enabled/mysql.pantuflo.es

5

10

15

20

< VirtualHost 212.128.4.4:80 > ServerName mysql . pantuflo . es ServerAdmin agutierr@gsyc . escet . urjc . es RewriteEngine on RewriteRule ^/(.*) https :// mysql . pantuflo . es / $1 [L , R ] < VirtualHost 212.128.4.4:443 > ServerName mysql . pantuflo . es ServerAdmin agutierr@gsyc . escet . urjc . es DocumentRoot / usr / share / phpmyadmin / SSLEngine On SSLCertificateFile / etc / apache2 / ssl / certificado - mysq l . pantuflo . es . pem < Directory / usr / share / phpmyadmin / > AllowOverride All < Directory / var / www / phpmyadmin / > AllowOverride All < Directory / var / lib / phpmyadmin / >

Proyecto Fin de Carrera

xxxiv

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION

25

30

Options - FollowSymLinks AllowOverride None Order deny , allow Deny from all < Directory / usr / share / phpmyadmin / config / > Options - FollowSymLinks AllowOverride None Order deny , allow Deny from all

35

40

< Directory / var / www / phpmyadmin / config / > Options - FollowSymLinks AllowOverride None Order deny , allow Deny from all ErrorLog / var / log / apache2 / mysql . pantuflo . es / error . log LogLevel warn CustomLog / var / log / apache2 / mysql . pantuflo . es / access . log combined

45



C.2.2.

Fichero de configuraci´ on de Postfix

Los ficheros de configuraci´ on m´ as importantes de Postfix se encuentran situados en los ficheros /etc/postfix/main.cf y /etc/postfix/master.cf. Listado C.9: Fichero de configuraci´ on /etc/postfix/main.cf # See / usr / share / postfix / main . cf . dist for a commented , more complete version smtpd_banner = $myhostname ESMTP $mail_name ( Debian / GNU ) biff = no 5

# appending . domain is the MUA ’ s job . append_dot_mydomain = no

10

15

20

25

# Uncomment the next line to generate " delayed mail " warning s # delay_warning_time = 4 h myhostname = pantuflo alias_maps = hash :/ etc / aliases alias_database = hash :/ etc / aliases myorigin = / etc / mailname mydestination = pantuflo . escet . urjc . es , pantuflo , local host . localdomain , localhost , pantuflo . es relayhost = mynetworks = 127.0.0.0/8 , 212.128.4.0/24 , 193.147.65.0/ 24 mailbox_command = procmail -d mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all # s m t p d _ s a s l _ a u t h _ e n a b l e = yes # b r o k e n _ s a s l _ a u t h _ c l i e n t s = yes # s m t p d _ s a s l _ a p p l i c a t i o n _ n a m e = smtpd # s m t p d _ r e c i p i e n t _ r e s t r i c t i o n s = permit_sasl_authentic ated , permit_mynetworks , reject_unauth_destination # s m t p d _ s a s l _ s e c u r i t y _ o p t i o n s = noanonymous # s m t p d _ s a s l _ l o c a l _ d o m a i n = $myhostname

30

# s m t p d _ s a s l _ a u t h _ e n a b l e = yes

A. Guti´errez Mayoral

xxxv

ETSI Inform´atica

´ C.2. MAQUINA PANTUFLO

35

40

# s m t p d _ s a s l _ a u t h e n t i c a t e d _ h e a d e r = yes # s m t p d _ s a s l _ a p p l i c a t i o n _ n a m e = smtpd # smtpd_sasl_path = private / auth smtpd_recipient_restrictions = permit_mynetworks , check_client_access hash :/ var / lib / pop - before - smtp / hosts , reject_unauth_destination , check_relay_domains

Listado C.10: Fichero de configuraci´ on /etc/postfix/master.cf

5

10

15

20

25

30

35

40

45

50

55

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

Postfix master process configuration file . Each logical line describes how a Postfix daemon program should be run . A logical line starts with non - whitespace , non - comment text . Empty lines and whitespace - only lines are ignored , as are c omment lines whose first non - whitespace character is a ‘# ’. A line that starts with whitespace continues a logical line . The fields that make up each line are described below . A " -" f ield value requests that a default value be used for that field . Service : any name that is valid for the specified transport type ( the next field ) . With INET transports , a service is specif ied as host : port . The host part ( and colon ) may be omitted . Either host or port may be given in symbolic form or in numeric form . Exam ples for the SMTP server : localhost : smtp receives mail via the l oopback interface only ; 10025 receives mail on port 10025. Transport type : " inet " for Internet sockets , " unix " for UNIX - domain sockets , " fifo " for named pipes . Private : whether or not access is restricted to the mail sys tem . Default is private service . Internet ( inet ) sockets can ’ t be private . Unprivileged : whether the service runs with root privileg es or as the owner of the Postfix system ( the owner name is controlle d by the mail_owner configuration variable in the main . cf file ) . Only the pipe , virtual and local delivery daemons require privileg es . Chroot : whether or not the service runs chrooted to the mail queue directory ( pathname is controlled by the queue_directory configuration variable in the main . cf file ) . Presently , all Postfix daem ons can run chrooted , except for the pipe , virtual and local delivery d aemons . The proxymap server can run chrooted , but doing so defeats most of the purpose of having that service in the first place . The files in the examples / chroot - setup subdirectory desc ribe how to set up a Postfix chroot environment for your type of machi ne . Wakeup time : automatically wake up the named service after the specified number of seconds . A ? at the end of the wakeup time field requests that wake up events be sent only to services that are actually being used . Specify 0 for no wakeup . Presently , only the pickup , queue manager and flush daemons need a wakeup ti mer . Max procs : the maximum number of processes that may execute this service simultaneously . Default is to use a globally confi gurable limit ( the d e f a u l t _ p r o c e s s _ l i m i t configuration paramet er in main . cf ) . Specify 0 for no process count limit . Command + args : the command to be executed . The command name is relative to the Postfix program directory ( pathname is con trolled by the daemon_directory configuration variable ) . Adding one or more -v options turns on verbose logging for that service ; addin g a -D option enables symbolic debugging ( see the debugger_comm and variable in the main . cf configuration file ) . See individual comman d man pages for specific command - line options , if any .

Proyecto Fin de Carrera

xxxvi

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION

60

65

70

75

80

85

90

95

100

105

110

115

# # General main . cf options can be overridden for specific ser vices . # To override one or more main . cf options , specify them as arg uments # below , preceding each option by " - o ". There must be no white space # in the option itself ( separate multiple values for an optio n by # commas ) . # # In order to use the " uucp " message tranport below , set up ent ries # in the transport table . # # In order to use the " cyrus " message transport below , config ure it # in main . cf as the mailbox_transport . # # SPECIFY ONLY PROGRAMS THAT ARE WRITTEN TO RUN AS POSTFIX DAE MONS . # ALL DAEMONS SPECIFIED HERE MUST SPEAK A POSTFIX - INTERNAL P ROTOCOL . # # DO NOT SHARE THE POSTFIX QUEUE BETWEEN MULTIPLE POSTFIX INS TANCES . # # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # ( yes ) ( yes ) ( yes ) ( never ) (100) # ========================================================================== smtp inet n n smtpd # submission inet n smtpd # -o s m t p d _ e t r n _ r e s t r i c t i o n s = reject #628 inet n qmqpd pickup fifo n 60 1 pickup cleanup unix n 0 cleanup qmgr fifo n 300 1 qmgr # qmgr fifo n 300 1 oqmgr rewrite unix trivial - rewrite bounce unix 0 bounce defer unix 0 bounce trace unix 0 bounce verify unix 1 verify flush unix n 1000? 0 flush proxymap unix n proxymap smtp unix smtp relay unix smtp # -o smtp_helo_timeout =5 -o s m t p _ c o n n e c t _ t i m e o u t =5 showq unix n showq error unix error local unix n n local virtual unix n n virtual lmtp unix n lmtp anvil unix n 1 anvil # # Interfaces to non - Postfix software . Be sure to examine the manual # pages of the non - Postfix software to find out what options it wants . # # maildrop . See the Postfix MAILDROP_README file for detail s . # maildrop unix n n pipe flags = DRhu user = vmail argv =/ usr / local / bin / maildrop -d $ { recipient } uucp unix n n pipe flags = Fqhu user = uucp argv = uux -r -n -z - a$sender - $nexthop ! rmail ( $recipient ) ifmail unix n n pipe flags = F user = ftn argv =/ usr / lib / ifmail / ifmail -r $nextho p ( $recipient ) bsmtp unix n n pipe flags = Fq . user = bsmtp argv =/ usr / lib / bsmtp / bsmtp -d - t$ne xthop - f$sender $recipient scalemail - backend unix n n 2 pipe flags = R user = scalemail argv =/ usr / lib / scalemail / bin / scalemail - store $ { nexthop } $ { user } $ { extension }

120

# only used by postfix - tls # tlsmgr fifo n # smtps inet n n -o s m t p d _ s a s l _ a u t h _ e n a b l e = yes #587 inet n = yes -o s m t p d _ s a s l _ a u t h _ e n a b l e = yes

A. Guti´errez Mayoral

300 -

1 -

tlsmgr smtpd -o s m t p d _ t l s _ w r a p p e r m o d e = yes

n

-

-

xxxvii

smtpd -o smtpd_enforce_tls

ETSI Inform´atica

´ C.2. MAQUINA PANTUFLO

125

tlsmgr scache discard

C.2.3.

unix unix unix

-

-

-

1000? -

1 1 -

tlsmgr scache discard

Fichero de configuraci´ on de Dovecot

El fichero de configuraci´ on del servidor de recogida de correo Dovecot se encuentra en /etc/dovecot/dovecot.conf. Listado C.11: Fichero de configuraci´ on /etc/dovecot/dovecot.conf ## Dovecot configuration file # If you ’ re in a hurry , see http :// wiki . dovecot . org / QuickC onfiguration 5

10

15

20

25

30

35

40

# ’# ’ character and everything after it is treated as comment s . Extra spaces # and tabs are ignored . If you want to use either of these expli citly , put the # value inside quotes , eg .: key = "# char and trailing whitesp ace " # # # # #

Default values are shown after each value , it ’ s not require d to uncomment any of the lines . Exception to this are paths , they ’ re just e xamples with real defaults being based on configure options . The pa ths listed here are for configure -- prefix =/ usr -- sysconfdir =/ etc -- loc alstatedir =/ var -- with - ssldir =/ etc / ssl

# Base directory where to store runtime data . # base_dir = / var / run / dovecot / # Protocols we want to be serving : # imap imaps pop3 pop3s # protocols = imap imaps protocols = imaps pop3s # IP or host address where to listen in for connections . It ’ s not currently # possible to specify multiple addresses . "*" listens in all IPv4 interfaces . # "[::]" listens in all IPv6 interfaces , but may also listen in all IPv4 # interfaces depending on the operating system . # # If you want to specify ports for each service , you will need to configure # these settings inside the protocol imap / pop3 { ... } section , so you can # specify different ports for IMAP / POP3 . For example : # protocol imap { # listen = *:10143 # ssl_listen = *:10943 # .. # } # protocol pop3 { # listen = *:10100 # .. # } # listen = * # IP or host address where to listen in for SSL connections . De faults # to above if not specified . # ssl_listen =

45

# Disable SSL / TLS support . # ssl_disable = no

50

55

# PEM encoded X .509 SSL / TLS certificate and private key . They ’ re opened before # dropping root privileges , so keep the key file unreadable by anyone but # root . # ssl_cert_file = / etc / ssl / certs / dovecot . pem # ssl_key_file = / etc / ssl / private / dovecot . pem # If key file is password protected , give the password here . A lternatively # give it when starting dovecot with -p parameter .

Proyecto Fin de Carrera

xxxviii

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION # ssl_key_password =

60

# File containing trusted SSL certificate authorities . Usu ally not needed . # ssl_ca_file = # Request client to send a certificate . # s s l _ v e r i f y _ c l i e n t _ c e r t = no

65

# How often to regenerate the SSL parameters file . Generatio n is quite CPU # intensive operation . The value is in hours , 0 disables rege neration # entirely . # s s l _ p a r a m e t e r s _ r e g e n e r a t e = 168

70

# SSL ciphers to use # ssl_cipher_list = ALL :! LOW

75

80

85

# Disable LOGIN command and all other plaintext authenticat ions unless # SSL / TLS is used ( LOGINDISABLED capability ) . Note that 127 .*.*.* and # IPv6 ::1 addresses are considered secure , this setting has no effect if # you connect from those addresses . # d i s a b l e _ p l a i n t e x t _ a u t h = yes # Should all IMAP and POP3 processes be killed when Dovecot ma ster process # shuts down . Setting this to " no " means that Dovecot can be up graded without # forcing existing client connections to close ( although that could also be # a problem if the upgrade is eg . because of a security fix ) . This however # means that after master process has died , the client proces ses can ’ t write # to log files anymore . # shutdown_clients = yes # Use this logfile instead of syslog () . / dev / stderr can be used if you want to # use stderr for logging ( ONLY / dev / stderr - otherwise it is c losed ) . # log_path =

90

# For informational messages , use this logfile instead of the default # info_log_path =

95

100

105

110

115

120

125

# Prefix for each line written to log file . % codes are in strft ime (3) # format . log_timestamp = " %Y- %m- %d %H: %M: %S " # Syslog facility to use if you ’ re logging to syslog . Usually if you don ’ t # want to use " mail " , you ’ ll use local0 .. local7 . Also other s tandard # facilities are supported . # syslog_facility = mail ## ## Login processes ## # Directory where authentication process places authentic ation UNIX sockets # which login needs to be able to connect to . The sockets are cr eated when # running as root , so you don ’ t have to worry about permission s . Note that # everything in this directory is deleted when Dovecot is sta rted . # login_dir = / var / run / dovecot / login # chroot login process to the login_dir . Only reason not to do this is if you # wish to run the whole Dovecot without roots . # http :// wiki . dovecot . org / Rootless # login_chroot = yes # User to use for the login process . Create a completely new user for this , # and don ’ t use it anywhere else . The user must also belong to a group where # only it has access , it ’ s used to control access for authenti cation process . # Note that this user is NOT used to access mails . # http :// wiki . dovecot . org / UserIds # login_user = dovecot # Set max . process size in megabytes . If you don ’ t use # l o g i n _ p r o c e s s _ p e r _ c o n n e c t i o n you might need to grow this .

A. Guti´errez Mayoral

xxxix

ETSI Inform´atica

´ C.2. MAQUINA PANTUFLO # login_process_size = 32

130

135

140

145

150

# Should each login be processed in it ’ s own process ( yes ) , or should one # login process be allowed to process multiple connections ( no ) ? Yes is more # secure , espcially with SSL / TLS enabled . No is faster since there ’ s no need # to create processes all the time . # l o g i n _ p r o c e s s _ p e r _ c o n n e c t i o n = yes # Number of login processes to create . If l o g i n _ p r o c e s s _ p e r _ c o n n e c t i o n is # yes , this is the number of extra processes waiting for users to log in . # login_processes_count = 3 # Maximum number of extra login processes to create . The extr a process count # usually stays at login_processes_count , but when multipl e users start logging # in at the same time more extra processes are created . To prev ent fork - bombing # we check only once in a second if new processes should be crea ted - if all # of them are used at the time , we double their amount until lim it set by this # setting is reached . This setting is used only if l o g i n _ p r o c e s s _ p e r _ u s e is yes . # l o g i n _ m a x _ p r o c e s s e s _ c o u n t = 128 # Maximum number of connections allowed in login state . When this limit is # reached , the oldest connections are dropped . If l o g i n _ p r o c e s s _ p e r _ c o n n e c t i o n # is no , this is a per - process value , so the absolute maximum n umber of users # logging in actually l o g i n _ p r o c e s s e s _ c o u n t * max_logging _users . # l o g i n _ m a x _ l o g g i n g _ u s e r s = 256 # Greeting message for clients . # login_greeting = Dovecot ready .

155

# Space - separated list of elements we want to log . The elemen ts which have # a non - empty variable value are joined together to form a comma - separated # string . # l o g i n _ l o g _ f o r m a t _ e l e m e n t s = user =< %u > method = %m rip= %r lip= %l %c 160

# Login log format . %$ contains l o g i n _ l o g _ f o r m a t _ e l e m e n t s string , %s contains # the data we want to log . # login_log_format = %$ : %s 165

170

175

## ## Mail processes ## # Maximum number of running mail processes . When this limit is reached , # new users aren ’ t allowed to log in . # max_mail_processes = 1024 # Show more verbose process titles ( in ps ) . Currently shows user name and # IP address . Useful for seeing who are actually using the IMAP processes # ( eg . shared mailboxes or if same uid is used for multiple acc ounts ) . # verbose_proctitle = no # Show protocol level SSL errors . # verbose_ssl = no

180

185

190

195

# Valid UID range for users , defaults to 500 and above . This is mostly # to make sure that users can ’ t log in as daemons or other syste m users . # Note that denying root logins is hardcoded to dovecot binar y and can ’ t # be done even if first_valid_uid is set to 0. # first_valid_uid = 500 # last_valid_uid = 0 # Valid GID range for users , defaults to non - root / wheel . Use rs having # non - valid GID as primary group ID aren ’ t allowed to log in . If user # belongs to supplementary groups with non - valid GIDs , thos e groups are # not set . # first_valid_gid = 1 # last_valid_gid = 0 # Grant access to these extra groups for mail processes . Typi cal use would be # to give " mail " group write access to / var / mail to be able to c reate dotlocks .

Proyecto Fin de Carrera

xl

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION # mail_extra_groups = mail

200

205

210

215

220

225

230

235

240

245

250

255

260

265

# ’: ’ separated list of directories under which chrooting is allowed for mail # processes ( ie . / var / mail will allow chrooting to / var / mail / foo / bar too ) . # This setting doesn ’ t affect login_chroot or auth_chroot v ariables . # WARNING : Never add directories here which local users can modify , that # may lead to root exploit . Usually this should be done only if you don ’ t # allow shell access for users . See # / usr / share / doc / dovecot - common / configuration . txt for more information . # valid_chroot_dirs = # Default chroot directory for mail processes . This can be ov erridden for # specific users in user database by giving /./ in user ’ s home directory # ( eg . / home /./ user chroots into / home ) . Note that usually t here is no real # need to do chrooting , Dovecot doesn ’ t allow users to access files outside # their mail directory anyway . # mail_chroot = # Enable mail process debugging . This can help you figure out why Dovecot # isn ’ t finding your mails . # mail_debug = no # Default MAIL environment to use when it ’ s not set . By leavin g this empty # dovecot tries to do some automatic detection as described in # / usr / share / doc / dovecot - common / mail - storages . txt . There ’ s a few special # variables you can use , eg .: # # %u - username # %n - user part in user@domain , same as %u if there ’ s no domain # %d - domain part in user@domain , empty if there ’ s no domain # %h - home directory # # See / usr / share / doc / dovecot - common / variables . txt for full list . Some examples : # # default_mail_env = maildir :/ var / mail / %1u/ %u / Maildir # default_mail_env = mbox :~/ mail /: INBOX =/ var / mail / %u # default_mail_env = mbox :/ var / mail / %d/ %n /: INDEX =/ var / indexes / %d/ %n # default_mail_env = maildir :/ var / mail / %u / # If you need to set multiple mailbox locations or want to chan ge default # namespace settings , you can do it by defining namespace sec tions : # # You can have private , shared and public namespaces . The only difference # between them is how Dovecot announces them to client via NAM ESPACE # extension . Shared namespaces are meant for user - owned mai lboxes which are # shared to other users , while public namespaces are for more globally # accessible mailboxes . # # REMEMBER : If you add any namespaces , the default namespace must be added # explicitly , ie . default_mail_env does nothing unless you have a namespace # without a location setting . Default namespace is simply done by having a # namespace with empty prefix . # namespace private { # Hierarchy separator to use . You should use the same separat or for all # namespaces or some clients get confused . ’/ ’ is usually a good one . # separator = / # Prefix required to access this namespace . This needs to be d ifferent for # all namespaces . For example " Public /". # prefix = # Physical location of the mailbox . This is in same format as # default_mail_env , which is also the default for it . # location = # There can be only one INBOX , and this setting defines which n amespace # has it . # inbox = yes

A. Guti´errez Mayoral

xli

ETSI Inform´atica

´ C.2. MAQUINA PANTUFLO # If namespace is hidden , it ’ s not advertised to clients via N AMESPACE # extension or shown in LIST replies . This is mostly useful when converting # from another server with different namespaces which you want to depricate # but still keep working . For example you can create hidden na mespaces with # prefixes "~/ mail /" , "~ %u / mail /" and " mail /". # hidden = yes

270

#}

295

# Space - separated list of fields to initially save into cach e file . Currently # these fields are allowed : # # flags , date . sent , date . received , size . virtual , size . ph ysical # mime . parts , imap . body , imap . bodystructure # # Different IMAP clients work in different ways , so they bene fit from # different cached fields . Some do not benefit from them at all . Caching more # than necessary generates useless disk I /O , so you don ’ t want to do that # either . # # Dovecot attempts to automatically figure out what client w ants and it keeps # only that . However the first few times a mailbox is opened , D ovecot hasn ’ t # yet figured out what client needs , so it may not perform opti mally . If you # know what fields the majority of your clients need , it may be useful to set # these fields by hand . If client doesn ’ t actually use them , D ovecot will # eventually drop them . # # Usually you should just leave this field alone . The potenti al benefits are # typically unnoticeable . # mail_cache_fields =

300

# Space - separated list of fields that Dovecot should never save to cache file . # Useful if you want to save disk space at the cost of more I / O when the fields # needed . # mail_never_cache_fields =

305

# The minimum number of mails in a mailbox before updates are done to cache # file . This allows optimizing Dovecot ’ s behavior to do less disk writes at # the cost of more disk reads . # mail_cache_min_mail_count = 0

275

280

285

290

310

# When IDLE command is running , mailbox is checked once in a wh ile to see if # there are any new mails or other changes . This setting defin es the minimum # time to wait between those checks . Dovecot is however able to use dnotify # and inotify with Linux to reply immediately after the chang e occurs . # m a i l b o x _ i d l e _ c h e c k _ i n t e r v a l = 30

315

# Allow full filesystem access to clients . There ’ s no access checks other than # what the operating system does for the active UID / GID . It wo rks with both # maildir and mboxes , allowing you to prefix mailboxes names with eg . / path / # or ~ user /. # m a i l _ f u l l _ f i l e s y s t e m _ a c c e s s = no

320

# Maximum allowed length for mail keyword name . It ’ s only for ced when trying # to create new keywords . # m a i l _ m a x _ k e y w o r d _ l e n g t h = 50

325

# Save mails with CR + LF instead of plain LF . This makes sendin g those mails # take less CPU , especially with sendfile () syscall with Lin ux and FreeBSD . # But it also creates a bit more disk I / O which may just make it s lower . # Also note that if other software reads the mboxes / maildirs , they may handle # the extra CRs wrong and cause problems . # mail_save_crlf = no

330

# Use mmap () instead of read () to read mail files . read () seem s to be a bit # faster with my Linux / x86 and it ’ s better with NFS , so that ’ s the default . # Note that OpenBSD 3.3 and older don ’ t work right with mail_r ead_mmaped = yes . # mail_read_mmaped = no

335

# Don ’ t use mmap () at all . This is required if you store indexe s to shared # filesystems ( NFS or clustered filesystem ) .

Proyecto Fin de Carrera

xlii

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION # mmap_disable = no

340

345

350

355

360

365

370

375

# Don ’ t write () to mmaped files . This is required for some ope rating systems # which use separate caches for them , such as OpenBSD . # mmap_no_write = no # Locking method for index files . Alternatives are fcntl , fl ock and dotlock . # Dotlocking uses some tricks which may create more disk I / O than other locking # methods . NOTE : If you use NFS , remember to change also mmap_ disable setting ! # lock_method = fcntl # By default LIST command returns all entries in maildir begi nning with dot . # Enabling this option makes Dovecot return only entries whi ch are directories . # This is done by stat () ing each entry , so it causes more disk I / O . # ( For systems setting struct dirent - > d_type , this check is free and it ’ s # done always regardless of this setting ) # maildir_stat_dirs = no # Copy mail to another folders using hard links . This is much f aster than # actually copying the file . This is problematic only if some thing modifies # the mail in one folder but doesn ’ t want it modified in the oth ers . I don ’ t # know any MUA which would modify mail files directly . IMAP pr otocol also # requires that the mails don ’ t change , so it would be problem atic in any case . # If you care about performance , enable it . # m a i l d i r _ c o p y _ w i t h _ h a r d l i n k s = no # Which locking methods to use for locking mbox . There ’ s four available : # dotlock : Create < mailbox >. lock file . This is the oldest and most NFS - safe # solution . If you want to use / var / mail / like directory , the users # will need write access to that directory . # fcntl : Use this if possible . Works with NFS too if lockd is used . # flock : May not exist in all systems . Doesn ’ t work with NFS . # lockf : May not exist in all systems . Doesn ’ t work with NFS . # # You can use multiple locking methods ; if you do the order they ’ re declared # in is important to avoid deadlocks if other MTAs / MUAs are us ing multiple # locking methods as well . Some operating systems don ’ t allo w using some of # them simultaneously . # mbox_read_locks = fcntl # mbox_write_locks = dotlock fcntl # Maximum time in seconds to wait for lock ( all of them ) before aborting . # mbox_lock_timeout = 300

380

# If dotlock exists but the mailbox isn ’ t modified in any way , override the # lock file after this many seconds . # m b o x _ d o t l o c k _ c h a n g e _ t i m e o u t = 120 385

390

# When mbox changes unexpectedly we have to fully read it to find out what # changed . If the mbox is large this can take a long time . Since the change # is usually just a newly appended mail , it ’ d be faster to simp ly read the # new mails . If this setting is enabled , Dovecot does this but still safely # fallbacks to re - reading the whole mbox file whenever somet hing in mbox isn ’ t # how it ’ s expected to be . The only real downside to this setti ng is that if # some other MUA changes message flags , Dovecot doesn ’ t noti ce it immediately . # Note that a full sync is done with SELECT , EXAMINE , EXPUNGE and CHECK # commands . # mbox_dirty_syncs = yes

395

# Like mbox_dirty_syncs , but don ’ t do full syncs even with SELECT , EXAMINE , # EXPUNGE or CHECK commands . If this is set , mbox_dirty_sync s is ignored . # m b o x _ v e r y _ d i r t y _ s y n c s = no 400

# Delay writing mbox headers until doing a full write sync ( EX PUNGE and CHECK # commands and when closing the mailbox ) . This is especially useful for POP3 # where clients often delete all mails . The downside is that our changes # aren ’ t immediately visible to other MUAs . # mbox_lazy_writes = yes

405

# If mbox size is smaller than this ( in kilobytes ) , don ’ t writ e index files .

A. Guti´errez Mayoral

xliii

ETSI Inform´atica

´ C.2. MAQUINA PANTUFLO # If an index file already exists it ’ s still read , just not upd ated . # mbox_min_index_size = 0 410

415

# Maximum dbox file size in kilobytes until it ’ s rotated . # dbox_rotate_size = 2048 # Minimum dbox file size in kilobytes before it ’ s rotated # ( overrides dbox_rotate_days ) # d b o x _ r o t a t e _ m i n _ s i z e = 16 # Maximum dbox file age in days until it ’ s rotated . Day always begins from # midnight , so 1 = today , 2 = yesterday , etc . 0 = check disabled . # dbox_rotate_days = 0

420

# umask to use for mail files and directories # umask = 0077

425

430

435

440

445

450

455

460

465

470

475

# Drop all privileges before exec () ing the mail process . This is mostly # meant for debugging , otherwise you don ’ t get core dumps . It could be a small # security risk if you use single UID for multiple users , as the users could # ptrace () each others processes then . # m a i l _ d r o p _ p r i v _ b e f o r e _ e x e c = no # Set max . process size in megabytes . Most of the memory goes to mmap () ing # files , so it shouldn ’ t harm much even if this limit is set pre tty high . # mail_process_size = 256 # Log prefix for mail processes . See # / usr / share / doc / dovecot - common / variables . txt for list of possible variables # you can use . # mail_log_prefix = " %Us( %u ) : " ## ## IMAP specific settings ## protocol imap { # Login executable location . # login_executable = / usr / lib / dovecot / imap - login # IMAP executable location . Changing this allows you to exec ute other # binaries before the imap process is executed . # # This would write rawlogs into ~/ dovecot . rawlog / director y : # mail_executable = / usr / lib / dovecot / rawlog / usr / lib / do vecot / imap # # This would attach gdb into the imap process and write backtr aces into # / tmp / gdbhelper .* files : # mail_executable = / usr / lib / dovecot / gdbhelper / usr / lib / dovecot / imap # # mail_executable = / usr / lib / dovecot / imap # Maximum IMAP command line length in bytes . Some clients gen erate very long # command lines with huge mailboxes , so you may need to raise this if you get # " Too long argument " or " IMAP command line too large " errors often . # i m a p _ m a x _ l i n e _ l e n g t h = 65536 # Support for dynamically loadable plugins . mail_plugins is a space separated # list of plugins to load . # mail_plugins = # mail_plugin_dir = / usr / lib / dovecot / modules / imap # Send IMAP capabilities in greeting message . This makes it u nnecessary for # clients to request it with CAPABILITY command , so it saves one round - trip . # Many clients however don ’ t understand it and ask the CAPABI LITY anyway . # l o g i n _ g r e e t i n g _ c a p a b i l i t y = no # Workarounds for various client bugs : # delay - newmail : # Send EXISTS / RECENT new mail notifications only when reply ing to NOOP

Proyecto Fin de Carrera

xliv

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION # and CHECK commands . Some clients ignore them otherwise , for example # OSX Mail . Outlook Express breaks more badly though , withou t this it # may show user " Message no longer in server " errors . Note that OE6 still # breaks even with this workaround if synchronization is set to # " Headers Only ". # outlook - idle : # Outlook and Outlook Express never abort IDLE command , so if no mail # arrives in half a hour , Dovecot closes the connection . This is still # fine , except Outlook doesn ’ t connect back so you don ’ t see if new mail # arrives . # netscape - eoh : # Netscape 4. x breaks if message headers don ’ t end with the em pty " end of # headers " line . Normally all messages have this , but settin g this # workaround makes sure that Netscape never breaks by adding the line if # it doesn ’ t exist . This is done only for FETCH BODY [ HEADER . F IELDS ..] # commands . Note that RFC says this shouldn ’ t be done . # tb - extra - mailbox - sep : # With mbox storage a mailbox can contain either mails or subm ailboxes , # but not both . Thunderbird separates these two by forcing se rver to # accept ’/ ’ suffix in mailbox names in subscriptions list . # The list is space - separated . # i m a p _ c l i e n t _ w o r k a r o u n d s = outlook - idle

480

485

490

495

} 500

## ## POP3 specific settings ## 505

protocol pop3 { # Login executable location . # login_executable = / usr / lib / dovecot / pop3 - login

510

# POP3 executable location # mail_executable = / usr / lib / dovecot / pop3

515

# Don ’ t try to set mails non - recent or seen with POP3 sessions . This is # mostly intended to reduce disk I / O . With maildir it doesn ’ t move files # from new / to cur / , with mbox it doesn ’ t write Status - header . # p o p 3 _ n o _ f l a g _ u p d a t e s = no

520

# Support LAST command which exists in old POP3 specs , but has been removed # from new ones . Some clients still wish to use this though . En abling this # makes RSET command clear all \ Seen flags from messages . # pop3_enable_last = no # If mail has X - UIDL header , use it as the mail ’ s UIDL . # pop3_reuse_xuidl = no

525

530

535

540

545

# Keep the mailbox locked for the entire POP3 session . # pop3_lock_session = no # # # # # # # # # # # # # # # # # # #

POP3 UIDL format to use . You can use following variables : %v %u %m %f

-

Mailbox UIDVALIDITY Mail UID MD5 sum of the mailbox headers in hex ( mbox only ) filename ( maildir only )

If you want UIDL compatibility with other POP3 servers , use : UW ’ s ipop3d : %08 Xv %08 Xu Courier version 0 : %f Courier version 1 : %u Courier version 2 : %v- %u Cyrus ( = 2.1.4) : %v. %u Older Dovecots : %v. %u Note that Outlook 2003 seems to have problems with %v. %u for mat which was Dovecot ’ s default , so if you ’ re building a new server it wou ld be a good idea to change this . %08 Xu %08 Xv should be pretty fail - safe .

A. Guti´errez Mayoral

xlv

ETSI Inform´atica

´ C.2. MAQUINA PANTUFLO # # NOTE : Nowadays this is required to be set explicitly , since the old # default was bad but it couldn ’ t be changed without breaking existing # installations . %08 Xu %08 Xv will be the new default , so use it for new # installations . # pop3_uidl_format = %f

550

# POP3 logout format string : # %t - number of TOP commands # %p - number of bytes sent to client as a result of TOP command # %r - number of RETR commands # %b - number of bytes sent to client as a result of RETR command # %d - number of deleted messages # %m - number of messages ( before deletion ) # %s - mailbox size in bytes ( before deletion ) # pop3_logout_format = top= %t/ %p , retr = %r/ %b , del= %d/ %m , size = %s

555

560

565

# Support for dynamically loadable plugins . mail_plugins is a space separated # list of plugins to load . # mail_plugins = # mail_plugin_dir = / usr / lib / dovecot / modules / pop3

570

# Workarounds for various client bugs : # outlook - no - nuls : # Outlook and Outlook Express hang if mails contain NUL chara cters . # This setting replaces them with 0 x80 character . # oe - ns - eoh : # Outlook Express and Netscape Mail breaks if end of headers - line is # missing . This option simply sends it if it ’ s missing . # The list is space - separated . # pop3_client_workarounds =

575

} 580

## ## dovecot - lda specific settings ## 585

590

595

# protocol lda { # If you wish to use plugins you need to specify plugin directo ry # For example quota enforcing is implemented by plugin # module_dir = / usr / lib / dovecot / modules / lda # Address from LDA should send MDNs like out of quota # postmaster_address = postmaster@your . dom # If there is no user - specific Sieve - script , global Sieve sc ript is # executed if set . # global_script_path = # UNIX socket path to master authentication server to find us ers . # auth_socket_path = / var / run / dovecot - auth - master # }

600

## ## Authentication processes ## 605

# Executable location # auth_executable = / usr / lib / dovecot / dovecot - auth # Set max . process size in megabytes . # auth_process_size = 256

610

615

# Authentication cache size in kilobytes . 0 means it ’ s disab led . # Note that bsdauth , PAM and vpopmail require cache_key to be set for caching # to be used . Also note that currently auth cache doesn ’ t work very well if # you ’ re using multiple passdbs with same usernames in them . # auth_cache_size = 0 # Time to live in seconds for cached data . After this many seco nds the cached

Proyecto Fin de Carrera

xlvi

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION # record is no longer used , * except * if the main database look up returns # internal failure . # auth_cache_ttl = 3600 620

625

# Space separated list of realms for SASL authentication mec hanisms that need # them . You can leave it empty if you don ’ t want to support mult iple realms . # Many clients simply use the first one listed here , so keep the default realm # first . # auth_realms = # Default realm / domain to use if none was specified . This is used for both # SASL realms and appending @domain to username in plaintext logins . # auth_default_realm =

630

635

640

645

650

655

# List of allowed characters in username . If the user - given u sername contains # a character not listed in here , the login automatically fai ls . This is just # an extra check to make sure user can ’ t exploit any potential quote escaping # vulnerabilities with SQL / LDAP databases . If you want to al low all characters , # set this value to empty . # auth_username_chars = a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 0 . - _@ # Username character translations before it ’ s looked up from databases . The # value contains series of from -> to characters . For example "# @ / @ " means # that ’# ’ and ’/ ’ characters are translated to ’@ ’. # auth_username_translation = # If you want to allow master users to log in by specifying the m aster # username within the normal username string ( ie . not using SASL mechanism ’ s # support for it ) , you can specify the separator character here . The format # is then < username > < separator > < master username >. UW - IMAP uses "*" as the # separator , so that could be a good choice . # auth_master_user_separator = # Username to use for users logging in with ANONYMOUS SASL mec hanism # a u t h _ a n o n y m o u s _ u s e r n a m e = anonymous # More verbose logging . Useful for figuring out why authenti cation isn ’ t # working . # auth_verbose = no # Even more verbose logging for debugging purposes . Shows for example SQL # queries . # auth_debug = no

660

# In case of password mismatches , log the passwords and used s cheme so the # problem can be debugged . Requires auth_debug = yes to be set . # a u t h _ d e b u g _ p a s s w o r d s = no 665

# Maximum number of dovecot - auth worker processes . They ’ re used to execute # blocking passdb and userdb queries ( eg . MySQL and PAM ) . They ’ re # automatically created and destroyed as needed . # a u t h _ w o r k e r _ m a x _ c o u n t = 30

670

# Kerberos keytab to use for the GSSAPI mechanism . Will use the system # default ( usually / etc / krb5 . keytab ) if not specified . # auth_krb5_keytab =

675

680

685

auth default { # Space separated list of wanted authentication mechanisms : # plain login digest - md5 cram - md5 ntlm rpa apop anonymous gs sapi # mechanisms = plain login ## ## dovecot - lda specific settings ## # # Password database is used to verify user ’ s password ( and no thing more ) . # You can have multiple passdbs and userdbs . This is useful if you want to # allow both system users (/ etc / passwd ) and virtual users to login without

A. Guti´errez Mayoral

xlvii

ETSI Inform´atica

´ C.2. MAQUINA PANTUFLO

690

695

700

705

710

715

720

725

730

735

740

745

750

755

# # # # # # # # # # #

duplicating the system users into virtual database . http :// wiki . dovecot . org / Authentication By adding master = yes setting inside a passdb you make the pa ssdb a list of " master users " , who can log in as anyone else . Unless you ’ re using PAM , you probably still want the destination user to be looked up from passdb that it really exists . This can be done by adding pass = yes se tting to the master passdb . http :// wiki . dovecot . org / MasterPassword

# Users can be temporarily disabled by adding a passdb with deny = yes . # If the user is found from that database , authentication will fail . # The deny passdb should always be specified before others , so it gets # checked first . Here ’ s an example : # passdb passwd - file { # File contains a list of usernames , one per line # args = / etc / dovecot . deny # deny = yes #} # PAM authentication . Preferred nowadays by most systems . # Note that PAM can only be used to verify if user ’ s password is correct , # so it can ’ t be used as userdb . If you don ’ t want to use a separa te user # database ( passwd usually ) , you can use static userdb . # REMEMBER : You ’ ll need / etc / pam . d / dovecot file created for PAM # authentication to actually work . passdb pam { # [ session = yes ] [ cache_key = < key >] [ < service name >] # # session = yes makes Dovecot open and immediately close PAM s ession . Some # PAM plugins need this to work , such as pam_mkhomedir . # # cache_key can be used to enable authentication caching for PAM # ( auth_cache_size also needs to be set ) . It isn ’ t enabled by default # because PAM modules can do all kinds of checks besides check ing password , # such as checking IP address . Dovecot can ’ t know about these checks # without some help . cache_key is simply a list of variables ( see # / usr / share / doc / dovecot - common / variables . txt ) which must match for the # cached data to be used . # Here are some examples : # %u - Username must match . Probably sufficient for most uses . # %u %r - Username and remote IP address must match . # %u %s - Username and service ( ie . IMAP , POP3 ) must match . # # If service name is "*" , it means the authenticating service name # is used , eg . pop3 or imap (/ etc / pam . d / pop3 , / etc / pam . d / imap ) . # # Some examples : # args = session = yes * # args = cache_key = %u dovecot # args = dovecot } # / etc / passwd or similar , using getpwnam () # In many systems nowadays this uses Name Service Switch , whi ch is # configured in / etc / nsswitch . conf . # passdb passwd { #} # / etc / shadow or similiar , using getspnam () . Deprecated by PAM nowadays . # passdb shadow { #} # BSD authentication . Used by at least OpenBSD . # passdb bsdauth { # [ cache_key = < key >] - See cache_key in PAM for explanation . # args = #}

Proyecto Fin de Carrera

xlviii

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION

760

765

# passwd - like file with specified location # passdb passwd - file { # Path for passwd - file # args = #} # checkpassword executable authentication # NOTE : You will probably want to use " userdb prefetch " with this . # passdb checkpassword { # Path for checkpassword binary # args = #}

770

775

780

785

# SQL database # passdb sql { # Path for SQL configuration file , see / etc / dovecot / dovecot - sql . conf # example # args = #}

for

# LDAP database # passdb ldap { # Path for LDAP configuration file , see / etc / dovecot / dovecot - ldap . conf for # example # args = #} # vpopmail authentication # passdb vpopmail { # [ cache_key = < key >] - See cache_key in PAM for explanation . # args = #}

790

795

800

805

# # # # # # #

User database specifies where mails are located and what user / group IDs own them . For single - UID configuration use " static ". http :// wiki . dovecot . org / Authentication http :// wiki . dovecot . org / VirtualUsers

# / etc / passwd or similar , using getpwnam () # In many systems nowadays this uses Name Service Switch , whi ch is # configured in / etc / nsswitch . conf . userdb passwd { } # passwd - like file with specified location # userdb passwd - file { # Path for passwd - file # args = #}

810

815

820

825

# static settings generated from template # userdb static { # Template for settings . Can return anything a userdb could n ormally # return , eg .: uid , gid , home , mail , nice # # A few examples : # # args = uid =500 gid =500 home =/ var / mail / %u # args = uid =500 gid =500 home =/ home / %u mail = mbox :/ home / %u / mail nice =10 # # args = #} # SQL database # userdb sql { # Path for SQL configuration file , see / etc / dovecot / dovecot - sql . conf for

A. Guti´errez Mayoral

xlix

ETSI Inform´atica

´ C.2. MAQUINA PANTUFLO # example # args = #} 830

# LDAP database # userdb ldap { # Path for LDAP configuration file , see / etc / dovecot / dovecot - ldap . conf for # example # args = #}

835

# vpopmail # userdb vpopmail { #}

840

# " prefetch " user database means that the passdb already pro vided the # needed information and there ’ s no need to do a separate user db lookup . # This can be made to work with SQL and LDAP databases , see thei r example # configuration files for more information how to do it . # http :// wiki . dovecot . org / AuthSpecials # userdb prefetch { #}

845

# User to use for the process . This user needs access to only user and # password databases , nothing else . Only shadow and pam auth entication # requires roots , so use something else if possible . Note that passwd # authentication with BSDs internally accesses shadow files , which also # requires roots . Note that this user is NOT used to access mai ls . # That user is specified by userdb above . user = root

850

855

# Directory where to chroot the process . Most authenticatio n backends don ’ t # work if this is set , and there ’ s no point chrooting if auth_u ser is root . # Note that valid_chroot_dirs isn ’ t needed to use this setti ng . # chroot =

860

# Number of authentication processes to create # count = 1 865

# Require a valid SSL client certificate or the authenticati on fails . # s s l _ r e q u i r e _ c l i e n t _ c e r t = no # Take the username from client ’ s SSL certificate , using X50 9_NAME_oneline () # which typically uses subject ’ s Distinguished Name . # s s l _ u s e r n a m e _ f r o m _ c e r t = no

870

}

875

# # # # # #

It ’ s possible to export the authentication interface to ot her programs , for example SMTP server which supports talking to Dovecot . Client socket handles the actual authentication - you give it a username and password and it returns OK or failure . So it ’ s pretty safe to allow any one access to it . Master socket is used to a ) query if given client was succ essfully authenticated , b ) userdb lookups .

880

885

890

895

# listener sockets will be created by Dovecot ’ s master proce ss using the # settings given inside the auth section # auth d e f a u l t _ w i t h _ l i s t e n e r { # mechanisms = plain # passdb pam { # } # userdb passwd { # } # socket listen { # master { # path = / var / run / dovecot - auth - master # # WARNING : Giving untrusted users access to master socket may be a # # security risk , don ’ t give too wide permissions to it ! # # mode = 0600 # # Default user / group is the one who started dovecot - auth ( root ) # # user =

Proyecto Fin de Carrera

l

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION

900

# # group = # } # client { # path = / var / run / dovecot - auth - client # mode = 0660 # } # } #}

905

910

915

920

# connect sockets are assumed to be already running , Dovecot ’ s master # process only tries to connect to them . They don ’ t need any ot her settings # than path for the master socket , as the configuration is done elsewhere . # Note that the client sockets must exist in login_dir . # auth external { # socket connect { # master { # path = / var / run / dovecot - auth - master # } # } #} plugin { # Here you can give some extra environment variables to mail p rocesses . # This is mostly meant for passing parameters to plugins . %va riable # expansion is done for all values . # Quota plugin . Multiple backends are supported : # dirsize : Find and sum all the files found from mail director y # dict : Keep quota stored in dictionary ( eg . SQL ) # maildir : Maildir ++ quota # fs : Read - only support for filesystem quota # quota = maildir

925

# ACL plugin . vfile backend reads ACLs from " dovecot - acl " file from maildir # directory . You can also optionally give a global ACL direct ory path where # ACLs are applied to all users ’ mailboxes . The global ACL dir ectory contains # one file for each mailbox , eg . INBOX or sub . mailbox . # acl = vfile :/ etc / dovecot - acls

930

935

# Convert plugin . If set , specifies the source storage path w hich is # converted to destination storage ( default_mail_env ) . # convert_mail = mbox : %h / mail }

C.3.

M´ aquina lechuzo

El u ´nico servicio relevante que se sirve en la m´ aquina lechuzo (servicio cr´ıtico, por otra parte) son los ficheros personales de los usuarios, a trav´es de NFS. El fichero de configuraci´ on m´ as importante es el fichero /etc/exports, que se muestra a continuaci´ on. Listado C.12: Fichero de configuraci´ on /etc/exports #

5

10

# # # # # # # # # #

/ etc / exports : the access control list for filesystems whi ch may be exported to NFS clients . See exports (5) . Example for NFSv2 and NFSv3 : / srv / homes hostname1 ( rw , sync ) hostname2 ( ro , sync ) Example for NFSv4 : / srv / nfs4 gss / krb5i ( rw , sync , fsid =0 , crossmnt ) / srv / nfs4 / homes gss / krb5i ( rw , sync )

# HOMES

A. Guti´errez Mayoral

li

ETSI Inform´atica

´ C.4. MAQUINA PELOTO

15

/ disks / raid / homes . mostoles 212.128.4.0/24( rw , sync , no _root_squash , no_subtree_check ) \ 193.147.56.0/24( rw , sync , no_root_squash , no_subtree_c heck )

C.4.

M´ aquina peloto

El servicio m´ as relevante de esta m´ aquina es el que se ofrece a trav´es del servidor LDAP. La m´ aquina peloto es el servidor LDAP primario del Laboratorio. El fichero de configuraci´ on de este servicio se encuentra en /etc/ldap/slapd.conf. Listado C.13: Fichero de configuraci´ on /etc/postfix/master.cf # This is the main slapd configuration file . See slapd . conf (5) for more # info on the configuration options .

5

####################################################################### # Global Directives : # Features to permit # allow bind_v2

10

15

# Schema and objectClass definitions include / etc / ldap / schema / core . schema include / etc / ldap / schema / cosine . schema include / etc / ldap / schema / nis . schema include / etc / ldap / schema / inetorgperson . schema include / etc / ldap / schema / pantufloperson . schema # Where the pid file is put . The init . d script # will not stop the server if you change this . pidfile / var / run / slapd / slapd . pid

20

# List of arguments that were passed to the server argsfile / var / run / slapd / slapd . args

25

# Read slapd . conf (5) for possible values loglevel 0 # Where the dynamically loaded modules are stored modulepath / usr / lib / ldap moduleload back_bdb

30

# The maximum number of entries that is returned for a search o peration sizelimit -1

35

# The tool - threads parameter sets the actual amount of cpu ’ s that is used # for indexing . tool - threads 1 threads 64

40

45

50

####################################################################### # Specific Backend Directives for bdb : # Backend specific directives apply to this backend until an other # ’ backend ’ directive occurs backend bdb checkpoint 512 30 ####################################################################### # Specific Backend Directives for ’ other ’: # Backend specific directives apply to this backend until an other # ’ backend ’ directive occurs # backend < other > ####################################################################### # Specific Directives for database #1 , of type bdb :

Proyecto Fin de Carrera

lii

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION

55

60

# Database specific directives apply to this databasse unti l another # ’ database ’ directive occurs database bdb # The base of your directory in database #1 suffix " dc = zipi , dc = escet , dc = urjc , dc = es " # rootdn directive for specifying a superuser on the databas e . This is needed # for syncrepl . # rootdn " cn = admin , dc = zipi , dc = escet , dc = urjc , dc = es "

65

# Where the database file are physically stored for database #1 directory "/ var / lib / ldap "

70

75

80

85

90

# For the Debian package we use 2 MB as default but be sure to upd ate this # value if you have plenty of RAM dbconfig set_cachesize 0 2097152 0 # Sven Hartge reported that he had to set this value incredibl y high # to get slapd running at all . See http :// bugs . debian . org /3 03057 # for more information . # Number dbconfig # Number dbconfig # Number dbconfig

of objects that can be locked at the same time . set_lk_max_objects 1500 of locks ( both requested and granted ) set_lk_max_locks 1500 of lockers set_lk_max_lockers 1500

# Indexing options for database #1 # index objectClass eq # index sn , uid , mail , cn eq , pres # index host , uidNumber eq , pres # Save the time that the entry gets modified , for database #1 lastmod on # Where to store the replica logs for database #1 replogfile / var / lib / ldap / replog

95

100

105

110

115

# The userPassword by default can be changed # by the entry owning it if they are authenticated . # Others should not be able to see it , except the # admin entry below # These access lines apply to database #1 only access to attrs = userPassword , shadowLastChange by dn =" cn = admin , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = tgonzale , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = cespedes , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = llopez , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = kleal , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = ceaguero , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = asantos , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = agutierr , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jcenteno , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = mortuno , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = grex , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = vmo , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jmplaza , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jgb , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = fmartin , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = aleonar , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = nemo , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = barrera , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jmrecio , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write

A. Guti´errez Mayoral

liii

ETSI Inform´atica

´ C.4. MAQUINA PELOTO

125

by by by by by by

130

by by by by by

120

135

140

145

150

155

160

165

170

175

dn =" uid = jferrer , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write dn =" uid = acs , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write dn =" uid = anto , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write dn =" uid = eva , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write dn =" uid = pheras , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write dn =" uid = esoriano , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write dn =" uid = lrodero , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write dn =" uid = jfs , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write anonymous auth self write * none

# Ensure read access to the base for things like # s u p p o r t e d S A S L M e c h a n i s m s . Without this you may # have problems with SASL not knowing what # mechanisms are available and the like . # Note that this is covered by the ’ access to * ’ # ACL below too but if you change that as people # are wont to do you ’ ll still need this if you # want SASL ( and possible other things ) to work # happily . access to dn . base ="" by * read # The admin dn has full write access , everyone else # can read everything . access to * by dn =" cn = admin , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = tgonzale , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = cespedes , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = llopez , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = kleal , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = asantos , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = agutierr , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = ceaguero , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jcenteno , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = mortuno , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = grex , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = vmo , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jmplaza , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jgb , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = fmartin , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = aleonar , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = nemo , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = barrera , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jmrecio , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jferrer , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = acs , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = anto , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = eva , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = pheras , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = esoriano , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = lrodero , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by dn =" uid = jfs , ou = usuarios , ou = profesores , dc = zipi , dc = escet , dc = urjc , dc = es " write by * read # For Netscape Roaming support , each user gets a roaming # profile for which they have write access to # access to dn =".* , ou = Roaming , o = morsnet " # by dn =" cn = admin , dc = zipi , dc = escet , dc = urjc , dc = es " writ e # by dnattr = owner write

180

#######################################################################

Proyecto Fin de Carrera

liv

Universidad Rey Juan Carlos

´ ´ APENDICE C. FICHEROS DE CONFIGURACION

185

# Specific Directives for database #2 , of type ’ other ’ ( can be bdb too ) : # Database specific directives apply to this databasse unti l another # ’ database ’ directive occurs # database < other > # The base of your directory for database #2 # suffix " dc = debian , dc = org " #

190

TLSCipherSuite HIGH : MEDIUM : - SSLv2 T L S C A C e r t i f i c a t e F i l e / etc / ldap / ssl / server . pem TLSCertificateFile / etc / ldap / ssl / server . pem T L S C e r t i f i c a t e K e y F i l e / etc / ldap / ssl / server . pem 195

replica uri = ldaps :// zipi . escet . urjc . es binddn =" cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es " bindmethod = simple credentials = replicator 200

205

replica uri = ldaps :// zape . escet . urjc . es binddn =" cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es " bindmethod = simple credentials = replicator replica uri = ldaps :// nano . cct . urjc . es binddn =" cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es " bindmethod = simple credentials = replicator

C.5.

M´ aquina sapientin

La m´ aquina sapientin nos sirve para realizar copias de seguridad diarias de los directorios personales de los alumnos (servidos por la m´ aquina lechuzo). Por tanto, la configuraci´ on de NFS es muy similar (por no decir id´entica) a la de la m´ aquina lechuzo. El fichero m´ as relevante en este caso es el fichero /etc/exports, que es id´entico al de la m´ aquina lechuzo.

C.6.

M´ aquina minervo

La m´ aquina minervo aloja las copias de seguridad de los directorios /etc/ y /root/ de todas las m´ aquinas, de forma incremental. Cada d´ıa, se comprime este directorio y se sincroniza utilizando rsync a la m´ aquina minervo. En principio, esta m´ aquina no tiene ficheros de configuraci´ on relevantes.

C.7.

M´ aquina espatula

La m´ aquina espatula hospeda el servicio de monitorizaci´ on Nagios. Debido a que los ficheros de configuraci´ on de esta aplicaci´on son excesivamente largos y verbosos, no se listar´ an en este documento. En el soporte electr´ onico adjunto se incluyen todos los ficheros de configuraci´ on de esta herramienta.

C.8.

M´ aquina bilo

La m´ aquina bilo aloja para los Laboratorios del Campus de Fuenlabrada los servicios de p´agina web del Laboratorio, servidor de correo electr´onico para las cuentas @bilo.cct.urjc.es as´ı como servidor de recogida de correo electr´onico (al igual que la m´ aquina pantuflo.). Adem´ as, esta m´ aquina aloja los ficheros personales o directorios HOME servidos para el Campus de Fuenlabrada. Adem´ as, esta m´ aquina aloja la p´agina web para el Laboratorio de Fuenlabrada, el A. Guti´errez Mayoral

lv

ETSI Inform´atica

´ C.9. MAQUINA NANO servicio de transporte de correo (Postfix) para el dominio bilo.cct.urjc.es y los respectivos servicios de recogida de correo a trav´es de los protocolos POP3 e IMAP. Debido a que estos u ´ltimos son muy similares a los de la m´ aquina pantuflo (las aplicaciones que se usan son exactamente las mismas, con las mismas configuraciones) redirigimos al lector del documento al soporte electr´ onico si tiene especial inter´es en la consulta de estos ficheros.

C.8.1.

Servicio NFS en bilo

El servicio NFS proporciona los directorios personales de los alumnos a trav´es de la red. La configuraci´ on de este servicio se encuentra en el fichero /etc/exports, el cual se muestra a continuaci´ on: Listado C.14: Fichero de configuraci´ on /etc/exports # / etc / exports : the access control list for filesystems whi ch may be exported # to NFS clients . See exports (5) . / disks / raid / homes . fuenla / 5

C.9.

*. cct . urjc . es ( rw , sync , no_r oot_squash ) \ 193.147.57.0/24( rw , sync , no_root_squash )

M´ aquina nano

Por u ´ltimo, la m´ aquina nano, cuya funci´on es muy parecida a la m´ aquina sapientin del Campus de M´ ostoles (aloja copias de seguridad de los directorios personales de los alumnos) sirve u ´nicamente el servicio NFS de disco en red. Si la m´ aquina bilo deja de funcionar, ser´ıa necesario que la m´ aquina nano comenzara a servir los directorios de los alumnos a trav´es de NFS. En este sentido, el fichero de configuraci´ on de NFS, situado en /etc/exports, es el mismo que el de la m´ aquina bilo, mostrado en la secci´ on anterior. Adem´ as, la m´ aquina nano sirve de forma secundaria el ´arbol LDAP en el que se almacenan las cuentas de usuario de los alumnos y profesores del Laboratorio. El fichero de configuraci´ on de este servicio es exactamente el mismo que el de las m´ aquinas zipi o zape mostrado anteriormente (las cuales sirven el directorio LDAP tambi´en de forma secundaria). Remitimos al lector al soporte electr´onico adjuntado en caso de mostrar inter´es en su consulta.

Proyecto Fin de Carrera

lvi

Universidad Rey Juan Carlos

Bibliograf´ıa

[1] Tom Adelstein, Administracion de Sistemas Linux Anaya Multimedia, 2007 [2] Gerald Carter, LDAP System Administration O’Reilly, 2003 [3] Hal Stern, Managing NFS and NIS O’Reilly, 2001 [4] Michael D. Baurer, Seguridad en Servidores Linux O’Reilly, 2005 [5] Chris McNab, Seguridad de Redes O’Reilly, 2004 [6] Brian W. Kernighan, El Entorno de programaci´ on UNIX Pearson Educaci´on, 1987

lvii

BIBLIOGRAF´IA

Proyecto Fin de Carrera

lviii

Universidad Rey Juan Carlos